On at 2026-05-01 12:24:15 -0400, Jerome Shidel via Freedos-devel
<[email protected]> wrote:
>
>
>Well, there are a couple things when it comes to using SRDISK instead of
>SHSURDRV.
>
>First, SHSURDRV was chosen because of its ability to reserve RAM for program
>usage.
Which I am suggesting could be replicated in my SRDISK fork.
>Second, since it was the preferred RAM drive, it is unknown how well various
>systems will support SRDISK. It is very possible that SRDISK is supported by
>more systems than SHSURDRV. It is known that QEMU does not like SHSURDRV and
>the RAM drive initialization process simply defaults to using SRDISK on that
>virtual machine.
I don't understand this logic in fdramdrv.bat [4]:
"%1" == "ALTDRVR" goto Alternate
vinfo /m
if errorlevel 103 goto NotQEMU
REM only initialize QEMU with alternate driver
if errorlevel 102 goto Done
goto NotQEMU
Is qemu the "errorlevel 102" case?
> For all other platforms, it attempts to use SHSURDRV first. If SHSURDRV fails
> to create one it then falls back to trying some smaller RAM disks using
> SRDISK.
>
>Third, there seems to be no option to get SRDISK to start with a specific
>drive letter. Say, assign it to the first available drive starting with R:. It
>always assigned to the first drive letter, often C:.
There's the srdummy device [1] which can be used to reserve drive letters until
a certain one is reached. And you do use devload to load srdxms.sys, right?
There's a /D switch to devload [2] that selects the first drive to use, which I
also believe I improved in my fork of devload. (Okay so the improvement to that
[3] was just to work better when multiple drives are installed by a single
devload invocation. Which doesn't seem to be your use case.)
>The logic which initializes the RAM drive is contained in two files on the
>LiveCD. These are in the RBE3’s project at
>https://gitlab.com/FreeDOS/OS/builder/-/tree/master/tools/dosfiles?ref_type=heads
>
><https://gitlab.com/FreeDOS/OS/builder/-/tree/master/tools/dosfiles?ref_type=heads>
>
>The files are "hydra-autoexec.bat” which calls the “fdramdrv.bat” with
>settings for SHSURDRV using decreasing sizes at various boot stages until one
>is created. If it is not capable of initializing a RAM drive, eventually it
>calls FDRAMDRV again using a special command line option. That option tells
>the batch to try again with smaller sizes using SRDISK.
Yes, that [5] is using devload to load srdxms.sys. (In my fork, there's several
.exe files that include one or several of the device drivers as well as the
formatting program.) You're passing a drive letter to the device driver, this
doesn't do what you want if I understand correctly. See [6]. You can pass /DR
to devload instead (make sure to put it before the srdisk device driver
filename).
Oh, you're using shsurdrv /C /QQ *and* redirecting its output to >NUL. This (if
successful) will TSR using 21.31 rather than 21.4C, leaking the SFT entry for
the NUL redirection. SHSURDRV doesn't yet free file handles when it uses 21.31.
As noted in the list (even before our updates) this leaks SFTs [7].
You don't need >NUL because of /QQ. And you also don't need /C probably, though
it may cause fragmentation if no sufficient UMB is available, I'm not sure.
>That whole process is done in three steps for a reason. If the initial larger
>RAM disk is created, then the LiveCD knowns it can move the entire booted OS
>onto the RAM drive. This provides faster performance once booted and permits
>the CD to be removed from the Drive and the user to insert a game disk or
>something else without having any issues. If a smaller RAM disk is created, it
>may put some of the OS on that RAM drive. But, the OS cannot be used reliably
>without the CD inserted. Finally, if all else fails, it will attempt to create
>a small drive in order to allow I/O redirection.
>
>Also, the larger RAM drive permits the user to use programs like FDIMPLES to
>install other packages from the LiveCD or BonusCD into the running OS on the
>RAM drive for testing and such without making any changes to the hard drive in
>the system.
Regards,
ecm
[1]: https://hg.pushbx.org/ecm/srdisk/file/bbdae817d9a0/srdisk.doc#l300
[2]: https://hg.pushbx.org/ecm/devload/file/f15a5ff2a542/devload.asm#l1937
[3]: https://hg.pushbx.org/ecm/devload/rev/3058585ab204
[4]:
https://gitlab.com/FreeDOS/OS/builder/-/blob/master/tools/dosfiles/fdramdrv.bat?ref_type=heads#L12
[5]:
https://gitlab.com/FreeDOS/OS/builder/-/blob/master/tools/dosfiles/fdramdrv.bat?ref_type=heads#L32
[6]: https://hg.pushbx.org/ecm/srdisk/file/bbdae817d9a0/srdisk.doc#l195
[7]:
https://github.com/LoopZ/TheList/blob/aa01e51a/source/Interrupt%20List/INT%2021%20DOS%20Function%20Calls/INT%202131%20DOS%202%20TERMINATE%20AND%20STAY%20RESIDENT.txt#L29
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
