Happy to release v6.1!

This release has the following features:

• Added new utility: CDD.COM. Change drive and directory in a single command.
• Added CDD functionality to SUPERBAT.COM.
• Added application icons to the applications list in TASKMAN.EXE.
• Added selectable graph colors for TASKMAN.EXE.
• Added user-selectable colors for CDIR.EXE using CDIR.INI.
• Added disk space check to SETUP.EXE.
• Fixed bug in FILEDATE.COM not releasing open file handle on passing invalid date and/or time.
• Fixed bug in TASKMAN.EXE's keyboard shortcuts not working.
• Fixed bug in SYSCLOCK.COM always showing 24 time format.
• Fixed bug in CDIR.EXE when specifying just a drive, current directory would be appended.
• Fixed bug in TASKMAN.EXE when opening Run dialog, user couldn't access any open programs.
• Changed TASKMAN.EXE's Run dialog to default to first entry in run history.
• Improved REVEAL.EXE's ROM scanning routine to be more efficient.

And by popular demand, I'm including a zip file download (without SETUP.EXE). You can download them from http://www.shelteringoak.com/du

OzzFan wrote on 2026-01-18, 03:10:

Here’s a quick overview of what’s included: 🪟 For Windows 3.1x - A Task List replacement styled after NT’s Task Manager - A Time […]
Show full quote

Here’s a quick overview of what’s included:
🪟 For Windows 3.1x
- A Task List replacement styled after NT’s Task Manager
- A Time Synchronization utility (requires TCP/IP stack installed)
💾 For DOS
- A color-coded directory viewer that uses VGA colors to highlight directories and key file types. (Note: I haven’t tested it on EGA, CGA, or monochrome setups yet—feedback welcome!)
- A file locator utility
- A time stamp utility to change the date and time on files
- A system information program with built-in benchmark

📥 Download & Info
You can grab the utilities using any retro browser like IE 3.x or Netscape Navigator 2.x by visiting:
👉 http://www.shelteringoak.com/du Dobson Utilities Home Page

This latest version brings improvements to Task Manager, adding resource graphs and a bug fix.

This looks really nifty!

I appreciate it! Thanks for taking a look.

Excelent , try it in my 386dx 40mhz + 8mb ram, thanks

Releasing a new version: 6.2, bringing 4 new Windows utilities and a few bug fixes.

• Added new utility: DISKSTAT.EXE, shows disk usage information for Windows.
• Added new utility: ENHNOTE.EXE, Notepad with 65,000 byte file support.
• Added new utility: EXPLORER.EXE, Windows 95-like file manager for Windows.
• Added new utility: ASSOCEDT.EXE, File association editor for Windows.
• Added localization support to SYSCLOCK.COM.
• Fixed bug in TASKMAN.EXE not launching applications with command line parameters.
• Fixed bug in TASKMAN.EXE when running low on RAM, the used memory graph would rise above the top of the graph and onto the top of the application window.
• Fixed various bugs in REVEAL.EXE that could cause crashes.
• Fixed bug in XMOVE.EXE not moving files marked as read only.
• Fixed bug in XMOVE.EXE not setting destination file time stamps properly.
• Improved TASKMAN.EXE's error messages when failing to launch an application.
• Changed REVEAL.EXE's benchmark to run for 1 second for each of the three tests and increased the memory test blocks to 2x 32KB.

You can download them from http://www.shelteringoak.com/du.

Maybe I jumped the gun but the download links don't work...

Sorry about that! Fixed now.

Oh wow, new 3.1x utilities - that is a rare sight!
Will check them out, thanks for sharing!

Hi, Charlie!
This XMOVE.EXE seems like the proper utility for DOS, that I needed to replace the stupid m$ "move" 😀 Thank you!

One question about the win 3.1x file explorer EXPLORER.EXE: Does it support FAT32 and LFN?

aVd wrote on 2026-04-26, 05:31:

Hi, Charlie!
This XMOVE.EXE seems like the proper utility for DOS, that I needed to replace the stupid m$ "move" 😀 Thank you!

