That kind of bootstrapping is different, and more of a colloquialism.

'Bootstrapping' more or less means 'getting initial software loaded' in both cases, but the kind mentioned here is for a computer that only has basic DOS operating system files installed, and you dont have another means of getting files in or out of that machine. (Say, files are too big for floppies, dont have floppy disks, or lack floppy disc drives. Dont have cdrom drives, or have a means to attach that computer's hard drive to another computer to put more software onto it.)

You can use MODE to configure a serial port, then CTTY to make a very primitive null-modem connection, then send a more robust serial data transfer program over, then use that.

Pushing that more capable program over this way is 'bootstrapping' the connection.

Most of the time you see that word though, it's in the context of the computer being turned on, and starting an operating system.

Modern computers have a pretty complicated bit of software baked into their motherboards, call the Extensible Firmware Interface, or EFI, but old computers have something much more limited and comparatively primitive, called Basic Input/Output Services, or BIOS.

When an old computer first powers on, it's CPU begins looking for a program to run, starting at the very bottom of memory (segment 0, offset 0, address 00000000). This program is part of the BIOS, and walks the processor through various Power-On Self Test (POST) routines, which make sure the system RAM is good, that external storage devices work and respond when accessed, and that there are no bus conflicts, among other things.

After it does all that, it's ready to start an operating system. It pulls the first 512 bytes from disk devices it knows about, and tests to see if that data contains a small program to execute or not. If not, it moves to the next one in the list until it finds one that does. If it fails to find one at all, it notifies the operator then waits for user input.

This process is *also* called bootstrapping.

The small 512 byte program that the bios post routine loads into memory is called a 'boot loader', and the special sector it loads from is called the 'boot sector'.

This program can be anything, as long as fits in the sector. DOS, WinNT, OS/2, Linux-- all start the same way up to this point, and each of them use different ways of doing things *after* this point.

Regardless, the job of this tiny program, is to copy more data into memory, like disk drivers or OS services handlers, then set up shop. It 'bootstraps' the computer into a functional state.

When most people say 'bootstrap' they mean this latter, but the former is also a correct useage.

Just dont confuse the two.

Take a look at my DDLINK which you can get (free) from my site.

This can move files between systems over a serial connection (also can do network and parallel connections)

Single 17k .COM - Does not have to be "installed" and does not any other software (network needs a "packet driver")

If you have no easy way to get it on to one of the systems, It can "bootstrap" itself over a serial connection, needing only CTTY (built into DOS), and possibly MODE if for some reason the COM port doesn't default to reasonable settings.

For a serial connection you will need a "null modem" cable - DDLINK can show you the correct wiring to make one (and also the parallel cable if you decide to try that)

Pretty good descriptions on how to get it working , making and connecting cables etc. are in it's included documentation.

Discussed a bit more here: DDLINK: Easily move files between/To/From DOS systems

Concerning 'bootstrapping' a serial null modem connection:

I know of at least 2 program suites that make this fairly painless.

Fastlynx 2, and DaveDDS's DDLINK.

The former is vintage buyware, and the latter is modern freeware. They both provide the same functionality, and even have very similar splitscreen mode interfaces.

You start the software on a computer you are better able to get data in and out of, connect the serial cable to the computer you need to 'bootstrap', put the software in bootstrap mode, then run MODE and CTTY on the computer you need bootstrapped.

This copies the suite to that remote machine over the primitive nullmodem connection. After that, you can run it there, the two machines can communicate more robustly, and can copy files to and from each other.

Yes, the term "bootstrap" comes from the old expression "pullinh yourself up by your bootstraps" (something you can't actually do) - and commonly refers to how a computer gets it's operating software into memory (what software do you use to load the first software to run) - PCs have "BIOS" roms, but I have worked on front panel systems where you can to manually enter a small "bootloader" via that front panel.

... I also use the term "bootstrap" for getting DDLINK onto a system without floppy etc. or comm software by a serial connection - also something that many consider not possible (also pulling up by bootstraps)

Literally bootstrapping a machine with nothing but a serial cable and blank disks is common in the Apple II world where they use ADTPro to do this. It's possible because the built in BASIC is powerful enough that it has commands like PR# to start taking input from the serial port, and the ADTPro server end then "bootstraps" the client side in to the Apple II's memory.

This is difficult on PCs since if you don't have bootable media of some form, there's no way to get the machine into that state to start loading an OS over serial. There are exceptions, like IBMs having ROM BASIC, and some people have hacked together a short program to type into it to do something similar to ADTPro. There's also the option of temporarily installing an ISA card with a boot ROM to get bootstrapped--e.g. XT-IDE Universal BIOS can emulate a disk over the serial port.

It sounds like your situation is simpler. The machine has a hard drive and DOS is up and running on it, but none of the removable media works.
If you have another DOS machine, Interlnk/Intersvr can do this bootstrapping including the CTTY part. Interlnk/Intersvr were written by the same company as FastLynx, in fact.
Note that for CTTY to work, your null-modem cable must be wired to assert DSR. Many do not, and for some reason this isn't a standard part of the conversation about CTTY. If it doesn't assert it, DOS will do a continual abort/retry/fail.

Laplink is another transfer utility able to do this.

I have also used one called Twin Express, which I think has a way to do it, but might be a bit more involved, not quite so automated. I prefer that one for machines with "slow" UARTs and no available LPT for parallel cable, as it is able to get 56k out of an XT serial port. The PC binaries are included with the Amiga distribution, so it flies under the radar unless you also have Amiga interests. Anyway, if you are stuck with serial, have a LOT of data to transfer and are only getting 19,200, 38,400 rates with other utils, shoving that over the line first and using it instead might get you done today instead of next Tuesday.

IIRC you need Dos 5 or better each end for Interlnk

Another point to note is that if switching to parallel transfer after you've got the utility "bootstrapped" laplink, DDlink and others, the Compaq LPT ports are typically at non-standard address and might need the default settings changed. Also they can be weird in other ways and prevent some parallel utilities working. (Be they transfer, disk, parallel DAC or whatever.)

The OP says DOS 6 is already on the machine, so Interlnk should already be there. The pain point for parallel is needing another somewhat-vintage machine on the other end to run Intersvr.

Hmmm, I have done DOS interlnk to Windows98 ICS booted to gui and done it DOS to Win98 command line, and done Windows 7 ICS with a USB parallel convertor to Win 98 GUI ICS.... so seems plausible that DOS interlnk and TCPIP to Win7 machine with any kind of parallel, USB, dock etc, could probably be configured, but I haven't actually tried it. Also been a decade since I had TCPIP going over interlnk so forgotten everything that end.

Edit: crap, or did I? I had various software lashups with parallel cables, might have had a PLIP driver. Using interlnk one way and plip the other, and switching around depending what I was doing.