Running Alpha NT programs on x86 Windows

[CaptainWillStarblazer]

I don't know if this belongs more in the Vintage Computer Software section, but for the first time, it has become possible to run (a select few, buggy) Windows NT for Alpha programs on x86. As you may know, there was a way to run x86 Win32 programs on Alpha via FX!32, but the opposite was never possible (nor is there presently a DEC Alpha system emulator capable of booting Windows NT), until now, via my project, EmuWoW. EmuWoW supports both the MIPS and Alpha architectures, and is capable of running a few simple apps for both.

EmuWoW can be found here: https://github.com/BHTY/EmuWoW and was even featured on VirtuallyFun, the blog post from which has surfaced on HN and some other tech news aggregators. I don't know if this is the right place to promote such a project but I was hoping I'd be able to gauge interest among DEC enthusiasts.

 

[ajacocks]

This is really cool @CaptainWillStarblazer . How long have you been working on this?

- Alex

 

[CaptainWillStarblazer]

This is really cool @CaptainWillStarblazer . How long have you been working on this?

- Alex

Thanks so much. I've been working on the project on-and-off since August. When I started the project in August, it was actually using a home-built 386 emulator and could only run x86 apps (the most advanced thing it could run was Reversi). In November, I picked it back up again, got enough working to make WinMine work, and then wrote a MIPS emulator and gave it support for simple MIPS executables. In January, I adapted MAME's MIPS emulator, which improved it further, and now, I've added some early Alpha support, which is why it's the most primitive right now.

One thing that would be a big help from anyone with an Alpha is if someone could build Reversi for Alpha for me. I have the source files (it was a Win32 SDK sample) here. All you need to do is extract the files and then type nmake reversi.mak in the Reversi directory. You'd need some Microsoft C/C++ compiler, but I think any version of Visual C++ from 1.0 to 6.0 should do just nicely. Earlier compiler version is better, if possible.

 

[neozeed]

It’s so cool it went from being home brew mips only a few months ago to a far more modular rewrite this month to suddenly doing the start of Alpha emulsion!

 

[commodorejohn]

Oh, very neat! I'm assuming this is essentially a CPU emulator core wrapped in a WINE-style system-call translation layer? (Of course, it wouldn't really require much "translation," but simply in terms of passing the call and response from the emulated environment to the host OS...)

 

[CaptainWillStarblazer]

Oh, very neat! I'm assuming this is essentially a CPU emulator core wrapped in a WINE-style system-call translation layer? (Of course, it wouldn't really require much "translation," but simply in terms of passing the call and response from the emulated environment to the host OS...)

Yeah, that is essentially how it works. Basically, whenever the emulated program needs to load a DLL (let's say, KERNEL32), we will load the native, real version of the DLL into EmuWoW's address space, and then also load in a version with the code section stubbed out where each export is just thunks containing an illegal instruction which invokes the emulator to make an API call, so when the Alpha program loads the arguments into registers and calls HeapAlloc, for example, it's calling a bit of Alpha code which executes that illegal instruction, causes the emulator to arrange the arguments to call the real HeapAlloc, and then put the result into the appropriate register for the Alpha.

 

[commodorejohn]

Nifty. Wonder if that's how FX!32 worked...?

 

[CaptainWillStarblazer]

Nifty. Wonder if that's how FX!32 worked...?

Fundamentally, yeah, it's the same idea. I actually did some reading about how FX!32 worked (and if I remember rightly, all versions of WoW64 from Microsoft that incorporate emulation, including x86 on Itanium and x86 on ARM, are descended from FX!32), and it does the same sort of thing, though FX!32 also analyzes the execution path and then recompiles parts of the EXE into native Alpha code.

 

[AndrewZ]

NT Alpha software is somewhat rare and geared towards server usage. In the mid 90's we ported our multimedia product, PhotoMorph, to the Alpha and did a number of trade shows
with the Alpha multimedia group. It was always amazing to render graphics on the Alpha, it was so much faster than anything else.

 

[CaptainWillStarblazer]

NT Alpha software is somewhat rare and geared towards server usage. In the mid 90's we ported our multimedia product, PhotoMorph, to the Alpha and did a number of trade shows
with the Alpha multimedia group. It was always amazing to render graphics on the Alpha, it was so much faster than anything else.

Yeah, that is the impression I got from most Alpha NT software (especially the non-MS stuff). Mostly, I'm focusing on getting the built-in applets (and SDK samples) working right now, since they're simple, recognizable, and have debug symbols. The Alpha is a really cool piece of hardware.

 

[AndrewZ]

Yeah, that is the impression I got from most Alpha NT software (especially the non-MS stuff). Mostly, I'm focusing on getting the built-in applets (and SDK samples) working right now, since they're simple, recognizable, and have debug symbols. The Alpha is a really cool piece of hardware.

There was MS Office for Alpha. It came installed on a lot of systems. That would be a good catch.

 

[CaptainWillStarblazer]

There was MS Office for Alpha. It came installed on a lot of systems. That would be a good catch.

MS Office is one of the most complicated Windows programs there is, with a ton of DLLs, interprocess communication and DDE/OLE, and heavy use of COM. I certainly would love to get it working down the road, but it's a ways out. Right now, my focus is on the built-in applets, and then there's applications I'd consider to be of "medium difficulty" like Doom and the Visual C++ command line tools, and then there's tools of "extreme difficulty" like Office and Visual Studio.