Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Debian Stretch can't do DPMI anymore!
7 views
Skip to first unread message
Ivan Shmakov
Nov 10, 2017, 9:40:29 AM11/10/17
to
>>>>> Charlie Gibbs <cgi...@kltpzyxm.invalid> writes:
I'm cross-posting this to news:alt.os.free-dos, for I suggest
using FreeDOS (under QEMU/KVM) instead of DOSEmu or DOSBox.
I'm also cross-posting to news:comp.unix.dos-under-unix just in
case someone may be following that group, but omitting it from
Followup-To: (as that seems somewhat unlikely.)
Please take care to remove news:comp.os.linux.misc as well if
your reply concerns FreeDOS only (and has nothing to do with
GNU/Linux per se.)
> I recently upgraded from a pre-release version of Debian Jessie to
> the latest version of Stretch (9.2). Things are generally improved,
(Most of all, Bash no longer crashes in certain cases involving
terminal signals and background jobs; IMO.)
> but I've lost the ability to do the MS-DOS compile that I still run
> from time to time. Normally I run dosemu, but I tried DOSbox and it
> crashes as well.
[...]
> # echo 1 > /proc/sys/abi/ldt16
> This command no longer works; it now generates the error message:
> bash: /proc/sys/abi/ldt16: No such file or directory.
> I've reported this as bug #880547 on the Debian bug tracking system.
My best guess is that a kernel compatibility feature necessary
for DPMI emulation in DOSEmu isn't enabled in the latest image
that comes with Debian 9.
> dosemu is the latest version; it reports 1.4.0.8, although "apt-get
> install dosemu" reports 1.4.0.7+20130105+b028d3f-2+b1.
> DOSbox reports the following error:
> Exit to error: DRC64:Unhandled memory reference
> Linux killer-penguin 4.0.0-4-amd64 #1 SMP Debian 4.9.51-1
> (2017-09-28) x86_64 GNU/Linux
> DOSbox version 0.74
> Does anyone have a workaround?
I'd just run FreeDOS under QEMU/KVM. I recall that not only it
offered a more stable and featureful environment (via thorough
emulation), but also had very good performance (so long as KVM
is available and enabled, at the least.)
Let's see if I still can get it running...
First of all, I'd need a large file to host the "C:" filesystem.
(And this seems like the biggest disadvantage of using QEMU, as
both DOSBox and DOSEmu support accessing the host's filesystem.
Then again, this isolation may be beneficial to host's security.)
I'd use a sparse file:
$ sh -Cexc 'dd bs=4k count=1 seek=$((-1 + 64 * 1024 / 4)) \
< /dev/zero > .dos-c' ; ### 64 MiB ###
Now I create an MBR partition table (or "disk label") and the
only "FAT16" (MBR code 6) bootable partition:
$ /sbin/parted -- .dos-c mklabel msdos
$ /sbin/parted -- .dos-c mkpart primary fat16 1mib 100%
$ /sbin/parted -- .dos-c set 1 boot on
$ /sbin/parted -- .dos-c u mib p
Model: (file)
Disk .dos-c: 64.0MiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1.00MiB 64.0MiB 63.0MiB primary fat16 boot, lba
$
(As an aside, the steps above are what my old "mkdosdisk" Bash
script does; see Debian Bug#533677. One of these days I should
rewrite it for style and POSIX compliance...)
Now I configure Mtools so that its "C:" is associated with the
first partition in that file. Also, I'm going to copy files
that constitute Balder 1.0 (an old and, sadly, unmaintained
single-floppy FreeDOS distribution) there, so I need to
configure Balder's image location in ~/.mtoolsrc as well; like:
$ cat < ~/.mtoolsrc
drive c: file="/home/private/users/ivan/.dos-c" partition=1
drive f: file=".../balder10.img"
$
Now I can create a FAT filesystem on the partition and copy
Balder's files to "C:/FDOS", and also its AUTOEXEC.BAT and
FDCONFIG.SYS (modified to reference /FDOS instead of the root
directory) to "C:/":
$ mformat c:
$ mdir c:
Volume in drive C has no label
Volume Serial Number is 72BA-D46F
Directory for C:/
No files
65 785 856 bytes free
$ mmd c:/fdos
$ mcopy -s f: c:/fdos/
$ mcopy -- f:/autoexec.bat c:/
$ mcopy -- f:/fdconfig.sys - \
| sed -e 's,=\(\w\+\.\w\+\)\>,=fdos/\1,' \
| mcopy -- - c:fdconfig.sys
$ mdir c:
Volume in drive C has no label
Volume Serial Number is 72BA-D46F
Directory for C:/
fdos <DIR> 2017-11-10 13:23
KERNEL SYS 45341 2006-08-17 21:58
COMMAND COM 66945 2006-08-28 12:37
autoexec bat 385 2017-11-10 13:45
fdconfig sys 921 2017-11-10 14:20
5 files 113 552 bytes
64 495 616 bytes free
$
(On a second thought, I should've used mcopy "-m" option, too.)
The only step left is to boot from the Balder's image and make
"C:" bootable with "SYS". (I will run QEMU on a tty, per
-display curses, to make it easier to copy the output here.)
$ qemu-system-i386 \
-m 32 -display curses \
-machine type=pc-i440fx-2.1,accel=kvm \
-boot order=a \
-drive file=.../balder10.img,if=floppy,readonly \
-drive file=.dos-c,if=ide
...
FreeDOS HIMEM64 3.26 [Aug 25 2006] (c) 1995, Till Gerken 2001-2006 tom ehlert
HIMEM - Always On A20 method used
Kernel: allocated 41 Diskbuffers = 21812 Bytes in HMA
CuteMouse v1.9.1 alpha 1 [FreeDOS]
Installed at PS/2 port
A:\>sys c:
FreeDOS System Installer v3.2, Aug 18 2006
Processing boot sector...
Reading old bootsector from drive C:
FAT type: FAT16
Old boot sector values: sectors/track: 32, heads: 4, hidden: 2048
Default and new boot sector values: sectors/track: 32, heads: 4, hidden: 2048
Root dir entries = 512
FAT starts at sector (2048 + 1)
Root directory starts at sector (PREVIOUS + 251 * 2)
Boot sector kernel name set to KERNEL SYS
Boot sector load segment set to 60h
writing new bootsector to drive C:
Copying KERNEL.SYS...
45341 Bytes transferred
Copying COMMAND.COM...
66945 Bytes transferred
System transferred.
A:\>fdapm /pureoff
Performing action: PUREOFF
Turning OFF system...
Resetting DOS filesystem and BIOS disk handler...
$
(Alternatively, instead of copying files and running SYS from the
Balder's image, a full-weight FreeDOS installer can be used.)
Finally, the newly installed system can be booted like:
$ qemu-system-i386 \
-m 32 -display curses \
-machine type=pc-i440fx-2.1,accel=kvm \
-boot order=c \
-drive file=.dos-c,if=ide
...
FreeDOS HIMEM64 3.26 [Aug 25 2006] (c) 1995, Till Gerken 2001-2006 tom ehlert
HIMEM - Always On A20 method used
Kernel: allocated 41 Diskbuffers = 21812 Bytes in HMA
C:\>
--
FSF associate member #7257 np. What's New -- Illya Leonov
I'm cross-posting this to news:alt.os.free-dos, for I suggest
using FreeDOS (under QEMU/KVM) instead of DOSEmu or DOSBox.
I'm also cross-posting to news:comp.unix.dos-under-unix just in
case someone may be following that group, but omitting it from
Followup-To: (as that seems somewhat unlikely.)
Please take care to remove news:comp.os.linux.misc as well if
your reply concerns FreeDOS only (and has nothing to do with
GNU/Linux per se.)
> I recently upgraded from a pre-release version of Debian Jessie to
> the latest version of Stretch (9.2). Things are generally improved,
(Most of all, Bash no longer crashes in certain cases involving
terminal signals and background jobs; IMO.)
> but I've lost the ability to do the MS-DOS compile that I still run
> from time to time. Normally I run dosemu, but I tried DOSbox and it
> crashes as well.
[...]
> # echo 1 > /proc/sys/abi/ldt16
> This command no longer works; it now generates the error message:
> bash: /proc/sys/abi/ldt16: No such file or directory.
> I've reported this as bug #880547 on the Debian bug tracking system.
My best guess is that a kernel compatibility feature necessary
for DPMI emulation in DOSEmu isn't enabled in the latest image
that comes with Debian 9.
> dosemu is the latest version; it reports 1.4.0.8, although "apt-get
> install dosemu" reports 1.4.0.7+20130105+b028d3f-2+b1.
> DOSbox reports the following error:
> Exit to error: DRC64:Unhandled memory reference
> Linux killer-penguin 4.0.0-4-amd64 #1 SMP Debian 4.9.51-1
> (2017-09-28) x86_64 GNU/Linux
> DOSbox version 0.74
> Does anyone have a workaround?
I'd just run FreeDOS under QEMU/KVM. I recall that not only it
offered a more stable and featureful environment (via thorough
emulation), but also had very good performance (so long as KVM
is available and enabled, at the least.)
Let's see if I still can get it running...
First of all, I'd need a large file to host the "C:" filesystem.
(And this seems like the biggest disadvantage of using QEMU, as
both DOSBox and DOSEmu support accessing the host's filesystem.
Then again, this isolation may be beneficial to host's security.)
I'd use a sparse file:
$ sh -Cexc 'dd bs=4k count=1 seek=$((-1 + 64 * 1024 / 4)) \
< /dev/zero > .dos-c' ; ### 64 MiB ###
Now I create an MBR partition table (or "disk label") and the
only "FAT16" (MBR code 6) bootable partition:
$ /sbin/parted -- .dos-c mklabel msdos
$ /sbin/parted -- .dos-c mkpart primary fat16 1mib 100%
$ /sbin/parted -- .dos-c set 1 boot on
$ /sbin/parted -- .dos-c u mib p
Model: (file)
Disk .dos-c: 64.0MiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1.00MiB 64.0MiB 63.0MiB primary fat16 boot, lba
$
(As an aside, the steps above are what my old "mkdosdisk" Bash
script does; see Debian Bug#533677. One of these days I should
rewrite it for style and POSIX compliance...)
Now I configure Mtools so that its "C:" is associated with the
first partition in that file. Also, I'm going to copy files
that constitute Balder 1.0 (an old and, sadly, unmaintained
single-floppy FreeDOS distribution) there, so I need to
configure Balder's image location in ~/.mtoolsrc as well; like:
$ cat < ~/.mtoolsrc
drive c: file="/home/private/users/ivan/.dos-c" partition=1
drive f: file=".../balder10.img"
$
Now I can create a FAT filesystem on the partition and copy
Balder's files to "C:/FDOS", and also its AUTOEXEC.BAT and
FDCONFIG.SYS (modified to reference /FDOS instead of the root
directory) to "C:/":
$ mformat c:
$ mdir c:
Volume in drive C has no label
Volume Serial Number is 72BA-D46F
Directory for C:/
No files
65 785 856 bytes free
$ mmd c:/fdos
$ mcopy -s f: c:/fdos/
$ mcopy -- f:/autoexec.bat c:/
$ mcopy -- f:/fdconfig.sys - \
| sed -e 's,=\(\w\+\.\w\+\)\>,=fdos/\1,' \
| mcopy -- - c:fdconfig.sys
$ mdir c:
Volume in drive C has no label
Volume Serial Number is 72BA-D46F
Directory for C:/
fdos <DIR> 2017-11-10 13:23
KERNEL SYS 45341 2006-08-17 21:58
COMMAND COM 66945 2006-08-28 12:37
autoexec bat 385 2017-11-10 13:45
fdconfig sys 921 2017-11-10 14:20
5 files 113 552 bytes
64 495 616 bytes free
$
(On a second thought, I should've used mcopy "-m" option, too.)
The only step left is to boot from the Balder's image and make
"C:" bootable with "SYS". (I will run QEMU on a tty, per
-display curses, to make it easier to copy the output here.)
$ qemu-system-i386 \
-m 32 -display curses \
-machine type=pc-i440fx-2.1,accel=kvm \
-boot order=a \
-drive file=.../balder10.img,if=floppy,readonly \
-drive file=.dos-c,if=ide
...
FreeDOS HIMEM64 3.26 [Aug 25 2006] (c) 1995, Till Gerken 2001-2006 tom ehlert
HIMEM - Always On A20 method used
Kernel: allocated 41 Diskbuffers = 21812 Bytes in HMA
CuteMouse v1.9.1 alpha 1 [FreeDOS]
Installed at PS/2 port
A:\>sys c:
FreeDOS System Installer v3.2, Aug 18 2006
Processing boot sector...
Reading old bootsector from drive C:
FAT type: FAT16
Old boot sector values: sectors/track: 32, heads: 4, hidden: 2048
Default and new boot sector values: sectors/track: 32, heads: 4, hidden: 2048
Root dir entries = 512
FAT starts at sector (2048 + 1)
Root directory starts at sector (PREVIOUS + 251 * 2)
Boot sector kernel name set to KERNEL SYS
Boot sector load segment set to 60h
writing new bootsector to drive C:
Copying KERNEL.SYS...
45341 Bytes transferred
Copying COMMAND.COM...
66945 Bytes transferred
System transferred.
A:\>fdapm /pureoff
Performing action: PUREOFF
Turning OFF system...
Resetting DOS filesystem and BIOS disk handler...
$
(Alternatively, instead of copying files and running SYS from the
Balder's image, a full-weight FreeDOS installer can be used.)
Finally, the newly installed system can be booted like:
$ qemu-system-i386 \
-m 32 -display curses \
-machine type=pc-i440fx-2.1,accel=kvm \
-boot order=c \
-drive file=.dos-c,if=ide
...
FreeDOS HIMEM64 3.26 [Aug 25 2006] (c) 1995, Till Gerken 2001-2006 tom ehlert
HIMEM - Always On A20 method used
Kernel: allocated 41 Diskbuffers = 21812 Bytes in HMA
C:\>
--
FSF associate member #7257 np. What's New -- Illya Leonov
0 new messages