Borland TDUMP v4.1 - DOS extended, but still dumb

The Borland TDUMP utility that shipped with the last version of the 16 bit compilers (Borland C++ v4.x) looks to be a DOS extender app. That's cool right? It should be able to use the whole 48M of memory on my ancient DOS development machine to process .OBJ files and handle some truly big stuff right?

Wrong. TDUMP's transition from a plain old DOS app to a 32 bit extended DOS app didn't go too well it seems.

First thing I try is stuffing an .OBJ through it that has a somewhat largish number of segments, but still nowhere near the max that the OMF format supports. 3,001 of them to be exact. This shouldn't be a big deal since they're all small -- in fact, they're only one byte each - only a byte larger than the smallest segment -- one that's zero bytes long.

Well TDUMP gets down around segment 200 or so and dies crapping out a nasty Trap-D message. That's it end of story. Do not pass GO do not collect $200.

The old plain DOS version of TDUMP had similar issues. After about segment 200 or so it started spewing trash all over the screen and acting rather unseemly.

So what have we got here? Any of you who's been in the business for a while knows the answer already. TDUMP has an indexed static array of somethings with a fixed length and its not being checked against the index running off the end and other memory being scribbled into.

What would it have cost to up this fixed limit to the theoretical max number of segments one can stuff into a .OBJ file? The theoretical max on segment indexes is 32767. The OMF supports, theoretically, having up to 32K-1 segments in any given .OBJ file. So if you had an array of pointers to SEGDEF records that was 32K-1 entries long, its only going to burn ~128K of memory for the pointer array. 128K -- not much in a DOS extended world where many megs are available.

OK, so you still don't want to burn 128K for something that only a crazed maniac would want to do anyway? That's reasonable.

Then maybe you do something like I did in the .OBJ hacking utility I'm writing - you throw the suckers on a linked list and let it expand dynamically as they're encountered. The code I've got so far handles the 3,0001 segments test file just fine using the linked lists, and it does it still being a plain old DOS app unable to access anymore than the usual 640K.