Inside the Windows Vista Kernel: Part 3

E’ uscito l’ultimo articolo di Russinovich riguardante il kernel di Vista:

http://www.microsoft.com/technet/technetmag/issues/2007/04/VistaKernel/default.aspx

Buona lettura.

Altro hardware e software provati

Intanto HP ha rilasciato un “basic” driver per lo scanner HP4600 che utilizzo a casa. In pratica permette l’utilizzo dello scanner dal programma di gestione dei fax e degli scanner fornito con Vista.

Il Symantec Corporate Antivirus funziona bene: ovviamente occorre utilizzare la versione apposita per Vista.

Con la calcolatrice HP 49G+ invece occorre scaricare il software aggiornato dal sito HP. Una volta installato questo crea una sottodirectory nella directory di installazione con il driver USB. A questo punto si collega la calcolatrice e si installa il driver indicando al wizard dove cercarlo.

Infine, ma non è una novità, l’ultima versione del player DivX sembra funzionare senza problemi.

Webcast di introduzione tecnica su Vista

Oggi ho tenuto il famoso webcast di introduzione tecnica su Vista. Parlare di tutto quello di cui ho parlato in soli 45 minuti è una impresa! Come ho detto ho anche trascurato molti argomenti che dovrebbero essere trattati. Comunque l’obiettivo era dare una idea delle possibilità e mi sembra di esserci riuscito. Per chi non lo avesse seguito è possibile vedere il webcast in differita sempre collegandosi al sito dello IAL.

Nei prossimi giorni mi passeranno la lista delle domande e io con calma risponderò sempre su questo blog. Alcune di queste domande erano interessanti e avrebbero meritato una risposta più articolata ma il tempo è tiranno.

Intanto a chi mi ha seguito indico alcuni link a post precedenti:

• Sul DRM leggete Vista e DRM.
• Sulla grafica leggete Apparire o essere.
• In generale sulla GUI leggete tutti i post su Vista UX.

E’ uscito il SP2 di Windows 2003

E cosa c’entra con un blog su Vista, voi direte? Niente a parte il fatto che sono state introdotte in 2003 alcune funzionalità già presenti in Vista. Si trova qui.

Lento? Ma quando?

A suo tempo quando la mia azienda programmava in C++, io e il mio socio eravamo impegnati in un progetto che aveva un tempo di sviluppo/consegna previsto di un anno. Effettuammo quindi dei test per capire se Java era accettabile in termini di prestazioni in un ambiente enterprise (non era per fare applet). Il processore di punta Intel era un PentiumPro a 200 MHz. Fatti i test arrivammo a questa conclusione: Java era più lento ma grazie alla legge di Moore avremmo ottenuto delle macchine con prestazioni più che adeguate non rimpiangendo il codice C++. Mal che vada si poteva deviare su dei RS/6000. Non solo dopo un anno avemmo quelle macchine ma avemmo anche un nuovo garbage collector, un JIT e una virtual machine IBM assai più performante di quella Sun. In conclusione noi accelerammo i tempi di sviluppo ottenendo codice più corretto e più performante. E un ambiente più semplice da imparare per i neoassunti. E questi vantaggi ebbero una notevole ricaduta anche sul cliente finale. Dal quel momento, nonostante ne fossimo esperti, abbandonammo completamente il C++ come strumento principale di sviluppo per un una gran parte delle varie tipologie di applicazioni.

Oggi ero da un cliente e ho avuto occasione di chiaccherare con dei tecnici. Il discorso è caduto sulle prestazioni dei programmi .NET e Java. In pratica queste persone sostenevano che i programmi .NET e Java erano lenti.

Premettendo che i programmi scritti bene in C/C++ sono sicuramente più veloci e aggiungendo il fatto che i programmi scritti bene in assembler sono probabilmente ancora più veloci, qui mi sembra che sfuggano alcuni punti fondamentali che è bene ribadire.

Scrivere buon codice è difficile e costoso. La gestione corretta della memoria è probabilmente una delle attività più complesse e soggette ad errori. Se si riesce a fare in modo che sia il runtime a gestire la memoria si riesce ad eliminare di colpo una grande fonte di potenziali problemi. Gli ambienti di esecuzione basati su VM (Virtual Machine) come quelli di Java, .NET, Smalltalk et similia gestiscono direttamente la memoria eliminando i puntatori e la allocazione/deallocazione esplicita. Quindi l’uso di questi ambienti semplifica la vita ai programmatori e ai tester, fa produrre codice migliore, rende i programmi meno costosi. Alla fine questi vantaggi ricadono sugli utenti.

