Even with a dead OS, there's a lot of people crying with this arguments, but... like 70% of freebsd users, all people defending unfundable stuff use windows as your primary OS. All arguments are based in hipocrisy.
But lets talk about OS/2:
- Single input queue (SIQ): if a GUI application was not servicing its window messages, the entire GUI system could get stuck and a reboot was required.
- No unified command line: OS/2 divided programs into strict categories and communication between programs of different categories was problematic: It was not possible to enter fullscreen mode from a "windowed OS/2 session"; a separate "fullscreen OS/2 session" was required, which could not be made windowed. It was not possible to run DOS or Windows programs from an OS/2 session: a specific "DOS session" was required. From this DOS session (which could be toggled fullscreen) it was not possible to start OS/2 programs.Therefore transparent piping of data was not possible. Worse, in the absence of 8.3 aliases for filenames and directories and DOS API extensions supporting long filenames, it was also problematic to give DOS programs access to files managed from OS/2 programs. Even native OS/2 programs had problems communicating: a command-line program could not fully access the system clipboard, which was reserved for "GUI" programs.
- Workarounds consisted in creating special helper programs (for example an invisible GUI program just for accessing the clipboard) or in using client-server setups, where the client and the server were different types of programs, but communicated using some available way. Just as OS/2 1.x, the 32-bit system was apparently designed with the idea that users would rapidly make a switch to all-native programs.
- No unified object handles. The availability of threads probably lead system designers to overlook mechanisms which allow a single thread to wait for different types of asynchronous events at the same time, for example the keyboard and the mouse in a "console" program. Even though select was added later, it only worked on network sockets. In case of a console program, dedicating a separate thread for waiting on each source of events made it difficult to properly release all the input devices before starting other programs in the same "session". As a result, console programs usually polled the keyboard and the mouse alternatively, which resulted in wasted CPU and a characteristic "jerky" reactivity to user input. In OS/2 3.0 IBM introduced a new call for this specific problem.
- No unified virtual memory and disk cache. Modern operating systems can use the entire available RAM for disk caching and can map files into the address space of processes. OS/2 had a dedicated memory pool for disk caching and could not map files. This could result in decreased performance and RAM waste.