One question about the win 3.1x file explorer EXPLORER.EXE: Does it support FAT32 and LFN?

No, it doesn't work with LFN. It doesn't work that closely to the filesystem so I don't see any reason why it couldn't work on FAT32, however, with the lack of LFN support, it may mangle long file names on FAT32.

OzzFan wrote on 2026-04-26, 19:05:

No, it doesn't work with LFN. It doesn't work that closely to the filesystem so I don't see any reason why it couldn't work on FAT32, however, with the lack of LFN support, it may mangle long file names on FAT32.

I'm asking, because there's a patch for installing win 3.1x on FAT32 with m$-DOS 7.10, but native win 3.1x file managers doesn't work well with FAT32 and LFN.

looks good , i try it

aVd wrote on 2026-04-27, 07:52:

OzzFan wrote on 2026-04-26, 19:05:

No, it doesn't work with LFN. It doesn't work that closely to the filesystem so I don't see any reason why it couldn't work on FAT32, however, with the lack of LFN support, it may mangle long file names on FAT32.

I'm asking, because there's a patch for installing win 3.1x on FAT32 with m$-DOS 7.10, but native win 3.1x file managers doesn't work well with FAT32 and LFN.

This is interesting. I wasn't aware of that patch.

I decided to look into this a bit more to see how much effort would need to go into making Explorer LFN compatible and here's what I learned: the LFN capability is built into Windows 9x's FAT32 Installable File System Driver, and applications can tap into Win9x's APIs to handle LFNs. MS-DOS 7.x has no native LFN APIs to work with, which is why you still see short file names when you reboot into DOS mode (or start Win9x without the GUI).

Obviously, Windows 3.1x does not contain LFN capabilities. So, in order to make this work, one would have to write their own file system driver that runs under Windows 3.1x that can translate LFNs just like Win9x does, and lots of testing would need to be done to ensure backward compatibility isn't broken for existing applications.

I'm not saying it can't be done, but that is not a trivial amount of development. I would also venture a guess to say that for performance reasons, whatever code is written should be in x86 assembly (as most Windows 3.1x VxDs were).

I'm currently working on a different project that is quite the undertaking, so I don't think I have time to take on another one as of right now. Maybe sometime in the future.

OzzFan wrote on 2026-04-30, 23:21:

This is interesting. I wasn't aware of that patch. […]
Show full quote

This is interesting. I wasn't aware of that patch.

I decided to look into this a bit more to see how much effort would need to go into making Explorer LFN compatible and here's what I learned: the LFN capability is built into Windows 9x's FAT32 Installable File System Driver, and applications can tap into Win9x's APIs to handle LFNs. MS-DOS 7.x has no native LFN APIs to work with, which is why you still see short file names when you reboot into DOS mode (or start Win9x without the GUI).

Obviously, Windows 3.1x does not contain LFN capabilities. So, in order to make this work, one would have to write their own file system driver that runs under Windows 3.1x that can translate LFNs just like Win9x does, and lots of testing would need to be done to ensure backward compatibility isn't broken for existing applications.

I'm not saying it can't be done, but that is not a trivial amount of development. I would also venture a guess to say that for performance reasons, whatever code is written should be in x86 assembly (as most Windows 3.1x VxDs were).

I'm currently working on a different project that is quite the undertaking, so I don't think I have time to take on another one as of right now. Maybe sometime in the future.

Hi,
Sorry for my late answer here.

This is the thread about making win 3.1x to work with DOS 7.10: Making Windows 3.11 work in DOS7.10 (patches inside) And there's a DOSLFN driver by Henrik Haftmann (2001-2003) and Jason Hood (2003-now?). I think, it should work in win 3.1x under m$-DOS 7.10.

I also want to report some bugs:
MEMINFO.EXE and REVEAL.EXE don't work with no DOS memory managers loaded - they just hang with no message. When I have HIMEM.SYS and EMM386.EXE loaded from CONFIG.SYS, both utilities work fine (REVEAL has other problems). I didn't tested them with HIMEM.SYS only loaded.

