Hacker News Reader

Comment by TaylorAlexander | Hacker News Reader

I wonder if the software would run on WINE. When they say “it won’t run on modern computers” I feel like what they mean is that you can’t buy a Windows 11 laptop from Best Buy and then run Windows 98 software as if it was a modern windows binary. But any modern computer can emulate a computer from the 1990’s one way or another. (Yes I know WINE is not an emulator but you get my meaning)

View on HN

Sometimes you really need the old hardware. A few years ago I was called in to help out a company that couldn't get 30 year old embedded code for an industrial PC platform running on modern replacement hardware. With my trusty old MS-DOS V2.11 version of DEBUG.COM I eventually managed to break into the hard loop I suspected the code was stuck in, to trace and disassemble it. It was communications code to talk to OG PC Uart hardware. For reasons best known to God or at least someone who probably retired 20 years ago they were using a scratchpad register in one of the chips instead of a byte of RAM to hold a timing variable to implement a delay/timeout. The modern [ASIC/FPGA/System on a chip/I don't know what] that was emulating the collection of OG PC hardware chips didn't bother providing that scratchpad register. A little big of creative assembly language rework and voila, the system worked like a charm. I really felt like invoicing for $10,000 or something ridiculous instead of 4 hours at my usual very reasonable hourly rate :-)

10? Try 50 next time.

$10000 would be extremely reasonable for such a fix, not ridiculous. You single handedly decoupled the software from dying hardware!

Sounds awesome! Need an apprentice?

Ha ha, I don't think there's much of a career to be had in being able to keep 16 bit MS-DOS software binaries with no source code running unfortunately:-)

There are some things Wine doesn't do. Last time I checked, it didn't fully implement DCOM, so it couldn't be used for OPC (OLE for Process Control) and similar. And the use case in the parent comment might need Windows 98 because (other than Windows ME which everyone pretends didn't exist) it was the last DOS-based version of Windows; AFAIK, Wine does have some MS-DOS emulation, but it's limited to what some Windows 3.x software might need.

Wine can use Windows' DLL's just fine.

Unless they use the bits of DCOM where Wine's DCOM implementation isn't quite compatible with Microsoft's, which was the OP's point.

By using Microsoft's DCOM implementation ("the Windows DLLs"), you bypass using Wine's DCOM entirely.

you can always contract codeweavers for it to do more.

Certification is a major issue here.

The computer that connects to the train system needs certification for its OS? I can understand the onboard controller needing certification, but a remote machine just connecting to it for configuration?

We know WINE is janky enough to be unlikely, "certification" is hand-waving in the general direction of "thankfully, there's opportunities for people outside an impulsive individual contributor to step in front of that"

Software could, but hardware probably won't.

These kinds of computers usually have customized ISA boards that aren't even PnP compatible. Software for that kind of hardware doesn't use drivers. Hardware is directly accessed from software, like you would do on a bare-metal microcontroller. Modern OSs like Linux and anything WinNT/2000/+ won't allow this, but Win311 in real mode does.

It should run on a VM though.

WINE is an emulator for 16-bit binaries.

First, WINE = Wine Is Not an Emulator. And it's not an emulator, the PE code runs directly on the host CPU. All you really need to implement is the OS API (on Windows the official API is with DLLs, such as KERNEL32.DLL, which in turn issue syscalls, and you're not generally supposed to do syscalls yourself).

Second, it runs 32 bit and even 64 bit too.

Missed the point. Wine runs Win16 binaries on 32- and 64-bit hosts, effectively by rethunking them to run in 32-bit mode. This can be viewed as a form of emulation.

Wine 9.0 can likewise rethunk 32-bit applications to run in 64-bit mode, but this is only the default on Mac OS X (where Apple removed 32-bit support), because it still introduces more compatibility problems on Linux than just running 32-bit code natively. (And thunking Win16 to 64-bit mode is not yet done.)

I'm not familiar with what exactly Wine does to run 32-bit code under OS X, but it would already have to do emulation / binary translation. Because some opcodes have been repurposed for the REX prefix in 64-bit mode, and any absolute 32-bit address would be interpreted as relative to RIP instead.

And 16-bit would be completely impossible, first there's the default operand size and then the completely different encoding for memory addressing.

But it does emulate the 16-bit x86 instructions from really old-school Windows code.

No it doesn't. 16-bit protected mode code will run natively even on 64-bit kernels - and there is a system call that can create the segment descriptors needed for that: https://man7.org/linux/man-pages/man2/modify_ldt.2.html

KERNEL32 is mainly implemented through calls to NTDLL. NTDLL is the one that triggers the actual system calls or thunks, the actual implementation is in NTOSKRNL.exe

Meanwhile USER32 used to do system calls to Win32k, but then they changed it to call Win32U, and have Win32U be all system calls to Win32k.

Reply on news.ycombinator.com