DOS ain't dead

I am newly registered on this forum. Thank you.

I want to add my comments about DOS filenames.

Reference this post ...

http://www.bttr-software.de/forum/forum_entry.php?id=8373

---

When the intention is to use a file or distriubition of files,
ie. a ZIP FILE, in a RAW DOS environment, all files should obey
the DOS 8.3 naming specification especially when they are being
distributed.

If you make a ZIP inside a WIN environment "excessive" names are
possible and should be avoided.

Only one "dot". Only 8 permissable characters to the left. For
example "+" is not permitted. Only 3 permissable to the right.
Ect.

Please, no long filenames. This may cause another persion a big
headache.

My personal preference is no "dot" extension in directory names.

And my main pet peeve is the following ...

Reference ...

http://en.wikipedia.org/wiki/ISO_9660

Please observe it's directory depth limitation of "8". Even on a simple
FAT32 drive.

Some unzippers might not work if > 8 and inside a RAW DOS environment.

Or to delete the files.

I had to format a whole USB stick once because I was unable to delete a directory structure with a DEPTH OF 11.

Please keep the destination user/environment in mind.

Steve Broshears ...

> My personal preference is no "dot" extension in directory names.

I use extension for dirs to utilize up to 11 chars and never had a problem with it :)

---
DOS gives me freedom to unlimited HW access.

> > My personal preference is no "dot" extension in directory names.
>
> I use extension for dirs to utilize up to 11 chars and never had a problem
> with it :)

There are some programs which don't expect such and are buggy. Caveat emptor.

BTW, you don't have to stick to 8.3 if your compressor can handle LFNs. Most unpackers should unpack them to 8.3. It's just more important to keep the first 8.3 distinct to avoid clashes. You can use DOSCHK (srcs) for that.

> And my main pet peeve is the following ...
>
> Reference ...
>
> http://en.wikipedia.org/wiki/ISO_9660
>
> Please observe it's directory depth limitation of "8". Even on a simple
> FAT32 drive.

This is interesting, since this is even more restrictive than DOS file naming conventions. This says that file names can only have upper-case letters, numbers, and underscores. There are quite a few more "legal" characters than those that can be used in a DOS file name.

This also says that directory names must never use dots (and thus are limited to 8 characters), also more restrictive than DOS (and not simply a "preference"). I see Rugxulo's comment below about some DOS programs not working with 8.3 directory names, but those are buggy programs, not a limitation of DOS. All DOS programs are _supposed_ to be able to understand 8.3 directory names.

In addition, DOS is not limited to 8 levels of sub-directories. The limit in DOS is that the path name to a file can be no longer than 64 characters. In some cases this is less than 8 levels, and in other cases more.

So ...

Are you recommending that only ISO 9660 Level 1 compatible file names be used, or DOS 8.3 compatible file names?

> > Reference ...
> > http://en.wikipedia.org/wiki/ISO_9660
> This also says that directory names must never use dots (and thus are
> limited to 8 characters),
The Joliet file system "extended" ISO 9660 to relax some of these rules.

> Rugxulo's comment below about some DOS programs not working with 8.3
Most likely with characters values over ASCII #127. Indeed I remember there was a >#127 character "feature" which I discovered in Windows 9x where explorer could be tricked into changing into the wrong directory by having 2 directories of similar names, e.g. mydir.x and mydir.y Where with the right naming it is possible to cause explorer to change into mydir.y when mydir.x is clicked onto.

> All DOS programs are _supposed_ to be able to understand 8.3 directory
Not DOS version 1 as directories were introduced in version 2 :)

> In addition, DOS is not limited to 8 levels of sub-directories.
Later DOS versions were not so limited by the levels of sub-directories.

> I am newly registered on this forum.

Welcome

> I want to add my comments about DOS filenames.
> When the intention is to use a file or distriubition of files,
> ie. a ZIP FILE, in a RAW DOS environment, all files should obey the
> DOS 8.3 naming specification especially when they are being distributed.

Right. Anyone cares except me ???

> Please, no long filenames. This may cause another persion a big headache.

This shows that "DOS" stuff was not compiled on DOS and most likely not tested either, and might not work well or at all.

> My personal preference is no "dot" extension in directory names.

Right. Then you might appreciate new new spec prohibiting extensions for directories

> Please observe it's directory depth limitation of "8". Even on a simple FAT32

FAT28

> Some unzippers might not work if > 8 and inside a RAW DOS environment.

Directory depth + path length limit is an "interesting problem" occasionally causing "interesting trouble" (reportedly NOT fixed on Wista ). There is a long rationale about it in my new (unfinished) spec.

> I had to format a whole USB stick once because I was unable to delete a
> directory structure with a DEPTH OF 11.

WtF ??? Maybe reducing the name length would help.

Rugxulo wrote:

> BTW, you don't have to stick to 8.3 if your compressor can handle LFNs.

Funny Why the bloat ??? Why not brew DOS package on DOS ???

> Most unpackers should unpack them to 8.3.

