From: dg AT dcs DOT st-and DOT ac DOT uk
Message-Id: <15137.9703150457@linkwood.dcs.st-andrews.ac.uk>
To: opendos AT mail DOT tacoma DOT net
Subject: Re: [opendos] Wishlist v2.0 
In-Reply-To: tbird@caldera.com's message of Fri, 14 Mar 97 14:03:26 -0700.
	     <199703142103 DOT OAA13180 AT caldera DOT com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 15 Mar 97 04:57:06 +0000
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk

[...]
>"Undocumented DOS" contains all (OK, most) of the information needed to do 
>this.  I wrote the NetWare lite client using this book.  When the
>OpenDOS source is available, there will be more than enough information
>to work on additional IFS modules.  (BTW, I also wrote LREDIR.EXE.  I
>don't know what LREDIR.SYS is, but I presume is a derivative work. Thanks
>a lot for the "nightmare" quote. :^)  If you want to get started
>now, and can't find "Undocumented DOS", most of the information came
>from Ralph Brown's "Interrupt List for DOS", available from several
>sites on the Web.

Actually, I was wrong here. EMUFS.SYS and LREDIR.EXE are fine; EMUFS.SYS is a 
rather nice little stub that looks as if it'll come in useful. The uncommented 
nightmare is the DOSEMU back end, mfs.c, which I have had dealings with before 
(trying to get it working on a 64-bit Alpha is not easy, trust me).

[...]
>I agree in part.  I don't have aything less than a 386 anymore, so I
>wouldn't be bothered by a 32-bit kernel or utilities.  Because it is
>an important market, the 16-bit code should continue to be supported.
>It should be possible support both in the code (conditional code)
>in many places, and use install-time or run-time checks to use
>appropriate code.  You don't have to substantially change DOS as an
>OS to benefit from some 32-bit code.

As the owner of several XT's (which I actually get useful work done on), I'm 
not happy about the idea of splitting things into pre-386 and post-386 
versions. That's the first step on the slippery slope down to dropping pre-386 
machines completely, because `nobody uses them any more'. (This is total 
nonsense. XT's and 286's are great machines, and are really useful for some 
things. These days its fashionable to assume that you can't get by without the 
latest Pentium Pro MMX with 64-bit bus and a 3D-enhanced graphics card. This 
fashion is, regardless to say, encouraged by the hardware and software 
manufacturers, and is completely baseless. A 286 is sufficient for most 
people's needs. Only a tiny proportion of the vast capability of modern 
machines is actually used for useful work; the rest is frittered away on 
things like the user interface.)

That said, yes, the 32-bit instructions can be useful. 4GB segments can be 
really handy, for example, as can the extended maths instructions. But I don't 
see much point in shifting everything to 32-bit code unless there's a good, 
compelling reason.

[...]
>> Yes, but but it won't *run* from that older version. It'll let you boot into 
>> your old DOS, *or* into MS-DOS 7 and Windows 95. It won't let you do both.
>First, you need to be more careful about saying something is "not
>possible".  That's not true.  Instead, say something like "hard", or
>"not worth it".  My own analysis is that this would be of medium
>difficulty.  Whether it would be worth it would depend on what other
>features of the kernel you could end up using under Win95.  You should
>be able to use many of the shell and utility features now (or soon, with
>long name support added).  

That bit was actually referring to someone confusing the ability to boot an 
old DOS *from* Win 95 with the ability to run Win 95 *on* the old DOS. I know 
that Win 95 gets rather confused if you try to run it on top of something 
else; I've got a nasty feeling that it uses all sorts of undocumented 
features. (Remember Win 3.1 and VM86 mode?) However, as a proud non-owner of 
Win 95 I'm not up-to-date on its internals, and I don't intend to have to 
become so.

[...]
>> Are *you* willing to backport the several million DOS programs that are 
>> currently in existence?
>No, but I'd be happier than I would otherwise be if one or two new
>programs came this way.  I don't expect to be resurrecting lots of
>old DOS programs for use with OpenDOS.  I'm not sure why I'd have to
>retrofit all of them (including ones I don't use) in order to see a
>benefit here.  If I went looking for 10 things on my drive I'd
>rather easily find 2 of them than none of them.

I'm afraid it's safe to say that there aren't going to be many new programs 
written specifically for OpenDOS. I think that most programs are going to be 
either old MS-DOS ones or new MS-DOS ones. Neither are going to abide by a 
OpenDOS file system standard.

>And another comment on retrofitting:  There is a large body of software
>which I might envision using on DOS, which installs from .ZIP files.
>Any degree of automation or wrappers that would ease downloading,
>installing, and uninstalling the files would be nice. (However,
>package placement (FSSTND) is related but distinct from 
>package management.

What I was really referring to was the `standard path' API currently being 
discussed in parallel. While a good idea, it only works if programs actually 
take notice of the API and ask it what the paths are. The vast, vast majority 
of any software being used won't.

Actually, the main problem I find is the path limitation. If you could specify 
large search paths it's relatively trivial to keep your hard drive organised. 
Unfortunately, while >128 char paths are possible, they're difficult, and >256 
char paths are even more so. Currently I have:

	C:\SYSTEM\OPENDOS
	C:\SYSTEM\UTILS
	C:\SYSTEM\HARDWARE
	C:\SYSTEM\NETWORK
	...

What I'd really *like* is:

	C:\SYSTEM\OPENDOS
	C:\SYSTEM\UTILS\ARCHIVERS
	C:\SYSTEM\UTILS\GNUISH
	C:\SYSTEM\UTILS\EDITORS
	C:\SYSTEM\UTILS\PROGRAMMING
	[...]
	C:\SYSTEM\HARDWARE\SOUND
	C:\SYSTEM\HARDWARE\NETWORK
	C:\SYSTEM\HARDWARE\VIDEO
	[...]
	C:\SYSTEM\NETWORK\NCSA
	C:\SYSTEM\NETWORK\CRYNWR
	[...]

This would avoid problems like my UTILS directory being so big that I can't 
see it all on the screen at once. Perhaps a feature to search a directory *and 
subdirectories* on the path? How complex would that be?

>Thanks for your comments, they have generated a lot of good 
>discussion.

The aim was to cast some of the Light of Reason on some of the discussions 
that, admit it, can get about over-the-top at times.


[If this seems incoherent, check the sending time.]

[Please do *not* cc: replies to me!]

-- 
------------------- http://www-hons-cs.cs.st-and.ac.uk/~dg --------------------
   If you're up against someone more intelligent than you are, do something
    totally insane and let him think himself to death.  --- Pyanfar Chanur
---------------- Sun-Earther David Daton Given of Lochcarron ------------------