Project-- Porting a Tetris game I wrote a long time ago in X86 to run on modern 64-bit Windows

The game was written in about 1000 lines of X86, and assembled with the A86 assembler tools. This was 12 years ago, in 2006.

It is extremely low tech and not super complicated or flashy, it was meant to be a personal effort back then to learn about it and becoming more comfortable debugging it. It was built as a 16-bit DOS COM executable. Although it ran on Windows at the time, the binary format was not very current even back then. Sadly time passed, the binary rotted and it does not run anymore.

There are three reasons why it does not run anymore
1. It's a .COM executable. Running these requires an MS-DOS emulation subsystem of Windows which is not present on 64 bit Windows
2. It's a 16-bit executable, which does not have support on 64 bit Windows
3. It uses DOS interrupts in order to work. These interrupts are not supported in modern OS. Modern Windows behavior is that they just crash the app

In addition to the broken binary, I had the source code still. So I decided to resurrect it by porting it so that it can be run natively now on a modern 64 bit Windows OS (where 'natively' here means 'not with an emulator'). Yeah you can run it in DOSBox, but meh

Although the program was originally assembled with A86, I ported it to use MASM (a Microsoft product). I want to say using MASM is not necessary for fixing the above problems. It would actually be possible to fix the above problems while still using A86. As it turns out, building Win32 programs with A86 is easier than ever because the author has (since 2006) created a new set of convenience tools for that, just barely too late for me to have taken advantage of. Looks promising.

The thing is, if I'm going to set out to make it work on Win32 anyway, it is almost certainly going to be easier with MASM. It has easy-to-set-up integration with Visual Studio, it's basically automatic setting up my project to link against the right libraries, and there are built-in conveniences which make the Win32 APIs (or anything) syntactically nicer to call for the purposes of doing this. MASM has different syntax than A86 but switching over to its syntax wasn't such a bad price to pay. Mnemonics themselves and the syntax for the addressing modes are basically the same. I thought I'd have to change over some things on this front, but as it turned out I didn't. In general I don't think the compatibility of mnemonics is standardized or guaranteed, but I didn't run into problems in this area.

The annoyance-- which would been there for MASM or A86 regardless-- was graphics, because this part had to be changed the most. I decided to go with GDI which is not going to be anything like mode 13h (If you haven't had to ever program with mode 13h it basically gives you a pointer to the aperture and writing to it draws indexed-color pixels on the screen) For GDI on Win32 the program needs to be structured a lot differently. It needs to create a window and window resources, the code for drawing the grid needed to be moved to a paint message handler, needs to update with a timer, it should be scaled up too since a 320x200 resolution 1:1 is not a great time on a modern display, etc.

Coming at this I had wanted to be able to treat the game as a black box. Change a few things to get it working in Windows and that's it. But in the end, I needed to understand nearly all parts of it to do what I wanted to do. There were all these long stretches of code organized horribly where I'd long forgotten how they work. Doing this was a gigantic hassle

Anyway I got it working. It is still extremely low tech but that's kind of the point, and to just get it working. I got to add a couple new things too:
- Different colors for the different pieces
- Fixed a bug where rows would sometimes not get cleared correctly
- Added a 'next piece' UI
- When you get game over instead of crashing it displays a message and you can press Escape to start again

I wonder... when it will rot again?? (As a GDI Win32 app) maybe it's good for a while

The code for the Win32 version is all in one file located here.