Path: ...!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.localhost!not-for-mail
From: Grant Edwards <invalid@invalid.invalid>
Newsgroups: comp.arch.embedded
Subject: Re: 32 bits time_t and Y2038 issue
Date: Wed, 19 Mar 2025 14:27:25 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vrek8d$8us$1@reader1.panix.com>
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>
Injection-Date: Wed, 19 Mar 2025 14:27:25 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="localhost:::1";
	logging-data="9180"; mail-complaints-to="abuse@panix.com"
User-Agent: slrn/1.0.3 (Linux)
Bytes: 2594
Lines: 30

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.

Back when the Earth was young I used to do embedded development on
VMS. I was, however, a "Unix guy" so my usual work environment on VMS
was "DEC/Shell" which was a v7 Bourne shell and surprisingly complete
set of v7 command line utilities that ran on VMS. [Without DEC/Shell,
I'm pretty sure I wouldn't have survived that project.] At one point I
wrote some fairly complex shell/awk/grep scripts to analyze and
cross-reference requirements documents written in LaTeX.  The scripts
would have taken a few minutes to run under v7 on an LSI-11, but they
took hours on a VAX 780 under VMS DEC/Shell (and used up ridiculous
amounts of CPU time). I was baffled.  I eventually tracked it down to
the overhead of "fork". A fork on Unix is a trivial operation, and
when running a shell program it happens a _lot_.

On VMS, a fork() call in a C program had _huge_ overhead compared to
Unix [but dog bless the guys in Massachusetts, it worked]. I'm not
sure if it was the process creation itself, or the "duplication" of
the parent that took so long. Maybe both. In the end it didn't matter:
it was so much easier to do stuff under DEC/Shell than it was under
DCL that we just ran the analysis scripts overnight.

--
Grant