Condividi tramite

  • Articolo

[Archivio newsletter ^] [< Volume 1, Numero 2] [Volume 1, Numero 4 >]

Newsletter Systems Internals Volume 1, Numero 3

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

19 giugno 1999 - In questo numero:

  1. NOVITÀ DI SYSTEMS INTERNALS

    • SDelete v1.1
    • Strings v2.0
    • LoggedOn
    • Filemon v4.13
    • DebugView/EE v3.1
    • "Approfondimento sulle risorse di rete NT"
    • Giugno - "Eventi interni di NT"
    • Stato dell'aggiornamento di NTFrob
    • Notizie quasi recenti

  2. NOVITÀ DI INTERNALS

    • Numega DriverStudio rilasciato
    • Giugno - Platform SDK disponibile
    • Protezione file di sistema Win2K (SFP)
    • Chiusura di file aperti dalla rete

  3. SVILUPPI FUTURI

    • API "AWE" straordinaria di Win2K

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 di Regmon e Filemon Enterprise Edition. Queste utilità forniscono tutte le funzionalità del freeware Filemon e Regmon e aggiungono queste potenti funzionalità:

  • Visualizzazione dell'attività del Registro di sistema e del file system eseguita nei sistemi Win9x/NT remoti
  • Registrazione dell'output in un file in tempo reale
  • Copia delle righe di output negli Appunti
  • Evidenziazione delle righe che corrispondono a un filtro
  • Visualizzazione dell'output da computer diversi contemporaneamente
  • Stampa dell'output direttamente in una stampante
  • Richiamo semplice delle ultime 5 selezioni di filtri

Ottenere informazioni sull'ordinamento e sui prezzi in http://www.winternals.com.

Ciao a tutti.

Benvenuti alla terza edizione della newsletter Systems Internals. La newsletter ha attualmente 4400 abbonati.

Nell'ultima newsletter ho segnalato che Microsoft ha completamente rivoluzionato la schermata blu nel passaggio a Windows 2000 (Win2K). La nuova schermata blu di Win2K non include le informazioni sul driver caricato e sul dump dello stack presenti nelle versioni precedenti di Windows NT. Ho chiesto se le informazioni rimosse da Microsoft risultavano utili e se gli utenti avrebbero preferito che non fossero apportate modifiche. La risposta è stata praticamente unanime, con ogni singolo intervistato (tranne uno) che si domandava perché Microsoft si stesse adeguando al minimo denominatore comune. Ecco un'opinione tipica, inviata da Tony Lavinio:

Quindi, in altre parole, questa è la risposta del cliente su cui Microsoft sta basando la propria decisione:

"Non capisco queste informazioni, quindi devono essere inutili e voglio che vengano rimosse".

Perché non rimuovono semplicemente l'intera schermata e visualizzano un messaggio di tipo "Stacca la spina, reinserisci la spina, ricomincia"? Perché stanno togliendo uno dei pochi indizi disponibili per capire perché si sono verificati problemi?

In precedenza, se si trattava di un programma antivirus o un deframmentatore o un driver con bug, era almeno disponibile un punto da cui iniziare la ricerca.

Se questo strumento risulta utile solo per 1 su 10.000 utenti, considerata l'ampiezza della base della distribuzione di NT, ne vale la pena, considerato soprattutto che lo 0,1% supporta una buona parte dell'altro 99,99%.

Chi era l'unica persona a non essere d'accordo? Non sorprende troppo che si tratti di un dipendente Microsoft che gestisce i report di arresto anomalo della schermata blu. Ecco il suo parere sulla modifica, che conferma la speculazione in merito ai motivi di questo cambiamento:

