Comment by jussij
6 years ago
The design of Win32 is incredibly close to the design of Win16 and since Win16 dates back to early 90's you need to comparing it to GUI programming layers of that same era.
So the question is, back then was there any better GUI programming layers?
And the answer is yes, there was actually an API that was better and it was called OS/2.
At that time Microsoft was in a partnership with IBM to develop OS/2.
However, when the partnership fell apart, Microsoft just took big chunks of that OS/2 API and created a sub par version and called it the Windows API.
> However, when the partnership fell apart, Microsoft just took big chunks of that OS/2 API and created a sub par version and called it the Windows API.
Microsoft learned from the mistakes IBM forced on them and did a better job. Right off the top of my head:
* IBM forced 80286 compatibility in an 80386 world.
* IBM forced incompatibility between Windows and OS/2 for the sake of preserving their mainframe graphics API's.
* OS/2 had a single messaging queue for the whole desktop.
* OS/2 was tied to the underlying hardware to the extent of being written partly in assembler.
OS/2 was great... I loved OS/2 2.0 in particular (and I worked for IBM testing OS/2 LAN Server for a summer)... but IBM had no idea how to address the market and no sense of how fast it was evolving.
I'm pretty sure it is the other way around, the OS/2 GUI (Presentation Manager) API is a cleaned up version of the Windows 2.x API.
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.
2 replies →
The Win is just one layer in the OS/2 API and suspect you might be right in that this layer was probably modeled on early Windows.
However OS/2 had many other layers to it's programming SDK that were not found in early Windows.
For example there was the Dos layer for things like processes, threads, semaphores, files, directories etc.
And then there was the Gdi layer for graphics.
Most of that functionality only made it's way into Windows with the advent of Windows NT (Windows 3.x/95 had poorer versions of those functions. For example running a process and capturing it's output was a real pain in Windows 3.x and Windows 95).
And based on the fact so many of those OS/2 Dos function have an equivalent Windows NT version I suspect Microsoft used that OS/2 design as their starting point for NT.
As just one of many examples consider DosCreateThread from OS/2 1.x
http://www.edm2.com/index.php/DosCreateThread_(OS/2_1.x)
It looks a lot like the CreateThread function found in Win32:
https://docs.microsoft.com/en-us/windows/win32/api/processth...
Right, this is why i explicitly said "the OS/2 GUI (Presentation Manager) API" and not the entirety of OS/2. The original comment mentioned "was there any better GUI programming layers" after all.