Details Windows voor AMD64 duiken op

The Inquirer heeft een document opgeduikeld dat bedoeld lijkt te zijn om ontwikkelaars in de praktijk kennis te laten maken met de AMD64-versie van Windows XP, codenaam Anvil. Het bespreekt niet alleen de voordelen van de ondersteuning van maximaal 16TB RAM, maar leert de programmeur aan de hand van aantal oefeningen ook hoe het 64-bits OS omgaat met een mix van legacy en pure 64-bits applicaties. Standaard gebeurt alles natuurlijk in 64-bit mode, maar de namen van diverse bekende systeembestanden en mappen (user32.exe, kernel32.dll, windows\system32) zijn verwarrend genoeg niet veranderd naar xxx64, om de compatibiliteit maximaal te houden. Naast de normale "Program Files" en "system32" mappen bevinden zich straks ook "Program Files (x86)" en "SysWoW64", waar alle 32-bits applicaties en systeem-dll's in thuishoren.

WoW staat in dit geval voor Windows-on-Windows, een soort virtuele machine die buiten de kernel draait en het mogelijk maakt om de processor - die als de computer aangezet wordt in x86-mode draait, maar bij het booten van 64-bits Windows onmiddelijk naar AMD64-mode wordt gezet - tijdelijk terug te schakelen naar x86-mode en zodoende het draaien van oude software mogelijk te maken. Het opstarten van WoW64 gebeurt automatisch als de gebruiker een x86-programma wil inladen, en dan worden meteen de nodige 32-bit dll's uit de SysWoW64-directory naar het geheugen gezet.

Deze 32-bits bestanden zijn voor het grootste deel exact dezelfde als die in de normale 32-bits uitvoering van Windows te vinden zijn, maar sommigen zijn iets aangepast zodat ze in de gaten hebben dat ze in een WoW-omgeving werken en niet direct bij de kernel kunnen komen. De 64-bits kernel kan namelijk niet direct benaderd worden door een normaal x86-programma, want WoW64 onderschept alle calls naar ntoskrnl.exe en win32k.sys, om ze vervolgens naar eigen inzicht te herstructureren en door te sturen. Volgens Microsoft is het performanceverlies dat hierdoor veroorzaakt wordt minimaal, en biedt het voordelen voor de beveiliging en stabiliteit. Ook het register is niet direct toegankelijk voor 32-bits applicaties, hoewel ze daar zelf niets van merken, krijgen ze door WoW64 een andere versie ervan gepresenteerd. De 32-bits-delen van het register zijn overigens wel toegankelijk voor 64-bits software.

Geheel naadloos is de integratie tussen x86-32 en x86-64 dus niet, maar de eindgebruiker zal er in de praktijk weinig van merken. Uitzonderingen zijn echter altijd wel mogelijk, want binnen één proces kunnen nu eenmaal geen 64-bits en 32-bits componenten uitgewisseld worden. Ga je bijvoorbeeld met de 64-bits Internet Explorer het net op, en kom je daar een 32-bits ActiveX-control tegen, dan zal de browser eerst de 32-bits versie van zichzelf moeten opstarten voor de pagina volledig getoond kan worden. Wanneer ontwikkelaars niet goed nadenken over zulk soort problemen kan de gebruiker daar last van hebben.

Verder gaat het document in op het compileren en debuggen van AMD64-software met behulp van Visual Studio .NET. Hoewel allang duidelijk was dat Microsoft ondersteuning voor de Hammer-chips in Windows zou gaan stoppen, zal het bedrijf AMD dus ook aan de ontwikkelkant ondersteunen. Of de ontwikkelomgeving tegelijk met de release van de nieuwe versie geüpdate wordt is niet bekend.

Reacties (54)

[The Jester]

Standaard gebeurt alles natuurlijk in 64-bit mode, maar de namen van diverse bekende systeembestanden en mappen (user32.exe, kernel32.dll, windows\system32) zijn verwarrend genoeg niet veranderd naar xxx64, om de compatibiliteit maximaal te houden.

Op momenten als deze vraag je je af waarom Windows geen symlinks kent.... (Of eigelijk: Shadows. Tenslotte is de 32-bits kernel een OS/2 derivaat).

Ik snap werkelijk niet waarom ze anno nu nog steeds met die brakke shortcuts werken. Dat ze het niet met een servicepack fixen is nog tot daar aan toe, maar met een nieuwe OS-versie, grijp je zo'n kans toch met beide handen aan