Lavoro nel gruppo di configurazione di NT in PSS presso Microsoft, che gestisce la risoluzione dei problemi delle schermate blu. Posso assicurarvi che la maggior parte delle persone con cui parlo non so cosa fare con le informazioni disponibili in una schermata blu 4.0. Sono sicuro che se ricevessi un messaggio di arresto 0xA con NAIFILTR.SYS in tutto lo stack, sapresti che è necessario aggiornare l'antivirus, ma la maggior parte delle persone non è in grado di fare quella associazione e non capisce affatto che il codice di arresto e i parametri sono utili. Le persone che capiscono come interpretare i dati della schermata blu saranno probabilmente scontente, ma purtroppo sono una minoranza.

Come accennato nell'ultima newsletter, ritengo che Microsoft dovrebbe continuare a rendere disponibile la schermata blu di NT 4.0, mantenendo l'elenco dei driver caricati e il dump dello stack. Penso anche che potrebbero migliorare la schermata blu fornendo maggiori informazioni, non meno. Ad esempio, perché non visualizzare il nome del processo attualmente in esecuzione al momento dell'arresto anomalo oppure fare in modo che più chiamate di BugCheck passino l'indirizzo dell'elemento che ha generato un errore, non solo l'indirizzo in cui si è verificato un errore? Un motivo importante per cui PSS ha rilevato così tanti clienti che non sono in grado di interpretare la schermata blu è costituito dal fatto che Microsoft non ha mai scritto la documentazione su come leggerla. Microsoft è quindi parzialmente responsabile dell'ignoranza degli utenti.

Per altre informazioni sui motivi per cui si verificano le schermate blu e sugli elementi inclusi nella schermata blu (NT 4.), vedere l'articolo di dicembre 1997, "Approfondimento sulla schermata blu", da Windows NT Magazine. La versione online è disponibile da http://www.sysinternals.com/publ.htm).

Come di consueto, si invita a condividere la newsletter con amici che si pensa potrebbero trovarla interessante.

Grazie.

- Mark

NOVITÀ DI SYSTEMS INTERNALS

SDELETE V1.1

Nell'ultima newsletter ho introdotto SDelete, un'utilità di eliminazione sicura che è possibile usare per distruggere in modo irreversibile i dati dei file, nonché per pulire lo spazio libero di un disco dai dati eliminati in precedenza. La prima versione di SDelete non riusciva a sovrascrivere in modo sicuro i nomi dei file eliminati. Il nome di un file rivela spesso informazioni riservate e l'uso di SDelete per eliminare un file con un nome rivelatore potrebbe lasciare tali informazioni esposte. Per risolvere questo problema, ho aggiornato SDelete per sovrascrivere in modo sicuro non solo i dati dei file, ma anche i nomi di file. SDelete elimina in modo sicuro un nome file rinominando il file 26 volte, sostituendo ogni lettera nel nome del file con lettere successive dell'alfabeto, da 'A' a 'Z'.

SDelete v1.1 con codice sorgente completo è disponibile per il download all'indirizzo http://www.sysinternals.com/sdelete.htm.

STRINGS V2.0

I file eseguibili e le DLL includono spesso stringhe incorporate che possono rivelare valori del Registro di sistema non documentati e messaggi di errore che indicano funzionalità non documentate. Sfortunatamente, la maggior parte delle DLL e dei file eseguibili di sistema di Windows NT/2K viene scritta per usare stringhe di caratteri Unicode, mentre gli strumenti di ricerca di stringhe tradizionali come Grep estraggono solo stringhe ASCII. Ho scritto la prima versione dell'utilità Strings qualche anno fa per analizzare i file binari per rilevare stringhe di caratteri ASCII o Unicode. L'ho usata molte volte nella mia ricerca di eventi interni di NT per capire cosa non viene documentato da Microsoft.

Strings ha tuttavia avuto sempre un grave difetto, ovvero l'incapacità di accettare un'espressione con caratteri jolly come identificatore di file in modo da poter analizzare più file contemporaneamente. Volevo questa funzionalità in modo che, dato il nome di un valore del Registro di sistema, ad esempio, fosse possibile determinare facilmente quali DLL di sistema vi fanno riferimento.

