GU>
  > I'm using a LapLink cable which is essentially a null modem cable.
  > The cable and sofware work fine when I run DOS 6.22 rather than OS/2.
  > When I try running LL in an OS/2-VDM the directory from the OS/2 machine
  > appears on the UltraLite's screen, however the remote directory will not
  > appear on the OS/2 machine, rather it gives an error reading remote
  > directory message.
GU>
  This tells us two things :
  1.  LapLink is perfectly happily running in an OS/2 Virtual DOS Machine
      (as I knew it would, since I did it myself several years ago), so
      the well-meant advice given to you about using a Virtual Machine
      Boot (otherwise known as "DOS image") or tweaking DOS_VERSION to run
      LapLink was misdirected.
  2.  LapLink is perfectly happily using the serial devices from within a
      Virtual DOS Machine in OS/2, since some data were received by your
      remote machine.  So your initial claim that LapLink couldn't use
      your serial port was in error, and the helpful advice that people
      gave to you in this regard was misdirected.
  The real cause of your problem ?
  I suspect that it's as simple as unbuffered UARTs. Remember that OS/2 is
  a multitasking operating system, where a program does not have exclusive
  use of the CPU at all times.  The problem that you have encountered is,
  essentially, that LapLink is receiving a corrupted data stream over a
  serial device.
  This is easily explained if you happen to have a 16450, or other
  unbuffered UART, for your serial hardware.  On DOS, LapLink just sits in
  a dedicated loop waiting for characters.  However, OS/2 is multitasking,
  and it is possible for a second character to be received by the UART
  before its predecessor has been read from the 1-character UART receive
  buffer, because OS/2 may be doing something else at the time that the
  character receive interrupt occurs.  This results in character loss, and
  protocol errors in programs such as LapLink.
  A buffered UART, such as a 16550, has an 8-character receive buffer, so
  RX buffer overruns like the above are much less likely on multitasking
  operating systems.
  The solution if this is the case ?  Fix your hardware.
  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01
---------------