Groups | Search | Server Info | Login | Register
Groups > comp.arch.embedded > #32380
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: 32 bits time_t and Y2038 issue |
| Date | 2025-03-19 19:08 +0000 |
| Organization | PANIX Public Access Internet and UNIX, NYC |
| Message-ID | <vrf4o5$1hc$1@reader1.panix.com> (permalink) |
| References | (7 earlier) <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> |
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. :)
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar
32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-11 16:22 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-11 17:32 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-11 23:21 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 10:33 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 16:48 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 17:39 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 18:13 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 19:18 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-13 09:57 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-13 16:51 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-14 13:27 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-14 14:20 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 08:44 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 11:14 +0100
Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-14 01:48 +0000
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-14 08:36 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-15 16:30 +0000
Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-15 17:02 +0000
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-15 23:26 +0000
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-18 09:21 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 11:34 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-18 17:31 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 20:29 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:20 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-21 13:54 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 20:53 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 11:19 +0100
Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-21 14:35 +0000
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-18 18:28 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 20:43 +0100
Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-18 20:58 +0000
Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-18 23:31 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 11:24 +0100
Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-19 14:27 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 17:33 +0100
Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-19 19:08 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 21:14 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:48 +0000
Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-21 13:27 +0000
Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-19 22:09 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-20 09:26 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-21 22:40 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:23 +0000
Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-21 22:38 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 08:24 +0100
Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-21 14:04 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-21 16:45 +0100
Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-21 22:51 +0100
Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-22 00:00 +0100
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 14:29 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-22 14:46 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 17:57 +0100
Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-22 15:57 +0000
Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 18:02 +0100
Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-18 18:44 +0000
csiph-web