While working with the dmd codebase (https://github.com/dlang/dmd/pull/12560) I noticed that it systematically shuns C runtime calls to functions such as unlink, rename etc. Instead the code uses native Windows API calls (DeleteFile, MoveFile).

Spoke to Walter about it, he said the reason is mostly historical and for the most part forgotten and probably obsolete - at least in the past, Windows implementations of CRT was poorly done, had subtle differences, and bugs.

Is that still the case? If not, we could reduce the complexity of source code considerably by unifying version(Posix) and version(Windows) code.

I haven't confirmed but I think the CRT functions work in ANSI instead of Unicode (unless you use the w prefixed ones... and at that point you're branching anyway so you haven't gained anything).

Probably should try it with a utf-8 name and confirm it works or doesn't.

On Saturday, 22 May 2021 at 16:25:08 UTC, Andrei Alexandrescu wrote:
> While working with the dmd codebase (https://github.com/dlang/dmd/pull/12560) I noticed that it systematically shuns C runtime calls to functions such as unlink, rename etc. Instead the code uses native Windows API calls (DeleteFile, MoveFile).
>
> Spoke to Walter about it, he said the reason is mostly historical and for the most part forgotten and probably obsolete - at least in the past, Windows implementations of CRT was poorly done, had subtle differences, and bugs.
>
> Is that still the case? If not, we could reduce the complexity of source code considerably by unifying version(Posix) and version(Windows) code.

Instead of trying to unify the code, OS dependent implementations should be moved to separate files. Also, should D rely on the C library? I would say the D should go the other way and rely on the C library a little as possible.

Another thing I have noticed that languages that use the C-library just creates a native copy of the interface (which just add another layer), instead of defining an own cross platform API

On Saturday, 22 May 2021 at 19:08:14 UTC, IGotD- wrote:
> Another thing I have noticed that languages that use the C-library just creates a native copy of the interface (which just add another layer), instead of defining an own cross platform API

It allows them to claim that they are based on Posix which is a standard, which looks good on paper... But for a systems development language it is a bit underwhelming as modern file systems have many more features...

On Saturday, 22 May 2021 at 20:05:46 UTC, Ola Fosheim Grostad wrote:
>
> It allows them to claim that they are based on Posix which is a standard, which looks good on paper... But for a systems development language it is a bit underwhelming as modern file systems have many more features...

C library API is an ISO C standard, POSIX is another standard which Windows doesn't natively support.

By today's standard the C library API is ancient and doesn't provide an asynchronous API for example. Win32 and POSIX (late to the game) have both an asynchronous APIs.

On Saturday, 22 May 2021 at 20:18:58 UTC, IGotD- wrote:
> By today's standard the C library API is ancient and doesn't provide an asynchronous API for example. Win32 and POSIX (late to the game) have both an asynchronous APIs.

The Windows overlapped io api is actually very nice too. In fact, I overall prefer the Windows functions to most the posix and c ones.

On Saturday, 22 May 2021 at 20:18:58 UTC, IGotD- wrote:
> C library API is an ISO C standard, POSIX is another standard which Windows doesn't natively support.

Alright, my mistake then. I thought they had a POSIX layer.. My windows machine has Windows XP :-D.

> By today's standard the C library API is ancient and doesn't provide an asynchronous API for example. Win32 and POSIX (late to the game) have both an asynchronous APIs.

It would be cool to have something directly built on Linux syscalls... Not sure if it is more useful, but sound cool :-D

On 5/22/21 12:25 PM, Andrei Alexandrescu wrote:
> While working with the dmd codebase (https://github.com/dlang/dmd/pull/12560) I noticed that it systematically shuns C runtime calls to functions such as unlink, rename etc. Instead the code uses native Windows API calls (DeleteFile, MoveFile).
> 
> Spoke to Walter about it, he said the reason is mostly historical and for the most part forgotten and probably obsolete - at least in the past, Windows implementations of CRT was poorly done, had subtle differences, and bugs.
> 
> Is that still the case? If not, we could reduce the complexity of source code considerably by unifying version(Posix) and version(Windows) code.
> 

It so happens that the CRT functions for something like unlink and rename *are* the system calls on Unix. On windows, they are wrappers. I know in at least some cases Windows implements minimal features for their C interface, while providing full featured support with their SDK calls. I think druntime/phobos should focus on the minimal required libraries to work on the OS. Especially for things that require i/o handles, the C library abstraction is poor on Windows.

But this is my opinion for our standard library. For DMD though? I don't really care if it uses/depends on CRT. Ideally, it should have an abstraction layer for these things, and use whatever works.

-Steve

On Sunday, 23 May 2021 at 00:13:51 UTC, Steven Schveighoffer wrote:
>
> But this is my opinion for our standard library. For DMD though? I don't really care if it uses/depends on CRT. Ideally, it should have an abstraction layer for these things, and use whatever works.
>

Support for the C standard library and specific OS support isn't mutually exclusive. D runtime/phobos can also support CRT as an OS option with limited functionality. This would be equivalent to OS "any" in Nim, that supports whatever is provided by the CRT.

For Linux and Windows I would just go for the raw system API. The C library also imposes limitations and extra overhead. For example maximum allowed open files. The file operations also might do buffering in the CRT and the question if we want buffering there as well.

On Sunday, 23 May 2021 at 00:13:51 UTC, Steven Schveighoffer wrote:
> It so happens that the CRT functions for something like unlink and rename *are* the system calls on Unix. On windows, they are

They are wrappers on unix too, but the cost is low as the context switch overhead is so large that it makes the wrapper cost neglible. On mac there is no ABI guarantees if you dont use the wrappers IIRC.