Research Stream: Examining Presentation Manager

From DisNCord Community Wiki
Jump to navigation Jump to search

Research Stream
OS2 Research Stream Thumbnail.png
Presentation Manager
VoD LinkRESEARCH STREAM: Examining The Early OS/2 GUI - Presentation Manager
Streamed OnJanuary 29th, 2023
Streamed byNCommander
Stream typeEmulated on 86Box


The goal in this stream is to understand the impact of Presentation Manager on OS/2. During this stream, we looked at OS/2 1.1, 1.2, and 1.3, and began to chart the course of the GUI portions of OS/2. For those unfamiliar with OS/2, the Presentation Manager is both the GUI and programming API for making graphical applications. Presentation Manager, at least in my opinion, suffers from serve technical flaws, and I find is unfit for purpose, at least in this era, primarily because its a forced addition.

Unlike Windows of the era, it's not (officially) possible to run OS/2 without PM at least being nominally loaded, and the existence of Presentation Manager drastically increases the base system requirements for OS/2 as a whole to a notational minimium of 2 MiB of RAM, although, in practice, 4 MiB is needed for it to actually be usable.


This section describes why certain choices were made for a given stream and more.

Use of Extended Edition

Extended Edition was IBM's special version of OS/2 and was not directly sold to customers. Instead, Extended Edition was available to existing IBM corporate customers, and included additional line of business applications that weren't included out of the box. During the 16-bit era, these applications were

  • Database Manager and Query Manager
  • Communication Manager
  • LAN Server and LAN Requester

While this project mostly deals with OS/2 as a whole, very little software has survived into 2023 for the early 16-bit versions of OS/2. As such, using Extended Edition at least provides additional applications and functionality, so we may get a better idea of how OS/2 was marketed and used, something we'll explore more with Hello World applications and system development.


Borland Sidekick was a very popular TSR for handling data, and it was also one of the first available Presentation Manager applications.[1] The direct comparison allows to show how the GUI did or didn't improve things ...

Console Multitasker

This would have probably been the main use for early Presentation Manager, since there were very few native graphical applications at the time period, although I won't be surprised if some developers used TSHELL or the like to make do with less capable hardware.

Questions Asked and Answered

These were questions I wrote down and asked before doing the stream to try and answer them, and my collected feelings over them.

How is Presentation Manager at handling running multiple console sessions at once?

OS/2 showing multiple instances of CMD.EXE in use

This question was asked originally during the drafting stages. Throughout OS/2's lifespan, there was very little in terms of native applications, nor were many applets included out of the box.'

In a standard non-OEM install, the default installed applications were the E Text Editor in OS/2 1.2 and later as a graphical application, and some settings applications. That mean, by and large, the biggest "value" of Presentation Manager was to be able to do multiple overlapping windows. This in and of itself already has some value. For example, X Windows, both then and now, is commonly used to simply manage multiple terminal emulators. The default configuration for many X environments when running xinit/startx is to load up 2-3 xterms, which in and of itself is a major upgrade over simply working on the console on UNIX/Linux.

On a high resolution display, Presentation Manager would not be dissimilar from Windows 2.x's DOS Executive, Windows 3.x Program Manager, or even graphical UNIX systems of this era. However, OS/2 had exceptionally poor support for OEM's and vendors. While it would technically be possible to run OS/2 1.x on a period correct high resolution video card such as the 8514/A, by and large, very few non-IBM cards were supported. As it stands, OS/2 1.1 doesn't appear to have support for anything greater than VGA graphics. OS/2 1.2+ can use 8514/A, and drivers for XGA and a handful of other chipsets are also available.

However, by and large, you would have been exceptionally lucky to run OS/2 beyond 640x350 display resolution with the then new VGA standard. EGA, with a max resolution of 640x350 and, based off the written accounts I've found, it appears using OS/2 with at least CGA and EGA adapters was at least semi-common practice. OS/2 1.0 also supported MDA adapters, which were still semi-common in this time period.

