Condividi tramite

  • Articolo

[Archivio newsletter ^] [< Volume 1, Numero 3] [Volume 1, Numero 5 >]

Newsletter Systems Internals Volume 1, Numero 4

http://www.sysinternals.com
Copyright (C) 1999 Mark Russinovich

5 agosto 1999 - In questo numero:

  1. NOVITÀ DI SYSTEMS INTERNALS

    • Portmon v3.0
    • Frob v1.5
    • ListDLLs v2.1
    • Nuove opzioni di BOOT.INI
    • PsList v1.0
    • Agosto - "Eventi interni di NT"
    • Notizie quasi recenti

  2. NOVITÀ DI INTERNALS

    • Correzione Re: Protezione dei file di sistema
    • Rilascio del DDK di Win2K RC1
    • API AWE di Win2K
    • WinDev '99 West

  3. SVILUPPI FUTURI

    • Strumento DiskEdit non documentato di SP4

SPONSOR: WINTERNALS SOFTWARE

La newsletter Systems Internals è sponsorizzata da Winternals Software, presente sul Web all'indirizzo http://www.winternals.com. Winternals Software è il principale sviluppatore e provider di strumenti avanzati di sistemi per Windows NT/2K. I prodotti Winternals Software includono FAT32 per Windows NT 4.0, ERD Commander (funzionalità del disco di avvio per Windows NT) e NTRecover.

Winternals Software annuncia il rilascio dell'ultima utilità di ripristino del sistema, Remote Recover. Remote Recover consente di accedere alle unità di un computer non avviabile tramite TCP/IP da qualsiasi punto dell'azienda. È possibile risparmiare tempo e costi per il supporto correggendo in remoto i problemi di driver, file system e configurazione che rendono inattivi i sistemi NT o Win9x. Scaricare una versione di valutazione di sola lettura gratuita all'indirizzo http://www.sysinternals.com/rrecover.htm e acquistare la versione di lettura/scrittura all'indirizzo http://www.winternals.com.

Ciao a tutti.

Benvenuti alla quarta edizione della newsletter Systems Internals. La newsletter conta attualmente 7000 abbonati.

Nell'ultima newsletter ho indicato che avrei trattato l'API AWE di Windows 2000 (Win2K). Ho sottolineato che AWE è l'acronimo di "Address Windowing Extensions" (per i neofiti del mondo Windows, API sta per "Application Programming Interface"). Questa pagina del sito Web di Microsoft dedicato agli sviluppatori hardware la descrive come segue: http://www.microsoft.com/hwdev/NTDRIVERS/AWE.htm. Tuttavia, il lettore Laxmikant Gunda mi ha segnalato un altro URL del sito Web di Microsoft, http://www.microsoft.com/windows/server/News/fromMS/intelpae.asp, dove AWE è indicato come API "Advanced Windowing Extensions". Chiaramente, "Address" ha più senso di "Advanced" nel contesto dell'API (che descriverò più avanti in questa newsletter), quindi ritengo che qualche scrittore di marketing sia stato tratto in inganno mentre selezionava il materiale tecnico per la pagina delle notizie.

Ho già visto questa confusione in passato nella copertura tecnica di Microsoft. Di recente, il programma di installazione per la versione Beta 3 del kit IFS (Installable File Systems) di Win2K si è presentato nella schermata iniziale come installazione del "kit Internal File Systems". La "I" di IFS è sempre stata usata per indicare "Installable" e "Internal" non ha molto senso in questo caso (a meno che non sia stata accidentalmente rilasciata la versione non pubblica del kit), quindi credo che si tratti di un altro caso in cui qualcosa è andato storto nella traduzione (o il programmatore dell'installazione non aveva a portata di mano un membro del team dei file system e ha usato la sua ipotesi migliore).

Qual è il mio punto di vista? In realtà non ne ho uno, se non che prima o poi si verificherà un'invasione di acronimi, in cui sviluppatori e addetti al marketing inizieranno a usare inavvertitamente gli stessi acronimi di tre lettere per descrivere tecnologie diverse. Qualcuno del gruppo IIS (Internet Information Server) di Microsoft chiamerà una nuova API "AIE" ("Advanced ISAPI Extensions" - ISAPI è l'acronimo di Internet Server API) e qualcuno del gruppo MTS (Microsoft Transaction Server) proporrà un altro acronimo di AIE, "Atomic Interface Exchange". E sono sicuro che un giorno un addetto al marketing o un scrittore tecnico riceverà dal team IIS un documento tecnico che fa riferimento ad "AIE" e, non conoscendo la differenza tra un database e un file system, ipotizzerà che sta per "Advanced Internet Explorer".

