Desktop fileCon sistemi x64

Wes Miller

Windows XP è disponibile in modalità nativa per le architetture a 64 bit da oltre cinque anni. A meno di non essere tra i primi ad aver adottato il processore Itanium di Intel (Windows XP per Itanium è stato messo sul mercato lo stesso giorno di Windows XP), è probabile che se ne sia avuta notizia solo di recente con la disponibilità delle versioni di Windows XP e Windows

Server 2003 per i sistemi x64. x64, a volte definito anche x86-64, è il nome generico per le architetture AMD64 di AMD e EM64T di Intel. Se si è acquistato un computer nuovo nell'ultimo anno, è molto probabile che contenga un processore a 64 bit, anche se utilizzato solo a 32 bit (come nella stragrande maggioranza dei casi).

Oggi lavoro per una piccola azienda di Austin, in Texas. Data l'architettura di uno dei nostri prodotti, siamo interessati a sfruttare i vantaggi molto specifici offerti dall'architettura x64, come è già successo al team Microsoft ® Exchange 2007, che ha avviato una piccola rivoluzione iniziando a distribuire solo prodotti per l'architettura x64. Allo stesso modo il team di sviluppo e test che gestisco si è concentrato esclusivamente sulle versioni x64 di Windows® XP e Windows® Server 2003 per workstation di sviluppo, computer portatili, server e server di produzione. Inoltre, utilizzo Windows XP Professional x64 Edition sul mio computer portatile per sottoporre a test ed eseguire il debug del nostro prodotto.

È interessante che la prima risposta che ottengo dalla maggior parte delle persone quando accenno all'utilizzo di Windows a 64 bit, soprattutto su un sistema mobile, è uno sguardo piuttosto confuso. Se l'interlocutore conosce bene l'elaborazione a 64 bit, l'espressione riassume un'incredulità mista a nausea e sorpresa. Il motivo che sta alla base di queste reazioni, è la diffusa convinzione che sia molto difficile trovare tutti i driver di dispositivo necessari per i sistemi a 64 bit. In questo articolo spiegherò come e perché utilizzo Windows XP e Windows Server 2003 su sistemi x64 nella modalità a 64 bit e descriverò alcuni dei vantaggi (e dei possibili ostacoli) della distribuzione. Esaminerò anche gli aspetti del supporto, della migrazione e della distribuzione di Windows Vista™ x64.

Un po' di storia

Come già accennato, l'origine del supporto a 64 bit per Windows è iniziato con il supporto per il processore Itanium di Intel (sebbene fosse disponibile una versione per processori Alfa a 64 bit, Windows non era mai effettivamente a 64 bit quando eseguito su Alfa). In Windows XP e Windows Vista non è previsto alcun supporto per Itanium, quindi l'architettura x64 è attualmente il punto di riferimento per l'elaborazione dei client Windows a 64 bit. È disponibile una gamma più ampia di edizioni di Windows Server 2003 per x64 che per Itanium (che è stato sostanzialmente rilegato ai carichi di lavoro intensivi dei centri dati), una tendenza che probabilmente continuerà con la prossima versione di Windows Server, nome in codice "Longhorn".

Il supporto per Windows sulla piattaforma x64 è diventato disponibile con la pubblicazione di Windows Server 2003 Service Pack 1 (SP1). Sebbene potesse generare qualche confusione, questo momento coincide con la disponibilità della versione x64 di Windows XP, quindi con prodotti Windows XP a 32 bit e a 64 bit che derivavano da strutture di codice diverse all'interno di Windows. Mentre per i prodotti a 32 bit è disponibile un secondo service pack, per la versione a 64 bit di Windows XP tecnicamente parlando non esiste alcun service pack (anche se si potrebbe dire che integra già il SP1 per Windows Server 2003).

Per l'utilizzo di un qualsiasi Windows a 64 bit, ovvero Windows XP, Windows Server 2003, Windows Vista o Windows Server "Longhorn", i requisiti restano sempre gli stessi. È ovviamente necessario disporre di un processore a 64 bit. Nel caso di AMD significa aver acquistato un sistema single, dual o quad-core con compatibilità AMD64 (vedere amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html). Per Intel, significa aver acquistato un sistema single, dual o quad core con supporto per EM64T o architettura Intel 64 (vedere intel.com/technology/intel64). È importante sottolineare i dettagli. Un sistema Intel Core Duo, ad esempio, non è a 64 bit. Un sistema Intel Core 2 Duo è invece a 64 bit, ma è possibile che venga denominato semplicemente Centrino Duo (come nel caso del mio computer portatile).