Bad hack.

> It's just more important to keep the first 8.3 distinct to avoid clashes.



Result: extracted 1'319 from 1'514 files, 195 lost

bretjohn wrote:

> I see Rugxulo's comment below about some DOS programs not
> working with 8.3 directory names, but those are buggy programs

NOT if you document your deprecation of directory extensions

> not a limitation of DOS.
> All DOS programs are _supposed_ to be able to
> understand 8.3 directory names.

Design fault.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> >
> > http://en.wikipedia.org/wiki/ISO_9660
> >
> > Please observe it's directory depth limitation of "8". Even on a simple
> > FAT32 drive.
>
> This is interesting, since this is even more restrictive than DOS file
> naming conventions. This says that file names can only have upper-case
> letters, numbers, and underscores. There are quite a few more "legal"
> characters than those that can be used in a DOS file name.
>

To be "extremely" compatible and not cause anyone anywhere a problem YES.
I think though that things like "$" and "&" are permitted.

>
> This also says that directory names must never use dots (and thus are
> limited to 8 characters), also more restrictive than DOS (and not simply a
> "preference"). I see Rugxulo's comment below about some DOS programs not
> working with 8.3 directory names, but those are buggy programs, not a
> limitation of DOS. All DOS programs are _supposed_ to be able to
> understand 8.3 directory names.
>

This is just my preference. Dots work just fine.

>
> In addition, DOS is not limited to 8 levels of sub-directories. The limit
> in DOS is that the path name to a file can be no longer than 64 characters.
> In some cases this is less than 8 levels, and in other cases more.
>

Well, you HAVE TO be able to WORK WITH the files. You must be able to
unzip them or you cannot use them. Unzipping them is up to the ZIP program
the downloader uses, possibly complicated by the ZIP program used to
create the archive.

And you will likely want to purge them. This is up to DOS and the purge program you might have. If you create an not-really-too-compatible ZIP
archive inside WIN, then a user running RAW DOS could easily have a problem.

The bottom line is to be careful and not cause someone else a problem.
Stated another way, be cautious and give the end user a better chance.

I had a major problem one time like I said, and my RAW DOS 8.00 wasn't
able to purge the thing. Luckily it was the only thing on the D: hard
disk and I used copy and formAT to work afround.

> So ...
>
> Are you recommending that only ISO 9660 Level 1 compatible file names be
> used, or DOS 8.3 compatible file names?

See above.

Thank you. Steve ...

INTERESTING.

> I had a major problem one time like I said, and my RAW DOS 8.00

???

> wasn't able to purge the thing.

Again, reduce length of something in the path, or use something less obscure than "RAW DOS"

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > I am newly registered on this forum.
>
> Welcome
>
> > I want to add my comments about DOS filenames.
> > When the intention is to use a file or distriubition of files,
> > ie. a ZIP FILE, in a RAW DOS environment, all files should obey the
> > DOS 8.3 naming specification especially when they are being distributed.
>
> Right. Anyone cares except me ???
>

Probably someone who is having a problem might care.

>
> > Please, no long filenames. This may cause another persion a big
> headache.
>
> This shows that "DOS" stuff was not compiled on DOS and most likely not
> tested either, and might not work well or at all.
>

IS TRUE.

>
> > My personal preference is no "dot" extension in directory names.
>
> Right. Then you might appreciate new new spec prohibiting extensions
> for directories
>
> > Please observe it's directory depth limitation of "8". Even on a simple
> FAT32
>
> FAT28
>
> > Some unzippers might not work if > 8 and inside a RAW DOS environment.
>
> Directory depth + path length limit is an "interesting problem"
> occasionally causing "interesting trouble" (reportedly NOT fixed on
> Wista ). There is a long rationale about it in my new (unfinished)
> spec.
>
> > I had to format a whole USB stick once because I was unable to delete a
> > directory structure with a DEPTH OF 11.
>
> WtF ??? Maybe reducing the name length would help.
>

But, the person creating the archive would have to do this.
This is what I'm saying.

>
> Rugxulo wrote:
>
> > BTW, you don't have to stick to 8.3 if your compressor can handle LFNs.
>

This says, only people with compatible zippers/unzippers can work together.

> Funny Why the bloat ??? Why not brew DOS package on DOS ???

Again, the person creating the archive would have to do this.
This is what I'm saying.

>
> > Most unpackers should unpack them to 8.3.
>
> Bad hack.
>
> > It's just more important to keep the first 8.3 distinct to avoid clashes.
>
>
>
>
> Result: extracted 1'319 from 1'514 files, 195 lost
>
> bretjohn wrote:
>
> > I see Rugxulo's comment below about some DOS programs not
> > working with 8.3 directory names, but those are buggy programs
>
> NOT if you document your deprecation of directory extensions
>
> > not a limitation of DOS.
> > All DOS programs are _supposed_ to be able to
> > understand 8.3 directory names.
>
> Design fault.

Steve ...

