|PEW! (Transparency isn't set up quite yet)|
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.