Since DSEG is *supposed* to be aligned to a paragraph boundary, this should
have never mattered. However, JWlink seems to not obey this segment alignment
in some layer of the linking process.
This now guarantees identical builds with TLINK, ALINK and JWlink.
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...
There's also the PC-98-specific nec_delay. Which means that the inclusion of
this function into the games was *ding* entirely pointless.
Man, compilers sucked in the early 90s.
Especially annoying if that happens in the middle of a Shift-JIS multi-byte
sequence, like in those two instances in TH02's OP.EXE. Also, making up for
the lack of string analysis during the dumping process of TH05's MAIN.EXE.