> > I had a major problem one time like I said, and my RAW DOS 8.00
>
> ???
>
> > wasn't able to purge the thing.
>
> Again, reduce length of something in the path, or use something less
> obscure than "RAW DOS"

What DOS would you recommend?

I currently use MSDOS800 MSDOS710 and FREEDOS.

Steve ...

>>> I want to add my comments about DOS filenames.
>>> When the intention is to use a file or distriubition of files,
>>> ie. a ZIP FILE, in a RAW DOS environment, all files should obey the
>>> DOS 8.3 naming specification especially when they are being distributed.

>> Right. Anyone cares except me ???

> Probably someone who is having a problem might care.

I care, too. More than once I have downloaded a so-called-"DOS" package,
only to have many of the files over-written in the unzipping because some one
has archived it with not only long file names but long directory names too.
Not to mention the odd moron who included file/directory names with spaces in
them.

There is a special place in hell for those who include spaces !!!!!!

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/

> What DOS would you recommend?

FreeDOS 2038 , EDR-DOS 2009 , DR-DOS 7.01

> There is a special place in hell for those who include spaces !!!!!!

Right

"http://www.openwatcom.org/ftp/readme.txt" wrote:

> Some Open Watcom tools currently do not function properly if installed
> in a directory with spaces in the name e.g. "C:\Program Files\WATCOM".
> Therefore choose a directory name like C:\WATCOM, D:\WATCOM etc.
> to install the tools in.



"http://mingw.org/wiki/Getting_Started" wrote:

> MinGW may have problems with paths containing spaces, and if not,
> usually other programs used with MinGW will experience problems
> with such paths. Thus, we strongly recommend that you do not
> install MinGW in any location with spaces in the path name
> reference; i.e. you should avoid installing into any subdirectory of
> "Program Files" or "My Documents", or the like.



"http://sf.net/projects/sevenzip/forums/forum/45798/topic/3783750" wrote:

> downloaded the 7-zip 9.15 BETA and also the 7za.exe.I am trying to run
> from the command prompt it is giving me an error which says 7z or 7ZA
> is not recognised as an internal or external command.I have the dir as
> c:\program files\7-zip\7.exe I have set the path of the environment
> variable to this directory and also the 7za path in the windows
> environment variable.When i am in this dir that is when i am in
> c:\program files\7-zip and run 7z it runs but when i am in C: dir and
> try to run the 7z command it says it is not recognised as an internal
> or external command.Iam trying to extract a .TAR file.
> Any help would be appreciated.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > What DOS would you recommend?
>
> FreeDOS 2038 , EDR-DOS 2009 , DR-DOS 7.01

IMO EDR-DOS 2009 should NOT be recommended - you can rather easily suffer severe data losses. I played with this version briefly, and found 2 issues:

-----------------------------------------------------
1. data loss
- create a directory on C: (FAT32)
- copy some files into it
- set the directory's system attribute ("attrib +s drdtest")
- move the directory from C: to D: using FreeDOS "move.exe"

result: the directory on D: wasn't created, but the files in the directory on C: were deleted.
-----------------------------------------------------
2. regression
you cannot delete any directory with VC (Volkov Commander), regardless what its attributes are.
-----------------------------------------------------

The WIP version from 17.6.2007 does NOT have these problems.

However, instead of EDR-DOS better use MS-DOS 7.1 or 8.0 if you love your data!

---
MS-DOS forever!

> > > What DOS would you recommend?
> >
> > FreeDOS 2038 , EDR-DOS 2009 , DR-DOS 7.01
>
> IMO EDR-DOS 2009 should NOT be recommended - you can rather easily suffer
> severe data losses. I played with this version briefly, and found 2
> issues:
>
> -----------------------------------------------------
> 1. data loss
> - create a directory on C: (FAT32)
> - copy some files into it
> - set the directory's system attribute ("attrib +s drdtest")
> - move the directory from C: to D: using FreeDOS "move.exe"
>
> result: the directory on D: wasn't created, but the files in the directory
> on C: were deleted.
> -----------------------------------------------------

I guess you'll be unsurprised, but ... FreeDOS move is abandoned and has bugs (esp. regarding attributes, e.g. moving a readonly file doesn't delete it afterwards). Also, most people don't put attributes on directories, most tools don't expect it, and I think DR-DOS doesn't even (directly) let you do so (at least not with its Attrib). Yet another "dark corner".

>
> I guess you'll be unsurprised, but ... FreeDOS move is abandoned and has
> bugs (esp. regarding attributes, e.g. moving a readonly file doesn't delete
> it afterwards).

Thanks for the info! FD move.exe is dated 30.8.2006, which is kind of "brand-new" for dos tools, so I wasn't aware of its abandoned state ( OTOH, isn't more or less all DOS software "abandoned"? ). Honestly, I usually don't use it at all, but VC fails to copy or move any directory with the mentioned EDR-DOS version, so I was in need of a tool which at least partially works.

> Also, most people don't put attributes on directories, most
> tools don't expect it, and I think DR-DOS doesn't even (directly) let you
> do so (at least not with its Attrib).

