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)

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)