De fleste computere i dag skib med en 64-bit version af Windows, og ofte en minimal mængde RAM. Dette bringer spørgsmålstegn, hvor godt disse systemer udføre. Dette gælder især, når brugerne ønsker at køre deres arv 32-bit software på disse nye computere.
Hvilke rejser et interessant spørgsmål. Har du brug for mere eller mindre RAM til at køre en 32-bit program på en 64-bit version af Windows? I denne uge, Bruce Epper finder ud
En læser spørger:.
Er det rigtigt, at køre 32-bit programmer på en 64-bit Windows-system forbruger 1,5 gange mere hukommelse Vi har tidligere diskuteret fordele og ulemper ved at holde alt 64 bit over hele linjen og nogle af virkningerne af "blande og matche". I dag skal vi undersøge, hvordan 32-bit programmer udfører på 64-bit versioner af Windows. En 64-bit Windows-operativsystem kan ikke køre en 32-bit Windows-program uden nogle yderligere hjælp. De er bare alt for forskellig: fra pointere og datatyper, til hvordan systemkald (hvordan programmer bruger ressourcerne i underliggende operativsystem). Du har brug for en måde at gøre dem forenelige. Windows bruger WOW64 (Windows32 på Windows64) delsystem for at kompensere for forskellene. Det fungerer effektivt som en 32-bit Windows mini-emulator på x64-systemer og et fuldgyldigt emulator på Itanium (ia64) systemer. ia64 systemer kræver en fuld emulator på grund af forskelle i processor instruktioner og hukommelse side størrelser (4K i x86 og x64, 8K i IA64). Da x64 processorer har alle anvisninger x86-processorer og bruger den samme hukommelse side størrelse, betyder det ikke har behov for en fuld emulator. I begge tilfælde WOW64 giver en grænseflade mellem 64-bit Windows-kernen og 32-bit-versionen af ntdll.dll (dette indeholder en liste over de centrale Windows kerne funktioner), opsnappe kernel opkald og ændre dem, så de kan behandles af de indfødte 64-bit funktioner, som Windows-kernen. Der er 3 DLL filer der bruges på x64 /ia64-systemer for at opnå dette: wow64cpu.dll, wow64win.dll, og wow64.dll. Deres funktioner er at abstrahere processoren egenskaber og give thunks ( vi vil komme til dem senere en thunk er et underprogram (tænk på disse som en række instruktioner, der udfører en enkelt opgave), der tillader et program til at udføre en fælles subrutine eller funktion i systemet. i dette tilfælde er det udtrækker argumenterne fra 32-bit program opfordring stak, konverterer dem til deres tilsvarende 64-bit, og gør 64-bit system opkald. Når den vender tilbage fra opkaldet, vil det konvertere 64-bit resultater tilbage til 32-bits og skubbe dem tilbage på programmets kaldstakkens for den, der ringer for at bruge. Alle thunking sker i brugerniveau (som har begrænsede tilladelser) af to grunde. For det første minimerer effekten af fejl i koden, som kan resultere i et sikkerhedshul, data korruption, eller et systemnedbrud, hvis kører i kernel-mode. For det andet, det reducerer effekten ydeevne, det ville have, hvis kører i kernel mode (tilstanden bruges af de væsentlige dele af operativsystemet) på grund af den involverede, når der skiftes mellem bruger mode og kernel mode og tilbage overhead. Går tilbage til Itanium-systemer, der er nogle andre vigtige forskelle at bemærke. IA64 systemer bruger to yderligere filer. IA32exec.bin er x86 software emulator og Wowia32x.dll giver grænsefladen mellem WOW64 og softwaren emulator. En 32-bit proces vil indlæse disse filer samt 64-bit versionen af ntdll.dll. Disse er de eneste 64-bit binære filer, der kan indlæses i en 32-bit proces forud for Windows 7. Windows 7 og senere også har en anden DLL, apisetschema.dll, som vil blive indlæst i alle processer. Når en 32-bit proces er startet, vil den indlæse Wow64.dll som igen loader 32-bit versionen af Ntdll.dll og eventuelle nødvendige 32-bit DLL'er fra % SystemRoot% \\ SysWOW64 Ser man på listen over DLL indlæst vi kan se, der er 9 DLL'er lagt i processen under Win64, som ikke er der for Win32 systemet. nu kan du blive fristet til at se på de filstørrelser, tilføje dem op og bruge det som dit grundlag for, hvor meget ekstra hukommelse der bruges, men du ville ende med unøjagtige resultater. Disse filer, ifølge deres natur, er designet til at blive delt komponenter og som et resultat, at den første fil kræver en DLL belastninger den i hukommelsen. Efterfølgende programmer, der kræver den samme DLL ikke indlæse hele komponent i hukommelse. De får en pointer til den allerede belastede komponent, og tildele RAM til de yderligere elementer, der er indlæst i processen. For at se, hvad der foregår, jeg har oprettet to virtuelle maskiner, der kører Windows 7 Ultimate med 2 GB RAM er afsat til hver. En af dem er 32-bit version og den anden er 64-bit. Begge gik igennem nøjagtig samme installation og lappe proces. Efter at begge systemer blev lappet, jeg deaktiveret swap-fil på både at få et bedre billede af hukommelsesforbrug ved at sikre RAM kunne ikke tilkaldte ud på disken. Når det var fuldstændig LibreOffice 5.0.3.2 blev installeret. En kopi af Sysinternals Process Explorer blev også placeret på begge maskiner. Dette er det værktøj, jeg brugte til at indsamle hukommelse information forbrug. Standard kolonne setup blev ændret, så jeg kunne se på Working Set og WS Privat forbrug. Disse arbejdsgrupper sæt tal afspejler mængden af RAM, der bruges af programmerne. Det det kompliceret lidt længere ved at reflektere den mængde hukommelse, der bruges af delte biblioteker, selvom de allerede var belastet af en anden proces. På grund af dette, hvis du tilføjer hele kolonnen, er det muligt at ende op med en total større end installerede RAM Processerne vi behandler ikke stå alene enten. De forskellige LibreOffice programmer lancere en anden proces, soffice.exe, som vil udføre endnu en anden proces, soffice.bin. Vi skal se på de samlede beløb i alle tre processer for at se den effektive hukommelsesbrug af hvert program. For den oprindelige test, jeg simpelthen åbnet Writer, Calc, og Impress individuelt for at se på, hvor meget hukommelse de forbruger uden nogen data, der indlæses og eksporteret data fra Process Explorer. Med Calc og Impress, havde jeg åbnet en 3,7 MB .xls-fil og 3,9 MB .pptx fil henholdsvis og registreres den nye brug af hukommelse. Resultaterne kan ses i nedenstående tabel. Alle data er i KB. Den store overraskelse skete med Impress. Uden et dokument det var ved hjælp af 4,1% mere RAM på 64-bit-system og 9,9% mindre med dokumentet indlæst. Jeg gravet op et par andre præsentationer og havde lignende resultater med dem alle. Den 64-bit system endte med at bruge mindre RAM end 32-bit system. Så gør de 64-bit versioner af Windows kræver mere RAM end deres 32-bit modstykker, når du kører 32-bit apps? Generelt ja. Men har du brug for at opgradere din RAM? Sikkert ikke. Forskellen virkelig Vi hjalp denne læser. Vi kan hjælpe dig, også. Fik en brændende spørgsmål, eller en tech problem, du behøver løst? Bare klik på knappen ovenfor! Og, selvfølgelig, kan du efterlade feedback eller kommentarer i kommentarerne nedenfor!
i forhold til at køre 32-bit app under en 32-bit Windows-operativsystem
Bruces Svar:?
Forståelse WOW64
) ind Win32k.sys som giver det "vindue" funktionalitet og ntoskrnl.exe som indeholder den udøvende magt, kerne, hukommelse leder , proces scheduler (ikke at forveksle med den Opgavestyring tilgængelig fra Kontrolpanel), og andre centrale elementer i operativsystemet.
. De fleste af disse filer er identiske med de binære filer på en 32-bit system, selv om nogle er blevet omskrevet til at opføre sig anderledes under WOW64.
Vores Test Setup
. Arbejdsgruppen sæt er stadig den bedste sporvidde på præcis hvor meget hukommelse der er nødvendig for en proces.
er ikke så massiv. Det er bestemt ikke 1,5 gange anderledes.
Vi kan hjælpe dig også!
Stil dit spørgsmål!