Groups | Search | Server Info | Login | Register
Groups > comp.arch.embedded > #32394
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: 32 bits time_t and Y2038 issue |
| Date | 2025-03-21 22:40 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <vrkmd9$2dn3k$1@dont-email.me> (permalink) |
| References | (9 earlier) <vre61i$laqo$1@dont-email.me> <vrek8d$8us$1@reader1.panix.com> <vrerlm$18bs6$1@dont-email.me> <vrffbi$1tnem$1@paganini.bofh.team> <vrgjff$2qpu7$1@dont-email.me> |
Il 20/03/2025 09:26, David Brown ha scritto: > On 19/03/2025 23:09, Waldek Hebisch wrote: >> 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, which >>> 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. >> >> Actually, Microsoft folks say that Windows NT kernel supports fork. >> It was used to implement Posix subsystem. IIUC they claim that >> trouble is in upper layers: much of Windows API is _not_ kernel >> and implementing well behaving fork means that all layers below >> user program, starting from kernel would have to implement >> fork. >> >> So this complicated layered structure seem to be main technical >> reason of not having fork at API level. And this structure >> is like VMS and Mica. Part of this layering could be motivated >> by early Windows split between DOS and Windows proper, but >> as Grant explained, VMS influence was stronger. >> >> IIUC early NT developement was part of joint IBM-Microsoft >> effort to create OS/2, so clearly DOS and Windows influence >> were limited. Only later Microsoft decided to merge >> classic Windows and NT and effectively abandon other >> system iterfaces than Windows API. >> > > DOS and Windows were a relevant part of OS/2 development too. Both IBM > and MS were fully aware that if OS/2 and/or NT were to succeed, > compatibility with existing software was essential. But more than that, > compatibility with existing software /developers/ was essential. > > But you are absolutely right that the NT kernel was originally intended > to support different API's or "personalities" (I think that was the term > used) - at least WinAPI, OS/2 and POSIX. It was also the intention that > the OS/2 kernel would be similarly flexible, so that users could pick > their base system and run all sorts of different software on top. IBM > and MS worked together for interoperability. Having at least minimal > support for "fork" would have been necessary (along with things like > case-sensitive filename support). > > However, it did not take long for MS to realise that they could stab IBM > in the back and take everything for themselves - through a mixture of > technical, economic, legal and illegal shenanigans, they killed off OS/2 > as an OS and as an API, and dropped everything but the WinAPI interface. > (As you point out, much of that was at a higher level than the kernel > itself.) > > > There's a lot of interesting detail here from you and Grant, which I > appreciate. However, we've strayed a long way from the OP's original > question and topic, and it's not really about embedded systems any more. > I hope Pozz got what he needed before we drifted! Yes, David, thank you very much all of you for a very interesting discussion.
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