Ho finalmente aggiornato Strings in modo che accetti nomi di file con caratteri jolly completi, oltre a directory ricorsive. Se si specifica un'espressione con caratteri jolly, Strings aggiunge automaticamente alle righe di output come prefisso il nome del file in cui si trova una stringa, in modo consentire l'esecuzione di operazioni simili alle seguenti:

strings *.dll | grep SafeBoot

La visualizzazione dell'output di questa espressione (una versione di Grep è disponibile nelle utilità Posix di Windows NT Resource Kit) segnala all'utente le DLL di sistema che controllano la chiave del Registro di sistema SafeBoot in Windows 2000. Strings risulta inoltre estremamente utile per vedere quali nuovi valori del Registro di sistema vengono usati da DLL, driver ed eseguibili di sistema di Win2K. Ad esempio, ho usato Strings per confrontare i valori del Registro di sistema a cui si fa riferimento nello stack TCP/IP NT 4.0 SP4 (tcpip.sys) con quelli a cui fa riferimento lo stack TCPIP di Windows 2000. Di seguito sono riportati circa la metà dei nuovi valori dello stack TCPIP di Win2K. Suppongo che si trovino tutti in HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters:

ReservedPorts
DefaultGatewayMetric
InterfaceMetric
TempLeaseExpirationTime
TempIpAddress
TempMask
DhcpDefaultGateway
TcpWindowSize
TcpInitialRTT
TcpDelAckTicks
EnableTrafficControl
EnableTOSetting
MaxNormLookupMemory
MaxSendSegments
MaxFreeConnections
MaxFreeTWTcbs
FFPFastForwardingCacheSize

Non rimarrò in attesa della documentazione di tutti i nuovi parametri di configurazione dello stack da parte di Microsoft.

È possibile scaricare Strings v2.0 all'indirizzo http://www.sysinternals.com/misc.htm.

LOGGEDON

Se si è mai voluto sapere chi è stato connesso a un sistema NT remoto, è consigliabile scaricare LoggedOn. LoggedOn è una semplice utilità che indica quali utenti sono connessi in modo interattivo al computer locale o a uno remoto, nonché a quali utenti sono connessi tramite connessioni di risorse, ad esempio, una condivisione file o stampante. Di seguito è riportato l'output LoggedOn di esempio:

C:\>loggedon main

LoggedOn v1.0 - Logon Session Displayer
Copyright (C) 1999 Mark Russinovich
Systems Internals - http://www.sysinternals.com

Users logged on locally:
MAIN\Administrator

Users logged on via resource shares:
MAINDOM\MARK

Windows NT e Win2K non forniscono un'API che le applicazioni possono usare per determinare chi è connesso a un computer, ma LoggedOn fornisce questa informazione esaminando le chiavi del Registro di sistema caricate nell'albero del Registro di sistema HKEY\USERS di un sistema. I profili di qualsiasi utente connesso in modo interattivo vengono caricati in questa chiave e i profili hanno nomi che identificano il SID (ID di sicurezza) dell'account utente associato del profilo. Ad esempio, se si apre Regedit e si cerca in HKEY_USERS, verrà visualizzato un risultato simile al seguente:

HKEY_USERS\.DEFAULT\S-1-5-21-734676951-386466661-1233803906-500

In questo caso solo un utente è connesso in modo interattivo. È possibile dedurre che si tratta dell'amministratore locale o dell'amministratore di dominio perché il RID (ID relativo) è 500, ovvero il RID riservato da NT per gli account amministratore.

Usando le API che consentono a un sistema di esaminare il Registro di sistema di un altro sistema, LoggedOn legge la chiave HKEY_USERS di un computer remoto e converte i SID trovati in nomi di account. Per determinare chi è connesso tramite condivisione di risorse, LoggedOn usa l'API NET, documentata nell'SDK. Lo strumento da riga di comando Net usa ampiamente l'API NET. Un effetto collaterale dell'accesso di LoggedOn al Registro di sistema remoto consiste nel fatto che l'account in cui è stato eseguito LoggedOn verrà sempre visualizzato come connesso a un sistema remoto tramite una condivisione di risorse nell'output di LoggedOn.

