File descriptor abstraction in Windows…

by admin on May 24, 2006 06:11pm

Submitted by: Alexandre Ferrieux

Question:

Hello,

I'd like to describe what is my highest frustration at the unix-Windows boundary: the lack of 'file descriptor abstraction' in Windows.

Consider:

In unix everything is a file descriptor, on which you simply use
read(), write(), and select() regardless of the underlying reality (files,pipes,sockets,devices,pseudoterminals).

In windows you have a set of API for every new type, with a few bridges here and there with limited support (not even talking of Windows CE).

Here is my point: this may look like just aesthetic considerations (the sheer beauty of having fewer syscalls is irrelevant to the end user). But there is one catch: when it comes to *mixing* all these things together, complexity explodes in the Windows case, and in my case there are true show-stoppers.

More precisely: let's try single-threaded, event-driven programming with select()/poll()/WaitForMultipleObjects(). In unix it amounts to giving a list of file descriptors. In Windows it is superficially the same (with handles), but it is *not*, because many handle types are just not waitable. To circumvent that, of course there is overlapped IO. But it is only possible when you open the handle yourself (to allow overlapped mode), not for one you inherit from the parent (like stdin).

Then the only possible workaround is to spawn extra threads doing their blocking IO or type-specific wait. But when it comes to resource-challenged environments (like WinCE), spawning an extra thread is sometimes not an option.

Questions:

(1) Are MS aware of such limitations in WinCE and even XP ?

(2) Any smart workaround to save me right now ?

TIA,

-Alex

Answer (Jeffrey Snover, Architect: Administration Experience Platform):

I concur!

PowerShell provides a similar abstraction on top of the OS and are working with feature teams to get providers. We call these namespace providers. It is slightly different than the UNIX model but we think it is more powerful. Our design center was admin scripting so we need to provide these abstractions against the Registry, WMI, AD, SQL, CERT STORES, etc.

If you download PowerShell and explore the concept of DRIVES (Get-PSDRIVE) then the concept will become a little clearer.

I'll monitor the comments here if you have any additional questions/feedback.

Jeffrey Snover