Mail Archives: opendos/1997/03/13/22:29:38
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
- Raw text -