I'm slightly tempted to ask "So what?", but since this is regarded as impolite I will swallow this question down.

---
MS-DOS forever!

> There are some programs which don't expect such and are buggy. Caveat
> emptor.

I guess some vyry old tools. I mostly work with files in some file manager (DN, VC, NC, M602, MM...) and with packers (RAR, ZIP, ARJ) and really didn't have any problem. Even when burning CDs the check may report violations against ISO but was silent to 8.3 dirs...

> BTW, you don't have to stick to 8.3 if your compressor can handle LFNs.

I know, e.g. DJGPP distro can be unpacked in pure DOS and cutting the filenames and it works. But for my own SW and source files I will always use 8.3 :)

---
DOS gives me freedom to unlimited HW access.

> Thanks for the info!



> FD move.exe is dated 30.8.2006, which is kind of
> "brand-new" for dos tools,

I'll admit that's not really "old", but what I meant was that it hasn't been updated since then (while much else of FreeDOS has, despite no official 1.1 release yet still, ahem like Tom Ehlert predicted [why??]).

> so I wasn't aware of its abandoned state ( OTOH,
> isn't more or less all DOS software "abandoned"? ).

No, not all DOS software is abandoned (e.g. Doszip, Mpxplay, JWasm).

What I mainly meant was that I had reported the +R bug to the (alleged) maintainer many moons ago and go no response. And no one else (nor me) stepped up to do it yet. FreeDOS is an exclusively volunteer project, and uncoincidentally it is very very low on manpower.

> Honestly, I usually
> don't use it at all, but VC fails to copy or move any directory with the
> mentioned EDR-DOS version, so I was in need of a tool which at least
> partially works.

Understandable, but ...

> > Also, most people don't put attributes on directories, most
> > tools don't expect it, and I think DR-DOS doesn't even (directly) let
> you
> > do so (at least not with its Attrib).
>
> I'm slightly tempted to ask "So what?", but since this is regarded as
> impolite I will swallow this question down.

Well, if DR-DOS doesn't let you do it at all, it's obviously not important enough to do! (At least not in their eyes.) Besides, permissions on DOS are pretty heavily unenforced or ignored in most circumstances (as is apparent by obscure bugs in FD move, touch, etc).

EDIT:

> I know, e.g. DJGPP distro can be unpacked in pure DOS and cutting
> the filenames and it works. But for my own SW and source files I
> will always use 8.3 :)

Considering that DJ himself wrote DOSCHK, that's no surprise that DJGPP does work (which I indeed knew).

> IMO EDR-DOS 2009 should NOT be recommended - you can rather easily suffer
> severe data losses. I played with this version briefly, and found 2 issues:

> 1. data loss
> - create a directory on C: (FAT32)
> - copy some files into it
> - set the directory's system attribute ("attrib +s drdtest")
> - move the directory from C: to D: using FreeDOS "move.exe"
> result: the directory on D: wasn't created, but the files in the directory
> on C: were deleted.

This is BAD - but it's a BUG of FreeDOS MOVE, not of EDR-DOS. I can "confirm" this BUG as I can discourage to use FreeDOS MOVE to move anything beyond a single file.

Besides of this, there are GOOD REASONS why I DEPRECATE the S and H attributes anyway.

> 2. regression
> you cannot delete any directory with VC (Volkov Commander), regardless what
> its attributes are.

Known issue. Why ? This is because of EDR-DOS 2009 immature experimental NTLFN support + Volkov NTLFN addiction. Remove NTLFN support from VC and problem is gone If for some reason you can't fix Volkov, launch UI21DEB and activate N

> instead of EDR-DOS better use MS-DOS 7.1 or 8.0 if you love your data!

I'm excited !!! Now please give us the link where one can download the thing. I'll test it ASAP

> OTOH, isn't more or less all DOS software "abandoned"?

Sure, since everybody has and loves Windaube ... "So what?"

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> This is BAD - but it's a BUG of FreeDOS MOVE, not of EDR-DOS. I can
> "confirm" this BUG as I can discourage to use FreeDOS MOVE to move anything
> beyond a single file.

Ok. I added FD MOVE to my list of FreeDOS "dontuse"-tools - which already contains quite a few items ( DEFRAG, FDISK, CHKDSK, HIMEM.SYS, ... ). All in all a rather dismal FreeDOS status.

> Known issue. Why ? This is because of EDR-DOS 2009 immature experimental
> NTLFN support + Volkov NTLFN addiction.

Oooh, it is a "known" issue. Then everything's alright of course.

> Remove NTLFN support from VC and problem is gone If for some
> reason you can't fix Volkov, launch UI21DEB and activate N

Thanks, but I don't "use" EDR-DOS. However, I guess Steve will happily follow your valuable hints.

>
> > instead of EDR-DOS better use MS-DOS 7.1 or 8.0 if you love your data!
>
> I'm excited !!! Now please give us the link where one can download the
> thing. I'll test it ASAP