Vivere con x64

Una volta determinato se il sistema supporta in modalità nativa una versione a di Windows 64 bit, è necessario occuparsi del supporto dei dispositivi. Purtroppo, per quanto Microsoft abbia sollecitato produttori e OEM (con almeno due anni di sessioni di WinHEC) a creare e certificare driver a 64 bit per i rispettivi dispositivi e sistemi, il problema maggiore da affrontare quando si decide di utilizzare un Windows x64 è il reperimento dei driver per l'hardware o il software. In base alla mia esperienza non esistono soverchie difficoltà nell'utilizzare un sistema operativo x64 su un server con un supporto di dispositivi limitato.

È invece più difficile trovare i driver per i sistemi desktop e portatili. In genere è più facile trovare tutto il necessario per i sistemi prodotti dai principali OEM del mercato o per un sistema creato con componenti di livello aziendale (poiché la probabilità che il sistema venga utilizzato in ambito aziendale spinge produttori o OEM a creare e firmare dei driver per x64).

Per Windows Vista, la situazione è molto migliore. In questo caso, a un mondo in cui x86 è l'architettura preferita mentre x64 è l'architettura ignorata, con driver a disponibilità limitata per la maggioranza dell'hardware, si contrappone il mondo del nuovo sistema operativo. Per Windows Vista, un produttore di dispositivi deve presentare i driver per x64 per ottenere una verifica di compatibilità. Non è infatti necessario includere i driver x86, sebbene sia ovviamente possibile. Teoricamente questo significa che alcuni dispositivi hardware, soprattutto i dispositivi che sfruttano le nuove funzionalità di Windows Vista, potrebbero supportare solo Windows x64 e non x86.

In realtà i driver sono solo uno dei problemi da affrontare quando si tenta di eseguire Windows a 64 bit in modalità nativa. Il problema maggiore consiste nel riuscire a implementare (o eseguire la migrazione verso) il nuovo sistema operativo, ma questo è un argomento che verrà affrontato in seguito.

Perché a 64 Bit?

AMD, Intel e Microsoft hanno deciso di passare a un'architettura a 64 bit a ragion veduta. Il passaggio ai 64 bit offre diversi vantaggi importanti. Come è possibile notare nella Figura 1, il miglioramento più importante garantito dall'architettura x64 è la capacità indirizzare molta più memoria: fino a 16 terabyte (TB) rispetto ai 4 GB di Windows a 32 bit. È importante sottolineare che, mentre i puntatori a 64 bit possono indirizzare fino a 16 TB, le applicazioni possono accedere solo a un massimo di circa 8 TB.

Figure 1 Limiti dello spazio degli indirizzi di memoria

Spazio degli indirizzi Windows a 64 bit Windows a 32 bit
Memoria virtuale 16 TB 4 GB
File di paging 512 TB 16 TB
Pool di paging 128 GB 470 MB
Pool non di paging 128 GB 256 MB
Cache di sistema 1 TB 1 GB

Inoltre, le versioni x64 di Windows consentono di sfruttare anche la Protezione esecuzione programmi (DEP) basata sull'hardware, disponibile anche sui sistemi x86 con il supporto NX (No Execute). Si tratta di una soluzione basata sull'hardware utilizzata da Windows per evitare gli overflow del buffer impedendo l'esecuzione di codice dalle pagine di dati in memoria. Per ulteriori informazioni su quest'argomento, vedere support.microsoft.com/kb/875352.

Le versioni x64 di Windows prevedono il supporto nativo di CPU multiprocessore o multicore, proprio come le versioni x86 di Windows. Una delle maggiori complessità per la creazione di immagini di un sistema Windows XP viene però eliminata con l'utilizzo di un unico Hardware Abstraction Layer (HAL) per tutte le installazioni di Windows x64. Non è più necessario lottare per identificare l'HAL in uso nei sistemi non ACPI o a CPU singola.

