>> On 14-Aug-2009 13:13, MegaBrutal wrote:
>> Who ever needs a 64-bit version of DOS, especially if you need
>> to emulate an entire processor while achieving it? 32-bit is
>> just fine. I don't know why would anyone switch to 64-bit for
>> DOS since people don't even use the advantages out. Of course
>> experimenting with 64-bit is still cool! ;)
>
> a Ramdrive that can be larger than 4GB or access beyond 4GB would
> be nice, requiring some 64bit challenges I think. I have 6GB in
> this machine at the moment.
I agree with "MegaBrutal", but at an even lower level: I think a
16-bit DOS can still be useful, since we never REALLY made use of
16-bit CPUs before Intel/AMD decided to "sell" us all 32/64-bits!
Re: using memory over 4-GB in DOS, the best way to AVOID many new
"custom" programs is to raise the capacity of XMS drivers such as
Japheth's HIMEMX/JEMMEX and my XMGR/UIDE (UIDE uses its own logic
in "real mode" XMS moves, for speed). This might require only 3
changes:
1) A change to the XMS request which determines available memory,
with a change to the FreeDOS "MEM" program to display all such
memory. I believe "MEM" is currently limited at 4-GB.
2) A new "Allocate SUPER-extended memory" request, which requests
memory above 4-GB if available. This new request would have
to return the "page" number (0 to 15) of the allocated memory,
for programs like UIDE that do their own "real mode" XMS work.
It would still return an XMS "handle" so the "Free XMS memory"
and standard "Move XMS memory" commands could work as-before.
3) A new "Move SUPER-extended memory" request, or a change to the
current "Int 15h AH=87h" move-memory request that denotes what
"page" of memory is being moved, for all "protected mode" move
requests (JEMM386/JEMMEX). There are no "extra" bits in the
current "Int 15h AH=87h" descriptor block, so some sort of new
"convention" would also be needed for large-scale XMS memory.
Item (3) is critical, since "protected mode" requires that JEMMEX
or JEMM386 must "trap" what looks like the old BIOS "move memory"
request (Int 15h AH=87h), then execute such moves itself. "Real
mode" moves can be handled by HIMEMX/XMGR/UIDE, using a "limited"
switch into "protected mode" like they all do now. But a "true"
protected-mode move is more complex and must be done thru JEMM386
or JEMMEX.
I am assuming here that, to keep things "simple" and still-useful
for programs that cannot or will-not be upgraded, the XMS drivers
will all "behave" same-as-before for current XMS commands. User
programs would still request up to 4-GB of memory, from the first
4-GB of a "large" system, and would still use normal XMS requests
via "handles" for their memory as-before. Only the XMS handlers
and upgraded "large scale" XMS programs like UIDE/RDISK need know
about and support the new commands above. This AVOIDS a lot of
"compatibility" issues.
But, a much-LARGER "issue" here is "Do we really NEED all this?"!
There are NOT many systems with over 4-GB, and I expect few would
ever need over 4-GB of memory for DOS use, if in fact their FIRST
4-GB is properly managed! Re: my own drivers, as I say in their
README file, a proper "split" of XMS memory between RDISK for all
"fast" files, UIDE for "ordinary" disk files, and saving some XMS
for other programs should yield a SCREAMING-fast DOS system!
It has been noted at many business schools that "80% of sales are
usually handled by only 20% of a company's inventory" -- the same
is likely true of today's "Gawd-AWFUL sized" computer files! If
the really NEEDED files load into a 2-GB RAMdisk, and either UIDE
or your-choice among other good caching programs is also run, DOS
should be "PLENTY Fast!" for most users.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
