>>> "Just uploaded Enhanced"

Great.

>>> "features LFN support for the DIR command in COMMAND.COM"

But DOSLFN is still required :?:

>>> "potentially critical bug that had been introduced by the 64-bit"

One more :shock:

I'll test :-)

> >>> "features LFN support for the DIR command in COMMAND.COM"

> But DOSLFN is still required :?:

Yes, just like in FreeDOS and DR-DOS 7.03.

I'm glad to see some LFN support in COMMAND.COM :)

>> Yes, just like in FreeDOS and DR-DOS 7.03.
I think, that DOSLFN is small enough and reliable to be constantly loaded as TSR.

But is it possible to load DOSLFN 0.40 into HIGH MEMORY AREA (no into UPPER MEMORY BLOCK) (TOGETHER with DOS kernel)? I guess that it will require some memory tricks (HIMEM.SYS allocates HMA as single block), but I think it is possible.

P.S. What is the usage of HMA with DR-DOS kernel (?? kb of 64 kb?)

> I'm glad to see some LFN support in COMMAND.COM :)

More is planned. :-)

> But is it possible to load DOSLFN 0.40 into HIGH MEMORY AREA (no into UPPER MEMORY BLOCK) (TOGETHER with DOS kernel)?
> I guess that it will require some memory tricks (HIMEM.SYS allocates HMA as single block), but I think it is possible.

This is an interesting idea, however, it would need some sort of
relocation mechanism for DOSLFN since it does not know in advance at
which address in the HMA it will be loaded. Unless you are thinking of
compiling it along with the kernel, that is.

> P.S. What is the usage of HMA with DR-DOS kernel (?? kb of 64 kb?)

Currently, it is a little bit less than 45 KB, without disk buffers.

BTW, is there a way to make FD MEM display the contents of the HMA?

>>> "I have compiled a new WIP version of Enhanced DR-DOS 7.01.08."

Seems that COMMAND.COM and DRBIO.SYS changed, DRDOS.SYS is unchanged
except (C).

>>> "More is planned. :-)"

LFN support in the kernel ?

What about the SHELL= and COMSPEC handling ? Did something change ?

> Seems that COMMAND.COM and DRBIO.SYS changed, DRDOS.SYS is unchanged except (C).

So what? You can easily tell what has changed by looking at the
difference patch.

> >>> "More is planned. :-)"

> LFN support in the kernel ?

Not before v7.01.09.

> What about the SHELL= and COMSPEC handling ? Did something change ?

Judging by a quick glance at the history.txt file, it does not look
like that was part of the new WIP version. ;-)

>> More is planned. :-)
Nice! It would be a real alternative for Datalight ROM DOS 7.1 command.com!

>> it would need some sort of relocation mechanism for DOSLFN since it
>> does not know in advance at which address in the HMA it will be loaded.
Probably it is possible to do it even without modification of DOSLFN: simply stuff it in High Memory Area using special type of loader and permanently turn on A20 gate (it is possible to make "A20 ALWAYS ON" in HIMEMX driver).

The main problem is emulation of PSP at the beginning of COM file memory image (probably it is possible to use loadsys.exe as a loader).

>> BTW, is there a way to make FD MEM display the contents of the HMA?
MEM /ALL - displays some information about HMA (rather scarce)

>> Currently, it is a little bit less than 45 KB, without disk buffers.
20Kb is enough for DOSLFNMS 0.40e. High memory and upper memory are really valuable resources and they should be stuffed just a subway trains in the morning rush-hour.
But I don't know if these 45 kb are solid block or not and what is the structure of usage (I'm not a developer of kernel :-) )

P.S. Now I'm trying to do another dirty hack: to enable "hot plug" of USB Flash drive in USBASPI.SYS v2.20 (main problem is garbage in XMS).

> >> it would need some sort of relocation mechanism for DOSLFN since it >> does not know in advance at which address in the HMA it will be
> loaded. Probably it is possible to do it even without modification of DOSLFN: simply stuff it in High Memory Area using special type of loader and
> permanently turn on A20 gate (it is possible to make "A20 ALWAYS ON" in HIMEMX driver).

