DOS ain't dead

I had a request (via email) to create a RAM drive greater than 4GiB. It sort of works (works on his and mine 8GiB AMD, but has issues with his 32GiB Intel) so if anyone has the time and inclination to test, that'd be great. You will need more than 4GiB RAM (in order to access super-extended memory), preferably more than 8GiB (in order to test accessing beyond 4GiB). Our testing has been simple so far: just copy large files (he was able to create a 28GiB RAM drive, copy hundreds of 64MiB files, but it fails copying a 1GiB file).

Cool!

> so if anyone has the time and inclination to test, that'd be great.

I tested and got a few errors.

My test does not need a large drive, 2 GB is ok. So I can compare the results with rdisk.com.

For testing purposes, it would be great to have a rdrv32.exe version, that's a FAT32 driver restricted to standard XMS block move calls. So one can be sure that the new XMS API is NOT the source of problems.

I tried to create that version myself, but apparently the rdrvsx32.nsm source requires a "special" version of nasm - the versions that I used were not happy with it.

---
MS-DOS forever!

> For testing purposes, it would be great to have a rdrv32.exe version,
> that's a FAT32 driver restricted to standard XMS block move calls.

Updated the zip, adding rdrvx32.exe, which uses normal extended memory (super-extended not required).

> I tried to create that version myself, but apparently the rdrvsx32.nsm
> source requires a "special" version of nasm - the versions that I used were
> not happy with it.

I originally created it with 0.98.39, but there were bugs with v2; I eventually reported those, which I think got into a 2.14 RC release, so anything earlier than that isn't going to work; it works with the current 2.15.05 (at least the Win64 version does).

> I had a request (via email) to create a
> RAM drive greater
> than 4GiB. It sort of works (works on his and mine 8GiB AMD, but has
> issues with his 32GiB Intel) so if anyone has the time and inclination to
> test, that'd be great.

Thanks very much for this FAT32 RAMdrive. It has been much-wanted for years. I tested the Super Extended Memory version, and didn't get errors either creating or copying files to a large RAMdrive. (I have 8G total RAM, but the program would only let me create a 5 GiB drive. Anything higher reported "Too big for system memory.) I'm using an Intel core i5 8250u laptop with 8GiB RAM, with CSM mode enabled in a UEFI BIOS which thankfully loads DOS bare metal.

I noticed some bugs:

-can only specify drive letter when used with the default option (specify ramdrive size in GiB), ie
rdrsx32 5,d creates a 5 GiB ramdrive in drive D
rdrsx32 5.5,d creates a 5 GiB ramdrive in drive D, the decimal point is ignored
rdrsx32 5500M,d creates a 5500M ramdrive in drive B, the first "drive" available in my system, NOT in drive d where I specified. Furthermore, this ramdrive in drive B gives many errors ("sector not" found) when writing files.

The ramdrive created in drive d works perfectly, in writing and copying files as large as 2 GiB. When attempting to decompress a .zip file containing a "blank" file of 4096MiB, DOS can't write this large file, giving errors. It is related to DOS not supporting unsigned filelengths, I believe. 2 GiB-1 seems to be the largest file I can create on the FAT32 RAMdrive in pure DOS (Microsoft "DOS 7.1."

Please fix the drive letter bugs, and the inability to specify floating point size of drive in GiB if possible.

The problem I found is rather complicated:

1. in config.sys, the new himemsx.exe, doslfn 0.41d and rdrvsx32 are loaded, a 4 GB ramdisk created.

2. some LFN files are copied to the ramdisk's root directory.
The LFNs need just a bit more space than what fits in a cluster ( so the root directory then has 2 clusters ).

3. a sub-directory is created in the root directory.

4. the very same files that were copied to the root directory are now copied into the sub-directory. Just before the last file is copied, everything seems ok. After the last file has been copied, there is garbarge in the sub-directory.

I verified that the problem occurs with doslfn loaded only. And it does NOT occur if both drives (src and dest) are physical drives. Might actually be a doslfn bug that is revealed by the fat32 ramdisk.

EDIT: the problem also occurs if I use rdrvx32.exe (with a 2 GB ramdisk) and the standard HimemX. So it definitely is NOT a problem of the modifed himemsx.

---
MS-DOS forever!

> I verified that the problem occurs with doslfn loaded only.

do these errors also occur without doslfn or with only short names involved?

> And it does NOT
> occur if both drives (src and dest) are physical drives. Might actually be
> a doslfn bug that is revealed by the fat32 ramdisk.

