Hi,

>>> 4 GB or even more in 64 bit are also interesting
>> The BIOS int 15.87 lets you access the first 4 GB, if you
>> want to access more than that, you have to do fancy stuff

> I think basically I would need to switch the CPU
> into long mode.

No you would not. See below.

> Is long mode supported by DOS?

No. You cannot run vm86 tasks and long mode at the same time,
so you would have to switch up and down the whole way between
modes. You would have to disable BIOS and DOS drivers and other
things running in the background during that time, and you can
not insert "IRQ windows" a la HIMEM / int 15.87 because those
long switches are really tedious. This is also why Linux does
not give you real vm86 when you use a 64 bit kernel. Instead,
it might give you a virtual vm86 or just no vm86 at all. Note
that you can easily do 64/80/128 bit *calc* in 16/32 bit OS!



HOWEVER, you can use far more "classic" methods like PAE, see
http://en.wikipedia.org/wiki/Physical_Address_Extension which
is available even in Pentium Pro / II / III CPUs already :-).

Microsoft asks lots of $$$ for Windows versions which allow
you to use more than 4 GB there, but other 32 bit OSes like
Linux, FreeBSD or MacOS are less greedy about that... ;-).

PAE lets you use up to 64 GB of actual RAM in almost normal
32 bit mode. This means that you can still run DOS while a
HIMEMXXL or JEMMXXL are running. However, you will run into
the compatibility limitations I described: No locking of XMS
handles above 4 GB (...you might need a command line tool to
enable/disable usage of RAM above 4 GB before you load apps
or drivers which need locking) and no VCPI. The latter means
either no JEMMXXL or no DOS extenders while you use that :-p

As for HIMEMXXL, that only needs XXL PAE superpowers while it
accesses high RAM, which it might be able to do in a way that
is compatible to DOS extenders if you can keep tasks separate.
Or you just say "you can only touch handles outside 4 GB space
while no DOS extenders nor EMM386s are running", again letting
the user decide manually which apps/drivers get XXL-made XMS.



You can also make new apps and DOS extenders which can coexist
with any of the XXL modified drivers, of course. And you can
make apps which have superpowers built-in, replacing the need
to add incompatibility-causing superpower mods to HIMEM/EMM.

Such apps can even co-exist with classic HIMEM/EMM386 at almost
no cost - they just have to let VCPI have its own classic task
(32 bit without PAE) and give HIMEM the usual int 15.87 service
and give DOS the usual vm86 task if they want to use DOS :-)).



> There is no DOS extender for this?

Nope. And if there was, which apps would use it and for what?

> Well, to access more then 4 GB there would be need
> for an updated DOS extender.

Unless you consider "4 GB per handle" enough, in which
case modified EMS or XMS drivers might be possible in
certain cases... - if you find a way to hide the whole
modern mess from VCPI, which has to stay in 4 GB space.

Looking from the other side, a DOS extender which does
all the big addr space stuff itself would probably be
incompatible by design with any DOS things or even any
EMM or XMS driver which tries to run in the background.

You would end up in a situation similar to running the
DOS loader of MEMTEST: You can get there, but there is
nothing left of DOS while it is running. And you would
only be able to return to the prompt after careful exit.

That said, some old games do similar stuff - their crude
"DOS extenders" take over the CPU after all necessary DOS
calls are done, then you play the game and all DOS stops
working, but starts to work again when you exit the game.



> I don't know why you are talking about the memory manager stuff?
> The goal was simply to store the whole RAM into a file.

That is a very special goal which you could also achieve
with one of the existing 64 bit operating systems. I was
just pondering other more general uses of "> 4 GB in DOS".

> At no point I was talking about using 4 GB in legacy
> applications and/or legacy application compatibility.

The incompatibility might be so big that you cannot do
anything "normal" at all while using > 4 GB of RAM ;-)

What you probably CAN do is write a very special app
which copies chunks of, say, 16 MB into the first 4 GB
and switches back the whole way to reach DOS again to
store those into a file, then repeats for the next 16.



>> I am almost sure Heise HAS a disk clone tool for DOS, though!

> There are some but dd as command line tool is nicer in some cases.

Then either you fail to read the docs of the disk clone
tools or you found a serious limitation in those tools.

Eric

PS: In case you have even more than 64 GB of RAM, please
let me know whether I can help you to spend your $$$ ;-)




------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to