Hi Christian and Eric,
> Did you use the latest DOSLFN version (from Jason Hood)?
This is the version I used at the time of the crashes:
DOSLFN 0.40c (haftmann#software & jmh 11/05)
> More importantly, notice that DOSLFN can be disabled or unloaded
> without rebooting. Did you disable it (or restarted the computer,
> without DOSLFN) before running CHKDSK?
Sorry, I do not remember what I did at the time. But today I
certainly restart, as I have a special fdconfig.sys configuration
for disk checking (see below).
> Disk-caching software such as LBACACHE or SmartDrive might also lead
> to problems (either stand-alone, or only in combination with DOSLFN).
> Do you use any cache?
Yes, I use them, first SmartDrive, and more recently LBACache.
> Your appended NSSI report says there's no XMS (HIMEM) or EMS (EMM386)
> driver installed. Is that your usual configuration? This might cause
> problems. I think DEFRAG and software ported to DJGPP (such as
> DOSFSCK) might run better with XMS than with "raw" extended memory.
> I agree :-) You also have much more DOS RAM free if you use HIMEMX and
> DOS=HIGH in your config (or fdconfig) sys because that allows kernel
> and command.com to load into HMA and swap to XMS, respectively.
Today I use:
- JemmEx Almost all the time.
- HimemX + Jemm386 Only in conjunction with MS-Client network
and Paradox, because they are, in my experience,
less stable under JemmEx.
- HimemX For disk checking and defragmentation. (But two
years ago I did not know that this is
recommended, so I probably used the regular
configuration for checking and defragmentation
NSSI is a special case. It crashes with JemmEx, so I had the habit
of running it with the absolute minimal configuration. This is why
yesterday's report showed no EMS or XMS memory. I just ran it again,
this time with HimemX, and this is the new report:
Present Yes, Version 3.0
Manager HIMEM, Revision 3.31
Total 31680 KB, Used 2094 KB (7%), Free 29586 KB (93%)
> I think NDN had some direct disk access option which sometimes caused
> problems with caches/DOSLFN/ramdisk?
As far as I know, direct disk access is not yet implemented in NDN.
However, the original DN (by Rit Labs) does have it, and caused a
lot of trouble before I disabled it.
> Please explain what you mean by strange... You should also be able to
> drop bad items with CHKDSK / DOSFSCK.
By strange I mean:
(1) Their names were full of illegal characters.
(2) They could not be deleted or moved, either by file managers or
directly from the FreeDOS command line, nor could they be fixed with
CHKDSK / DOSFSCK.
(3) If they were folders, it was in some cases impossible to enter
them and see the files they supposedly contained.
This has not happened in recent file damage episodes, which leads me
to believe it was related to the DN direct disk access, or to
DOSLFN, both of which I no longer use.
> If your DOSFSCK runs very slow and you have file damage afterwards
> then maybe you used a strange DOS extender / DPMI which swaps to (the
> scanned) disk when running out of RAM? DOSFSCK 2.11.DOS3 explicitly
> tells CWSDPMI to disable this but very old DOSFSCK versions did not
> have that feature.
Possible, as I did have CWSDPMI in my hard drive. I also have two
files called DPMIINST.EXE and DPMILOAD.EXE in the Paradox folder,
which is in the path. Could those be the "strange DPMI" you
But probably the DOSFSCK version was not very old, as I only
started using FreeDOS two years ago.
Sao Paulo, Brazil
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
Freedos-user mailing list