One problem that was encountered is that certain OS/2 applications, including E.EXE, require the use of full screen mode, and can not run in a console window. It's not certain as to why it is, although this limitation can be patched out as described on the OS/2 Museum[2], and likely deals with the specifics of the Vdu API.

Is Presentation Manager an upgrade over the TSHELL interface?

OS/2 1.0 with TSHELL

At least with OS/2 1.1 and 1.2, Presentation Manager is a questionable at best upgrade. By and large, its slow and bloated, especially compared to Windows of the era, and other graphical interfaces. This, in and of itself, might not have been a big issue, but due to the problems with console applications mandating the use of full screen UIs, general slowdowns, and more, by and large, Presentation Manager appears to be a strict downgrade over both OS/2 1.0, and Windows of this era. While Presentation Manager got better, it was too little, too late.

By and large, the functionality of Presentation Manager is no different from Windows 2.x of this era, albeit with a slightly less blinding color scheme. Presentation Manager was originally announced as a core component of OS/2, but didn't ship until OS/2 1.1 until October 1988.[3]

As far as graphical systems went, in a consumer market, OS/2's main competition in this era would have been Microsoft Windows, Apple's Macintosh, and Commodore's Amiga platform, as well as general UNIX efforts in the form of Xenix, SunOS, and others.

Originally, as part of the OS/2 SDK efforts[4], Microsoft provided beta builds of OS/2 1.0 up until its final release. Early builds including the prototypes of the Presentation Manager were also shipped through this program up until OS/2 1.2 from what I can see.

Why would you buy OS/2 over DOS?

This question was came up during livestreaming the drafting of these notes. Understanding why you would buy OS/2 is an important step in understanding the market.

This is a somewhat subjective question, but the two main markets for OS/2 were developers trying to future proof their products, and corporations looking for a platform to build applications on. Microsoft appears to have mostly catered to the developer market, with the release of the OS/2 SDK and generic non-OEM releases, while IBM appeared to only care about customers who simply needed a smaller alternative to their mainframe and minicomputer lines of systems, and which price was not necessarily an objection.

IBM's extended editions of OS/2 very much point to a company that is trying to achieve vertical integration within the market, and it did find some success in these fields. Rather notably, OS/2 is still actively supported in 2023 by Arca Noae, and it is still in production use in places, such as powering the New York City Subway Metrocard payment system.

How did people buy OS/2

Operating systems, and specifically how OSes were bought and sold were very different in the 1980s vs. even the 1990s or the modern era, thus some context is needed. This wasn't asked originally, but was added here to provide context for other questions

Early use of OS/2 was primarily by developers, and those who needed a better platform for business purposes. The first developer releases and betas were released as part of a $3000 software development kit, which included not only OS/2, but printed programming manuals, Windows 1.x, Microsoft C compiler, and much more. After 1987, and the formal OS/2 1.0 release, the situation gets a bit more complicated. For those on true IBM hardware, IBM offered two distinct versions of OS/2: The rather aptly named "IBM OS/2 Standard Edition", and what we've mostly looked at, "IBM OS/2 Extended Edition", which can best be seen as equivalent the differences between the client and server versions of Microsoft Windows.

The situation is somewhat different if you weren't an IBM customers. While there is a de facto standard for 8088 based computers since by and large, everyone copied the IBM PC 5150, and 5160, there is much wider amount of variation in terms of hardware and capability from the 286 era to the tale end of the 486 era. By and large, systems were not interchangeable, and compatibility issues were distressingly common. This is due in part due to the the lack of a protected mode ABIOS, differences in disk interfaces, and just flat out hardware bugs.

By and large, operating systems were sold for specific hardware, and the idea of a generic PC operating system wasn't as clear cut then, as it is now. For example, a commonly cited reason for OS/2's poor adaption was the belief that you needed a PS/2 system for it to work, or otherwise needed a tailor made OEM version. This is similar to how you had PC-DOS for IBM machines, COMPAQ DOS for Compaqs, etc. Likewise, known OEM versions of OS/2, all based on the generic Microsoft release, were available from Tandy, Nokia, Intel, and others. From what I can see from examining multiple non-IBM OEM releases, the only significant differences appears to be drivers, installation media (3.5 vs 5.25) and documentation changes.

