• Operating Systems

    From Utopian Galt@21:4/108 to All on Fri Apr 5 21:33:44 2024
    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)
  • From Digital Man to Utopian Galt on Fri Apr 5 22:44:45 2024
    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
  • From Nightfox@21:1/137 to Utopian Galt on Sat Apr 6 09:48:50 2024
    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)
  • From poindexter FORTRAN@21:4/122 to Utopian Galt on Sat Apr 6 10:11:00 2024
    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)
  • From Shurato@21:2/148 to Nightfox on Sat Apr 6 14:16:00 2024

    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)
  • From Ogg@21:4/106.21 to poindexter FORTRAN on Sat Apr 6 17:55:00 2024
    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)
  • From poindexter FORTRAN@21:4/122 to Ogg on Sun Apr 7 08:38:00 2024
    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)
  • From poindexter FORTRAN@21:4/122 to Nightfox on Sun Apr 7 08:42:00 2024
    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)
  • From Nightfox@21:1/137 to poindexter FORTRAN on Sun Apr 7 14:00:26 2024
    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)
  • From tenser@21:1/101 to Nightfox on Mon Apr 8 11:48:40 2024
    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)
  • From tenser@21:1/101 to poindexter FORTRAN on Mon Apr 8 12:43:04 2024
    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)
  • From Nightfox@21:1/137 to tenser on Sun Apr 7 18:27:55 2024
    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)
  • From Exodus@21:1/144 to Nightfox on Sun Apr 7 22:35:26 2024
    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)
  • From AKAcastor@21:1/162 to Tenser on Sun Apr 7 20:02:50 2024
    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)
  • From apam@21:1/101 to Nightfox on Mon Apr 8 16:21:42 2024

    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)
  • From fusion@21:1/616 to apam on Mon Apr 8 01:33:50 2024
    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)
  • From tenser@21:1/101 to Nightfox on Tue Apr 9 00:06:01 2024
    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)
  • From tenser@21:1/101 to AKAcastor on Tue Apr 9 00:08:58 2024
    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)
  • From claw@21:1/210 to Utopian Galt on Mon Apr 8 07:53:23 2024
    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)
  • From Blue White@21:4/134 to Exodus on Mon Apr 8 08:07:24 2024
    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)
  • From tenser@21:1/101 to claw on Tue Apr 9 01:38:25 2024
    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)
  • From tenser@21:1/101 to Blue White on Tue Apr 9 01:39:23 2024
    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)
  • From fusion@21:1/616 to tenser on Mon Apr 8 12:03:35 2024
    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)
  • From Nightfox@21:1/137 to tenser on Mon Apr 8 09:07:24 2024
    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)
  • From apam@21:1/182.1 to Nightfox on Tue Apr 9 07:17:13 2024
    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)
  • From Utopian Galt@21:4/108 to Apam on Mon Apr 8 19:27:58 2024
    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)
  • From Blue White@21:4/134 to tenser on Tue Apr 9 07:51:26 2024
    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)
  • From Digital Man to poindexter FORTRAN on Tue Apr 9 15:27:18 2024
    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
  • From tenser@21:1/101 to Nightfox on Thu Apr 11 00:15:26 2024
    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)
  • From tenser@21:1/101 to Blue White on Thu Apr 11 00:19:39 2024
    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)
  • From fusion@21:1/616 to tenser on Wed Apr 10 12:17:21 2024
    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)
  • From Nightfox@21:1/137 to fusion on Wed Apr 10 10:55:12 2024
    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)
  • From tenser@21:1/101 to fusion on Thu Apr 11 06:20:00 2024
    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)
  • From tenser@21:1/101 to Nightfox on Thu Apr 11 06:23:58 2024
    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)
  • From niter3@21:1/199 to Nightfox on Wed Apr 10 14:35:35 2024
    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)
  • From fusion@21:1/616 to tenser on Wed Apr 10 16:06:30 2024
    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)
  • From Digital Man to claw on Wed Apr 10 14:56:24 2024
    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
  • From tenser@21:1/101 to fusion on Thu Apr 11 13:04:11 2024
    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)
  • From Nightfox@21:1/137 to tenser on Wed Apr 10 18:16:45 2024
    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)
  • From Nightfox@21:1/137 to niter3 on Wed Apr 10 18:17:43 2024
    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)
  • From Digital Man to tenser on Wed Apr 10 22:47:28 2024
    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
  • From tenser@21:1/101 to Nightfox on Fri Apr 12 00:05:11 2024
    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)
  • From tenser@21:1/101 to Digital Man on Fri Apr 12 00:12:49 2024
    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)
  • From claw@21:1/210 to Digital Man on Thu Apr 11 07:52:34 2024
    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)
  • From Digital Man to tenser on Thu Apr 11 11:13:44 2024
    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
  • From Digital Man to claw on Thu Apr 11 11:15:19 2024
    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
  • From Shurato@21:2/148 to claw on Thu Apr 11 13:00:00 2024

    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)
  • From Gamgee@21:2/138 to Digital Man on Thu Apr 11 14:29:00 2024
    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)
  • From tenser@21:1/101 to Digital Man on Fri Apr 12 08:17:39 2024
    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)
  • From claw@21:1/210 to Digital Man on Thu Apr 11 23:24:24 2024
    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)
  • From claw@21:1/210 to Shurato on Thu Apr 11 23:25:15 2024
    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)
  • From Digital Man to claw on Thu Apr 11 23:52:49 2024
    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
  • From Digital Man to claw on Thu Apr 11 23:54:44 2024
    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
  • From Tiny@21:1/700 to GAMGEE on Fri Apr 12 06:28:00 2024
    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)
  • From Gamgee@21:2/138 to Tiny on Fri Apr 12 07:31:00 2024
    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)
  • From tenser@21:1/101 to claw on Sat Apr 13 02:39:12 2024
    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)
  • From Digital Man to tenser on Fri Apr 12 11:29:20 2024
    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
  • From smokku@21:1/222 to Nightfox on Sat Apr 13 08:17:22 2024

    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)
  • From Tiny@21:1/700 to Gamgee on Sat Apr 13 08:39:00 2024
    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)
  • From tenser@21:1/101 to Digital Man on Wed Apr 17 02:43:36 2024
    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)