A Problem Easily Solved

Monday, 13th November 2017

At the time of writing yesterday's post on my space game project, I had a problem with the DOS executable. Sometimes it would freeze. Sometimes it would more helpfully output "Null pointer assignment." Sometimes it would work perfectly.

I'm using Watcom C under Linux, and the Linux executable always seems to work flawlessly. The "Null pointer assignment" suggested to me that sometimes, when reserving memory for something, the DOS version would fail. So I put in an explicit check whenever malloc() is called, which will print a clear error message and exit the program if any memory allocation fails.

Success! After running successfully a few times, my program declared that it had failed to reserve memory for a planet. Why would this be? I suspected that my DOS executable was being compiled with the small memory model (64k total for program and data), and that my data was sometimes exceeding the limit. The number of planets is variable, which is why sometimes there isn't a problem.

The solution to this problem: find the compiler option to build the program with a large memory model. This allows up to 1mb to be addressed, encompassing all of the 640k of memory a basic XT-class machine can have. Now I've run the program about a dozen times, without a problem.

My next job, then, is to create some basic error checking on possible points of failure like malloc(), with a way for different parts of the program to communicate the precise error that stops them. These errors can then be reported to the user. Once this is done, I can proceed with planet generation safe in the knowledge that I'm not leaving DOS behind.