Ho visto confusione di acronimi anche in altri posti. Un recente articolo di Windows NT Magazine che parlava di porte seriali e parallele utilizzava nel testo il termine "porta COM". Dopo l'ultimo passaggio del copy editor e la pubblicazione dell'articolo, la frase è diventata "porta COM (Component Object Model)".

Come al solito, vi invito a condividere la newsletter con gli amici che pensate possano trovarla interessante.

Grazie.

- Mark

NOVITÀ DI SYSTEMS INTERNALS

PORTMON V3.0

Portmon è stato notevolmente migliorato con la versione 3.0. Portmon è un'applicazione di monitoraggio delle porte seriali e parallele per Windows 95/98/NT/2K. La versione 3.0 introduce:

  • funzionalità avanzate di filtro ed evidenziazione dell'output
  • la possibilità di monitorare l'attività delle porte seriali e parallele nei sistemi remoti
  • supporto dell'opzione log-to-file e della stampa
  • integrazione degli Appunti
  • impostazione che consente di specificare la quantità di dati di lettura/scrittura da registrare

Scaricare Portmon v3.0 all'indirizzo http://www.sysinternals.com/portmon.htm.

FROB V1.5

Windows NT 4.0 Server non offre agli amministratori la possibilità di controllare la lunghezza dei quanti (giri) che l'utilità di pianificazione dei thread di NT fornisce ai thread. In Windows 4.0 Workstation l'applet Sistema nel Pannello di controllo ha una scheda Prestazioni con un dispositivo di scorrimento che consente di designare un boost quantistico per i thread in primo piano (il dispositivo di scorrimento è presente anche in Server, ma non ha alcuna funzione). I quanti più brevi in genere producono applicazioni più reattive agli input dell'utente, mentre i quanti più lunghi vanno bene per i sistemi dedicati all'esecuzione di applicazioni server non interattive.

Il programma Frob di Systems Internals offre lo stesso grado di controllo a grana fine sulla lunghezza dei quanti sia su Workstation che su Server, consentendo di ottimizzare i quanti in base al carico di lavoro eseguito su un sistema. Tuttavia, poiché Frob modifica le impostazioni interne al kernel NT, deve essere aggiornato per funzionare con ogni nuovo Service Pack. Frob v1.5 è ora disponibile e offre la compatibilità con il Service Pack 5.

È possibile scaricare Frob v1.5 all'indirizzo http://www.sysinternals.com/ntfrob.htm.

LISTDLLS V2.1

ListDLLs è un'utilità da riga di comando che mostra informazioni dettagliate sulla versione delle DLL caricate dai processi. ListDLLs estrae le informazioni sulla versione dai file su disco che corrispondono ai percorsi dei file delle DLL caricate e ottiene i nomi dei percorsi usando interfacce non documentate. A volte un file DLL su disco viene aggiornato dopo che un'applicazione lo ha già caricato, nel qual caso ListDLLs mostra informazioni sulla versione non corrette.

ListDLLs v2.1 riconosce quando c'è una differenza tra la versione su disco e quella caricata di una DLL e segnala la differenza nell'output. In caso di discrepanza, ListDLLs stampa i tempi di collegamento del file su disco e del file caricato. I tempi di collegamento dei file eseguibili e DLL si trovano nell'intestazione del formato di file PE (Portable Executable) usato da NT per crearne pacchetti.

Scaricare ListDLLs v2.1 all'indirizzo http://www.sysinternals.com/listdlls.htm.

NUOVE OPZIONI DI BOOT.INI

Win2K Beta 3 introduce tre nuove opzioni di BOOT.INI. Tutte e tre sono correlate a PAE (Physical Address Extensions) di Intel, una tecnologia introdotta da Intel con il Pentium Pro per consentire ai sistemi x86 di gestire fino a 64 GB di memoria fisica. Tradizionalmente, i sistemi x86 possono gestire solo 4 GB di memoria fisica, ma con PAE e il chipset 450NX questo limite è stato superato. Win2K è il primo sistema operativo Microsoft che sfrutta PAE (Sun Solaris 7 e SCO UnixWare 7 supportano già PAE). Esiste in realtà una build speciale del kernel di Win2K, denominata ntkrnlpa.exe, che ha il supporto integrato. NTLDR, il boot loader di Win2K, è responsabile del caricamento del kernel standard, ntoskrnl.exe, o di quello abilitato per PAE, a seconda che il sistema sia in grado di gestire più di 4 GB di memoria e abbia tale quantità presente.