there is another difference: the ramdisk is formatted when loaded, and the formatter (integrated into RDFVSX32) is different from the external FORMAT.EXE.

if this integrated formatter is slightly off from what doslfn expects problems would also occur.

this should be easy to check by using FORMAT.EXE to re-format the ramdisk, and see if problems vanish.

> do these errors also occur without doslfn or with only short names
> involved?

No. With SFNs only, there's no problem, no matter if doslfn is loaded or not.

> this should be easy to check by using FORMAT.EXE to re-format the ramdisk,
> and see if problems vanish.

It's funny. Trying to format the ramdisk K: displays:

K:\>format k:
Formatierung Laufwerk K: nicht unterstützt.
Formatierung beendet.

>Aktuelles Laufwerk nicht mehr gültig.

... and the ramdisk has disappeared.

---
MS-DOS forever!

> Please fix the drive letter bugs, and the inability to specify floating
> point size of drive in GiB if possible.

Done, but I'll hold off uploading a new version.

> Might actually be a doslfn bug that is revealed by the fat32 ramdisk.

Confirmed, still investigating.

> this should be easy to check by using FORMAT.EXE to re-format the ramdisk, and see if problems vanish.

Format is not supported, but I could put it back if desired.

> ... and the ramdisk has disappeared.

DRVON from SHSUFDRV might restore the drive.

Can someone confirm if I have correctly setup a FAT32 RAMdrive in the first 4GB of memory (XMS). The relevant FreeDOS (RC5) FDauto.bat lines are...




devload c:\freedos\bin\himemX.exe
c:\freedos\bin\rdrvX32.exe 1400M
copy d:\nulll.txt g:\G
copy d:\1 g:\1_Gbyte
dir g:\

rem himemX.exe 6,074 bytes Oct-29-2020
rem RdrvX32.exe 3,682 bytes Mar-14-2022
rem 1400M is about the maximum available for my computer




and the output produced is



Volume in drive G is RDRVX32

Dir of G:\

1_Gbyte 1,073,741,824 ...
G 0 ...

2 file(s) 1,073,741,824 bytes
0 dir(s) 392,822,784 bytes free




I booted off a USB stick (laptop in Legacy Mode) and the USB stick is the C:\ D:\ E:\ drives and drive F is a DVD drive (in the laptop).

At present I have trouble copying a file bigger than 64Mbytes from the USB stick to a FAT32 drive in the Super Extended Memory (hence why I wanted to see if I could copy to a FAT32 drive in normal Extended Memory).


Question - how can I tell if I actually have a FAT32 drive? In windows I can use File Explorer to tell me - but in DOS?

> Can someone confirm if I have correctly setup a FAT32 RAMdrive in the first
> 4GB of memory (XMS).

> devload c:\freedos\bin\himemX.exe
> c:\freedos\bin\rdrvX32.exe 1400M

HimemX won't access beyond 4GiB, so ergo it's in the first 4GiB.

> Volume in drive G is RDRVX32

The drive is created...

> 2 file(s) 1,073,741,824 bytes
> 0 dir(s) 392,822,784 bytes free

at the size requested (~1.4GiB; the size is how much XMS to request, not how big the drive itself should be, unlike my other RAM drives).

> Question - how can I tell if I actually have a FAT32 drive?

Hm, I thought FreeDOS chkdsk would tell me that FAT32 isn't supported, but now it's saying it can't read the FAT(s). Try my Trace utility. (Or take it as given, since that's all it creates.)

There seems to be a lower size limit for the FAT32 ramdisk: 260 MB. Trying to create a disk with 256 MB results in error message "FAT is corrupt" ( translated to English ) and the number of clusters for that drive is zero. Is this some FAT32 limitation or a bug?

---
MS-DOS forever!

> There seems to be a lower size limit for the FAT32 ramdisk: 260 MB.

I've been testing in FreeDOS and that works fine with a 16M drive. Turns out that's what caused the chkdsk issue, since it only looks at the cluster count, so the drive needs to be over 256M to be detected as FAT32. This sounds like the same thing.

