• Please review our updated Terms and Rules here

Laplink- transfer between modern PC and MS-DOS 3 PC?

Ok, I have been trying out Kermit. Suffice to say that unless a user has quite a bit of time to read the manuals and practice, practice, practice, this is not the best solution. I did get Kermit to connect between my DOS 286 and my Windows 7 machine, using both the serial port connections (the same as used with LapLink) and the LAN network (same ethernet as used with mTCP). I have had a small amount of success in transferring some text files. I have not been successful yet with binary files.

I intend to stick with this and eventually I will figure it out. But I tend to agree with the OP in that Kermit is pretty techy and not as user friendly as LapLink. It's not so much that it is command line driven but that it is a complete new language and requires a fair amount of IT experience and understanding of the underlying protocols and rules for communication between different computer systems.

LapLink was targeted at the executive that had both a laptop and a desktop and needed to easily transfer files between the two similar systems (usually DOS or Windows) through a cable that was provided to them in the box. Kermit was designed for IT departments and enterprises with mainframes and minis and some offsite workers, or departments transferring company data back to the main office, or between universities, etc. Kermit is a powerful tool. But it is not for the faint of heart. Be prepared to study and get pretty damn techy.

In order of preferrence, for me, when needing to transfer files to an old DOS machine:

mTCP FTP over the LAN to Windows 7 FTP server on LAN
LapLink over direct cable to Windows XP or Win ME machine that is already on LAN
Floppy Drive

Note - I also like the XT-IDE route with a CF card. I use that on my Tandy 1000. I have several computers on the LAN that can copy to CF cards. But I understand that in some cases it not easy, or desirable, to add a CF card, or Goteck Floppy emulator, etc.

Thanks for taking the time to look at these options.

I've had good luck running laplink 2 and laplink 3 over serial between a modern machine running Linux and the running dosbox to host laplink.

Too bad there seem to be no easy ways to use the same kind of setup with parallel cable. Dosbos does not support parallel. Neither does virtualbox. So parallel is out in this approach.

For me linux is a good general platform to revolve around.

I just now tried to run laplink in Win2k on my pentium 4 tweener. No luck. So I think in that case the timings are off. Seems like laplink 2 or 3 needs to run in a throttled environment.

Laplink 3 supports parallel. May try that on win2k.
By the time of Win2K and XP LapLink had moved away from DOS. The versions that ran in DOS do not like to run in a Windows environment. You would be better off with WinME or Win98, both of which supported the DOS environment.

I had moved to LapLink Gold for my Windows machines. I kept LapLink 3 for use with my older DOS machines. Eventually I moved on to other tools. I now use a program called SyncBack in my business. But I don't have any old DOS machines there, all Windows or Linux.

"Easy" and an old DOS machine is not always going to happen. By the time advances in network communications software were being made DOS was pretty much dead in the marketplace.

I had a quick go at it myself just to see as I've never actually used MS-DOS Kermit before - I've got a NetWare server on my LAN so all my DOS (and OS/2, and windows, and classic Mac) machines get proper network drives. For me, serial cables for file transfer are a last resort option for when something is un-networkable. I'll also note that I'm the maintainer of the Windows version of C-Kermit though I mostly use it for terminal emulation and for getting files to/from modern linux systems without having to switch to something like WinSCP.

The vintage PC:
  • Celebris GL 5133ST, MS-DOS 6.22
  • MS-DOS Kermit 3.14 patch level 9
The modern PC:
  • Thinkpad T470, Windows 10
  • C-Kermit for Windows 10.0 Beta.07/windows-04 pre-release
  • USB-serial adapter
Connecting the two computers: a cat5 cable wired in a cisco-style rollover configuration with an RJ45-DE9 adapter at either end. The cat5 is a bit dodgy - its that blue solid-core stuff designed to go in walls, and I suspect the RJ45-DE9 adapters aren't great either. I had to wiggle things a bit to get a bidirectional connection. I wish I could find my good properly made null modem cable but this is all I have at hand.

On the vintage PC I ran kermit.exe, then:
set line com1
set speed 57600

And in C-Kermit for Windows, I ran:
set line com3
set speed 57600
set carrier-watch off
send k95g.exe

The robust command sets kermit protocol settings to favor reliability over speed and the file went through fine. I found using fast instead of robust resulted in failed transfers - quite possibly a result of my dodgy cobbled together null modem cable. Maybe the fast mode would have worked at a slower line speed and been faster overall - probably something worth playing around with. The set carrier-watch off command which C-Kermit for Windows told me to run may also only be required due to my garbage null-modem cable.

