I bet that the timecard application was a 16 bit executable. 32 bit Windows was able to run 16 bit executables using the NT Virtual DOS Machine (NTVDM), but 64 bit Windows couldn't.
Wine is however able to run 16 bit executables on 64 bit hosts using their version of NTVDM.
This is one of the rare use cases where Wine on Windows actually makes sense - you can build it under SFU/SUA, or at least you used to be able to. (I never managed to get FreeType working, so messages weren't sized properly for dialogue boxes, but it was enough to do what I needed).
Not rare at all! If you work with older games, you often will struggle to get the correct version of direct3D to work on Windows 11. Most of those games start first try in Wine on Windows.
You are right that Windows 7 x64 is unable to run 16-bit applications but I suspect it would have been far easier to do a Windows 7 x86 installation than Ubuntu VM + Wine per PC.
And I honestly never understood this apart from Microsoft wanting to finally kill Win16: after all, it’s not like V86 mode (whose absence in x86-64 is the official justification) is actually required—non-x86 versions of NT had perfectly serviceable Win16 support through the extremely expected approach of having a full PC emulator inside[1]. (Some even extremely briefly had x86 Win32 support[2], but that wasn’t resurrected for Windows for ARM either, perhaps because the sheer amount of stuff in the system has grown so much since that time.)
Mind you, the decision was made with the release of (I think) Windows XP for x86-64, in 2005. I actually briefly used a computer with Windows 3.11 on it around that time (oh the wonders of school IT). I’m not saying Microsoft’s decision was wrong, though, only that the official rationale is kind of bullshit.
... I’m trying to imagine how one’d handle interrupts in this setup, and it sounds kind of terrifying. Reprogram the LAPIC each time? Carefully code the interrupt entry to work as both 32- and 64-bit code to determine if it needs to switch back? Ouch.
You don't need to use the same IDT as in long mode. Just have a 32-bit one that decides whether to handle an interrupt (e.g. vm86 traps/emulation) or re-enable long mode and forward it to the 64-bit handler.
But you don't have to imagine -- early amd64 Linux could do it, and there was a patch floating around that kept that feature all the way to 2.6.2x series.
Wine is however able to run 16 bit executables on 64 bit hosts using their version of NTVDM.