I would like to migrate to Linux. Windows 32 bit will be negated eventually. Perhaps run Mystic/Linux and use dos emu for the door games.
But door games will only be a memory in 14 years with the 2038 problem.


--- WWIV 5.9.03738[Windows]
* Origin: inland utopia * california * iutopia.duckdns.org:2023 (21:4/108)

Re: Operating Systems
By: Utopian Galt to All on Fri Apr 05 2024 09:33 pm

But door games will only be a memory in 14 years with the 2038 problem.

We still manage to run a lot of 16-bit doors that had/have Y2K bugs. <shrug>
--
digital man (rob)

Breaking Bad quote #2:
We flipped a coin, OK? You and me. You and me! Coin flip is sacred! - Jesse Norco, CA WX: 46.0øF, 75.0% humidity, 0 mph WSW wind, 0.09 inches rain/24hrs --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

Re: Operating Systems
By: Utopian Galt to All on Fri Apr 05 2024 09:33 pm

I would like to migrate to Linux. Windows 32 bit will be negated eventually. Perhaps run Mystic/Linux and use dos emu for the door games. But door games will only be a memory in 14 years with the 2038 problem.

I moved my BBS from 32-bit Windows to Linux a couple years ago. I had a couple other servers I was running in Linux, so for a while I was running my BBS in a Win32 VM on that PC, and finally decided to move my BBS to Linux as well.

I imagine there's probably no way to patch old DOS binaries to fix the 2038 problem, which is a shame.. Unless some people make new versions of all the old DOS door games. There's a LORD & LORD2 written for Synchronet's JavaScript, but of course, those will only run in Synchronet. There is also a program called 'jsdoor' that would allow a Synchronet JavaScript door to run outside of Synchronet, which is supposed to allow such door games to run on any BBS, so I'd wonder how well itworks with those JS versions of LORD & LORD2.

Nightfox
--- SBBSecho 3.20-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

Utopian Galt wrote to All <=-

I would like to migrate to Linux. Windows 32 bit will be negated eventually.

What I think is interesting about Microsoft is that while they move
everything to a subscription model (including, apparently Windows
itself) that Microsoft365 runs pretty well in a Chrome browser under
Linux, and gives you probably 80% of the user experience you'd get with
the Office app suite on Windows.

I've personally given up on using the Windows apps at work, mostly
because OneDrive is pretty buggy, especially when dealing with multiple
users editing cloud docs, then trying to sync to a local copy.

Every time there's an issue with a Windows upgrade I keep saying I'll
move to Linux, but I'm still there with Windows. I thought I'd migrate
when Windows 10 went EOL (my 4th gen i7 system wouldn't run Windows 11)
but I found a great deal on a 10th gen i7 with nvme support and lots of
ram, so the working 4th gen system is in my closet.

If Windows goes subscription, I'll definitely move.



... Wait, this is a *scene*?
--- MultiMail/Win v0.52
* Origin: realitycheckBBS.org -- information is power. (21:4/122)

Re: Operating Systems
By: Utopian Galt to All on Fri Apr 05 2024 09:33 pm

I would like to migrate to Linux. Windows 32 bit will be negated eventually. Perhaps run Mystic/Linux and use dos emu for the door

games.

But door games will only be a memory in 14 years with the 2038

problem.

I moved my BBS from 32-bit Windows to Linux a couple years ago. I had a couple other servers I was running in Linux, so for a while I was running my BBS in a Win32 VM on that PC, and finally decided to move my BBS to Linux as well.

I imagine there's probably no way to patch old DOS binaries to fix the 2038 problem, which is a shame.. Unless some people make new versions of all the old DOS door games. There's a LORD & LORD2 written for Synchronet's JavaScript, but of course, those will only run in Synchronet. There is also a program called 'jsdoor' that would allow a Synchronet JavaScript door to run outside of Synchronet, which is supposed to allow such door games to run on any BBS, so I'd wonder how well itworks with those JS versions of LORD & LORD2.

It works fine with LORD, I don't know about LORD2, haven't tried that yet.
It doesn't work with an other Synchronet JS doors I've tried.

---
Shurato, Sysop Shurato's Heavenly Sphere (ssh, telnet, pop3, ftp,nntp,
,wss) (Ports 22,23,110,21,119,8080) (ssh login 'bbs' pass 'shsbbs').


*** THE READER V4.50 [freeware]
---
* Origin: Shurato's Heavenly Sphere telnet://shsbbs.net (21:2/148)

Hello pF!

What I think is interesting about Microsoft is that while they move
everything to a subscription model (including, apparently
Windows itself)...

Where is that happening?



--- OpenXP 5.0.58
* Origin: (} Pointy McPointFace (21:4/106.21)

Ogg wrote to poindexter FORTRAN <=-

Hello pF!

What I think is interesting about Microsoft is that while they move
everything to a subscription model (including, apparently
Windows itself)...

Where is that happening?

They've talked about it for some time, no solid plans (yet). I'm sure
they'll come up with a E365 model for business that includes Windows
licensing before too long.



... Arachnophobia is the fear of ducks.
--- MultiMail/Win v0.52
* Origin: realitycheckBBS.org -- information is power. (21:4/122)

Nightfox wrote to Utopian Galt <=-

I imagine there's probably no way to patch old DOS binaries to fix the 2038 problem, which is a shame..

I thought the 2038 problem was a unix time_t issue?


... Tony Hawk began skateboarding when he was 12 hours old.
--- MultiMail/Win v0.52
* Origin: realitycheckBBS.org -- information is power. (21:4/122)

Re: Re: Operating Systems
By: poindexter FORTRAN to Nightfox on Sun Apr 07 2024 08:42 am

I imagine there's probably no way to patch old DOS binaries to fix the
2038 problem, which is a shame..

I thought the 2038 problem was a unix time_t issue?

