Comment by quotemstr
13 years ago
Actually, I think one NT's largest advantages over POSIX systems is process management: yes, the venerable CreateProcess API.
See, in Windows, processes are first class kernel objects. You have handles (read: file descriptors) that refer to them. Processes have POSIX-style PIDs too, but you don't use a PID to manipulate a process the way you would with kill(2): you use a PID to open a handle to a process, then you manipulate the process using the handle.
This approach, at a stroke, solves all the wait, wait3, wait4, SIGCHLD, etc. problems that plague Unixish systems to this day. (Oh, and while you have a handle to a process open, its process ID won't be re-used.)
It's as if we live in a better, alternate universe where fork(2) returns a file descriptor.
You can wait on process handles (the handle becomes signaled and the wait completes when the process exits). You can perform this waiting using the same functions you use to wait on anything else, and you can use WaitForMultipleObjects as a kind of super-select to wait on anything.
If you want to wait on a socket, a process, and a global mutex and wake up when any of these things becomes available, you can do that. The Unix APIs for doing the same thing are a mess. Don't even get me started on SysV IPC.
Another thing I really like about NT is job objects (http://msdn.microsoft.com/en-us/library/windows/desktop/ms68...). They're a bit like cgroups, but a bit simpler (IMHO) to set up and use.
You can apply memory use, scheduling, UI, and other restrictions to processes in job objects. Most conveniently of all, you can arrange for the OS to kill everything in a job object if the last handle to that job dies --- the closest Linux has is PR_SET_PDEATHSIG, which needs to be set up individually for each child and which doesn't work for setuid children.
(Oh, and you can arrange for job objects to send notifications to IO completion ports.)
Yes, Windows gets a lot wrong, but it gets a lot right.
> 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.
17 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.
11 replies →
Can you name any software that doesn't have an internal API that's not meant for use by 3rd parties?
My personal annoyance is the introduction of win32k in NT4. With per-session CSRSS existing since WinFrame and Vista+ having Session 0 Isolation, not to mention much faster processors, and the removal of XPDM and the requirement of the DWM in Win8, it doesn't make as much sense anymore.
Update: And I forgot to mention the font parsing security issues (look up Duqu), and the issues with user mode callbacks too.
> the issues with user mode callbacks too.
Genuine question (because I really don't know) -- how do Linux GUI frameworks work without kernel-mode callbacks? What do they use instead, when they need to send messages to other windows?
X11 clients communicate with the server using Unix domain sockets or TCP sockets. Requests, responses and event notifications are exchanged as messages.
Asynchronous communication is achieved using syscalls like select and poll which take a set of file descriptors (files, special files, sockets) and block the calling thread until some descriptor from this set has new data available for reading, starts accepting writes or signals an error.
GUI toolkits repeatedly poll the X server descriptor, parse incoming messages and call application-defined callbacks.
7 replies →
Nobody likes win32k, but it's there and it works.
Okay, you're in charge. Are you sure you can't find a better way to deploy shareholder capital than using it to remove win32k?
"Okay, you're in charge. Are you sure you can't find a better way to deploy shareholder capital than using it to remove win32k?"
Could that be why developing an OS inside of a shareholder-owned corporation is inherently hobbled compared with developing it as an open source project?
3 replies →
Note that the problem you describe for process is not a fundamental design choice. For instance, FreeBSD has added such API.
http://www.freebsd.org/cgi/man.cgi?query=pdfork
I wonder if this is going to make it to OSX at some point, given the commonality between OSX and FreeBSD?
OS X has provided such APIs for a while - you can create processes using posix_spawn rather than fork, and monitor them with kqueues.
That said, if you're writing an app you might be able to go higher level and use XPC services, which can be much less pain.
IO Completion Ports are a pretty nice feature too, in an of themselves.
Great explanation