È possibile scaricare LoggedOn con il codice sorgente completo in http://www.sysinternals.com/misc.htm.

FILEMON V4.13

Filemon v4.13 è stato appena rilasciato. Si tratta di un aggiornamento che riflette le modifiche apportate al driver di filtro di Windows NT e corregge un bug che ho inavvertitamente introdotto nel driver 4.12. Il driver di filtro 4.13 presenta queste modifiche:

  • Usa il tipo di sincronizzazione delle risorse per proteggere alcune delle relative strutture di dati interne
  • Gestisce il nuovo IRP di Win2K, IRP_MJ_PNP_POWER

Il tipo di sincronizzazione delle risorse non è praticamente documentato nei Kit di sviluppo dei driver di dispositivo di Windows NT 4.0 e in Win2K. La guida alla progettazione non menziona nemmeno le risorse, mentre le relative funzioni sono documentate nella sezione "Routine di supporto esecutivo". Le risorse sono un meccanismo utile per proteggere le strutture di dati che possono essere lette simultaneamente da thread diversi, ma che richiedono l'accesso esclusivo da parte di un thread durante un aggiornamento. Di conseguenza, sono blocchi lettore/writer acquisiti per l'accesso condiviso da parte dei lettori e l'accesso esclusivo da parte dei writer. I driver del file system fanno un uso esteso delle risorse, quindi ho ritenuto opportuno aggiornare Filemon in modo da usarli dove appropriato.

Filemon v4.13 gestisce anche il nuovo IRP IRP_MJ_PNP_POWER in modo che sia un driver di filtro compatibile con plug-and-play e alimentazione quando viene eseguito in Win2K. L'unico requisito di un driver di filtro del file system nella gestione di IRP di questo tipo consiste nel passarli ai dispositivi del file system a cui è collegato il filtro.

È possibile scaricare Filemon v4.13 con codice sorgente completo all'indirizzo http://www.sysinternals.com/filemon.htm.

DEBUGVIEW/EE V3.1

DebugView/EE è un monitor di output di debug versatile che è possibile usare per acquisire l'output di debug locale o remoto generato da programmi di Win32 o driver di dispositivo in modalità kernel in Win95, Win98, WinNT e Win2K. La sua utilità è tuttavia limitata negli ambienti in cui un utente riscontra un arresto anomalo usando un driver di dispositivo, perché tutto l'output di debug acquisito da DebugView prima che si verifichi un arresto anomalo viene perso. La versione più recente di DebugView/EE risolve questo problema in Windows NT/2K. Se un utente acquisisce l'output in modalità kernel generato da un driver di dispositivo e l'utente ha configurato NT per salvare un dump di arresto anomalo, DebugView/EE può estrarre l'output di debug dal file di dump al riavvio del sistema. Usare l'opzione di menu Edit|Process Crash Dump di DebugView/EE per fare in modo che analizzi un dump di memoria per ottenere l'output di debug. Questa funzionalità consente agli utenti di inviare un file di testo contenente l'output di debug generato dal driver fino al momento dell'arresto anomalo.

DebugView/EE v3.1 è disponibile per il download all'indirizzo http://www.sysinternals.com/debugview.htm.

"APPROFONDIMENTO SULLE RISORSE DI RETE NT"

L'articolo di marzo 1999 della rubrica "Eventi interni di NT" di Windows NT Magazine è ora online. Fornisce informazioni sull'architettura di rete di NT dall'alto verso il basso, incluse le API implementate, il modo in cui gli stack di protocolli interagiscono con le API e il modo in cui i fornitori di hardware scrivono driver di rete per lavorare con i driver di protocollo. Fornisce inoltre informazioni su alcune nuove funzionalità di rete di Win2K, tra cui il supporto NDIS deserializzato e ATM.

