"Quali sono i limiti di memoria per le applicazioni a 32 bit su un Windows a 64 bit?"
È possibile ottenere l'accesso all'intera memoria di sistema dalla vostra applicazione. Anche se è molto più di 4 gigz.
Il problema non è che non puoi avere più memoria, ma che non puoi mapparla tutta nello spazio virtuale dell'applicazione. Le cose si complicano un po': dovrete usare i driver di memoria, e mappare dinamicamente le regioni di memoria con cui state lavorando e dismappare le regioni che non sono effettivamente necessarie per liberare dello spazio di indirizzamento. Questo non equivale a liberare e allocare la memoria: essa manterrà il suo contenuto e sarà disponibile per la vostra applicazione anche quando non è mappata. Mappare e dismappare è un'operazione relativamente economica, solo le tabelle di traduzione degli indirizzi devono essere aggiornate.
Questa era una pratica comune per il software di database che doveva gestire più di 4 giga su vecchie macchine a 32 bit. Era anche cruciale per i driver hardware che dovevano gestire grandi buffer DMA, come diverse centinaia di megabyte. Lo spazio di memoria totale del kernel è di 1 o 2 gigz su diverse versioni di Windows a 32 bit, e potrebbe essere pesantemente frammentato. Vi dico cosa succede se provate ad allocare 500 megabyte con AllocateContiguousMemorySpecifyCache() sotto XP a 32 bit: il sistema si blocca per mezz'ora, tentando freneticamente di riorganizzare lo spazio degli indirizzi del kernel per servire la vostra richiesta, e di solito fallisce anche se avete 4 gigz nella macchina. Eravamo soliti allocare il buffer DMA in liste di descrittori di memoria (MDL), e mappare dinamicamente solo le regioni da cui volevamo leggere o scrivere. Funzionava come un fascino, veloce come un fulmine. Potevo ottenere quasi tutta la memoria di sistema (circa 3 gigz) anche se lo spazio totale degli indirizzi del kernel era solo 1 gig!
Gestire più di 4 gigz non è assolutamente un problema per Windows a 32 bit. Le versioni home erano limitate, ma fate una ricerca per le versioni server. Non ricordo il limite teorico per la MMU a due livelli in tutti i processori x86 dopo il 386, credo sia 2 terabyte! Fino a questo limite, il supporto software è relativamente semplice.
La vita è più facile con uno spazio di indirizzi lineare a 64 bit, ma non perché si può avere più memoria. Non si può davvero, è solo più facile da fare. Ma è stato fatto abitualmente anche prima dell'avvento dei sistemi a 64 bit.
Direi che il più grande vantaggio è che la frammentazione dello spazio virtuale degli indirizzi non è più un problema. Quando i computer avevano megabyte di memoria, la frammentazione della memoria fisica poteva essere evitata mappando la piccola memoria fisica in uno spazio di indirizzi virtuale molto più grande. Indipendentemente da quanto fosse frammentata la memoria fisica, lo spazio di indirizzo virtuale a 32 bit poteva essere smussato. In realtà questa non era una vera soluzione, abbiamo solo dato un calcio al barattolo lungo la strada. Quando abbiamo iniziato ad avere gigabyte di memoria fisica, il problema della frammentazione è tornato. Ovviamente, avere uno spazio di indirizzi che inizialmente era centinaia o migliaia di volte più grande della memoria fisica, non era sufficiente. Con la transizione 32 bit -> 64 bit ora abbiamo uno spazio di indirizzi che è 4 miliardi di volte più grande! Questo "dovrebbe essere sufficiente per chiunque" - almeno per alcuni anni.