For 32-bit immediate values, PUSH by itself is enough. For everything else,
PUSHD works in both TASM and JWasm.
Also, could it be...? Could we actually move to JWasm without breaking the
build in TASM at all?
... and then I end up copying modified versions into the individual game
subdirectories after all, because the changes between games were simply too
drastic. (That's also why I'm counting pfopen() itself twice.)
Only one slice left now, and then we're done with reduction!
Yup, packfiles finally proved that we really have a different set of changes
to master.lib in every game. Also, there are bound to be more of these game-
specific small changes to otherwise identical code in ZUN's own code.
And hey, no need to define that value in the build scripts anymore.
(I've also considered just copying modified versions into the individual game
subdirectories, but it's not too nice to expect people to diff them in order
to actually understand why these copies exist and where the changes actually
are.)
> introduce a new macro to halve the lines of a far function pointer
assignment, hoping that this commit will end up deleting more lines than it
adds, because TH03 has lots of those
> oh wait, these games mainly use near function pointers
> unearth even more new functions in the process
Seriously, how many more functions are still hidden in this codebase? And all
that just because IDA was not smart enough to begin with.
So that's the - admittedly rather weird - solution to the problem that has
been plaguing this project ever since the beginning of the reduction step.
Without any 32-bit dummy segments in the compiled object files, more linkers
will be able to build this project, one of them being JWlink
(http://sourceforge.net/projects/jwlink/).
Still can't rename dseg to _DATA though, as TASM stupidly refuses to accept
any ALIGN directives above a segment's alignment attribute value. TH01's
floating-point data slices already require larger alignments, and we're very
likely to have even more of those in the future.
Also, we're finally defining the Borland C++ model symbols directly in the
code, rather than in my unpublished build batch files. :)
Mostly moving spurious null bytes, which are actually supposed to denote
alignment, into their associated slices, but also prettying up some of the
very first slices.
Well, we have to start reducing this mess somewhere. The actual reduced
initialization code I've been preparing still fails to compile, and the data
is shared with a number of other components anyway, so...
Which challenges a lot about what we thought to know about Amusement Makers'
modifications to master.lib, due to the fact that TH02 contains the modified
version of this function, but the original of draw_trapezoid...
And I haven't even begun to research how this removal of conditional branches
could have a positive effect on the game, especially since it's only called
before exiting anyway.
OK, *that's* the last piece of C++ crud shared across all main executables.
According to the object in the library file though, it seems to include one
more dword named
__DestructorCountPtr
in the BSS segment. Neither games nor the runtime itself seem to use it, and
as a consequence, it doesn't even seem to be included in the games' BSS
segments, given that they all end with the symbols of xx.cpp...
Neither is this one. Also, interesting how IDA didn't identify the function in
one third of the cases.
[Binary change] Order of 2 relocations in TH03's MAINL.EXE, TH04's MAIN.EXE
and MAINE.EXE, and TH05's MAINE.EXE.
OK, looks like we got all of the C++ crap out of the way... e~xcept for
another function in TH01's REIIDEN.EXE, of course.
[Binary change] Order of 2 relocations in TH01's FUUIN.EXE.
God, this C++ stuff really is a crappy mess. Even had to manually adjust the
alignments at the end of the the TEXTC segment - and no, the ALIGN directive
remains an inadequate tool random bytes, even more so because TASM's
implementation just pads the space with random bytes. But hey, nice to finally
see some reduction outside of seg000.
[Binary change]
* Order of 3 relocations in all of TH04 and TH05's OP.EXE
* Order of 6 relocations in TH03's OP.EXE and MAIN.EXE, and TH05's MAIN.EXE
and MAINE.EXE
* Order of 9 relocations in all of TH01, TH02's OP.EXE and MAINE.EXE, and
TH03's MAINL.EXE
* Order of 11 relocations in TH02's MAINE.EXE
[Binary change]
* Order of 2 relocations in all executables of TH02, TH03, TH04 and TH05
* Order of 4 relocations in TH01's FUUIN.EXE
* Inserts a new relocation into TH01's REIIDEN.EXE
Yup. 50 functions in a single module, totalling 12,633 bytes, used in all 15
game executables, and no references to any of that in the remaining game code.
[Binary change]
* Order of 3 relocations in all of THO3, TH04 and TH05, TH02's MAIN.EXE and
MAINE.EXE, and TH01's OP.EXE and FUUIN.EXE
* Order of 2 relocations in TH02's OP.EXE and TH01's REIIDEN.EXE
* Inserts a new relocation into TH03's MAIN.EXE
Well. Even after downloading pretty much every (identical) copy of Turbo /
Borland C++ 3, 4, 5 and everything inbetween, I could *not* find the original
source to most of the C++ parts in the runtime. Using the IDA disassemblies
to build their slices is simply the only option.
... Really, though, who cares.
Same for registerbgifont() being a wrapper around registerfarbgifont(). But
at least there, IDA should have noticed something weird. The original delete[]
operator refers to the delete function, so registerbgifont() would have had to
be a wrapper around registerbgidriver(), which of course doesn't make sense,
and IDA claims to *know* these functions...
Lol, "registerbgidriver". Just because the original function is nothing but a
wrapper around free(), and registerbgidriver() is also just a wrapper around
registerfarbgidriver().
Well, great. Why did the trapezoid variables have to be included in this
object file? 10 of the executables don't use them, and there's no way to
locate that one needle in the haystack of uninitialized data now.
nmlgc