You'll have to format a floppy disk under WinXP. You'll see an option to create an MS-DOS boot disk. If you don't own WinXP or your comp has no FD anymore - bad luck!

---
MS-DOS forever!

> Thanks, but I don't "use" EDR-DOS. However, I guess Steve will happily
> follow your valuable hints.

he does !!!

> You'll have to format a floppy disk under WinXP

I deprecate XP

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Ok. I added FD MOVE to my list of FreeDOS "dontuse"-tools - which already
> contains quite a few items ( DEFRAG, FDISK, CHKDSK, HIMEM.SYS, ... ). All
> in all a rather dismal FreeDOS status.

Patches welcome. (I know, standard lame thing to say.) For MOVE alternative, try DJGPP's mv (I think? in FIL41B.ZIP). Or any file manager.

DEFRAG is mostly okay, just it has the unenviable task of needing to work on 8088 on up, even with FAT32. So it's somewhat understandable. (maintainer - Imre Leber)

FDISK is compatible but vaguely buggy. You'll need SPFDISK for SATA. Or you can try XFDISK. FreeDOS includes all three. (maintainer of FD FDISK - Brian Reifsnyder, who I guess never did finish latest beta, someone needs to e-mail him again I guess)

CHKDSK is for 16-bit machines only. For 32-bit use, DOSFSCK is recommended. (maintainer - maybe none, else Eric Auer)

HIMEM - why, what's wrong with it? Even your HIMEMX still doesn't have the fix for old 386s (sorry, Ninho). (maintainer - nobody, originally by Michael Devore, some improvements by you Japheth). At least we also have XMGR as an option (hi, Jack!) or FDXMS (Martin Stromberg).

> > Known issue. Why ? This is because of EDR-DOS 2009 immature experimental
> > NTLFN support + Volkov NTLFN addiction.
>
> Oooh, it is a "known" issue. Then everything's alright of course.

No, but lacking corporate sponsorship (or someone to actually want to hack it to death), it won't get fixed.

> > Remove NTLFN support from VC and problem is gone If for some
> > reason you can't fix Volkov, launch UI21DEB and activate N
>
> Thanks, but I don't "use" EDR-DOS. However, I guess Steve will happily
> follow your valuable hints.

You well know that we could all band together and test / fix these bugs in FreeDOS or EDR-DOS if we wanted. Do we want to?? Or aren't we always busy with other projects?

> > > instead of EDR-DOS better use MS-DOS 7.1 or 8.0 if you love your data!
> >
> > I'm excited !!! Now please give us the link where one can download
> the
> > thing. I'll test it ASAP
>
> You'll have to format a floppy disk under WinXP. You'll see an option to
> create an MS-DOS boot disk. If you don't own WinXP or your comp has no FD
> anymore - bad luck!

You can use a USB floppy drive or maybe emulate one on USB flash drive somehow.

> Ok. I added FD MOVE to my list of FreeDOS "dontuse"-tools - which already
> contains quite a few items ( DEFRAG, FDISK, CHKDSK, HIMEM.SYS, ... ). All
> in all a rather dismal FreeDOS status.

What did FFDISK bad to you? I use it sometimes. With others I would agree.

---
DOS gives me freedom to unlimited HW access.

>
> What DOS would you recommend?
>
> FreeDOS 2038 , EDR-DOS 2009 , DR-DOS 7.01
>

MSD-710 and MSD-800 are compatible with all the DOS programs I use.

I started testing FreeDos a while back. I had just begun to test
the drivers loaded in CONFIG.SYS. IO.SYS, COMMAND.COM, (or the
free-dos equivalent names), UMBPCI, and LOWDMA worked fine.

The fifth driver I tested was "Drive Exchange" from this web site.
It doesn't work at all and I cannot live without it.

I don't consider drive exchange to be defective. I think that
FreeDos is simply "less than" adequately DOS compatible.

This was just a tiny start into testing FreeDos. My thoughts are
that if I had continued a thourogh test, that a "large list" of
problems would be uncovered.

I quickly gave up on FreeDos.

As for EDR-DOS there are compatibility problems too.

I have the following types of disks:

1.44mb floppies.
120mb LS-120 super floppies.
IDE hard disks.
SATA hard disks.
USB sticks.

Under MS-DOS the MSDOS formatter formates all of these fine.

Under EDR-DOS it's formatter only formats 1.44 and IDE disks.
I had to search the internet for formatters, and it tool an
additional two formatters for a total of three to format
everything.

So I quit using EDR-DOS too.

Steve ...

Yes sir!

Just download one of the many many MS 71 or 80 bootdisks, run rawrite,
or burn the ISO image, and you have a starting point.

<g>

Another incedent with FreeDos ...

I uncovered a PROBLEM a few years back ...

When I used FreeDOS on a desktop with an ATAPI LS-120 drive,
FreeDos failed to execute CONFIG.SYS or it's FreeDos counterpart.
Skipped right to AUTOEXEC. It left everything at the defaults.

