Date: Thu, 13 Mar 1997 21:58:49 -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: <15396.9703132259@orkney.dcs.st-andrews.ac.uk> Message-ID: Organization: Total disorganization. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-opendos AT mail DOT tacoma DOT net Precedence: bulk On Thu, 13 Mar 1997 dg AT dcs DOT st-and DOT ac DOT uk wrote: > >Okay, I've updated the wishlist that I'm keeping. > >Here it is: > > > >1] Direct screen write > > No. Direct screen write is totally inappropriate in the kernel. It uses up > valuable kernel space (64kB limit, remember?) and reduces flexibility. The > kernel should just pass on requests to the BIOS; if you want direct screen > writes, then you can load a TSR later that hooks the BIOS interrupt. That's > what it's for. This should be rephrased as "Optional direct screen writes in COMMAND.COM". > >3] IFS support > > What, you mean support for a *different* IFS than the one we've already got? > Why? Hmmm. Maybe so that we can use other filesystems such as ext2, NTFS, HPFS, and use them natively, and have access to all of their features as a standard. Symlinks, hardlinks, long filenames, case sensitivity, possibly even permissions. > >4] File Descriptions > Better suited for an external program. If I can get gdbm ported to Borland I > might give it a try. Belongs in COMMAND.COM. The descriptions show up when you do a DIR, and DIR is an internal command. > >5] Make OD boot from *any* partion or HD > Yup. (Can't be too hard.) Probably a #define in the source. > >6] Compile all drivers in the kernel > > You're kidding, right? No, it could be an option. > >10] Make the source compilable by one compiler and linker (not our job, but > >I'm sure a lot > > of people would like this)(DJGPP??????????) > > This is definitely needed. But not DJGPP. DJGPP is a 32-bit protected-mode > compiler. DOS is a 16-bit real-mode operating system. We can't use DJGPP for > *any* of OpenDOS apart from, possibly, external utilities, and even then it > would be a Really Bad Idea. Try to remember that we are going to try and improve OpenDOS as much as possible, while still maintaining backwards compatibility. This means that it is entirely possible that there will sprout forth an OpenDOS32 that has been compiled in DJGPP. The utilities will be the first to be ported. Have you ever tried to sort a file > 64k? SUCKS!!!!!!!! > >11] A compiler and linker to re-compile the kernel (DJGPP????????????) An optional install of DJGPP could be included, as well as a 16 bit C compiler. > >12] Make W95 run from OpenDOS > > Almost certainly not possible, I'm afraid; MS-DOS 7 was majorly bent to make > Win 95 work. You're probably stuck with WfW and Win32s (I don't run Windows). I doubt it. Anything is possible. If you sit 10000 monkeys down at typewriters... Consider the internet the 10000 monkeys... :o) > >13] On the fly DLD's (dual mode) (Dynamically Loaded Driver) > > Not possible with block devices and file systems, because of the way drives > are allocated. Most other drivers are already dynamic (TSR's). Loadable modules need to be looked into. They are certainly possible, the question is *HOW*? > >14] Add 4DOS's cool stuff > > Mmmm... possibly. 4DOS is very complex. I think that anyone who actually needs > the extra features can install 4DOS proper. If a few simple extensions were to > be put into the current shell (passing command lines through the % expander, > %? which returns the error level, SETVAL which evaluates numeric expressions) > that would suffice for most purposes. Naw, acquiring the 4DOS sources sounds better to me. Put the 4DOS, COMMAND.COM, and bash sources into a blender, then feed it to those 10000 monkeys. :o) > >16] Filename completion with TAB > > Vital. I find it difficult to live without it. I had a TSR called WCED that > did this, but it doesn't cooperate with the multitasker. See the 4DOS comment above. > >21] Coredump!!! > > Well, I've been doing Unix programming for some years now and I have *never* > found a use for a coredump. HAHAHHAHA! I must agree with you there! It took me quite some time to figure out how to disable coredumps. But it *would* be nice to have a little utility that would write out the contents of memory to disk, or a range of memory. This would be blatantly simple to write. I'm planning on doing it when I've got some time and finish off some other projects. Should only take an hour or so of C hacking to do. > >22] FSSTND > > It's too late. It's never to late. This is the birth of a new generation of DOS. A "Bridge to the 21 century"! :o) > >23] Symlinks > > Yup. Interestingly, JOIN and SUBST both have 150% of the necessary > functionality between them. Unfortunately, you can't JOIN a SUBST'ed drive. > Does anyone know where I can find source for freeware versions of JOIN and > SUBST? I would think that it'd be almost trivial to write a version that did > true symbolic links. Symlinks will come in time. JOIN and SUBST provide similar services, but not exact as a symlink. REAL symlinks will come. Mark my words. :o) (Yes, I've been fiddling. No you can't have them yet. :o) > The MOST IMPORTANT thing *must* be to to fix EMM386. It just > *doesn't work* properly. Until that's done, everything else > must stay at second place. Well, EMM386 is an allready existing program. This is the OpenDOS wishlist, that belongs on the OpenDOS buglist. We need to separate the two lists. I've noticed that this list allready has bugs on it. I'm separating the two for my lists which will be given to Mark to put on the webpage. Both lists are soon forthcoming. 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 Close windows, and OpenDOS! http://www.caldera.com/dos/dos.htm