Maar goed: het is fijn om te weten dat het x86-64 platform eindelijk serieuze ondersteuning uit Redmond krijgt. Toch een eerste vereiste voor AMD om een successverhaal te kunnen schrijven.

* 786562 The

[Anoniem: 86857]

Maar goed: het is fijn om te weten dat het x86-64 platform eindelijk serieuze ondersteuning uit Redmond krijgt. Toch een eerste vereiste voor AMD om een successverhaal te kunnen schrijven.

Dat vraag ik me af. Voor zover ik heb begrepen is de servermarkt de voornaamste doelgroep van de AMD64, dit vanwege de grotere addresspace. Windows incl. apps heeft voorlopig aan 4Gb genoeg (bovendien is de 4Gb grens niet eens de echte grens, maar goed.) Behalve het feit dat een double float nu ineens kan worden gerekend zie ik voor thuis het voordeel van 64-bit voorlopig ff niet.

MS heeft overigens nog een ander probleempje: als straks 64-bit is ingeburgerd, maar de Intel64 ondersteunt geen 32-bits apps meer... dan zouden gebruikers kunnen overwegen om een ander OS te gaan proberen. Of MS moet op 1 of andere manier ook 32-bit apps gaan draaien onder hun "Windows for Intel64". Gelukkig is Bill Gates goed in simulaties.

Of zie ik ff iets over het hoofd hier

[yeep]

Je ziet inderdaad iets over het hoofd. Naast de server markt zit ook een groot deel van de mensen die in de grafische vormgeving werkt te springen om meer dan 4 GB geheugen. Ik kan me op /. het verhaal herinneren van een CAD tekenaar bij Boeing. Een gemiddeld Jumbo jet ontwerp kost meer dan 4 GB om in te laden in het CAD programma. Daarbij heeft Epic al aangekondigt dat de level editor voor de volgende versie van de Unreal/Unreal Tournament editor al 64-bits spullen gaat vereisen en met de versie daarna gaat waarschijnlijk het spel zelf ook een 64-bits processor veresien.

De manier om meer dan 4 GB op Windows te gebruiken die je noemt, is de AWE (Address Windowing Extensions. Alleen voor WinNT) en die doen constant pointer herberekeningen om je steeds een stuk (window) van 4 GB geheugen te geven binnen een veel groter geheugen bereik (4 TB max geloof ik). Ik hoef natuurlijk niet te zeggen dat dit ONTZETTEND traag is, omdat Windows dan eerst een deel van het geheugen naar de harde schijf moet pagen, dan een heel zooi pointers gaan berekenen en eerder gepaged geheugen weer van de harde schijf laden.

En dat 4 GB niet eens de echte grens is klopt. Windows NT/2000 pro/2000 server kan voor user programs maximaal 2 GB gebruiken. De rest is alleen voor het systeem. Op Win2k Adv. Server/Data center, WinXP en Win2003 kan maximaal 3 GB gebruikt worden voor programma's, maar daar moet het programma wel op zijn voorbereid.

Als de IA-64 geen IA-32 meer ondersteunt is dat niet echt een probleem. Of zijn mensen niet op de hoogte dat Microsoft Virtual PC heeft gekocht en daar Server programmatuur mee aan het ontwikkelen is?

[jappo]

The code for the program was left mostly up to Bill Gates while Paul Allen began working on a way to simulate the Altair with the schools PDP-10.

Volgens mij is vooral Paul Allen goed in simulaties. Maar je bent nooit te oud om te leren

[Anoniem: 50043]

Ze hadden minstens in WoW64 de bestandsnamen kunnen afvangen. Dan hadden ze ook de naamgeving kunnen aanpassen.

[rickiii]

Volgens mij is de stap van 16-bits naar 32-bits exact zo verlopen met een emulator voor oude programma's. Daar hebben gebruikers volgens mij ook weinig van gemerkt.

[dion_b]

Hangt ervan af hoever terug je gaat. De overstap van 8086/8->80286 is best rampzalig gelopen, vooral doordat de protected mode van de 286 buggy was, er geen MMU was en er niet teruggeschakeld kon worden. 286->386 was dan een enorm verschil, maar eigenlijk veel minder problematisch (vrijwel alles wat voor de 286 bedoeld was te werken werkte nu betrouwbaar, met die 32b en MMU erbij).