Tutte e tre le nuove opzioni di BOOT.INI sono destinate al debug dei driver di dispositivo progettati per funzionare con sistemi di memoria di grandi dimensioni (sistemi con più di 4 GB). La prima, /PAE, fa sì che NTLDR carichi la versione PAE del kernel anche se il computer non ha più di 4 GB di memoria presenti. La seconda, /NOPAE, forza NTLDR a caricare il kernel standard. Infine, l'opzione /NOLOWMEM fa sì che il kernel Win2K usi solo la memoria fisica superiore a 4 GB. Questo costringe tutti gli indirizzi fisici usati da Win2K a richiedere più di 32 bit per rappresentarli, esercitando così la gestione degli indirizzi fisici di grandi dimensioni da parte dei driver di dispositivo.

L'elenco più completo delle opzioni di BOOT.INI è disponibile all'indirizzo http://www.sysinternals.com/bootini.htm.

PSLIST V1.0

La maggior parte delle versioni di UNIX è dotata di uno strumento da riga di comando denominato "ps" usato dagli amministratori per elencare le statistiche di CPU e memoria dei processi. NT dispone di uno strumento equivalente basato su interfaccia grafica, Gestione attività, ma NT non ha una versione da riga di comando. Windows NT Resource Kit include due strumenti da riga di comando, pstat e pumon, simili a 'ps'. PsList mostra una combinazione delle informazioni disponibili con pstat e pumon, ma ha una capacità che nessuno dei due strumenti del Resource Kit possiede: è possibile usare PsList per eseguire query sulle informazioni dei processi in un sistema remoto.

PsList accetta diversi flag che consentono di visualizzare le statistiche sulla CPU, sulla memoria o sui thread del processo e un'opzione che consente di specificare un computer NT diverso su cui eseguire query. PsList usa i contatori delle prestazioni integrati di NT per ottenere le informazioni mostrate e funziona su NT 3.51, 4.0 e Win2K.

Scaricare PsList all'indirizzo http://www.sysinternals.com/pslist.htm.

AGOSTO - "EVENTI INTERNI DI NT"

La mia rubrica "NT Internals" nel numero di agosto di Windows NT Magazine si intitola "Inside Win2K Reliability Enhancements, Part 1". Questa prima parte di una serie di tre parti descrive le funzionalità di Win2K volte ad aiutare gli amministratori a far funzionare un sistema dopo che è diventato non avviabile. Queste includono l'avvio in "modalità provvisoria" e la Console di ripristino di emergenza.

Dall'inizio di agosto, le versioni online degli articoli di Windows NT Magazine sono accessibili solo agli abbonati e gli articoli vengono pubblicati online con ogni nuovo numero. Se non si è abbonati, usare il link per l'abbonamento a Systems Internals all'indirizzo http://www.sysinternals.com/publ.htm per ottenere lo sconto sull'abbonamento a Systems Internals.

NOTIZIE QUASI RECENTI

Se non ci si è già divertiti a spaventare uno o due amici con questo screen saver, vedere Bluescreen Screen Saver di Systems Internals. La versione 2.0 visualizza la versione Win2K della schermata blu di errore BSOD (Blue Screen of Death) e la sequenza di avvio Win2K quando viene eseguita in un sistema Win2K. Sono orgoglioso di dire che Bluescreen Screen Saver ha recentemente ricevuto cinque stelle, la valutazione più alta possibile, dalla Software Library di Ziff-Davis.

Scaricare Bluescreen Screen Saver v2.0 all'indirizzo http://www.sysinternals.com/bluescrn.htm.

NOVITÀ DI INTERNALS

CORREZIONE RE: PROTEZIONE DEI FILE DI SISTEMA

