From what I can tell, this program does exactly three things:
• preparing the initial high score list
• writing default settings to HUUMA.CFG
• and allocating the game's resident configuration structure and writing its
segment address to bytes 6-7 of HUUMA.CFG
All that results in a COM file of 6.84 KiB, 83% of which is library code.
That's why C was once seen as a bloated high-level language as well.
Yep, we'll be needing some of those smaller executables embedded into ZUN.COM
after all in order to fully understand what's going on with things like that
persistent configuration structure used in each game, for example.
For now, I'll be keeping every one of these executables separately, for a
number of reasons:
• I can't get IDA to segment the code in a way that would reconstruct the
layout of the individual executables, since it unfortunately requires
segments to be aligned on paragraph boundaries...
• This, in turn, means that IDA can't apply FLIRT signatures, making
identification of the Borland C++ functions a bit harder. Probably not that
big of a deal at this point anymore, but still.
• There are bound to be multiple copies of Borland C++ and master.lib
functions in these. We are still using the "slice model", meaning that *all*
functions in an executable are part of the same namespace. Creating copies of
some source files just to allow a second instance of that function is not
too pretty.
• Lastly, we don't actually need to reproduce all executables. For example,
TH02's version of ZUNSOFT.COM is bit-identical to TH01's.
Hence, adding a separate build step to wrap these smaller executables back
into a bit-perfect version of ZUN.COM at a later point is a much better
option. (And it would be even better if we could track down the program used
to wrap those in the first place!)
nmlgc