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.
Lol, these are so similar to __rtl_write and __write that Git's diff treats
reada.asm as a modified copy of writea.asm. Same situation with the CAS file
here, too.
Because it just so happens that master.lib's bfnt_header structure contains
an element named "START".
And huh, this suddenly works without changing any assembler or linker
parameters? I swear it didn't when I tried it first.
> "OK, the signal slice is pretty large, let's do it tomorrow"
> stay there for the majority of the day
Oh well, at least it paid off. I *really* should work towards PI loading now,
though.
With seg000 changed to word alignment and all definitions for "func" removed,
the master.lib functions can keep their exact alignment themselves.
[Binary change] db 0 → nop before get_machine_98() in the MAIN.EXE and
MAINE.EXE files of TH04 and TH05, respectively.
... I, um, don't know what's going on there. C++ class instances, maybe? At
least the code is largely identical in all three executables, so reduction's
going to take care of that.
Again, we can't split dseg into the "real" segments just yet, because that
would force us to correct the assumed data segment in every single function.
[Binary change] Relocations in TH01's FUUIN.EXE. Again.
Having thought this over for a while, I've decided to stay with the "include
slice" model for now, due to various bugs and other reasons.
We need to compile for the 386 CPU, but this causes TASM to automatically
default every segment to 32-bit mode, which of course is not what we want (and
no, .MODEL USE16 sadly does not help either). Appending USE16 to every segment
declaration in all included files seems to work, but for some reason, this
messes up certain jump instructions. WTF? And even if it did work, we would
still have to do this for every single file we include.
The alternative would be to build proper libraries and let the linker merge
all the code. This would add a lot of unwarranted complexity to the build
process. Not to mention all the EXTERN statements we'd have to maintain.
Ultimately, all of the C runtime ASM code is going to vanish anyway once we've
completed the reduction step. Once we're there, we can simply link to the
original version of the library. These initial dumps are not pretty, and I see
no point in wasting time on making intermediary stages of development look
pretty.
Since including RULES.ASI from every slice seems a bit inefficient (and even
potentiall harmful, considering the age of the development tools we have to
work with), we'll only include it once at the top of every main dump file.
[Binary change] Relocations in TH01's REIIDEN.EXE, again.
Wow, what a slice. Lots of code, and it comes with its own data declarations
inside the code segment! Since all these functions were originally contained
in one code file, it makes sense to do all 13 in one commit. This removes all
erroneous references to the 'NULL CHECK' string.
[Binary change] This also changes some relocations in TH01's REIIDEN.EXE.
It begins. And this already shows that the inclusion of TH01's ZUNSOFT.COM
will double the size of all Borland C routines we slice out, because we have
to cover both large and tiny memory models...
nmlgc