I put in files=60. Didn't happen.
I put in xxxxx=60 expecting an error message. Didn't happen.

In both cases Microsoft DOS worked as expected.

My testing was more extensive but these two statements are sufficient.

I discussed this issue with them.
A big argument came to pass.
They told me my tests were invalid.

I voulintered to be thier test subject.

3 days passed.

Then they told me IF I WANTED THIS FIXED, I WOULD JUST HAVE TO FIX IT MYSELF.

Numerous thoughts then came into mind.

Is True Sory ...

Anyway ...

>
> What did FFDISK bad to you? I use it sometimes. With others I would agree.

It has been a long time, but IIRC then I got "divide by zero" errors when leaving FD fdisk.

---
MS-DOS forever!

> Or aren't we always busy with other projects?

Face it: we are permanently busy with tunig our loved Windaube's and testing DOS stuff compatibility with everything non-DOS around :-\

> Another incedent with FreeDos ... I uncovered a PROBLEM a few years back ...

Without kernel version this is NOT a valid BUG report.

> <g>

ggg

> USB sticks. Under MS-DOS the MSDOS formatter formates all of these fine.

Sure, MS-DOG inside XP AKA NT command prompt AKA CMD.EXE

> Just download one of the many many MS 71 or 80 bootdisks

Done !!!

> They told me my tests were invalid.

If the quality of them was comparable to your above posts ...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> I discussed this issue with them.
> A big argument came to pass.
> They told me my tests were invalid.
>
> I volunteered to be their test subject.
>
> 3 days passed.
>
> Then they told me IF I WANTED THIS FIXED, I WOULD JUST HAVE TO FIX IT
> MYSELF.

Such kind of experiences have been common with some of those involved in FreeDOS development over time. It doesn't matter if you were right or wrong, those people have used to show a lot of aggressive self-conceit and lack of elementary politeness in discussing whatever problem. I don't have regrets for the pitiful state of the project.

---
Glory to God for all things

> I started testing FreeDos a while back. I had just begun to test
> the drivers loaded in CONFIG.SYS. IO.SYS, COMMAND.COM, (or the
> free-dos equivalent names), UMBPCI, and LOWDMA worked fine.

MSDOS.SYS + IO.SYS = MS-DOS
KERNEL.SYS = FreeDOS

> The fifth driver I tested was "Drive Exchange" from this web site.
> It doesn't work at all and I cannot live without it.

Wait until rr gets back from hiatus, see what he says. I find it hard to believe it wasn't tested under FreeDOS also.

> I don't consider drive exchange to be defective. I think that
> FreeDos is simply "less than" adequately DOS compatible.

Barely. It runs almost everything. There are some corner cases, however (as nothing is perfect). But overall FreeDOS is indeed quite good (IMHO)!

> This was just a tiny start into testing FreeDos. My thoughts are
> that if I had continued a thourogh test, that a "large list" of
> problems would be uncovered.

Large? No, definitely not. But some obscure things will exist, surely.

> I quickly gave up on FreeDos.

Please don't. The only reason to (ever) give up on FreeDOS is if it's no longer developed. (Ahem, MS, DR.) And even then, it still "mostly" works!

> As for EDR-DOS there are compatibility problems too.
>
> I have the following types of disks:
>
> 1.44mb floppies.
> 120mb LS-120 super floppies.
> IDE hard disks.
> SATA hard disks.
> USB sticks.
>
> Under MS-DOS the MSDOS formatter formates all of these fine.

