C++Builder 6 cannot compile anything past Y2K38

[Arceml]

Hello everyone,

I am usually a lurker on this forum as I still use Windows 7 Ultimate as my daily driver (except for stuff that needs the internet) and this community has helped me out in many ways. However in this particular case I cannot find a single thread anywhere here nor anywhere online for that matter so I'm posting here in the hopes someone can help. Also I understand this is way ahead of schedule since Y2K38 happens in 2038 but I figured might as well run some tests on my 32bit software now so I won't get blindsided by this problem a decade later because I tend to forget easily.

So far, Borland C++Builder 6 Enterprise has been the only 32bit program that I use that from my tests continuously gives me trouble. Before Y2K38, C++Builder can easily compile my programs without issue or fuss, however when the time is reached it no longer can, providing the error message below:


Anyone who still uses this ancient program for their software projects, or anyone knowledgeable on this - is there anything I can do to resolve this issue? I really do not want to get something new or different if I can absolutely help it as I use this program a lot.

I am running tests on it in a Windows 7 Ultimate 64bit VirtualBox VM on my linux machine. But I have successfully replicated this error on VMWare on my main machine and on bare metal on an old Thinkpad T520 that I sold to a friend.

Any help would be greatly appreciated!

 

[Alejandro85]

I don't use it personally, but it seems from your description and screenshots that the compiler itself has is subject to the Y2K38 bug somehow and it crashes because of that (if the only difference between a successful build and a crash is the system date).

There is little you can do if that's the case, sort of debugging the compiler, spot the bug and try to patch it (whose technical difficulty is far above just a compilation, and the legallity of that is questionable). The best option is to try to upgrade to a newer version, hoping the developers have fixed it already (it doesn't need to be the last one, just new enough to avoid the bug).

If there isn't a new version available, or you don't really want to update to them, there could be a few options.
To me, the most likely cause why a compiler even needs to work the system date is to put a timestamp on the compiled executable. A way to workaround that is to use reproducible builds that fundamentally always output the same binary from the same code, implying that they're not timestamped, thus the compiler won't need the system date at all.
Whether or not your particular compiler supports that is beyond me.

The obvious radical solution would be to change the system date to something earlier before compiling, thus avoiding the bug. It of course becomes tedious over time and the binary timestamps would get crippled that way. Another option would be to use some kind of system patch to return a fixed date to the compiler, without changing the full system.

There is another problem going 13 years into the future.
That version of the compiler, from what I've read, is 32 bit only and probably cannot generate 64 bits binaries. 64 bit could easily bypass the Y2K38 problem, but also could as well become mandatory by that point, forcing you to update by the mere fact that the binaries it produces might not run in operating systems 13 years from now.

As we stand, just in the Windows world, Windows stopped making 32 bits OSs for the server market with Windows 7, and the release of Windows 11 was the first 64 bits only workstation OS. While both still have support for 32 bits programs, that might be dropped in some future version (as it already happened to 16 bits programs in 64 bits OSs).
Linux also went this way on their major distributions, as now all most known ones are releasing only 64 bits versions.
Even MacOS dropped support for 32 bits.
So you may need, by that point, consider upgrading your programs to 64 bits because of obsolescence dictated by OS support rather than a compiler bug. There is still plenty of time, but personally, that's the route I would follow, or at least, make sure your programs are still able to run in the newest version of Windows as they're released, and be prepared to switch to something else if the stop to be.