Mail Archives: opendos/1997/03/14/16:19:37
> >>>3] IFS support
> >>What, you mean support for a *different* IFS than the one we've
> >>already got?
> >The whole point of IFS is to have more than you already have. What if
> >you have a Linux drive on your system? Think FAT'll let you use it?
>
> I do believe that people have a rather mistaken idea of what an IFS is. IFS
> stands for Installable File System. This lets you install run-time drivers
> that will give invisible access to non-standard file systems. Contrary to
> popular belief, DOS has extensive support for this. Example: NWCDEX is an IFS
> that gives access to ISO9660 and High Sierra format filesystems, on CD.
> Example: Personal Netware is an IFS that gives access to remote file systems
> mounted via Netware (I forget exactly what protocol). Example: INTERLNK is an
> IFS. Example: I once had a program that gave access to about 150 formats of
> CP/M floppy discs. That, too, was an IFS.
>
> What's needed is not IFS *support* (that's already there) but the IFS modules
> themselves. I'd like an ext2 module as much as the next sentient being. I'd be
> willing to give it a try, myself; unfortunately, I can't find any on-line
> documentation or source. The closest I've got is the DOSEMU LREDIR.SYS source,
> which is an uncommented nightmare. If anyone can give me a pointer I'd be
> grateful.
"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.
>
> >>>10] Make the source compilable by one compiler and linker (not our
> >>This is definitely needed. But not DJGPP. DJGPP is a 32-bit
> >And yet, isn't a 32bit DPMI OS which utilizes V86 consoles _definitely_
> >what we want? The only problem is the overhead - for just the kernel,
> >though, and without any external crap (sound, graphics, et cetera,
> >they're all drivers) the kernel shouldn't be too bad.
>
> DOS is a 16-bit real-mode operating system. It is *not* a 32-bit protected
> mode operating system. If you want a 32-bit protected mode operating system,
> use Linux or Demos or something. If you want to try to convert DOS into a
> 32-bit protected mode operating system then it won't be DOS.
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.
>
> >>>12] Make W95 run from OpenDOS
> >>Almost certainly not possible, I'm afraid; MS-DOS 7 was majorly bent
> >Doesn't W95 let you keep an older version of DOS if you wish? Then why
> >couldn't we make it work like this?
>
> 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).
> >>>22] FSSTND
> >>It's too late.
> >Why? Is there any good reason software can't be written FIRST for OD,
> >_then_ ported to other OS's? IMHO, This'll help it more than anything.
>
> 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.
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.
Thanks for your comments, they have generated a lot of good
discussion.
Tim Bird
- Raw text -