It's not clear that end users were really intended to install OS/2 by themselves. While operating system installation got progressive easier through the 80s and 90s, there was still a fairly high barrier to entry, just due to compatibility concerns. If you were going to switch over to OS/2, you'd probably need an upgraded PC, new library of OS/2 native software, and more.

What are the minimum requirements for running Presentation Manager

The stated requirements for Presentation Manager 1.1 appears to be any 286 processor, and 2 MiB of Extended Memory + 640kb of conventional memory. While OS/2 1.1 will install, and Presentation Manager will load, it is practically unusable in this configuration. In practice, to be usable, OS/2 1.1 required 4 MiB of memory, and really wants a 20-30Mhz processor of some sort. This is hardware that was either exceptionally expensive at the time, or simply did not exist.

OS/2 1.2 and more notably 1.3, still had the higher memory requirements, but were somewhat more performant than OS/2 1.1, likely due to code optimizations and improvements in Microsoft's C compiler.

What was Presentation Manager and OS/2's competition in this era

Enduser Competition

  • Apple Macintosh
  • Amiga Workbench
  • Microsoft Windows
  • DESQView

Server Competition

  • Novell NetWare

Minicomputer Competition

  • UNIX (all sorts including Xenix)
  • IBM's own mainframes?

Other Competitors

  • Atari TOS
  • 3COMM 3+Share

Deferred Questions

These questions are better suited for future livestreams ...

  • How does Windows 2.x compare Presentation Manager in OS/2 1.1?
  • How does the Windows 2.x development environment differ from Presentation Manager?
  • How does Borland Sidekick compare between DOS and Windows?

Interesting Timestamps


Presentation Manager on OS/2 1.1

OS/2 1.1 with a few applications installed

During the original livestream, I used OS/2 1.1 and 1.2 pretty extensive on air. OS/2 1.1 is in many ways closer to a public beta than it is to an actual retail product. While it is theatrically possible to run Presentation Manager within 2.5 MiB of memory, which is the actual documented minimums, it cases so much thrashing (due to disk paging) that the system is practical unusable. This is a long departure from the relative simplicity and performance of the TSHELL interface on OS/2 1.0.

The problem is that Presentation Manager (and the underlying Graphics Precision Interface or GPI), was both bloated, and extremely unoptimized in this initial release of OS/2, which was further compounded by the fact that the ability to quit to a command line was either removed, or never implemented. That meant, even if you didn't need graphical applications such as running a text editor and/or C compiler, you still had to deal with the performance overhead imposed by Presentation Manager. Considering that OS/2 1.0 was usable in 512kb of extended memory, the value to cost ratio is, at best, misplaced.

It should be noted, that beta versions of OS/2 1.1 showed something much closer to Windows 2.x running ontop of OS/2, and is subject to further investigation.

Console Applications under Presentation Manager

The E editor editing CONFIG.SYS on OS/2 1.1. Note that out of box, it must run in full screen mode

By and large, support for console applications on OS/2 was/is fairly terrible. The E editor, which is the only OS/2 native editor included in the box only runs "full screen", it can't run in a console window. This is also true of MEP, or the M editor, which is what Microsoft provided on the SDK, and was also available for some versions of Windows NT.[5] This isn't a limitations of OS/2 in and of itself; it is possible for 'graphical' console applications, like the Word for OS/2 setup manager to run without a problem. This is likely similar to how binaries for Windows 1.x/2.x must be marked for 3.x and later.

That meant that you couldn't even take full advantage of overlapping windows, you would have to press Ctrl-Esc to bring up the task manager, and switch back and forth, which could also change screen resolution. It's difficult to experience this accurately in emulation, but on the whole, this feels considerably slower, and clunker than the original TSHELL that was in OS/2 1.0. In addition, as a note going forward, IBM never fully cleaned up the console API. Even until the final version, it was essentially unchanged from OS/2 1.0, and never got a 32-bit interface except in the ill fated PowerPC port.