MS-DOS can't read USB either. So your BIOS must be emulating a HD there. SATA is almost definitely running in compatibility mode. (Don't) try MS FDISK with your SATA drive or (don't) try to create FAT32 without mucking up other partitions.

> Under EDR-DOS it's formatter only formats 1.44 and IDE disks.
> I had to search the internet for formatters, and it tool an
> additional two formatters for a total of three to format
> everything.
>
> So I quit using EDR-DOS too.

EDR-DOS is a valiant effort, but the license is less than ideal, and Caldera / Lineo really screwed the pooch by not releasing a fully patched version. (7.01 had known bugs, even some long fixed by Novell.) It's a shame, the idea was sound, but not everybody can be the next Linux.

> > Then they told me IF I WANTED THIS FIXED, I WOULD JUST HAVE TO FIX IT
> > MYSELF.

There's not enough developers to go around. The few they do have are just extremely busy (no surprise, smarter you are the harder you work). Don't take it personally.

> Such kind of experiences have been common with some of those involved in
> FreeDOS development over time. It doesn't matter if you were right or
> wrong, those people have used to show a lot of aggressive self-conceit and
> lack of elementary politeness in discussing whatever problem. I don't have
> regrets for the pitiful state of the project.

That's not true, that's a bit of an overgeneralization. I mean, I don't know what you experienced, and I'm not defending everything under the sun, just saying ... many FreeDOS contributors have been extremely polite and helpful to me. In fact, I can't think of anything that offended me so horribly. To be honest, I almost (but not really) would prefer that specific people were called out on this rather than FreeDOS as a whole. But that's heavily counter-productive too. (Please don't, it's just my lame instinct.) Nobody's perfect. Volunteers welcome! GPL! Fork it! Hack it! Fix it! Play with it! Share it!

> > Or aren't we always busy with other projects?
>
> Face it: we are permanently busy with tuning our loved Windaube's and
> testing DOS stuff compatibility with everything non-DOS around :-\

What's wrong with compatibility? If you want to be pure DOS only (e.g. VCPI), you'll get lots less users. Besides, duh, DOS has no (native) networking or multitasking, which can on rare occasion actually be useful! It's also not our fault that perfectly good DOS software won't work on modern hardware (ahem, non-SB soundcards), so emulation is the only way to truly get it working.

> > Another incedent with FreeDos ... I uncovered a PROBLEM a few years back
> ...
>
> Without kernel version this is NOT a valid BUG report.

Correct, but personally I've never used LS-120 (or really even know what it is, "removable SCSI storage"??). I assume the same is true of most FreeDOS peeps.

---
Know your limits.h

> Volunteers welcome! GPL! Fork it! Hack it! Fix it! Play with it! Share it!

I surely don't want to prevent others from contributing, but for me the conclusion about a few things (like FreeDOS MOVE that had originally fired this flame, and a few others not necessarily excluding the kernel or the FAT-CRAP) is: throw it away and brew a new one from scratch.

> What's wrong with compatibility?

Hack over hacks over ...

> If you want to be pure DOS only (e.g. VCPI)

I deprecate VCPI.

> you'll get lots less users.

Face it: DOS is a one man show, so what ??? (anyone dared to test "my" MPLAYER ???) :-\

> Besides, duh, DOS has no (native) networking or multitasking, which can on rare occasion actually be useful!

Multi: nope in legacy DOS kernels, need to be brewn from scratch.

Net: why ??? There is Arachne, DOSLynx, some servers, mTCP FTP, WGET ... what's missing (besides features in those apps) ???

> It's also not our fault that perfectly good DOS software won't work on modern hardware (ahem,

But it's out fault that we don't have a sound driver model.

> non-SB soundcards), so emulation is the only way to truly get it working.

Right, get BOCHS

> 2010: the year of the DOS desktop

7/12 over

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> That's not true, that's a bit of an overgeneralization. I mean, I don't
> know what you experienced, and I'm not defending everything under the sun,
> just saying ... many FreeDOS contributors have been extremely polite and
> helpful to me. In fact, I can't think of anything that offended me so
> horribly. To be honest, I almost (but not really) would prefer that
> specific people were called out on this rather than FreeDOS as a whole. But
> that's heavily counter-productive too. (Please don't, it's just my lame
> instinct.) Nobody's perfect. Volunteers welcome! GPL! Fork it! Hack it! Fix
> it! Play with it! Share it!

I don't see how I "overgeneralized" as long as I used the word "some". I didn't refer to my experience, I have preferred to avoid the possibility of such experiences, but it would be enough for you to read more or less recent posts on their mailing list in order to better understand what I meant. I obviously prefer to avoid giving any name (would make any sense?), and I am glad to know that you have had the chance for a good (and I hope fruitful) experience with many FreeDOS contributors. In the end you care about the project and you are emotionally involved in it, whilst I don't do either, and I don't have any need of FreeDOS.

---
Glory to God for all things

> > The fifth driver I tested was "Drive Exchange" from this web site.
> > It doesn't work at all and I cannot live without it.
>
> Wait until rr gets back from hiatus, see what he says. I find it
> hard to believe it wasn't tested under FreeDOS also.

I surely isn't a general problem because for me this tool DOES WORK with FreeDOS (2039 kernel, 01.08.2009, size 45161 ).

---
MS-DOS forever!

>
> Another incedent with FreeDos ... I uncovered a PROBLEM a few years back
>
> Without kernel version this is NOT a valid BUG report.
>

Correct. It is not intended as a bug report. Not on this forum.

What I'm reporting here is how they acted when I told them.
How they treated me.

>
> Correct, but personally I've never used LS-120 (or really even know
> what it is, "removable SCSI storage"??).
>

LS-120 is a 120-MB optical disk shaped and sized like a floppy.
The drives themselves are either ATAPI or USB.
They are still available on EBay.

They are still supported natively on a lot of BIOSes and MS
versions of DOS and Windows up to and including Seven.

If you have one it's nice if it doesn't case problems.

>
> I assume the same is true of most FreeDOS peeps.
>

Thus on a scale of ONE to a THOUSAND FreeDOS and ED-DOS
would get a few less compatibility points.

I actually looked at the code.
However the problem is/was obviously in the kernel.
The absolutely worst module to troubleshoot.
Would need the author to fix this one.

