Hi sparky, (PS: Please decide on which of the 3 lists this should be discussed)
> 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? 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. However, the BIOS probably also has 64 bit reporting today. You could make a version of EMM386 or HIMEM or both which let you access more than 4 GB, but they would still limit you to 4 GB per allocated handle in XMS far call function ah=0x0b, offset/size are 32 bit and you can only lock XMS to places in the first 4 GB (function ah=0x0c). For EMS (int 0x67 functions 0x40 and up, but similar things also hold e.g. for QEMM specific extensions) you can get up to 1 GB per handle (64k pages of 16kB each, less in 4kB EMS 4.0 pages :-p) and you can only talk about mappings within the usual 4 GB address space again. With VCPI (int 0x67 function 0xde and subfunctions) you also manipulate 4kB pages, also in the first 4 GB of address space... DPMI (see int 0x31, ax 0 to 0x0e01) also lets you manipulate mapping only in the first 4 GB of linear and physical address space and generally does not do talking about larger sizes of RAM at all, as far as I can tell. 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. 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. 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. > 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. 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. 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). Note that you are often limited to 2 GB or 4 GB per file and 2 TB per drive letter, even if you would add support to GPT / EFI / UEFI partition tables in addition to old MBR partition tables which have a limit of 2 TB per real harddisk. Support for newer partition tables can be in the kernel, but a driver for config sys is also possible and maybe in some cases preferable. Of course you would have to boot from some MBR partition, within the first 2 TB, if only a driver and not the kernel supports GPT. > If i reported this before please ignore it i cannot remember ^^; > also I think i should make a utility to convert FreeDOS 1.0 Packages to > version 1.1! I already have alot on my programming plate! Sounds useful :-) > and i have announcement! > http://www.viste-family.net/mateusz/software/fdnpkg/ > FDNPKG v0.93a Has a bug fix in it please upgrade to latest version! You already said that and Mateusz already fixed it, thanks :-) 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. Regards, Eric ------------------------------------------------------------------------------ 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-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