Fundamental Design Problems with Presentation Manager

As a matter of policy, both Microsoft and IBM de-emphasized the use of traditional console and text based applications, even though these would actually remain common well into the 90s and beyond. However, disregarding this, Presentation Manager manages to negate most of the advantages brought by the OS/2 kernel. Memory usage and general performance aside, OS/2 graphical applications use what is known as the Single Input Queue or SIQ to handle messages for each individual application. This is fundamentally how 16-bit Windows worked, and aspects of this design actually are still present in the modern day Win32 API (in the form of Get/PeekMessage and the like).

Presentation Manager has a similar programming interface to Windows 2.x and later, but entirely replaces the graphics interface with IBM's own "Graphics Programming Interface", which makes several arbitrary changes from Microsoft's GDI (Graphics Device Interface), presumably to meet some sort of requirement within Big Blue itself. Prototypes of OS/2 1.1 show a Windows 2.x like interface before evolving to the Presentation Manager that we have now.

Single Input Queue

The Single Input Queue (also known as the Single Event Queue) is used to provide messages and user input to all PM applications. The SIQ, as best I can tell, is a performance and memory hack. Window manager events (aka, anything started WM_*) pass through the SIQ, and are processed by each application. However, because there's only one system wide queue, a single application can lock up the entire system without fail by either not properly pumping the SIQ, or by injecting so many messages, that it overflows, and hangs the system.

This entirely negates OS/2's pre-emptive multitasking, and by and large, reduces system stability to that of early DOS and Windows. This is inspite of the fact that OS/2 supports threading, which is how the SIQ problem was solved on Windows NT. It wasn't until the release of OS/2 Warp 4, Fixpack 17, released over a decade later, that a partial fix for the SIQ was finally shipped by IBM.[6]

The reasons as to why the SIQ exist vary, and as of writing, I haven't found a first party explanation as of yet, although one likely exists. The most commonly cited reason I've seen is due to performance penalties, either due to the 286, or the overall design of OS/2 threading. It is also possible that IBM was waiting for NT OS/2 (which never happened) to fix the problem properly, and when OS/2 2.x "Cruiser" fell through due to Microsoft withdrawing from the project, although this can not be proven at this time.

It should be noted (and pointed out by Tom Rune Berg in chat), that a SIQ lockup doesn't actually freeze the entire system. Non-graphical applications running at the time of a PM crash will keep running without issue. However, there's no built utility (nor programming API that I am aware of) that can forcibly restart Presentation Manager after a crash. As such, while OS/2 is pre-emptively multitasked, it is effectively cooperatively multitasked as far as graphical applications go.

NOTE: The reason I say effectively cooperatively multitasked is that the event loop is processed as in 16-bit Windows applications. While getting a PM application stuck in a tight loop might not necessarily crash the system as a whole, it can lead to the SIQ becoming exhausted, and that will lead to PM deadlocking. While this isn't *technically* a cooperative multitasking problem, the end result is very similar to 16-bit Windows, hence why the comparison is made here.

Hardware Compatibility Issues

Getting OS/2 to run on period correct hardware is difficult at best. In general, compatibility at best is hit or miss, and very few period correct systems have enough memory, and processor power to actually run OS/2 in any significant fashion. Even with the correct system, installing 4 to 12 MiB of memory in a 286-class system is not a trivial undertaking. Furthermore, success on installation entirely depends on if you are using the correct edition of OS/2, and your system is sufficiently close enough to an IBM machine, that the very limited set of built in drivers will cover you.

In short, unless you have a OEM release, don't expect anything but the bare basics to work. Even in emulation, getting OS/2 working on a 286 is a non-trivial undertaking. As of writing, I'm still dealing with getting an IBM Model 30 286 in good enough shape to try and run it on real hardware. While I can't speak specifically what a "new in box" experience might have been like in 1987, what I can say its distressingly common for OS/2 to simply hang on startup with no debugging messages. While this was also true of OS/2 1.0, this problem persisted throughout the entire 16-bit era, and no doubt formed many of the negative opinions made about OS/2 in this time period.