I thought I'd heard that as well. I don't remember for sure if it's just that or if it also affects DOS binaries.

Nightfox
--- SBBSecho 3.20-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

On 06 Apr 2024 at 09:48a, Nightfox pondered and said...

I imagine there's probably no way to patch old DOS binaries to fix the 2038 problem, which is a shame.. Unless some people make new versions

Meh; just set the date back to some arbitrary time in
the past, perhaps a year where the days of the week line
up with whatever the current year it currently is. I
doubt many people would notice if a BBS door game thought
it was 1989.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 07 Apr 2024 at 08:42a, poindexter FORTRAN pondered and said...

I thought the 2038 problem was a unix time_t issue?

Depends on the Unix and the definition of `time_t`; on
any reasonably modern system that's an `int64_t`. It's
really just old binaries or old versions of the OS.

What DOS does with time is an interesting question. The
earliest IBM PC didn't have a real-time clock, so the
operating system asked the user for the date and time on
each boot, but time on each request was obtained from the
BIOS. It's not clear to me that DOS itself maintained
an internal time; I rather suspect that it did not. Near
as I can tell, the BIOS maintains two variables in its
data area: a count of timer interrupts since the system
booted, and a count of 24 hour intervals since system boot.
The timer in question is the programmable interval timer,
and it interrupts abut 18 times a second. It appears
that the timer tick counter is a 32-bit integer and it
is returned to DOS as a pair of 16-bit registers.

According to some Microsoft site I found, DOS records dates
and times for files as "packed 16-bit values". There's a
16-bit integer that encodes the date, and another that
encodes time.

The date representation uses 5 bits for the day of the month,
4 for the month, and the last 7 bits for the year, as an
offset for 1980. This implies that MS-DOS can accurately
track dates on files until the end of 2107, after which it
will roll back around to 1980.

The time representation is similar: 5 bits to represent a
second divided by 2, 6 bits for the minute, and the last
5 bits for the hour (using a 24-hour clock). The seconds
representation is a little weird; this implies that the
resolution on time stamps is only to two seconds (note
that 2^5=32 is not enough to hold the full range of 60
seconds). I don't know that there's a cleverer
representation that can represent the full range and still
be packed into a 16-bit integer.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: Operating Systems
By: tenser to Nightfox on Mon Apr 08 2024 11:48 am

I imagine there's probably no way to patch old DOS binaries to fix the
2038 problem, which is a shame.. Unless some people make new versions

Meh; just set the date back to some arbitrary time in the past, perhaps a year where the days of the week line up with whatever the current year it currently is. I doubt many people would notice if a BBS door game thought it was 1989.

I'm not sure that would be a good solution though, as you wouldn't want your whole OS and other apps thinking it was 1989 or something.

Nightfox
--- SBBSecho 3.20-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

I'm not sure that would be a good solution though, as you wouldn't want you whole OS and other apps thinking it was 1989 or something.

Yeah, BRE would lose it's mind! ;)

... My other tagline's a Rolex...

--- Renegade v1.35à/DOS
* Origin: The Titantic BBS Telnet - ttb.rgbbs.info (21:1/144)

I thought the 2038 problem was a unix time_t issue?

Depends on the Unix and the definition of `time_t`; on
any reasonably modern system that's an `int64_t`. It's
really just old binaries or old versions of the OS.

DOS has its own date/time formats, but it is also common for software to convert between those and unix timestamps - so I think we will see many DOS programs directly affected by the year 2038 time_t overflow.


Chris/akacastor

--- Maximus 3.01
* Origin: Another Millennium - Canada - another.tel (21:1/162)

I'm not sure that would be a good solution though, as you wouldn't want your whole OS and other apps thinking it was 1989 or something.

I wonder if it's possible to set the date back for just dosemu or qemu or whatever is running the dos door.

Andrew

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 08 Apr 2024, apam said the following...

I'm not sure that would be a good solution though, as you wouldn't wa your whole OS and other apps thinking it was 1989 or something.

I wonder if it's possible to set the date back for just dosemu or qemu or whatever is running the dos door.

could write a TSR to override the interrupts for the date & time. just pick an arbitrary offset that matches days of the week or something like someone else mentioned.

maybe for pascal doors something like tppatch could sacrifice earlier dates for later ones? who knows :)

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi (21:1/616)

On 07 Apr 2024 at 06:27p, Nightfox pondered and said...

Re: Re: Operating Systems
By: tenser to Nightfox on Mon Apr 08 2024 11:48 am

I imagine there's probably no way to patch old DOS binaries to fix t
2038 problem, which is a shame.. Unless some people make new versio

Meh; just set the date back to some arbitrary time in the past, perha year where the days of the week line up with whatever the current yea currently is. I doubt many people would notice if a BBS door game th it was 1989.

I'm not sure that would be a good solution though, as you wouldn't want your whole OS and other apps thinking it was 1989 or something.

Sorry, I don't think I was clear here. You're already
running the DOS program under some sort of simulator;
simply set the date back for that simulator.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 07 Apr 2024 at 08:02p, AKAcastor pondered and said...

I thought the 2038 problem was a unix time_t issue?

Depends on the Unix and the definition of `time_t`; on
any reasonably modern system that's an `int64_t`. It's
really just old binaries or old versions of the OS.

DOS has its own date/time formats, but it is also common for software to convert between those and unix timestamps - so I think we will see many DOS programs directly affected by the year 2038 time_t overflow.

Again, "Unix timestamps" have changed definition and meaning
over time. The issue is if someone tries to stuff the number
of seconds since 1970 into a 32-bit signed integer; `time_t`
these days is 64 bits, even on 32-bit machines. But also, one
is running DOS binaries under some sort of DOS emulator. In
that case, one can artificially inject a date in the past into
the emulator, avoiding the entire issue, unless one really cares
that some random MS-DOS programs know the proper date sometime
in the late 2030s, which I found dubious.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 05 Apr 2024, Utopian Galt said the following...