> The main problem is emulation of PSP at the beginning of COM file memory image (probably it is possible to use loadsys.exe as a loader).

No, I suppose the main problem is that the offset address is no longer
100h. DRBIO.SYS uses a special padding to allow COMMAND.COM to be
loaded below the kernel in the HMA; a similar solution would have to
be found for DOSLFN.

> >> BTW, is there a way to make FD MEM display the contents of the HMA? MEM /ALL - displays some information about HMA (rather
> scarce)

But alas not about the items in the HMA themselves, it seems.

>> No, I suppose the main problem is that the offset address is no longer >> 100h.
Yes, it is a real problem. Probably it will require some patching of DOSLFN which will make it movable in memory. (It is very easy to receive IP register to AX, but patch 200kb of assembly language listing... :-( )

And this area is also very suitable for fonts of russificator (or another localizator) - it always uses 10-12Kb of memory! Probably, I'll try to make HMA keyboard driver (without such "bells and whistles" as codepages, text files with layouts - almost everybody everybody needs only two layouts - English and national (e.g. Russian)).

Probably, Soviet RK.COM will be a nice choice for patching - it is small and not too complicated, but I'm not sure. RK.COM may be easily patched to any European language using its own command line keys.

Probably this problem is not actual for your native language - if you cannot see letters with dashes and dots over it - you may read the text, it I haven't cyrillic font - I see "Tumba-Yumba" language.

>> But alas not about the items in the HMA themselves, it seems.
HIMEM.SYS allocates it as a single unit and this information will require the usage of undocumented features of kernel.

> DOSLFN is small enough and reliable to be constantly loaded as TSR.

It's not bug-free though - it seems to have problems in its SFN handling. Many times I've seen the Borland Pascal IDE complain about not being able to create a SFN file when DOSLFN 4.x is active, but BP7 works perfectly without DOSLFN and also in a Win9x DOS box.

The other big problem with an LFN DOS is that (to my knowedge) there is no equivalent to the Win9x version of ScanDisk, which means that any file system corruption cannot fixed if there are any LFN's on that volume.

>> Many times I've seen the Borland Pascal IDE complain about not being
>> able to create a SFN file when DOSLFN 4.x is active, but BP7 works
>> perfectly without DOSLFN and also in a Win9x DOS box.
I cannot reproduce the bug: BP7 compiles and saves "Hello, World" fast and accurate! I'm using the latest DOSLFN 0.40e.
What were your conditions - may be it is possible to reproduce bug and write bugreport?

>> The other big problem with an LFN DOS is that (to my knowedge) there is >> no equivalent to the Win9x version of ScanDisk
Yes, it's a problem, but I think it is really actual only for offices not for home users: you can simply take Scandisk from Windows 98 SE which can be bought just for 5$ at some disk markets and sometimes near metro stations (or even downloaded ;) ).

> you can simply take Scandisk from Windows 98 SE which can be bought
> just for 5$ at some disk markets and sometimes near metro stations

;-D

> What were your conditions - may be it is possible to reproduce bug and
> write bugreport?

I've upgraded to DOSLFN 0.4e (from 0.4a) and SHCDX 3.04 (from 3.0) and everything now works. So hopefully the problem has now been fixed.

> you can simply take Scandisk from Windows 98 SE

One of my machines three-way boots (DR-DOS 7.03 + 2 x Win98SE) but only one of the partitions is visible - they all assume drive letter 'C', the other two being hidden. So neither of my Win9x boots can see my DR-DOS partition.

> One of my machines three-way boots (DR-DOS 7.03 + 2 x Win98SE) but only > one of the partitions is visible - they all assume drive letter 'C', the > other two being hidden. So neither of my Win9x boots can see my DR-DOS
> partition.
But you may simply take DOS version of ScanDisk from Win98SE and run it under DR-DOS (I haven't tried it under DR-DOS, but I think you may launch it). If it will say "incorrect DOS version"... may be it will be possible to patch it (or to hook INT 21h).

> SHCDX 3.04
I use SHCDX 3.03C - it can work with DOSLFN 0.40e (unofficially, but works :-)

> But you may simply take DOS version of ScanDisk from Win98SE and run it under DR-DOS

But isn't the DOS version of Scandisk pretty useless? It nearly always says (something like) "Unable to fix drive 'X:' Run the Windows version of Scandisk to correct the error" whenever I've seen it find a corruption.

Yes, I also remember this... and then many files are corrupted... very bad

> But isn't the DOS version of Scandisk pretty useless? It nearly always says (something like) "Unable to fix drive 'X:' Run the Windows version of
> Scandisk to correct the error" whenever I've seen it find a corruption.

Well, the name is *Scan*Disk, not *Fix*Disk, isn't it? ;-)

Use Norton Disk Doctor if you are interested in fixing any problems.

BTW, I remember having read something about a port of the Linux tool
DOSfsck to DOS.

I've googled DOSdosfsck (DJGPP port of DOSfsck): http://www.coli.uni-saarland.de/~eric/stuff/soft/by-others/

Direct link:
http://www.coli.uni-saarland.de/~eric/stuff/soft/by-others/dosdosfsck-2.11.zip

I don't know if it is better than Norton Disk Doctor (aka Norton Disk Destroyer) and didn't test it.

> The other big problem with an LFN DOS is that (to my knowedge) there is no equivalent to the Win9x version of ScanDisk, which means that any
> file system corruption cannot fixed if there are any LFN's on that volume.

The DOS version of Norton Disk Doctor (NDD) can do this.

But of course you are right; we need alternatives to those commercial
tools, simply because they are neither still being updated nor sold.

Hello Udo, I downloaded your new release, it works fine, but when I "packed" it (to include on Boot Disk) using your special tools it no longer worked. Do the "packing" tools need to be updated to??
Best regards, Stephen William Foyle

Thanks for the report.

I made some changes to the init code, but nothing related to Pack or
the startup code, just stuff needed for the fast reboot.

I currently cannot reproduce this problem here, so I need more info.
What exactly happens when you boot the packed version? Are there any
error messages? Does it work when you only use PACKDOS but not PACKBIO
or vice versa?

OK!OK!OK! Dummy me I had a freeware debug.com clone in my path.
Now that I moved DrDos 7.03 debug.exe into my pack directory both drbio.sys and drdos.sys compress corectly and boot OK! I have also included jemmex.exe on my recovery boot disk and now I have 650,144 bytes of available DOS memory:

Modules using memory below 1 MB:

Name Total Conventional Upper Memory
-------- ---------------- ---------------- ----------------
SYSTEM 35,664 (35K) 4,752 (5K) 30,912 (30K)
4DOS 8,352 (8K) 272 (0K) 8,080 (8K)
ntfsdos 34,512 (34K) 0 (0K) 34,512 (34K)
HDPMI32 13,072 (13K) 0 (0K) 13,072 (13K)
ANSI 976 (1K) 0 (0K) 976 (1K)
SHCDX 8,768 (9K) 0 (0K) 8,768 (9K)
XMSDSK 688 (1K) 0 (0K) 688 (1K)
Free 679,600 (664K) 650,144 (635K) 29,456 (29K)

Memory Type Total Used Free
Press <Enter> to continue or <Esc> to exit . . .
---------------- -------- -------- --------
Conventional 640K 5K 635K
Upper 124K 95K 29K
Reserved 260K 260K 0K
Extended (XMS) 2,096,112K 99,052K 1,997,060K
---------------- -------- -------- --------
Total memory 2,097,136K 99,412K 1,997,724K

Total under 1 MB 764K 100K 664K

Total Expanded (EMS) 8,192K (8,388,608 bytes)
Free Expanded (EMS) 8,064K (8,257,536 bytes)

Memory accessible using Int 15h 65,472K (67,043,328 bytes)
Largest executable program size 635K (650,128 bytes)
Largest free upper memory block 28K ( 28,928 bytes)
DR-DOS is resident in the high memory area.

Regarding jemmex.exe I now it is a "Development version (unstable)"
when I exit fm.com (by AirSoft, Bulgaria) jemmexe gives me a nice exception message (4 lines of numbers etc) but if I press escape I can continue. Best regards, Stephen William Foyle

I guess that makes this a false positive, a report of a bug that does
not exist, which is always better than having an existing bug that
nobody reports. ;-)