So am I the only one who actually kinda likes the classic Windows API? I never used it when it was current (I had an Amiga back then), but out of curiosity I bought an ancient copy of Programming Windows at the used bookstore a year or so ago.
Honestly, I can see why Windows did okay with programmers. People act like the Win16 API was awful, but they’re comparing it to what we have today. I wrote a lot of code for the Amiga, and I was passingly familiar with Mac Toolbox programming…the Win16 API was considerably better than its contemporaries.
EDIT: Obviously there were systems other than Windows, Mac, and the Amiga, but on consumer-grade hardware that was pretty much it. There was OS/2 (which apparently had a very similar API but a lot of problems both technical and political that hindered its adoption), the various Unix windowing systems and NeXT (which ran on hardware out of reach of the average consumer), and also-rans like GEOS and such that never had the critical mass needed to catch on.
It’s not just you. The original core Windows APIs were very pleasant compared to competitors I used (Mac and OS/2), and the additions in early versions of Windows NT (COM, the object manager, etc.) felt clean and powerful. I remember at the time being frustrated trying to go from Windows to Mac (as a teenager) because the Mac Toolbox was a ridiculous PITA compared to Windows, even if I happened to think that the actual user-experience of the Mac was nicer at the time. (And don’t even get me started on things like Winsock v. OpenTransport, or COM v. OpenDoc. Good lord.)
And the thing is, it’s not even as if everything went downhill after that as such. Yeah, there were some awful APIs (e.g., early versions of DirectX), but there were also some great improvements and additions (e.g., WDDM, later versions of DirectX, .NET). I think the reason Windows has a bad rap is just that it never throws out legacy, and that MS has a general habit of making something new, instead of improving something already there. The combo doesn’t necessarily mean that any given API is worse than its Unix counterparts, but rather than the entire combo of all of the Windows APIs, and their sometimes byzantine ways of interacting with one another, is just too damn much. So suddenly you have Foo, FooEx, and FooEx2, and you need to know what defaults suddenly happen implicitly when you use FooEx instead of FooEx2, and those aren’t even always consistent across Windows versions because $REASON_THAT_RAYMOND_CHEN_THINKS_IS_INTUITIVE, and it manifests later as a segfault because you have a hole in your structure that only matters on Windows ZT Service Pack π Edition 2. Or I want to do some automation, but some of the stuff is only in PowerShell, and some is only in WMI, and some are objects provided for WSH, so you end up doing just bizarre multi-language apps to get simple things done.
For all the vitriol that Windows 10 has gotten, I actually think things have been massively going in the right direction over the last couple of releases, but even with the clean and promising “WinRT + .NET Core everywhere” attitude they’re espousing, it’ll be a long road.
Regarding the Mac, Microsoft sold a Mac targeting version of Visual C++ 4 that used MFC and adapted Windows API - it was used to port a lot of their application back then, including Word 6.
I like it although I kind of think that is because I learned the Win32 API first when I was also learning C. I know people complain about all the parameters you have pass to various functions but at least they were well documented. Even the Hungarian notation wasn’t too terrible after a while (at some point it just becomes second nature). Even today I prefer Win16/32 API over GTK+/Qt. I wish there was a GUI Toolkit API modeled after Win32
The best thing about WinAPI is indeed the documentation to popular functions. But there are also some obscure areas inside Windows for which the documentation is very poor (like ITraceRelogger).
But I need to write this, it’s hard for me to imagine how you can prefer using CreateFile() function with all its arguments each time you want to open a file, instead of using a simple QFile object (with RAII support).
OK, you can create a simple function wrapper in your application and use this simple wrapper. But if you create lots of small tools without shared code, on different computers in different time, having to write the same wrapper functions over and over again gets old pretty quick.
My dad has this old book by Charles Petzold (the guy who wrote Code) whose first chapter is basically what’s covered here. The edition I was using was from the early 90s and I pored over that book as a teenager. The main thing that strikes me is that this information is still relevant. I’d bet if you remove all of the 16 bit weirdness (FAR, PASCAL, etc) this could compile for 64-bit.
Wow, I remember reading a lot of Charles Petzold in the late 80s and early 90s - his columns in PC Magazine on OS/2 and Windows programming as well as his various books. He, Ray Duncan, Jeff Duntemann, Michael Abrash and a few others were a huge influence on me in the days before I got into Unix.
You mostly can. You’ll need to use message crackers if you want to write an app that can “trivially” jump from Win16 to Win32, though. (If you’re willing to just adapt by hand, it’s easier, but then why start with Win16?)