Hacker News Reader

Comment by ecalifornica | Hacker News Reader

San Francisco Bay Area Rapid Transit (BART) scrounges around for hardware to run Windows 98: https://news.ycombinator.com/item?id=32884814

> When a BART car runs into trouble, Shawn Stange steps back in time. He pops open a circa-2000 IBM Thinkpad running Windows 98 and opens a portal into the train’s brain — the Automated Train Control system — through the DOS computer language.

> Stacks of vintage laptop carcasses are common at BART warehouses. The train software is so old it won’t work on modern computers.

Reminds me of the software archeology in Vernor Vinge's A Deepness in the Sky.

View on HN

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)

It should run on a VM though.

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"

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.

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.

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:-)

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.

I don’t know about the German windows 3.11 thing, but Bart uses ancient Siemens PLCs if I remember correctly.

I doubt there is any logic running in windows 98, but there will be PLCs that interface to old laptops for updating the logic of control systems, probably with proprietary dongles and licenses tied to specific laptops. Can you technically get that stuff working in wine? Probably. Can you do it legally, responsibly and without assuming a lot of liability? Probably not.

Even if the trains have been upgraded, there will be a ton of tendrils reaching into old PLCs from other equipment like train washes, maintenance equipment, etc that interface to the overall system somehow and it would be forbidden and unwise for any individual to start inventing new ways to update the software without an actual project in place to replace the PLC of whatever you’re working on.

> San Francisco Bay Area Rapid Transit (BART) scrounges around for hardware to run Windows 98: https://news.ycombinator.com/item?id=32884814

At this point I believe all the original 50-yr old rolling stock has been retired and only the new cars are operating. It would surprise me if the news ones have the win98 dependency.

For regular service yes, but I've heard that sometimes they pull out the old cars for some reason.

> through the DOS computer language

Oh yes, that DOS computer language. Bill Gates was fluent in that language.

Totally makes me trust everything else in that article even more.

Ah yes, the good old DOS computer language, now that was a great thing…

The DOS CLI has a syntax

Reply on news.ycombinator.com