With the Vintage computer running the server command, you can on the other computer run set locus remote and then browse the DOS PCs filesystem as though you were browsing your local filesystem. set locus local switches back to browsing your local filesystem. You can use the send command to send a file to the vintage PC, or the get command to get a file from the vintage PC. Wildcards are, of course, supported. There is also a recursive send/get option but that requires MS-DOS Kermit 3.16.

If you'd rather do everything from the vintage PC, you can instead run the server command inside C-Kermit for Windows. The MS-DOS version of Kermit doesn't have a set locus command so instead you've got to use commands like remote dir. This is documented in chapter 10 of the MS-DOS Kermit book.
Last edited:
The next objective is to give my Z-171 a way to overcome the 9600baud limit.

The Z171 uses an 8250 UART which has no buffer and so must be served promptly. As debugging has indicated, there is a non-maskable interrupt that the system needs, and this interferes with the serial port throughput. So, to fix this, there was a great suggestion to swap in a 16550 UART, which is pretty close to pin compatible, but includes a buffer!

I'm excited to try this out. The part arrives soon.

However the question remains... will I need to write a little driver to put the UART in "FIFO" mode or not?

My guess and hope is that applications like LapLink were all over this, and they probably include the write to the UART to enable the FIFO. So, my guess is that I can drop in the part and it will work right away at 115200 baud.

I will report findings hopefully soon.
Well, there are versions of PLIP for DOS, but backing up a bit--why not use a standard serial protocol such as YMODEM/YMODEM-G or ZMODEM on the DOS machine? Linux has the rzsz package for this--I've used it and it works very well.
fair question. I have an affinity for Traveling Software products, firstly. I also like the UI for LapLink.
serial transfer at 115200baud is plenty quick for my needs, so if I can get the serial port buffering sorted, I think I have a workable solution.

Now that I have a W98SE/Win2K based tweener, I might be able to run parallel, come to think of it. Certainly my focus has been on serial because in the past I have been using a linux box with DOSBOX to use Laplink, and parallel is not supported in DOSBOX.

So, point well taken. I might be able to up the game here by using parallel, now that I have my tweener sorted.

But the real issue is that the Z171 cannot handle more than 9600 baud with an 8250. I want to get 115200 working. Period. just because. :)
Especially if it is just a single chip swap and voila.
115K on a 4.77 MHz 8088 is pretty tough; it mostly depends on the way the software is coded. For example, if the software routines are triggered by an IRQ (not unusual), there's no way. A FIFO won't help in that case.

Best of luck to you!
I have already verified that 115200 works on the Z171 - so long as you avoid the NMI. This means that the main routines for servicing the serial port are suitably fast, with some margin. Can that margin afford more tax? If the NMI happens, and the duration of distraction is quite short, then maybe. I guess the experiment will confirm if there is enough net time to allow the processor to keep up and not overflow the buffer, in the face of periodic NMI.

of course parallel is much quicker.

the part was 5$, to enable me to scratch at this ;)
Well tonight my Z171 gave up the ghost and won't boot now. Hardware problem...doesn't get past ram test at all. Garbage on the screen. So much for experimenting.
Great news!
Reliable COM port flow at 115200 baud is achieved very easily with the substitution of a 16C550 UART for the 8250!
In fact, when used with Laplink, no additional driver work is needed; Laplink knows enough to enable the FIFO mode on it's own.

Thanks for the great suggestion to swap this UART out. It immediately worked, no issues at all. Dropped right in!

I'll do some more testing, with large files, but seemed solid and fast transferring a 50k file.
I have to report back that after extensive testing, I did have to drop the speed to 57600 baud for reliability reasons. So Chuck(G) was right ;)

So in the end DOSBOX + Laplink3 seems like a good solution for serial transfer. Too bad DOSBOX cannot support parallel transfers.
Too bad DOSBOX cannot support parallel transfers.
If you, or anyone, consider the next as hijacking the thread, please say so.

I have been playing with an Arduino Uno and connected it to the LPT port of my Commodore PC20-III. With a small INO and a small Pascal program on the PC20 I was able to exchange some data. The advantage: can be used on any modern computer with USB. The disadvantage: we cannot use existing software and have to write new one. Unless somebody knows what protocol LapLink (or any equivalent program) uses.
115K on a 4.77 MHz 8088 is pretty tough; it mostly depends on the way the software is coded. For example, if the software routines are triggered by an IRQ (not unusual), there's no way. A FIFO won't help in that case.

Best of luck to you!
The virtual serial drive code in XUB can do 4 times that much but that's with polling only - no IRQs.