Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.localhost!not-for-mail From: Grant Edwards Newsgroups: comp.arch.embedded Subject: Re: 32 bits time_t and Y2038 issue Date: Wed, 19 Mar 2025 19:08:53 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Wed, 19 Mar 2025 19:08:53 -0000 (UTC) Injection-Info: reader1.panix.com; posting-host="localhost:::1"; logging-data="1580"; mail-complaints-to="abuse@panix.com" User-Agent: slrn/1.0.3 (Linux) Xref: csiph.com comp.arch.embedded:32380 On 2025-03-19, David Brown wrote: > On 19/03/2025 15:27, Grant Edwards wrote: >> On 2025-03-19, David Brown 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. :)