Rebuilding ulib missing extract command

[the-grue]

I am working on getting the programs compiled with Borland C++ 3.1 to compile under the freely available Turbo C++ 1.01 in the Borland Museum. While working through the build process for ulib.lib it is calling an extract command. This command is not available in the BIN directory nor in the installed products previously identified as required. I also can't find it as a buildable command in the source code.

Any idea what it is, if it is necessary, and where it may be located?

[andrewbird]

Do you know which file it's supposed to operate on? If you can identify the file type it may help you figure out what the tool is?

[roelandjansen]

I have the full build env, obviously (from the tape. What's the exact command and when is it referenced?

[the-grue]

Sorry for the delay. The code is in the file:

SOURCES\src\ulib\GENNDX.BAT

and is called as:

extract #ulib.dat /d=ulib.ndx /b /l /m=f /s /c

I believe it operates on ulib.lib. I noticed the .ndx file does not exist in the repo, so it may not be necessary. I just ignored it and proceeded with my work after building ulib.lib under Turbo C++ and was able to build export.exe, hdsetup.exe, and install.exe under SOURCES\src\cutils with some minor tweaks. I also did some testing of the newly built .exe files, which seem to work, and got sidetracked by hdsetup not seeing my third drive. :)

I don't think this is a show stopper, and will offer a patch once I clean things up a bit. This bit of code is not in the main MAKEMOS.BAT build stream, so it will always use the precompiled library for ulib.lib.

[the-grue]

Assuming 6 months is long enough for my patch to have been tested, I believe we can close this issue. The extract command, whatever value it may have had, doesn't seem to have any impact on the library or executables linked to it.

[ghost]

The ulib.mak calls out to genndx because a makefile can't directly execute a command with a # character. As Wikipedia notes, NDX is a dbase index file. And ulib.mak calls genndx whenever any source associated with the .lib is changed. Wild guess, they used dbase to create documentation.

As Wikipedia also says:

Jerry Pournelle in July 1980 called Vulcan "infuriatingly excellent" because the software was powerful but the documentation was poor. He praised its speed and sophisticated queries, but said that "we do a lot of pounding at the table and screaming in rage at the documentation".

Sounds like PC-MOS.

[ghost]

I am working on getting the programs compiled with Borland C++ 3.1 to compile under the freely available Turbo C++ 1.01 in the Borland Museum

It's your time to spend as you wish. But does ideological purity help find bugs? My idea is, once all the bugs are fixed, and the architecture is refined to elegance, then it should be easy to port the code to ideologically pure environments.

Again, your time, your rules. Do what you will.