Needlessly linked with TCC rather than TLINK, adding almost 4 KB of
completely unnecessary libc startup code.
Or maybe not, since ZUN doesn't free the allocated memory himself, but
relies on libc to do that?
Part of P0117, funded by [Anonymous].
On the surface, Version1.02 of the `INTvector set program` seems to
be largely the same as Version1.01, just with fancier instructions,
some redundancy removed, and some slightly different wording in the
playful messages… or is there more to it? Stay tuned!
Part of P0117, funded by [Anonymous].
Yup, it's finally the right time to properly rebuild ZUN.COM. While
all of these small binaries would still need some RE attention, putting
in the few minutes to make them position-independent right now is
definitely worth it. Adding them to the PI calculation on the website
would take much longer 😅
Part of P0117, funded by [Anonymous].
Yeah, why *were* we assembling them in the 16-bit part before?!
Possible reasons:
• In a time before Tup, it made no actual difference whether these
little files were assembled in the 32-bit or 16-bit part. Now it sort
of does, since we've temporarily given up on minimal rebuilds in the
16-bit part.
• Emphasizing the temporary nature of the 32-bit part by deliberately
moving everything to the 16-bit part as early as possible?
• It all started with the ZUN.COM ASM code, which doesn't include any
other files, and can therefore be perfectly tracked by a Makefile.
Which *was* superior than the exclusive dumb batch file we had in the
past. And then I've simply cargo-culted all new .ASM translation
units into the 16-bit part well.
Oh, and another positive side effect of temporarily not using 16-bit
TASM: The build process now also runs on Windows 95.
Part of P0113, funded by Lmocinemod.
nmlgc