Borland Sidekick for Presentation Manager

About Box in Sidekick's Calculator

There was very few third party applications for OS/2 across its entire lifespan, however, applications for the 16-bit era are especially hard to come by. In general, only Microsoft offered "good" support for OS/2, and in general, most vendors, like Borland and Lotus, either never provided an OS/2 port, or only provided one for a short period of time. One exception to this rule is Borland, who did support OS/2 quite a bit better than most of the competition, including ports of Turbo C, and more to the platform.

Borland's Sidekick was an extremely popular on DOS based systems as a personal information manager, or PIM application. Under DOS, Sidekick ran as a TSR, and it was possible to due a very limited form of multitasking, by having Sidekick break in and interrupt other DOS applications, and then copy and paste data as a series of keystrokes. This is pretty common for DOS of the era, and other products, such as Microsoft Bookshelf, work very similar to provide a "de facto" integration with otherwise single tasking applications.

Notably though, Borland did provide a version of Sidekick that ran under 16-bit Presentation Manager, and there does appear to be a later 2.x version for 32-bit systems. This article is only concerned with the 16-bit version, and its one of the few applications we can draw a direct line of comparison from DOS to OS/2.

Unfortunately, Borland Sidekick for OS/2 is not a great example of what graphical applications could offer. Instead of a nice and easy to use interface, Sidekick for OS/2 is extremely slow and laggy, and is more of an exercise in pain to actually use. As compared to a DOS TSR, while the PM version of Sidekick looks nice, it behaves quite poorly, with visibly slow redraws and more. It's unclear if this is a side effect of OS/2 1.1 in general, or poor coding in Sidekick itself.

However, while Sidekick supports the system clipboard, it is impossible to copy and paste into terminal windows on this version of OS/2. It also has no integration with the DOS compatibility box, which means that, by and large, this is actually a downgrade from the earlier product due to lower levels of integration.

Microsoft Word for Presentation Manager

Word for Presentation Manager - Startup Splash

Microsoft applications in this era provide a unique insight on how the transition from DOS to OS/2 was supposed to take place. As we saw in during the OS/2 1.0 exploration Word 5.0 and 5.5 for DOS also included native support for OS/2 as a text mode application. This is a special type of application known as a "family mode" application, which can work without changes on DOS, OS/2 and Windows NT, and was supposed to be the 'seamless' migration path of the future.

Word for Presentation Manager is directly based off Word for Windows 1.1a, the source code of which is available under a non-commerical license from the Computer History Museum. Back in 2021, I did a video on building Word for Windows ontop of a OS/2 host environment, and got a fairly good understanding of how Microsoft was approaching application compatibility in this era. It also provides a unique opportunity to look at a single application that worked on Windows 2.x, 3.x, and OS/2 all within the same period of time.

Unlike most applications of this era, Word is not compiled to native binary code. It's instead compiled to P-code, and run ontop of a virtual machine, similar to Pascal of the era. Microsoft used an internal compiler to do this, which was shared with at least Multiplan, and Excel of this era, and was used to port Microsoft products to a wide variety of platforms. In addition to DOS, Windows, and OS/2, Word was ported to multiple UNIX platforms, classic Mac OS, and the Atari ST (in the form of Microsoft Write). As implied, Word was also the basis for the Write editor included in Windows 1.x to 3.x, as denoted by the JR flag within the Word for Windows source code (and thus also gives a point of comparison with the WLO applications).

From what I can tell, Word for Presentation Manager works just fine, and is feature equivalent to Word running on Windows 2.x. What I can't find is a compelling reason to use this. Word for Windows will run just fine on a 8088 with 640 kb of memory, under Windows 2.0. Or in short, you can run it with no loss of functionality on a system literally 1/4th as capable, with subjectively less latency and lag.

