Willy J. Hoogstraten wrote:
>I don't know much about himem.sys. Only that the Win98 himem.sys is very
>small in memory (20 kb less than the one from Win95) and it has a higher
>limit than _all_ others (maybe Win2000 is better, but I never used it yet).
20K less? I would suspect I would notice such heavy use on memmory (I use
the 95 version on the schools DOS computers (96MB)).
Could you perhaps send me win98's himem.sys (and smartdrv.exe)?
>But emm386.exe from DR-DOS (7.03) is very good and doesn't require himem.sys.
>DR-DOS is also good with it's DPMI-support.
No it isn't (7.01). It kept crashing Heroes of Might and Magic II over and
over again.
The freeware cwsdpmi.exe is much better.
>I know that people who use
>DJGPP 2.xx don't like it, but DJGPP has no support for DR-DOS at all.
>(programs compiled with it often flush the nwcache!).
Oh. I'll need to look into that (it would be very bad if djpeg.exe did that).
>DR-DOS's fdisk is much better than MS-DOS's fdisk.
This one I'll completly agree on. An (assumed) broken 250MB HD didn't work
in MS-DOS but works with DR-DOS and Linux.
>The weakest points of DR-DOS (7.03) are:
>1) it doen't support FAT32.
I'll quote Matthias Paul on this (recently on the opendos list (at
delorie.com))
>BTW. There have been many queries about Caldera s/Lineo s FAT32
>support. In the current issue of the German computer magazine c t
>(06/2000), they compare variour Crash Recovery Tools developed
>by Ontrack, Powerquest, and others. What they all have in common,
>is that they use DR-DOS to boot their stuff. At least the Ontrack
>product (free evaluation download at www.ontrack.com) includes
>the DRFAT32.SYS/.EXE drivers to access FAT32 partitions via the
>redirector interface. So, if you want to have a look, this is
>where to go to... ;-)
>For an overview of all the available options of the DRFAT32.SYS driver
>(to be loaded in CONFIG.SYS) just give it an invalid parameter line so
>that the driver shows its internal help screen, or have a look
>at the end of the binary in the file viewer like inside the NC.
>DRFAT32.SYS supports CHS and LBA access, however, the DRFAT32.EXE
>redirector (to be loaded in AUTOEXEC.BAT similar to NWCDEX) has some
>limitations with partitions beyond 8 GB, and unfortunately DPMS and
>EMS support are disabled in this release...
>The advantages of the redirector approach are, that people without
>FAT32 drives are happily off with a small unbloated kernel, that
>virus contamination etc. of the FAT32 partition is much more
>difficult as the partition can be write-protected, that this solution
>works with *any* DOS 3.3+ (and DR DOS 5.0+), as long as run on a 386+.
>And it is compatible with all old DOS disk tools not knowing of
>MS-DOS 7.10+ FAT32 changes in the kernel. Of course, this also has
>disadvantages: You cannot boot DR-DOS off a FAT32 drive, if loaded
>it consumes more memory than a native solution, and it s slower...
I've downloaded, but not tried it yet (need to get hold of a FAT32 drive as
well <g>).
BTW: Does anyone have the NTFSDOS version that could *write* to an NTFS
partition?
>2) there's no compiler, assembler or image-viewer part of the distribution.
>3) there's bad support from software developers. (eg, most cdplay programs
> detect MSCDEX and won't work with NWCDEX).
Perhaps because they look for a "filename" mscdex$$ (or whatever it is)
instead of doing an interupt check?
>The weakest points of stand-alone MS-DOS are:
>5) it has no commandline-editing (as far as I know).
Do you mean editing the command line or editing on the command line?
