But door games will only be a memory in 14 years with the 2038 problem.
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.
Utopian Galt wrote to All <=-
I would like to migrate to Linux. Windows 32 bit will be negated eventually.
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 doorgames.
But door games will only be a memory in 14 years with the 2038problem.
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.
What I think is interesting about Microsoft is that while they move
everything to a subscription model (including, apparently
Windows itself)...
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?
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 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 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
I thought the 2038 problem was a unix time_t issue?
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 you whole OS and other apps thinking it was 1989 or something.
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.
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'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.
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.
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.
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'm not sure that would be a good solution though, as you wouldn'twant you
whole OS and other apps thinking it was 1989 or something.
Yeah, BRE would lose it's mind! ;)
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?
I'm not sure that would be a good solution though, as you wouldn'twant 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. ;)
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.
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.
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..
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.
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?
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.
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..
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.
Very likely that, in 2038, they'll be running win32 under an
emulator as well.
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..
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..
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.
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.
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.
Whats the 2038 Problem?
there's a reason i quoted what i did and what i didn't. my post isn't about dos support at all.
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.
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.
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.
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>
https://en.wikipedia.org/wiki/Year_2038_problem
AKA the "Epochalypse".
--
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
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???
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???
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.
There are other differentiating features beyond performance and
power consumption, that keep some of these non-ARM architectures
thriving, believe it or not. :-)
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. :-)
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)
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').
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.
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. :)
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.
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.
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.
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.
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.
Gamgee wrote to Tiny <=-
I still use Wordperfect office for DOS at home because it does
converting) and work from home using dos.
Sweet!
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. --
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,042 |
Nodes: | 15 (1 / 14) |
Uptime: | 00:13:44 |
Calls: | 500,352 |
Calls today: | 25 |
Files: | 95,205 |
D/L today: |
21,185 files (2,808M bytes) |
Messages: | 465,990 |
Posted today: | 3 |