What this says about OS/2 as an application platform is left as an exercise to the reader ...

OS/2 1.2 - The Feature Complete Release

Desktop Manager on OS/2 1.2-1.3

OS/2 1.1 was not a long lived product, and was rapidly replaced with OS/2 1.2 in late 1989[7]. 1.2 represents what could be called the first "feature complete" version of the OS/2 1.x line. Instead of just a graphical version of the program switcher, a full "Desktop Manager", with similarities to Windows 3.x's Program Manager first appeared in this version. Furthermore, the look and feel was much more in line with the 1990 Windows 3.0 release, and not the earlier 2.x release, something that can be clearly seen in the windows decorations, and overall palette.

The system included a native graphical text editor, but just OS/2 1.0 and 1.1 before it, included virtually nothing in terms of applets. Like before, you needed add-on software to basically do anything, or at least a copy of the Windows Libraries for OS/2, which provided ports of the native Windows built-in applications to OS/2, drastically increasing the system's usability and partially solving the lack of applications problems. It should be noted, for the sake of completion, that even Windows 1.0 included add-on applications like Paintbrush and Write, which when combined with a much lower total cost of ownership, very much helped make Windows usable on a day to day basis without external applications.

OS/2 1.3 - The Bugfixed and Actually Usable Release

OS/2 1.3 was the last version we looked at on stream, and has few if any user visible changes in it. Primarily, this is more of a service pack or bug fix release, but while running on a 286, there is a rather notable improvement in performance. It's also been documented that 1.30.2 fixes many of the race conditions and other bugs that happen when running on a system faster than a 33Mhz 386, and thus is the most usable of the 16-bit versions.

Rather notably, Microsoft OS/2 1.3 was used as the basis for the first versions of Microsoft LAN Manager, which was later incorporated into Windows NT. As such, things like Windows domains actually started life ontop of OS/2 1.3, and there are significant kernel differences, because this was the only version of OS/2 that Microsoft developed without much input from IBM. For example, Microsoft OS/2 1.3 supports LADDR storage drivers, which were also possible to backport to OS/2 1.2, and were used as the basis for the Windows 95 "Dragon" block layer.[8]

Migration and Forward Compatibility

Understanding the migration mechanisms from DOS/Windows to OS/2 helps understand how users were supposed to use the system, and why it failed.

Family Mode Applications

The Word for OS/2 installer is an example of a family mode application

It appears that Microsoft intended for OS/2 console applications to be used much more extensively than history shows. This can easily be seen because Microsoft provided family mode ports of almost all its applications in this era, meaning they would work seemlessly between OS/2 and DOS. For an actual shipping example, the setup application for multiple versions of Word is a family mode application, as were the console based versions of Word itself.

In theory, a well behaved DOS console application that either does not talk to the hardware , or has some internal driver layer should be relatively easy to port to OS/2. However, console applications were very quickly de-emphasized, and the console API was never ported to 32-bit, meaning that family mode applications had a very short shelf life. As far as I know, you can't call to Presentation Manager or Windows if you're starting from the Family Mode API, meaning that this was only really useful for porting DOS applications to OS/2.

While graphical applications would prove to be the future of computing, there considerable technical and logistical difficulties in converting a console based application to a graphical one, something that was the eventual deathblow for both Lotus 1-2-3 and WordPerfect through the 90s. Had console applications been less horrible, the odds are that OS/2 would have been much more viable as a platform in the 80s, prior to the release of the 386, and OS/2 2.0 in the 90s.

Windows Libraries for OS/2

Progress Pride running under WLO

There is a dedicated article related to Windows Libraries for OS/2 on this wiki, see there for more information

As part of its promises to developers, Microsoft said that it would be quick and easy to port Windows applications to OS/2. As a proof of concept, Microsoft released a special port of core Windows libraries to OS/2, including USER, GDI, and KERNEL DLLs. These work identically to the Windows versions, and the WLO example applications are merely ports of the Windows 3.x binaries to OS/2, with a corresponding SDK.

