3 ms·
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. Whethe
by emn13 7y ago
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.
- soraminazuki 7y agoIf 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.
- jsjohnst 7y agoTo make it a bit more clear, libusb would be a closer comparison to the Windows/MacOS APIs OP is talking about being better.
- emn13 7y agoSure; 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.