Re: 32 bits time_t and Y2038 issue

On 2025-03-19, 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,

The accounts I've read about NT say otherwise. They all claim that NT
was a brand-new kernel written (supposedly from scratch) by Dave
Cutler's team.  They implemented some backwards compatible Windows
APIs, but the OS kernel itself was based far more on VMS than Windows.

Quoting from https://en.wikipedia.org/wiki/Windows_NT:

   Although NT was not an exact clone of Cutler's previous operating
   systems, DEC engineers almost immediately noticed the internal
   similarities. Parts of VAX/VMS Internals and Data Structures,
   published by Digital Press, accurately describe Windows NT
   internals using VMS terms. Furthermore, parts of the NT codebase's
   directory structure and filenames matched that of the MICA
   codebase.[10] Instead of a lawsuit, Microsoft agreed to pay DEC
   $65–100 million, help market VMS, train Digital personnel on
   Windows NT, and continue Windows NT support for the DEC Alpha.

That last sentence seems pretty damning to me.

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.

But it did end up making support for the legacy fork() call used by
many legacy Unix programs very expensive. I'm not claiming that fork()
was a good idea in the first place, that it should have been
implemented better in VMS or Windows, or that it should still be used.

I'm just claiming that

 1. Historically, fork() was way, way, WAY slower on Windows and VMS
    than on Unix. [Maybe that has improved on Windows.]

 2. 40 years ago, fork() was still _the_way_ to start a process in
    most all common Unix applications.

However, true "fork" is very rarely useful, and is now rarely used in
modern *nix programming.

I didn't mean to imply that it was.  However, back in the 1980s when I
was running DEC/Shell with v7 Unix programs, fork() was still how the
Bourne shell in DEC/Shell started execution of every command.

Those utilities were all from v7 Unix.  That's before vfork()
existed. vfork() wasn't introduced until 3BSD and then SysVr4.

https://en.wikipedia.org/wiki/Fork_(system_call)

So these days, bash does not use "fork" for starting all the
subprocesses - it uses vfork() / execve(), making it more efficient
and also conveniently more amenable to running on Windows.

That's good news.  You'd think it wouldn't be so slow. :)