DOS from win 98SE, so it must be v. 7.10.

I pulled out my P2 333 running Windows 98SE and my Pentium (Classic) 200 running Windows 95 OSR2, both using DOS 7.10, booted into Safe Mode (Command Prompt Only) so that no memory managers were loaded, and MemInfo and Reveal both worked.

I also grabbed 30MB of floppy images and used that for testing XMove (leaving originals alone and using a copy of the folder), and I did find a bug where the first folder found wasn't getting moved, and therefore the process was erroring out. I was able to find and fix that bug, but I couldn't replicate the original bug so I'm hoping it's fixed.

Ok. Even, if I can't find any sence in this, probably my PII system is too picky. I will just not use the problematic utilities without DOS memory managers loaded.

As for XMOVE, I still haven't tested v.2.21.

EDIT:

OzzFan wrote on 2026-05-08, 22:39:

I pulled out my P2 333 running Windows 98SE and my Pentium (Classic) 200 running Windows 95 OSR2, both using DOS 7.10, booted into Safe Mode (Command Prompt Only) so that no memory managers were loaded, and MemInfo and Reveal both worked.

"Command prompt only" mode doesn't stop HIMEM.SYS from loading in win 98SE/m$-DOS 7.10. Win 98SE "DOS" always loads himem.sys, regardless of config.sys

If you still want to replicate my case, try to disable HIMEM.SYS loading on boot. At least, now we know, that the reason for REVEAL's and MEMINFO's normal operation is not related to usage of EMM386.EXE 😀

Safe Mode Command Prompt Only, the option I selected which is different from Command Prompt Only, in fact doesn't load HIMEM.SYS.

Ok, I see. Than I have no explanation why I still have exactly the same problem with the fixed utilities.

Finally I got the problem. I was misled by the lack of the message "HIMEM is testing extended memory… done" on DOS 7.10 booting in my current test configuration. Actually HIMEM.SYS always loads (no matter, if it does or it does not present in my CONFIG.SYS), except when I press <F8> on boot and then select "Safe mode command prompt only".

So, the REVEAL and MEMINFO version 2.21 work fine when HIMEM.SYS and EMM386.EXE are loaded or when both HIMEM.SYS and EMM386.EXE are not loaded, but these utilities hang when only HIMEM.SYS is loaded. Very weird situation.

HIMEM.SYS from m$-DOS 7.10 alone is the culprit.

I almost forgot... MEMINFO reports different amount of free conventional memory (largest executable program) compared to standard DOS MEM command. Is memory occupied by MEMINFO excluded form the total free conventional memory calculations?

REVEAL's CPU benchmark results now seem consistent.

So that's an interesting find and it narrows down the code path I should focus on. In that section of code, I primarily use software interrupt 67h to check for the existence of third-party memory managers like QEMM and Netroom. Homing in on this, I looked into possible changes in interrupt 67h and discovered that Microsoft did change the behavior in DOS 7.x. Specifically, when HIMEM.SYS is loaded without EMM386, it leaves int 67h as a bare IRET instruction and leaves the CPU registers in an unpredictable state.

I suspect this to be the source of the lockups.

I think the proper way to handle this is that I need to check that int 67h is attached to a real service before calling it. I'll have to look into implementing this and testing it out.

Good catch on MemInfo. Yes, I forgot to subtract the application's RAM usage from the output to give a more realistic picture of available RAM. That's a relatively easy fix.

Hi, Charlie,
Sorry, that I'm bothering you with those bugs. Most users probably won't even notice them, since they only appear under very specific conditions.

OzzFan wrote on 2026-05-13, 13:20:

So that's an interesting find and it narrows down the code path I should focus on. In that section of code, I primarily use software interrupt 67h to check for the existence of third-party memory managers like QEMM and Netroom. Homing in on this, I looked into possible changes in interrupt 67h and discovered that Microsoft did change the behavior in DOS 7.x. Specifically, when HIMEM.SYS is loaded without EMM386, it leaves int 67h as a bare IRET instruction and leaves the CPU registers in an unpredictable state.