I would like to migrate to Linux. Windows 32 bit will be negated eventually. Perhaps run Mystic/Linux and use dos emu for the door games. But door games will only be a memory in 14 years with the 2038 problem.

Whats the 2038 Problem?

|23|04Dr|16|12Claw
|16|14Sysop |12Noverdu |14BBS |20|15Radio|10@|14HTTP://Noverdu.com:88
|16|10 Standard ports for SSH/Telnet |04 WEB|14@|12HTTP://noverdu.com:808 |20|15Global Chat, Global Messaging and Games! |16|10Ditch the Unsocial Media

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: Noverdu BBS (21:1/210)

I'm not sure that would be a good solution though, as you wouldn't

want you

whole OS and other apps thinking it was 1989 or something.

Yeah, BRE would lose it's mind! ;)

That was the first thing I thought also. ;)



--- Talisman v0.53-dev (Linux/armv7l)
* Origin: possumso.fsxnet.nz * telnet:24/ssh:2122/ftelnet:80 (21:4/134)

On 08 Apr 2024 at 07:53a, claw pondered and said...

On 05 Apr 2024, Utopian Galt said the following...

I would like to migrate to Linux. Windows 32 bit will be negated eventually. Perhaps run Mystic/Linux and use dos emu for the door gam But door games will only be a memory in 14 years with the 2038 proble

Whats the 2038 Problem?

Time on Unix systems has been, since the early 1970s, represented
as a signed, 32-bit integer counting the number of seconds since
the "epoch", which as arbitrarily chosen to be midnight between
Dec 31, 1969/Jan 1, 1970, UTC. This gives Unix timestamps a range
of about 2.15 billion seconds before they go negative (actually a
little less than that: 2^31 - 1 is the exact number). That rolls
over in January, 2038.

On Unix, the type `time_t` is usually a `typedef` for the C type
`long` which, on most modern Unix machines, is a 64-bit signed
integer. So on any machine made since, oh, 2010 or so, this isn't
that much of an issue. But on older, 32-bit hardware, `long` was
usually a signed 32-bit value, so for old binaries or old OS, we've
got this roll-over problem in 2038. It's a legit issue.

There are a few things we can do to address this. 1) we can treat
32-bit time stamps as _unsigned_, perhaps with the all-bits-1 value
treated specially as a sentinel. That would effectively double the
range of such values, kicking the can down the road 70-ish years.
But it won't really help for statically compiled binaries, or things
that care about the signedness of time_t.

2) Another thing we can do recompile old binaries, where we can.
That won't work for a lot of old stuff where the source code has
been lost or is otherwise just unavailable; a lot of DOS programs,
for instance. But note that DOS uses a different format for
representing dates, so this is only relevant in instances where
an old DOS program converts some notion of time to a signed 32-bit
int using the Unix epoch.

But for hobbyist DOS programs, we can always just set the date for
whatever DOS emulator is running back to some arbitrary point before
the 2038 rollover date, and that's probably fine for BBS doors and
things like that.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 08 Apr 2024 at 08:07a, Blue White pondered and said...

I'm not sure that would be a good solution though, as you wouldn't

want you

whole OS and other apps thinking it was 1989 or something.

Yeah, BRE would lose it's mind! ;)

That was the first thing I thought also. ;)

So set it to some time in the 2000's well before the 2038 date,
if BRE cares.

... Inside every cynical person, there is a disappointed idealist.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 09 Apr 2024, tenser said the following...

But for hobbyist DOS programs, we can always just set the date for whatever DOS emulator is running back to some arbitrary point before
the 2038 rollover date, and that's probably fine for BBS doors and
things like that.

best bet is current_year - 56 (once 2038 rolls around at least) .. that nets you matching days/dates from "1982" to "2038" (2038 to 2094) .. and then it's broke again. current - 28 works but you only get 2038 -> 2066.

dos itself is good until 2099.. assuming software uses that data the same way (turbo pascal system functions do) it should be fine.

https://www.stanislavs.org/helppc/int_21-2a.html https://www.stanislavs.org/helppc/int_21-57.html

definitely enough examples of pascal unix time code from that era to mess things up though.

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi (21:1/616)

Re: Re: Operating Systems
By: tenser to Nightfox on Tue Apr 09 2024 12:06 am

I'm not sure that would be a good solution though, as you wouldn't want
your whole OS and other apps thinking it was 1989 or something.

Sorry, I don't think I was clear here. You're already running the DOS program under some sort of simulator; simply set the date back for that simulator.

I'm using dosemu2 to run DOS doors. I'd have to check its documentation, as I'm not sure how I'd do that.

Also, for sysops running their BBS in Win32, I'm not sure if there's a way to do that.. Win32 can seamlessly run 16-bit DOS apps, and I don't recall ever seeing a way to modify the date just for its virtual DOS machine. Maybe there is a way..

Nightfox
--- SBBSecho 3.20-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

Re: Re: Operating Systems
By: Nightfox to tenser on Mon Apr 08 2024 09:07 am

Also, for sysops running their BBS in Win32, I'm not sure if there's a way to do that.. Win32 can seamlessly run 16-bit DOS apps, and I don't recall ever seeing a way to modify the date just for its virtual DOS machine. Maybe there is a way..

By 2038, win10 will be a relic and so will win32.

Andrew
--- SBBSecho 3.20-Linux
* Origin: HappyLand - happylnd.synchro.net (21:1/182.1)

BY: apam (21:1/182.1)

|11a|09> |10By 2038, win10 will be a relic and so will win32.|07
|11a|09> |07
I would like to see a preservation layer.


--- WWIV 5.9.03738[Windows]
* Origin: inland utopia * california * iutopia.duckdns.org:2023 (21:4/108)

Yeah, BRE would lose it's mind! ;)

