On May 2, 2012 12:10 PM, "Eric Auer" <e.a...@jpberlin.de> wrote:
>
>
> Hi Martin,
>
> > The main aim behind the idea is to make a DOS system that is comparable
> > to Linux, Windows or any other of the 100+ OS's out their while still
> > using the DOS Kernel at the core, which if my idea is viable would allow
> > DOS to be 16, 32 & 64-bit compaitable, seems like a crazy idea huh...!
>
> Well that idea is probably based on the misunderstanding that
> Linux is bloated and complicated while DOS is fast, small and
> simple.
Linux doesn't have to be complicated, but developers throw too many heavy
dependencies and overcomplicate it with a brittle and arcane build system,
IMO.
> HOWEVER, when you create a system that can run "all"
> Linux programs, it also will be big and complex, even if you
> use DOS as core component.
Networking, GUI, USB, multitasking, multithreading, Unicode, etc. is a lot
to support (not counting AMD64).
> On the other hand, if you only want to run, say, Midnight
> Commander (or NC or similar) you can do that in either DOS
> or in a very minimalistic version of Linux, maybe even a
> Linux that would fit on one or very few floppy disks :-)
The kernel alone won't fit (anymore) on a floppy, and floppies are almost
completely commercially dead anyways. Windows Vista (2007) already required
a DVD drive (also semi-obsolete) unlike Win95 (mine was like 18
overformatted 1.68 DMF floppies).
> Of course a Firefox would be dozens of disks big if you
> made a DOS version, or you would need a Linux that takes,
> say, 10 floppies to install plus a Firefox of 10 further
> floppies in size. The Firefox itself for Linux is smaller,
> but needs to be run on a less minimalistic Linux to work.
Forget Firefox entirely, I know we miss Flash and Javascript, but honestly
we're VERY lucky to have Dillo, that was no small miracle in itself. :-)
> In short, before you start re-inventing DOS and/or Linux,
> you should have a close look at the possibilities with a
> NORMAL DOS or a NORMAL Linux.
It would make more sense (to me) to compile a working DOSEMU for ttylinux
(48 MB), for example. Though alternatively, others (e.g. late genius Pat
Villani) already had ideas of moving to a 32-bit kernel built via GCC using
FreeBSD driver framework. That wouldn't be too bad either. (And remember
that DOSEMU runs atop 64-bit Linux too. And VirtualBox with VT-X works too.
Even QEMU has long had slow software emulation of 64-bit guest atop 32-bit
host).
> Maybe Rugxulo can folloup
> my mail by suggesting some small Linux versions.
Not really, it's impossible to do much without very heavy hacking and
compiling from scratch (LFS, anyone?). Too much to support, not enough
consensus among users, esp. given the dozens of x86 variations (and total
RAM between users often varies).
> To stick
> with the internet example, you can have a look at, for
> example: mtcp, ssh2dos, lynx, Arachne and Dillo, which
> are a few of the possibilities to use the internet with
> any normal DOS, sorted by complexity.
A bigger problem is lacking packet drivers. Maybe Mike B. can suggest a
cheap USB card that works well on modern machines.
> > -A secondary 32/64-bit capable kernel that *doesn't* replace the
current
> > FDOS kernel but expands upon the existing kernel by writing new 32-bit
> > and 64-bit binaries/ code.
Unlike DJGPP or DOSEMU or FreeDOS-32?
Anyways, there are already some wimpy "jump to 64-bit" examples for DOS
(see FASM or JWasm), but I'm not sure how easily (if at all) you use the
BIOS, which kinda cripples the idea.
I've mentioned before that latest VT-X is probably our only hope for a
64-bit extender, though I could be wrong (and am not qualified to write it
myself).
> The design of the FDOS64 kernel is take care
> > of converting between 64-bit to 16-bit. This kernel would take care of
> > the processing load and any other applications that require higher
memory
> > address space (I.e. GUI's, graphics card Drivers, any current software
> > would run through this kernel, while DOS command would run through the
> > the FDOS kernel.)
>
> DOS extenders, running in a normal DOS kernel, already access up
> to 4 GB of RAM.
In theory, though that ignores page tables, page size variations, VCPI or
DPMI 1.0 compliance, bugs, or libc (2 GB) limitations. DJGPP: use sbrk()
and CWSDPMI r7 or HDPMI32. OpenWatcom: use experimental PAE DOS/32A.
> There is no graphics card driver in DOS, because
> apps usually include their own drivers for that, same for sound.
Forget entirely about that unless / until someone writes an Allegro wrapper
for SDL and / or updates the DJGPP build of Mesa (software only). Even
then, I'm not sure. Oh, I guess building the SDL libs with OpenWatcom would
work well with HX. I hope.
> > - Direct access to the FDOS64 kernel could be obtained by expanding a
new
> > category within DOS Command (e.g. adding 64 to the start of each command
> > or something like that)
>
> It would probably be more user friendly to only have a 64 bit DOS
> extender running in a classic DOS. Performance will be minimally
> worse. For comparison, FD32 is a bit faster for certain things in
> comparison to normal FreeDOS, but the difference is quite small
> and there are not as many fans of FD32 as there are for FreeDOS.
FD32 doesn't fully support DPMI nor DJGPP stuff. But otherwise is a nice
proof of concept (and allegedly builds with DJGPP, though I dunno if it
needs classic FD kernel to bootup or not).
64-bit is completely unnecessary unless someone ports Java or other such
bloatware (unlikely). ;-) Alleged speedups are minimal and irrelevant,
IMO.
> > HAL, Win32/ 64 API & Windows Drivers:
> > - Most of the HAL compatiblity already exists within FreeDOS, and what
> > doesn't could be ported from ReactOS.
>
> Then it would be more straightforward to use ReactOS itself :-)
> Also, HXRT (similar to a DOS extender) lets you run (not overly
> complex) Windows software in a classic DOS :-)
Sounds difficult, and ReactOS isn't exactly stable anyways. Though of
course if they were to give first class status to the DOS subsystem (doubt
it), it would be foolish not to work together with them (or anyone else ...
Haiku??).
There are already several frameworks for re-using drivers across OSes, so
that's feasible and a good idea (in theory).
> DOS does not have any real HAL (hardware abstraction layer).
> This is one of the STRENGTHS of DOS: You can have all hardware
> for yourself without a complex OS interfering. But you also do
> not have much comfort. If you want a HAL, use ReactOS or Linux.
I thought HAL was deprecated and dead? Or you just mean "abstraction layer"
in general?
> > I have rough simple kernel layout sketched, alot of the other things
are
> > preference, such as running with a Windows based GUI like ReactOS or
> > using a compatiblity layer like Cygwin and Cygwin/x and use the
X-Windows
> > System.
Such as WINE now using DosBox when atop AMD64?
I don't think we're going to get much help or sympathy from all these (Win
/ Lin) groups, sadly. Ideas are great, but when nobody wants to help, what
can you do? Free / libre doesn't negate the fact that people only support
themselves and aren't interested in helping the little guy, only big dogs.
:-(
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
