>>Your heap is divided into segments you can have maximum 64 segments <blabla>
That also is implementation dependent. I think that is how it works in ancient 16-bit MS-DOS but things have change just a tad since the 1980s. Memory is no longer segmented like that.

>>That also is implementation dependent. I think that is how it works in ancient 16-bit MS-DOS but things have change just a tad since the 1980s. Memory is no longer segmented like that.

I am not sure how it use to work in 16 bit DOS but I am sure this is how it works in Windows Vista !

Link please. No version of Windows since NT 4.0 have had segmented memory. The segment registers do not contain segments -- they contain descriptors.

>>you can have maximum 64 segments
Then why can I allocate as much memory as I want at one time up to the limit of size_t and size of RAM + hard drive? The 32-bit version of Windows can address up to 4 gig of physical RAM.

Seems I could not present myself correctly...
Heap and Virtual memory are different
see this for heaps
http://msdn2.microsoft.com/en-us/lib...11(VS.85).aspx
This http://msdn2.microsoft.com/en-us/library/aa366599.aspx cluearly states why allocations grater in size do not fails.
Heap manager manages heaps it is a part og Windows memory manager.

You can see "Windows Internals 4th Edition" or you can use Windbg to see the implimentational details of heaps in Windows.

Heap Manager
Many applications allocate smaller blocks than the 64-KB minimum allocation granularity possible using page granularity functions such as VirtualAlloc. Allocating such a large area for relatively small allocations is not optimal from the memory usage and performance standpoint. To address this need, Windows provides a component called the heap manager, which manages allocations inside larger memory areas reserved using the page granularity memory allocation functions. The allocation granularity in the heap manager is relatively small: 8 bytes on 32-bit systems and 16 bytes on 64-bit systems. The heap manager has been designed to optimize memory usage and performance in the case of these smaller allocations.
The heap manager exists in two places: Ntdll.dll and Ntoskrnl.exe. The subsystem APIs (such as the Windows heap APIs) call the functions in Ntdll, and various executive components and device drivers call the functions in Ntoskrnl. Its native interfaces (prefixed with Rtl) are available only for use in internal Windows components or kernel mode device drivers. The documented Windows API interface to the heap (prefixed with Heap) are thin functions that call the native functions in Ntdll.dll. In addition, legacy APIs (prefixed with either Local or Global) are provided to support older Windows applications. The most common Windows heap functions are:
• HeapCreate or HeapDestroy—Creates or deletes, respectively, a heap. The initial reserved and committed size can be specified at creation.
• HeapAlloc—Allocates a heap block.
• HeapFree—Frees a block previously allocated with HeapAlloc.
• HeapReAlloc—Changes the size of an existing allocation (grows or shrinks an existing block).
• HeapLock or HeapUnlock—Controls mutual exclusion to the heap operations.
• HeapWalk—Enumerates the entries and regions in a heap.
Types of Heaps
Each process has at least one heap: the default process heap. The default heap is created at process startup and is never deleted during the process's lifetime. It defaults to 1 MB in size, but it can be bigger by specifying a starting size in the image file by using the /HEAP linker flag. This size is just the initial reserve, however—it will expand automatically as needed. (You can also specify the initial committed size in the image file.)
The default heap can be explicitly used by a program or implicitly used by some Windows internal functions. An application can query the default process heap by making a call to the Windows function GetProcessHeap. Processes can also create additional private heaps with the HeapCreate function. When a process no longer needs a private heap, it can recover the virtual address space by calling HeapDestroy. An array with all heaps is maintained in each process, and a thread can query them with the Windows function GetProcessHeaps.
A heap can manage allocations either in large memory regions reserved from the memory manager via VirtualAlloc or from memory mapped file objects mapped in the process address space. The latter approach is rarely used in practice, but it's suitable for scenarios where the content of the blocks need to be shared between two processes or between a kernel mode and a user mode component. If a heap is built on top of a memory mapped file region, certain constraints apply with respect to the component that can call heap functions. First, the internal heap structures use pointers, and therefore do not allow relocation to different addresses. Second, the synchronization across multiple processes or between a kernel component and a user process is not supported by the heap functions. Also, in the case of a shared heap between user and kernel mode, the user mode mapping should be read-only to prevent user mode code from corrupting the heap internal structures, which would result in a system crash.

PAE does not have to do anything with Heaps.

Only in that the heap can not access memory beyond the 4 gig boundry.

>>Only in that the heap can not access memory beyond the 4 gig boundry.

In fact heap can never access memory beyond 4 GB in 32 bit Windows Operating System.

I am sorry for not making myself clear. Virtual memory and heap are different. Heap is a part of virtual memory with low allocation granuality. It is all different set of APIs are given to access it, cretate it and distroy it.
PAE inclreases limit of Virtual Memory, it dont effect heaps directly.