Re: 32 bits time_t and Y2038 issue

On 19/03/2025 20:08, Grant Edwards wrote:

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.
 

The kernel itself was new - and perhaps was more "inspired" by VMS than some lawyers liked.  But the way it was used - the API for programs, and the way programs were built up, and what users saw - was all based on existing Windows practice.  In particular, it was important that the API for NT supported the multithreading from Win32s - thus it was not at all important that it could support "fork".

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.
 

I'm sure there were plenty of similarities in the way things worked internally.  And perhaps Cutler had some reason to dislike "fork", or perhaps simply felt that VMS hadn't needed it, and so NT would not need it.  But NT /had/ to have multi-threading, and when you have multi-threading, "fork" is not nearly as useful or important.

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

Agreed.
Windows NT originally tried to be POSIX compliant (or at least, to have a POSIX "personality" - along with a Win32 "personality", and an OS/2 "personality").  That would mean that some level of "fork" would be needed.  But the POSIX support aims were reduced over time.  I don't know how much of Cygwin's "fork" support is implemented in Cygwin or how much is in the NT kernel.
However, it's worth remembering that MS was not nearly as nice a company at that time as it is now, and not nearly as much of a team player.  The only thing better for MS than having Windows NT be unable to run ports of *nix software was to be able to run such software very badly.  For example, if Oracle could run on Windows but was much slower than MS SQL server due to a poor "fork", that would be a bigger marketing win than simply not being able to run Oracle.  But perhaps that is being a bit too paranoid and sceptical.

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

Agreed.
I remember the early days of getting gcc compiled for Windows (for the 68k target, in my case) - most of it was fine, but one program ("collect2" used by C++ to figure out template usage, if I remember correctly) used "fork" and that made things massively more complicated.

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.
 

Yes, vfork() was a later addition.
I also remember endless battles about different threading systems for Linux before it all settled down.

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

Even without "fork" being involved, Windows is /much/ slower at starting new processes than Linux.  It is also slower for file access, and has poorer multi-cpu support.  (These have, I believe, improved somewhat in later Windows versions.)  A decade or so ago I happened to be approximately in sync on the hardware for my Linux desktop and my Windows desktop (I use both systems at work), and tested a make + cross-gcc build of a project with a couple of hundred C and C++ files. The Linux build was close to twice the speed.