(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
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
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!
> 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.
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Freedos-kernel mailing list