Some of the coding conventions changed a bit between Windows 3.0 and 3.1. In 3.0 many of the headers and docs were K&R, but the compiler improved and Visual C++ can use ANSI instead. In 3.0 “PASCAL” was used to indicate the standard calling convention, but that was replaced by “WINAPI”. So things using Visual C++ can look a lot cleaner.
For me the complexity of Win16 was because it’s a huge step from DOS. In DOS, you own the machine. In Win16, it’s cooperatively multitasked, so you absolutely must periodically give back control to the system. That in turn means there’s a lot more cases where you call the system, and the system calls you, and then you need to be aware of all of the strange quirks like function calling conventions or making sure you’re called with the right data segment. These are things DOS developers could almost completely ignore.
It also felt to me like Win16 was abandoned before the tools to work with it were any good. This applies to deep things, like when your program crashes it’s easy to crash the system, but still not have any diagnostic thing like a crash dump to figure out how you did it. It applies to minor things too, like in the article the author says that Visual C++ reimplemented the edit control - yes, because Win16 doesn’t have a rich edit control, and the multiline edit control is monochrome and can’t do syntax highlighting. So it reimplemented it, fairly minimally.
In terms of debugging, Visual C++ was a huge step forward (it should have been called Debuggable C++.) Because Win16 is cooperative, you can’t just put breakpoints and halt execution, because doing so would halt the system. So Visual C++ has a crazy complex system to allow you to pretend you halted execution at some place, without actually halting execution. I don’t know the details of how this works, because if it starts pumping messages that will obviously interfere with what you’re trying to debug. Trying to convince the system that the app is working normally and the human debugger that it’s fully stopped simultaneously seems to be quite an achievement.
I’ve heard that of its contemporaries, (such as X11, the Macintosh Toolbox, OS/2 Presentation Manager, etc.) the Windows API was easiest to program for.
Back in those days I only wrote code for the Amiga. Intuition (the Amiga windowing API) is…painful…to use, but I didn’t know any better. I read a bit on Mac programming and it seemed only marginally better.
Later I wrote plenty of code for X, both raw Xlib and via Xt (Athena and Motif).
Years (decades!) later, I picked up a copy of Programming Windows 3.1 at the used bookstore for a dollar. I can say, without question, the Windows API was leaps and bounds better than any of its major competitors.
It seems antiquated today, of course, but that’s looking at it with modern eyes. At the time it really was better.
(Later versions of AmigaOS included BOOPSI, an object-oriented programming system that eased the pain somewhat. MUI (Magic User Interface) was a third-party BOOPSI-based framework that was really excellent and made application programming on the Amiga a joy.)
Years (decades!) later, I picked up a copy of Programming Windows 3.1 at the used bookstore for a dollar. I can say, without question, the Windows API was leaps and bounds better than any of its major competitors.
When I was a teen, my parents had Windows computers (initially 3.1, later 95) that I taught myself how to code for. But I pined for a Mac. I knew that everything would be better on a Mac: the user experience was better, the feel was better, everything was more consistent, the software clearly got more attention, so I knew that I really wanted to be a Mac developer. And then, finally, I saved up enough to buy a Mac and what the actual fuck is going on here? you want me to shove what in a global pointer because why now?!
I think that was honestly an incredibly valuable lesson for me. Yeah, I honestly did enjoy using the Mac a lot more, in the same way that I’d later enjoy using a Treo a lot more than a WinCE phone. But coding for Mac classic was an incredible pain. And that taught me that technical quality of the underlying software,, and the quality of the user experience, don’t necessarily align.
In my contemporary career, I keep that lessson in mind, bidirectionally: doing everything right, technically, doesn’t magically mean we’ve got the best product for users. Having a suboptimal product, technically, doesn’t mean we can’t still be best-in-class for our customers. It’s helped me be much more balanced about when tech debt is and isn’t worth paying off, and to be much more nuanced on what actually goes into making a good product.
(Edit and post script: on a lark in 2008, I did a rough port of Fog Creek Copilot to OS/2, and I left that experience being very thankful that Windows NT won that particular war.)
As someone who spent a lot of time using Win3.1/Win98, seeing deep dives into these stacks and usage is really interesting.
One “desert island “ project I’ve had for a while is to pull out some user interface guidelines from those times and try to build apps out of those for things like instant messaging or task management.
I get a lot of these apps existed in the past but I feel like going back to these older design styles with today’s knowledge could lead to interesting places
I feel there’s been a decline in things like HIGs; like HCI is focused on branding over consistent user experiences. There’s been some revisiting (hamburger menus are copied from Xerox’s UIs, skipping the Macintosh) but I think immersing into the context of both their creation and environment would be good for modern applications to learn from.
For those who don’t know, WineVDM allows you to run Win16 apps on 64 bit Windows. It’s still early, but if you want to mess with Win16 it’s one way to do it.
Some of the coding conventions changed a bit between Windows 3.0 and 3.1. In 3.0 many of the headers and docs were K&R, but the compiler improved and Visual C++ can use ANSI instead. In 3.0 “PASCAL” was used to indicate the standard calling convention, but that was replaced by “WINAPI”. So things using Visual C++ can look a lot cleaner.
For me the complexity of Win16 was because it’s a huge step from DOS. In DOS, you own the machine. In Win16, it’s cooperatively multitasked, so you absolutely must periodically give back control to the system. That in turn means there’s a lot more cases where you call the system, and the system calls you, and then you need to be aware of all of the strange quirks like function calling conventions or making sure you’re called with the right data segment. These are things DOS developers could almost completely ignore.
It also felt to me like Win16 was abandoned before the tools to work with it were any good. This applies to deep things, like when your program crashes it’s easy to crash the system, but still not have any diagnostic thing like a crash dump to figure out how you did it. It applies to minor things too, like in the article the author says that Visual C++ reimplemented the edit control - yes, because Win16 doesn’t have a rich edit control, and the multiline edit control is monochrome and can’t do syntax highlighting. So it reimplemented it, fairly minimally.
In terms of debugging, Visual C++ was a huge step forward (it should have been called Debuggable C++.) Because Win16 is cooperative, you can’t just put breakpoints and halt execution, because doing so would halt the system. So Visual C++ has a crazy complex system to allow you to pretend you halted execution at some place, without actually halting execution. I don’t know the details of how this works, because if it starts pumping messages that will obviously interfere with what you’re trying to debug. Trying to convince the system that the app is working normally and the human debugger that it’s fully stopped simultaneously seems to be quite an achievement.
Back in those days I only wrote code for the Amiga. Intuition (the Amiga windowing API) is…painful…to use, but I didn’t know any better. I read a bit on Mac programming and it seemed only marginally better.
Later I wrote plenty of code for X, both raw Xlib and via Xt (Athena and Motif).
Years (decades!) later, I picked up a copy of Programming Windows 3.1 at the used bookstore for a dollar. I can say, without question, the Windows API was leaps and bounds better than any of its major competitors.
It seems antiquated today, of course, but that’s looking at it with modern eyes. At the time it really was better.
(Later versions of AmigaOS included BOOPSI, an object-oriented programming system that eased the pain somewhat. MUI (Magic User Interface) was a third-party BOOPSI-based framework that was really excellent and made application programming on the Amiga a joy.)
When I was a teen, my parents had Windows computers (initially 3.1, later 95) that I taught myself how to code for. But I pined for a Mac. I knew that everything would be better on a Mac: the user experience was better, the feel was better, everything was more consistent, the software clearly got more attention, so I knew that I really wanted to be a Mac developer. And then, finally, I saved up enough to buy a Mac and what the actual fuck is going on here? you want me to shove what in a global pointer because why now?!
I think that was honestly an incredibly valuable lesson for me. Yeah, I honestly did enjoy using the Mac a lot more, in the same way that I’d later enjoy using a Treo a lot more than a WinCE phone. But coding for Mac classic was an incredible pain. And that taught me that technical quality of the underlying software,, and the quality of the user experience, don’t necessarily align.
In my contemporary career, I keep that lessson in mind, bidirectionally: doing everything right, technically, doesn’t magically mean we’ve got the best product for users. Having a suboptimal product, technically, doesn’t mean we can’t still be best-in-class for our customers. It’s helped me be much more balanced about when tech debt is and isn’t worth paying off, and to be much more nuanced on what actually goes into making a good product.
(Edit and post script: on a lark in 2008, I did a rough port of Fog Creek Copilot to OS/2, and I left that experience being very thankful that Windows NT won that particular war.)
When I learned BOOPSI I thought it reminded me a lot of Objective-C. Now MUI can bind to Objective-C :)
As someone who spent a lot of time using Win3.1/Win98, seeing deep dives into these stacks and usage is really interesting.
One “desert island “ project I’ve had for a while is to pull out some user interface guidelines from those times and try to build apps out of those for things like instant messaging or task management.
I get a lot of these apps existed in the past but I feel like going back to these older design styles with today’s knowledge could lead to interesting places
I feel there’s been a decline in things like HIGs; like HCI is focused on branding over consistent user experiences. There’s been some revisiting (hamburger menus are copied from Xerox’s UIs, skipping the Macintosh) but I think immersing into the context of both their creation and environment would be good for modern applications to learn from.
For those who don’t know, WineVDM allows you to run Win16 apps on 64 bit Windows. It’s still early, but if you want to mess with Win16 it’s one way to do it.
This was an interesting read, I had to throw some styles on the
articletag to make it actually readable though :D