Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch.embedded
Subject: Re: 32 bits time_t and Y2038 issue
Date: Wed, 19 Mar 2025 21:14:09 +0100
Organization: A noiseless patient Spider
Lines: 133
Message-ID: <vrf8ii$1jr2p$1@dont-email.me>
References: <vqpkf9$1sbsa$1@dont-email.me> <vqpoi3$226ih$1@dont-email.me>
 <slrnvtbaot.sal.news-1513678000@a-tuin.ms.intern>
 <vrbado$2133a$1@dont-email.me> <vrbi79$2a30t$1@dont-email.me>
 <slrnvtjeq9.566.news-1513678000@a-tuin.ms.intern>
 <vrcidh$35fbp$2@dont-email.me> <vrcmpp$175$1@reader1.panix.com>
 <m3uah8F5prcU1@mid.dfncis.de> <vre61i$laqo$1@dont-email.me>
 <vrek8d$8us$1@reader1.panix.com> <vrerlm$18bs6$1@dont-email.me>
 <vrf4o5$1hc$1@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 19 Mar 2025 21:14:10 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1d916a32c2f1effdd5bad6b690159690";
	logging-data="1698905"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+mStJM7BiCha01XwzdWowxPSfLRp0zSaE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:YlfS8cKRBhRzHAdlTBer2HzBgPM=
In-Reply-To: <vrf4o5$1hc$1@reader1.panix.com>
Content-Language: en-GB
Bytes: 7797

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.