That was the first thing I thought also. ;)

So set it to some time in the 2000's well before the 2038 date,
if BRE cares.

I am not sure that BRE standalone does care, but BRE interBBS very much
does. I have found that out a few times when the date in one of my
dosemu sessions got borked.

Getting all the sysops in a league to set their dates to the same
imaginary past date, and keeping it there, would be a royal PITA.
Hopefully BRE is not one of the ones that uses a UNIX style date.



--- Talisman v0.53-dev (Linux/armv7l)
* Origin: possumso.fsxnet.nz * telnet:24/ssh:2122/ftelnet:80 (21:4/134)

Re: Re: Operating Systems
By: poindexter FORTRAN to Nightfox on Sun Apr 07 2024 08:42 am

Nightfox wrote to Utopian Galt <=-

I imagine there's probably no way to patch old DOS binaries to fix the 2038 problem, which is a shame..

I thought the 2038 problem was a unix time_t issue?

It is. And many DOS programs were written in C or C++ and used time_t (a 32-bit signed integer type, in those days) to store date/time values.
--
digital man (rob)

Rush quote #8:
One likes to believe in the freedom of music...
Norco, CA WX: 79.2øF, 16.0% humidity, 2 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

On 08 Apr 2024 at 09:07a, Nightfox pondered and said...

Re: Re: Operating Systems
By: tenser to Nightfox on Tue Apr 09 2024 12:06 am

I'm not sure that would be a good solution though, as you wouldn't w
your whole OS and other apps thinking it was 1989 or something.

Sorry, I don't think I was clear here. You're already running the DO program under some sort of simulator; simply set the date back for th simulator.

I'm using dosemu2 to run DOS doors. I'd have to check its
documentation, as I'm not sure how I'd do that.

You've got 14 years to figure it out, my guy. :-)

Also, for sysops running their BBS in Win32, I'm not sure if there's a
way to do that.. Win32 can seamlessly run 16-bit DOS apps, and I don't recall ever seeing a way to modify the date just for its virtual DOS machine. Maybe there is a way..

Very likely that, in 2038, they'll be running win32 under an
emulator as well.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 09 Apr 2024 at 07:51a, Blue White pondered and said...

Yeah, BRE would lose it's mind! ;)

That was the first thing I thought also. ;)

So set it to some time in the 2000's well before the 2038 date,
if BRE cares.

I am not sure that BRE standalone does care, but BRE interBBS very much does. I have found that out a few times when the date in one of my
dosemu sessions got borked.

Getting all the sysops in a league to set their dates to the same imaginary past date, and keeping it there, would be a royal PITA. Hopefully BRE is not one of the ones that uses a UNIX style date.

*shrug* It's either a) not affected, b) people will figure out
some solution (probably based on coordinating setting the date
back) and c) it will stop working.

Given that there's no evidence that BRE even cares about the Unix
epoch roll-over, which is still 14 years away, it seems a bit
premature to worry about solutions, let alone shoot them down.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 11 Apr 2024, tenser said the following...

Very likely that, in 2038, they'll be running win32 under an
emulator as well.

apparently microsoft has just gotten their intel-on-arm emulation matched in speed with apple's. pretty likely we're going to have official support for win32 (the api) and x86 & x86_64 for more than 14 years..

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi (21:1/616)

Re: Re: Operating Systems
By: fusion to tenser on Wed Apr 10 2024 12:17 pm

Very likely that, in 2038, they'll be running win32 under an emulator as
well.

apparently microsoft has just gotten their intel-on-arm emulation matched in speed with apple's. pretty likely we're going to have official support for win32 (the api) and x86 & x86_64 for more than 14 years..

I wonder how many people will be using ARM-based Wnidows machines though. I've heard of Microsoft working on that, but at least right now, I haven't seen anyone using an ARM Windows machine, either at work or for personal use.

Nightfox
--- SBBSecho 3.20-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

On 10 Apr 2024 at 12:17p, fusion pondered and said...

apparently microsoft has just gotten their intel-on-arm emulation
matched in speed with apple's. pretty likely we're going to have
official support for win32 (the api) and x86 & x86_64 for more than 14 years..

What "Win32" means has changed over time and continues to evolve.
What DOS programs require for compatibility may fall under some
broad umbrella of "Win32" but support for 32-bit programs running
directly on hardware will fall away. Clearly, if MSFT moves
Windows to ARM-based systems, that will be the case anyway. I
feel fully confident saying that, in 2038, DOS programs will only
run in an emulator.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 10 Apr 2024 at 10:55a, Nightfox pondered and said...

Re: Re: Operating Systems
By: fusion to tenser on Wed Apr 10 2024 12:17 pm

Very likely that, in 2038, they'll be running win32 under an emulato
well.

apparently microsoft has just gotten their intel-on-arm emulation mat in speed with apple's. pretty likely we're going to have official sup for win32 (the api) and x86 & x86_64 for more than 14 years..

I wonder how many people will be using ARM-based Wnidows machines
though. I've heard of Microsoft working on that, but at least right
now, I haven't seen anyone using an ARM Windows machine, either at work
or for personal use.

"It all depends."

The era of x86 on the "desktop" is likely drawing to a conclusion.
We've got a few more generations and probably another 10 years or
so, and then it's going to be mostly ARM and RISC-V. x86 will
remain on the high-end in the server space for a while, but will
probably asymptotically trend towards 0% of the market, kind of
like the mainframe.

Microsoft is not stupid. They see the trend and will react
accordingly, for as long as they intend to keep Windows as a going
concern (likely forever, but probably in a somewhat diminished
form, perhaps moving in favor of Linux over time).

What you see _now_ has nothing to do with what you'll see in 2038.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

I wonder how many people will be using ARM-based Wnidows machines
though. I've heard of Microsoft working on that, but at least right
now, I haven't seen anyone using an ARM Windows machine, either at work
or for personal use.

