> On Apr 30, 2026, at 1:51 PM, E. C. Masloch via Freedos-devel > <[email protected]> wrote: > > On at 2026-04-30 12:05:54 -0400, Jerome Shidel via Freedos-devel wrote: >> SHSUFDRV and SHSURDRV are both part of the same package SHSUFDRV. >> >> SHSURDRV.EXE is used on most systems and virtual machines by >> the primary FreeDOS installer to create temporary storage space >> when no hard disk has yet been partitioned and formatted. It is >> preferred over using SRDISK because it can be told to keep a >> minimum amount of XMS memory available for programs on systems >> whose available memory is not known. If SHSURDRV.EXE fails to >> allocate a RAM drive (Or always under QEMU), it will fall back >> and attempt to allocate a RAM drive using SRDISK. >> >> While the FreeDOS installer “can” run without any RAM drive or >> temporary storage, removing the SHSUFDRV package will greatly >> curtail some of its functionality which occurs prior to >> partitioning and formatting the internal disk on many systems. >> Only relying on SRDISK (when supported) can also result in >> having no free XMS when booting from the LiveCD, which could >> prevent the user from trying various games and programs. > > What exact behaviour do you want to have? I already forked SRDISK > a while back, see website [1] and repo [2]. It does have an > option called /FREEMEM: already, though it is possible this does > not work the way you desire. > > From a quick look at SHSURDRV, it appears that it works like so: > > 1. Allocate /R memory > 1.a. if successful store handle in XMSrsrv > 1.b. if failed do ignore and continue > 2. Allocate actual memory to use for all drives > 2.a. if all drives failed, abort installation > 3. Free /R memory (handle in XMSrsrv) if it was allocated > 4. Terminate process (TSR using 21.4C or 21.31 if installed) > > Do you use /T as well? What it does for that seems to be only > slightly more complicated, I could create a description of that > too. > > I didn't look into SRDISK's /FREEMEM as much yet. However, I do > believe it can be made to work in a similar way to SHSURDRV's /R. > > Regards, > ecm > > > [1]: https://pushbx.org/ecm/web/#projects-srdisk > <https://pushbx.org/ecm/web/#projects-srdisk> > [2]: https://hg.pushbx.org/ecm/srdisk/ <https://hg.pushbx.org/ecm/srdisk/> >
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. 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. 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:. 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. 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. :-) Jerome
_______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