REVEAL's CPU benchmark has vast variety of test results for one and the same CPU, no matter after what period of idleness the test is re-done - tested on PII-233. Also "Hardware" report shows motherboard's BIOS Anti-virus Option ROM version/string.

EDIT: Unfortunately XMOVE.EXE causes some big troubles when used to move big directory structures 🙁 It gives some "R6000 error" with stack overflow and message about memory allocation error. Tested with ot without DOS memory managers loaded. In case with memory managers loaded at some point it hangs without any error messages. For some unknown reason it even deleted my DOS config files (possibly other files too) after this hang. Consider it unsafe to be used in current version.

aVd wrote on 2026-05-01, 19:44:

Hi,
Sorry for my late answer here.

No worries at all. I appreciate you taking the time and giving me feedback.

aVd wrote:

This is the thread about making win 3.1x to work with DOS 7.10: Making Windows 3.11 work in DOS7.10 (patches inside) And there's a DOSLFN driver by Henrik Haftmann (2001-2003) and Jason Hood (2003-now?). I think, it should work in win 3.1x under m$-DOS 7.10.

I reviewed their work and their source code. I'm a little weary of building a tool on top of an early beta that hasn't reached at least a 0.8 or 0.9 version to indicate it's nearly complete. But also, I can't find any documentation on public APIs that other applications can call upon, be it using software interrupts or some sort of library file and header definition. Maybe if the project matures a little more and the developer can document how to call upon their stack, it might be worth looking into.

aVd wrote:

I also want to report some bugs:
MEMINFO.EXE and REVEAL.EXE don't work with no DOS memory managers loaded - they just hang with no message. When I have HIMEM.SYS and EMM386.EXE loaded from CONFIG.SYS, both utilities work fine (REVEAL has other problems). I didn't tested them with HIMEM.SYS only loaded.

I wasn't able to replicate this with MEMINFO but I did replicate with REVEAL. It looks like it was a bug in my EMS detection causing the hang. Both applications share the same EMS detection code, so I went ahead and created a fix that works with no memory managers loaded. I tested on a DX/4 100 with DOS 6.22 and a 386DX with DOS 5.0.

aVd wrote:

REVEAL's CPU benchmark has vast variety of test results for one and the same CPU, no matter after what period of idleness the test is re-done - tested on PII-233. Also "Hardware" report shows motherboard's BIOS Anti-virus Option ROM version/string.

I hadn't tested on anything faster than a Pentium 133. I'll have to look into the benchmark code to see what can be done for faster CPUs.

aVd wrote:

EDIT: Unfortunately XMOVE.EXE causes some big troubles when used to move big directory structures 🙁 It gives some "R6000 error" with stack overflow and message about memory allocation error. Tested with ot without DOS memory managers loaded. In case with memory managers loaded at some point it hangs without any error messages. For some unknown reason it even deleted my DOS config files (possibly other files too) after this hang. Consider it unsafe to be used in current version.

😲 That's definitely not good. Thank you for reporting this. It sounds like for large moves it blew through the limited application stack space. I'll have to revisit the logic and test for large moves. I had previously only tested on relatively small application directories. I would agree, don't use this version for large directory moves.

I'll get to work on fixing the rest of the bugs.

OzzFan wrote on 2026-05-02, 23:39:

I reviewed their work and their source code. I'm a little weary of building a tool on top of an early beta that hasn't reached at least a 0.8 or 0.9 version to indicate it's nearly complete. But also, I can't find any documentation on public APIs that other applications can call upon, be it using software interrupts or some sort of library file and header definition. Maybe if the project matures a little more and the developer can document how to call upon their stack, it might be worth looking into.

I think, DOSLFN has long since moved past the "beta testing" stage, but Jason Hood kept the zero-leading version numbering for some unknown reason. Te main problem is that the tool is developed on and off for the last quarter of century and still has some missing functionalities. AFIK, so far we don't have a better LFN driver for DOS.

You're right, that DOSLFN is poorly documented, but at least the source code is freely available. This is what I noticed in the DOSLFN ver. 0.42 source asm-file:

