It's just not that simple. A kernel syscall just isn't an abstraction on windows, so if you want to compare the two, you need to include other OS APIs. Whether something is a syscall or not is a technical detail in the sense that it simply doesn't matter for it's actual function, but does matter for lots of non-functional concerns; possibly including api usability, performance, etc.

I don't know anything about the USB issue here, so I can't comment on that. But, typically, if you're looking for the closest equivalent to linux syscalls on windows, you're unavoidably going to be looking at non-kernelmode dll calls (which internally may or may not involve a kernel-mode syscall - that's a private implementation detail).

It's not a question choice of abstraction, simply of how the OS exposes low-level functionality (at least - it's the OS's choice, not yours).

The point being that if you reject any comparison of linux syscalls vs. window api calls then you effectively reject all comparisons between linux and windows apis. Fair enough; if you want - but it's not very helpful.

If you want to compare the capabilities of Linux and Windows systems, comparing Linux kernel APIs and Windows library APIs might make sense. However, complaining that dealing with the Linux kernel interface directly requires more work than calling Windows API functions doesn't make any sense, because of course higher-level interfaces are more pleasant to work with regardless of the target platform. If you want to make that comparison in a meaningful way, you should be comparing Linux libraries against equivalent Windows APIs.

To make it a bit more clear, libusb would be a closer comparison to the Windows/MacOS APIs OP is talking about being better.

Sure; nothing wrong with that comparison either - you're just not going to get a straightforwards apples to apples comparison. Unlike libusb, the windows api really is part of the OS; whereas libusb is a convenience library that - on windows - must use the lower level api; it's not a peer. Then again, there's no reason to care much about great convenience from a lowest-level api, so I'm not really sure what all the fuss is about: as long as the api isn't so wrong-headed to make good wrappers difficult or error prone, inconvenience seems like a fairly small price.

The same high level libraries are relatively bad when compared against the respective Objective-C and .NET/UWP high level libraries.

But then I guess it would be considered fair.

If that is indeed the case, then I would agree. But then, the "everything is a file" mantra, which the whole USB example was supposed to be about, doesn't become relevant anymore. It seems like an entirely different problem.