Using an arm install under Mac Parrells.

... You can learn many things from children... like how much patience you have

--- Mystic BBS v1.12 A49 2023/04/30 (Linux/64)
* Origin: Clutch BBS * telnet://clutchbbs.com (21:1/199)

On 11 Apr 2024, tenser said the following...

On 10 Apr 2024 at 12:17p, fusion pondered and said...

apparently microsoft has just gotten their intel-on-arm emulation matched in speed with apple's. pretty likely we're going to have official support for win32 (the api) and x86 & x86_64 for more than 1 years..

What "Win32" means has changed over time and continues to evolve.
What DOS programs require for compatibility may fall under some
broad umbrella of "Win32" but support for 32-bit programs running
directly on hardware will fall away. Clearly, if MSFT moves
Windows to ARM-based systems, that will be the case anyway. I
feel fully confident saying that, in 2038, DOS programs will only
run in an emulator.

there's a reason i quoted what i did and what i didn't. my post isn't about dos support at all.

"win32" means the windows api. (it's right there where i said it in parenthesis). it has nothing to do with it being 32-bit, and microsoft uses it that way all over their website.

i think there's a pretty hefty distinction between "officially supported by microsoft" and what you implied. there won't be effort involved in emulating it. most people won't know they are.

as an example: dos has been emulated while windows is running since windows/386 (2.0). i'm not sure why you're suggesting it will suddenly be again in 2038 ;)

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi (21:1/616)

Re: Re: Operating Systems
By: claw to Utopian Galt on Mon Apr 08 2024 07:53 am

Whats the 2038 Problem?

https://en.wikipedia.org/wiki/Year_2038_problem

AKA the "Epochalypse".
--
digital man (rob)

Breaking Bad quote #50:
I've got your restraining order right here. [grabs crotch] Restrain this! - WW Norco, CA WX: 80.7øF, 27.0% humidity, 6 mph W wind, 0.00 inches rain/24hrs
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

On 10 Apr 2024 at 04:06p, fusion pondered and said...

there's a reason i quoted what i did and what i didn't. my post isn't about dos support at all.

Then I guess I'm confused because the whole context of
the thread is support for DOS doors after 2038.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: Operating Systems
By: tenser to Nightfox on Thu Apr 11 2024 06:23 am

The era of x86 on the "desktop" is likely drawing to a conclusion. We've got a few more generations and probably another 10 years or so, and then it's going to be mostly ARM and RISC-V. x86 will remain on the high-end in the server space for a while, but will probably asymptotically trend towards 0% of the market, kind of like the mainframe.

Microsoft is not stupid. They see the trend and will react accordingly, for as long as they intend to keep Windows as a going concern (likely forever, but probably in a somewhat diminished form, perhaps moving in favor of Linux over time).

What you see _now_ has nothing to do with what you'll see in 2038.

That's probably true. I just hope there will still be a way to build your own desktop PC - That offers the best way to customize your own computer, and I've always enjoyed doing that. I'd be disappointed if all computers basically become a closed box that you can't customize or upgrade, and would be forced to buy a whole new computer if you just need more RAM, a faster processor, etc..

Also, I hope ARM-based computers would still be as performant (or more) for intensive computing tasks, such as video processing, photo editing, gaming, etc.. Though I imagine that will be the case.

Nightfox
--- SBBSecho 3.20-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

Re: Operating Systems
By: niter3 to Nightfox on Wed Apr 10 2024 02:35 pm

I wonder how many people will be using ARM-based Wnidows machines
though. I've heard of Microsoft working on that, but at least right now,
I haven't seen anyone using an ARM Windows machine, either at work or for
personal use.

Using an arm install under Mac Parrells.

Well yeah, though the hardware is a Mac. I was thinking computers that are made to run Windows - I still see x86/x64 machines these days.

Nightfox
--- SBBSecho 3.20-Linux
* Origin: Digital Distortion: digdist.synchro.net (21:1/137)

Re: Re: Operating Systems
By: tenser to Nightfox on Thu Apr 11 2024 06:23 am

Microsoft is not stupid. They see the trend and will react
accordingly, for as long as they intend to keep Windows as a going
concern (likely forever, but probably in a somewhat diminished
form, perhaps moving in favor of Linux over time).

Microsoft also has created versions of Windows NT for MIPS, Alpha, i860, PowerPC and Itanium. So their ability to "see the trend and react accordingly" isn't fool proof. :-)

What you see _now_ has nothing to do with what you'll see in 2038.

14 years will go by pretty quick. 2010 wasn't so long ago now. I started working on ARM devices and hearing about how ARM was going to take over everything in 1999 (25 years ago, about). Maybe RISC-V and ARM will take over everything, maybe not. I could easily imagine 14 years now being very similar in balance of processor architectures and market share to what we see now. <shrug>
--
digital man (rob)

Synchronet "Real Fact" #58:
The last version of Synchronet to run on MS-DOS and OS/2 was v2.30c (1999) Norco, CA WX: 64.6øF, 47.0% humidity, 0 mph N wind, 0.00 inches rain/24hrs
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

On 10 Apr 2024 at 06:16p, Nightfox pondered and said...

That's probably true. I just hope there will still be a way to build
your own desktop PC - That offers the best way to customize your own computer, and I've always enjoyed doing that. I'd be disappointed if
all computers basically become a closed box that you can't customize or upgrade, and would be forced to buy a whole new computer if you just
need more RAM, a faster processor, etc..

I suspect that will be the case for power users. Simply plugging
the various components in shouldn't be something that's restricted
just to OEMs.

Also, I hope ARM-based computers would still be as performant (or more) for intensive computing tasks, such as video processing, photo editing, gaming, etc.. Though I imagine that will be the case.