;N: Most Protected Mode DOS extenders doesn't translate the LFN API to ; Real Mode. (When running Windows9x, Windows makes tha […]
Show full quote

;N: Most Protected Mode DOS extenders doesn't translate the LFN API to
; Real Mode. (When running Windows9x, Windows makes that task, effectively
; disabling the DOS extender.)
; For DPMI programs, it is up to the programmer to translate these DOS
; calls to Real Mode, using DPMI services at INT31. Best solution would
; be a DLL that makes this task at load time, hooking the protected mode
; INT21 chain.
; When running Windows3 in Enhanced Mode,
; DOSLFN auto-loads an LFNXLAT.386 VxD that translates these APIs.
; With this VxD, there is no need for translation for Windows programs.
; Unfortunately, Win32s programs cannot see long file names,
; unless someone publish a great patch of one Win32s DLL.
; The rarely used Standard Mode should be configured to load the DLL
; (above mentioned) at startup - but DOSLFN requires a 386 itself.

I'm not aware if Jason reads (and writes in) this forum, so he could give more details.

OzzFan wrote on 2026-05-02, 23:39:

I wasn't able to replicate this with MEMINFO but I did replicate with REVEAL. It looks like it was a bug in my EMS detection causing the hang. Both applications share the same EMS detection code, so I went ahead and created a fix that works with no memory managers loaded. I tested on a DX/4 100 with DOS 6.22 and a 386DX with DOS 5.0.

Good. Please, could you share the fix or the fixed executables?

OzzFan wrote on 2026-05-02, 23:39:

I hadn't tested on anything faster than a Pentium 133. I'll have to look into the benchmark code to see what can be done for faster CPUs.

Nice! The benchamrk seems promising.

OzzFan wrote on 2026-05-02, 23:39:

😲 That's definitely not good. Thank you for reporting this. It sounds like for large moves it blew through the limited application stack space. I'll have to revisit the logic and test for large moves. I had previously only tested on relatively small application directories. I would agree, don't use this version for large directory moves.

I'll get to work on fixing the rest of the bugs.

When this serious problem happened to me, I tried to move about 24MB of data spread in directory structure with more than 100 (sub-)subfolders. The data loss was not critical, but I was amazed how it ended up with missing/deleted CONFIG.SYS and AUTOEXEC.BAT from the C drive root directory, as they have absolutely no relation to moving directory structure. Also, I don't know what method you're using for copying the files to the new destination, but on mechanical HDD it "sounds" like byte-by-byte read-write or something like this. The speed is very low, when moving big directory structures or/and directories containing big files.

Thanks for your effort in developing and maintaining these utilities!

I'm attaching the updated executables for Reveal, MemInfo, and XMove. Here's a summary of the changes I made:

Reveal and MemInfo - Fixed bug in EMS detection to allow code execution to continue if EMS driver not found (avoid system hang).

Reveal - Changed benchmark code to run for 2 seconds per test to reduce 3:1 variance in results. Changed all values to Kilo-operations (1000). Changed starting point for BIOS ROM string search to F800:0.

XMove - Increased application stack space from 2K to 8K. Re-worked move logic to use buffered I/O instead of bit copy. Improved speed of move operations on the same partition by simply updating FAT records. Allow for dynamically increasing in-memory records of source/destination pair to allow for larger moves.

I haven't had much of a chance to test XMove (been very busy lately), so I'll rely on your feedback. I appreciate it!

Hi,
Unfortunately for me MEMINFO.EXE and REVEAL.EXE v.2.21 behave the same way as v.2.20 🙁 I don't know if this is due to I'm not using mS-DOS v.6.xx or because of the system, that I'm currently using for tests - the one with PII-233 CPU. But it's fine, as these are not some essential utilities.

As for XMOVE.EXE v.2.21, I haven't tested it yet, because I have to copy some fresh megabytes of sacrificial useless data (at least 20MB, I think) on the test system's HDD...

What OS are you using? Maybe I can replicate and get them to work.