4 ms·

Wow, that's so crazy and wonderful. And yet very okay, since it wasn't like there would be any other application running. :) If I recall correctly, (original)

Wow, that's so crazy and wonderful. And yet very okay, since it wasn't like there would be any other application running. :) If I recall correctly, (original) XBOX games would often go the the next level of whatever game by just loading a new EXE and start over from scratch, rather than bothering with some kind of "level loading and init" code.

remarkEon 7y ago
The Command and Conquer episode from last year is also excellent: https://youtu.be/S-VAL7Epn3o https://youtu.be/S-VAL7Epn3o
Insanity 7y ago
guess that could make sense in a way. Dump all 'state' to disk, start new exe that begins by reading that state, and go from there.
- jacobush 7y ago
  And often that state would be minimal. What character am I playing, what is the total score, stuff like that.
- akx 7y ago
  Reminds me of how Emacs is built, with a `temacs` executable whose state is dumped to generate `emacs` which boots faster... https://www.gnu.org/software/emacs/manual/html_node/elisp/Building-Emacs.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu...
- anoncake 7y ago
  They needed that code anyway for savegames.
- ascagnel_ 7y ago
  It was fine on consoles, but on PC it'd lead to some weird behavior, like the monitor switching modes as it returned to the desktop and then went back into 3D mode as the newly-launched EXE ran its init code.
nottorp 7y ago
The original x-com (the good one from 1994) had separate executables at least for the geoscape and tactical battles. In spite of being a 32 bit application using a dos extender, so not limited to the first 640k ram.
- dfox 7y ago
  Almost all Microprose PC games from early 90's were structured as small .COM driver that switched between some number of separate .EXEs. IIRC there is notable exception of Civilization that used proper overlays.
anthk 7y ago
The Italian Job for PC works like that too.

remarkEon 7y ago

The Command and Conquer episode from last year is also excellent: https://youtu.be/S-VAL7Epn3o https://youtu.be/S-VAL7Epn3o

Insanity 7y ago

guess that could make sense in a way. Dump all 'state' to disk, start new exe that begins by reading that state, and go from there.

jacobush 7y ago
And often that state would be minimal. What character am I playing, what is the total score, stuff like that.
akx 7y ago
Reminds me of how Emacs is built, with a `temacs` executable whose state is dumped to generate `emacs` which boots faster... https://www.gnu.org/software/emacs/manual/html_node/elisp/Building-Emacs.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu...
anoncake 7y ago
They needed that code anyway for savegames.
ascagnel_ 7y ago
It was fine on consoles, but on PC it'd lead to some weird behavior, like the monitor switching modes as it returned to the desktop and then went back into 3D mode as the newly-launched EXE ran its init code.

nottorp 7y ago

The original x-com (the good one from 1994) had separate executables at least for the geoscape and tactical battles. In spite of being a 32 bit application using a dos extender, so not limited to the first 640k ram.

dfox 7y ago
Almost all Microprose PC games from early 90's were structured as small .COM driver that switched between some number of separate .EXEs. IIRC there is notable exception of Civilization that used proper overlays.

anthk 7y ago

The Italian Job for PC works like that too.