> > Question - how can I tell if I actually have a FAT32 drive?
>
> Hm, I thought FreeDOS chkdsk would tell me that FAT32 isn't
> supported, but now it's saying it can't read the FAT(s). Try my
> Trace utility. (Or take it as
> given, since that's all it creates.)

Eric Auer's whichfat might tell you. (If it can detect the drive.)

---
Forum admin

@Jason

My results so far







https://www.dropbox.com/s/s3ro7z074lkqia0/FAT32_28G.png?dl=1

> Eric Auer's whichfat might tell you. (If it can detect the drive.)

It detects the drive, but uses the cluster count, too.

I've updated the zip with the drive letter fix and decimal sizes, along with a fixed DOSLFN.

> > Eric Auer's whichfat might tell you. (If it can detect the drive.)
>
> It detects the drive, but uses the cluster count, too.
>
> I've updated the zip with the drive letter fix and decimal sizes, along
> with a fixed DOSLFN.

so it was a bug in DOSLFN?

after all these years with DOSLFN in the wild with no (such) reported bugs I had assumed that it was a problem with RDRVSX32 as the bug seems to be easily reproduced.

what exactly was the bug (to satisfy our curiosity)

edit: just posting a 'fixed' DOSLFN.COM without posting also the sources is not nice behavior in my book

> I've updated the zip with the drive letter fix and decimal sizes, along
> with a fixed DOSLFN.

Thanks! The trashed sub-dir is gone now.

Btw, comparing FAT32 (rdrvsx32.exe) and FAT16 (modified shsurdrv that also uses super-extended memory) disk access times reveals that the FAT32 ramdisk is significantly slower. Copying a directory of about 6000 files ( virtually all are LFNs, total size is about 500 MB ) to the ramdisk needs about half a minute for FAT16, but 2 min & 15 seconds for FAT32. So the FAT32 option is probably only useful in rare cases.

---
MS-DOS forever!

> after all these years with DOSLFN in the wild with no (such) reported bugs
> I had assumed that it was a problem with RDRVSX32 as the bug seems to be
> easily reproduced.

I was pretty sure that the bug will be located in DOSLFN. After all, a ramdisk, once the init phase with its bureaucrazy is over, has a pretty simple job. OTOH, if you have ever looked into the DOSLFN source ...

> what exactly was the bug (to satisfy our curiosity)

I'm also eager to know.

It surely isn't the last bug in doslfn...

---
MS-DOS forever!

> > I've updated the zip with the drive letter fix and decimal sizes, along
> > with a fixed DOSLFN.
>
> Thanks! The trashed sub-dir is gone now.
>
> Btw, comparing FAT32 (rdrvsx32.exe) and FAT16 (modified shsurdrv that also
> uses super-extended memory) disk access times reveals that the FAT32
> ramdisk is significantly slower. Copying a directory of about 6000 files (
> virtually all are LFNs, total size is about 500 MB ) to the ramdisk needs
> about half a minute for FAT16, but 2 min & 15 seconds for FAT32.

to compare this in a fair way, you should have equal clustersize for both.
however a factor of 4 sounds like a bug (somewhere else).




> So the
> FAT32 option is probably only useful in rare cases.
when you want > 4GB you need FAT32. which was the requirement in the first place.

> @Jason
>
> My results so far
>
>
>
>
>
>
>
> https://www.dropbox.com/s/s3ro7z074lkqia0/FAT32_28G.png?dl=1

Very interesting.

How did you create / copy those 4095 MiB files on the ramdrive in DOS? The best I can do is 2047 MiB since my DOS (MS-DOS 7.1) doesn't support unsigned long integer seek / create. Which DOS are you using? How did you get it to support long unsigned file seeks? I assume you're on bare metal DOS?

It appears that you have 32 GiB total system RAM and the the new Ramdrive has problems with accessing beyond 24 (?) GiB.

So the
> FAT32 option is probably only useful in rare cases.

Very useful to reduce slack space (wasted space) due to large cluster sizes necessary in large FAT16 drives, when copying / storing large numbers of small files. I think a 2 GiB FAT32 drive may even use 512-byte clusters, vs 32 kb clusters for a 2 GiB FAT16 drive. The size of the FAT increases drastically when using small cluster sizes, however.

May we have the option in new rdsk32.exe to specifiy the exact cluster size of the created FAT32 ramdrive and the number of FATs and root directory entries? Does the possibility also exist to change the sector-size to 1024, 2048, or 4096 bytes?
(It doesn't hurt to ask!)

> so it was a bug in DOSLFN?
> what exactly was the bug (to satisfy our curiosity)

Incorrect cluster count when extending the directory, so the cluster wasn't being zeroed.

> edit: just posting a 'fixed' DOSLFN.COM without posting also the sources is
> not nice behavior in my book

I wanted to check it really worked first; since it has I've made a new release.

> Btw, comparing FAT32 (rdrvsx32.exe) and FAT16 (modified shsurdrv that also uses super-extended memory) disk access times reveals that the FAT32 ramdisk is significantly slower.

That might be a free space issue, try with the new doslfnms.com.

> It surely isn't the last bug in doslfn...

No one else has offered to take up maintenance.

> May we have the option in new rdsk32.exe to specifiy the exact cluster size
> of the created FAT32 ramdrive and the number of FATs

I've kept it simple and fixed it at a 4Ki cluster and 1 FAT. I don't intend to support FAT32 image files, so I don't see a need for anything else.

> and root directory entries?

FAT32 places the root directory in a cluster, so it will expand as necessary.

> Does the possibility also exist to change the sector-size to 1024,
> 2048, or 4096 bytes?

The possibility exists, but I won't be the one doing it. :)

> > @Jason
> >
> > My results so far
> >
> >
> >
> >
> >
> >
> >
> >
> https://www.dropbox.com/s/s3ro7z074lkqia0/FAT32_28G.png?dl=1
>
> Very interesting.
>
> How did you create / copy those 4095 MiB files on the ramdrive in DOS? The
> best I can do is 2047 MiB since my DOS (MS-DOS 7.1) doesn't support
> unsigned long integer seek / create. Which DOS are you using? How did you
> get it to support long unsigned file seeks? I assume you're on bare metal
> DOS?
>
> It appears that you have 32 GiB total system RAM and the the new Ramdrive
> has problems with accessing beyond 24 (?) GiB.



I created a USB BOOT stick using Rufus with the image file from FreeDOS RC5 (full usb image). Note RC5 has just recently been replaced with FreeDOS 1.3. As per guidelines from FreeDOS two partitions on the USB stick were created (the C:\ partition is only 512 Mbyte total (of which ~~400 MByte is used by FreeDOS).

I used the FreeDOS default FDCONFIG.SYS and FDAUTO.BAT as the framework for my configuration (and did some adjustments to suit my needs).

So with the laptop BIOS setup for "Legacy Mode", I boot up from the USB stick and the USB stick is C:\, D:\, E:\ drives of capacity 512 MB, 12 GB, 2 GB respectively (for my 16 GB USB stick). The hard drive of my laptop is not "visible" to the FreeDOS environment. Also (still having to sort things out), drive F:\ is the built-in DVD drive. So to answer your question - YES, working in bear metal mode (no virtual machine (VM) stuff at all).

The laptop has 32 GByte RAM (which is the maximum allowed for the INTEL i7 4th generation 4810MQ processor). Note that my laptop has a Q3 display (3200 x 1800) and because of this, I think that a big "chunk" of XMS (i.e. the first 4 GB of standard Extended Memory) is reserved for the display. When actually running FreeDOS the whole display area is used, so it seems a waste of display resolution for a DOS text based display (but this is what I have).

So the first 4 GB is XMS, the remaining 32-4 = 28 GB is SXMS. I set up a ~1.4 GB FAT32 G:\ RAMdrive in XMS, and ~28 GB FAT32 H:\ RAMdrive in SXMS. I think that the supplied digital photograph screenshot clearly indicates this. I used both WhichFAT.com and trace.com to verify the FAT size. I think that if you do the sums of bytes used + bytes free, for H:\, the result is 28 Gbyte. Now g:\ is only ~1.4 GB (in XMS), and this value is about the maximum, it seems, I can have for G:\. So I have "problems accessing all of the XMS", i.e. the first 4 GB of memory (keep in mind that maybe my Q3 display is a significant factor here).

So to sum up, 1.4 GB (G:\) + 28 GB (H:\) ~= 29.4 GB RAMdrives (total) as FAT32 appears to have been achieved. I don't know if I can "squeeze" out any more memory as RAMdrive.


As to the question of DOS version used - I don't know - it is whatever is the default settings of FreeDOS RC5 (or if you wish 1.3 official release).

Via a simple BASIC program (in windows 10), I created a 1 GByte file (1024 * 1024 *1024 bytes), the filename is "1", and copied it to my USB stick to the appropriate partition (D:\ when in bare metal metal). So the relevant lines in FDauto.bat are


copy d:\1 g:\1
copy g:\1 h:\1
copy h:\1 + h:\1 + h:\1 + h:\1 h:\4
copy h:\4 + h:\4 h:\8
copy h:\4 h:\4a
copy h:\4 h:\4b
copy h:\4 h:\4c
copy h:\4 h:\4d
copy h:\4 h:\4e

so the 1 GByte file, filename "1", on the USB stick D:\ partition, is copied to the FAT32 drive G:\ (in XMS), and this copied file is copied to the FAT32 H:\ (in SXMS). I used the old method of adding two files together (here they are plain ascii files) to generate a 4 GB file "4". However, as expected, if I try to create a 8 GB file "8"- only a 1 byte file is created.


This reply to you is very verbose - but I hope it answers all your questions.

For my testing and comparison purposes I would like to have a FAT16 ~o.7 GB RAMdrive in XMS (to supplement FAT 16 in SXMS and FAT32 in both XMS and SXMS).

I use c:\freedos\bin\xmsdsk.exe 700000 I:

but the problem is I have to keyboard answer YES to the message

XMS driver not loaded. Want to install it (y\n)?


I have devload c:\freedos\bin\himemSX.exe in the early part of FDauto.bat.


Do I need say a "special SHSURDRV_XMS.exe" or something to compliment the SHSURDRV.EXE used to create FAT16 drives in SXMS?

deleted

(realized that the source is now available).

---
MS-DOS forever!

> I use c:\freedos\bin\xmsdsk.exe 700000 I:
>
> but the problem is I have to keyboard answer YES to the message
>
> XMS driver not loaded. Want to install it (y\n)?

It's actually "XMSDSK driver", which you can autoanswer by adding /y at the end of the command.

>
> It's actually "XMSDSK driver", which you can autoanswer by adding
> /y at the end of the command.

Thanks - that works.

Now I have

FAT16 RAMdrive I:\ in XMS o.7 GB
FAT16 RAMdrive J:\ in SXMS 4 GB
FAT32 RAMdrive G:\ in XMS o.7 GB
FAT32 RAMdrive H:\ in SXMS 24 GB

to experiment regarding timings of large files.

So it seems all of SXMS is allocated in my 32 GB system.

Just for fun I did c:\freedos\bin\SHSURDRV 1000M,K: and it appeared to give me ~ 1 GB drive. Also did c:\freedos\bin\SHSURDRV 100M,L: and it appeared to give me ~ 100 MB drive. But I thought ALL SXMS has been allocated to J:\ + H:\ drives above?

When previously, I determined by trial and error, that a maximum of 1400M is available for RAMdrives (in XMS), a value of 1500M created all sorts of problems - I cannot understand at the moment how it is even possible to have the later drives K:\ (1 GB) and L:\(100 MB).


Question - Is there a DOS utility that gives me a memory map of the SXMS - i.e. so I can tell what the addresses in RAM for all the RAMdrives are?

> Btw, comparing FAT32 (rdrvsx32.exe) and FAT16 (modified shsurdrv that also
> uses super-extended memory) disk access times reveals that the FAT32
> ramdisk is significantly slower. Copying a directory of about 6000 files (
> virtually all are LFNs, total size is about 500 MB ) to the ramdisk needs
> about half a minute for FAT16, but 2 min & 15 seconds for FAT32. So the
> FAT32 option is probably only useful in rare cases.

Ok, now testing with the new doslfnms.com, things look a lot better: copying to the FAT16 ramdisk needs 15 s, while the copy to FAT32 needs 17 s.

---
MS-DOS forever!

> Question - Is there a DOS utility that gives me a memory map of the SXMS -
> i.e. so I can tell what the addresses in RAM for all the RAMdrives are?

Not sure if XMSCC will work; it does for XMS using HimemSX, but I don't know if it will pick up SXMS. But since the source is available...

> > Question - Is there a DOS utility that gives me a memory map of the SXMS
> -
> > i.e. so I can tell what the addresses in RAM for all the RAMdrives are?
>
> Not sure if XMSCC will work;
> it does for XMS using HimemSX, but I don't know if it will pick up SXMS.
> But since the source is available...

Yes, it works for me to pick up all SXMS, and sees all the > 4GiB XMS in my systems. Very good software.

Did some further experimentation with settings, now it appears for all 4 possibilities (FAT16/FAT32/XMS/SXMS) the maximum possible on my 32 GB system is



https://www.dropbox.com/s/69sbecj1xs6bac0/2022-mar-18.PNG?dl=1


Used Trace_2.01.com. In some cases cluster size of 0 bytes is reported - surely it is not possible for a bug to exist in TRACE? :) I would have thought cluster size to be 32K or 64K or something.


Is it possible to add a feature to TRACE to have displayed:-

- Total bytes (i.e. free bytes + used bytes)?

- What in RAM memory are the start and end addresses?


That way, i.e. a map of the RAMdrive for the drive being traced, I can confirm whether or not a drive is in XMS or SXMS. Because of different cluster sizes for various FAT16/32 possibilities - the addresses in HEX bytes would be probably less confusing.



> > Question - Is there a DOS utility that gives me a memory map of the SXMS
> -
> > i.e. so I can tell what the addresses in RAM for all the RAMdrives are?
>
> Not sure if XMSCC will work;
> it does for XMS using HimemSX, but I don't know if it will pick up SXMS.
> But since the source is available...


I had a look at GitHub regarding XMSCC - I am not sure that it will be suitable for me (it mentioned that it does not work with virtual drives - which I gather what a RAMdrive would be). In any case...

Question - how to create a .exe (or .com, .sys, etc) from the downloaded .zip?

Usually, in the past, everything was already built ready at the download stage and packaged in the .zip.

> Used Trace_2.01.com. In some cases cluster size of 0 bytes is reported -
> surely it is not possible for a bug to exist in TRACE? :) I would have
> thought cluster size to be 32K or 64K or something.

Yeah, 64K, which is 65536, which is 0x10000, which is 0 in 16 bits. I'll fix it later...

> Is it possible to add a feature to TRACE to have displayed:-
>
> - Total bytes (i.e. free bytes + used bytes)?

That would make sense.

> - What in RAM memory are the start and end addresses?

That would not; it would need to be done in RDRV. Probably won't bother, though.

> I had a look at GitHub regarding XMSCC - I am not sure that it will be
> suitable for me (it mentioned that it does not work with virtual drives -
> which I gather what a RAMdrive would be). In any case...

Where do you see that?

> Question - how to create a .exe (or .com, .sys, etc) from the downloaded
> .zip?

Go to Releases, get the .exe (or the .zip, which contains the exe and readme).

>
> > I had a look at GitHub regarding XMSCC ...

>
> Go to Releases, get the .exe (or the .zip, which contains the exe and
> readme).

Thanks - have it now.

I had always been downloading from GitHub using the "BIG GREEN Code Button" always clearly visible at the top section even when viewing the web page is heavily cropped by me to have many windows simultaneously visible. I suppose the not so obvious/inviting "Releases" has been always there.


So to summarize:

In sequence I created

~1.4 GB FAT32 RAMdrive in XMS G:\
~ 24 GB FAT32 RAMdrive in SXMS H:\
~ 4 GB FAT16 RAMdrive in SXMS J:\
~2.5 GB FAT16 RAMdrive in XMS I:\ (or so I thought)


With the goal of trying to establish RAMdrive addresses in the 32 GB system I used XMSCC




Blocks 1, 2 and 3 match with G:\, H:\, and J:\ BUT I:\ is not shown.

Can I use the 32-bit base address (pity it was not shown in HEX) as the boundaries of the RAMdrives (at least where the actual files go)?



Also I tried XMStat, getting



and this does show my I:\ as the last entry.



Lastly, I tied XMSStat, getting



and this does show my I:\ as the last entry. However in the region section (of I:\) it goes from a larger value to a smaller value (opposite effect compared to all other entries).


So are there bugs in XMSCC and XMSSTAT regarding my I:\ RAMdrive ?


So, I now do not know if my I:\ RAMdrive (~2.5 GB) is in the XMS or not - hence why I wanted a RAM map showing where (and ranges) things such as RAMdrives are.

> So are there bugs in XMSCC and XMSSTAT regarding my I:\ RAMdrive ?

After creating himemsx I updated xmsstat to make it show the full 40-bit addresses of EMBs. To get it, just download the newest jemm package.

---
MS-DOS forever!

The newest doslfn 0.41e may in a few cases report an error ( access denied, DOS error 5 ) which in fact is none.

I have a test case which should make doslfn emit this error, but I'm not quite sure if it will do so on another machine, so I examined the probable bug a bit on my own. If needed, I can provide the test case, of course.

The error occurs during a copy operation of a directory, containing more than 1000 files, mostly with LFNs.

The error is actually in doslfn, procedure "make_free_dirent_space":


        and     dx,not bit 3    ;weiter mit normalem Next_DirEnt
@@l1_:  jns     @@l1            ;(clears bit 3 of DL, tests sign of DH)
        call    Calc_Next_Cluster       ;there was no room for the longname
        jc      mfde_ret                ; so need to point to the new cluster
        call    _set_cur
        mov     bx,[Sektorp]
        jmp     @@l1_           ;Calc_Next_Cluster will clear sign


When Calc_Next_Cluster is called, it expects registers EAX and CL to be set correctly, but they aren't ( CL is supposed to contain a shift factor, but actually contains 0FFh!; and EAX does not contain the "user area" sector number for the directory that is to be enlarged ). So Calc_Next_Cluster fails, resulting in error 0005 to be returned.

---
MS-DOS forever!

> [XMSCC] Blocks 1, 2 and 3 match with G:\, H:\, and J:\ BUT I:\ is not shown.

Press Down or PgDn...

> I have a test case which should make doslfn emit this error, but I'm not
> quite sure if it will do so on another machine, so I examined the probable
> bug a bit on my own. If needed, I can provide the test case, of course.

Please provide the test case, in my testing the code was never executed. I did set CL, but I don't know why EAX would be wrong, since it comes directly from CurSector.

> Please provide the test case, in my testing the code was never executed. I
> did set CL, but I don't know why EAX would be wrong, since it comes
> directly from CurSector.

https://github.com/Baron-von-Riedesel/Test
https://github.com/Baron-von-Riedesel/Test/releases/download/test/Test.zip

---
MS-DOS forever!

> Please provide the test case, in my testing the code was never executed. I
> did set CL, but I don't know why EAX would be wrong, since it comes
> directly from CurSector.

Just in case the error is hard to find, there's a simple workaround:


@@l1_:  jns     @@l1            ;(clears bit 3 of DL, tests sign of DH)

;--- since the directory's size has been increased already when this code
;--- is reached, it might be sufficient to just restart the command???
        jmp make_free_dirent_space
if 0
        call    Calc_Next_Cluster       ;there was no room for the longname
        jc      mfde_retx               ; so need to point to the new cluster
        call    _set_cur
        mov     bx,[Sektorp]
        jmp     @@l1_           ;Calc_Next_Cluster will clear sign
endif


It works, AFAICS, and since this situation occurs not too often ... I'm no purist

---
MS-DOS forever!

> The error is actually in doslfn, procedure "make_free_dirent_space".

Wow, it's a wonder that ever worked. Here's an updated doslfnms (with diff from 0.41e). This time I'll hold off the release for a bit...

> Wow, it's a wonder that ever worked. Here's an updated
> doslfnms (with
> diff from 0.41e). This time I'll hold off the release for a bit...

Yes, it's fixed, nice work!

Btw, something about the dosfsck.exe tool: if it's been run to check the FAT32 ramdisk, it wants to "cure" the content of the FS-info and BS-backup sectors. Obviously it isn't happy with the sector numbers -1 as set by the ramdisk.

---
MS-DOS forever!

> Btw, something about the dosfsck.exe tool: if it's been run to check the
> FAT32 ramdisk, it wants to "cure" the content of the FS-info and BS-backup
> sectors. Obviously it isn't happy with the sector numbers -1 as set by the
> ramdisk.

FreeDOS: if the info & backup sectors are -1 don't use 'em.
dosfsck: if the info & backup sectors are 0 don't use 'em.

Oh, goody. New version of rdrvsx32 with valid info & backup sectors. A size < 100 is assumed gibibyte, otherwise mebibyte. You can also have a drive bigger than 32GiB (that was previously an implicit limit, 64Ki FAT sectors).

>
> Oh, goody. New version of
> rdrvsx32 with
> valid info & backup sectors. A size < 100 is assumed gibibyte, otherwise
> mebibyte. You can also have a drive bigger than 32GiB (that was previously
> an implicit limit, 64Ki FAT sectors).


It has been almost a week since I last did "DOS stuff", and then my system was in a more or less "usable state".

I just replaced relevant files (himemSX.exe rdrvX32.exe rdrvSX32.exe) with the ones from the quote link above and now my system DOES NOT WORK.


By the process of elimination (i.e. deleting relevant FDauto.bat one line at a time), BOTH the new rdrvX32.exe and rdrvSX32.exe create one (or both) of the following errors




Invalid Opcode at 16c2 06d9 0246 0000 0000 ...

(which is infinite scrolling on display repeating the same message)




Interrupt divide by zero,stack:
50c6 06d9 0246 0000 ...
Invalid Opcode at 006c 06d9 0217 3a00 9000
Invalid opcode at 01d4 0474 0246 08aa 08aa


or if POWER OFF (above via Alt Ctrl Del) and e.g.

rdrvSX32.exe 1
Interrupt divide by zero, stack:
1448 650e 4697 4646 02fd



In all error cases, I have to either (Alt Ctrl Del) or even (POWER OFF) to use my computer.


Should it be of any relevance, below is screenshot using xmSStat before attempting to use either rdrvX32.exe or rdrvSX32.exe

> Oh, goody. New version of
> rdrvsx32 with
> valid info & backup sectors. A size < 100 is assumed gibibyte, otherwise
> mebibyte. You can also have a drive bigger than 32GiB (that was previously
> an implicit limit, 64Ki FAT sectors).

There's a small bug in this version: the volume label entry in the root directory isn't written to the first sector of the root cluster, but to the second. This confuses MS scandisk a lot, makes it display a rather misleading error message. After clearing the volume label entry with a disk editor, the error disappears.

About doslfn: please hold off a new release! It's likely that there's still a bug in make_free_dirent_space, causing a "hang". I have no test case yet, but may be able to narrow the bug down.

---
MS-DOS forever!

> >
> > Oh, goody. New version of
> > rdrvsx32
> with
> > valid info & backup sectors. A size < 100 is assumed gibibyte,
> otherwise
> > mebibyte. You can also have a drive bigger than 32GiB (that was
> previously
> > an implicit limit, 64Ki FAT sectors).
>
>
> It has been almost a week since I last did "DOS stuff", and then my system
> was in a more or less "usable state".
>
> I just replaced relevant files (himemSX.exe rdrvX32.exe rdrvSX32.exe)
> with the ones from the quote link above and now my system DOES NOT WORK.
>
>
> By the process of elimination (i.e. deleting relevant FDauto.bat one line
> at a time), BOTH the new rdrvX32.exe and rdrvSX32.exe create one (or both)
> of the following errors

50% of bug fixing is always bug reproduction at developer's site.

as this software obviously works on other peoples' PC, you could help A LOT by
providing the minimum configuration to produce these bugs; ideally with naked device=himemsx.exe in config.sys, and rdrvx32.exe started from command line; then add additional programs until it crashes.

> By the process of elimination (i.e. deleting relevant FDauto.bat one line
> at a time), BOTH the new rdrvX32.exe and rdrvSX32.exe create one (or both)
> of the following errors

Fixed (problem with not relocating high).

> Should it be of any relevance, below is screenshot using xmSStat before
> attempting to use either rdrvX32.exe or rdrvSX32.exe

How did you take the screenshot?

> There's a small bug in this version: the volume label entry in the root
> directory isn't written to the first sector of the root cluster

Fixed. I've also set the initial free space/next cluster, so dosfsck/scandisk on a brand new drive won't complain.

Grab the new version from the old link.

> > By the process of elimination (i.e. deleting relevant FDauto.bat one
> line
> > at a time), BOTH the new rdrvX32.exe and rdrvSX32.exe create one (or
> both)
> > of the following errors
>
> Fixed (problem with not relocating high).
>


Thanks - appears to be working.

After setting up himemsx I manually rdrvX32 1 and rdvXS32 30 and it appears to be working ok (refer the 6 screenshots below)
















I then restored by recent FDauto.bat + FDconfig.sys to what it was a week ago, and it appears to be WORKING ok (like when a week ago). (refer the 7 screenshots below)

















I have yet to do very heavy testing but so far it looks OK.

>
> > Should it be of any relevance, below is screenshot using xmSStat before
> > attempting to use either rdrvX32.exe or rdrvSX32.exe
>
> How did you take the screenshot?



I used a program from st204f.zip for the screen captures.


I do not fully understand the "legal stuff" (copyrights, licensing, free-ware, share-ware, abandon-ware etc) but if you are interested in a copy of st204f.zip (assuming you cannot source it yourself from the internet) - the .zip may just happen to come into your mail (or anyone else for that matter if interested).

:)


A screenshot, as above, was much more fun than using an old digital camera, taking a digital photo of the computer screen (needing to focus, compose, adjust camera settings, etc) removing SD card (with photo) from camera, shutting down DOS computer, installing SD card (from camera) into computer (now in windows mode), sometimes adjusting windows 10 to allow it to read the SD card, converting (in windows) the photo into format suitable for BTTR, removing SD card from computer and reinstalling same into digital camera.


A long term project of mine is to try to modify the screenshot program to require a "certain single key" to activate - rather than at present three keys to press.

> I used a program from st204f.zip for the screen captures.

Ah, Screen Thief, sounds somewhat familiar.

> A screenshot, as above, was much more fun than using an old digital camera...

Yeah, it really didn't look like a photo, and it wasn't a text grab, which is what got me curious.

> A long term project of mine is to try to modify the screenshot program to
> require a "certain single key" to activate - rather than at present three
> keys to press.

Maybe try SNARF, it's Alt+S (by default, Alt is fixed, but the key is configurable).