Premesso questo io penso che i miglioramenti sarebbero evidenti anche a prezzo di un notevole rallentamento.

Ma questo notevole rallentamento non accade.

Java, .NET e anche alcune implementazioni di Smalltalk hanno dei sistemi di ottimizzazione del runtime. In particolare Java e .NET sfruttano dei compilatori JIT (Just In Time). I JIT analizzano il codice in esecuzione e lo compilano in codice nativo (vuol dire che su un Windows Vista a 32 bit viene generato codice per il processore x86). Questo accade durante l’esecuzione del programma. In altri termini se il programma rimane in memoria viene compilato man mano che viene eseguito (Just In Time appunto). Il trade-off quando questo accade è di solito una maggiore occupazione di memoria. E’ ovvio che se si scarica un programma (cioè se ne termina l’esecuzione) spesso, il JIT non ha modo di manifestare adeguatamente la sua presenza. Inoltre alcuni ambienti permettono persino di precompilare un programma e di memorizzare il codice in una cache o in un eseguibile. In questo modo il JIT è eseguito a priori come un normale compilatore. In .NET esiste un comando dell’SDK denominato NGEN che serve a questo. Infine si noti che .NET è usato anche per scrivere videogiochi sulla XBOX ed esistono implementazioni real-time di Java (J9 di IBM).

Parlare quindi oggi di lentezza delle VM è abbastanza fuori luogo, soprattutto in un momento in cui stanno anche tornando di moda i linguaggi dinamici. Chi è ancora ancorato al passato ne prenda finalmente atto e cominci ad agire di conseguenza. 

WIN32HLP per Windows Vista

Poco tempo fa raccontavo di una vecchia versione del IBM Personal Communications che aveva i file di help nel vecchio formato WIN32HLP deprecato da tempo. Microsoft ha rilasciato una versione dell’eseguibile per Vista in grado di visualizzare questi file. Lo trovate qua: http://www.microsoft.com/downloads/details.aspx?FamilyID=6ebcfad9-d3f5-4365-8070-334cd175d4bb&DisplayLang=en

Sicuro!

Dopo un po’ di mesi di lavoro con Vista e molti anni con XP e 2003 ho raggiunto una mia personale conclusione sulla sicurezza dell’ultimo nato: le tecniche usate in Vista sembrano renderlo molto sicuro.

Però se osserviamo le ultime vulnerabilità su XP a me sembra evidente un trend: non è il sistema operativo ad essere insicuro ma soprattutto le applicazioni (e fra queste metto IE6).  Sono le applicazioni che ti constringono a lavorare come amministratore. E le applicazioni spesso soffrono di vulnerabilità.

Vista rimedia a parecchi degli errori procedurali commessi nelle versioni precedenti dei sistemi operativi desktop (volutamente escludo i server perchè 2003 è molto sicuro). Per esempio introduce programmi a livello di privilegio basso, UAC, IE7 con sandbox, DEP, vari meccanismi di randomizzazione della RAM, firewall bidirezionale, un processo di sviluppo orientato alla sicurezza e altro ancora.

Tutto questo è utile ma non basta: ci sono in giro troppe applicazioni intrinsicamente non sicure.

La conclusione del mio discorso è questa: non basta pensare alla sicurezza dei sistemi operativi e della rete e non basta educare gli utenti. I bug accadono ma occorre pensare anche alla sicurezza delle applicazioni.

Quante delle vostre applicazioni che utilizzate sono sicure? E se create applicazioni quanto importante è la sicurezza nel vostro ciclo di sviluppo?

Vista UX: PowerShell

Anche se non strettamente legata a Vista (è in grado di funzionare anche su XP e 2003) è disponibile PowerShell, una nuova shell di comandi molto più potente del vecchio prompt (il CMD.EXE per intenderci). Un utente normale solitamente non utilizza una shell di comandi ma è comunque un elemento che ha a che fare con l’esperienza utente.

Prima di tutto occorre dire che il vecchio CMD.EXE non era così brutto come lo dipingevano molti detrattori. Nelle ultime versioni si era arricchito di notevoli funzionalità (tanto per provare digitate HELP FOR al prompt). E anche i comandi erano diventati parecchi. In pratica con il vecchio prompt si possono costruire file di comandi complessi.

La parte di scripting invece è sempre stata uno dei punti forti di Windows. Grazie al fatto che molte funzionalità dei sottosistemi erano esposte via interfacce COM/DCOM/ActiveX/ecc., è sempre stato possibile creare script molto complessi in grado di interagire con il sistema e le applicazioni usando svariati linguaggi (VBScript, Javascript, Perl, ecc.).