Leggere "Approfondimenti sulle risorse di rete di NT" e altri articoli precedenti della rubrica "Eventi interni di NT" in http://www.sysinternals.com/publ.htm.

GIUGNO - "EVENTI INTERNI DI NT"

L'edizione di giugno della mia rubrica in Windows NT Magazine è intitolato "Approfondimento di EFS, Parte 1". Questo articolo descrive l'architettura del file system EFS (Encrypting File System) di Microsoft e illustra in dettaglio i passaggi che EFS segue quando crittografa un file. EFS fornisce una funzionalità di crittografia trasparente per le unità NTFS di Win2K e Microsoft lo ha sviluppato specificamente per risolvere il problema relativo alla capacità dello strumento NTFSDOS di leggere i file NTFS senza considerarne la sicurezza. Questo articolo sarà disponibile online tra tre mesi.

Due newsletter fa ho descritto il modo in cui le API EFS necessarie per il backup e il ripristino dei file crittografati non sono documentate. Sfortunatamente, queste API non sono ancora documentate nell'edizione corrente di MSDN. Sono stato tuttavia informato che Microsoft sta inviando la documentazione, contrassegnata come "Microsoft Confidential", ai suoi partner e ai fornitori di software di backup. David Golds, Program Manager di File System presso Microsoft, ha inoltre presentato una relazione sui miglioramenti del file system per Win2K alla recente conferenza Microsoft TechEd a Dallas. Nella presentazione, di cui è possibile visualizzare online le diapositive all'indirizzo http://www.teched99.com/slides/1-337.ppt, conferma che le API di backup non sono documentate, ma che è possibile rivolgersi a lui se si vuole la documentazione. Sfortunatamente, il suo indirizzo di posta elettronica non è elencato nelle diapositive.

Visitare http://www.winntmag.com per informazioni sull'abbonamento a Windows NT Magazine.

STATO DELL'AGGIORNAMENTO DI NTFROB

NTFrob è un'utilità che ho rilasciato un paio di anni fa e che consente di configurare con precisione le lunghezze quantistiche dei processi in primo piano e in background su NT 4.0. NTFrob modifica le strutture di dati interne al kernel NT, quindi è altamente specifico per ogni Service Pack. Dopo il rilascio di NT 4.0 Service Pack 5 ho ricevuto numerose domande in merito a quando verrà rilasciato NTFrob v1.5, l'aggiornamento per Service Pack 5. La risposta è che l'aggiornamento è imminente. Sto aspettando che Microsoft fornisca il Service Pack 5 agli abbonati a MSDN, incluse le informazioni di debug. Le informazioni di debug sono necessarie per aggiornare NTFrob per i nuovi Service Pack.

È possibile scaricare NTFrob per NT 4 SP0-4 all'indirizzo http://www.sysinternals.com/ntfrob.htm.

NOTIZIE QUASI RECENTI

Qualche mese fa ho rilasciato un monitor di porte seriali e parallele per Win9x/NT/2K in Systems Internals. Portmon consente di vedere esattamente in che modo le applicazioni interagiscono con porte seriali e parallele, inclusi i dati inviati e ricevuti. È possibile usarlo per controllare le sessioni di connessione remota, le connessioni seriali Laplink o l'attività della stampante. Portmon è stato un enorme successo e ha ottenuto recentemente 5 stelle dalla Libreria software di Ziff-Davis, la valutazione più alta possibile. Altri strumenti di Systems Internals che hanno ottenuto 5 stelle includono Regmon, NTFSDOS e BlueSave.

Portmon è disponibile per il download all'indirizzo http://www.sysinternals.com/portmon.htm.

NOVITÀ DI INTERNALS

DRIVERSTUDIO RILASCIATO

