Hi, On Wed, Feb 20, 2013 at 5:07 PM, Eric Auer <e.a...@jpberlin.de> wrote: > >> FreeDOS's mem program output only 4 GB of detected memory out of the >> machine's total 16 GB .... Dose this mean FreeDOS can only detect 4GB >> maximum?
For the record, I would take whatever MEM says with a healthy dose of skepticism. It's not totally accurate in some cases, even for under 4 GB. It's slightly buggy. > This is NOT related to the kernel: MEM only reports what EMS, > XMS, UMB and HMA drivers and maybe BIOS tell and all those are > 32 bit, simply speaking. Same for VCPI and DPMI. Typically you're not going to get anything much unless you use XMSv3 or DPMI. Japheth has MEMSTAT.EXE, EMSSTAT.EXE, and XMSSTAT.EXE in JEMM386 (JEMM575B.ZIP). DJGPP (DJDEV*.ZIP) has GO32-V2.EXE to report total DPMI available (though it's sometimes wrong too; obscure bugs, memory holes, or lying OS [XP]). XMSv3 (e.g. XMGR) "should" get you approx. 2 GB of RAM. DPMI should get you somewhere around that amount too, but it depends on your DPMI host (e.g. CWSDPMI r7 or HDPMI32). Actually, this 4 GB laptop only reports like 2.6 GB free, I think. I can't remember honestly. (r7 was intended to use all 4 GB, even with memory holes, but it too has some minor bugs that CWS never fixed, though he did do some work over the recent Christmas holidays). The X32 extender (Digital Mars, link still broken, dang it!! Email me for a .ZIP of it.) claimed to use up to 3 GB (untested). Not totally sure about others (Causeway, DOS/32A). In other words, you'll be lucky to use 2 GB, in most cases. > So what are your options? With a super-powered HIMEM or EMM386 > you can give multiple handles memory to reach more than 4 GB > in total, but regarding protected mode software which has to > use VCPI or DPMI, size of the directly reachable heap still is > limited to 4 GB. Normally, people prefer protected mode exactly > to avoid having to mess with EMS or XMS handles so to break the > 32 bit barrier, your software will have to juggle with memory > handles again as if it was 16 bit software before VCPI and DPMI > days. Also, in case you have not guessed yet, there ARE NONE > of the mentioned super drivers available so far. PAE might work, but IIRC, nobody has really tried that with DOS (yet) except for a very very rough (buggy??) DOS/32A hack. CWS showed some interest, but he never implemented it yet (and is busy with new job). > The next option would be running your software directly in the > 64 bit protected mode of modern CPU. You will not get any help > from DOS for that and it is more ado than the already complex > EMM386 architecture had to keep DOS and 64 bit software alive > and useful at the same time... Of course you could also switch > to 64 bit mode and accept that you cannot use DOS at all until > your program finishes, maybe even the hard way with a reboot. Yes, if all you wanted was raw number crunching gigabytes of data, I guess you could switch from DOS to 64-bit long mode, do the math, then switch back and report your results. Unlikely to be done, but hey, who knows what people want. > In theory, you could also define 64 bit variants of EMS, XMS, > VCPI or DPMI interfaces and then use those, making life a bit > easier if you want more people to write 64 bit DOS software. > On the other hand, people ran their stuff in 32 bit directly > for years until it became popular to use VCPI, DPMI or other > DOS extender related interfaces, so do not expect your 64 bit > proposals to turn into instant breaktroughs. If you just want 64-bit support *and* DOS support (but not necessarily in the same program, which would be hard, if not "almost" impossible), your best bet would be DOSEMU (x64) or VirtualBox with latest (Nehalem Westmere-ish) hardware cpu VT-X support enabled. >> Also The df program is outdated and reporting incorrect sizes... it only >> detects a maximum of 2 GB disk space of a hard drive. I may just have an >> outdated version... or it must be the latest DOS version... i need to >> check > > This is also NOT related to the kernel, unless you meant 2 TB. > > Please check. It is indeed a good idea to use FAT32- and disk- > size/space-above-2-GB aware versions of DF. If you really can > not find one (try ftp://ftp.delorie.com/pub/djgpp/current/ > DJGPP ports, maybe somewhere in one of the v2gnu packages?) > then we should make one. I think the one in "current" (FileUtils?) only reports 2 GB max, but the one in "beta" is better (and reports 4 GB for me, last I checked). So grab that one, and try again. Vaguely related: there was (is?) a bug in the FreePascal 2.6.0 installer in a similar vein. Apparently "sysutils" wasn't fully working like unit "dos" for DiskSize and DiskFree re: FAT32 (7303h). In other words, FAT32 calls aren't always fully supported by some old apps. > For example my free-disk-space-tester-freetest.zip tool > can, depending on command line options, report things as > "how many times 256 MB are free?" as errorlevel from 0 > to 255 which thus saturates at 64 GB... This uses int 0x21 > function 0x7303 "get extended free space" which only can > be used with FAT32-aware DOS versions such as FreeDOS or > the DOS of Win95 / Win98 but not with MS DOS 6.22 etc. http://ericauer.cosmodata.virtuaserver.com.br/soft/specials/free-disk-space-tester-freetest.zip > Note that even Win95 / Win98 will sometimes PRETEND that > at most 2 GB are free, maybe to not confuse DOS software > with so much space... :-p The get extended free space API > can report at most 2^32 sectors and 2^32 clusters and as > sectors are often 512 bytes in DOS, you get a limit of ca > 2 TB for disk size but (in theory) a LARGER limit for the > amount of free space (clusters are bigger than sectors). XP also lies about free space, perhaps due to API (register size) limitations. Though IIRC it doesn't support int 21h, 7303h, but just saying, even its old int 21h, 36h isn't totally accurate. > Note that you are often limited to 2 GB or 4 GB per file Maximum 2 GB per file for FreeDOS, even for FAT32. > I hope I impressed you a bit with those 4 GB / 2 TB limits and > the sketched possibilities to get even further, but as you can > see from the reaction of Ralf: 640 kB uhm 4 GB should be enough > for everybody, in particular in DOS, for now. Not sure if 4 GB is truly supported, esp. not by DJGPP's libc (without weird hacks like manually using sbrk). So 2 GB is probably "reasonable", though your mileage may vary (esp. re: CWS r7 and whatever update may eventually come [be patient!]). Also try HDPMI32, maybe it works better, dunno. But yes, seriously 2 TB should be enough for anybody (doing anything semi-reasonable!)! ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
