Comment by huhtenberg
13 years ago
> WaitForMultipleObjects as a kind of super-select to wait on anything
Except for the 64 handle limit, which makes it largely useless for anything that involves server applications where the number of handles grows with the number of clients. So then you'd spawn "worker" threads, each handling just 64 handles. And that's exactly where your code starts to go sour - you are forced to add fluff the sole purpose of which is to work around API limitations. What good is the super-select if I need cruft to actually use it in the app?
And don't get me started on the clusterfuck of the API that is IOCP.
> Yes, Windows gets a lot wrong, but it gets a lot right.
Oh, no, it doesn't.
Specifically, what Windows does not get is that it's other developers that are using its services and APIs, not just MSSQL team that can peek at the source code and cook up a magic combination of function arguments that does not return undocumented 0x8Fuck0ff. I have coded extensively for both Linux and Windows, including drivers and various kernel components, and while Windows may get things right at the conceptual level, using what they end up implemented as is an inferior and painful experience.
> not just MSSQL team that can peek at the source code and cook up a magic combination of function arguments that does not return undocumented
Don't leave us hanging... what examples are you referring to?
One problem that the WINE project (windows emulator for unix)has is that windows is full of undocumented APIs, some of which might be really quite useful, which are used by windows internal developers.
For WINE, if you are going to write an emulator that runs Microsoft code (like the .net framework, or notepad.exe), you need to find the correct behavior of these undocumented APIs by trial and error.
For a developer on Windows, it is perhaps frustrating that MS identifies and solves problems with it's platform, but doesn't publicly release these solutions to you.
I work for some random company that makes an SDK, although I mostly make products using it. Many of our best features are hidden - we don't ship the header files with the SDK, but the symbols are there in the binaries. Someone doesn't think they are useful enough to justify the testing expense for a full release. I guess MS have the same thing.
No. You can complain about insufficiently documented APIs, or internal APIs that you wish you could use but are not documented, but please do not complain about undocumented APIs that are used by Microsoft applications outside of Windows.
Ever since the monopoly rulings against Microsoft, they have had extremely strict internal controls preventing non-OS code from using undocumented APIs. If a DLL or EXE does not ship on the Windows client install disk, it cannot reference APIs which are not documented in MSDN. Full stop.
You're referencing an API that inadvertently didn't get documented, but everyone knows about it, has blogged about it and lots of articles mentioning to use it? Too bad. Either stop using the API or delay release by 3 months for the next MSDN update.
> undocumented APIs
"undocumented APIs" != "a magic combination of function arguments"
Any function that's not documented can be called an undocumented API, any program has them -- Linux, Windows, whatever.
But you were talking about the argument combinations being undefined, not the functions themselves. What are some examples of that?
2 replies →
>One problem that the WINE project (windows emulator for unix)
Wine Is Not an Emulator.
12 replies →
As far as I see you had a contact with Win API but you haven't understood enough, based on your complaints. Moreover, why do you mention "MySQL" as the team with the access to kernel sources?
You see wrong. And I meant MSSQL, of course. Fixed.
Can you than please give a technical reason for you to insist on waiting on more than 64 threads in a single API call, having simply too many threads for good performance anyway when IO Completion Ports could be used instead?
10 replies →
Can you name any software that doesn't have an internal API that's not meant for use by 3rd parties?