20 January 2007

OS/2 Today

Well... This subject are *a lot* boring, but I'm tired to listen that "OS/2 have the best tcp/ip even nowadays" and "OS/2 have a perfect stack and no one make something near". This is a lot stupid, and so, IBM now are devel stuff for linux and a lot of your hardware runs linux internally. Defend this is stupid. OS/2, even in 90s doesn't have the best tcp/ip stack.

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.

1 comment:

  1. It is interresting that you don´t mention the WPS (Work Place Shell), the Killer-Feature of OS/2 that no other OS/2 don´t have yet. My personal attitude is, that OS/2 and of corse eCS is obsolet today. It is a nice toy to play around with, if you know how to play with it, but it is totaly outdated. But the die-hard OS/2 Zelots are still porting Software to that platform just to use it a little bit longer. It is like pumping adrenalin into a dying horse just to push it a few steps further.
    For me, OS/2 was the OS that tried to kicked the ass of Windows in 1994. In 1996 IBM left the Battleground and declared Windows the official winner. It is nice to lock back to this day and toy around the Warp OS, but that´s all.

    ReplyDelete