Pew Pew!

PEW! (Transparency isn't set up quite yet)

Guns work, but there are still underlying issues. Computer systems nowadays are extremely  intolerant of dereferenced null pointers. It actually threw me for a loop too. It's was another issue where DOS was very forgiving, but Windows was not having any of it. The whole issue came down to what NULL used to be, and what it is now.

In the olden days before memory protection, when you set a pointer to NULL, it was largely up to the compiler to implement what that meant. Sometimes the compiler would just set the pointer address to 0 and some would even be nice enough to dereference the value of a null pointer to 0. (A useful example given to me was when you wanted to dereference a null string.) Suffice to say, ROE makes an assumption that the compiler is "nice" and dereferenceing null will give you something. Here's is an example I'm coming acorss.

MissPtr m;           //m is a pointer to a missile object

m = Game->missiles;  //Game->missiles = NULL at this point in the game

//Memory is allocated for a new Missile object

Game->missiles = (MissPtr)malloc((int)sizeof(struct MissStru));

//The old Missile object is linked back (In this case NULL) 

Game->missiles->link = m;

m->prev = Game->missiles;  //CRASH! m is NULL and member is invalid.

I can see how that can be valid on old systems. The compiler is assuming that if the object is NULL then all the other members of that object are also NULL. On newer systems, the act of asking for m->prev is the same as asking "Hey can you look at this obviously invalid address and and give me a data value that in that area?"

The OS will take away your program counter, kill the program, and tell you to think about what you just did. You are not getting data from unknown parts of memory. That's the whole point of protected mode.

I have a feeling there are lots of these in the main code. I ran into one just running the game for fifteen minutes. I have a Trello card now for this so I'll be looking for it.