Ed eccoci alla prima risoluzione di problemi con Windows 7.

Il client VMware per accedere ad una infrastruttura Vsphere 4.x … non funziona su Windows 7 (e fa girare le palle il fatto che invece su Windows Vista funziona correttamente).  L’errore riportato è relativo al formato del file xml di connessione.

Il problema è noto a VMware, che sembra non abbia messo ancora a punto una versione patchata, ed è causata da una diversa versione del file System.dll installato nel Framework .NET di Windows 7.

Per risolvere il problema dovete fare quanto segue:

• Da una macchina NON Windows 7, andate a copiarvi il file System.dll che trovate nella directory %systemroot%\Microsoft.NET\Framework\v2.0.50727
• Ora, sulla macchina Windows 7, andate nella cartella c:\Program Files(x86)\VMare\Infrastructure\Virtual Infrastructure Client\Launcher e create una sottocartella con il nome “lib” (senza virgolette)
• Copiate il file System.dll che avete prelevato dalla macchina NON Window 7, dentro questa nuova cartella.
• Avviate ora Notepad (con privilegi di Amministratore) ed aprite il file C:\Program Files(x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe.config ed inserite esattamente le seguenti righe prima del tag di chiusura </configuration>:
   
  <runtime>
  <developmentMode developerInstallation=”true”/>
  </runtime>
   
• Salvate il file
• Create ora una nuova variabile di ambiente:
  DEVPATH=C:\Program Files(x86)\VMare\Infrastructure\Virtual Infrastructure Client\Launcher\lib
   
• Riavviate il pc con Windows 7
• Eseguite il client VMWare.

Da un paio di giorni mi è stato recapitato da Dell il pacchetto gratuito di aggiornamento a Window 7. Avevo infatti acquistato un laptop in dicembre (un bell XPS Studio 1340) che aveva Vista precaricato: ho potuto quindi beneficiare dell’upgrade gratuito a Windows 7.

L’installazione è andata abbastanza bene: c’è ancora una periferica non riconosciuta nonostante abbia montato tutti i nuovi driver Dell che mi sono stati recapitati in un CD allegato. Purtroppo, dato che era nelle mie intenzioni valutare Windows 7 per decidere se fosse opportuno fare l’upgrade anche sul fisso (dove ho ancora Vista), sono rimasto deluso. Non perchè Windows 7 non funzioni … anzi. Il fatto è che funziona come Vista o, se dei miglioramenti ci sono stati, non giustificano certo, a mio modestissimo modo di vedere le cose, L’ASSURDO ESBORSO DI OLTRE 280 EURO che mi chiedono.

Se è vero che, come molti dicono, Windows 7 è un Vista che funziona, dovrebbero farlo pagare pochi Euro e mandarti pure un biglietto di scuse per averti fatto perdere tutto quel tempo per cercare di rendere Vista utilizzabile. Eh già … perchè alla fine, dopo smanacciamenti nel registro, aggiustamenti di valori di cache nel file system, sistemazione parametri nei driver e compagnia bella, Vista funziona, come Seven. Solo che Seven funziona out-of-the-box, mentre con Vista dovrete perderci del tempo.

Tradotto … ti facciamo pagare perchè ti diamo già su un DVD quello che è stato il lavoro di milioni di utenti che, gratuitamente, hanno fatto da betatester e da cavie. Mannaggia …

Non ho trovato nulla di eclatante in Seven … tale da richiedere l’aggiornamento del mio vecchio Vista: il file system è lo stesso, IIS è lo stesso, il supporto Wireless è lo stesso, il consumo di memoria uguale … probabilmente con l’uso scoprirò nascoste preziosità-

Altro sfogo.

Graziosamente, mamma Microsoft, di tanto in tanto si diletta a “togliere” da sotto i piedi di collaudati impianti di rete, importanti caratteristiche. Proprio recentemente alcuni client “ospiti” di una rete, il cui accesso ad Internet è gestito e protetto da Squid + DansGuardian ( installati su un server Linux con autenticazione degli utenti tramite NTLM ), dotati del nuovissimo Windows 7, fallivano sistematicamente l’autenticazione e venivano bloccati nella navigazione (che invece con le stesse credenziali era garantita ai guest XP e Vista).

La soluzione per ovviare al problema è attivare in Windows 7 il livello di compatibilità NTLM V1 e V2.

1. Sulla macchina Windows 7 avviare Regedit (con privilegi di amministratore)
2. Navigare alla chiave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Controllare che esista la chiave LmCompatibilityLevel. Se non esiste create la chiave di tipo DWORD.
4. Modificate il valore della chiave LmCompatibilityLevel al valore 1
5. Chiudete regedit
6. Riavviate il pc con Windows 7

Per riferimenti su cosa significhi questa chiave potete trovare informazioni sulla Technet Microsoft.

Grazie Rob per la segnalazione.

Mentre sto attendendo che il corriere consegni il pacchetto di Dell con il quale dovrei ricevere l’upgrade gratuito a Windows 7, ho voluto fare una ricerchina per vedere se l’annoso problema di una lentezza mostruosa nella copia dei file via rete sperimentata già con Vista fosse stato risolto.

Con mia grande sorpresa … no !!

Inserendo in Google i classici termini “slow network copy Windows 7″ si trovano ancora decine di migliaia di post irrisolti, inseriti da persone ormai disperate, il più delle volte arrese. Eppure questo secondo approfondimento ha portato i suoi frutti. Ho trovato una soluzione, illustrata per Windows 7, che, almeno per la mia configurazione, ha risolto il problema. Consideratelo quindi come un ulteriore tentativo di porre rimedio ad una delle tante annoyances di Windows Vista : non ne cercherò altri perchè, ripeto, ora finalmente la copia dei miei file anche di grandi dimensioni con Vista ( e spero anche con 7 ) funziona a velocità cristiane.

Ecco dunque come procedere (Windows Vista)

1. Se avete UAC (Controllo Accesso Utente) abilitato, assicuratevi di aprire un prompt di comando (cmd) con privilegi di amministratore;
2. Digitate il comando netsh int ip show offload Dovrebbe apparire un output simile al seguente: Interfaccia 1: Loopback Pseudo-Interface 1
Interfaccia 7: Connessione alla rete locale (LAN)
Checksum ipv4 transmit supportato.
Checksum udp transmit supportato.
Checksum tcp transmit supportato.
LSO tcp supportato.
Checksum ipv4 receive supportato.
Checksum udp receive supportato.
Checksum tcp receive supportato.

3. Ovviamente i numeri di interfaccia potrebbero cambiare.
4. Digitate ore il comando : netsh int ip set global taskoffload=disabled. Come unico output dovreste ricevere un OK.
5. Dal menu Start eseguite ora : ncpa.cpl (viene avviata l’applet di gestione delle connessioni di rete)
6. Sulla vostra connessione di rete (fatelo su tutte se ne avete più di una) cliccate con il bottone di destra e quindi scegliete Disabilita. Attendete che la disconnesione di rete sia completata e poi subito riabilitatela (clic destro -> Abilita)
7. Ora tornate al prompt di comando precedente e digitate di nuovo : netsh int ip show offload. Questa volta, a parte l’elenco delle interfacce, non dovrebbe apparire alcun messaggio di stato.
8. Molto bene. Provate ora ad eseguire una copia di un file corposo (un centinaio di mega) da o verso una condivisione di rete remota. Finalmente una velocità degna di questo nome (almeno per me … yuppiee).

Trovandosi a scegliere la migliore versione per Windows per il nostro computer, ci si imbatte, non ultimo, nella scelta tra un’architettura a 32 bit o a 64 bit. La percezione comune, purtroppo sbagliata, vuole che le versioni a 64bit dei sistemi operativi abbiano performance comunque superiori a quelle degli omologhi a 32 bit. Non è così: in linea generale è molto difficile apprezzare significativi aumenti di prestazioni nell’architettura a 64bit rispetto a quella a 32. E per di più potrebbero esserci delle implicazioni negative nell’adottare le versioni x64 di Windows Vista e Windows 7.

L’architettura a 64 bit è la naturale evoluzione di quella a 32 ma il suo sviluppo non ha mai avuto come obiettivo primario quello dell’aumento delle prestazioni: al contrario lo “scoglio” da superare era (ed è) quello della limitazione fisica nell’accesso allo spazio degli indirizzi di memoria utilizzabili. Per le architetture a 32 bit il limite superiore è 2^32 ovvero 4.294.967.296 (poco più di 4Gb). Limite per altro teorico perchè la quantità di memoria realmente disponibile per le applicazioni viene ridotta della quantità riservata alle periferiche su piastra motivo per cui in un sistema a 32 bit l’utente non avrà mai a disposizione 4GB pieni. Con l’architettura a 64 bit questo limite viene spostato sensibilmente in alto (2^64 = 18.446.744.073.709.551.616) rendendo disponibili spazi di indirizzi di memoria che verosimilmente (dati i valori esposti) non costitueranno un limite per un bel pezzo di tempo.

Ovviamente questa ampliata disponibilità può avere un impatto rilevante sulle prestazioni del nostro computer ma bisogna fare delle considerazioni. Tutti sappiamo che avere più RAM a bordo significa aumento delle prestazioni perchè così il sistema riesce a tenere in RAM i dati di più processi simultanei senza ricorrere al paging su disco. Se però si monta un sistema a 64 bit su un PC con meno di 4GB di RAM fisica è evidente che, anche potendo accedere ad indirizzi superiori ai 4GB, la RAM fisica oltre i 4GB non c’è quindi, giocoforza, il sistema operativo swappa su disco perdendo quindi ogni vantaggio. In queste condizioni appare chiaro che non è più l’architettura a 64 bit che può aumentare le nostre prestazioni quanto piuttosto, nel caso specifico, un hard-disk molto veloce. Al contrario, avendo a disposizione oltre 4GB di Ram, verrà consumato un minore numero di cicli per il roll-out / roll-in dei dati inRAM quando si passa da un processo all’altro.

Un’altra considerazione da fare è relativa a quali ambiti applicativi possono avvantaggiarsi dall’adozione di un sistema operativo a 64bit :

• Ovviamente hardware che dispongono di oltre 4Gb di ram
• Applicazioni che richiedono calcoli matematici in virgola mobile
• Applicazioni che utilizzano ampi database ad elevate performance
• Acquisizioni video o di analisi che richiedono trasferimento di grandi quantità di dati in memoria RAM ad alta velocità

Anche in queste condizioni comunque NON sempre un sistema operativo Windows a 64 bit può risultare più veloce di un omologo a 32bit.

• Il maggior numero di indirizzi “visibili” da parte del kernel è comunque un aggravio di informazioni da gestire
• I programmi applicativi a 32 bit avranno comunque un degrado di performance in quanto “girano” in uno strato di emulazione (WoW64 = Windows On Windows 64) che traduce le istruzioni a 32 bit in istruzioni a 64 bit. Ovviamente questo strato di emulazione rallenta il processo. L’applicazione a 32 bit “crede” di trovarsi all’interno di un sistema 32 bit ma in realtà è come se girasse (molto grossolanamente) dentro a VirtualPc o VirtualBox.

Ad aggravare il tutto ci si è messa la Microsoft che per le sue versioni a 64 bit di Windows 7 e di Vista richiede obbligatoriamente che i driver siano firmati elettronicamente (adducendo come giustificazione – sensata per altro – della necessità di un aumento di stabilità del sistema) : questo può comportare dei problemi per esempio a quegli utenti che, pur dotati di oltre 4GB di ram, hanno a bordo periferiche ancora valide ma per le quali i produttori non hanno ancora rilasciato versioni ufficiali dei propri driver per 64 bit.

In funzione di quanto sopra emerge un altro aspetto non trascurabile: il confronto di prestazioni tra un sistema a 32 bit ed uno puro a 64 bit è un esercizio senza significato. Bisogna tenere infatti presente che driver e programmi sono DIVERSI e spesso i produttori nella ricompilazione a 64bit li ottimizzano

Nella ricerca quindi delle migliori prestazioni il tipo di architettura è sicuramente uno degli elementi discriminanti ma non certo il più importante: ancora l’hardware è il pilastro portante delle scelte facendoci preferire ampie disponibilità di RAM, dischi molto veloci e processori multicore.