Windows x64 come architettura consente di utilizzare l'infrastruttura di gestione esistente e il software a 32 bit già disponibile (tramite l'emulazione), oltre al software a 64 bit con la possibilità di accedere agli importanti miglioramenti illustrati in termini di memoria. In effetti, gli unici effetti collaterali spiacevoli del passaggio a Windows x64 sono: assenza completa di supporto per applicazioni a 16 bit (compresi i trucchi come le applicazioni a 32 bit con programmi di installazione a 16 bit); problemi con le applicazioni che non vengono eseguite in modo attendibile quando si attiva la DEP hardware (sebbene sia possibile disattivare DEP per singoli processi e il team di Windows Application Compatibility stia risolvendo i problemi di alcune applicazioni che non vengono eseguite correttamente con DEP attivata); infine, in Windows Vista a 64 bit, tutti i driver devono essere firmati.

Quest'ultima voce è stata aggiunta per migliorare la difesa contro la manomissione del kernel di Windows in memoria, una tecnica spesso utilizzata dai rootkit. Dal momento che, nelle intenzioni di Microsoft, x64 è l'architettura per cui i produttori devono sviluppare i driver per primi (per ottenere la certificazione di qualità dell'hardware di Windows), questo non è il requisito problematico che sarebbe stato in passato.

Quando si pensa a una migrazione a un sistema x64, è necessario prendere in considerazione un altro paio di punti. Non esistono versioni di Windows XP per sistemi x64 che contengano le funzionalità disponibili in Windows Media® Center Edition o Windows Tablet PC Edition. Tuttavia, questo non è vero per Windows Vista, dove le versioni x64 di Windows hanno le stesse funzionalità delle versioni x86.

Virtualizzazione

Una caratteristica non ancora menzionata è la virtualizzazione. Non mi riferisco ai prodotti di virtualizzazione come Microsoft Virtual PC o VMWare, ma alla virtualizzazione del sistema operativo per gli eseguibili a 32 bit. Nelle versioni a 32 bit di Windows le applicazioni a 16 bit venivano tutte eseguite nel contesto di NTVDM, una macchina virtuale MS-DOS®. Come già anticipato, nelle versioni a 64 bit di Windows non è previsto il supporto per applicazioni a 16 bit. Inoltre, mentre i componenti più integrati di Windows vengono eseguiti in modo nativo come binari 64 bit, alcuni componenti e molti programmi di terze parti vengono eseguiti come applicazioni a 32 bit.

Windows dispone di un livello di emulazione del tutto nuovo, denominato Windows On Windows (WOW), che consente di eseguire le applicazioni a 32 bit in una versione effettivamente a 32 bit di Windows. Sotto WOW, le applicazioni x86 vedono Programmi (x86) semplicemente come Programmi. Allo stesso modo, %WINDIR%\SysWOW64 viene rilevato dalle applicazioni x86 come %WINDIR%\System32. Le applicazioni x86 vedono la chiave del Registro di sistema HKLM\SOFTWARE\Wow6432Node come fosse il nodo HKLM\SOFTWARE.

Con lo strumento Process Explorer è possibile notare un'altra peculiarità della virtualizzazione. Poiché molte applicazioni a 32 bit sono progettate per interagire con i binari a 32 bit integrati in Windows, molti di tali binari sono disponibili in entrambe le versioni a 64 e 32 bit. È possibile notare questa specificità del nuovo sistema operativo aggiungendo una colonna in Process Explorer. Nella Figura 2 è possibile notare due istanze di cmd.exe, una versione a 32 bit e una a 64 bit. Inoltre, nell'istanza a 32 bit evidenziata, è possibile notare alcune DLL wow64* caricate nel processo a 32 bit. Queste dimostrano che è in corso una virtualizzazione, che consente alle applicazioni a 32 bit di funzionare sotto un sistema operativo Windows a 64 bit. Notare infine la directory di lavoro (percorso) utilizzata dalle versioni di cmd.exe a 64 e a 32 bit.

Figura 2 Process Explorer rivela le versioni a 32 bit e a 64 bit di cmd.exe

Figura 2** Process Explorer rivela le versioni a 32 bit e a 64 bit di cmd.exe **(Fare clic sull'immagine per ingrandirla)

Una considerazione finale sull'argomento della virtualizzazione: Windows esegue explorer.exe come applicazione nativa a 64 bit e questa caratteristica propone vantaggi e svantaggi. Lo svantaggio principale consiste nella necessità di ricompilare le eventuali estensioni della shell di explorer.exe per l'architettura x64.

Per Internet Explorer®, che per impostazione predefinita viene eseguito in modo nativo con la versione a 32 bit, è vero il contrario. In tal modo si è voluto salvaguardare il corretto funzionamento dei tanti controlli Activex® già disponibili su Internet. In caso contrario, poiché le applicazioni a 64 bit non caricano DLL o driver a 32 bit, non vi sarebbe modo di caricare i controlli Activex a 32 bit, che comprendono quasi tutto i controlli Activex attualmente disponibili, in un browser a 64 bit, con il risultato che una buona parte del contenuto Internet resterebbe inaccessibile. Per un esempio pratico, provare a caricare C:\Programmi\Internet Explorer\iexplore.exe in un sistema Windows a 64 bit e visitare un qualunque sito che preveda il caricamento di un controllo Activex (anche Windows Update). Il risultato sarà un'operazione non riuscita a vari livelli. Windows Update (vedere la Figura 3) ora è stato aggiornato in modo da aprire un'istanza a 32 bit di Internet Explorer in questa situazione. In futuro, verrà di certo sviluppato del contenuto di controlli Activex aggiornati in modo da sfruttare i vantaggi offerti da Internet Explorer a 64 bit, ma con la maggioranza di sistemi Windows che oggi utilizzano esclusivamente Windows a 32 bit, non si sente la necessità di aggiornare i contenuti dei controlli Activex. È difficile immaginare che la situazione cambi in tempi brevi.

Figura 3 Operazioni non riuscite dei controlli Activex a 32 bit in Internet Explorer a 64 bit

Figura 3** Operazioni non riuscite dei controlli Activex a 32 bit in Internet Explorer a 64 bit **(Fare clic sull'immagine per ingrandirla)

Windows x64 in Pluck

Ho anticipato all'inizio di questo articolo che in Pluck abbiamo iniziato la transizione a Windows x64. La transizione ha interessato tre versioni diverse di Windows: Windows XP Professional x64 Edition, Windows Server 2003 Enterprise Edition x64 e Windows Vista x64.

La nostra organizzazione è abbastanza piccola da sopportare l'improvvisa migrazione a Windows x64 non appena è iniziato lo sviluppo del nostro prodotto più recente, per approfittare dei vantaggi offerti dal sistema operativo. Per una migrazione corretta e completa, è stato necessario accertarsi che tutto il nuovo hardware ordinato fosse compatibile con l'architettura x64. Infatti, sono proprio le funzionalità espanse di gestione della di memoria dell'architettura x64 unite alla virtualizzazione che ci consente di eseguire il nostro prodotto nel modo desiderato. Tutti i server fisici vengono utilizzati come server a 64 bit virtuali su un server host a 64 bit. Ciascun server host dispone di 16 GB di RAM divisa tra i server virtuali ospitati (in genere 2 GB per ciascuna macchina virtuale o VM di gestione temporanea e 3 GB per ciascuna VM di produzione).

Con l'utilizzo di sistemi di livello 1 e di hardware virtualizzato, siamo in grado di ottenere un supporto dei dispositivi prossimo al 100%. Nel mio computer portatile, ad esempio, sono presenti tre periferiche che non dispongono di driver per x64. Sembra trattarsi di dispositivi di tipo backplane non critici e il sistema funziona bene anche senza. È interessante notare che un'installazione di Windows Vista RC1 x64 ha prodotto esattamente lo stesso supporto dei dispositivi. Mi aspetto tuttavia che arriveranno molto presto anche questi driver per il mio sistema con il logo Windows Vista Capable.

Poiché il nostro uso dei sistemi si limita principalmente a Microsoft Office, Visual Studio® e ad alcuni strumenti aggiuntivi utilizzati per i processi di sviluppo e generazione, non abbiamo molte applicazioni legacy che possano provocare problemi di compatibilità durante la migrazione. Mentre una parte importante della nostra organizzazione utilizza ancora versioni di Windows a 32 bit, abbiamo iniziato la migrazione a 64 bit con dell'hardware nuovo e il passaggio è stato relativamente indolore.

Distribuzione e migrazione verso x64

È necessario sottolineare alcuni aspetti relativi alla distribuzione. Microsoft fornisce una versione di Windows Preinstallation Environment (Windows PE) specifica per l'architettura x64. Tuttavia, poiché nei sistemi x64 persiste la parità x86, in alcuni casi è preferibile utilizzare la versione x86 di Windows PE per la distribuzione, specialmente se si utilizza una soluzione di imaging. Quando si distribuisce Windows XP utilizzando l'installazione automatica, è necessario che Windows PE sia specifico per l'architettura, come winnt32.exe deve essere eseguito sotto la medesima architettura oggetto della distribuzione. Poiché Windows PE non dispone di un livello di compatibilità a 32 bit e winnt32.exe sotto x64 è un'applicazione a 64 bit, per Windows a 32 bit è necessario utilizzare Windows PE a 32 bit. Lo stesso vale per le versioni a 64 bit di Windows, per le quali è necessario utilizzare Windows PE a 64 bit.

Da questo punto di vista Servizi di installazione remota (RIS) si comporta in modo diverso, ed è per questo che in Pluck utilizziamo RIS. RIS, a partire da Windows Server 2003 SP1, è in grado di distribuire architetture di Windows x64, x86 o Itanium. Quando un sistema x64 si connette a un server RIS, il server (nella configurazione predefinita) offre immagini RISetup o RIPrep x86 e x64. È possibile configurare RIS anche in modo da offrire ai client x64 solo immagini x86 o solo immagini x64. La scelta viene offerta come predefinita per garantire una migliore gestione con l'hardware x64.

Non si è ancora detto degli aggiornamenti e per una buona ragione. Purtroppo, l'aggiornamento di un intero sistema operativo da x86 a x64 è una vera impresa. Per questo motivo, e data la distribuzione limitata di Windows XP Pro x64 Edition, non è possibile eseguire l'aggiornamento a Windows XP x64 da una qualsiasi versione x86, né è possibile eseguire l'aggiornamento da una versione di Windows XP (x86 o x64) a Windows Vista x64. Windows Vista su sistemi x64 è concepito, come già in precedenza Windows XP Pro x64 Edition, come un prodotto per la sola installazione pulita. Per questo motivo, in molte organizzazioni la migrazione a x64 viene presa in considerazione solo quando è previsto un aggiornamento generale dell'hardware aziendale. Una strategia simile a quella che, si prevede, verrà adottata da molte organizzazioni per Windows Vista in generale (il doppio salto sembra quasi logico in questo caso).

Ma ciò non significa che le persone o le organizzazioni che intendono passare da un Windows x86 a un Windows x64 non possano disporre di strumenti facilmente reperibili. Le versioni di Utilità di migrazione stato utente (USMT) per Windows XP e per Windows Vista sono state entrambe estese per supportare la migrazione (rispetto a un aggiornamento in-band del sistema operativo) da un'installazione di Windows a un'altra. Questo è il metodo più utilizzato oggi nelle organizzazioni per distribuire Windows, anche su uno stesso computer, e l'utilizzo dello stesso meccanismo per passare a un Windows sotto un'architettura interamente nuova non dovrebbe presentare un più ostacoli di prima.

Conclusioni

Nonostante la migrazione graduale a x64 della nostra piccola organizzazione possa presentarsi decisamente più facile rispetto al complesso processo di migrazione delle organizzazioni più grandi, è opportuno che tutti i professionisti IT prendano in considerazione il passaggio all'architettura x64. La realtà è che, sebbene l'architettura x86 e le versioni native x86 di Windows resteranno in circolazione per i prossimi dieci anni, l'architettura x64 rappresenta certamente il futuro dell'informatica aziendale. Con il completamento del passaggio di Microsoft alle funzionalità dell'architettura x64 con Exchange Server e altri prodotti, si inizierà a capire quali sono i settori aziendali in cui l'architettura x64 si adatta meglio al preesistente. Sarà anche più facile decidere l'eventuale integrazione di questa migrazione con il passaggio a Windows Vista, indipendentemente dall'utilizzo corrente di Windows XP o Windows Server 2003 in modo nativo sui sistemi x64 esistenti.

Wes Miller è Development Manager presso Pluck (www.pluck.com) ad Austin, Texas. In precedenza ha lavorato a Winternals Software e a Microsoft in qualità di program manager e product manager per Windows. È possibile contattarlo all'indirizzo technet@getwired.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.