Hey Rugxulo,
> 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.
> Don't get me wrong lol. I am running both Linux, BSD and FreeDOS currently,
> and FreeDOS is amazingly fast in comparision to Linux. >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.
> Sounds Interesting, but wouldn't that mean that DOS would essentially not be
> DOS lol, it would DOSBSD???? :P
> > -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. No the intention was different to DOSEMU but
> > similar to FreeDOS-32. DOSEMU is an emulator ontop of a host system,
> > practically the DOS version of virtualbox and the like. The x-windows
> > system was only a small part of the idea. DJGPP just does what essentially
> > the idea of what cygwin on DOS would have done. The secondary kernel
> > design was more about enabling SMP and expanding memory access to run more
> > intense applications (bloatware lol) like firefox. Not to re-design the
> > whole system. Whether SMP or greater RAM can be achieved through a DOS
> > extender i don't know, or even if SMP is already implemented? I was of the
> > assumption and knowledge that greater than 4GB of RAM access requires a
> > 64-bit kernel or PAE to address that higher RAM. Martin
------------------------------------------------------------------------------
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