Nell'ultima newsletter ho affermato che System File Protection (SFP) di Win2K consente alle applicazioni come Service Pack (SP) e hotfix di aggiornare i file di sistema chiamando una funzione esportata da SFP denominata SfcTerminateWatcherThread. Sebbene SFP esporti tale funzione, i Service Pack e le hotfix non la usano durante l'aggiornamento dei file di sistema. Sono invece in grado di aggiornare i file di sistema perché sostituiscono i file di sistema esistenti con quelli firmati digitalmente da Microsoft. SFP rileva gli aggiornamenti, ma consente loro di rimanere perché SFP verifica che i nuovi file siano firmati digitalmente. Un'altra correzione riguardante il mio articolo su SFP è che dopo Win2K Beta 3 Microsoft ha cambiato il nome di SFP in Windows File Protection (WFP).

Assicurarsi di consultare il numero di settembre di Windows NT Magazine, dove si troverà la mia rubrica NT Internals "Inside Win2K Reliability Enhancements, Part 2", che descrive in dettaglio WFP e la firma digitale dei file di Microsoft.

RILASCIO DEL DDK DI WIN2K RC1

È possibile scaricare la versione Win2K RC1 di Microsoft Device Driver Development Kit (DDK) all'indirizzo http://www.microsoft.com/ddk/ddk2kRC1.htm. È possibile scaricare gratuitamente il kit o consultare la documentazione online.

API AWE DI WIN2K

Ho già accennato all'API AWE nell'introduzione di questa newsletter e ho fatto riferimento a una pagina Web di Microsoft dove è possibile ottenere altre informazioni: http://www.microsoft.com/hwdev/NTDRIVERS/AWE.htm. Nei sistemi con più di 4 GB di memoria fisica, il kernel compatibile con PAE di Win2K, ntkrnlpa.exe, è in grado di sfruttare tutta la memoria fisica del computer senza alcuna modifica alle applicazioni. Win2K Advanced Server userà fino a 8 GB di memoria fisica e Win2K Datacenter Server userà fino a 64 GB di memoria fisica.

