Comment by mschaef
6 years ago
Sort of. IBM really wanted to ensure that OS/2 had an imaging model that was compatible with what it used in some of its larger computers. This resulted in a bunch of differences between OS/2's imaging model and GDI. (Different window origin coordinates, etc.)
In a more Microsoft-centric world, I'm pretty sure the OS/2 API would've been exactly as you describe it and almost strictly in parallel with Windows. In fact, Microsoft did exactly this with Win32s (and Windows 95) In their relationship with Windows NT (which was once known as OS/2 NT or OS/2 3.0).
The same compiled binary could run on both the 'entry level' OS and the 'server level' OS, with a bit of care taken in the way the API was used.
Once Microsoft agreed to the graphics api change, it was open season to redesign the window manager api because backward compat was moot at that point. The OS/2 window manager api was designed by the same team who designed the win16 window manager apis. There were improvements and a bunch of api change but at the 10K foot level the model was the same - input loop, window messages, and window procs.
> at the 10K foot level the model was the same - input loop, window messages, and window procs.
That's a fairly broad description, isn't it? At least I have a hard time coming up with windowing API models that don't fundamentally work that way at the lower levels. (About the only exception think of is a text-based library that shipped with Microsoft BASIC 7.0, and that was mainly because the language didn't support any of the abstractions needed for callbacks.)
That's a fair point, I'll restate: the level of abstraction that developers were exposed to was 95% the same. Exposed message loops, window classes, window messages, unpacking window params, post and send message semantics, painting, single cooperative input queue (window app hanging would hang all apps), and other equivalences.