De gemiddelde tweaker herinnert zich deze overgangen niet, maar die waren zeer pijnlijk, althans voor software die de extra mogelijkheden probeerde te gebruiken. Het is kenmerkend dat de 16-32b overgang in CPU hardware al in 1987 gebeurde, en hoewel OS/2 binnen een jaar 32b ondersteunde, het tot 1991 duurde voordat MS een NT versie op 32b had draaien, pas in 1996 kwam NT4 als echt serieus x86 32b OS en pas in 2001 (14 jaar later!) is de thuisgebruikers OS van MS volledig 32b geworden.

Kortom, met zo'n aanlooptijd is het niet zo'n wonder dat eea soepel leek te gaan- deze keer zal de aanlooptijd vermoedelijk veel korter zijn (al verwacht ik de komende 3 jaar niet dat 64b op de desktop echt mainstream wordt)

[yeep]

Vroeger maakte het noet zo heel veel uit. Dankzij de protected mode extenders (DOS4GW is de bekenste gevolgt door CWSDPMI van Quake faam) had je 32-bits applicaties op 16-bits DOS. Alleen geen multi-tasking nee. Maar de mensen die dat echt nodig hadden werkte toch op Unix workstations.

[mr._Anderson]

Ik denk echter dat AMD er wel belang bij heeft dat Windows 64 bits doordrukt.. en MS aan de andere kant ook.. omdat het anders voor niets is.

Als amd grote leverancies als bijv. HP over de brug krijgt..en veel athlon64's zal gaan leveren.. zal automatisch daar windows 64 op gaan draaien.

Ook zal AMD erop in springen dat het de eerste 64bits cpu is... 2x zoveel.. dat ziet de noob tenminste..

ik bedoell.. hmm 32 bits.. 64 bits... dezelfde prijs.. dan moet die AMD wel 2x zo snel zijn

Ook MS zal zijn graantje mee proberen te pikken denk ik.

Ik denk dat na een periode van 2 a 3 jaar toch wel een flink deel over zal zijn op 64 bits versies van windows, dan wel niet linux.

[Wouter Tinus]

Klopt, als je een heel oud programma opstart in een moderne Windows-versie zie je in de task manager ook dat dit eigenlijk als subproces van wow32 (of iets dergelijks) draait. Het zal leuk zijn om te zien hoe 64-bit Windows omgaat met 16-bits applicaties, WoWoW? .

[yeep]

De 64-bits versie van Windows ondersteunt geen 16-bits applicaties meer. Dus geen WowWow :-)

[rb338]

Was dat niet precies andersom, met WinS32 ofzoiets? Daar kan ik me wat van herinneren... was een soort 32-bit "addon" voor Windows 3.1

Kan ook zijn dat ik er helemaal naast zit, heb al een tijdje geen Windows 3.1 meer gedraaid

edit:

Ohja, 32-bit Windows heeft natuurlijk idd voor 16-bit apps WoW32
Dat wat ik zei is weer een ander verhaal

[yeep]

Win32s was een 32-bits uitbreiding voor Windows 3.11
Was dus soort van forward-compatibility in plaats van backwards-compatibilty. Het was echter gewoon een ramp en is gelukkig snel vergeten.

[Anoniem: 19076]

volgens mij kan je 32-bits x86 ook in 16 bits mode draaien (virtual86 ofzo). ik zou dat geen emulatie willen noemen.

[nose]

16 bit = real mode (standaard opstart modus)
32 bit = protected mode (wordt ie door het OS heen gezet (of door DOS4GW vroeger) )

[Anoniem: 19076]

klopt. maar er is nog een tussenin mode, waar je naar toe kan schakelen, virtual86 mode genaamd.

[Contagion]

Virtual 86 mode is in het leven geroepen om 16bits apps die de eerste geheugenadressen (met segmeten en offsets) fysiek 'moeten' aanroepen de mogelijkheid te geven ook daadwerkelijk te draaien onder een echt multi-tasking OS. Een programma kan natuurlijk op een heel ander deel van het geheugen gemapped worden, dan in de DOS tijd waar je dat zelf kon uitmaken. V86 zorgt dat het eenvoudige programma DENKT dat ie ook daadwerkelijk direct in de geheugenadressen zit te poken . Je eerste verhaal klopt dus wel zo ongeveer.

[Wolfboy]

Wat je wel vergeet is dat er toen nog maar heel weinig n00b gebruikers waren.

Tegenwoordig heeft bijna iedereen een computer, toen was het voor 90% van de mensen gewoon een duur overbodig ding

[Anoniem: 41851]

Windows NT/2k/XP zijn compleet 32 bit, maar ze zijn via WOW toch in staat om ouwe 16 bit applicaties te draaien. Dit gaat redelijk stabiel, maar niet perfect. De WOW laag draait onafhankelijk van de kernel; als er iets fout gaat in 1 van de 16 bits programma, dan sluit Windows de hele WOW laag af. (En daarmee alle andere 16 bit programma's onder dat proces.) Er kunnen volgens mij meerdere WOW lagen naast elkaar worden opgestart, als dat wordt ingesteld, met in elke laag 1 of meerdere programma's. De ene laag heeft dan geen last van de andere(n).

Indien exact hetzelfde gaat gebeuren voor de komende 64 bit versie van windows (volledig 64 bits dus, met een WOW voor 32 bits en een andere WOW-laag voor 16 bits apps), dan gaat het wel redelijk werken denk ik, al zal de perfomance van Win32 applicaties op het 64 bit OS wellicht achteruitgaan tegenover die op een 32 bit OS, vanwege de extra laag. Tevens zullen veel mensen nog 32 bit applicaties gebruiken; het afsluiten van de hele WOW laag is dan niet de bedoeling als er meerdere applicaties in draaien. Dan helpt MS het hele protected mode weer om zeep. (Elke app in zijn eigen beschermde gebied -> app dood -> anderen hebben geen last.) Men moet dan óf een crashende applicatie apart kunnen afsluiten, of standaard voor elke applicatie een WOW laag gebruiken.

Als er echter een hybride 64/32 bit besturingssysteem komt in de trant van Win9x, dan zie ik weer grote stabiliteitsproblemen aankomen. Systemen die 64 en 32 bit code in 1 kernel tesamen integreren (zoals Win9x doet), zijn volgens mij altijd onstabieler als een syteem dat óf 32, óf 64 bits is.

[The Wizard]

Nee, er komt geen hybride systeem :

De 64-bits kernel kan namelijk niet direct benaderd worden door een normaal x86-programma

Waarschijnlijk krijgt hier elk programma ook wel zijn eigen protected ruimte om de rest van de 32 bit programmatuur niet mee onderuit te trekken, vooral in het begin is er natuurlijk nog erg veel 32 bit software, waarvan niet alles vlekkeloos werkt en dus crashed. Als ze deze windows versie willen gebruiken in het bedrijfsleven is het onmogelijk om zulke beveiligingen niet in te bakken.

Zeker thuisgebruikers zullen geen 16 TB nodig hebben (De komende jaren...)

[hardwareaddict]

Nu zo moeilijk is het niet om 'documenten' op te duikelen hoor. Het is al sinds 1 juni 2003 zo dat je online dat allemaal kunt vinden in MSDN.

Ga maar eens naar MSDN toe en tik wat dingen in als 64 bits en AMD64

bijvoorbeeld dit vind je als je alleen al AMD64 daar intikt:

http://search.microsoft.com/search/results.aspx?View=msdn&st=a&qu=AMD6 4&c=4&s=2

MVG

[RetepV]

maar de namen van diverse bekende systeembestanden en mappen (user32.exe, kernel32.dll, windows\system32) zijn verwarrend genoeg niet veranderd naar xxx64

ARG! Waarom doen ze het niet in één keer GOED? De namen van de systeembestanden kom je als programmeur nooit tegen, dat zit in libraries verstopt, en de namen van systeemmappen kun je opvragen met een paar API calls. Als een programma goed is opgezet, zou het gewoon hercompiled kunnen worden, gelinkt tegen de nieuwe .lib's en klaar.

Maar nee, Microsoft wil slecht programmeergedrag belonen door slechte programmeurs tegemoet te komen. En goede programmeurs worden hierdoor ook niet byzonder gemotiveerd om hun software netjes te programmeren (wat doorgaan meer tijd kost dan iets in elkaar hacken).

Dit is imo het allergrootste probleem van Microsoft, ze nemen amper verantwoordelijkheid voor hun eigen producten. Niet met betrekking tot nieuwontwikkelingen, niet met betrekking tot veiligheid en niet met betrekking tot het standaardiseren van API's om stabiliteit te krijgen.

Voor elke functie in Windows zijn minstens twee manieren om het te programmeren. Soms mogen bepaalde functies niet door elkaar gebruikt worden (C runtime functies in threads gebruiken is maar beperkt veilig), maar de documentatie is daar nooit 100% duidelijk over.

Hoe kan een programmeur op zo'n platform nou een goed en stabiel programma schrijven?

[catfish]

je slaat de bal totaal mis hoor, MS weet maar al te goed hoe het "wel" moet, maar er zijn bepaalde functies die je in windows kan opvragen op wel 4 manieren...
de reden? heel eenvoudig, als een "slecht" gemaakt programma (vele custom build bedrijfssoftware) vastloopt krijgt MS dikwijls de schuld, hoewel het probleem niet bij hen ligt,
wat voor een bedrijf dus een geldig excuus zou zijn om NIET te upgraden naar de nieuwe windows versie... als commercieel bedrijf zoals MS kan je zoiets dus niet veroorloven

[yeep]

ARG! Waarom doen ze het niet in één keer GOED? De namen van de systeembestanden kom je als programmeur nooit tegen, dat zit in libraries verstopt, en de namen van systeemmappen kun je opvragen met een paar API calls. Als een programma goed is opgezet, zou het gewoon hercompiled kunnen worden, gelinkt tegen de nieuwe .lib's en klaar.

Nee, die bestandsnamen zijn wel degelijk van belang. De enigste manier om de taalversie van Windows te bepalen is door de taalversie van het bestand User32.dll te bepalen. Veel programmeurs doen dit via de region API's, met als gevolg dat je niet de taal versie van je OS krijgt, maar de ingestelde regio taal. En dat is dus niet goed. Verder kan je soms bijvoorbeeld willen weten welke versie van de shell aanwezig is om bepaalde mogelijkheden te gebruiken van die shell. Dan moet je dus de versie hebben van Shell32.dll. Het is dus maar goed dat ze dit allemaal afvangen.

Voor elke functie in Windows zijn minstens twee manieren om het te programmeren. Soms mogen bepaalde functies niet door elkaar gebruikt worden (C runtime functies in threads gebruiken is maar beperkt veilig), maar de documentatie is daar nooit 100% duidelijk over.

Noem eens een voorbeeld dan. Dat van die C-runtime is duidelijk vermeld bij de CreateThread documentatie.

[YaPP]

hmm.. en waarom simuleren ze dan niet gewoon dat er een user32.dll is? je vraagt toch immers aan windows om een API uit user32.dll te halen. dat doet je app echt zelf niet.

korte termijn oplossingen vormen juist lange termijn problemen.

user64.dll zou ik toch liever zien. met deze houding krijg ik toch kriebels bij het idee dat verder in het OS toch ook dit soort "oplossingen" gebruikt zijn. Het kan zo echt een grote boel worden.

Onder UNIX is het bijvoorbeeld altijd zo geweest dat alles op 1 uniforme manier moest werken. dat er geen uitzonderingen zijn. Dat maakt het juist zo krachtig. Of ik nou 1 file van het netwerk, disk, de cd-rom of direct de sectors van mijn HD wil uitlezen, het kan allemaal met hetzelfde commando en subsysteem. (om maar een voorbeeld te noemen)

overgens, idd een goede reden voor symlinks.

[ErrieR]

Ik ben het met je eens. Softwarebedrijven zouden hun produkten moeten hercompileren, en tegen een kleine vergoeding moeten aanbieden aan mensen/bedrijven met een licentie.

Als je het belangrijk genoeg vindt, ga je echt wel upgraden (bv. Office, of Autocad).
En zo hou je Windows dan ook echt 64-bit. Die backwards compatibiliteit is alleen maar extra code, en extra code = extra "undocumented features" .

64 bit zet toch wel door, dus waarom nu moeilijk doen, als alle "belangrijke" software over niet al te lange tijd toch wel beschikbaar is als 64-bit versie?

[boner]

Ga je bijvoorbeeld met de 64-bits Internet Explorer het net op....

Je moet je natuurlijk wel afvragen welke apps er 32 bits kunnen blijven en welke niet.

IE is niet interessant genoeg om 64bits te zijn.

CAD programma's en dergelijke. Die zijn wel aan een volgende stap toe.of Excel, je weet maar nooit hoe groot de sheets zijn die sommige finciele 'experts' weten te produceren. En dan heb je nooit last van oude situaties die je kunt tegenkomen.

Als 64bit net zo is ingeburgerd als 32bits nu, zijn programma's als IE aan de beurt.

[Wouter Tinus]

Je moet je natuurlijk wel afvragen welke apps er 32 bits kunnen blijven en welke niet.

IE is niet interessant genoeg om 64bits te zijn.

Dat kun jij wel vinden, maar heel Windows met alle meegeleverde applicaties etc. wordt gewoon gecompileerd naar een berg AMD64-binaries, en dan is Internet Explorer standaard dus ook gewoon een 64-bits applicatie, die misschien nog geen gebruik maakt van 64-bits mogelijkheden, maar wel van de uitgebreide ISA (extra registers enzo), en die zal dus niet meer op een standaard x86-processor kunnen draaien. In die Windows-versie zal je ook 64-bits notepad en 64-bits Solitaire hebben zitten. Je wil gewoon zoveel mogelijk in native mode laten draaien, en aangezien het gewoon een kwestie is van opnieuw compileren gaan ze echt niet bij iedere applicatie apart de afweging maken of het nuttig is of niet.

Als 64bit net zo is ingeburgerd als 32bits nu, zijn programma's als IE aan de beurt.

Dit klopt dus niet, 64-bits IE zit er gewoon in, dat staat ook in het document.

[Exirion]

Je moet je natuurlijk wel afvragen welke apps er 32 bits kunnen blijven en welke niet.

IE is niet interessant genoeg om 64bits te zijn

Moet je niet te hard zeggen. Laten we nou niet weer een jarenlange overgangsfase tegemoet gaan zoals bij 32-bits. Het heeft ruim 10 jaar geduurd voordat 32-bits applicaties gemeengoed waren na de introductie van de 386. De ontwikkelingen gaan nu veel sneller maar als je er nu vanuit gaat dat veel apps prima 32 bits kunnen blijven dan krijg je toch weer hetzelfde gevaar.

Er worden extra dingen gedaan 32-bits software in de 64-bits omgeving te laten draaien. Dat gaat ten koste van performance maar kan in veel gevallen ook gepaard gaan met stabiliteitsproblemen. En zeker een applicatie die zo massaal gebruikt wordt als IE zou dan beter meteen native 64-bits kunnen zijn.

edit:
hmmm... te laat op de knop gedrukt dus Wouter was me min of meer voor

[Munters]

De meeste programma, zoals inderdaad IE, hebben geen baat bij 64 bits. Ze zullen het echter wel worden, al was het maar om de WoW-laag te omzeilen.

CAD programma's hebben er ook nog niet zoveel aan, die gebruiken toch FP, geen integers.

Excel heeft voorlopig ook nog niets aan 64-bits. Laten ze Excel eerst maar eens 32-bits maken! (Het aantal kolommen is in mijn versie tot 256 (8-bits!) en het aantal rijen tot 65536 (16-bits!) beperkt; wanneer met name het aantal rijen tot 2^32 uitgebreid is, ben ik al heel blij).

Programma's die echt wat aan 64-bits hebben zijn:
- Video-editing (bestanden > 4 GB)
- Databases

[Anoniem: 76218]

Mss een stomme vraag, maar met een 64-bit compiler krijg je toch volledig andere binaries.
Verandert de bestandextensie (.exe) van 64-bits bestanden dan? (of hoe gaat dat in z'n werk )

[Tomatoman]

De binaries zullen waarschijnlijk zo'n 50% groter worden (gokje) en in ieder geval binair wat anders in elkaar zitten: ze hebben bijvoorbeeld een andere byte alignment. Wat echter onveranderd blijft, zijn de eerste bytes van het bestand. Daarin worden alleen een paar flags (Engels woord) veranderd die aangeven dat het een 64-bits-programma betreft. 32-bits Windowssystemen herkennen die veranderde flags niet en zullen een melding geven dat het programma niet compitabel is en het eenvoudigweg niet verder starten.

Er was in het bestandsformaat van 32-bits executables (het zogeheten PE-formaat) al rekening mee gehouden dat programma's in de toekomst een andere structuur konden krijgen. Dat kan door een nieuwe waarde voor een bepaalde flag te introduceren. Een flag is in feite niets meer dan een getal dat een speciale betekenis heeft. Oude besturingssystemen herkennen een nieuwe flag uiteraard niet en zullen het programma daarom weigeren te starten.

De overgang van 16 bits naar 32 bits werkte wat anders. In het oude 16-bits MS-DOS-bestandsformaat (het MZ-formaat) was geen rekening gehouden met het feit dat Windows-programma's niet onder MS-DOS werken. Daarom werd een truc gebruikt. Iedere Windows executable(dus zelfs een nieuw 64-bits programma) begint als een mini MS-DOS programma. Als het onder MS-DOS gestart wordt, wordt dat miniprogramma gestart, dat meestal niet meer doet dan een boodschap op het scherm zetten, zoiets als "This program requires Microsoft Windows." Daarna is het programma klaar en wordt het afgesloten. Een aantal bytes achter het DOS-programma begint het eigenlijke Windows-programma. Windows-besturingssystemen gaan op die plek zoeken naar de informatie die duidt op een Windows-programma - dat is het PE-gedeelte van de executable. Zo ja, dan wordt dat gestart en wordt het voorafgaande MS-DOS-gedeelte genegeerd. Zo nee, dan is het blijkbaar geen Windows-programma en geeft het besturingssysteem een foutmelding.

Eigenlijk is het nog iets ingewikkelder dan ik het hier weergeef, want er bestaat ook nog zoiets als ME-executables's voor Windows. Ik hoop niettemin dat het principe een beetje duidelijk is .

[Anoniem: 68006]

Eigenlijk is het nog iets ingewikkelder dan ik het hier weergeef, want er bestaat ook nog zoiets als ME-executables's voor Windows. Ik hoop niettemin dat het principe een beetje duidelijk is .

is dit dan voor WinME ?

[nose]

Waarschijnlijk krijg je dan net zo'n soort melding als dat je een Windows-exe in DOS wilt opstarten. "Cannot run this program in DOS-mode" wordt dan bijvoorbeeld "Cannot run this 64-bit application in 32-bit mode" of "...in a 32-bit environment".

[Kevinp]

Ik verwacht zeker in het begin veel bugs, Niet omdat ze niet nagedacht hebben, maar zoiets is gewoon erg lastig. Misschien door de moeilijkheid, denken ze beter na en zitten er geen/bijna geen bugs in.

[procyon]

Elke omgang is moeilijk, laten we vertrouwen hebben in microsoft.

AMD64-versie van Windows XP, codenaam Anvil

Best gevat als je je bedenkt dat de codenaam voor de opteron "Hammer" is.

[NiGeLaToR]

En ik denk dat je nogal wat geheugen nodig zal hebben als je wat 64bits en 32bits app's door elkaar draait. Niet erg, maar wel rekening mee te houden.

AMD en MS gaan de ijzerhandel in samen laten we hopen dat het geen schroothoop wordt

[arjankoole]

En ik denk dat je nogal wat geheugen nodig zal hebben als je wat 64bits en 32bits app's door elkaar draait. Niet erg, maar wel rekening mee te houden

als het goed is zou het weinig uit moeten maken. Natuurlijk moet je rekening houden met een extra memory footprint door WoW.... Of 64bit applicaties ook meer geheugen trekken dan hun 32bit broertjes weet ik niet, maar als een applicatie in 32bits 2MB is, dan zal ie op een 64bits systeems hoop ik toch niet opeens 4MB zijn.

[Fairy]

Ik begrijp het niet helemaal. Kun je me vertellen wat dan de vertaling in het nederlands is voor het woord Anvil

[Concrete]

Aambeeld? Als in smid, smeden aambeeld.

[Jack]

Anvil lijkt verdomt veel op Evil

[m-m]

een aanbeeld, zo'n ding dat tekenfilmfiguren altijd op hun kop krijgen

[cryforhelp]

\o/ aan degene die die codenaam bedacht heeft
Heel mooi dat ze windows voor de hammer, anvil (aambeeld) noemen

[tweakerbee]

Zie je wel, nerds hebben wel gevoel voor humor

[boner]

lijkt ook op advil.

[IndoBoy]

Als Microsoft zelf al voor de Hammerchips een speciale windows versie gaat maken, betekend dit dat MS veel vertrouwen heeft in deze chip.
Ik denk dus dat we veel kunnen verwachten van de Hammer generatie. Immers, MS kenende die zal niet gaan investeren in iets wat kans heeft om te gaan floppen.