PowerShell è invece una shell che propone un modello nuovo di gestione del sistema. Prima di tutto occorre dire che la shell è progettata per essere usata in modo interattivo e via script. Supporta un modo uniforme di nominare i comandi, completition, history, file di comandi, funzioni, alias.

La shell è basata su .NET e quindi è in grado di manipolare oggetti. In effetti è object oriented. Si possono persino definire (e non solo istanziare) oggetti dinamicamente. Molti dei comandi sono uniformi tra oggetti diversi. Ad esempio il comando

Get-ChildItem

restituisce una lista di oggetti figli della locazione in cui ci si trova. In altri termini se vi trovate su C:\TEMP il comando restituisce una lista di oggetti file e directory contenuti in C:\TEMP. Alias di questi comandi sono DIR e LS (vecchie conoscenze). Se cambiate locazione così:

Set-Location HKLM:\SOFTWARE

e digitate

Get-ChildItem

allora vi viene restituita una lista di oggetti che rappresentano le chiavi del registry nella locazione HKEY_LOCAL_MACHINE\Software (notate: stessi comandi delle directory). Ovviamente potevate anche usare gli alias ad esempio in questo modo:

cd HKLM:\Software\Adobe
dir

Questi comandi mostrano il contenuto di una chiave del registry utilizzata dai programmi di Adobe.

Con questi semplici esempi è stato mostrato il concetto di provider per le unità. In pratica grazie a questi provider (e agli oggetti) è possibile lavorare su differenti “spazi” in modo uniforme. Ci sono provider per il file system, per le variabili di ambiente, per i certificati digitali e altro.

La caratteristica principale è però quella di lavorare ad oggetti. Per gestire in modo efficiente questi oggetti PowerShell introduce il concetto di pipe di oggetti. In UNIX il sistema implementa una pipe di caratteri. Per esemplificare prendiamo un comando del tipo:

ls -al | grep “^d”

mostra una lista di tutte le directory contenute nella directory corrente. Il tutto funziona perchè il comando ls emette il suo output su una pipe di caratteri. La pipe di caratteri viene poi usata come input dal programma grep che però opera sul testo. Sempre per esemplificare in PowerShell il comando

dir | where { $_.PSIsContainer }

mostra come il precedente una lista delle directory contenute nella directory corrente (provate a farlo su una directory del registry). La differenza è pero sostanziale. Il comando dir crea un pipe di oggetti di tipo directory o file. Il comando where prende in input questi oggetti e ad ognuno di loro chiede se è un contenitore (cioè una directory) utilizzando una proprietà degli oggetti stessi.   

Come altro esempio consideriamo

ps | where { $_.ProcessName -eq “winword” } | select { $_.Company }

ps crea una pipe di oggetti di tipo processo. where seleziona i processi che si chiamano winword. select mostra il nome della società che ha creato il programma. Anche qui le pipe producono oggetti e i comandi lavorano con i metodi e le proprietà degli oggetti.

Il fatto di utilizzare oggetti rende la manipolazione di entità estremamente più semplice. In effetti esistono già diversi prodotti, oltre al sistema operativo, in grado di utilizzare PowerShell.

Vista e Lotus Notes

In attesa di Notes 8, IBM supporta Notes 7.0.2 su Vista.

Dal blog di Ed Brill una support note di IBM che già conoscevo: http://www-1.ibm.com/support/docview.wss?rs=463&uid=swg21252343.

Per chi non lo sapesse nel nostro settore supportato non significa semplicemente che funziona ma che il produttore cerca di risolvere i bug (sempre che abbiate un contratto di manutenzione/supporto attivo o che questa sia compresa nella licenza). Prodotti non supportati possono funzionare benissimo.

Altro "vecchio" hardware provato

In azienda abbiamo un vecchio portatile IBM Thinkpad A20 di qualche anno fa: P4 da 1.4 Ghz, 1GB di RAM e un disco nuovo da 60 GB (ho sostituito quello da 20 GB in dotazione). Vista ci gira benissimo anche se senza Aero. Ovviamente la macchina non è più usata dagli sviluppatori da un paio d’anni ed è un po’ più pesante (nel senso dei Kg) di quelle moderne ma per un uso da normale utente va bene. Il problema è che le batterie sono esaurite e non si trovano batterie di ricambio adeguate! Cercheremo fonti alternative (di batterie non di energia). In attesa lo useremo come trasportabile.

Vista va bene anche sugli Acer Ferrari 3200 (Aero compreso). Ne abbiamo un paio con dischi da 100 GB e 2 GB di RAM.