[dmeybohm]

I wrote a utility to copy small files from Linux -> DOS over a LapLink cable.

https://github.com/dmeybohm/ppcopy

I used it to fix a Windows 98 laptop that wasn't booting all the way to Windows. The would boot to a DOS prompt only, there was no CD-ROM driver, and I only had a Windows 98 install CD. So, there was no to re-install Windows to fix it.

So I wrote the assembly copier for the parallel port. I think it was about 200-500 bytes. Then I used dos DEBUG.EXE to write the hexadecimal code for the program into memory and then write the .COM program to disk. Surprisingly, I didn't make any mistakes (or any that mattered...) and it worked the first time. I had also done a checksum in the copy program in case I screwed it up. But it took about an hour to write the program into DOS debug.exe.

[ronsor]

Even in DOS, I think

    copy LPT1 output.bin

would have worked at the time.

Anyway, was there a chance you posted that story to Reddit or somewhere else previously? I'm sure I've read it before.

[dmeybohm]

Thanks - I don't know if I ever tried that. I'm curious if that works, sadly I don't have any hardware to check anymore.

It seems unlikely to me though that that would work on DOS without special software because it's such a pauper's OS. To implement the read-side, the DOS kernel or COPY program would have to have a way to pretend to be a printer and then clock the data in according to some protocol. And given DOS is so resource constrained, seems unlikely Microsoft would add code in those fundamental pieces for such a use case, unless it were as simple as switching a few instructions.

There is also the INTERLNK and INTERSVR programs that are built-in to either MS-DOS 6 or 6.22 that could help with that use case.

Yeah, I've probably posted about it before - maybe even here.

[bombcar]

Copying from a COM port could work because the MODE command could set the various settings - but input from LPT1 or PRN wouldn’t work by default in DOS.