ideally I should be able to patch arbitrary python in there and do some kind of interop to return values to python

but that's hard. and way easier unflexible thing this is 80% of what I need that for

I forgot about callee cleanup. fucking stdcall is callee cleanup. I can't have a generic int blah(){return 0x1234;} function because it needs to know how many words of arguments were pushed.

RELOCATIONS!!!! *shakes fist at sky*

I took a look at the 1985 version to see if it had any other graphics command line options (it doesn't), but I did discover in passing that it uses a different pronoun system than the 1990 Enhanced version!

It uses @0 for "He/She", @1 for "he/she", and @2 for "his/her".

hacking a computer system by changing my pronouns to they/them so that it'll use up more memory composing strings referring to me and overflow the buffer

Where in the World is Carmen Sandiego? (1985) has an invert-y-axis option for the joystick, just in case you want to use flight simulator controls to navigate a menu

back on hacking Enhanced, DOS, 1990.

My best guess is that this game has between 4-6 compression algorithms, depending on how you count them. Possibly more are hidden in the bowels of this program.

that may be only the IMAGE compression algorithms, and they use a separate different compression algorithm for text.

everything is going WONDERFULLY

this is not the game to do it with, but I really wanna try swapping out the drawing routines for one of these games once. go into a VESA mode where I can run at 1024x768 or something, and just make the drawing write to that buffer instead. Could I make BIGSCREEN DOS GAMES?

maybe I'll try it with railroad tycoon sometime. that game has loadable graphics modules. if I figure out enough of how it works, I could write my own driver for VESA Railroads

I want a girl with a short skirt and loooong BUTTONS!

hah, I love DOS programmers.
This code mallocs 65516 bytes in a loop until malloc returns zero.

totally normal part of starting program: allocate all the RAM in the system.

I mean, it's DOS. There's nothing else running that could possibly call malloc. So why not?

You also have to remember that it's not going to succeed more than, like, 6-8 times?
There's just not that much memory in the system that this can touch, since it's not supporting any of the endless varieties of breaking the 640k barrier

there's a story on Old New Thing somewhere about Windows 95 accidentally breaking a DOS game, because it did this same trick of allocating all the memory, but since Win95 was running as the DPMS, it meant it had access to all of windows 95's virtual memory. including the swap.

So instead of mallocing all 8mb or whatever your 486 had, it malloced all that and then tried to use up YOUR ENTIRE HARD DRIVE, slowly.

And then it crashed because it didn't expect to succeed that many times. It had a fixed array of handles to memory, and it overflowed because it was run on a system with HUNDREDS OF MEGABYTES OF RAM, which is clearly impossible and unthinkable

I think the solution was that win95 just defaults DOS programs to maxing out at 16mb. It won't let them allocate more than that unless you adjust the EXE options

this game runs mostly in a 16 color mode, with some high-end modes being basically 16-colors within 64 or 256 colors, right?

SO WHY DOES IT USE 16-BIT INTEGERS FOR COLOR INDICES?