<p><span class="h-card" translate="no"><a href="https://mastodon.social/@gamingonlinux" class="u-url mention">@<span>gamingonlinux</span></a></span> just tried it. It&#39;s fantastic 👏</p>

<p>I&#39;m not sure if anyone has ever designed a paletted graphics system that uses more than 256 colors. Probably at some point someone thought it was a good idea.</p>

<p>this game runs mostly in a 16 color mode, with some high-end modes being basically 16-colors within 64 or 256 colors, right?</p><p>SO WHY DOES IT USE 16-BIT INTEGERS FOR COLOR INDICES?</p>

<p>I think the solution was that win95 just defaults DOS programs to maxing out at 16mb. It won&#39;t let them allocate more than that unless you adjust the EXE options</p>

<p>And then it crashed because it didn&#39;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</p>

<p>there&#39;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&#39;s virtual memory. including the swap. </p><p>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.</p>

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

<p>totally normal part of starting program: allocate all the RAM in the system.</p><p>I mean, it&#39;s DOS. There&#39;s nothing else running that could possibly call malloc. So why not?</p>

<p>hah, I love DOS programmers.<br />This code mallocs 65516 bytes in a loop until malloc returns zero.</p>