DOS ain't dead

Hi! I wish to get Luchezar Georgiev's attention (in public) about a minute but annoying misfeature in 4DOS. Are these forums the right place, or else where is it ?

I might as well post the question\suggestion itself since it will be very concise really. I'm asking for the possibility to *omit* the background within the internal "color" command (like it worked happily in NDOS - old version of 4DOS licensed to Norton).

> color cyan

... background defaults to black in NDOS and, I assume, in antique versions of 4DOS. Why this was removed (still broken as of 4DOS 8.0) is a mystery, please make it work again !

Kind regards

---
Ninho

> Hi! I wish to get Luchezar Georgiev's attention (in public) about a minute
> but annoying misfeature in 4DOS.

AFAIK Lucho leaved this forum after some flamewar so you should rather contact him personally or on some 4dos forum. I don't know I don't use 4dos.

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

> > Hi! I wish to get Luchezar Georgiev's attention (in public) about a
> minute
> > but annoying misfeature in 4DOS.
>
> AFAIK Lucho leaved this forum after some flamewar so you should rather
> contact him personally or on some 4dos forum. I don't know I don't use
> 4dos.

oh, I see... thx !

> Hi! I wish to get Luchezar Georgiev's attention (in public)

IIRC he got banned from here. So a better public place is the forum of King Udo or you can mail him: there is a "protected" - thus possibly valid and working - address on his page.

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

>> Hi! I wish to get Luchezar Georgiev's attention (in public)
>
> IIRC he got banned from here. So a better public place is the forum
> of King Udo or you can mail him: there is a "protected" - thus
> possibly valid and working - address on his page.

I emailed Lucho - don't know if he got the mail, anyway... from that ongoing thread at comp.os.msdos.4dos <http://groups.google.com/group/comp.os.msdos.4dos/browse_thread/thread/738f4d9c0a03fd0f#>
... it appears he won't take this or other suggestions any more. I've come at the wrong moment !

