3 ms·
Without getting into the specifics here, it's fair to compare linux kernal calls - sometimes - to windows api calls, because that's simply a technical detail,
by emn13 7y ago
Without getting into the specifics here, it's fair to compare linux kernal calls - sometimes - to windows api calls, because that's simply a technical detail, and in fact - that's just how those OS's expect you to communicate with the respective "OS" (whatever that even means; the linux kernel is hardly the whole OS). Calling the windows api's isn't calling some convenience wrappers, it is the api - the kernel api isn't (generally) public, and they try to avoid stability promises too, though, this being windows, I wouldn't be surprised if the kernel "internal" syscalls were nevertheless usually stable for legacy support reasons.
- soraminazuki 7y agoThe original speaker is comparing two totally different layers of abstraction. That's not a technical detail when considering if the comparison is appropriate. It's simply misleading when higher level libraries are available and widely used in Linux. On the other hand, whether the kernel interface is documented or not is a technical detail which simply doesn't matter in this context.
- pjmlp 7y agoThe 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.
- soraminazuki 7y agoIf 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.
- emn13 7y agoIt'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.