Unfortunately, this SDK does not appear to have been archived, but copies of the example binaries have survived to the current day. It is also possible to run arbitrary Windows binaries ontop of OS/2 1.2+ by using the WLO loader and a pre-existing Windows 3.0 NE binary. As a proof of concept, FLAGGEN, a program that displays the Progress Pride flag using GDI primitives written in 2022, can be run ontop of WLO to create a de facto native OS/2 version.

Win OS/2

Win OS/2 didn't exist until OS/2 2.x, although it is possible to install Windows 3.0 in the DOS compatibility box, something mentioned in the Windows 3.0 README, and is officially supported.


Presentation Manager

Borland Sidekick for OS/2

OS/2 1.2 and 1.3

Word for Presentation Manager 1.1B

Windows Libraries for OS/2

Next Steps

A more in depth comparsion with Windows of this era is called for. At least for an initial investigation, I want to look at a 8088 based system (likely my Compaq Portable) running Windows, as this would have still been a very common system in 1988, and would have been increasingly affordable on the secondary market as good first IBM compatible machine.

In theory, anything capable of running OS/2 would run circles around my Compaq Portable or any other 8088 based system, however, I want to compare this first hand by running DOS, Windows, and even doing some multitasking on the Portable and seeing how to compared to the 'advanced' operating system that was supposed to succeed it.

Original Stream Plan/Notes

Stream Plan

This is likely going to be divided into parts to determine the full context of what's going on

Part 1

  • Install OS/2 1.1 Extended Edition
  • Try Word as OS/2 console application
  • Try out Sidekick for OS/2
  • Multitask between Word and Presentation Manager
  • Upgrade to OS/2 1.2 Extended Edition
  • Look at GUIified EE applications

Part 2

  • Install Sidekick for DOS
  • Install WordPerfect for DOS
  • Install Microsoft C for DOS and OS/2
  • Install Windows/286 2.x
  • Install Word for Windows/Excel for Windows
  • Compare Windows 2.x and PM 1.1
  • Compare Windows 3.x and PM 1.2
  • Do some Windows app development or the like (like compile example programs)

Stream Notes

E.EXE can only run as a full screen application

IBM OS/2 teachs you how to A

Tutorial program operates like IBM 3270 with function keys being defined on screen

Menu is called Action Bar?!

So Presentation Manager is improvement (in usability) over command line, but its very slow

Way to running multiple command line applications "nicer"

IBM's manuals have printing dates in date

Most of chat feels like this is an upgrade

IBM OS/2 1.2 - Has dual booting. Microsoft OS/2 1.0 has it. IBM 1.1 (and MSFT 1.1) does nto appear to ...

Tom Rune Berg noted OS/2 1.1 had tech demo feels

2 MiB of memory + 640kb was not enough

Trying with 4 MiB of memory ...

With 4 MiB of memory, pretty laggy/slowly

Entry Level systems with Model 30, 50, 60 was between 2-4k, Model 50 with MCA and non EDSI HDD was $4000

IBM OS/2 1.1 Extended Edition - Server components have some minor changes, namely color scheme; first version of LAN Requester, but needs Token Ring or PC Network Card

For the PS/2 I need:
- EEPROM Programmer
- Blank EEPROMs + Eraser
- Network Card (16-bit)

Disk copying much faster under Windows 286/2.1

Were the Microsoft OS/2 versions notably different in performance?

Emulating 10 Mhz 286, 287 and 2560 kb

What was the actual sales numbers for various OS/2 versions?

86Box Performacne seems unusually slow - confirm on real hardware

Was 286 Segmeneted Protected Mode responsible for slow UI performance of OS/2

Potentially benchmark PM?

Look at surviving DDKs

OS/2 1.2 Minimium Requirements 3 MiB/30 MiB disk space standard edition

Guess we're going to need to look at Microsoft OS/2 versions

Locked up on low disk space ...

Locked up again ...

Install on MS OS/2 1.3 done at 25Mhz for patience reasons ...