open, close, dup, dup2, lseek, read, write, fileno, etc.

[Bruce Adams]

On Sat, 09 Feb 2008 06:34:57 -0000, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Janice Caron wrote:
>> On 09/02/2008, Walter Bright <newshound1 at digitalmars.com> wrote:
>>> Going directly to the underlying OS functions makes for faster, more
>>> efficient I/O. Calling open, close, etc., on Windows makes for poor
>>> performance, because those functions are layered on top of the Windows
>>> I/O functions.
>>  Thanks for the answer. Though my question wasn't "Why does
>> std.stream.File use them?", it was "Why can't I use them?", which is a
>> slightly different question, and I see no reason for prohibition.
>
> You can use them - they are in the C runtime library for Windows. Just  
> put in the declarations for them. You'll be disappointed, though. They  
> are NOT part of Windows, they are C runtime functions which mostly  
> emulate the linux ones.
>
> You're better off skipping the middleman.
>
>> It is simpler easier to write platform-independent code if you can use
>> open() and close(), because then you don't have to do
>>      version(Windows) { h = wide ? CreateFileW() : CreateFileA(); }
>>     version(linux) { h = open(); }
>>  Platform independent code is also inherently easier to test, if you
>> don't happen to have a linux platform handy.
>
> To write platform independent code, why not use the D I/O facilities?  
> That is the point of them. If they are deficient, it is better to  
> enhance them than use open/close/read/write/dup.
>
> open/close/etc. are NOT platform independence. They are low level unix  
> api functions. For example, for open() on windows, you have to go  
> through one layer to CreateFileA() (and a lot of messing about trying to  
> convert unix-style modes and permissions to windows-style), and internal  
> to Windows, CreateFileA() executes a conversion to go to CreateFileW().
>
>> I wasn't complaining though - it is trivially easy to import those
>> functions with extern(C) so it's hardly a big deal. I was just
>> curious.
>
> I advise against using them because they are the wrong abstraction to  
> use. For example, they are a direct reflection of the linux filesystem,  
> not the Windows filesystem.

Unfortunately this is so. A long time ago the POSIX standard was invented
(or rather brought together from some early Unixes) and though low-level
(not OO for a start) it is solid and reliable.
The idea being if you want to write portable code you write it using only  
POSIX
functionality.
M$ in their finite wisdom chose to tear up the standard and invent their  
own
and then pretend they supported it. The result is it is practically  
impossible
to write portable code without having another wrapper layer inbetween.  
This is
where language standard libraries are a godsend. Though its hard to find  
good
portable implementations of non-blocking IO and file locking.
I suspect this may be an area where Tango is ahead of Phobos but not  
knowing
both APIs well I'm not in a position to comment.