"Quelles sont les limites de mémoire pour les applications 32 bits sur un Windows 64 bits ?"
Vous pouvez avoir accès à toute la mémoire du système depuis votre application. Même si c'est beaucoup plus que 4 gigz.
Le problème n'est pas que vous ne pouvez pas avoir plus de mémoire, mais que vous ne pouvez pas toutes les mapper dans l'espace d'adressage virtuel de l'application. Les choses se compliquent un peu : vous devrez utiliser des pilotes de mémoire, et mapper dynamiquement les régions de mémoire avec lesquelles vous travaillez et démapper les régions qui ne sont pas réellement nécessaires pour libérer de l'espace d'adressage. Cela n'équivaut pas à libérer et allouer la mémoire : elle conservera son contenu et sera disponible pour votre application même lorsqu'elle est désaffectée. Le mappage et le démappage sont des opérations relativement peu coûteuses, seules les tables de traduction d'adresses doivent être mises à jour.
C'était une pratique courante pour les logiciels de base de données qui devaient gérer plus de 4 gigz sur de vieilles machines 32 bits. C'était également crucial pour les pilotes matériels qui devaient gérer de gros tampons DMA, comme plusieurs centaines de mégaoctets. L'espace mémoire total du noyau est de 1 ou 2 gigaoctets sur différentes versions de Windows 32 bits, et il peut être fortement fragmenté. Je peux vous dire ce qui se passe si vous essayez d'allouer 500 mégaoctets avec AllocateContiguousMemorySpecifyCache() sous XP 32 bits : le système se bloque pendant une demi-heure, essayant frénétiquement de réorganiser l'espace d'adressage du noyau pour répondre à votre demande, et cela échoue généralement même si vous avez 4 gigz dans la machine. Nous avions l'habitude d'allouer le tampon DMA dans des listes de descripteurs de mémoire (MDL), et de mapper dynamiquement seulement les régions que nous voulions lire ou écrire de/vers. Cela fonctionnait comme un charme, à la vitesse de l'éclair. Je pouvais obtenir presque toute la mémoire système (environ 3 gigz) même si l'espace d'adressage total du noyau n'était que de 1 gig !
Gérer plus de 4 gigz n'est absolument pas un problème pour Windows 32 bits. Les versions domestiques étaient limitées, mais faites une recherche pour les versions serveur. Je ne me souviens plus de la limite théorique de la MMU à deux niveaux dans tous les processeurs x86 après le 386, je crois que c'est 2 téraoctets ! Jusqu'à cette limite, le support logiciel est relativement simple.
La vie est plus facile avec un espace d'adressage linéaire de 64 bits, mais pas parce que vous pouvez avoir plus de mémoire. Vous ne pouvez pas vraiment, c'est juste plus facile à faire. Mais cela se faisait couramment bien avant l'avènement des systèmes 64 bits aussi.
Je dirais, le plus grand avantage est que la fragmentation de l'espace d'adressage virtuel n'est plus un problème. Lorsque les ordinateurs avaient des mégaoctets de mémoire, la fragmentation de la mémoire physique pouvait être évitée en mappant la petite mémoire physique dans un espace d'adressage virtuel beaucoup plus grand. Quelle que soit la fragmentation de la mémoire physique, l'espace d'adressage virtuel de 32 bits pouvait être lissé. En fait, il ne s'agissait pas d'une véritable solution, mais d'un simple coup de pied dans la fourmilière. Lorsque nous avons commencé à avoir des gigaoctets de mémoire physique, le problème de la fragmentation est revenu. Il est évident que le fait d'avoir un espace d'adressage qui était initialement des centaines ou des milliers de fois plus grand que la mémoire physique n'était pas suffisant. Avec la transition 32 bits -> 64 bits, nous disposons désormais d'un espace d'adressage 4 milliards de fois plus grand ! Cela "devrait suffire à tout le monde" - au moins pendant quelques années.