RS> And with DOS 3.3 effectively close to free on the second hand market,
 RS> whats the point of a public domain DOS anyway ?  The main attraction
 RS> with a public domain thing is getting for free what you would other wise
 RS> have to pay heaps for, say a C compiler. When the commercial product is
 RS> close to free, whats the point ?

Well there are a couple of reasons:

1. I think the fundamentals used by hobbiests should be PD
2. I like the idea of having the source code to my OS if I don't like
something.
3. I don't actually know anything about 80x86, or DOS programming, but after
finishing this exercise, I expect to know them VERY well.

 PE>> and for someone who just wants to do a bit of WP, it would seem
 PE>> reasonable.

 RS> I cant agree myself. I think the days of single tasking OSs are fading
 RS> fast. And with something like WP, people rapidly start to need the full
 RS> enchilada, spelling checking, thesaurus, font support, etc. You are even
 RS> now starting to see mainline commercial wp abandoning the DOS platform.
 RS> WordPervert has just announced that they wont be bothering with more
 RS> than maintenance on the DOS product now.

Or even simpler applications, e.g. I want to give my Grandmother a PC for
the sole purpose of being able to do a search of the dictionary to find
words using patterns like "do*" or "?ab?t".  No need
for anything other than IO.SYS, MSDOS.SYS, COMMAND.COM and some sort of
grep.

 RS> And on a new system you normally get DOS and Win bundled anyway.

Or a discount if you don't.

 PE>> Actually, someone suggested that I should see what commercial
 PE>> applications there are for a basic version of DOS in "rugged
 PE>> environments" (or something like that).  Like PC's that are used
 PE>> to control a softdrink machine.

 RS> People dont generally use a gp OS like DOS for that sort of thing. The
 RS> vast majority of those machines dont have any drives at all. And they
 RS> dont have any keyboard and screen stuff either. There is no real place
 RS> for an OS like DOS in a machine like that. DOS essentially provides an
 RS> API for use of the stuff like drives, keyboard and screen. Those
 RS> machines dont have any of those.

So what about a cut-down version of DOS?  If I have the source code to POS,
I can rip out anything they don't want.

 RS> Yeah, I could have spelt that out better. You have a choice, you either
 RS> change modes every time you want to execute the code in the rom, or you
 RS> redo the code in the rom so you dont have to change modes all the time.
 RS> OS2 has chosen to replace the code and only uses the motherboard bios to
 RS> boot the machine essentially, booting in real mode and abandoning it as
 RS> quickly as possible in the boot phase.

No, I'll be doing the mode change.  You can play "spot the time
difference" when I'm finished.  Double-blind test on 50% of real
applications.  On the other 50%, I don't mind if there is a noticeable
difference.  So long as it comes close, and I can assure you that no-one
will be able to type faster than my code can keep up with.

 PE>> What I have in mind is a clean 32-bit OS, for both application
 PE>> programs and the operating system to see, but still make it use the
 PE>> existing BIOS.

 RS> Whats the point of 32 bit anyway ?  Cant see it actually gets you very
 RS> far at all. Particularly with the app unchanged. In fact if the app is
 RS> unchanged, and the bios is unchanged, all you really to is introduce
 RS> the need for continual cpu mode swapping as you execute code in the app,
 RS> the OS and the bios. You have introduced inefficiency in the mode swaps
 RS> and havent actually gained anything.

Yes, that's a good summary of what I am trying to do.  Except I conceive
the advantages to be:

1. As much functionality as is ever wanted in the future can be added to the
32-bit version, since it's all sitting out of harm's way.

2. NEW applications can use the 32-bit interface.

3. There is an outside chance it will actually free up lower memory, for
people running short on memory, like I am at work.

 PE>> If I have to translate addresses internally, or if I have to read
 PE>> sectors into low memory, and then coyp them into high memory, it
 PE>> doesn't worry me a bit.

 RS> It should, it introduces extra overhead. If you get substantial benefits,
 RS> that extra overhead may be justifiable. If there are no substantial
 RS> benefit, you havent gained enough to warrant the extra overhead.

Oh, and I can write it in C instead of assembler, so that it's more friendly
to program in, and people to change themselves, and learn from, etc.

 PE>> I'm also only planning to produce only as much functionality as is
 PE>> provided by MSDOS.SYS and IO.SYS, ie about 80k worth of 8086
 PE>> assembler.

 RS> Well, in that case you will have even less to offer people. If they can
 RS> get the full thing with a secondhand copy of DOS 3.3, and just those two
 RS> components in the PD DOS, three guesses which they will choose.

I expect enthusiasts would like to have the source code to their OS, and my
grandmother certainly won't get any choice, since I'll be giving her the
computer for free.  Admittedly I'm only looking for an XT in AUST_TRADING for
this purpose, when I would need a 386SX-16.  I wonder how much the price
difference is going from a second-hand XT to a second-hand 386SX-16, all
other things being equal (HD etc).

 RS> A PD DOS might have some theoretical attraction for a commercial operation
 RS> which wanted to churn out lots of copys, but they would need the full DOS
 RS> with all the utes and memory managers etc.

Why would a commercial operation want to churn out lots of copies?  Or are
you talking about companies using it in-house?

 PE>> Do you think that replacing 80k of assembler in C is a massive
 PE>> operation?

 RS> I think you will get a hell of a surprise just how much is involved in
 RS> providing total compat with DOS alone, in just those two bits of DOS.
 RS> There are an awful lot of warty bits in there now. Just look at Ralph
 RS> Browns list, its a hell of a list even if you chop out all the stuff which
 RS> isnt in those two files.

Ah yes, there's my next shortcut.  Being a stickler for standards, I'm only
planning on implementing the documented ones.  Last night I counted the ones
in one of the books David Begley gave me, and there is 100 MSDOS interrupts,
and probably the equivalent in BIOS.  I will be writing INTERFACES to the
BIOS ones, and REPLACING the MSDOS ones.  I will be implementing them
according to what this book says they are.  BFN.

Paul

--- GoldED/2 2.42.G0614