They already are! Apple's M-series chips are very fast, certainly
on par with desktop x86 parts. On the high-end, Altera's core IPes
are used in a number of de novo systems; Google just launched an
offering there (I presume for GCP; they've been using ARM for their
internal services for several years now). And of course Amazon has
Graviton, et al. I'm sure MSFT has something coming. The Chinese
players seem to be mostly leaning towards RISC-V, though; SiFive is
saying they're going to unleash a high-end processor sometime later
this year (if only they'd chosen a better page table format...sigh).

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 10 Apr 2024 at 10:47p, Digital Man pondered and said...

Re: Re: Operating Systems
By: tenser to Nightfox on Thu Apr 11 2024 06:23 am

Microsoft is not stupid. They see the trend and will react accordingly, for as long as they intend to keep Windows as a going concern (likely forever, but probably in a somewhat diminished
form, perhaps moving in favor of Linux over time).

Microsoft also has created versions of Windows NT for MIPS, Alpha, i860, PowerPC and Itanium. So their ability to "see the trend and react accordingly" isn't fool proof. :-)

Ah, i860.... I needed that belly laugh. They made a lot of margin
dollars on that Alpha port, though. And of course, everyone thought
that Itanium was going to be the future; can't really fault 'em
there.

What you see _now_ has nothing to do with what you'll see in 2038.

14 years will go by pretty quick. 2010 wasn't so long ago now. I started working on ARM devices and hearing about how ARM was going to take over everything in 1999 (25 years ago, about). Maybe RISC-V and ARM will take over everything, maybe not. I could easily imagine 14 years now being
very similar in balance of processor architectures and market share to what we see now. <shrug>

I some sense, ARM did kinda take over everything. Consider all
the places that you used to stick a 68k or a Dragonball or 8085;
what's in those now? Mostly Cortex-M, and RISC-V is coming up
in the uCtlr space (those WDC chips look pretty nice, and I saw
something the other day that looked like it'd give an M7-class
chip a run for its money). On the high-end, ARM's making serious
inroads with the hyperscalers, China's bowing out of the x86
world, and Intel keeps tripping over it's own feet; the big wild
card in my mind is AMD, which stumbled back from the dead with
Zen. But even there, the PSP is an ARM core, not x86, so.... :-D

Of course it's impossible to predict the future, and I could be
wrong. But I just don't see x86 retaining its dominant position
for that long.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 10 Apr 2024, Digital Man said the following...

https://en.wikipedia.org/wiki/Year_2038_problem
AKA the "Epochalypse".
--

Well Ain't that a b!+c4. People haven't been 32 bit in a long time I can't imagine the newer systems have this issue???

|23|04Dr|16|12Claw
|16|14Sysop |12Noverdu |14BBS |20|15Radio|10@|14HTTP://Noverdu.com:88
|16|10 Standard ports for SSH/Telnet |04 WEB|14@|12HTTP://noverdu.com:808 |20|15Global Chat, Global Messaging and Games! |16|10Ditch the Unsocial Media

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: Noverdu BBS (21:1/210)

Re: Re: Operating Systems
By: tenser to Digital Man on Fri Apr 12 2024 12:12 am

I some sense, ARM did kinda take over everything. Consider all
the places that you used to stick a 68k or a Dragonball or 8085;
what's in those now? Mostly Cortex-M, and RISC-V is coming up

ARM is huge (especially in consumer electronics), no doubt, and definitely PPC and MIPS are dynosaurs today, but they're *still* used in automotive, in very large volumes, and in other safety-critical industries (aviation, aerospace) along with other obscure architectures (e.g. Infineon's TriCore architecture) that won't be going away any time soon.

There are other differentiating features beyond performance and power consumption, that keep some of these non-ARM architectures thriving, believe it or not. :-)
--
digital man (rob)

This Is Spinal Tap quote #46:
"Not an Exit" - we don't want an exit. Well that's true.
Norco, CA WX: 78.7øF, 32.0% humidity, 0 mph NW wind, 0.00 inches rain/24hrs
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

Re: Re: Operating Systems
By: claw to Digital Man on Thu Apr 11 2024 07:52 am

On 10 Apr 2024, Digital Man said the following...

https://en.wikipedia.org/wiki/Year_2038_problem
AKA the "Epochalypse".
--

Well Ain't that a b!+c4. People haven't been 32 bit in a long time I can't imagine the newer systems have this issue???

The problem is in the softare, not "the system". The system can be 64-bit and still have plenty of 32-bit time_t use lurking in its software. Y2K38 is definitely going to blow some shit up (figuratively, if not literally).
--
digital man (rob)

Steven Wright quote #25:
If at first you don't succeed, destroy all evidence that you tried.
Norco, CA WX: 79.8øF, 33.0% humidity, 2 mph W wind, 0.00 inches rain/24hrs
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

On 10 Apr 2024, Digital Man said the following...

https://en.wikipedia.org/wiki/Year_2038_problem AKA the
"Epochalypse". --

Well Ain't that a b!+c4. People haven't been 32 bit in a long time I can't imagine the newer systems have this issue???

That's not true. A lot of sysops run 32 bit systems to be able to run DOS doors... But no, my main OS for regular purposes won't experience this.

--- shsbbs.net
Shurato, Sysop Shurato's Heavenly Sphere (ssh, telnet, pop3, ftp,nntp,
,wss) (Ports 22,23,110,21,119,8080) (ssh login 'bbs' pass 'shsbbs').


*** THE READER V4.50 [freeware]
---
* Origin: Shurato's Heavenly Sphere telnet://shsbbs.net (21:2/148)

Digital Man wrote to tenser <=-

Re: Re: Operating Systems
By: tenser to Digital Man on Fri Apr 12 2024 12:12 am

I some sense, ARM did kinda take over everything. Consider all
the places that you used to stick a 68k or a Dragonball or 8085;
what's in those now? Mostly Cortex-M, and RISC-V is coming up