I suspect this to be the source of the lockups.

Great finding. This seems completely logical and reasonable as an explanation for the bug.

OzzFan wrote on 2026-05-13, 13:20:

I think the proper way to handle this is that I need to check that int 67h is attached to a real service before calling it. I'll have to look into implementing this and testing it out.

You know your code best, I can only guess.

OzzFan wrote on 2026-05-13, 13:20:

Good catch on MemInfo. Yes, I forgot to subtract the application's RAM usage from the output to give a more realistic picture of available RAM. That's a relatively easy fix.

Sometimes I pay a lot of attention to the details. Yeah, that one will be the easiest bug to fix 😀

And I still haven't tried win 3.1x utilities...

Yet another unexpected and unpleasant surprise. Today I tried to use FINDFILE.EXE in my test PII system for the first time and it also gave me runtime "R6000 error" (or it was "R600"?) with stack overflow.

Ok, I think I've fixed all reported bugs. These are still part of the 6.21 series so the version number hasn't changed.

Keep the bug reports coming. I don't want to put out bad software that no one wants to use.

I can now confirm. Finally MEMINFO.EXE and REVEAL.EXE work fine with HIMEM.SYS from m$-DOS 7.10. FINDFILE.EXE now works without the error while using "wildcards" (* and ?). XMOVE.EXE - I didn't tested it with big directory structures, for small directory trees works fine and faster than previous problematic version. Thanks!

The rest of the DOS utilities:
CDD.COM - seems Ok
CDIR.EXE - seems Ok
FILEDATE.COM - not tested, since I'm not sure if it uses writing in FAT and I don't know how it will behave on FAT32
SUPERBAT.COM - still not used, so not tested
SYSCLOCK.COM - seems Ok

I'm not sure why almost none of the forum users are willing to provide feedback on such DOS software projects. Until now I had only one case to communicate with a developer, who hardly accepts any suggestions for improving his DOS software at the "user level", but most of the developers here are open for suggestions and bug reports.

Wrapping up all those fixes into a new release: version 6.21.

• Added CTL3D.DLL detection to most Windows applications.
• Added Windows for Workgroups support to ASSOCEDT.EXE.
• Fixed shared bug in REVEAL.EXE and MEMINFO.EXE causing the system to hang trying to detect EMS while in real mode (no XMS memory manager loaded).
• Fixed bug in REVEAL.EXE and MEMINFO.EXE under DOS 7.x when only an XMS driver is loaded, the system would hang.
• Fixed number of installed floppies detection in REVEAL.EXE.
• Fixed bug in REVEAL.EXE's version display of TSRs.
• Fixed bug in XMOVE.EXE running out of stack space when moving large directories (greater than 100).
• Fixed MEMINFO.EXE's output for free conventional memory and largest executable program size not showing correct info.
• Fixed bug in FINDFILE.EXE when used on large hard drives, the search stack would overflow and crash the system.
• Improved XMOVE.EXE's move process by switching to buffered I/O instead of bit copying.
• Improved the speed of XMOVE.EXE when moving files on the same partition by updating FAT records.
• Improved REVEAL.EXE's ROM string detection and removed trailing garbage characters.
• Changed REVEAL.EXE's benchmark to run for 2 seconds per test, changed the instruction mix, and improved benchmark timing granularity.
• Changed REVEAL.EXE's benchmark results to kilo-operations (1000).

Download on my newly re-designed Dobson Utilities website at http://www.shelteringoak.com/du.

aVd wrote on 2026-05-16, 06:16:

FILEDATE.COM - not tested, since I'm not sure if it uses writing in FAT and I don't know how it will behave on FAT32

FILEDATE works fine on FAT32. The only problem is, that it does not accept only one (/D or /T) of the two command line parameters, so to change only file date or file time.