Re: 32 bits time_t and Y2038 issue

On 19/03/2025 23:09, Waldek Hebisch wrote:

David Brown <david.brown@hesbynett.no> wrote:

On 19/03/2025 15:27, Grant Edwards wrote:

On 2025-03-19, David Brown <david.brown@hesbynett.no> wrote:
>

There are certainly a few things that Cygwin can handle that msys2
cannot.  For example, cygwin provides the "fork" system call that is
very slow and expensive on Windows, but fundamental to old *nix
software.

>
I believe Windows inherited that from VAX/VMS via Dave Cutler.

>
I am always a bit wary of people saying features were copied from VMS
into Windows NT, simply because the same person was a major part of the
development.  Windows NT was the descendent of DOS-based Windows, which
in turn was the descendent of DOS.  These previous systems had nothing
remotely like "fork", but Windows already had multi-threading.  When you
have decent thread support, the use of "fork" is much lower - equally,
in the *nix world at the time, the use-case for threading was much lower
because they had good "fork" support.  Thus Windows NT did not get
"fork" because it was not worth the effort - making existing thread
support better was a lot more important.

 Actually, Microsoft folks say that Windows NT kernel supports fork.
It was used to implement Posix subsystem.  IIUC they claim that
trouble is in upper layers: much of Windows API is _not_ kernel
and implementing well behaving fork means that all layers below
user program, starting from kernel would have to implement
fork.
 So this complicated layered structure seem to be main technical
reason of not having fork at API level.  And this structure
is like VMS and Mica.  Part of this layering could be motivated
by early Windows split between DOS and Windows proper, but
as Grant explained, VMS influence was stronger.
 IIUC early NT developement was part of joint IBM-Microsoft
effort to create OS/2, so clearly DOS and Windows influence
were limited.  Only later Microsoft decided to merge
classic Windows and NT and effectively abandon other
system iterfaces than Windows API.
 

DOS and Windows were a relevant part of OS/2 development too.  Both IBM and MS were fully aware that if OS/2 and/or NT were to succeed, compatibility with existing software was essential.  But more than that, compatibility with existing software /developers/ was essential.
But you are absolutely right that the NT kernel was originally intended to support different API's or "personalities" (I think that was the term used) - at least WinAPI, OS/2 and POSIX.  It was also the intention that the OS/2 kernel would be similarly flexible, so that users could pick their base system and run all sorts of different software on top.  IBM and MS worked together for interoperability.  Having at least minimal support for "fork" would have been necessary (along with things like case-sensitive filename support).
However, it did not take long for MS to realise that they could stab IBM in the back and take everything for themselves - through a mixture of technical, economic, legal and illegal shenanigans, they killed off OS/2 as an OS and as an API, and dropped everything but the WinAPI interface.   (As you point out, much of that was at a higher level than the kernel itself.)
There's a lot of interesting detail here from you and Grant, which I appreciate.  However, we've strayed a long way from the OP's original question and topic, and it's not really about embedded systems any more.   I hope Pozz got what he needed before we drifted!