ARM is huge (especially in consumer electronics), no doubt, and
definitely PPC and MIPS are dynosaurs today, but they're *still*
used in automotive, in very large volumes, and in other
safety-critical industries (aviation, aerospace) along with other
obscure architectures (e.g. Infineon's TriCore architecture) that
won't be going away any time soon.

Yes, and I believe that many banking ATMs still run OS/2 for some
reason, and I know that MANY Point-of-Sale devices/systems still run
good old MSDOS. Not worth the effort/expense to update those systems,
and they're reliable.

There are other differentiating features beyond performance and
power consumption, that keep some of these non-ARM architectures
thriving, believe it or not. :-)

Yup, and reliability/niche-status are two of them.



... Users come in two types: Those who have lost data, and those who will.
=== MultiMail/Linux v0.52
--- SBBSecho 3.20-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (21:2/138)

On 11 Apr 2024 at 11:13a, Digital Man pondered and said...

I some sense, ARM did kinda take over everything. Consider all
the places that you used to stick a 68k or a Dragonball or 8085;
what's in those now? Mostly Cortex-M, and RISC-V is coming up

ARM is huge (especially in consumer electronics), no doubt, and
definitely PPC and MIPS are dynosaurs today, but they're *still* used in automotive, in very large volumes, and in other safety-critical
industries (aviation, aerospace) along with other obscure architectures (e.g. Infineon's TriCore architecture) that won't be going away any time soon.

There are other differentiating features beyond performance and power consumption, that keep some of these non-ARM architectures thriving, believe it or not. :-)

I totally do! There's also still a lot of SPARC in aerospace,
somewhat weirdly. Register windows are still a bad idea,
though. :-)

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 11 Apr 2024, Digital Man said the following...

The problem is in the softare, not "the system". The system can be
64-bit and still have plenty of 32-bit time_t use lurking in its
software. Y2K38 is definitely going to blow some shit up (figuratively,
if not literally). --
digital man (rob)

Well I will have to read more about it. If its software then Why isn't this fixed already. Guess I will have to ready about it to know why its not simple.

|23|04Dr|16|12Claw
|16|14Sysop |12Noverdu |14BBS |20|15Radio|10@|14HTTP://Noverdu.com:88
|16|10 Standard ports for SSH/Telnet |04 WEB|14@|12HTTP://noverdu.com:808 |20|15Global Chat, Global Messaging and Games! |16|10Ditch the Unsocial Media

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: Noverdu BBS (21:1/210)

On 11 Apr 2024, Shurato said the following...

That's not true. A lot of sysops run 32 bit systems to be able to run
DOS doors... But no, my main OS for regular purposes won't experience this.

--- shsbbs.net
Shurato, Sysop Shurato's Heavenly Sphere (ssh, telnet, pop3, ftp,nntp, ,wss) (Ports 22,23,110,21,119,8080) (ssh login 'bbs' pass 'shsbbs').

Linux FTW. :)

|23|04Dr|16|12Claw
|16|14Sysop |12Noverdu |14BBS |20|15Radio|10@|14HTTP://Noverdu.com:88
|16|10 Standard ports for SSH/Telnet |04 WEB|14@|12HTTP://noverdu.com:808 |20|15Global Chat, Global Messaging and Games! |16|10Ditch the Unsocial Media

--- Mystic BBS v1.12 A47 2021/12/24 (Linux/64)
* Origin: Noverdu BBS (21:1/210)

Re: Re: Operating Systems
By: claw to Digital Man on Thu Apr 11 2024 11:24 pm

On 11 Apr 2024, Digital Man said the following...

The problem is in the softare, not "the system". The system can be 64-bit and still have plenty of 32-bit time_t use lurking in its software. Y2K38 is definitely going to blow some shit up (figuratively, if not literally). --

Well I will have to read more about it. If its software then Why isn't this fixed already. Guess I will have to ready about it to know why its not simple.

Because we're mostly talking about older software (e.g. 16-bit programs for MS-DOS) that hasn't been updated or supported in 20 or 30 years, the build tools and run-time libraries are no longer supported or updated (so they're not going to be migrated to 64-bit time_t's, even if that was feasible) and the source code to many of these programs was lost anyway. No, it's not a simple problem to solve.
--
digital man (rob)

Rush quote #63:
He's got a problem with his poisons, but you know he'll find a cure
Norco, CA WX: 61.0øF, 69.0% humidity, 0 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

Re: Re: Operating Systems
By: claw to Shurato on Thu Apr 11 2024 11:25 pm

That's not true. A lot of sysops run 32 bit systems to be able to run DOS doors... But no, my main OS for regular purposes won't experience this.

Linux FTW. :)

