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

Is there any good reason why these functions are available in Phobos for the Linux version of D only, but not for the Windows version?

These functions certainly do exists on Windows (albeit with names preceeded by a single underscore). In C and C++, you just have to #include <io.h>

I looked at the source code for std.streams, just to end my confusion about what File does, and it turns out it's full of lots of conditional code, with Windows using Windowsy functions like CreateFileW() and CreateFileA(). I'm sure there's probably a good reason for this - I just don't know what it is. Can anyone explain?

Thanks.

TJanice Caron wrote:
> open, close, dup, dup2, lseek, read, write, fileno, etc....
> 
> Is there any good reason why these functions are available in Phobos
> for the Linux version of D only, but not for the Windows version?
> 
> These functions certainly do exists on Windows (albeit with names
> preceeded by a single underscore). In C and C++, you just have to
> #include <io.h>
> 
> I looked at the source code for std.streams, just to end my confusion
> about what File does, and it turns out it's full of lots of
> conditional code, with Windows using Windowsy functions like
> CreateFileW() and CreateFileA(). I'm sure there's probably a good
> reason for this - I just don't know what it is. Can anyone explain?
> 
> Thanks.

I think theres some limitations to the POSIX subsystem on win32. Dunno heh.

http://support.microsoft.com/kb/149902
http://support.microsoft.com/kb/101270
http://support.microsoft.com/kb/308259

On Fri, 8 Feb 2008 12:37:17 +0000, Janice Caron wrote:

> open, close, dup, dup2, lseek, read, write, fileno, etc....
> 
> Is there any good reason why these functions are available in Phobos for the Linux version of D only, but not for the Windows version?

No. So go ahead and code them then submit them to the Phobos development
team. I might just do it myself, mwahahahaha!

> These functions certainly do exists on Windows (albeit with names preceeded by a single underscore). In C and C++, you just have to #include <io.h>

I'm pretty sure the C versions end up calling the "Windowsy" functions anyway.


-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Janice Caron wrote:
> open, close, dup, dup2, lseek, read, write, fileno, etc....
> 
> Is there any good reason why these functions are available in Phobos
> for the Linux version of D only, but not for the Windows version?
> 
> These functions certainly do exists on Windows (albeit with names
> preceeded by a single underscore). In C and C++, you just have to
> #include <io.h>
> 
> I looked at the source code for std.streams, just to end my confusion
> about what File does, and it turns out it's full of lots of
> conditional code, with Windows using Windowsy functions like
> CreateFileW() and CreateFileA(). I'm sure there's probably a good
> reason for this - I just don't know what it is. Can anyone explain?

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.

On 09/02/2008, Walter Bright <newshound1@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.

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.

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.

Janice Caron wrote:
> On 09/02/2008, Walter Bright <newshound1@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.

Walter Bright wrote:
> Janice Caron wrote:
>> On 09/02/2008, Walter Bright <newshound1@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.

I am not certainly sure, but I do think open, close & co are POSIX functions, not Linux functions per se. They're available on almost all modern Unices. So actually, they are what one would call cross platform. They're just a step-child on Windows, coming with the POSIX subsystem.

Just my two nitpicking cents. :)

Alexander Panek, el  9 de febrero a las 12:20 me escribiste:
> Walter Bright wrote:
> >Janice Caron wrote:
> >>On 09/02/2008, Walter Bright <newshound1@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.
> 
> I am not certainly sure, but I do think open, close & co are POSIX functions, not Linux functions per se. They're available on almost all modern Unices. So actually, they are what one would call cross platform. They're just a step-child on Windows, coming with the POSIX subsystem.

Yes, and this reminds me why there is no "posix" version (like in Tango AFAIK). It seems to me a little lame to have a "linux" version where mostly all the imports have *posix* functions and can be used in any *posix* sysm (which is even more wide than Unices, as said here Windows has a -poor- posix API, and QNX 6 -clearly not a Unix- is posix too).

Posix is a great way to do portable code. I think it would be great if D had better (and D-ish) Posix "bindings".

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
La máquina de la moneda, mirá como te queda!
	-- Sidharta Kiwi

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

> Janice Caron wrote:
>> On 09/02/2008, Walter Bright <newshound1@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.

On 2/9/08, Bruce Adams <tortoise_74@yeah.who.co.uk> wrote:

> 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.

ANSI C (including the standard library) wasn't standardised until 1990. The first versions of MS-DOS appeared in 1982. POSIX didn't appear until 1988. Which standard are you referring to, or is this just more of the same uninformed Microsoft bashing?


David.


> 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.
>