Date: Thu, 20 Mar 1997 08:00:52 -0500 (EST) From: "Mike A. Harris" Reply-To: "Mike A. Harris" To: dg AT dcs DOT st-and DOT ac DOT uk cc: opendos AT mail DOT tacoma DOT net Subject: Re: [opendos] Wishlist v2.0 In-Reply-To: <15137.9703150457@linkwood.dcs.st-andrews.ac.uk> Message-ID: Organization: Total disorganization. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 15 Mar 1997 dg AT dcs DOT st-and DOT ac DOT uk wrote: > >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. No it is NOT the first step of abandoning a 16 bit DOS. It is the first step of moving OpenDOS into the future and taking advantage of features only present on newer processors. Look at Linux. It is now being ported to the 286 architecture. OpenDOS will be out available to the world to do what they want with it. Since many of us want a 386+ version, we will create it. I highly doubt that this will put a dent in the 16 bit version at all, nor would it be aimed at doing so. I've got a 286 too, and it is a useful spare machine a lot of the time. Regardless, I have a 386 and a 486 as well, and a 32bit OpenDOS would be much better on these machines. It will be done. > 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. No, I don't need a Pentium Pro MMX blah blah blah. I only need what I already have. However an enhanced 386 version of OpenDOS would greatly extend the life of my 386 and 486 systems as it would allow me to get more work done with less hassle when in DOS. It will be done. > A 286 is sufficient for most people's needs. Not in this day and age. Most people could *get by* with a 286, however most peoples needs include a user friendly system that runs modern software and uses a modern interface. Modern stuff (GUI) doesn't run very well on a 286, nor do modern applications such as WP 6.1. If you say that most people's needs would be satisfied by a 286, support it by showing figures. Make a survey if you need to. Even survey this group. I'm sure you'll find that a 286 does NOT satisfy "MOST" people's needs. It does satisfy my need for a spare terminal, or a spare editor occasionally, however my needs are far greater than that. > 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.) Well the user interface in a 32 bit OpenDOS wouldn't change very noticably IMO, so the extra power would go directly into making apps faster than making a better interface. Thus is the reason that 386+ users are interested in OpenDOS-32. > 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. There isn't a compelling reason to "shift" everything to 32 bit. That would kill off the 32 bit OS. Rather, a "port" to 32 bit for those that want it. The 32 bit version of the OS would run all or most 16 bit software, and would also run NEW 32bit specifiec OpenDOS software. (Compiled with DJGPP, or possibly with a new port of GCC that doesn't need or use DPMI, it just runs straight 32 bit.) > >> 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. That depends on what new enhancements are made to OpenDOS. If OpenDOS adds the IFS layer that we've been discussing, I think MANY new programs will come out that directly support the IFS layer. New C compiler libs would need to be made for DJGPP for all filesystem code. Or for any other C compiler. Then a simple recompile of most software would add support for the new IFS layer. If a recompile is not possible, or doesn't work for some reason, then the old method will still work. As for abiding to the OpenDOS file system standard, programs don't even need to know that it exists. It is the user who installs the program that chooses wether to abide by the standard. Either way programs will still work. > >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: Large search paths are not needed. Only a few paths need exist. In reality the only directories that should be in *ANYONE*'s path are directories that contain MANY executables such as \DOS and \UTILS (or whatever it is on a particular computer) as well as programs that *EXPECT* their dir to be in the path such as Borland C, Windows, etc... Dirs with 1 or 2 executables in them have no need in the path. A much better solution to them is either a batch file or an alias, or a menu program. Or simply just CD to the directory and run them. > 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. Light of Reason? That is subjective and relative. We need to define exactly what a filesystem standard is, what exactly the IFS is, etc... THEN and ONLY then can we start to decide on implementation details. Sound fair? Mike A. Harris | http://blackwidow.saultc.on.ca/~mharris Computer Consultant | Coming soon: dynamic-IP-freedom... My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html mailto:mharris AT blackwidow DOT saultc DOT on DOT ca Question: Does anyone know how to get talk to work in Linux?