For many years, Linux (and the GNU C libraries used to built it's userland programs) had the exact same problem/limitation.
--
digital man (rob)

Synchronet/BBS Terminology Definition #18:
CVS = Concurrent Versioning System
Norco, CA WX: 60.4øF, 70.0% humidity, 0 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

Quoting Gamgee to Digital Man <=-

reason, and I know that MANY Point-of-Sale devices/systems still run
good old MSDOS. Not worth the effort/expense to update those systems,
and they're reliable.

I ran a MSDOS program for inventory / invoicing when I ran my business and
it just worked perfectly.

I still use Wordperfect office for DOS at home because it does everything
I want. I can even load work excel docuemtns (after converting) and work
from home using dos.

Shawn

... "Be careful and have a good time!" (Mothers' paradox curse)
___ Blue Wave/386 v2.30
--- SBBSecho 3.20-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/700)

Tiny wrote to GAMGEE <=-

Quoting Gamgee to Digital Man <=-

reason, and I know that MANY Point-of-Sale devices/systems still run
good old MSDOS. Not worth the effort/expense to update those systems,
and they're reliable.

I ran a MSDOS program for inventory / invoicing when I ran my
business and it just worked perfectly.

I still use Wordperfect office for DOS at home because it does
everything I want. I can even load work excel docuemtns (after converting) and work from home using dos.

Sweet!



... Gone crazy, be back later, please leave message.
=== MultiMail/Linux v0.52
--- SBBSecho 3.20-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (21:2/138)

On 11 Apr 2024 at 11:24p, claw pondered and said...

On 11 Apr 2024, Digital Man said the following...

The problem is in the softare, not "the system". The system can be 64-bit and still have plenty of 32-bit time_t use lurking in its software. Y2K38 is definitely going to blow some shit up (figurativel if not literally). --

Well I will have to read more about it. If its software then Why isn't this fixed already. Guess I will have to ready about it to know why its not simple.

For the simple reason that software rots if left unattended
for a long time. Very few programs require _no_ maintenance
as the world around them evolves.

There's a lot of software out there, written 20 or 30 years
ago, that made a lot of assumptions about the state of the
world; there were a lot of programmers who thought to
themselves in 1991, "Gee, the year 2038 is a long time from
now..." and took shortcuts. In some cases, the source code
has been lost, or orphaned, or the programmer has even died;
consider Spitfire BBS, as an example: Mike Woltz passed away
a year or so ago. It's unlikely that anyone will ever see
the Spitfire source code. Or consider all of those unattended
little boxes with a microprocessor in them running some
ancient unpatched version of an operating system, that no
one bothers to update because either they can't, or no one
feels the need to do so.

The same thing happened with Y2K, and occasionally we _still_
kick up a Y2K bug turning over some software rock.

It's not that we _can't_ fix it in software, it's that it's
actually a really big job, and no one has done the work yet.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: Operating Systems
By: tenser to claw on Sat Apr 13 2024 02:39 am

There's a lot of software out there, written 20 or 30 years
ago, that made a lot of assumptions about the state of the
world; there were a lot of programmers who thought to
themselves in 1991, "Gee, the year 2038 is a long time from
now..." and took shortcuts.

Speaking for myself at least, I started using time_t types for storing dates and times in C programs in 1988 and wasn't even aware that it would ever roll-over (go negative) at any point. I don't think I actually realized that most time_t's are signed (can go negative) and that for those systems (C libraries), dates before Jan-1-1970 are *suppoosed* to representable in that way (as negative valeus). [libraies that use unsigned time_t's cannot represent dates before Jan-1-1970] And I'm pretty sure it was 1992 when I did the math and realized that 2038 and 2106 are going to be problematic years for 32-bit time_t-based libraries/programs. It was certainly not discussed in the programming books or among C programmers of the era. We weren't taking shortcuts, we were just following the norms. Use of 64-bit integers for most things seemed excessive/wasteful and in many environments (e.g. 16-bit systems) not practical or even possible.
--
digital man (rob)

Steven Wright quote #32:
The colder the x-ray table, the more of your body is required to be on it. Norco, CA WX: 57.0øF, 82.0% humidity, 4 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

On 2024-04-10 3:55 Nightfox said...

I wonder how many people will be using ARM-based Wnidows machines though.
I've heard of Microsoft working on that, but at least right now, I haven't seen anyone using an ARM Windows machine, either at work or for personal use.

This might change with the recent Chineese ban on the use of non-chineese processors. The cores Huawei etc. use to mass produce processors are ARM.
I guess we will soon see a lot of personal laptops based on ARM produced for chineese market, that will eventually spread to other markets.

--
smk
--- ENiGMA 1/2 v0.0.14-beta (linux; x64; 20.11.1)
* Origin: X65.zone (21:1/222)

Gamgee wrote to Tiny <=-

I still use Wordperfect office for DOS at home because it does
converting) and work from home using dos.

Sweet!

Just what I got used to, and my fingers just know what keys to hit
without using menus.

At work I'm stuck with M$ office, so I'm slowly getting used to that
and will probably end up scrapping my dos setup eventually.

Shawn


... Forgive your enemies but never forget their faces

--- MultiMail/Linux v0.52
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/700)

On 12 Apr 2024 at 11:29a, Digital Man pondered and said...

Re: Re: Operating Systems
By: tenser to claw on Sat Apr 13 2024 02:39 am

There's a lot of software out there, written 20 or 30 years
ago, that made a lot of assumptions about the state of the
world; there were a lot of programmers who thought to
themselves in 1991, "Gee, the year 2038 is a long time from
now..." and took shortcuts.

Speaking for myself at least, I started using time_t types for storing dates and times in C programs in 1988 and wasn't even aware that it
would ever roll-over (go negative) at any point. I don't think I
actually realized that most time_t's are signed (can go negative) and
that for those systems (C libraries), dates before Jan-1-1970 are *suppoosed* to representable in that way (as negative valeus). [libraies that use unsigned time_t's cannot represent dates before Jan-1-1970] And I'm pretty sure it was 1992 when I did the math and realized that 2038
and 2106 are going to be problematic years for 32-bit time_t-based libraries/programs. It was certainly not discussed in the programming books or among C programmers of the era. We weren't taking shortcuts, we were just following the norms. Use of 64-bit integers for most things seemed excessive/wasteful and in many environments (e.g. 16-bit systems) not practical or even possible. --

Using time_t was less the "shortcut" issue that I was thinking
of, and more people doing things like casting back and forth
between various int types. Disciplined use of `time_t`, and
not making a lot of assumptions about size of that type, makes
the problem tractable in programs for which one has the source.

The VMS people warned us about this a long time ago; certainly
in the 80s. DEC engineering famously had a bug that they kept
open that said something like, "VMS dates won't work after the
year 9999."

I distinctly remember people talking about 2038 in the runup
to Y2K and the consensus was mostly, "meh, we'll fix it before
then." In the 32-bit era, we had more pressing issues, like
running out of address space, or the UID space rolling over on
big installations.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)