>
> > I started testing FreeDos a while back. I had just begun to test
> > the drivers loaded in CONFIG.SYS. IO.SYS, COMMAND.COM, (or the
> > free-dos equivalent names), UMBPCI, and LOWDMA worked fine.
>
> MSDOS.SYS + IO.SYS = MS-DOS
> KERNEL.SYS = FreeDOS
>
> > The fifth driver I tested was "Drive Exchange" from this web site.
> > It doesn't work at all and I cannot live without it.
>
> Wait until rr gets back from hiatus, see what he says. I find it
> hard to believe it wasn't tested under FreeDOS also.
>

What drive exchange does for me is to put my hard disk D: and E: back
below the USB STICKS where they should be.

On my system (IE. with exactly the same hardware and BIOS)

under Microsoft DOS drive exchange works as advertized, but
under Free DOS drive exchange doesn't recognize anything to re-arrange.

Remembrt, exactly the same PC and thus HARDWARE and BIOS.

> > I don't consider drive exchange to be defective. I think that
> > FreeDos is simply "less than" adequately DOS compatible.
>
> Barely. It runs almost everything. There are some corner cases, however (as
> nothing is perfect). But overall FreeDOS is indeed quite good (IMHO)!
>
> > This was just a tiny start into testing FreeDos. My thoughts are
> > that if I had continued a thourogh test, that a "large list" of
> > problems would be uncovered.
>
> Large? No, definitely not. But some obscure things will exist, surely.
>
> > I quickly gave up on FreeDos.
>
> Please don't. The only reason to (ever) give up on FreeDOS is if it's no
> longer developed. (Ahem, MS, DR.) And even then, it still "mostly" works!
>
>

OK I can continue to test FreeDOS but first let's see what the
Drive Exchange author as to say.

> > As for EDR-DOS there are compatibility problems too.
> >
> > I have the following types of disks:
> >
> > 1.44mb floppies.
> > 120mb LS-120 super floppies.
> > IDE hard disks.
> > SATA hard disks.
> > USB sticks.
> >
> > Under MS-DOS the MSDOS formatter formates all of these fine.
>
> MS-DOS can't read USB either. So your BIOS must be emulating a HD there.
> SATA is almost definitely running in compatibility mode. (Don't) try MS
> FDISK with your SATA drive or (don't) try to create FAT32 without mucking
> up other partitions.
>
> > Under EDR-DOS it's formatter only formats 1.44 and IDE disks.
> > I had to search the internet for formatters, and it tool an
> > additional two formatters for a total of three to format
> > everything.
> >
> > So I quit using EDR-DOS too.
>
> EDR-DOS is a valiant effort, but the license is less than ideal, and
> Caldera / Lineo really screwed the pooch by not releasing a fully patched
> version. (7.01 had known bugs, even some long fixed by Novell.) It's a
> shame, the idea was sound, but not everybody can be the next Linux.

> > > The fifth driver I tested was "Drive Exchange" from this web site.
> > > It doesn't work at all and I cannot live without it.
> >
> > Wait until rr gets back from hiatus, see what he says. I find it
> > hard to believe it wasn't tested under FreeDOS also.
>
> I surely isn't a general problem because for me this tool DOES WORK with
> FreeDOS (2039 kernel, 01.08.2009, size 45161 ).

I tested 2039 too.

I guess MS-800 might now work on someone elses hardware too.

Works both ways.

So I voulinteer to test things on my hardware.

> What drive exchange does for me is to put my hard disk D: and E: back
> below the USB STICKS where they should be.
Swapping DOS drive letters was a common activity at one time, hence be aware that in addition to RR's util there are a large number of other utilities to do this. e.g. DOS ASSIGN util, STAC electronics's Stacker product shipped with a util, JSWAP etc.

FileWatcher looks to be an interesting site.
I'm going to have to check it out.

SteveB ...

> The fifth driver I tested was "Drive Exchange" from this web site.
> It doesn't work at all and I cannot live without it.
>
> I don't consider drive exchange to be defective. I think that
> FreeDos is simply "less than" adequately DOS compatible.

I admit I have not touched DRVEXCH since 2001, and I do not remember testing it with any version of FreeDOS. The method I used was an ugly hack (modifying low-level internal DOS structures) as nothing else I tried worked reliably enough with all tested DOS versions.

Do you call DRVEXCH from CONFIG.SYS? Which syntax do you use ('#' for auto-rearrange, or explicit drive letter ordering)?

> FileWatcher looks to be an interesting site.
Yes, FileWatcher is a very useful straight forward to use site. It is run by MARUHN IT Consulting / Oliver Maruhn, in Germany.

I call it from config.sys using #.

It reports "nothing to do" "nothing to re-arrange"
something like that.

It works fine in Microsoft DOS 710 and 800.

> I call it from config.sys using #.
>
> It reports "nothing to do" "nothing to re-arrange" something like that.

Running in this mode, DRVEXCH 0.4.2 should report detected drive list and finished re-arranging, like below:

Drives found:
C: on HD0
D: on HD0
E: on HD1
Re-arranging done.

So I guess you get an empty drive list and `done' message, but please single-step through your CONFIG.SYS (or use our PAUSE tool) and note exact messages.