Oh, well, if they find a new maintainer (let's hope!) I'll be back to them.

QUOTE "
There will probably not be any never versions from me past the current one
(8.00). If you know someone who can program in C and x86 Assembler and who
would like to take over the 4DOS maintenance, please ask him. [....]

My last wish is that 4DOS *never* falls into the hands of the only
FreeDOS developer left, Eric Auer. [....]

Goodbye,
Lucho
"
QUOTE END

---
Ninho

> I emailed Lucho - don't know if he got the mail, anyway... from that
> ongoing thread at comp.os.msdos.4dos
> <http://groups.google.com/group/comp.os.msdos.4dos/browse_thread/thread/738f4d9c0a03fd0f#>
> ... it appears he won't take this or other suggestions any more. I've come
> at the wrong moment !
>
> Oh, well, if they find a new maintainer (let's hope!) I'll be back to
> them.
>
> QUOTE "
> There will probably not be any never versions from me past the current
> one
> (8.00). If you know someone who can program in C and x86 Assembler and
> who
> would like to take over the 4DOS maintenance, please ask him. [....]
>
> My last wish is that 4DOS *never* falls into the hands of the only
> FreeDOS developer left, Eric Auer. [....]

The only technical reason for him not continuing to develop 4DOS is some relocation limit, from what I've heard him say.

And I'm not sure why he still holds grudges against some people, particularly Eric Auer, who never did anything to him (as far as I know). Eric is a very nice person, and FreeDOS users owe a lot to him, probably more than anybody else. But anyways, I'm not mad at Lucho, just don't understand his positions sometimes. (Besides, I think his site still claims some problems building with OpenWatcom 1.8, so it's still stuck to MSVC + MASM, I think, ugh.)

> Eric is a very nice person,

Sure

> and FreeDOS users owe a lot to him, probably more than anybody else.

I'm aware of the LBAcache and FDapm tools. Perhaps you did have access to knowledge which is - or was - forbidden for us normal mortals, so please elaborate!

---
MS-DOS forever!

> > Eric is a very nice person,
>
> Sure
>
> > and FreeDOS users owe a lot to him, probably more than anybody else.
>
> I'm aware of the LBAcache and FDapm tools. Perhaps you did have access to
> knowledge which is - or was - forbidden for us normal mortals, so please
> elaborate!

I think I've literally e-mailed Eric about 1000+ times in the past two years. He's done so much for FreeDOS that's it's shocking. He's patched or written or updated a million things that no one else ever got close to doing. I can't even remember it all, but if pushed I could try!

cpulevel, finddisk, sysmem, xmssize, 3-disk ("brezel"), fdshield, runtime, locktone, calcfixp, FD edit, callver, graphics, dosfsck, mode, para631, gfx_mine, snake_vr, cdrcache, ctmouse 2.1b4, devload, cdrom2, eecho, filetype, freetest, getserno, whichfat, moresys, memteste stub, pcisleep, terminal, etc. etc. (web page updates, server admin crud, lots of testing, probably other things I'm forgetting).

IIRC, the only other people I've e-mailed nearly 1/10th as much are Octavio Vega Fernandez (back before work overtook him) and David Lindauer (back when CC386 was on fire with updates). All equally nice and brilliant people.

And FYI, that's not to discount anybody on this forum either. I'd every bit as much praise you guys for your efforts too! (Remember, Japheth, you're FreeDOS Man of the Year 2008 ... of course, that's just my humble opinion!)

> cpulevel, finddisk, sysmem, xmssize, 3-disk ("brezel"), fdshield, runtime,
> locktone, calcfixp, FD edit, callver, graphics, dosfsck, mode, para631,
> gfx_mine, snake_vr, cdrcache, ctmouse 2.1b4, devload, cdrom2, eecho,
> filetype, freetest, getserno, whichfat, moresys, memteste stub, pcisleep,
> terminal, etc. etc. (web page updates, server admin crud, lots of testing,
> probably other things I'm forgetting).

I know that you love to supply huge lists, but you probably should be aware that some people - including me - won't get intimidated by such "information", because they prefer quality over quantity.

> IIRC, the only other people I've e-mailed nearly 1/10th as much are
> Octavio Vega Fernandez (back before work overtook him) and David Lindauer
> (back when CC386 was on fire with updates). All equally nice and brilliant
> people.

I know that you love to talk, so it's not very surprising for me that you like people who are "slightly" talkative.

> And FYI, that's not to discount anybody on this forum either. I'd every
> bit as much praise you guys for your efforts too! (Remember, Japheth,
> you're FreeDOS Man of the Year 2008 ... of course, that's just my humble
> opinion!)

This isn't appreciated, because I use FreeDOS for testing purposes only. I still prefer MS-DOS, simply because it is better IMO. Additionally, I'm not a victim of the "Freedom illusion", so the GPL-guy's propaganda is unable to have any impact on my thinking.

---
MS-DOS forever!

> I think I've literally e-mailed Eric about 1000+ times in the past two
> years. He's done so much for FreeDOS that's it's shocking. He's patched or
> written or updated a million things that no one else ever got close to
> doing. I can't even remember it all, but if pushed I could try!

Maybe Eric has done many things for FreeDOS, as you say, but he unfortunately lacks a quality indispensable for people's collaboration, a quality which is called open-mindedness. Someone who is so obstinate I assure you that is not as great as you pretend.

---
Glory to God for all things

> I know that you love to supply huge lists, but you probably should be
> aware that some people - including me - won't get intimidated by such
> "information", because they prefer quality over quantity.

Like making sure HIMEMX runs on 386s? (Still waiting on that patch.)

> > IIRC, the only other people I've e-mailed nearly 1/10th as much are
> > Octavio Vega Fernandez (back before work overtook him) and David
> Lindauer
> > (back when CC386 was on fire with updates). All equally nice and
> brilliant
> > people.
>
> I know that you love to talk, so it's not very surprising for me that you
> like people who are "slightly" talkative.

For all the whining I always hear from various people "Report a bug, write a patch, roll your own, port it yourself, test it yourself, contact the author", guess how all of that is accomplished? Talk.

> > And FYI, that's not to discount anybody on this forum either. I'd every
> > bit as much praise you guys for your efforts too! (Remember, Japheth,
> > you're FreeDOS Man of the Year 2008 ... of course, that's just my
> humble
> > opinion!)
>
> This isn't appreciated, because I use FreeDOS for testing purposes only. I
> still prefer MS-DOS, simply because it is better IMO.
> Additionally, I'm not a victim of the "Freedom illusion", so the GPL-guy's
> propaganda is unable to have any impact on my thinking.

What's so superior about closed source, abandoned software? The minute big business decides to break hardware and software compatibility, you're screwed anyways. At least some people try to make things work (or continue to work) to the best of their ability instead of throwing everything away. MS couldn't give a crap about DOS or OS/2 or Win16 or even Win9x anymore (even XP is almost obsoleted by them). No, I don't think you should delete a perfectly fine working MS-DOS install, but at the same time, e.g. I don't think their DEBUG is really up to snuff, SMARTDRV could be improved, EDIT is too weak for my tastes, codepage support is less than stellar, etc. And if you think their kernel doesn't have bugs, you're wrong:


* 2165, BUG: nonfunctional in MS-DOS 4.00 through 7.10 (Win98) due to a bug (the code sets a pointer depending on the high bit of AL, but doesn't clear the bit before branching by function number).  Supported and functional(!) in Novell DOS 7 (Update 15), as well as PC-DOS 7 and OS/2 MVDM

* 2F1230, BUG:  Win95-OSR2 is reported to have a bug that can potentially corrupt memory if SFT tables are "arranged poorly"

* 2F1231, BUG:  Windows98 will crash the system if DL>02h on entry due to an off-by-1 conditional jump; if the jump were correct, the function would return CF set/AX=0001h as for Windows95


> What's so superior about closed source, abandoned software? The minute big
> business decides to break hardware and software compatibility, you're
> screwed anyways. At least some people try to make things work (or continue
> to work) to the best of their ability instead of throwing everything away.

MS-DOS 7.10, which I use since 1999, is by far the best DOS available (I tested them all, believe me), and I'm afraid there will never be a better DOS. Even if "cm" thinks perhaps that I'm wrong.

EDIT: Those people (how many left?) who try to make "the things work" don't sacrifice their lives on any altar, they have no other things to do with their spare time. Better would have been if they would have consumed their time in other areas of interest - re: DOS.

---
Glory to God for all things

> Like making sure HIMEMX runs on 386s? (Still waiting on that patch.)

The problem is: I modified this himem thing mainly for myself, I don't regard myself as "maintainer". So, since I don't have a working 386 computer anymore - and probably also won't buy one on Ebay anytime soon -, it might take a while until a patch is released.

But returning to your list: dosfsck and ctmouse are probably also "quality" tools, but I somehow doubt that one can call them "Eric's tool" just because he has added a line or two to the sources.

> For all the whining I always hear from various people "Report a bug, write
> a patch, roll your own, port it yourself, test it yourself, contact the
> author", guess how all of that is accomplished? Talk.

Yes, if used intelligently then communication has advantages...

---
MS-DOS forever!

> Even if "cm" thinks perhaps that I'm wrong.

I think that RxDOS might become a compatible DOS kernel first. If this happens, lets talk about whether I'll want to replace my MS-DOS 7.10 installation with it then. Yes. I'm not using DOS-C either. If I did, some things probably would've annoyed me enough to fork my own versions, and that's really work I don't want to do.

> I think that RxDOS might become a compatible DOS kernel first. If this
> happens, lets talk about whether I'll want to replace my MS-DOS
> 7.10 installation with it then. Yes. I'm not using DOS-C either. If I did,
> some things probably would've annoyed me enough to fork my own versions,
> and that's really work I don't want to do.

I hope you'll be able to even leave behind MS-DOS 7.10, but hardly I'm afraid that in the future you'll have less spare time or you'll find something better to do with your free time left. I really want to think that your project will find finality, but I have my reserves. And I'm sorry, but I don't believe in "one man shows". My apologies if you feel somehow offended.
Good luck!

---
Glory to God for all things

> I really want to think
> that your project will find finality, but I have my reserves. And I'm
> sorry, but I don't believe in "one man shows". My apologies if you feel
> somehow offended.

No way! I'm rather afraid of too high expectations. Thank you anyway. We can discuss whether to replace MS-DOS if I'm finally releasing something which could replace it.

> Like making sure HIMEMX runs on 386s? (Still waiting on that patch.)

Here you have HIMEMX for 386sx
http://rayer.ic.cz/os/himemx33.zip

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

> MS-DOS 7.10, which I use since 1999, is by far the best DOS available (I
> tested them all, believe me), and I'm afraid there will never be a better
> DOS. Even if "cm" thinks perhaps that I'm wrong.

"Never" is a strong word. But if you'd said "There will never be a better MS-DOS, you'd be correct.

Even if you have sporadically tried all the other DOSes (which I highly doubt), there's no way you tested them in all situations exhaustively. MS has better testing than you and they still can't get NTVDM up to par, even compared to previous versions. (Vista's NTVDM is actually dated older than XP's and works worse in most ways.)

DOSBox, ROM-DOS, PTS-DOS, PTS-DOS32, FreeDOS, FreeDOS-32, DOS-C, RxDOS, ZDOS, RDOS, Novell DOS, OpenDOS, DR-DOS (not the same!), IBM PC DOS, and a bunch of other weird variants that Lucho would know more about than I would. It's too much for one man to test. And let's be honest, without an active developer or sources, it's dead. If you like MS-DOS 7.10, fine, but don't expect it to do what you want in all cases because it won't, no matter how much you add on top. (It's amazing how little FreeDOS is used by you guys. Oh well, whatever. To each his own.)

> > Like making sure HIMEMX runs on 386s? (Still waiting on that patch.)
>
>
> Here you have HIMEMX for 386sx
> http://rayer.ic.cz/os/himemx33.zip

For completeness here's the GNU diff output against HimemX 3.32.

--- HIMEMX332.ASM Tue Mar 11 15:24:50 2008
+++ HIMEMX333.ASM       Sun Apr 27 01:50:02 2008
@@ -6,6 +6,7 @@
 ; original work by Till Gerken.
 ; major rework by tom ehlert.
 ; modified for >64M support, Michael Devore
+; 386/486 PMode switch patch by Ninho, tested by RayeR on Am386SX-25
 ;
 ; If you would like to use parts of this driver in one of your projects, please
 ; check up with me first.
@@ -86,7 +87,7 @@
 
 ;--- assembly time parameters
 
-VERSIONSTR             equ <'3.32'>
+VERSIONSTR             equ <'3.33'>
 DRIVER_VER             equ 300h+32
 INTERFACE_VER  equ 300h
 
@@ -1324,6 +1325,9 @@
     mov cr0,eax
 ;--- the 80386 (and 80486?) need a short delay after switching to PM
 ;--- before a segment register can be set! Any instruction is sufficient.
+flushes both the instruction prefetch and predecode queues.
+flushes both the instruction prefetch and predecode queues.
+    jmp $+2                 ; flush both the instruction prefetch and predecode queues
     dec ax                  ; clear PE bit
     mov ds,dx
     mov es,dx

---
Forum admin

> And let's be honest, without an active developer or sources, it's dead.

and

> It's amazing how little FreeDOS is used by you guys. Oh well, whatever. To each his own.

This isn't "amazing", it's reasonable and a matter of course. Let's see the FD pros and cons:

[talkative]

+ FD is "free" and "open source".

Fine - but virtually a non-issue for 99.97% of the FD users ( as you can see, I'm optimistically assuming that there are 10.000 FD users and 3 of those are able to understand the sources). Additionally, FD costs nothing, but since there are at least 1 billion of WinXP or Win9x licenses around which include MS-DOS 8 or 7.1, it isn't that big an advantage for private users.

+ FD is "alive"

There is reportedly a maintainer remaining for the FD kernel, but I'm unable to see "progress" - on the contrary, the recent versions of the FD kernel are now incompatible with HX, and I don't believe this will change anytime soon.

- FD is slow(er)

This was the result of a test a couple of years ago and since nothing has changed on the FD side I assume it is still valid. The differences were "significant".

- FD isn't fully compatible

some things are implemented differently (syntax of config.sys), some things are missing altogether. Anyways, some apps won't run, or at least won't run properly. Regrettably at least one of those apps (OW's WD) is frequently used by me.

[/talkative]

---
MS-DOS forever!

> Even if you have sporadically tried all the other DOSes (which I highly
> doubt), there's no way you tested them in all situations exhaustively. MS
> has better testing than you and they still can't get NTVDM up to par, even
> compared to previous versions. (Vista's NTVDM is actually dated older than
> XP's and works worse in most ways.)

I didn't refer to any exotic/experimental/toy DOSes, but to those DOSes which are intended to be actually used, not only tested/tried. To be more explicit I have enough experience with any of MS-DOS, FleaDOS, DR-DOS and PC-DOS, and limited experience with PTS-DOS and ROM-DOS. But by simply pointing to a heterogeneous list of software you convince no one neither that there will be a DOS better than MS-DOS 7.10, nor that such a DOS already exists. And there is no need to test exhaustively (i.e., in all possible situations, which is practically impossible) an OS in order to see how well it works.

---
Glory to God for all things

> but since there are at least 1 billion of WinXP or Win9x licenses around
> which include MS-DOS 8 or 7.1, it isn't that big an advantage for private
> users.

MS-DOS 8 however only runs properly from floppy disks, so forget about WinXP here. (There's some hack to run from hard disk but it still doesn't process CONFIG.SYS then.)

---
l

> I didn't refer to any exotic/experimental/toy DOSes, but to those DOSes
> which are intended to be actually used, not only tested/tried. To be more
> explicit I have enough experience with any of MS-DOS, FleaDOS, DR-DOS and
> PC-DOS, and limited experience with PTS-DOS and ROM-DOS. But by simply
> pointing to a heterogeneous list of software you convince no one neither
> that there will be a DOS better than MS-DOS 7.10, nor that such a DOS
> already exists. And there is no need to test exhaustively (i.e., in all
> possible situations, which is practically impossible) an OS in order to
> see how well it works.

Jim Leonard heavily prefers PC DOS over any other, and that's on an IBM 5160 8088 (I think) with CGA. I think he said it's fastest but also just plain good. I've never tried it.

Matthias Paul worked on DR-DOS for years, and he heavily preferred it. Every time I read some message he wrote on Usenet or otherwise, he makes it sound like DR-DOS truly is better in every way (memory management, tools, speed). Obviously, though, it probably won't ever be updated (nor will MS-DOS) and only supports FAT16. So, if those are your requirements, you'd better prefer FreeDOS. (And BTW, OpenDOS lacks about a year's worth of work that Novell DOS had. And DR-DOS had a lot of work done since then too. I'm not trying to split hairs here.)

Having never tried PTS-DOS, I can't say much about it, but it had built-in compression, smaller footprint (written in assembly?), and CD-ROM redirector built into the kernel among other things.

Note that my testing scenario means you have to test all popular compilers, network redirectors, USB and other quirky device drivers, TSRs, as well as make sure things like codepages/COUNTRY.SYS/NLSFUNC.EXE etc. work correctly. Some work better than others, and if you'd really kept up with FreeDOS, you'd know how hard it is (and how impossible it is for one DOS to truly be better in all ways.)

> > And let's be honest, without an active developer or sources, it's dead.
>
> and
>
> > It's amazing how little FreeDOS is used by you guys. Oh well, whatever.
> To each his own.
>
> This isn't "amazing", it's reasonable and a matter of course. Let's see
> the FD pros and cons:
>
> [talkative]
>
> + FD is "free" and "open source".
>
> Fine - but virtually a non-issue for 99.97% of the FD users ( as you can
> see, I'm optimistically assuming that there are 10.000 FD users and 3 of
> those are able to understand the sources). Additionally, FD costs nothing,
> but since there are at least 1 billion of WinXP or Win9x licenses around
> which include MS-DOS 8 or 7.1, it isn't that big an advantage for private
> users.

Believe it or not, there are plenty of people that don't have licenses for Windows (yes, it surprised me too), esp. those who buy computers to manually assemble or recycle old ones. A lot of them prefer GNU/Linux, which I'm sure you've heard of. And MS isn't too keen on sharing files with non-subscribers, so FreeDOS is your only choice there. (Now if only somebody somewhere would actually include DOSEMU + FreeDOS in a distro!)

Besides, OEM licenses of Windows are get stricter by the version ("this computer only"). And even if "only 3" understand the sources, at least they can learn and fix it eventually (unlike MS-DOS). I think FreeDOS is a bit stagnant only because it's "good enough" for those who worked on it. Also, they don't do this for money, so they do have other responsibilities and jobs. Plus, as even Linux devs will tell you, you can't keep up a frantic developing pace forever, it wears you out. Sometimes you have to take a hiatus.

> + FD is "alive"
>
> There is reportedly a maintainer remaining for the FD kernel, but I'm
> unable to see "progress" - on the contrary, the recent versions of the FD
> kernel are now incompatible with HX, and I don't believe this will change
> anytime soon.

What kernel has what incompatibility? I've never heard anything about this. (Although, to be fair, you also said OpenWatcom 1.8 wasn't compatible anymore either. I don't know why.) E-mail the freedos-kernel mailing list if you have to.

> - FD is slow(er)
>
> This was the result of a test a couple of years ago and since nothing has
> changed on the FD side I assume it is still valid. The differences were
> "significant".

As I recall, this was just a COPY test. There are many third-party tools that will be much faster. We're just talking defaults here. And since most people don't need that, it hasn't been worked on.

> - FD isn't fully compatible
>
> some things are implemented differently (syntax of config.sys),

Actually, MS didn't implement DR-DOS' syntax correctly (since they invented it first). So I don't know which was supposed to be preferred by FreeDOS (although I think there was a patch in the works at one time by Arkady to mirror MS-DOS MENU syntax).

> some
> things are missing altogether. Anyways, some apps won't run, or at least
> won't run properly. Regrettably at least one of those apps (OW's WD) is
> frequently used by me.

Won't run at all or just has quirks? There are some minor incompatibilities, yes, e.g. TC++ 3.0 last I heard, and it's a shame, but it's not nearly as bad as you make it sound. This isn't set in stone, guys. If you have a problem with it, either find somebody to fix it or try fixing it yourself.

Firstly, you should have understood that I did refer only to the kernel, not to the full contents of the package (drivers, tools, utilities) associated with one DOS or another. I have to accept that I haven't tried PC-DOS on an 8088, but on the systems I used it I can assure you that it's not at all faster, as neither DR-DOS is. OTOH the 'built-in' things are rather a loss than a gain. What happens if people don't need them or have found better alternatives? And I'm sorry to say, but from all the DOSes I enumerated, I found PTS-DOS to be the worst (but not far worse than ROM-DOS).
I still can't see nothing concrete from you. Give a single example of a program which strongly uses int 21h calls and runs better/faster in the same testing conditions (same hardware, same DOS configuration) with any other DOS than MS-DOS. Eventualy post your profiling results here.

---
Glory to God for all things

> Firstly, you should have understood that I did refer only to the kernel,
> not to the full contents of the package (drivers, tools, utilities)
> associated with one DOS or another.

The kernel is obviously most important, but then again, without all the tools, it's fairly wimpy. You really think it'd be best to use only official MS tools, even in this day and age? (I suspect you use JEMMEX, UIDE, a better editor, etc, which is most sensible.)

> I have to accept that I haven't tried
> PC-DOS on an 8088, but on the systems I used it I can assure you that it's
> not at all faster, as neither DR-DOS is. OTOH the 'built-in' things are
> rather a loss than a gain. What happens if people don't need them or have
> found better alternatives? And I'm sorry to say, but from all the DOSes I
> enumerated, I found PTS-DOS to be the worst (but not far worse than
> ROM-DOS).

Oops, I forgot to mention EDR-DOS, which is yet another fairly big change in the DR-DOS line. Yes, I've heard PTS-DOS is a little buggy, but I think RxDOS (no offense) is even buggier. Still, probably not completely useless.

> I still can't see nothing concrete from you. Give a single example of a
> program which strongly uses int 21h calls and runs better/faster in the
> same testing conditions (same hardware, same DOS configuration) with any
> other DOS than MS-DOS. Eventualy post your profiling results here.

Win 3.x runs anywhere from 10% to 30% faster on DR-DOS. At least that's what I've been told. I haven't (and wouldn't know how) to benchmark that, though. But that's the best example I know of. (Although I do remember benchmarking XCOPY and RxCOPY etc. on MS-DOS vs. FreeDOS on my 486, and in most cases it was much faster on FreeDOS. I forget the details, would have to check old e-mails with Eric, or maybe he remembers, who knows.)

Anyways, if you have a problem with FreeDOS, best is to check against 2036 stable, 2037 unstable, and 2038pre. Part of the problem is that they haven't merged all changes into a single official kernel (yet) due to not confirming that old bugs have been fixed, nothing regressed / broke, etc. I think Eric wants to do that, eventually, if he can ever make his list of what changed in 2037.

> Yes, I've heard PTS-DOS is a little buggy, but I think RxDOS (no offense)
> is even buggier. Still, probably not completely useless.

Be assured that RxDOS has the most bugs. The only reason I don't consider it "completely useless" is because it's open source (and of course because that's the coolest DOS name, no offense ).

> benchmarking XCOPY and RxCOPY etc.

Nice try, but I think you meant FreeDOS's RXCOPY. I'm not aware it has anything to do with RxDOS.

---
l

> > Yes, I've heard PTS-DOS is a little buggy, but I think RxDOS (no
> offense)
> > is even buggier. Still, probably not completely useless.
>
> Be assured that RxDOS has the most bugs. The only reason I don't consider
> it "completely useless" is because it's open source (and of course because
> that's the coolest DOS name, no offense ).

Well, the only real problem with it is that it hasn't been polished and tested enough. And that's probably due to the MASM-only sources (although as mentioned, a rough A86 port exists). The more the merrier, esp. an assembly version!

> > benchmarking XCOPY and RxCOPY etc.
>
> Nice try, but I think you meant FreeDOS's RXCOPY. I'm not aware it has
> anything to do with RxDOS.

I do mean FreeDOS' "RxCOPY", which is what they call it (don't ask me why). It doesn't have anything to do with RxDOS, AFAICT.

P.S. Checking old messages, it seems there was a lot of discussion over whether to migrate to or incorporate either OpenDOS or RxDOS kernel features. But I guess DOS-C was better / easier (and obviously better license than OpenDOS). I think Tom E. told us here not too long ago that C was chosen due to easier maintenance for the developers at the time. I think it was a good decision.

> What kernel has what incompatibility? I've never heard anything about
> this. (Although, to be fair, you also said OpenWatcom 1.8 wasn't
> compatible anymore either. I don't know why.) E-mail the freedos-kernel
> mailing list if you have to.

Sorry, I cannot remember the names and dates of the numerous FD kernels which lay around here and there. I reported the bug ( it was about Ctrl-C terminating my FTE "session" ), it's known by the FD kernel development crew, so we can confidently wait and see.............

> but it's not nearly as bad as you make it sound.

Hey, I said that some apps have problems. I don't see that this is making it sound worse than it is.

> If you have a problem with it, either find somebody to fix it or try
> fixing it yourself...

... or use another DOS if you prefer the lazy way out - which I did .

---
MS-DOS forever!

> Well, the only real problem with it is that it hasn't been polished and
> tested enough.

Which would easily show many bugs.

> And that's probably due to the MASM-only sources (although
> as mentioned, a rough A86 port exists).

Yeah, I heard about the A86 port only after I've got my own port to assemble with NASM

> > > benchmarking XCOPY and RxCOPY etc.
> >
> > Nice try, but I think you meant FreeDOS's RXCOPY. I'm not aware it has
> > anything to do with RxDOS.
>
> I do mean FreeDOS' "RxCOPY", which is what they call it (don't ask me
> why).

It's apparently called exactly RXCOPY, I guess because it's the XCOPY that is/was maintained by Rene.

---
l

Japheth wrote:

> + FD is "free" and "open source".
> Fine - but virtually a non-issue for 99.97% of the FD users
> ( as you can see, I'm optimistically assuming that there
> are 10.000 FD users and 3 of those are able to understand
> the sources). Additionally, FD costs nothing, but since there
> are at least 1 billion of WinXP or Win9x licenses around which
> include MS-DOS 8 or 7.1, it isn't that big an advantage for private users.

Nor for pirates, even source code is available for the good guys having the proprietary tools from MacroSoft available:

(link removed)

> + FD is "alive"
> There is reportedly a maintainer remaining for the FD kernel,
> but I'm unable to see "progress"

Recently (2009-May) seems a few things got fixed

http://freedos.svn.sourceforge.net/viewvc/freedos?view=rev&revision=1384

> on the contrary, the recent versions of the FD kernel are now incompatible
> with HX, and I don't believe this will change anytime soon.

What an excellent BUG report Please reveal what they do wrong (steps to reproduce ???)

> - FD is slow(er)
> This was the result of a test a couple of years ago and since nothing
> has changed on the FD side I assume it is still valid. The differences
> were "significant".

Slower in what activity ?

> - FD isn't fully compatible

Non-issue

> some things are implemented differently (syntax of config.sys)

It's a feature

> some things are missing altogether.

Examples ?

> Anyways, some apps won't run, or at least won't run properly.
> Regrettably at least one of those apps (OW's WD) is frequently used by me.

It could be a BUG of FreeDOS or a BUG of OW-WD

> it was about Ctrl-C terminating my FTE "session"
> it's known by the FD kernel development crew,
> so we can confidently wait and see.............

Regrettably this "bug" is unique to your experimental FTE binary, I don't have this "bug" in FASM edtior, so most likely it's a bug of FTE source or some of your FTE hacks

> > it was about Ctrl-C terminating my FTE "session"
> > it's known by the FD kernel development crew,
> > so we can confidently wait and see.............
>
> Regrettably this "bug" is unique to your experimental FTE binary, I don't
> have this "bug" in FASM edtior, so most likely it's a bug of FTE source or
> some of your FTE hacks

I once tried the provided FTE binary but it crashed on MS-DOS as well, so it seems that this is not a problem of FreeDOS.

---
l