I read somewhere that date functions in some C++ libraries will fail after 2038.
I have tested DOSBox 0.74 Win32 and it fails to load after 18 Jan 2038.
Will Synchronet work after the year 2038 ?
Synchronet for Windows and *nix is built with 64-bit time_t, so no problem with year 2038 (or 2106), for those platforms. Some of the older versions (maybe 3.14 and earlier, I'd have to check) might have some issues in 2038. Sysops should have upgraded or died by then. :-)
Some file formats still use a 32-bit time_t though... there's a time32_t still in use.
Hopefully we'll have eliminated those before then though.
The official BBS FAQ says that those improvements are scheduled for version 4.
I read somewhere that date functions in some C++ libraries will fail after 2038.
I have tested DOSBox 0.74 Win32 and it fails to load after 18 Jan 2038.
Will Synchronet work after the year 2038 ?
Quoting Deuce to Digital Man <=-
Re: Synchronet after 2038
By: Digital Man to Dran Draggore on Sat Apr 16 2016 10:05 pm
Synchronet for Windows and *nix is built with 64-bit time_t, so no problem with year 2038 (or 2106), for those platforms. Some of the older versions (maybe 3.14 and earlier, I'd have to check) might have some issues in 2038. Sysops should have upgraded or died by then. :-)
Some file formats still use a 32-bit time_t though... there's a
time32_t still in use.
Hopefully we'll have eliminated those before then though.
-!-
þ Synchronet þ The future of BBSing
Re: Synchronet after 2038
By: Digital Man to Dran Draggore on Sat Apr 16 2016 10:05 pm
Synchronet for Windows and *nix is built with 64-bit time_t, so no problem with year 2038 (or 2106), for those platforms. Some of the older versions (maybe 3.14 and earlier, I'd have to check) might have some issues in 2038. Sysops should have upgraded or died by then. :-)
Some file formats still use a 32-bit time_t though... there's a time32_t still in use.
Hopefully we'll have eliminated those before then though.
Spacesst wrote to DEUCE <=-
Not Every Body use 64 Bit Computer , bbsing still use 32/16 bit computer
this Will Conflic ??
Not Every Body use 64 Bit Computer , bbsing still use 32/16 bit
computer
this Will Conflic ??
22 years is an eternity in computing. I almost never use 16 bit software today. Most is 32 bit, and I've used a lot of 64 bit software, especially on Linux, where I've run at least one 64 bit system for several years now. At home, mostly 32 bit (the BBS is running on a Pi 1B+), and of course, most Windows application software is still 32 bit, though all my desktops run a 64 bit Windows OS (another reason I almost never use 16 bit apps!).
Not Every Body use 64 Bit Computer , bbsing still use 32/16 bit
computer
this Will Conflic ??
22 years is an eternity in computing. I almost never use 16 bit software today. Most is 32 bit, and I've used a lot of 64 bit software, especially on Linux, where I've run at least one 64 bit system for several years now. At home, mostly 32 bit (the BBS is running on a Pi 1B+), and of course, most Windows application software is still 32 bit, though all my desktops run a 64 bit Windows OS (another reason I almost never use 16 bit apps!).
In the BBS world though, hopefully we (sysops) will still have a fairly easy way to continue running all of our favorite door games, many of which are 16- bit DOS software which has since been abandoned. I know there's already a way to run DOS doors in Linux with Synchronet (using dosemu, I believe), but I think it's more difficult in Windows.
22 years is an eternity in computing. I almost never use 16 bit software today. Most is 32 bit, and I've used a lot of 64 bit software, especially on Linux, where I've run at least one 64 bit system for several years now. At home, mostly 32 bit (the BBS is running on a Pi 1B+), and of course,
most Windows application software is still 32 bit, though all my desktops run a 64 bit Windows OS (another reason I almost never use 16 bit apps!).
Nightfox wrote to Tony Langdon <=-
In the BBS world though, hopefully we (sysops) will still have a fairly easy way to continue running all of our favorite door games, many of
which are 16- bit DOS software which has since been abandoned. I know there's already a way to run DOS doors in Linux with Synchronet (using dosemu, I believe), but I think it's more difficult in Windows. But in
22 years, perhaps a solution will come along to make it easier.
Digital Man wrote to Nightfox <=-
In my opinion, running DOS doors on Windows (32-bit) is much easier
than running them on Linux/DOSemu. FWIW,
Mro wrote to Tony Langdon <=-
it's an eternity, eh?
well you are speaking with bbs people and we use a lot of 16bit
programs. ---
In the BBS world though, hopefully we (sysops) will still have a
fairly easy way to continue running all of our favorite door games,
many of which are 16- bit DOS software which has since been abandoned.
I know there's already a way to run DOS doors in Linux with Synchronet
(using dosemu, I believe), but I think it's more difficult in Windows.
In my opinion, running DOS doors on Windows (32-bit) is much easier than running them on Linux/DOSemu. FWIW,
In the BBS world though, hopefully we (sysops) will still have a
fairly easy way to continue running all of our favorite door games,
many of which are 16- bit DOS software which has since been abandoned.
I know there's already a way to run DOS doors in Linux with Synchronet
(using dosemu, I believe), but I think it's more difficult in Windows.
In my opinion, running DOS doors on Windows (32-bit) is much easier than running them on Linux/DOSemu. FWIW,
I agree. I was just thinking that in the future, if one wanted/needed to use a 64-bit edition of Windows, hopefully there will eventually be a fairly easy way to run DOS doors on it. I imagine a 64-bit OS would be required to make use of a replacement for the 32-bit time_t that Deuce mentioned, but I'm not 100% sure if that's true.
Digital Man wrote to Nightfox <=-
In my opinion, running DOS doors on Windows (32-bit) is much easier than running them on Linux/DOSemu. FWIW,
no 32 bit Windows systems here. They're all either Linux or 64 bit
Windows. :)
Mro wrote to Tony Langdon <=-
it's an eternity, eh?
well you are speaking with bbs people and we use a lot of 16bit programs. ---
Some do, some don't. :P
Nightfox wrote to Digital Man <=-
I agree. I was just thinking that in the future, if one wanted/needed
to use a 64-bit edition of Windows, hopefully there will eventually be
a fairly easy way to run DOS doors on it. I imagine a 64-bit OS would
be required to make use of a replacement for the 32-bit time_t that
Deuce mentioned, but I'm not 100% sure if that's true.
I agree. I was just thinking that in the future, if one wanted/needed
to use a 64-bit edition of Windows, hopefully there will eventually be
a fairly easy way to run DOS doors on it. I imagine a 64-bit OS would
be required to make use of a replacement for the 32-bit time_t that
Deuce mentioned, but I'm not 100% sure if that's true.
No, a 64-bit OS is not required for a 64-bit time_t. Even 16-bit programs (and OSes) could use a 64-bit time_t, if they so choose (if they even have the concept of unix time and a time_t to begin with).
Nightfox wrote to Tony Langdon <=-\
In the BBS world though, hopefully we (sysops) will still have a fairly easy way to continue running all of our favorite door games, many of
which are 16- bit DOS software which has since been abandoned. I know there's already a way to run DOS doors in Linux with Synchronet (using dosemu, I believe), but I think it's more difficult in Windows. But in
22 years, perhaps a solution will come along to make it easier.
Synchronet for Windows and *nix is built with 64-bit time_t, so no problem with year 2038 (or 2106), for those platforms. Some of the older versions (maybe 3.14 and earlier, I'd have to check) might have some issues in 2038. Sysops should have upgraded or died by then. :-)
Some file formats still use a 32-bit time_t though... there's a time32_t still in use.
Hopefully we'll have eliminated those before then though.
Not Every Body use 64 Bit Computer , bbsing still use 32/16 bit computer this Will Conflic ??
Re: Synchronet after 2038
By: Deuce to Digital Man on Mon Apr 18 2016 02:41 am
> Re: Synchronet after 2038
> By: Digital Man to Dran Draggore on Sat Apr 16 2016 10:05 pm
>
> > Synchronet for Windows and *nix is built with 64-bit time_t, so no
> > problem with year 2038 (or 2106), for those platforms. Some of the older
> > versions (maybe 3.14 and earlier, I'd have to check) might have some
> > issues in 2038. Sysops should have upgraded or died by then. :-)
>
> Some file formats still use a 32-bit time_t though... there's a time32_t
> still in use.
That true, but in the files, they're treated as unsigned 32-bit values, so 2106
would be the year of demise, not 2038.
> Hopefully we'll have eliminated those before then though.
Sure. I'll get right on that. :-)
In the BBS world though, hopefully we (sysops) will still have a fairly easy way to continue running all of our favorite door games, many of
which are 16- bit DOS software which has since been abandoned. I know there's already a way to run DOS doors in Linux with Synchronet (using dosemu, I believe), but I think it's more difficult in Windows. But in
22 years, perhaps a solution will come along to make it easier.
In the BBS world though, hopefully we (sysops) will still have a
fairly easy way to continue running all of our favorite door games,
many of which are 16- bit DOS software which has since been
abandoned. I know there's already a way to run DOS doors in Linux
with Synchronet (using dosemu, I believe), but I think it's more
difficult in Windows.
In my opinion, running DOS doors on Windows (32-bit) is much easier
than running them on Linux/DOSemu. FWIW,
In the BBS world though, hopefully we (sysops) will still have a
fairly easy way to continue running all of our favorite door games,
many of which are 16- bit DOS software which has since been
abandoned. I know there's already a way to run DOS doors in Linux
with Synchronet (using dosemu, I believe), but I think it's more
difficult in Windows. But in 22 years, perhaps a solution will come
along to make it easier.
I have bbs running in a VM which sits on a windows 64bit os. The VM is an XP os and all works fine. So when not messing with the bbs I minimize the VM and work on the 64bit windows os.
That is one way around having a Windows 64bit os and having a bbs. The VM is by oracle
Just my .02
IIRC, ZModem uses a 32-bit time_t for example, so ZModem will stop transferring the correct file date (YModem will continue to work).
Message bases use a 32-bit time_t as well as I recall.
A lot of little fixes will end up being needed, as well as a few backward incompatible ones... which is why we're slowly moving from time32_t to time_t. At the end of it all, if the C compiler and library continue to use a 32-bit time_t, everything will remain broken though.
| Sysop: | MCMLXXIX |
|---|---|
| Location: | Prospect, CT |
| Users: | 325 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 04:57:30 |
| Calls: | 510 |
| Messages: | 220570 |