Hacker News Reader

Comment by leeter | Hacker News Reader

This forgets MS:

MS: "Let's design it so either it never breaks or if we can't avoid that we'll just add a FooEx or Foo2 method call"

This is why so many Win32 methods take structs that have a size parameter that must be filled in. That acts as a version parameter. That's not to say they haven't had ABI fun moments... glares at COM.

View on HN

While Microsoft's backwards-compatibility guarantees have historically been a strong competitive advantage for them… every time I get a glance into Windows APIs I'm blown away by how much historical garbage they seem to be stuck with.

I get this feeling every time I read a post on The Old New Thing (Raymond Chen). He'll patiently explain why some weird wart is the way it is, or how misusing some API is bad, and it's always extremely interesting. But at the same time I'm sitting there just thanking my lucky stars I've managed to avoid ever having to write software for that environment, because it's always absolutely bonkers.

Honestly? Having written software for both Win32 is actually pretty nice to work in. Better in many ways than the alternatives. Most of the things Raymond goes on about are weird quirks you can ignore for the most part. Whereas there are some very serious hazards running around POSIX if you're not careful that can bite hard. Glares at signals

I much prefer the EVENT based system Win32 goes with. You can just suspend on the event and not worry about it. The kernel will wake you up when it matters. Also MS seems to have very serious API design rules that help keep usage patterns consistent, which is important in making sure things aren't accidentally misused.

While I much prefer Linux as a platform, it’s fair to say Linux has more than it’s fair share of historical baggage as well. The entire design of the console for starter: TTYs, ANSI escape sequences used for encoding data in band, typeless byte streams, job control being a weird cross responsibility between the kernel, shell and application, etc.

…And that’s without addressing any other parts of the system beyond the console.

I’d still take Linux over Windows every day if the week though.

It’s so much nicer than Linux.

Whatever version of windows you make your software work on it just works on all future versions.

If you don’t like the old APIs don’t use them.

Being able to put software on a website and have people download and use it immediately is kind of amazing compared to Linux.

COM is very annoying tho. I’ll give you that.

There's nothing special about Windows in this regard. You can do this on Linux, too. Ship a package for whatever operating systems you need to support. If you have dependencies and you want to bundle them, bundle them.

Example: https://gankra.github.io/blah/c-isnt-a-language/#case-study-...

NGL... that inspired my comment XD

> This is why so many Win32 methods take structs that have a size parameter that must be filled in. That acts as a version parameter

That said, I couldn't name you a Win32 that actually has more than one valid value for said cbSize member. Are there any?

Sure, you can find a fair number with a grep of the Wine source. Try "git grep if.*cbSize", there's a few obvious ones and some less obvious, too.

One example: https://source.winehq.org/git/wine.git/blob/62df608d3ed84aac...

It's hard to notice sometimes because the a struct FOO is often a typedef to whatever the latest version is in the SDK you're using (FOO1, FOO2, etc).

This happens a lot in the Media SDKs, dsound, ddraw, dplay etc. Not that they're really used nowadays.

um/winuser.h has some, although they haven't changed in awhile. WNDCLASSEX gained hIconSm after Windows 3.x. MENUITEMINFO gained hbmpItem in Windows 2000. NONCLIENTMETRICS gained iPaddedBorderWidth in Windows Vista.

https://devblogs.microsoft.com/oldnewthing/20031212-00/?p=41...

um/webauthn.h has a bunch of structures that explicitly document fields added in various dwVersion s. However, no individual structure has changed since being published in the Windows SDK last I checked. e.g.:

    //
    // The following fields have been added in WEBAUTHN_AUTHENTICATOR_MAKE_CREDENTIAL_OPTIONS_VERSION_2
    //

    // Cancellation Id - Optional - See WebAuthNGetCancellationId
    GUID *pCancellationId;

um/wincrypt.h also has a few structures chopped up with #ifdef ..._HAS_EXTRA_FIELDS s that are presumably differentaited between via cbSize.

um/ShlObj_core.h has COMPONENT, which extends and is differentiated from IE4COMPONENT - presumably by dwSize.

It also wouldn't suprise me if cbSize is also used to differentiate between 32-bit and 64-bit versions of the same structure as well, with WoW64 blindly forwarding said structures.

Thanks to you, and everybody else, for the examples.

I find it interesting upgrading the SDK could make your code invalid, due to uninitialized struct members. Compiler warnings can catch that sort of thing, thankfully—at least these days.

There's a reason examples tend to use ZeroMemory or other mechanism for zero-initializing the entire struct ;)

There are other subtle edge cases as well - like needing to make sure all code (including third party libs) is built with the same defines and settings if they might share said structs without painstaking checking cbSize & never passing by value. (Even that might not be enough when statically linking, as it's an ODR violation - and thus undefined behavior - to mix and match different definitions of the same struct...)

A good example of a really important one is CreateProcess for lpStartupInfo. The value is either a STARTINFO or STARTUPINFOEX and the first member of both structs is cb which is set to the size of the struct that is being used. This allows the code to understand what struct is actually used in the call.

One flaw with that is that the struct size won't change if you do something like reordering the members (not that anyone would ever do that).

Which they explicitly prohibit, in fact if you look at how they design the APIs they'll deliberately add reserved members to ensure they hold the space so that it's much harder to break.

Yes, it takes some discipline to keep that working. You need to internalize which changes cause ABI breaks, look for them in code reviews, evangelize that culture to new hires that aren't familiar with the rules (which becomes harder over time as people coming up now tend to spend less time learning C), etc.

Also "make everyone carry their dependencies down to the standard C library". The churn that the userland on Linux distros has is very unfortunate, but it's probably not going to change any time soon. It's not that hard to ship software with minimal dependencies if you know what you're doing, but it sure is easier for Windows.

AmigaOS2.0 had an interesting API: tag arrays: a variable length key/value pair of parameters

Reply on news.ycombinator.com