Re: [Freedos-devel] why is shsufdrv still in the live CD?

Fritz Mueller via Freedos-devel Wed, 29 Apr 2026 11:11:50 -0700

Thanks!

This is the result that I got from KI slop when I entered the source code (there is no version 1.11 or 3.0 available!), as I am no programmer, I do not know how much is true, but I saw the result:

The incompatibility of SHSUFDRV (specifically this 1.02 version from 2005) with FreeDOS stems from the fact that this driver is a "low-level hack." It bypasses standard APIs and directly manipulates the internal memory structures of the DOS kernel.

While FreeDOS is highly compatible with MS-DOS at the application level, its internal kernel structures (how it manages drives and memory) differ significantly.

Here are the primary technical reasons why this code fails under FreeDOS:

1. SDA (Swappable Data Area) & Reentrancy

The biggest issue is in the ReadImage routine (starting at line 260).

The Problem: A block device driver is normally called by the DOS kernel. For the driver to then call DOS again (Int 21h) to read the image file, it must perform a "reentrant" call.

The Hack: To prevent a system crash, the driver tries to manually save and restore the SDA (lines 270-305). The SDA contains the internal state of DOS.

Why FreeDOS fails: The structure, size, and location of the SDA in FreeDOS are different from MS-DOS. When SHSUFDRV tries to copy the SDA using MS-DOS assumptions, it either fails to set the InDOS flag correctly or corrupts FreeDOS’s internal state, leading to an immediate crash or a "System Halted" error.

2. Hardcoded Internal Structures (CDS and DPB)

The driver directly edits the CDS (Current Directory Structure, line 108) and DPB (Drive Parameter Block, line 136).

The Problem: In the SetRoot function (line 495), the driver calculates memory offsets to "force" new drives into the system's list.

Why FreeDOS fails: FreeDOS (especially the 32-bit FAT kernel) uses different offsets and sizes for these structures. For example, if the CDS_size in FreeDOS is 88 bytes instead of the 67-71 bytes expected by the driver, the driver will write its data into the wrong memory location, corrupting the kernel's drive table.

3. Self-Relocation into the PSP

The driver uses a very unusual installation method: it relocates its resident code into its own PSP (Program Segment Prefix) and then shrinks its memory block (lines 570-590).

The Problem: FreeDOS memory managers (like JEMMEX) and the FreeDOS kernel handle TSR (Terminate and Stay Resident) memory allocation more strictly than older MS-DOS versions. This "self-moving" trick often triggers memory allocation errors or conflicts with the FreeDOS "high-loading" logic.

4. Recursive File I/O

The driver is a "Block Device Driver" that uses "File I/O" to function. This is a circular dependency. MS-DOS allowed this if the SDA was swapped perfectly. FreeDOS’s design is more modular, and its kernel often blocks file access requests that originate from within the strategy routine of another block device to prevent infinite loops.

Recommended Alternatives for FreeDOS:

If you need to mount disk images under FreeDOS, the following methods are much more stable:

MEMDISK: Part of the Syslinux project. It works at the BIOS level (Int 13h) rather than the DOS level. It is the gold standard for mounting floppy/hard disk images in a way that is invisible to the DOS kernel.

Updated SHSUFDRV: There are modified versions of the SHSU tools (often found in FreeDOS distributions like 1.2 or 1.3) that have been patched specifically to recognize the FreeDOS kernel structures.

VFD (Virtual Floppy Drive): Some DOS-native virtual drive creators use standard BIOS hooks rather than SDA-swapping, making them more compatible with FreeDOS.

Summary: This assembly code is a masterclass in MS-DOS optimization, but it relies on "undocumented DOS" internals that FreeDOS simply does not replicate 1:1.

Sent: Wednesday, April 29, 2026 at 6:04 PM
From: "Jim Hall via Freedos-devel" <[email protected]>
To: "Technical discussion and questions for FreeDOS developers." <[email protected]>
Cc: "Jim Hall" <[email protected]>
Subject: Re: [Freedos-devel] why is shsufdrv still in the live CD?

Interesting that it works on MS-DOS but not FreeDOS. And the LSM entry
says Jason is "looking for a new maintainer" so it's not likely to be
fixed anyway. (Also, the website for it is dead.)

I copied a 1.44MB floppy image to my C: drive and tried to test it on
T2604. You're right, it doesn't work:

:: C:\>shsufdrv floppy.img
:: SHSUFDRV by Jason Hood <[email protected]>.
:: Version 1.02 (21 December, 2005). Freeware.
:: http://shsufdrv.adoxa.cjb.net/
::
:: C:\FLOPPY.IMG : Drive F
::
:: SHSUFDRV image driver installed.
:: C:\>dir F:
:: Volume in drive F is R
:: Volume Serial Number is 1F17-1CF6
:: Directory of F:\
::
:: α⌠u☻OA├ 0 00-00-80 12:00a
:: τ♠v♦<ar♦ áτ♠ 3,892,671,558 00-00-38 7:32a
:: 2 file(s) 3,892,671,558 bytes
:: 0 dir(s) 382,976 bytes free

I agree, we should remove this from the distribution. It may be too
late to remove it for T2605 (days away) but certainly it should be
removed for T2606.

On Wed, Apr 29, 2026 at 9:09 AM Fritz Mueller wrote:
>
> Hi,
> whereas the program shsurdrv works fine, shsufdrv works on MS-DOS but not FreeDOS.
> I already asked the programmer some time ago and he confirmed this.
> So my question: Why having a program in the distribution that is not usable?
>

_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel