Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 215 reacties

Microsoft denkt dat het moment nabij is waarop er meer 64bit- dan 32bit-besturingssystemen geïnstalleerd worden. Dit zou betekenen dat de 64bit-versie van Windows 7 de meest gebruikte versie van dat besturingssysteem wordt.

De omslag in het gebruik van 64bits Windows-versies is vooral het gevolg van de lage hardwareprijzen, denkt Jon DeVaan, vice-president van de Windows Core Operating System-divisie van Microsoft. "We denken dat het keerpunt bereikt is en dat komt grotendeels doordat geheugenprijzen aan het zakken zijn. Hier in de VS speelt ook een rol dat retailers ram-upgrades gebruiken om hun marges te verhogen." Een van de voordelen van een 64bit-besturingssysteem is dat er meer dan 4GB ram gebruikt kan worden. In de praktijk gebruikt de 32bit-versie van Windows Vista bijvoorbeeld maximaal 3,12GB, ook al is er 4GB of meer in de machine aanwezig.

Hoewel 64bits software in opmars is, lijkt de opmerking van DeVaan wat voorbarig. Volgens van DailyTech was eind 2008 een kwart van alle Vista-installaties in de VS van het 64bit-type. De verwachting is bovendien dat Windows 7 het laatste besturingssysteem van Microsoft wordt met native 32bit-ondersteuning. De opvolger zal wel overweg kunnen met 32bit-software, maar dan via een omweg. Windows Server 2008 R2 is al volledig overgestapt op 64bit. Het grootste obstakel is nog de ontwikkeling van 64bit-drivers: dergelijke drivers zijn voor lang niet alle hardware beschikbaar.

Moderatie-faq Wijzig weergave

Reacties (215)

Zolang de ondersteuning van 64-bit nog niet goed is, zodat er optimaal van de beschikbare 64-bits gebruik kan worden gemaakt, zie ik dit zo'n vaart nog niet lopen. Misschien wordt er wel een 64-bits besturing op de computer geïnstalleerd, maar je hebt daar niets aan omdat er zo weinig tools zijn.
Wanneer Windows-7 standaard als 64-bits wordt meegeleverd, en je voor een minderprijs ('t is nu eenmaal vaak goedkoper) de 32-bits versie kan krijgen en er nog weinig programma's zijn die optimaal van de mogelijkheden gebruik maken, zou ik toch kiezen voor een 32-bits versie.
Ik heb gieteren de BETA 7000 build x64 geïnstalleerd op mijn klapjapanner en moet zeggen dat ik nog problemen heb gezien.
x64 gaat naar mijn mening ook de standaard worden. Steeds meer mensen zullen overgaan van x86 32-bits naar x64.
het gaat standaard worden, maar de vraag is alleen wanneer en hoe snel. Er zijn nog te weinig programma's die optimaal gebruik maken van de mogelijkheden die een 64-bits aansturing biedt. Dat zal eerst moeten veranderen, de ondersteuning zou breder moeten worden voor we echt overgaan naar 64-bits.

[Reactie gewijzigd door jbdeiman op 22 januari 2009 12:00]

Programma's hoeven niet per se native 64-bit te draaien om profijt te hebben. Een 32-bit programma kan onder een 64-bit Windows 4GB geheugen gebruiken in plaats van maximaal 2GB bij een 32-bit Windows. Daarnaast gebruiken Windows Vista en 7 het extra geheugen in je machine als cache om applicaties sneller op het scherm te toveren. Voor een beetje workstation is een paar GB smeerolie wel zo fijn, naast een paar GB aan applicaties en virtuele (test)machines. Dat red je met een 32-bit OS gewoonweg niet.
Ik heb zeker vijf nieuwe computers met Windows Vista voor mensen samengesteld het afgelopen jaar, allemaal 4GB of meer geheugen en allemaal 64-bit. Bij een iemand heb ik zelfs de 64-bit business geïnstalleerd die eerder 32-bit had samen met een geheugenupgrade van 2GB naar 4GB. Niemand heeft problemen gehad dat hardware niet wilde werken. Al die mensen kunnen afhankelijk van het moederbord nog een keer upgraden naar 8GB of 16GB geheugen zonder Windows opnieuw te moeten installeren.
Ontbrekende 64-bit drivers of 16-bit software kunnen een overgang naar 64-bit belemmeren, maar het eerste kom je bij nieuwe hardware niet meer tegen en het tweede kan met emulatie of virtualisatie worden opgelost. Al met al zie ik 2009 wel als het jaar dat 64-bit Windows het meest verkocht zou moeten gaan worden.

[Reactie gewijzigd door Bas van der Doorn op 22 januari 2009 12:15]

Een 32-bit programma kan onder een 64-bit Windows 4GB geheugen gebruiken in plaats van maximaal 2GB bij een 32-bit Windows.
Nee, dit is absoluut niet waar!
Een 32bit programma onder 64bit windows zit ook gewoon aan de 2GB limit. (het denkt dat het gewoon in 32bit windows draait)

Alleen als het is gecompileerd met de /LARGEADDRESSAWARE optie, dan kan het 4GB gebruiken. In een 32bit OS kan het dan 3GB gebruiken met de /3GB optie.
Helaas ben ik nog nooit een desktop applicatie tegen gekomen die dat ondersteunt.
Een wel heel bekende dan: Photoshop.

En daar is het belangrijk om zoveel mogelijk geheugen te kunnen adresseren. Van Photoshop (CS4) is er nu eindelijk ook een 64 bit versie die meer dan 4GB kan adresseren. Op mijn systeem (Windows7 met 12GB) geeft Photoshop aan ruim 10GB beschikbaar te hebben voor de applicatie.

In het verleden had in een XP systeem met 4GB en de /3GB switch. Daar had Photoshop ruim 2.6GB geheugen ter beschikking.
Helaas ben ik nog nooit een desktop applicatie tegen gekomen die dat ondersteunt.
Omdat deze dit meestal niet nodig hebben. Ik denk wel dat er een aantal recente (32bit) games dit wel hebben gedaan.
Klopt - SupCom met patch, Forged Alliance sowieso.
Alleen moet je er dan ook nog even bij vermelden dat 64 Bit dus ook veel meer geheugen nodig heeft (verbruikt) en dat 4 GB dus eigenlijk ook wel meteen als minimum voor een goed bruikbaar 64 Bit OS gesteld mag worden.
4x zoveel geheugen als dat aanbevolen wordt is wel erg veel he? Standaard voor mailen en internetten is 1 GB voldoende: link
Los van de Vista requirements vind ik het wel grappig om te zien dat mensen, zonder te knipperen met hun ogen, kunnen schrijven:
"voor mail en internetten is 1GB voldoende".
Ik mailde en internette al op een Amiga met 2Mb geheugen... (oh ja en 8Mhz)... M'n mail is er niet beter van geworden nu ik 4Gb in mijn machine heb....
Ik doelde puur op de eisen van Vista. Die zijn ruimschoots voldoende om dit te doen, maw je hebt niet meer nodig ;)
Zolang u maar één progamma tegelijkertijd gebruikt misschien wel, toch zult u met zo weinig geheugen veel beter af zijn met 32 bits XP.
Inderdaad alles kan, lekker swappen met de HD is ook mogelijk onder Vista, alleen werkt u dan wel op de snelheid van een verouderde PC.

'Vista heeft eigenlijk 4GB geheugen nodig'

[Reactie gewijzigd door fevenhuis op 22 januari 2009 13:47]

In dat bericht heeft een IBM figuur het over 512 MB eisen, terwijl MS 1 GB opgeeft. Wereld van verschil. Bovendien zei ik al dat dit requirements zijn en dat dit voldoende is om 'kantoor'werk mee te doen. Natuurlijk is dit bij lange na niet genoeg om Crysis te spelen, maar zoals je op die verpakkingen leest, is ook daarop een minimum eis, die vele malen hoger ligt. :+
Nou ik denk dat MS Office op Vista 64 draaien met 512 Mb of 1 Gb geheugen wel zeer oneconomisch antiproduktief is.
Dat is niet zo hoor. Het is niet zo dat alles nu ineens 2 of 4 keer zoveel geheugen gebruikt. Het is niet dat alles ineens in 64-bits wordt opgeslagen. Een 32-bits long blijft een 32-bits long, ook op een 64-bits OS.
Een 64 Bits OS gebruikt gewoon 64 Bit hoor en geen 32 Bit, er wordt dus standaard wel degelijk meer geheugen gebruikt.
Waar the f*ck heb je het over? Als ik in C++ 32 bit alloceer (bijvoorbeeld voor een 32bit int, dan krijg ik 32 bit terug. Of de registers (en andere logica) in de CPU nu 32 of 64 bits groot zijn maakt mij niet uit en maakt voor geheugengebruik niet uit, al waren de registers 1024 bits.

De enige voor wie 64bit uitmaakt is voor de CPU bakkers, maar aangezien die al jaren 64bits CPUs maken denk ik niet dat ze er problemen mee zullen hebben.

[Reactie gewijzigd door Snoitkever op 22 januari 2009 14:24]

Windows Vista 64 Bit gebruikt meer geheugen dan de 32 bit variant, erg ingewikkelde materie is dit niet. Neemt u gerust nóg een kopje koffiie...

[Reactie gewijzigd door fevenhuis op 22 januari 2009 15:44]

Misschien moet je je eens verdiepen in wat C en desnoods assembly en hoe variabelen worden opgeslagen in het geheugen en registers. Dan snap je wat 32-bits en 64-bits betekent.
Hoogstens zullen de geheugenpointers 64bit lang zijn ipv 32bit, maar of je dat verschil zal merken...

Misschien wel als je veel gebruik maakt van pointers in een programma.

[Reactie gewijzigd door IveGotARuddyGun op 22 januari 2009 15:06]

mmwha, xp64 gebruikt anders minder dan 600 mb, met browser en alles open, dus idd, met 1 gb heb je al meer dan genoeg..
4+ gb is handig als je meerdere taken of applicaties wil draaien die geheugen vreten (VM's, bijvoorbeeld, of iets met video bewerking)
kip-ei verhaal.

Als je het bericht goed leest zie je dus dat er enkele mensen (die er daadwerkelijk veel verstand van hebben) nu de markt dusdanig inschatten dat wanneer je hardware hebt wat 64bits ondersteund (bijna alle recente hardware dus) er geen reden meer is om een 32bits (verouderd) besturings systeem te installeren. Daarmee zeggend; de ondersteuning is dus voldoende gefundeerd dat je je daar geen zorgen meer om hoeft te maken.
Ik denk niet dat dat veel gaat maken hoor. Misschien voor de tweaker zelf zijn systeempje ineen zet, maar niet voor de grote OEM's.

Maakt een hardwareproducent geen goede 64 bit drivers, dan kopen ze gewoon hardware in bij een andere producent die wel degelijke 64 bit drivers maakt. Die andere producent zal dan wel héél snel aanpassen en wel goede 64bit drivers maken gewoon om nog zijn verkoop kwijt te kunnen.

Ik zou sowieso voor een 64 bit systeem gaan. Je kan meer geheugen adresseren (en sowieso ga je met een systeem dat pas volgend jaar uitkomt naar de 4, 6 of 8 gig) waardoor je bij een eventuele upgrade geen nieuwe licentie meer moet kopen. Hardware is niet echt een probleem, kijk gewoon voor je ze aanschaft wat rond of ze op 64 bit werkt en anders koop je gewoon andere hardware.

Moederborden genoeg met perfecte 64 bit drivers, videokaarten hebben ook al een hele eind goede 64 bit drivers en de rest heb je geen drivers voor nodig of heb je zodanig veel merken die het produceren dat er wel eentje tussen zit die degelijke drivers ontwikkelt.
Het heeft niets met snelheidswinst of 'optimaal van 64bit gebruikmaken' te maken. De 64bit versie van Windows is in de meeste gevallen (zeker in 32bit applicaties) zelfs een paar procent langzamer, dus voor de performancewinst hoef je het niet te doen; nouja, tot je 4GB of meer geheugen wilt gebruiken natuurlijk.
Van die bewering zou ik graag even een bronnetje willen zien :)

Ik heb laatst mijn Windows Vista 32-bits vervangen door Windows Vista 64-bits (werkte op dezelfde legale serial trouwens tot mijn verbazing, maar dat terzijde) en ik heb het gevoel dat Vista veel en veel sneller is. Natuurlijk is een OS na installatie altijd sneller dan de 'clogged-up' versie die je daarvoor draaide en lijkt na een format altijd alles sneller, maar dan nog. Zo snel als Vista x64 nu is, zo snel is bij mij x86 nooit geweest.
Correctie de 32 Bit software mag dan wel langzamer zijn op een 64 Bit OS, de 64 Bit software draait dus wel degelijk weer sneller dan 32 Bit software op een 32 Bits OS, vooral complexe berekeningen zijn dus sneller, taken zoals compressie.
Bron? Voor zover ik weet heeft een 64 bits processor namelijk ook de 32 bits extensies (anders zou je 32 bit applicatie totaal niet werken, zonder emulatie). Zolang de processor de instructieset bevat, draaien 32 bits applicaties toch niet langzamer?
Er zijn meerdere factoren die spelen. Op zich heb je gelijk dat een 64 bits CPU de 32 bits code niet langzamer zal uitvoeren dan een 32 bits CPU. Sterker nog, de meeste 64 bits CPU's waren sneller, maar dit had natuurlijk vooral te maken met vooruitgang in chip design. Maar goed, in feite doet dit er niet toe, want we gebruiken nu al een tijdje 64 bits CPU's, ookal waren 64 bits OSen nog niet mainstream. Hell, the Athlon 64 bestaat al 5 en een half jaar.

Maar waar het hier om gaat is 32 bits applicaties onder een 32 bits OS versus 32 bits apps onder een 64 bits OS. Beiden draaien typisch op een 64 bits CPU dus daar zit het verschil niet in. Waar het verschil wel in zit is dat een 64 bits OS een 64 bits kernel heeft. Er zal dus een vertaalslag gemaakt moeten worden van de 32 bits address space naar een 64 bits address space. Dit wordt gedaan door de 'Windows on Windows' module. Het verschil in snelheid is echter marginaal.

En dan 32 bits apps versus 64 bits apps. Je kunt niet echt zeggen dat 64 bits apps standaard sneller zijn. Soms zijn ze zelfs langzamer, en het hangt dan ook een beetje af van z'n footprint. Een applicatie die vooral veel berekeningen doet en vrij weinig geheugen aanspreekt zal onder 64 bits typisch sneller zijn, omdat hij van meer registers gebruik kan maken om de resultaten in op te slaan. Bovendien zijn op een 64 bits CPU extensies zoals SSE2 gegarandeerd aanwezig, wat op een 32 bits CPU niet het geval is. Het nadeel van 64 bits is echter dat datastructuren groter worden. Met name pointers nemen nu ineens 8 bytes in ipv 4. Voor applicaties die vooral veel met geheugen doen heeft dit een nadelig effect. Om een typisch voorbeeld te geven, als ik mijn entry voor de 4e GPC voor 64 bits ging compileren was hij ongeveer 10% langzamer dan de 32 bits variant, omdat hij nogal memory-bound is.
En dan wil alleen nog zeggen dat 32 Bits compilen waarschijnlijk toch iets beter geoptimaliseerd zal zijn dan 64 Bit, want dat wordt al wat langer geoptimaliseerd.
Ik weet verder niet in hoeverre dat meespeelt want ik programmer zelf niet.

Oja mijn ervaring met is dat 64 Bit's ook sneller is met het bewerken grote aantallen bestanden. En ik ik heb hier een 64 Bit audioprogramma (Sonar) wat ook een stuk sneller werkt onder 64 Bit, dit ondanks het bepaalt geen licht pakket is (dus ik denk dat de stelling hoe minder geheugen er gebruikt wordt onder 64 Bit hoe sneller het is vergeleken met 32 bit niet helemaal opgaat).
Photoshop heb ik eigenlijk nog niet goed vergeleken.

[Reactie gewijzigd door fevenhuis op 22 januari 2009 13:53]

Nee, dat wil dat helemaal niet zeggen. Instructiesets zijn namelijk nagenoeg identiek en hebben dezelfde execution paths in de CPU, dus de optimizers zijn ook vrijwel gelijk. Bovendien ligt het grootste voordeel van optimalisaties niet de laatste fase, de assembly, maar het hele traject dat daarvoor ligt. Denk aan het bepalen van invarianten in loops en functies e.d.. En dat is in feite een wetenschap dat compleet los staat van de gebruikte processor. Bovendien, in mijn ervaring blijft geheugen echt de grootste bottleneck. Tegenwoordig zijn CPU's dermate rap dat je beter een berekening 2x kan doen dan dat je de uitkomst opslaat als die, wanneer je 'm nodig hebt, niet meer in de cache staat. Cache miss latencies van honderden cycles zijn vrij normaal. In die honderden cycles kan een CPU heel wat doen als hij al z'n data al klaar heeft staan.

.edit nav jouw edit:
(dus ik denk dat de stelling hoe minder geheugen er gebruikt wordt onder 64 Bit hoe sneller het is vergeleken met 32 bit niet helemaal opgaat).
Niet zonder meer nee. Ik had het over interne datastructuren. Jouw audiostream blijft evenveel data innemen, of je applicatie nou 32 bits of 64 bits is. Geldt ook voor photoshop, pixeldata blijft dezelfde pixeldata. Als je applicatie echter datastructuren gebruikt die groter worden, bijvoorbeeld omdat ze gebruik gaan maken van 64 bits integers (optioneel) of 64 bits pointers (verplicht), en er veel van dat soort datastructuren in het geheugen staan, dan kan een 64 bits versie flink nadelig zijn tov de 32 bits versie.

[Reactie gewijzigd door .oisyn op 22 januari 2009 15:25]

bijvoorbeeld omdat ze gebruik gaan maken van 64 bits integers (optioneel) of 64 bits pointers (verplicht)
Mij is altijd geleerd dat je voor integers altijd de native size van de CPU gebruikt, tenzij er een specifieke reden is om dat niet te doen. Je gebruikt een "kleinere" integer dus alleen omdat je externe code aanroept (of met een bestandsformaat werkt) die nou eenmaal een kleinere integer gebruikt. En je gebruikt een "grotere" integer als de waarde anders niet past.
Juist als we het hier over efficiency hebben is het gebruik van 64 bit integers dus niet optioneel, maar (practisch gezien, niet technisch) verplicht.

@.oisyn: Weer wat geleerd, dankjewel!

[Reactie gewijzigd door robvanwijk op 23 januari 2009 02:57]

er een specifieke reden is om dat niet te doen
Zoals bijvoorbeeld dat je minder geheugen gebruikt en daardoor minder cache misses hebt, waardoor code over het algemeen sneller performt :). Het is niet zonder meer waar dat het native type altijd het snelst performt. Zeker niet als het gaat om kleinere types dan het native type.

Overigens, het design van AMD64 zit zo in elkaar dat de kale opcode van de instructies met 32 bits waarden werken. In tegen stelling tot IA-32, waar een 16 bits waarde in een register zetten 1 byte meer kost dan een 32 bits waarde in een register zetten omdat de instructie een prefix krijgt, is het bij x86-64 juist precies andersom - om een 64 bits waarde in een register te zetten moet de prefix gebruikt worden. Daardoor wordt code voor 64 bits waarden langer, wat weer nadelig is voor de instruction cache.

Daarnaast is bij de LP64 (linux) en LLP64 (Windows) modellen het type 'int' gewoon nog steeds 32 bits.
Nee inderdaad, het is andersom 64 Bit draait sneller. 64 Bit grote hapklare brokken ipv. 32 bit brokjes.

Probeer het maar eens uit met een 32 Bit en een 64 Bit versie van 7zip, als bron.
x64 is vrijwel altijd sneller dan x86, en wel om een vrij domme reden. Het allersnelste geheugen in een PC zijn de registers op je CPU. De x86 heeft er historisch heel erg weinig (4 general purpose EAX-EDX, instruction pointer EIP, stack pointer ESP, frame base pointer EBP - dat was het wel zo'n beetje). x64 heeft er 16. Het maakt niet zo gek veel uit dat het 64 bits registers zijn, die 8 extra doen het meest.

(* Ik weet dat je register renaming hebt. Dat is niet bepaald handig op 3Ghz, en ook maar een beperkte oplossing)
Er zijn echt maar heel weinig programma's die een snelheidswinst boeken als je de native 64-bits versie gebruikt in plaats van de 32-bits versie. Bij 64-bits zijn voor sommige berekeningen met grote getallen minder instructies nodig en er kan winst worden geboekt met 64-bits only instructies. Ook de verhoging van 8 naar 16 interne registers kan een snelheidswinst opleveren als de compiler er slim gebruik van maakt. Maar over het algemeen is de snelheidswinst erg beperkt. De mogelijkheid om meer dan 4GB geheugen te kunnen gebruiken is gewoon de voornaamste reden om te switchen naar 64-bits.
Het ligt eraan wat voor programma's je gebruikt in principe hoe zwaarder de programma's hoe groter snelheidswinst, voor de gemiddelde consumenten software valt het wel mee inderdaad. Toch is er ook software waarbij consumenten snelheidswinsten kunnen boeken, bij zoiets als videoediting bijvoorbeeld.

Geheugenadressering is echt niet de enigste reden waarom er 64Bit OS'sen bestaan en waarom deze voornamlijk op server en wetenschappenlijk nivo al heel lang worden gebruikt .

Over het algemeen is een snelheidswinst van 20% niet ongebruikelijk voor zware applicaties.
(maar dat geldt ook weer niet voot alle taken).

[Reactie gewijzigd door fevenhuis op 22 januari 2009 14:08]

Wat jij "zware" programma's noemt zijn dus meestal programma's die gebaat zijn bij veel geheugen. Bijvoorbeeld Photoshop (als je er iets meer mee doet dan het editen van een digitale foto) of Premiere zijn van die typische programma's die voordeel hebben bij veel geheugen.

Het is niet zo dat filterbewerkingen in Photoshop automatisch sneller gaan dankzij 64-bits. Als je bijvoorbeeld een normale RGB foto hebt met 8-bits per kleur (zoals ze uit nagenoeg iedere digitale camera komen) dan wordt iedere pixel vertegenwoordig door een 32-bits getal. Filters zullen met deze 32-bits waardes moeten werken. Daar helpt 64-bits niks bij. Het is niet automatisch zo dat je dan maar twee pixels in één 64-bits instructie kan verwerken. De meeste basis instructies van een processor lenen zich daar namelijk helemaal niet voor (compare, add, substract, multiply, divide, etc).

Ik zou graag vergelijkingstests willen zien waar die 20% uitkomt. Ik laat me graag overtuigen maar ben erg sceptisch.

[Reactie gewijzigd door Milt op 23 januari 2009 00:37]

Tevens heb ik nog nooit een applicatie gezien in het bedrijsleven die meer dan 4Gb vraagt. (heb ik het dus niet over servers e.d.)
Als je in de audio/video hoek zit kan je er wel wat mee hoor, hoe minder je vanaf disks hoeft te streamen hoe liever.
3D modelleer- en renderpakketten gebruiken zoveel geheugen je wil.
Denk hierbij niet meteen aan kantoorapplicaties, maar aan engineering applicaties. Bijvoorbeeld Matlab, een veelgebruikt wiskundig pakket, of 3-D simulatie programmas, mechanical modelling etc.
Ik heb hier zitten werken met een scanner, waarbij ik een oude foto heb ingescanned op 1200dpi. Dat leverde "raw data" van 400 Mb op. Na een aantal bewerkingen (die je met "undo" weer ongedaan kan maken, hij onthoudt een aantal stappen) nam mijn photoshop.exe toch al gauw bijna 2.8 Gb aan geheugen in, terwijl dat op een 32bits machine bij 2 Gb op zou houden, en de harde schijf flink zou gaan ratelen om de boel naar pagefile te schrijven.

Ook Visual Studio is maar al te blij met meer dan 4 Gb, zeker als je meerdere projecten tegelijk open wil hebben.

En dan is het draaien van meerdere Virtual Machines om je applicatie te testen ook enorm handig. Moest je daar vroeger 3 PC's voor op je bureau hebben staan, nu kun je het vanaf 1 werkstation doen, en zelfs van 1 laptop als je wil developen en testen in de trein of het vliegtuig. ;)

En dan heb ik het nog niet gehad over AutoCAD en andere engineering/design applicaties, 3D modellering/ontwerp, etc....

Wellicht moet je eens voor een ontwerpstudio gaan werken in plaats van een saaie accountant. :P
Als je een legale vista 32bits hebt kun je de disk van de gelijkwaardige 64bits versie tegen kostprijs bij microsoft bestellen. Vista business is vista business of dat nu 32bit of 64 bit is.
Alle Windows Vista en Windows 7 licenties zijn taal en platform onafhankelijk. Je/je OEM betaalt voor een sleutel. Niets meer, niet minder.

x64 is niet duurder dan x86 software. Tussenbedrijven/Microsoft zelf mogen echter wel een meerprijs vragen voor het naleveren van extra media voor andere platformen (x86 <> x64).

Het is volledig legitiem om je eigen x86 computer te herinstalleren met x64 media. Het enigste aspect waarmee je wellicht in de knel komt, is de directe support van je fabrikant/OEM wanneer je buiten hun normale supportpaden gaat wandelen.
Grote "probleem" is en blijft het geheugen. Het is nu al bijna standaard om 4 GB standaard in een systeem te hebben, waar je dus maar effectief 3,2 GB ongeveer aan overhoudt.

Het houdt ooit ergens op, dus zullen de software-fabrikanten er steeds sneller opduiken, gok ik :)
Het is een beetje een kip-ei probleem. 64-bit tools hebben weinig zin zonder een besturingssysteem dat daar gebruik van kan maken. Het feit dat er nu een bredere basis is voor de besturingssystemen zou kunnen betekenen dat het aantrekkelijker is om ook de tools e.d. te gaan optimaliseren voor 64bit, wat op zich natuurlijk positief is.
Ik draai op mijn desktop al sinds Vista de x64 versie, en ik heb absoluut niet te klagen, loop allemaal vlot. Enige probleem is dat er geen drivers zijn voor mijn webcam, nuja die sluit ik dan maar aan op men laptop.

Fabrikanten willen soms gewoon geen x64 drivers maken voor hun oudere apparatuur om mensen te verplichten een nieuw product te komen.

Qua x64 software begint het ook redelijk vlot te lopen. Virusscanners, sommige games (HL2 bijvoorbeeld), professionele software (Photoshop), enz. Sommige software begint immers ook bijna te eisen dat je 4GB aan werkgeheugen hebt om zeer deftig mee te kunnen werken.

Daarnaast natuurljk het feit dat de maximale geheugendensiteit op moederborden al lang voorbij de 4GB grens is. DDR2 mobos kan je 8GB in proppen, DDR3 to 16GB met 4 slots, 24GB met 6 slots. Heb je natuurlijk echt wel een 64bit OS voor nodig om dat allemaal aan te spreken.
Wellicht heeft dit ook te maken met de nieuwe Core i7 processors die een triple channel geheugeninterface hebben. 6 GB (3 x 2 GB) is een vrij logische keuze voor dat soort systemen, en je gaat natuurlijk geen 32-bits OS op zo'n systeem draaien waardoor de helft van het geheugen ongebruikt blijft.

Ik gebruik zelf overigens al anderhalf jaar 64-bit Ubuntu, en dat werkt volledig zonder problemen. Adobe en Sun hebben eindelijk ook beta-versies van 64-bit Flash en een 64-bit Java browser plug-in beschikbaar voor Linux (zodat je niet meer de 32-bit versie hoeft te gebruiken op je 64-bit systeem).

Ook voor Windows worden er steeds meer programma's in een 64-bit versie uitgebracht, de Adobe CS4 programma's bijvoorbeeld zijn nu ook in een 64-bit versie beschikbaar.

[Reactie gewijzigd door jj71 op 22 januari 2009 12:52]

De verwachting is bovendien dat Windows 7 het laatste besturingssysteem van Microsoft wordt met native 32bit-ondersteuning
Dat zal wel moeten zolang MS pretendeert dat het op netbooks te draaien valt. Verreweg de meeste netbooks herbergen een Atom N270 of een VIA C7 en bij mijn weten heeft geen van die twee AMD64 of Intel64.
De nieuwe Via Nano heeft echter wel ondersteuning voor de x86-64 (AMD64) instructieset, dus die kan wel overweg met een 64-bit OS.
En ook de Intel Atom heeft gewoon wel de x86-64 instructieset.
Is 64 bit altijd sneller? Nee.

Bij gebruik van een 64bit systeem wordt er gebruik gemaakt van 64 bit's adres pointers in de code. Deze worden in de cache opgeslagen. Adres pointers zijn een significant onderdeel van de code. Hierdoor wordt effectief je cache gehalveerd.

Maar er worden nu toch 64 bts instructies gebruikt?
Klopt. Dus als er gerekend wordt met grote getallen kan het dus sneller. Dit gebeurd echter maar sporadisch bij een normale kantoor machine. Er zijn ook extra SSE instructies die grotere getallen kunnen verwerken in 64bits mode.

Waneer dan 64 bits gebruiken?
Als je meer 3GB intern geheugen gebruikt kan een 64bits systeem dit rechtstreeks aanspreken en gebruiken als cache. Hierdoor wordt bijna alles sneller.

Waneer niet? Bij het bebruik van bv applicatie server voor business applicaties van sommige ERP systemen is het bekend dat als er met minder dan 3GB gewerkt wordt de applicatie sneller is in 32bit. Dit omdat de cache effectiever wordt gebruikt en er geen of amper 64bits berekeningen worden gedaan.
Wat ik me afvraag: betekent dit dat support voor 16-bit applicaties dan volledig afgeschaft wordt?
Dat zal denk ik nog steeds via een emulator kunnen. DOS programma's kan je ook nog steeds via DOSbox gebruik. Maar ik moet zeggen dat dat niet altijd ideaal werkt. Uiteindelijk zal een 64-bit omgeving een 32-bit omgeving gewoon kunnen emuleren.

En als je dan nog een DOS applicatie wil draaien, dan emuleer je in de geëmuleerde 32-bit omgeving weer een 16-bit omgeving :D
Op dit moment kun je ook op een 64-bits OS zonder problemen 16-bits applicaties draaien, hetzij gevirtualiseerd. Althans 'k heb hier op mijn Windows 7 64-bit zonder problemen een Windows 2.1 installatie voor elkaar binnen een VM. Of het ook met bv. DOSbox zou werken weet ik niet, maar het kan wel natuurlijk...
Installeer XP op je VM en daarna in die XP je DOSBox voor oudere spellen ;-) Zo heb ik afgelopen jaar 'ouderwets' doom gespeeld (en ja, ik weet dat er doom95 en zdoom variaties zijn, maar ging ook om oudere spellen zoals Decent etc. waar de windows versies minder goed van werken)

En dit allemaal onder Vista64 zonder problemen.
Onder Linux heb je DOSEMU een goede DOS emulator
http://www.preshweb.co.uk/linux/howtos/dos/

En ook FAT16 kan worden geïnstalleerd (indien gewenst).

[Reactie gewijzigd door nieuwstip op 22 januari 2009 13:40]

Wat is er mis met rechtstreeks DOSBox onder vista draaien?
Als je win 2.1 hebt draaien geef je zelf al het antwoord...

[Reactie gewijzigd door Davey400 op 22 januari 2009 13:49]

Helemaal mee eens, je kan dmv virtualisatie en emulatie (vaak nog gratis ook) zo ver terug gaan als je wilt, dus eigenlijk zal het vrijwel altijd mogelijk zijn om applicatie x op OS y te draaien.
Ja, in WIndows 64 is geen 16 bit ondersteuning meer.

Zie ook: http://support.microsoft.com/kb/282423
ohnee! definitief afscheid van paratrooper! O-)
dan port je die naar 64 bits, zal niet zo moeilijk zijn denk ik, :).
Dus.
Of je doet het makkelijk;
download Vbox van Sun,
installeeer vBox
maak een nieuwe VM. Geef hem 4 GB ram (van je 64bit bak moet dat lukken toch?)
mik er je ouwe legale Windows XP 32bit op
installeer DosBox
installeer paratrooper in dosbox
speel paratrooper
ontdenk dat de processor véééééél te snel is
run vijftig maal het programma "slow.com"
speel nogmaals paratrooper.
ontdek na tien minuten dat dat fucking saai is.
zet vbox uit
start Crysis Wars
ga online en schiet je vrienden en kenissen de puinpoeier in
na een jaar of twee, drie, als er weer een nieuwe windows versie komt die iets niet kan, word je nostalgisch en ga je weer bovenaan dit tekstje opnieuw beginnen.

Have fun! :+
mik er je ouwe legale Windows XP 32bit op
installeer DosBox
Ben ik nou gek of kun je dan beter meteen DOS installeren?
Niks zo nostalgisch als klooien met config.sys en je proberen te herinneren hoe het ook alweer zat met expanded/extended/high memory. Lineair adresseren is zooooo 1995! :+
Krijg je dan geen problemen met de afwezigheid van een VESA modus? 8-)
Je kunt DOSbox ook gewoon native op 64bit installeren, dat is immers een 32bits programma. Net zoals je een Amiga II of C64 kunt emuleren, kan dat ook met DOS natuurlijk. ;)
Ik denk dat je geen gelijk hebt, op dit moment is het nog steeds mogelijk om een 16-bits applicatie te draaien onder Windows 7. Goed voorbeeld daarvan is het ontwikkelingsplatform Silicon Office uit de jaren 90.
"native" zal hier wel een belangrijk keyword zijn dat vergeten werd...
16bit applicaties draaien op een virtueel/geëmuleerd systeem zal waarschijnlijk wel mogelijk blijven, en evt volledig transparrant voor de gebruiker.
Volgensmij hebben de Core2 chips al geen 16bit mode meer. Ik meen dat de Netburst chips de laadste waren.-not sure-
De Core2 heeft nog gewoon een 16-bit mode. Iedere PC start standaard in 16-bit mode op. Zodra het BIOS het besturingssysteem start zal vrijwel direct naar 32/64-bit overgeschakeld worden.

[Reactie gewijzigd door Icelus op 22 januari 2009 12:41]

Yep; je PC BIOS boot not altijd in 16-bit "real mode" ala 1978 (al is de term pas vanaf de 80286 in gebruik), de OS loader zelf switcht pas naar 32-bits "protected mode" of 64 bits "long mode".

Native EFI BIOSes zijn wel 32-bits, maar er bestaat ook een EFI implementatie (Intels BIOS32) die op de klassieke BIOS16 doorbouwd, waarbij dus van 16 naar 32 bits wordt overgeschakeld door de BIOS voordat EFI "gestart" wordt.
Daarom is Intel ook met de EFI standaard gekomen, eerst voor hun eigen ontwikkeld in 2000 en nu wordt het door de "Unified EFI Forum" beheert.

De Intel Itanium systemen hadden namelijk meer nodig, en Apple is er al een tijdje mee bezig (sinds Jan 2006) voor hun desktop systemen.

Sinds Vista SP1, zit er nu ook UEFI ondersteuning in Vista. Microsoft kon niet zo snel als Apple ondersteuning toevoegen, omdat het teveel afhankelijk is van andere partijen voor hardware support.
Wat is de rede hierachter eigenlijk?
Zou het niet logischer zijn om meteen (op zijn minst) in 32-bit mode starten?
Of zijn er anders technische problemen?
Backwardscompatible blijven. Zodra een CPU start staat het standaard in 16-bit mode en begint het vanaf een vast adres instructies te lezen. Hier staat normaal een verwijzing naar het BIOS die, na wat tests, het OS opstart.
Bedoel je niet de 8-bit mode?
De 80286 is volledig (intern en extern) 16 bit, maar de 8086/8088 niet.
De 8086 en 8088 zijn 16-bit processoren; de 8088 heeft echter een 8-bit databus. Dit scheelde in productiekosten maar maakte de processor wel trager doordat 16-bit-gegevens nu in twee stappen opgehaald moest worden. De 80286 was de eerste x86 met protected mode (1GB logisch en 16MB fysiek geheugenadressering).

[Reactie gewijzigd door Icelus op 22 januari 2009 16:32]

de vraag is: hoeveel 16 bit applicaties zijn er nog...

en zelfs al zijn die er, een Virtual Machine doet wonderen
Het probleem is niet alleen de 16 bit software, maar treedt ook bij 32 bits software op. Zeker oudere 32 bits software of software die via een oudere installer gebruikt wordt.

De problemen kunnen als volgt zijn: Veel maatwerk applicaties (maar ook nog genoeg standaard applicaties overigens) zijn doorontwikkelingen van een oudere versie. Het kan best zijn dat wat aan de gebruiker getoond wordt wel gewoon 32 bist is, maar op de achtergrond voor een bepaald proces nog gewoon een oude 16 bits exe gestart wordt. De applicatie werkt dan tot het moemtn dat die exe aangesproken wordt. Je gaat dan dus functionaliteit missen of zelf onverklaarbare crashes krijgen.

Een ander probleem wat ik al gezien heb is het volgende: Applicaties worden in de regel door middel van een installer op het systeem gezet. Deze installer is zelf ook een applicatie. Veel mensen staan bij dat laatste niet stil. Als er gebruik is gemaakt van een oudere tool voor om de installer te maken, dan kan het best zijn, dat de installer zelf 16 bits is en je de applicatie niet kunt installeren, hoewel de applicatie zelf 32 bist is. Vooral oudere 32 bits applicaties willen hier nog wel eens last van hebben.

Thuisgebruikers zullen hier waarschijnlijk allemaal minder last van hebben, maar voor bedrijven kan dit wel problemen veroorzaken.
Dit dus, nageneog alle software is op die manier nog gewoon te gebruiken en ook nog eens tot op een x hoogte cross platform.
DOSBox en dergelijke projecten blijven voorlopig nog wel bestaan. Al was het alleen maar vanwege de oude games.
Het enige probleem dat je kan hebben is DRM. Een low level sector check op een disk kan wel eens niet werken als het host OS dat niet meet toestaat, of waneer de originele media niet meet bestaat of niet meer aan te sluiten is. Ik begin maar niet eens over authentication servers.
Lang leven de crackers en release groups dus :)
Niet alleen DRM, soms gaat het ook "per ongeluk" fout. Bijvoorbeeld bij (als ik me goed herinner) de eerste versie van MechWarrior. De installer daarvan probeert bestanden naar je schijf te schrijven door rechtstreeks met de HDD te kletsen (in plaats van system calls aan te roepen). Zodra Windows (NT, 2K, XP, etc.) dat ziet wordt het proces meteen gekilled (en da's maar goed ook, want die installer verwacht een FAT-indeling, geen NTFS).
Gelukkig zijn er ook spellen die netjes geprogrammeerd zijn. De eerste X-Wing doet het bijvoorbeeld prima op een Duron 1300 onder Windows 2000 (zelfs geen problemen met timing). Moet binnenkort eens proberen wat er gebeurt onder XP 64... :p
Ik wilde laatst Monkey Island 4 weer eens uit de kast halen, een spel van 2000.... en die heeft dus een 16bit installer! Gelukkig kun je op het internet een installer vinden van een hobbyist waarmee je het spel perfect kunt installeren en spelen op Vista x64.

Starcraft (het orgineel) is ook een spel met 16bit installer, en dat is nog steeds mateloos populair. Ook hiervoor heeft iemand online een workaround bedacht trouwens, omdat het spel zelf 32bits is.

Het komt dus nog wel eens voor.... maar niet bijzonder vaak. Ik heb er zelf op 64bit Vista geen last van iig.
Daar is al afstand van gedaan in XP64. Dat je via virtualisatie/emulatie of iets dergelijks moeten doen.
Ik heb xp64 ooit geinstalleerd als experiment voor FarCry x64 en ben na verloop van tijd blijven plakken op x64.
Ik heb voor uitzonderingen een XP32 VirtualMachine opgetuigd, die ik in de laatste 2 jaar wel 2x opgestart (t.b.v. Citrix).

Nu ik mijn bak ga ombouwen naar PII 940, ben ik ook van plan om Win7 x64 te installeren, als proef.
Ik heb diverse uitgetest en moet concluderen dat 64bits toch de toekomst is. Draai al een tijdje de 64bit en zonder problemen. Ja die problemen worden veroorzaakt door MS zelf dat de drivers digital ondertekent moet zijn. Ik heb 1 produkt wat nog niet een 64bit driver heeft. Dat wil zeggen niet digitaal ondertekent.

Door een klein bestandje te downen schakel je dit uit of je laat de beveilingpatch weg en gebruikt een CMD string en walla het werkt gewoon. Begrijp ik wel is natuurlijk niet de bedoeling. Naar tijd zal het leren, 64 bit word gewoon gemeengoed.
Ik dacht dat je driversigning kunt uitschakelen door gewoon in je boot.ini een extra switch toe te voegen ( /debug meen ik). Er zijn ook tools om unsigned drivers alsnog zelf lokaal te signen, waardoor je deze toch kunt installeren. Zowieso mensen die zelf aan driverontwikkeling doen zullen zoiets op een testbak moeten uitvoeren om snel die drivers te kunnen testen.

Anyway, voor fabrikanten hoeft het niet zoveel moeite te kosten om de drivers te porten (indien ze goede driver developers hebben). Heb dit ooit op stage al gedaan. Ging toen welliswaar om XP drivers, maar het idee is hetzelfde. Je moet de .inf file wat aanpassen, je code nalopen om te kijken of er ergens datatypes worden gebruikt die ineens 64 bits groot zijn (pointers, etc) en daar wat aanpassingen in doen.
Alleen als je assembly gebruikt zul je flink aan de slag moeten aangezien inline assembly niet meer is toegestaan. Je zal dan de buildprocedure moeten aanpassen door eerst je c code te compileren en daarna je assembly te assembleren en daarna alles aan elkaar te linken. En bij assembly heb je ook nog eens te maken met het feit dat de calling convention op de schop is genomen bij x64.
Zelfs mét die workaround zijn er genoeg drivers die nog niet 64-bit compatibel zijn. Simpel gezegd: Er zijn genoeg 32-bit drivers die er niet op werken en waar de fabrikant geen 64-bit driver van uit heeft gebracht :Y

Een goed voorbeeld is de B-Control serie van BEHRINGER.
de Behringer B-Control serie.... hmmm.... nog NOOOOOOIT van gehoord... vind het daarom ook niet vreemd dat er geen 64bit drivers zijn... klinkt als vrij (oude) exotische hardware... oftewel.... Ga maar zeiken bij Behringer dat ze geen drivers hebben uitgebracht...

edit:
Nader onderzoek leert mij dat het gaat om een MIDI-controller uit 2004 (!) dus A ) het is "exotische" software en B ) het is OUD... (Ja, in de computerwereld is 5jaar oud)

dus goed voorbeeld? NEE!
slecht dat er GEEN 64bit drivers voor zijn? Ja, want "muziekapparatuur" gaat meestal langer mee dan 5 jaar...
Daarnaast is er misschien een userbase van 1% van alle Muzikanten (ff uit de lucht gegrepen) wat misschien 0.01% van alle computergebruikers is... wat het niet commercieel haalbaar maakt.

daarnaast is 2004 het jaar dat 64bit voor het "eerst" doorbrak in de consumentenindustrie...

[Reactie gewijzigd door mstreurman op 22 januari 2009 14:03]

Ik heb gieteren de BETA 7000 build x64 geïnstalleerd op mijn klapjapanner en moet zeggen dat ik nog problemen heb gezien.
x64 gaat naar mijn mening ook de standaard worden. Steeds meer mensen zullen overgaan van x86 32-bits naar x64.
Het is logisch dat het de standaard word. Al is het maar voor ram gebruik.
Desalniettemin is het een fabeltje. Zo ook dit stuk uit het artikel:
Een van de voordelen van een 64bit-besturingssysteem is er meer dan 4GB ram gebruikt kan worden.
Complete onzin. De pentium pro kon al 64GB adresseren (klik), en Windows XP SP2 maakt van dezelfde PAE extension gebruik om de NX-bit op pages te gebruiken zodat je code niet standaard uit datapages (die die bit dan typisch gezet hebben) kan runnen. Dit om een bepaalde categorie van exploits tegen te gaan. 32 bits linux versies ondersteunen al een tijd 64 GB, en ook de geavanceerdere Windows Server edities kunnen meer mem aanspreken. De enige reden dat de 32 bits versies van XP en Vista het niet kunnen is omdat daar bewust voor is gekozen, niet omdat dat een technische limiet is van de hardware. Als je meer wilt, dan koop je maar een server OS.

Goed, het blijft natuurlijk wel waar dat pointers op een 32 bits systeem gewoon 32 bits zijn, waardoor je niet meer dan 4GB lineair kunt adresseren. In Windows betekent dat typisch dat je per proces nog steeds aan de 2GB (of 3GB als zowel de app als het OS die vlag gebruikt) vast zit. Echter is het dus niet zo dat het onmogelijk is om het OS meer dan 4GB aan te laten spreken.

[Reactie gewijzigd door .oisyn op 22 januari 2009 13:15]

Windows 32 bit kan meer dan 2 Gigabyte geheugen addresseren. En ja, dat werkt inderdaad met PAE. En de NX bit is hier niet voor bedoeld. Wat wel kan onder Windows is de 3GB switch gebruiken. Alleen zit de beperking van 32 bit niet in de hoeveelheid geheugen (64GB) maar in de maximale adresseerbaarheid binnen 1 proces, en dat is 4GB. In het ontwerp heeft MS dan ook besloten om een process in twee onderdelen op te delen van 2GB (adresspace van een process onder Windows is exact 4GB per process net zoals onder Linux 32 bit, is beperking van processor), de 3GB optie zorgt er voor dat dit 3 en 1 verdeling is. Binnen een process is onder Windows de eerste 2GB voor applicatiecode en data (heap, stack, etc. etc), de 2GB is adresspace wat (soms) gedeeld wordt en bedoeld is voor kernel routines (gemapped) en DLL bestanden (geladen door de applicatie en OS), dit wordt voornamelijk gedaan doormiddel van Memory mapped toegang. Daarom is Windows efficiënt met het laden van DLL bestanden, die staan als het goed is maar 1 maal in het geheugen en wordt alleen dubbel geladen bij een Copy Memory On Write bij bijvoorbeeld een actie van een virus of andere integriteits aanpassing.

Microsoft heeft er echter voor gekozen om PAE alleen te ondersteunen in de Advanced/Enterprise en datacenter Editions van 2000, 2003, 2008.

64 bit software is een ander verhaal. Hierdoor wordt de processspace uit de 4GB grens getrokken (64 bit pointers in plaats van 32 bit pointers) en hoeft men geen gebruik te maken van PAE zoals onder 32 bit nodig is.
Om de NX-bit te ondersteunen moet je PAE gebruiken, omdat er anders geen manier is om die bit op een page in te stellen. Windows XP en Vista gebruiken dus wel degelijk de PAE extension, maar maken er niet gebruik van om meer dan 4GB aan te kunnen spreken (terwijl dat in feite een kleine moeite is)
Klopt helemaal, maar wat gesteld werd is dat NX nodig was voor meer dan 4GB en dat is het niet, PAE is nodig om NX te kunnen ondersteunen dus precies andersom :) Maar dat zeg jij ook :)

Overigens heeft MS haar productrange gesplitst en doen ze dat door specificaties vast te stellen. Net zoals het CPU limiet. Home kan bijvoorbeeld maar 1 CPU aan (met meerdere cores) Pro kan 2 CPU's aan :)
maar wat gesteld werd is dat NX nodig was
Dan moet je m'n originele post nog even goed lezen. Ik zei namelijk:
Windows XP SP2 maakt van dezelfde PAE extension gebruik om de NX-bit op pages te gebruiken
Nergens zeg ik dat de NX-bit nodig is voor meer dan 4GB, dat is slechts hoe jij mijn post (foutief) interpreteert :)
Overigens heeft MS haar productrange gesplitst
I know, en daarom zei ik ook:
Als je meer wilt, dan koop je maar een server OS
Die kunnen namelijk wél meer dan 4GB aanspreken onder 32 bits. Hangt wel af van de versie hoeveel ze daadwerkelijk kunnen aanspreken. Volgens mij halen alleen de advanced servers de 64GB. Goed, deze opmerking gaat inmiddels natuurlijk niet echt meer op met de 64 bits OS'en, maar toen die er nog niet waren was dat de enige keuze (hoewel consumenten met 4GB of meer in hun desktop vrij zeldzaam waren)

[Reactie gewijzigd door .oisyn op 26 januari 2009 12:27]

Er zitten een aantal specifieke voordelen en om dit nu onwaar te verklaren is misschien wat cru. .Oisyn heeft gelijk dat een machine die gebruik kan maken van Physical Adress Extentions tot 64GB aan memory kan adresseren.

PAE maakt het namelijk mogelijk om in plaats van 32 bits 36bits aan geheugen te adresseren. Dit komt overeen met de 64GB die .oisyn noemt. Het nadeel dat hier bij zit is dat hoewel er 36bits voor adressering zijn er maar 4GB aan memory per proces kan worden gealloceerd. Hier in maakt het echt geen verschil of er gekozen is tussen een client of een server OS op 32bit. Dit zijn gewoon de restrictie die hier aan verbonden zijn.

De limiet van 4GB per proces komt voort uit het feit dat PAE pagetables gebruikt om de 4GB blokken in de max. 64GB aan memory plaatst. Belangrijk is dat je dus wel moet switchen naar 64bit als je dus meer dan 4GB aan 1 proces wilt kunnen toekennen.
Ik reageer hier maar even op alle reacties tegelijk
guidorobben
Euh ja, ik snap even totaal niet de relevantie van die post eigenlijk... :?

TheCodeForce
jij hebt er alleen meer details bijgehaald en impliciet aannamen gemaakt dat er bedoeld is dat het OS niet meer geheugen kan aanspreken
Idd, letterlijk zoals in het artikel stond: Een van de voordelen van een 64bit-besturingssysteem is dat er meer dan 4GB ram gebruikt kan worden. Dat is dus niet een voordeel, een 32 bits besturingsssyteem kan dat ook. Ja, zelfs bepaalde 32 bits versies van Windows. Vandaar mijn conclusie "onzin". Niet zo vreemd, toch?

Mr_Light
Als je meer wilt, dan koop je maar een server OS
Dat is je oplossing?
Nee, dat was de redenatie van MS. Ik beweer helemaal nergens dat ik er zo over denk.

Clueless
Het nadeel dat hier bij zit is dat hoewel er 36bits voor adressering zijn er maar 4GB aan memory per proces kan worden gealloceerd
Om precies te zijn, 4GB per selector. Maar er is in feite geen limiet aan het aantal selectors in een applicatie (ja, ok, 8191), dus het is weldegelijk mogelijk om de volle 64GB in 1 proces aan te spreken. Maar dus niet in lineaire vorm, zoals ik al zei. Je hebt dan 16 afzonderlijke chunks van 4GB. Leesvoer. Wat betreft Windows heb je overigens wel gelijk (van andere OS'en weet ik het niet), omdat die nou eenmaal niet ondersteunt dat je meerdere selectors op applicatieniveau kunt aanmaken. Of je moet een driver maken die die ondersteuning toevoegt. Maar dat was niet de kern van mijn reactie. Veel mensen denken dat de 4GB limiet van Windows XP en Vista een hardwarematige is, namelijk door het 32 bits model. Dat is niet zo.
Is echt geen onzin, jij hebt er alleen meer details bijgehaald en impliciet aannamen gemaakt dat er bedoeld is dat het OS niet meer geheugen kan aanspreken.

Het is ook zo dat de extenties (PAE) niet zo prettig werken als een grotere adresruimte. En daarom is bij server software die meer dan 4GB kan aanspreken het gebruik beperkt tot het cachen van data.
So the _only_ explanation today for 12GB on a 32-bit machine is
(a) insanity
or
(b) being so lazy as to not bother to upgrade
and in either case, my personal reaction is "I'm *not* crazy, and yes, I'm
lazy too, and I can't give a rats *ss about those problems".

HIGHMEM was a mistake in the first place. It's one that we can live with,
but I refuse to support it more than it needs to be supported. And 12GB is
*way* past the end of what is worth supporting.

Linus
http://lkml.org/lkml/2007/11/15/423
Als je meer wilt, dan koop je maar een server OS.
Dat is je oplossing? Maar een dikke hack en een speed penalty voor lief nemen en nog eens een os draaien die eigenlijk helemaal niet geschikt is voor je taken. Dat dat de goede manier zou zijn dat vind ik nu een fabeltje..

Dan heb ik het nog niet eens gehad over alle issues rond om die rommel of hoe native ondersteunen de kans op fouten in een cpu in de hand werkt etc etc.

En dat allemaal voor een of andere rare voorliefde voor 32 bit.

//edit
...mijn kern was dat het dus helemaal niet uitmaakt of PEA werkt de optie is van 64 bits is er lang genoeg. 32bit is gewoon geen optie meer dat kost je uiteindelijk alleen maar meer geld en inspanning.
En voor de mensen die hun geheugen op een normale manier wil adresseren is het een prima reden om voor 64bit te kiezen

[Reactie gewijzigd door Mr_Light op 22 januari 2009 20:09]

Je vergeet dan wel dat om PAE te kunnen gebruiken dat zowel de applicaties als drivers dat moeten ondersteunen.

Voorbeeld: Je 32bits photoshop in een 32bits Windows met PAE geheugen laten gebruiken boven de 4 Gb grens gaat niet, waar de 32bits versie dat prima kan in 64bits Windows.

Een SQL server op HP Proliant hardware, dat gaat prima. Maar gaming, photoshopping, etc op een zelf in elkaar geflanste kloon.... daar kun je PAE niet voor gebruiken.
Photoshop krijgt virtueel geheugen, geen fysiek geheugen. Daarom kan het makkeljk geheugen boven de 4GB grens gebruiken, bijvoorbeeld fysiek 4-7 GB. Je zit echter nog steeds aan de 3GB grens per proces. PAE voorkomt dus swappen.
Ik draai al maanden zonder enige problemen Vista 64 bit.

Dat een beta versie van windows 7 problemen heeft is logisch. beta he....
Maar vista 64 bit werkt gewoon prima, zeker als je geen oude onderdelen gebruikt.
Idem hier. Op een enkel programma na (die wel aangeven Vista compatibel te zijn) draait alles zonder veel problemen.

Behalve Flash. In Minefield,de (onofficiële?) 64 bit versie van Firefox, werkt Flash niet.
In het begin had ik mij voorgenomen alleen maar 64 bit software te gaan draaien op mijn machine en kwam daarom ook uit bij Minefield (64 bit heeft geen echte toevoeging op een browser heb ik begrepen, maar principe is principe).
Mijn teleurstelling was dan ook groot dat ik voor flash content terug moest grijpen op een 32 bit versie van FF of IE.

Inmiddels heb ik gezien dat er al wel een 64 bit versie van Flash uit is voor Linux dus er is hoop, maar voordat je echt kan spreken van een 'goede' overgang naar 64 bit denk ik dat er nog heel wat software te gaan is om dit te bereiken.
[nieuwsgierig]
En wat gebruik je dan als PDF reader?
[/nieuwsgierig]
gewoon de 32bit versie van Adobe Acrobat Reader zeker?
Nu lees ik niet zoveel pdf's dat ik dit uit mijn hoofd weet (en ik zit nu op mijn werk dus kan het niet direct opzoeken).
Maar in het begin heb ik voor alle software gekeken op http://www.start64.com.
Daar heb ik volgens mij (ik herken in ieder geval de schermafbeelding) deze gedownload.
ach, ik draai xp x64, ben dr ook tevreden over, dr zijn maar 3 dingen die ik niet draaiend kreeg, dat was sketchup (die haperde/reageerde niet goed op de muis), de vpn client van de universiteit (= x32 driver) en een webcam uit <1999.
verder draait x64 prima. win7 trouwens ook :)
vpn client van Cisco zeker, man heb ik gevloekt daarop, alles werkte goed op vista 64.

behalve 1 ding: men vpn Client om te connecten op school, wel een groot probleem als je informatica doet, en Cisco weigert om een x64 versie te lanceren
dan maar jammer genoeg terug naar x32...

het word tijd dat iedereen eens een extra inspanning leveren en alle programma's/drivers x64 compatibel maken
en een simpele kale 32bits virtual pc draaien? :), installeer je daar je cisco vpn in en klaar :)

Met een share op je host + netwerk drive connecten in de virtual pc moet het 1 en ander toch wel te regelen vallen :) zeker met hardware supported/assisted virtualisation moet dat geen probleem zijn.
Precies! zo doe ik het ook!
Ik draai verder alles thuis al sinds midden 2005 op 64bit (XP)
in het begin wat moeilijker , maar veeeeeeeel stabieler als een 32bit variant!
(natuurlijk ook te maken met de server2k3 kernel.)
vista 64 bit werkt hier ook uitstekend
het enige minpuntje dat ik heb is dat mn oude cam niet meer werkt,
maarja dat ding heeft maar 20 euro ofzo gekost en en gebruik het toch bijna niet.
Het lijkt me logisch dat je problemen hebt, aangezien het nog maar een BETA is :).
weinig verrassend inderdaad, zelf had ik wat problemen met name bij het gamen met corruptie van het beeld. Waarna windows er ook mishandeld uitzag :+

Oplossing daarvoor was gewoon de laatste beta vista 64 bit drivers gebruiken.
Het zelfde heb ik ook uiteindelijk voor mijn geluidskaart gedaan zodat ik de mic ingang als hoofdtelefoon uitgang kan gebruiken. Op punkbuster die bij online games kickt na heb ik verder eigenlijk geen problemen gehad. Alles draait out of the box, en is het ook stabieler dan vista 64 bit op mijn systeem.
Deze beta is op veel gebieden gewoon beter/stabieler dan vista toen het uitkwam (en op sommige gebieden nog steeds)

Win 7 zie ik als ze het niet heel hard vernachelen als een goede optie om mn XP installatie te vervangen.
Ik had stiekem gehoopt dat Windows 7 alleen in 64 bit uitvoering uit zou komen. Dat zorgt er voor dat hardwarefabrikanten sowieso nieuwe drivers moeten gaan schrijven en uit moeten gaan brengen voor Windows 7. Een ander voordeel is dat mensen Windows 7 niet gaan installeren op een verouderde pc waardoor de Experience beter wordt.

Zeg nou zelf, als jou hardware 64 bit drivers heeft, waarom zou je nu dan nog een 32bits OS installeren als je de keuze hebt?

edit: spelling/grammar: thanx jvo!

[Reactie gewijzigd door Joost_1981 op 22 januari 2009 12:09]

Ik denk niet dat de leeftijd van de PC de issue is met Vista experience.
Vista is vergeleken met alternatieven gewoon feitelijk zwaar, even los van het feit waar dat aan ligt en waarom dat zo is.
Ik had begrepen dat dit met Windows 7 juist weer minder zou worden, dus verwacht ik ook dat Windows 7 beter presteert op dezelfde of misschien zelfs mindere hardware dan Windows Vista.
de eisen voor XP lagen eerder te laag IMO. Met de requirements was je PC niet vooruit te branden... Draai jij het maar eens op een P300 met 128 MB. Kan je een thermoskan koffie zetten en leegdrinken voordat je systeem opgestart is. ;)

De aanbevolen hardware voor Windows 7 ligt however momenteel toch echt 'nagenoeg' gelijk;
-Windows Vista
-Windows 7

Waarom 'nagenoeg' tussen quotes? Ik zie geen verschil tussen de vereisten... :+
p3 230 met 128 mb geheugen.. (had de buurman het op geinstalleerd)
computer deed dr inderdaad bijna 10 minuten over om naar bruikbare desktop te komen, en *alles* was traag. (browser openen duurde ook weer een minuut, alles swappen)
dus idd, de eisen van xp waren idd te laag.. mja, dat is ook al weer.. 8 jaar geleden?
Windows 7 niet gaan installeren op een verouderde pc
De meeste (32-bit!) Core Duo PC's/Macs kunnen Vista (en Windows 7) prima draaien.

[Reactie gewijzigd door Dreamvoid op 22 januari 2009 15:12]

32 core duo ?
Is dat een nieuwe type processor ?
Nope: http://en.wikipedia.org/wiki/Intel_Core

Eerste core generatie van intel is nog 32 bit, de Core 2 Duo's zijn pas 64-bit.
Idd niet overnagedacht Dreamvoid. De Core Duo is 32bit! Dat sloopt mijn stelling behoorlijk ;)
Ja, dat lijkt mij ook het beste. Gewoon alleen 64 bits met 32 bits ondersteuning. Voor 32 bits met 16 bits ondersteuning gebruik je maar XP. (Of vista natuurlijk.) Op dat moment wordt ook het driververhaal weer duidelijker. Een windows 7 driver is een windows 7 driver.
offtopic:
Het is "sowieso" (uit het Duits), niet zo-ie-zo o.i.d.
tuurlijk, laten we windows7 alleen in een 64-bit uitvoering uitbrengen zodat men weer massaal kan zeiken op MS dat hun OS zo brak is door ouwe "rotzooi" niet te accepteren.

Waarom denk je dat een OS als Vista welk in mijn ogen superstabiel is (thuis+werk) volledig de grond in is geboord vanwege de vele randapparatuur wat het niet meer deed?? heel goed voorbeeld, de geluidskaarten van Creative

edit//

HELL, ik heb gister voor het eerst meegemaakt dat ik geen youtube filmpjes kon bekijken tijdens het surfen en het eerste waar ik aandacht was kut IE browser terwijl ik de flash plugin al had geinstalleerd op mn pc... blijkt achteraf dat FLASH helemaal geen 64-bits player heeft vrijgegeven... en dat voor iemand die al jaren in het vak zit..

[Reactie gewijzigd door SYQ op 22 januari 2009 12:33]

Dat is de schuld van creative, of het word tijd voor een nieuwe soundkaart
Je slaat de spijker op zijn kop! En daarom moeten we naar alleen 64 bit in mijn ogen!

En creative..... zucht.....
Sorry hoor, maar tenzij je IE 64 bit expliciet opstart, draai je IE toch echt de 32 bit versie...

MS is trouwens niet verantwoordelijk voor drivers, maar de hardware leveranciers. Kan je MS niet op afrekenen.

Bovendien, er moet wel vooruitgang zijn. Een SB 16 kan niet tot in de eeuwigheid ondersteund worden.
dat was dus mijn fout, ik heb zelf 64-bits IE opgestart.. na tijdje surfen was ik dit vergeten, toen ik uitkwam op youtube en deze deed het niet ging ik er automatisch vanuit dat het aan IE zelf lag..
Het beste zou zijn, om iedere licentie van windows 7 gewoon recht te geven op of 32 of 64 bit. Dat wil dus zeggen, de licentie nemer zou zelf moeten kunnen kiezen of hij de 32bit versie of de 64bit versie wil installeren. Nu worde oems meestal geleverd met vista 32bit terwijl ze zelfs 4gb ram hebben (het voordeel bestaat nog, want dual channel), wil de gebruiker toch 64 bit windows, dan kan hij als nog dokken...

Wat een problemen toch, als we nu eens allemaal GNU/Linux of BSD zouden gebruiken...
Het beste zou zijn, om iedere licentie van windows 7 gewoon recht te geven op of 32 of 64 bit
Je bedoelt zoals met all 32 bits Vista retail versies al het geval is ?
http://www.microsoft.com/...3/ordermedia/default.mspx
Oh, dan ben ik dus slecht geïnformeerd :). Maar mijn punt blijft wel staan (denk ik toch): Als 32bit oem versie geleverd wordt moet ge toch zelf nog een nieuwe licentie kopen (die dus blijkbaar wel 64bit kan).
nee, met de "32bits" key, kan je nadat je van de buurman de 64bits dvd geleend hebt de 64bits dvd lenen (of je download je de 64bits dvd), het gaat toch of de code legaal is, en omdat je kan overleggen dat je een legale versie GEKOCHT hebt is dat geen probleem :)
De "echte" grote oems leveren beide.

Men net nieuwe laptop van HP geeft tijdens de eerste start een keuze tussen Vista 32/64 en NLD/ENG.
De Atom notebooks zijn 32 bits. Je moet nu XP draaien omdat Vista-32 al te zwaar is. Windows 7 gaat op dieet, maar zelfs dan nog heeft Win7-x64 vele geheugen nodig - in elk geval meer dan Win7-32. Atom notebooks hebben dus om 2 redenen Win7-32 nodig.
Niet het besturingssysteem maakt dat de overstap gemaakt gaat worden, maar de software die de gebruiker gekocht heeft of nog moet kopen. Dan kan je OS 64bit zijn, maar de meeste van mijn pakketten draaien er simpelweg niet op. Ik heb dus een dubbelboot draaien, en zie het helaas niet gebeuren dat de software-giganten ook overgaan. Helaas...

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True