Quoting Sean 'Captain Napalm' Conner <spc at conman.org>:
Which isn't vanilla C (but may be vanilla C++) ...
Except for the function name, a C compiler would be pretty happy with it. The
compiler is bad, but not that bad!
Sounds like a fixup problem. If it's the first
constant string, then it
sounds like it's at offset 0 of some segment, and the linker may be thinking
it's a NULL value (easy to see how this could happen actually). And it may
be that that implementation of sprintf() checks for a NULL string, and if
so, "does the right thing" (not print anything, and return 0 characters
written).
I'm guessing this too, but I can't figure out the difference. When the extra
constant is not there a 0x0004 gets loaded into AX. When the extra constant is
there, a 0x0005 gets loaded into AX. I might be looking at the wrong register
before the call, but I never see a case of 0x0 or 0x1 being moved in - I think
the 0x0004 and 0x0005 are the correct offsets.
Now I'm wondering if sprintf is buggered, and just doesn't like 0x0004 as input
on the call.
Changing the constant string in sprintf to different things or changing the
length didn't help.
Can you produce Microsoft .obj files and link with LINK.EXE?
-spc (Either that, or just forget C++ and use C ... )
It is producing OBJ files, but I'm not sure who's format it is. Historically
I've been scared of using linkers directly, but I guess now it's time. :-)
Another path I went down was searching for Turbo C++ 3.0 erratta on the web, but
I wasn't able to find any lists. And Borland's site doesn't cover the old
stuff, except for the downloads in the museum part.