NuMega Labs di CompuWare ha rilasciato DriverStudio, un toolkit completo per sviluppatori di driver di dispositivi di Windows 9x/NT/2K. Include SoftICE 4.0, BoundsChecker per driver, VtoolsD, DriverAgent, DriverWorks, FieldAgent per driver e in futuro includerà TrueTime per driver e TrueCoverage per driver. Come accennato nell'ultima newsletter, questo è un toolkit assolutamente essenziale per gli sviluppatori. NuMega ha anche lanciato un sito Web orientato agli sviluppatori di driver di dispositivi denominato "Driver Central" - http://www.numega.com/drivercentral/default.asp.

GIUGNO - PLATFORM SDK RILASCIATO

È possibile scaricare ora la versione di giugno di Microsoft Platform SDK all'indirizzo http://www.msdn.microsoft.com/developer/sdk/platform.asp.

PROTEZIONE FILE DI SISTEMA WIN2K (SFP)

Uno dei problemi principali per gli amministratori di sistema e utenti di NT è definito "Inferno di DLL" di NT. L'inferno di DLL è il risultato di molte applicazioni che aggiornano le DLL di sistema chiave con le versioni in bundle. Le applicazioni in genere eseguono questa operazione in modo da poterne garantire il corretto funzionamento, ma quando sostituiscono una DLL possono a volte causare interruzioni per altre applicazioni installando versioni incompatibili o anche "aggiornando" una DLL a una versione precedente.

Microsoft ha risolto i problemi di controllo delle versioni delle DLL in Win2K con l'introduzione di Protezione file di sistema. In realtà il nome cambierà presto in Windows File Protector (WFP), ma nella versione Beta 3 (build 2031) è ancora Protezione file di sistema. La funzionalità Protezione file di sistema viene implementata in una DLL denominata sfc.dll caricata dal processo Winlogon (winlogon.exe) all'avvio del sistema. Protezione file di sistema include un elenco predefinito di circa 3000 DLL di sistema Win2K standard, file eseguibili (con estensione exe), file di installazione (con estensione inf), driver (con estensione sys) e file di tipo di carattere (con estensione fon) installati in 30-40 directory diverse. Quando Protezione file di sistema viene inizializzato, esegue un'operazione di directory change-notify in ogni directory che contiene file protetti. Quando rileva la manomissione di un file, viene visualizzata una finestra di dialogo che informa l'utente corrente, scrive un elemento nel registro eventi e sostituisce il file modificato con un backup archiviato in %systemroot%\system32\dllcache. Se il file di backup cercato da Protezione file di sistema in dllcache è mancante o è stato manomesso, Protezione file di sistema recupera una copia aggiornata dal supporto di installazione di Win2K.

Per visualizzare i file protetti da Protezione file di sistema, è possibile usare l'utilità Strings menzionata altrove in questa newsletter per eseguire il dump dei nomi di stringa Unicode incorporati in %systemroot%\system32\sfc.dll.

Le uniche utilità che possono aggiornare i file di sistema sono hotfix.exe, Service Pack (update.exe), installazioni di aggiornamento e servizio di aggiornamento Win2K. In che modo questi strumenti riescono a ignorare Protezione file di sistema? Disabilitano temporaneamente questa funzionalità chiamando la funzione SfcTerminateWatcherThread esportata di sfc.dll e assicurandosi di riflettere gli aggiornamenti nella sottodirectory dllcache. Si noti che Win2K richiede che tutti i file di sistema siano firmati digitalmente da Microsoft, quindi in genere non è possibile aggiornare un file di sistema con una versione arbitraria personalizzata.

I programmi Win32 possono controllare se sono presenti modifiche in una directory usando le API FindFirstChangeNotification e FindNextChangeNotification di Win32. Queste API informano tuttavia semplicemente un'applicazione che qualcosa è cambiato. Non indicano all'applicazione esattamente cosa è cambiato. Un'applicazione deve quindi analizzare un'intera directory per determinare quali file o sottodirectory potrebbero essere stati modificati. Protezione file di sistema usa l'API nativa di NT per eseguire una richiesta di notifica delle modifiche in cui NT indica esattamente quali file o sottodirectory cambiano nelle directory monitorate. La funzione usata da Protezione file di sistema è denominata NtNotifyChangeDirectoryFile e, come il 90% dell'API nativa di NT, non è documentata. Nel prossimo futuro sarà disponibile in Systems Internals un'applet che illustra come usare NtNotifyChangeDirectoryFile.

