Eric Auer schrieb: > 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!
True, them removed V86 from 64 bit. I always wanted to know this, couldn't find it on google. Is it possible to switch from long mode back to let's say real mode? > > > > 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 :-). I wouldn't rely on PAE, it's outdated, long mode has more future... > 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? The ram dumper! Or maybe a ram tester? Future applications? :D Do you want to to make the next joke a bit like "64GB ought to be enough for anybody."? :D Don't we have more phantasm? Otherwise poor performance. :p >> 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. > Don't you think it's theoretically possible to modify an existing DOS extender to - save the state - switch to long mode - do something - return to state - do something in v86 - loop while staying compatible with all that stuff? Or is this extender stuff limited to v86? I was reading a lot about this topic more then once. For example DOS_extender in wikipedia. It says it switches all time from v86 OR realmode (means not limited to v86) to protected mode and back. Why a switch to long mode shouldn't work? > > >> 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". Well, for a forensic tool (a ram dumper) a full blown 64 bit os is like "operating success, patient dead". Not much sense. I hoped to use DOS for this purpose as it uses only ~1 MB for most things. >> 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. Mostly graphical tools and on their homepages I don't find the term "raw image" or something similar, mostly proprietary formats. > > 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 $$$ ;-) > Alright, I will invite you to the party. -mr ------------------------------------------------------------------------------ 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