Mentre ogni applicazione in un sistema di memoria di grandi dimensioni ha a disposizione al massimo 2 GB di memoria virtuale (3 GB se si specifica l'opzione /3GB BOOT.INI), la somma della memoria fisica assegnata a tutte le applicazioni in esecuzione può essere uguale alla quantità di memoria fisica. Inoltre, in Win2K alla cache del file system viene assegnato un massimo di 960 MB di memoria virtuale, ma la quantità di dati dei file memorizzati nella cache può essere molto più grande della memoria fisica assegnata alla cache, che può superare i 960 MB.

L'API AWE offre alle singole applicazioni la possibilità di controllare direttamente la memoria fisica, oltre il limite di 2GB o 3GB imposto dalle dimensioni dello spazio di indirizzi virtuali. L'idea di base dell'API AWE è che un'applicazione designi una parte dello spazio di indirizzi virtuali come "finestra" nella memoria fisica. Alloca quindi una parte di memoria fisica. Il limite massimo della quantità di memoria fisica che un'applicazione può allocare è essenzialmente la quantità di memoria fisica del sistema meno la memoria non di paging già allocata dal kernel, dai driver di dispositivo e da altre applicazioni che usano l'API AWE. Quando l'applicazione vuole accedere a parte della memoria fisica che ha allocato, esegue il mapping della memoria nella finestra di indirizzi virtuali. Pertanto, la quantità di memoria fisica a cui l'applicazione può accedere con un determinato mapping è limitata dalle dimensioni della finestra riservata. Infine, quando un'applicazione ha terminato di usare la memoria fisica, libera semplicemente la memoria e chiude (dealloca) la finestra di indirizzi virtuali che ha creato.

Le API che corrispondono a queste azioni vengono esportate da kernel32.dll e sono le seguenti:

  • Un'applicazione chiama VirtualAlloc con i flag MEM_PHYSICAL e MEM_RESERVE per creare la finestra di indirizzi virtuali
  • AllocateUserPhysicalPages alloca la memoria fisica per un'applicazione
  • Un'applicazione usa MapUserPhysicalPages per eseguire il mapping di parti della memoria fisica nella propria finestra
  • FreeUserPhysicalPages libera la memoria fisica allocata dall'applicazione

La possibilità per le applicazioni di modificare direttamente più GB di memoria è un vantaggio per i programmi a elevato utilizzo di memoria, come i server di database, i server di posta elettronica, i server Web, le analisi finanziarie e le applicazioni scientifiche.

Mentre la possibilità di usare più di 4 GB di memoria fisica è consentita solo in alcune versioni di Win2K, l'API AWE è presente in tutte le versioni. Ciò significa che, ad esempio, in un sistema Win2K Professional con 4 GB di memoria, l'API AWE consente alle applicazioni a elevato utilizzo di memoria di gestire più di 2 o 3 GB di dati nella memoria fisica.

L'API AWE ha interfacce equivalenti in modalità kernel su cui kernel32.dll basa le API in modalità utente. Un driver può allocare memoria fisica usando MmAllocatePagesForMdl, che è l'equivalente in modalità kernel di AllocateUserPhysicalPages. Questa funzione ha un prototipo nel file ntddk.h di Win2K DDK, ma non è documentato. Il prototipo è:

NTKERNELAPI
PMDL
MmAllocatePagesForMdl (
    IN PHYSICAL_ADDRESS LowAddress,
    IN PHYSICAL_ADDRESS HighAddress,
    IN PHYSICAL_ADDRESS SkipBytes,
    IN ULONG TotalBytes
    );

LowAddress è l'indirizzo fisico accettabile più basso da allocare e HighAddress è quello più alto. SkipBytes rappresenta il numero di byte che il kernel deve tenere liberi sopra LowAddress e sotto l'indirizzo in cui inizia ad allocare la memoria fisica. TotalBytes rappresenta il numero di byte che il driver vuole allocare. Il valore restituito della funzione è un MDL che se diverso da zero descrive la memoria fisica che il kernel ha assegnato al driver. Per accedere a parti della memoria, il driver deve creare MDL secondari dall'MDL restituito che descrivono parti della memoria fisica appropriate. Quando un driver vuole accedere alla memoria fisica descritta da un MDL secondario, deve eseguire il mapping dell'MDL secondario usando MmGetSystemAddressForMdlSafe.

I driver usano MmFreePagesFromMdl, l'equivalente in modalità kernel di FreeUserPhysicalPages, per liberare la memoria fisica allocata con MmAllocatePagesForMdl. Anche questa funzione viene inserita come prototipo in ntddk.h:

NTKERNELAPI
VOID
MmFreePagesFromMdl (
    IN PMDL MemoryDescriptorList
    );

Si noti che il driver è responsabile della deallocazione dell'MDL restituito da MmAllocatePagesForMdl con una chiamata a ExFreePool, poiché MmFreePagesFromMdl non libera l'MDL.

WINDEV '99 WEST

L'edizione 1999 della West Coast della più importante conferenza per sviluppatori Windows si sta avvicinando rapidamente. WinDev '99 West si terrà dal 13 al 18 settembre presso il Santa Clara Marriot in California. Interverranno molti grandi nomi dello sviluppo Windows, tra cui Jeff Richter, Jeff Prosise e Don Box. Sarò lì con Jamie Hanrahan e Brian Catlin per i driver di dispositivo. Le mie presentazioni comprendono un'esercitazione di un giorno sugli eventi interni di NT, una sulla scrittura dei driver del file system Windows NT/2K e una su problemi avanzati di sviluppo dei driver di dispositivi. Passate a salutarci!

Visitare la pagina Web di WinDev West all'indirizzo http://www.butrain.bu.edu/windev/.

SVILUPPI FUTURI

DISKEDIT DI NT 4.0 SP4

Il Service Pack 4 di Windows NT 4.0 viene fornito con una pratica utilità sul CD che molti potrebbero non aver notato: DiskEdit. E non c'è da meravigliarsi: lo strumento non viene installato sul disco rigido e non include alcuna documentazione. È quasi certo che si tratti di uno strumento usato internamente dagli sviluppatori di file system Microsoft che è stato accidentalmente fornito sul CD. DiskEdit è prezioso per coloro che hanno sentito la mancanza di uno strumento di modifica disco delle utilità Norton per Windows NT o che vogliono semplicemente esplorare le strutture di dati NTFS e FAT su disco. La prossima volta fornirò alcune istruzioni su come usare DiskEdit.

Grazie per aver letto la newsletter Systems Internals.

Pubblicato giovedì 5 agosto 1999 alle 19:13 da ottoh

[Archivio newsletter ^] [< Volume 1, Numero 3] [Volume 1, Numero 5 >]