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.

FWIW - I made DDLINK primarilily as a companion to ImageDisk

ImageDisk can record/recreate ANY floppy disk the PC hardware can handle, not just the formats MSOFT likes - it is used by many "true classic" collectors, Museums and research instutions.

It accesses the FDC in some unusual and non-standard ways, hence it has to run under DOS (direct ability to access hardware) but most these days don't have DOS systensm, so I made up a bootable ImageDisk system floppy. No need to create a DOS compatible partition on your hard drive.

It creates a RamDisk big enough to store/retreive disk images - but how to get them on/off the system.

DDLINK was made to be TINY - single 17k .COM (no other parts) - doesn't take much space on that boot floppy, and can transfer via Network(without other LAN software), Parallel or Serial. And it's the same 17k .COM that can run as either client or server. Most others I looked at were quite a bit bigger - and I wanted to leave as much space on the boot floppy as possible so other "favorite" tools could be addded!

I've since found it very useful for other stuff - single .COM (and packet driver if doing network) - just get it on a system & you're good.

It can be run under DosBox if you need to move to/from a "modern" system.

I'm pretty sure I confirmed it works down to DOS 2.0, I know I've used it under 3.3 fairly recently. - just some random information/history

Thank you, DDLink looks like the perfect tool for my needs, I'll give it a try!

AMIGA can truly bootstram over serial, no OS needed. https://hackaday.com/2022/10/28/you-can-now-b … ne-weird-trick/

IBM 5150 can bootstrap over keyboard port https://minuszerodegrees.net/5150/post/5150%2 … 20breakdown.htm
IF REQUESTED, LOAD DIAG. CODE "Take the clock pin in the motherboard's keyboard DIN connector LOW for 40 ms. (Done by the KBD_RESET subroutine.)
If the attached device responds with the byte of 65h, the attached device is a special IBM device that supplies diagnostic/test code to the 5150 via the keyboard port. If 65h received, load in the diagnostic/test code (255 bytes) via the keyboard port, then execute the code."
This routine is only active for a split second during Post.

Zenith Data Systems implemented something similar in its ZBIOS (Re: What retro activity did you get up to today?), except they meant to leave it _active all the time_ https://github.com/raszpl/Zenith_ZBIOS/blob/0 … 3.2C.lst#L19177 seg000:7B03 Backdoor_loader
A true backdoor allowing anyone walk to your computer, plug something to keyboard port, upload H4X0r code to 0:500h and immediately execute it 😮 :] Its deactivated/patched out in final bios.

Yes, although DDLINK itself needs only a 3-wire null-modem cable, DOS (for BootStrap) needs more - the extras are marked in the help output showing the cable wiring.

DosBox can access serial ports directly and network with a suitable PCAP installed, but I've never gotten parralel transfers it to work reliable - WinBlows seems to "twiddle" the LPT pins frequently - presumable looking to for a printer attached.

It's on my "I should write someday" list to do a native DDLINK server for Win32 ... ideally could access serial ports directly, network without PCAP and parallel by either blocking access by the system somehow, or direct access to "disabled" hardware. ... but so far I've not gotten deep enough into such needed low-level access to hardware under Winblows - anyone knowlegable in this care to help out?

DaveDDS wrote on Today, 10:25:

It's on my "I should write someday" list to do a native DDLINK server for Win32 ... ideally could access serial ports directly, network without PCAP and parallel by either blocking access by the system somehow, or direct access to "disabled" hardware. ... but so far I've not gotten deep enough into such needed low-level access to hardware under Winblows - anyone knowlegable in this care to help out?

Hello,
For serial, opening the serial device as a file and using these functions that are analogous to Unix <termios.h> to set the baud rate, data bits, parity bits, etc. should suffice: https://learn.microsoft.com/en-us/windows/win … tions-functions and that's probably what Dosbox is using under the hood anyway.
Very quickly looking at the DDLINK code, as you're sending raw ethernet frames with a custom ethertype, you'll probably still need npcap even as a native Win32 program.
There are these IOCTLs for parallel ports where you could similarly open one as a file, but it isn't obvious that they're usable from userspace: https://learn.microsoft.com/en-us/previous-ve … rts-and-devices
Have you done anything with USB to parallel printer adapters? I'm not sure whether they grant low-level enough access for this kind of programming, and tend to have the "wrong" (Centronics) end on them anyway.