[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shared disk (DOS)

From: Jakob Bohm
Subject: Re: shared disk (DOS)
Date: Sun, 11 Apr 2021 22:25:40 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:4.8) Goanna/20210402 Interlink/52.9.7762

On 2021-04-10 18:02, Tomas By wrote:

On Sat, 10 Apr 2021 17:57:26 +0200, Peter Maydell wrote:
This is a guest configuration question. There is no magic
"tell QEMU to use this format for a shared disk image and it
will all work" option. You'd need to run *one* guest connected
to the disk, and have it serve access to that disk over the
network, that your other guests access only as a network drive.
The page I linked to seems to talk about sharing a disk image, though.

You are both wrong about SHARE.EXE, probably due to the sloppy
documents written about it for many years.

SHARE.EXE implements the parts of the DOS kernel that handles
multiple programs (on ONE machine, not many) accessing the same
file.  It makes programs that do file locking etc. work at all.
 Running any kind of multitasking on top of DOS (like Topview or
MSWindows or a DOS-based file server) makes it extra important.

SHARE.EXE does nothing to help two DOS machines accessing the
same disk at the same time.

The only available DOS file systems are the FAT file system,
the read only CD-ROM file system and network file systems.

Thus for a writable disk, there is no DOS feature to share
a disk image, while a read only disk (where the virtual hardware
returns error for any attempt to write to disk) would work just
fine, especially because of the long DOS history of booting from
a read-only floppy and saving files on a writable floppy in the
second drive.  DOS sees (virtual) hard drives as really big
floppies that cannot be popped out of the drive/reader before
(virtual) power off.

The network file system option goes like this:

1. Install Samba on the Linux host and share a read/write directory.
  (I assume you are not ready to deal with the limited Linux support
  for IPX or NetBEUI).

2. On a DOS boot image (which will be made read only later) install
  software to access SMB file systems, such as the Microsoft network
  client that was historically used to access Windows NT or OS/2 file

3. Configure DOS to "map" the shared network location to an unused
  drive letter such as Z: on startup.

4. Finalize the configuration and shut down to make the disk image
  read only from the Linux side, typically by changing the qemu
  command line.

5. Optionally configure Qemu to make a temporary blank disk image
  available to each virtual machine as a second hard drive.  Use that
  for temporary files in your DOS programs and scripts, typically
  by setting the various environment variables such as TMP, TEMP,
   This is easier if you have an image of an empty disk that can be
  gunzipped to a file under a tmpfs just before starting qemu.

Besides networking, other ways to get data in/out of DOS are these:
  S. Tell qemu to map the virtual serial port (at extremely high
    speed) to host (Linux) side files or software, then have DOS
    code read/write there.   I hope qemu serial ports can be
    configured in a lossless mode that never overruns or underruns,
    even if the guest software can't keep up.

  F. Prepare a temporary FAT disk image (loop mount or mtools) for
    each qemu run and make it available as a floppy or 3rd disk,
    where DOS programs can read instructions and/or write results.
     Note that DOS does very little write caching, provided you wait
    2 seconds from last program exit before power off.  That's
    because back in 1980, the fastest guy at Microsoft couldn't change
    5.25" floppies faster than 2 seconds.


Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

reply via email to

[Prev in Thread] Current Thread [Next in Thread]