Hello everyone, and welcome to a double GUI Wonderland Episode, where we explore the birth and evolution of Graphical User Interfaces (GUIs) in computers; today, we’ll have a look at two parallel projects by IBM and Microsoft, OS/2 and Windows 2.x, which shared some development time, and have a very similar UI. Yes, I could have talked about them in two separate Episodes but, given how they’re both shorter and share some points, I decided to release both at the same time!
Whilst I recommend you don’t start reading from 12b (this one), it’s also true that you don’t necessarily have to read 12a, about Windows 2.x, first; in the end, it’s your choice!
That aside, I’ve always been fascinated by this OS, especially as it really seemed to be an improved version of Windows (at least the versions that preceded Windows 95), so I’m looking forward to showing it to you!
This is the first release of Operating System/2 created and developed by a team of both IBM and Microsoft developers, at least initially; unlike Windows 1.x [ep 10] and 2.x, this one is a full operating system complete with its own GUI (from version 1.1 onwards), and it was meant to supersede MS-DOS by taking advantage of the full capabilities of the Intel 80286 processors, such as true multitasking and the ability to manage more RAM than MS-DOS could.
Given how OS/2 belongs to the past now, we can imagine that it didn’t work out, and thus OS/2 ended up being used only for development reasons, or if you needed networking.
It all started when Microsoft began work on a new operating system which would replace MS-DOS, which was still super popular yet not exactly up to date anymore; plus, Microsoft was also intending to release a multitasking version of DOS, which would replace the single-tasking version for the users who still required it. It’s from the latter project that OS/2 actually originated, given how, in August 1985, IBM joined that project and both Microsoft and IBM would have ownership of that OS; later on, that same project would be renamed to CP/DOS (Control Program/DOS), which sounded almost like PC-DOS, yet keeps reminding me of CP/M (Control Program for Microcomputers, invented in 1974).
Unfortunately, that name didn’t stick, as it was then renamed to OS/2; the idea was that the name would resemble the new IBM PS/2 line of machines (a bit of clever marketing there), but it gave people the impression that they could only run OS/2 on that line of computers, which wasn’t actually true.
When it came to deciding who did what, it was concluded that Microsoft would write most of the underlying code, whilst IBM had to design the rest of OS/2; the problem was that IBM had a different modus operandi than Microsoft, one that is still hated today, and that caused a lot of issues for Microsoft. I’m talking about the infamous “kLOCs”, thousand lines of code, which states that the more lines of code you write, the more you’re paid; whoever invented this clearly knew nothing about computers, as your software will run better if it has less bloated code to read. This is essential today, as the idea is that you should always strive to write your code in as few lines as you can; still, you can imagine how, in the eyes of someone who doesn’t understand that software works differently, the more you “work”, the better it is. Thus, you can imagine that the Microsoft developers weren’t exactly thrilled at the idea; they would have a harder time maintaining it, and it would require more RAM and CPU power!
Funnily enough, this was one of the reasons why, when OS/2 1.0 shipped in December 1987, there was one tiny part missing: the entire GUI.
Yes, the system which was supposed to welcome users coming from Windows had no GUI to speak of, and it wasn’t even that optimized; plus, as it was written from scratch, it even had no true 100% DOS compatibility, which left a lot to be desired. Also, what was even more hilarious was that IBM and Microsoft’s marketing said that Windows 2.0 was supposed to be using the same amazing new interface of OS/2… which didn’t exist; not only that, but in a 1987 Computerworld interview, Bill Gates himself said that “three years out, over 80% of new office systems will be based on OS/2”.
At long last, in October 1988, OS/2 1.1 came out, and it introduced Presentation Manager, the GUI that had been promised a year prior; they even had two versions available to buy, which catered to different audiences, one being the Standard Edition, and the other being the Extended Edition, which introduced database support and other useful features for corporate users.
Later on, in 1989, OS/2 1.2 came out, which allowed you to have your installation under the HPFS file system; it was certainly superior to FAT, because it allowed you to have long filenames, as well as other useful features. Plus, if you got the Extended Edition, it also introduced TCP/IP and Ethernet support!
The most intriguing fact for us here is how the GUI itself was adapted to look more like the upcoming Windows 3.x UI; yes, Windows 3.0 was about to come out, which would end up causing numerous issues for OS/2! The problem was that OS/2 didn’t end up being as popular as they thought, and Microsoft didn’t want to partner with IBM anymore; it had understood that Windows 3.0 was good enough, especially given how it sold millions of copies, being bundled with the average computer you could buy. Plus, OS/2 still lacked many drivers for devices such as printers, as IBM wanted to sell its own hardware; the entire OS/2 project was their way to sell more IBM hardware, whilst Microsoft had a wider vision as well as better driver support, and thus, they were bound to break up at some point.
Thus, sadly, this was the end, and as OS/2 1.3 came out in 1990, IBM and Microsoft’s partnership was already over; I mean, Microsoft had other reasons to worry, especially because of the lawsuit from Apple!
Luckily, OS/2’s story would not end like this, as it would be developed further even without Microsoft’s help.
| OS/2 1.1 build 4.72 – 1988-03-07 | This is the earliest known and shared build, and it was included with versions 1.03 and 1.04 of the Microsoft OS/2 SDK; it is also the first build to include the Presentation Manager. It also had the same color scheme and window controls of Windows 2.x, rather than the ones we ended up getting. Bugs: |
| OS/2 1.1 build 4.99 – 1988-06-12 | You can now double click the window menu to close a window, but if you have a 486 processor with a clock speed over 50 MHz, this build will not work. |
| IBM OS/2 1.1 build 4.108 – 1988-08-08 | Again, it doesn’t work when your processor is faster than a 486 due to a bug in the keyboard driver; you can actually fix this by editing the KBD01.SYS file, deleting the code that causes the PC to divide by zero. |
We’re lucky this OS got updated right away, given how, as of version 1.0, we literally had no GUI!
Apart from the lack of the one requirement to be featured in the GUI Wonderland series, OS/2 had several intriguing features that DOS could never normally dream to have, such as:
- It had preemptive multitasking and multithreading;
- It could support virtual memory (swap) up to 1 GB (which wasn’t really doable, but the support existed);
- It could support 16 MB of RAM;
- It all ran in Protected Mode;
- It had a task switcher called Program Selector, that was operated through the Ctrl-Esc combo, and allowed you to switch between various text-mode sessions which were running different programs at once (almost like Alt-Tab).
Luckily, as we saw above, our GUI, called Presentation Manager, arrived in 1988, and 1.1 came in two editions; as we saw before, the Standard one was your regular OS/2 with the new GUI, whilst the Extended Edition added various programs, including a multitasking Database Manager and support for a LAN connection.
Why not 2.0?
It didn’t end up being called 2.0 probably because the most important addition was the GUI, which had been promised since day one, so they felt they had to accomplish that before moving on.
The main part of the new UI was the Presentation Manager, which, in a sense, was much more reminiscent of Windows 3.0 than of 2.0’s MS-DOS Executive; it had two permanent icons on the desktop, which were always there as they represented two crucial parts of the system, the DOS icon and the task manager. However, just like Windows 2.0, each program you opened and minimized would be placed next to these icons on the desktop.
Instead of the MS-DOS Executive [ep 10] program, every time you turned the system on, you’d be greeted by the Start Programs window, which allowed you to add programs to various groups (similar to the category folders in the classic Windows XP/Vista/7 Start Menu, or the categories in something like KDE) and run them from there; whilst programs were usually added automatically, you could always add them yourself or rearrange them, and even if it was a text-based menu, it was certainly more convenient than having to scrounge your file system to find an executable, and a nice alternative to having program icons always on the desktop (like on the Apple systems of the time [ep 7]).
This may seem obsolete or “ugly” (Windows 3.0’s equivalent, Program Manager, at least had icons), but it’s a simple way of launching programs that was still present in Apple’s Finder, the later introduced NextStep, BeOS, and its lightweight and modern alternative, Haiku, alongside other lightweight desktop environments you can still use today; I guess that, sometimes, you just need to be smart with what you have, and simply make it usable, rather than too pretty!
Other than this, it was all fundamentally similar to Windows 2.x, albeit with a different color scheme.
Thanks to it being built as a standalone OS, the developers could implement some “quality of life” upgrades, such as being able to double-click on a file to open it with the associated program; Windows 2.x’s MS-DOS Executive didn’t know how to do that! This is actually more intriguing than it may appear, as it makes OS/2 both partially object-oriented and program-oriented; at the time, an operating system worked only in one way, and based on that, you’d have a different system philosophy.
My beloved Apple Lisa
Let’s explain this a bit better; if your system was like the famous Apple Lisa [ep 3], you wouldn’t click on programs to open them, and then open the files, but you’d click on the file first (or on an “empty” file), which would automatically open the respective program. This meant that you didn’t need to care about the location of your programs, or what they were, you just needed to know where you stored your documents; this was amazing for the average person, who didn’t know what a program was, and simply knew that they had to write a document or a spreadsheet, and didn’t care what program would be used. Of course, power users didn’t need this kind of hand-holding, but it’s still a convenient feature to have. Instead, if you were using DOS or Windows 1.x and 3.x, or the Xerox Star [ep 2], you had to necessarily open a program first; this meant that you had to know which programs you needed, and you needed to be aware of their existence in the first place. Whilst this gives more control to power users, you can understand why this wasn’t too awesome back in the day, when you only really needed a computer for “boring” office tasks; I mean, that’s why GUIs were invented in the first place [ep 1]!
This screenshot of the Xerox Star desktop was a pain to take, so there you go
Back to OS/2, other parts of the system also acted in a similar way to the programs, such as actions you could do on files or parts of the system (like paragraphs in texts); the idea was that you’d select an item first, and then choose an action to perform. Again, it looks like a far-fetched thing to consider, but this wasn’t so obvious at the time; many programs at the time, especially text-based ones, had Modes, which were “states” of a program that you would activate at the press of a button, and that would change how a program operated. The problem was that you had to turn them off, and most of the times, you had no idea whether they were actually activated or not; this led to numerous mistakes (like formatting text rather than inputting it), or just to plain frustration, as average users couldn’t understand how to exit Modes! Some systems and programs of the time were aware of this and tried to mitigate it, especially thanks to the research by Larry Tesler [ep 3] and Jef Raskin [ep 7], who also wrote this fascinating book about GUIs; it’s nice to see how, despite it being less famous and widespread, OS/2 was so modern!
Here are the other important programs that made up the system; first of all we have the File Cabinet, which allows you to manage drives, directories, programs, and system files. Then, we have the Task Manager, which is brought up by clicking on the third mouse button (the right one, by today’s standards) or Ctrl+Esc, and allows you to check running programs and processes; it also has some window management functions, as you can bring hidden windows to the front and close the unneeded ones. Additionally, the Task Manager allows you to access the Shutdown menu, which can either save your current desktop and remember what apps you had open, or just reset everything.
Lastly, we have the Control Panel, which allows you to change your usual system setting, but it also lets you modify some more intriguing stuff; you can decide the colors of basically every element of the system, even the background of windows or the color of the scroll bar! You can even resize borders, which may make them harder to manipulate but will increase the space you have available on your screen; or, if you’re having trouble manipulating them, you can make them thicker! Some other options allow you to remove logos, and invert the order of mouse buttons.
Unless an application is running in DOS full screen mode, it will be always run in a window; we all know how a window works as we have met windowing in older Episodes [ep 2 + 3 + 8], yet there are some interesting intricacies here. Apart from the fact OS/2’s window manager is both reparenting and compositing [ep 11], by reading the developer manuals we can understand that whether an app will share its screen with others or not is based upon entering a specific “session”, and the program will enter one of them based on their needs or coding. Additionally, every program, even the tiniest one, needs a window when they want to accept input and produce output, and that’s when they’ll start receiving info by OS/2.
Something that may confuse people is how the Action Point, the position of the mouse pointer, will determine whether a window is active or not; on many window managers today, such as Windows, MacOS or KDE’s, you must click on a window to make it active. Unlike those, OS/2 will make a window active when the mouse pointer is inside its borders, even if you haven’t clicked on it beforehand; it can be a useful feature, but it can also lead to many mistakes if one isn’t careful, which is why window managers tend to avoid it. Another example of a feature that wants to minimize errors is found in the icons for minimized windows that appear on the desktop; unlike what you’d do today, you’ll need to double-click on them to maximize them.
Lastly, similarly to Amiga OS [ep 8] and X11 [ep 11] environments, the system wallpaper is its own window, and it’s called Desktop Window; there’s even an invisible one to host all of the programs that don’t need to be displayed on screen, called Desktop-Object window.
There were two types of programs, depending on how they interacted with the screen; the “Presentation Manager” programs were the ones that could play nice with the GUI shell, and whose windows could be resized, whilst the “non-Presentation Manager” ones would occupy the entire screen. Of course, they couldn’t use any features of the Presentation Manager, and weren’t so comfortable to use in multitasking; these were often DOS applications, which had limited support.
Being built from the ground up in order to ignore DOS, you could imagine that there were some problems in making DOS programs run; they could have tried virtualization, but the 286 didn’t allow virtualizing real mode, which is how you ran DOS programs. The problem was that, when Intel made the 286, they didn’t expect DOS to last any longer, so they didn’t offer an easy way to switch from protected to real mode.
Still, a smart engineer at Microsoft, Gordon Letwin, found a way to make it work; they would induce a hardware reset on the CPU, and then it would switch to real mode, and they ended up using this trick in Windows/286 and Windows 3.x as well!
Even with this problem partially taken care of, their DOS API was still incomplete, so many programs had to access the hardware directly rather than through OS/2. As you can imagine, this was a problem for whoever still relied on DOS programs, something that we saw happen with both Windows 1.x [ep 10] and the Mindset [link], and this also contributed to the system being more niche.
Even if many apps had not been ported yet, Microsoft still offered compatible versions of all the professional compilers, so whilst the Word and Excel versions weren’t ready yet, third parties could still develop for OS/2.
In case you wanted to develop DOS apps which would be guaranteed to run fine on OS/2, you could build them in “family mode”, which could work fine on both OS/2 and DOS, yet of course, they’d have no special features in them, as they had to be compatible; whilst this meant that they had not escaped DOS yet, at least they could satisfy both crowds in one go!
People were thrilled about the release of OS/2, especially as IBM was marketing it as the future of computing; given how the IBM PC was so revolutionary, people had good reason to believe them. Plus, it was also getting announced alongside some new shiny hardware, the PS/2 line, so it really was exciting!
Let’s see what people thought of this new revolution!
In 1989, BYTE included it in its “Excellence” winners of the BYTE Awards, saying that even if it wasn’t perfect yet, it was still a really good product, and it just needed developers to make apps for it, similarly to the Macintosh’s situation in 1984 [ep 7]; additionally, they believe OS/2 could have definitely replaced DOS, if only there were more compatible computers around.
Something users loved was that it had true multitasking, which only the Amiga had; whilst you could multitask in Windows and on the Macintosh, minimized apps would be frozen so that the computer could make the current one work.
Unfortunately, by November 1989, OS/2 had not sold very well, especially because not all PCs had the kind of hardware needed to optimally run it; plus, it was buggy, and given how bloated it was because of IBM’s kLOCs policy, we shouldn’t be so surprised.
Plus, its DOS compatibility wasn’t good enough, and customers just couldn’t justify spending the huge amount it cost, to then have to buy MS-DOS too in order to run certain apps; plus, it was even harder for developers, as the development kits cost thousands of dollars, with the first one in April 1987 costing $3000!
Lastly, it lacked drivers for many devices and printers, and if you add that to its sneaky name, you can understand why people would think that you needed IBM hardware to run it; thus, unless you needed much more power or special OS/2 apps, it was more reasonable to buy a Windows 2.x copy and MS-DOS.
Still, it was a huge step for computing, and it would have gotten considerably better in the time to come!
Poor OS/2’s story might be paused for now, but it will resume soon enough in a future Episode, so stay tuned!
If you haven’t read Windows 2.x’s side yet, you can do so by clicking here.
Our next stop in our journey in GUI Wonderland will bring us to visit Acorn Computers and their Acorn Archimedes computers, with their Arthur (later RISC OS) operating system! Then, if I can make it work we’ll also have a look at a 3D game called Zarch, which you could play on your Acorn Archimedes computer!
Also, before you go, have a look at the References and Further Reading section, to find more materials to read.
Thank you for reading, and I hope I’ll see you in the next GUI Wonderland Episode, in our next Journal Page about video games and others, or anywhere around the site!
This contents of this article are for entertainment, commentary and/or educational purposes only, and any copyrighted material used within the confines of it are being used under the fair use provisions of copyright law.
Anything within this article that might fall outside of those confines are entirely unintentional, and we will be more than happy to remove the offending material immediately. You can find links to all sources used by either clicking here or scrolling to the “References” section above, however, if we have missed a credit anywhere, please let us know and we will be happy to rectify the issue.
All rights and credit belong directly to their rightful owners. No copyright infringement is intended.