Memory Allocation

JoeTheProgrammer · Post by **JoeTheProgrammer** » Sat May 10, 2008 3:04 pm

Do you have to get the total RAM size in order to initialize the memory manager? I think I am lost...but if I have the right idea, how do you get the total RAM size of the platform?

Please help,
Joseph

Solar · Post by **Solar** » Sat May 10, 2008 4:52 pm

How Do I Determine The Amount Of RAM.

JoeTheProgrammer · Post by **JoeTheProgrammer** » Sat May 10, 2008 5:14 pm

Solar wrote:How Do I Determine The Amount Of RAM.

Thanks, as I did not see this in the wiki.

Alboin · Post by **Alboin** » Sat May 10, 2008 6:01 pm

JoeTheProgrammer wrote:
Solar wrote:How Do I Determine The Amount Of RAM.
Thanks, as I did not see this in the wiki.

I can see that. Mediawiki's search engine sucks.

bewing · Post by **bewing** » Sat May 10, 2008 7:40 pm

That article is next on my list to rewrite (probably within the next month). The rewrite process should make it easier to find, too.

CmpXchg · Post by **CmpXchg** » Sun May 11, 2008 1:25 am

I noticed that an old DOS driver called HIMEM.SYS is capable of determining the amount of RAM on any machine, so it must contain a reliable algorythm.

JamesM · Post by **JamesM** » Mon May 12, 2008 1:26 am

CmpXchg wrote:I noticed that an old DOS driver called HIMEM.SYS is capable of determining the amount of RAM on any machine, so it must contain a reliable algorythm.

DOS is realmode, isn't it? So wouldn't that driver just pull the memory map from the BIOS?

CmpXchg · Post by **CmpXchg** » Mon May 12, 2008 7:01 am

JamesM wrote:DOS is realmode, isn't it? So wouldn't that driver just pull the memory map from the BIOS?

Yeah, it probably would. But what if the required BIOS functions are not supported? Do you think it never attempts to probe RAM directly?

JamesM · Post by **JamesM** » Mon May 12, 2008 8:17 am

CmpXchg wrote:
JamesM wrote:DOS is realmode, isn't it? So wouldn't that driver just pull the memory map from the BIOS?
Yeah, it probably would. But what if the required BIOS functions are not supported? Do you think it never attempts to probe RAM directly?

I have no idea. I was merely postulating - hence the inquisitive tone and question marks

CmpXchg · Post by **CmpXchg** » Mon May 12, 2008 11:31 am

OK

Here can we only guess...

bewing · Post by **bewing** » Mon May 12, 2008 11:50 am

CmpXchg wrote: I noticed that an old DOS driver called HIMEM.SYS is capable of determining the amount of RAM on any machine, so it must contain a reliable algorithm.

JamesM wrote: DOS is realmode, isn't it? So wouldn't that driver just pull the memory map from the BIOS?

Uh, no. HIMEM.SYS is the Extended Memory driver. I'm not sure exactly what mode the later versions of DOS actually did run in -- but with the "Huge Memory Model" and HIMEM.SYS, they were capable of addressing somewhere between 64MB and 4GB with "far pointers". (Yes, the "near" pointers were only 16 bit.)

DOS, however, is completely built on using BIOS functions to do all the hard work. I really doubt it uses manual probing at any point. I suspect that HIMEM.SYS exclusively used INT0x15 calls (up to E801, I'd bet).

CmpXchg · Post by **CmpXchg** » Mon May 12, 2008 12:30 pm

Thanks for your knowledgeable reply, bewing!

But what do you mean by "Huge Memory Model"?

As far as I know (or guess

), DOS itself utilizes real mode, but as soon as HIMEM.SYS loads, it switches the system into Protected mode, enables A20 and becomes kind of supervisor. As the result, the entire DOS session runs in V86, but it goes unnoticed for the most programs.

This fact turned my attention when I tried to read CR0 under DOS - the PE bit was set(!), which can only mean that the system ran under V86.

EDIT: sorry, I was mistaken. HIMEM.SYS doesn't switch the machine into protected mode, it merely enables A20 to allow the DOS kernel to be moved into HMA (that memory area of 65520 bytes starting at 0x10000h, the highest region process can access in real mode). But what really enters Protected Mode (and then starts a V86 task) is the memory manager EMM386.

I quite agree that HIMEM uses only BIOS functions to get memory size.

bewing · Post by **bewing** » Mon May 12, 2008 1:56 pm

Compilers under DOS could use one of four possible "memory models". The choice affected the way that segment registers were handled in the assembled output.

1) Compact. The only choice for .COM programs. All code and data is contained in one 64K page, so all the segment registers are set to exactly the same values at load time, and never changed. Uses 16bit pointers.

2) Tiny. Code is on a separate page from data, but code < 64K and data < 64K. Again, the segment registers are never modified. Uses 16bit pointers.

3) Standard. Can access all low mem (640K), using segment:offset pointers for every memory access.

4) Huge. Uses 32bit flat memory pointers for all memory accesses.

I still use M$ QuickC to make .COM files whenever I need a quickie utility to do some little thing, and run it in a DOS window.

jal · Post by **jal** » Tue May 13, 2008 4:14 am

bewing wrote:3) Standard. Can access all low mem (640K), using segment:offset pointers for every memory access.

Not really. It usually uses one data segment of 64KB, with a heap allowing you to allocate more memory. To access structures on the heap, one uses pointers and pointer dereferencing, but 'normal' global variables are stored in the data segment, which is still limited to 64KB. As for code, it depends on the language and compiler used.

4) Huge. Uses 32bit flat memory pointers for all memory accesses.

Only available with a DOS extender, I presume? Or using unreal mode?

JAL

pcmattman · Post by **pcmattman** » Tue May 13, 2008 4:36 am

Or,

Just use GRUB and tell it to give you memory information