Comment by andix
4 hours ago
I've also helped running an old Windows 3.1 accounting software. It runs perfectly fine on Windows XP inside a VM.
In 2020 it suddenly came to a halt, because the date pickers just couldn't go further than 2019. Nobody seemed to care in 1992 when it was released.
It was really easy to de-compile the Visual Basic 3 software (perfectly legal where I live). My first idea was to get the source cleaned up a bit and compile it again to 32 bit with Visual Basic 4, but I couldn't figure it out, it required some 3rd party libraries that I just couldn't get a hold of.
In the end I just changed the number 2019 in the binary to 2059 in a hex editor, and it just worked. There was only one occurrence of the number 2019 in the whole binary. I guess I got really lucky.
Edit: It seems like Windows and Visual Basic are not affected by the Unix 2038 problem at all. 16 bit Windows seems to be fine until the year 2107.
> My first idea was to get the source cleaned up a bit and compile it again to 32 bit with Visual Basic 4, but I couldn't figure it out, it required some 3rd party libraries that I just couldn't get a hold of.
This was super common for VB apps. The original architecture of VB was, loosely speaking, a GUI container for various pluggable controls connected to a BASIC runtime. The number of controls that came in the box would vary depending on how fancy a version of VB you bought, and you could plug in additional third party controls in the form of "VBX's" - Visual Basic eXtensions. Even though VBX's were designed mainly for GUI controls, they were the easiest extension point for VB and got extensively used for all sorts of integrations until OLE Automation became more prevalent. (Roughly contemporaneous with the switch to 32-bit.)