L'articolo di settembre della rubrica "Eventi interni di NT", "Approfondimenti sui miglioramenti all'affidabilità di Win2K, Parte 2", descrive Protezione file di sistema in modo più dettagliato.

CHIUSURA DI FILE APERTI DALLA RETE

Una delle domande più frequenti che ricevo dai visitatori di System Internals è "come si chiudono i file aperti dagli utenti dalla rete?" Se un utente ha un file o una directory aperta in remoto, non è possibile eliminare, rinominare o aggiornare il file o la directory in locale. Una domanda simile è: "Come posso vedere quali file gli utenti hanno aperto dalla rete?" L'utilità da riga di comando Net, disponibile in Windows NT/2K, risponde a entrambe le domande. Per vedere quali file vengono aperti, digitare semplicemente "net file". Si otterrà un elenco di nomi di file aperti, identificatori di nome file corrispondenti e nomi degli utenti con file aperti. Per chiudere uno dei file visualizzati come aperti, digitare net file <id> /close. Per visualizzare i file aperti localmente, è possibile usare gli strumenti NTHandle o HandleEx.

Le API che si trovano alla base delle funzionalità di visualizzazione e chiusura di file del comando Net sono documentate in Platform SDK e in MSDN Library. Usare l'API NetFileEnum per enumerare i file aperti e l'API NetFileClose per chiudere un file aperto. Le API consentono effettivamente di enumerare i file aperti nei server remoti, un'opzione che il comando Net non consente.

NTHandle è disponibile all'indirizzo http://www.sysinternals.com/nthandle.htm. HandleEx è disponibile all'indirizzo http://www.sysinternals.com/handleex.htm.

SVILUPPI FUTURI

API "AWE" STRAORDINARIA di WIN2K

Win2K presenta una nuova API denominata AWE (Address Window Extensions) che le applicazioni a elevato utilizzo di memoria possono usare per accedere direttamente e gestire grandi quantità di RAM fisica, anche più di 3 GB, il limite massimo di RAM che un'applicazione Windows NT può gestire nello spazio di indirizzi virtuali. Di fatto, se un sistema x86 ha PSE (Page Size Extensions) e più di 4 GB di RAM, un'applicazione può usare AWE per sfruttare tutta la memoria del computer. Questa API è quindi ideale per applicazioni che richiedono molta memoria, come server Web e server di database. La prossima volta spiegherò come usare le API, sia dalle applicazioni Win32 che dai driver di dispositivo.

Rimanendo in tema di applicazioni che richiedono molta memoria, ecco un suggerimento per chiunque scriva un'applicazione che memorizza nella cache i file, ad esempio un server Web. Gestione cache di Windows NT divide la memoria della cache in slot da 256 KB slot denominati "viste". Se un file con dimensioni inferiori a 256 KB viene memorizzato nella cache, Gestione cache deve comunque assegnare al file un intero slot da 256 KB, il che significa che parte della memoria virtuale della cache viene sprecato. Risulta quindi in genere più efficiente memorizzare nella cache i file di dimensioni inferiori a 256 KB nella memoria virtuale dell'applicazione e affidarsi al file system per memorizzare nella cache i file di dimensioni superiori a 256 KB. IIS 5.0 usa questo trucco.

Grazie per aver letto la Newsletter di Systems Internals.

Data di pubblicazione: sabato 19 giugno 1999 alle 19:14 di ottoh

[Archivio newsletter ^] [< Volume 1, Numero 2] [Volume 1, Numero 4 >]