What's with people using Win32 API as a negative example all the time? It was verbose, but quite good even compared to the stuff you have to deal with in 2015. Sure it wasn't hot-sexy-object-oriented and you often had to pass 20 unused params, but at least it was somewhat consistent and documented, not to mention powerful.
The problem of doing this is you end-up with something like the Win32 API, with decade of undocumented methods people called that you must support 10 years after because some critical applications are crashing.
Contrasting the subtle incompatibilities and custom APIs in Mac with the unparalleled legacy support in Windows.. I'm not sure the lesson is what you are suggesting.
As I said, YMMV but the biggest standout that I remember was trying to play sounds using the windows API. There weren't any packages our team could find that really did it correctly, the one that everyone pointed to leaked memory like crazy and it was hard for us to track down since it relied on bouncing back and forth between C and Go so frequently (making malloc/free lifetimes difficult to follow because C can't know what things have been GC'd by the Go runtime)
Correct - the semantics are simply too different to directly emulate. The simple fact that starting processes takes much longer in Windows cripples naive implementations, for example.
Yeah though... pretty much any natively compiled language and many interpreted/VM-based languages can use the C ABI in any modern plaform anyway, so what COM provides isn't so much the ability to use the same API from many languages but a dynamic object oriented approach for doing so.
After all it isn't like you can't use the Win32 API directly from Rust - or any other language, e.g. Python.
Note that nowadays there aren't many of such compat hacks in the actual Windows codebase. Most applications can be coaxed to work by just shimming a few API calls and those shims can be kept separately and don't impact other software that doesn't need them. The simplest one of those would be the one that simply pretends to be an older Windows version for broken version checks to still work. There are others where HeapAlloc simply allocates a little more to prevent a buffer overflow, etc.
The OS architecture no longer suffers from such things.
Can you give an example(or a link to an article discussing this)? I've never had the displeasure of working with the Windows API(though I often shook my head when I saw code for it)
The Microsoft-specific variant of it is something I've seen up close. One of the issues always struck me as confusing interface and implementation. There isn't a good recognition of the fact that when you write against an API, you code against an abstraction, not a particular implementation. If your interface is good enough, you can do the rewrite treadmill thing to justify your current bonus or whatever, but you can point the old interface at a new implementation without most callers knowing the difference.
So, I think a good example of this working relatively well would be Windows audio. The WinMM API still works. They rewrote the audio stack a couple of times, and introduced new APIs such as WASAPI and I forget the newer one. Winmm isn't broken. It may not have access to all the latest features, but it works.
In contrast, all too often they discard an entire API because they want to rewrite the components underneath. But the I in API stands for interface. A good interface can survive rewrites of what's underneath.
To paraphrase: Windows NUL is a poor example, IMO. Yes, it needs to be carefully handled for reasons. But it also offers great flexibility that is actually widely used, and that wouldn't be available through other mechanisms.
I'm not doubting that the windows API has remained stable. I'd like to try if the tooling (e.g. IDE config format or makefile equivalent) has also received the same amount of attention to backward compat
reply