Compartilhar via

  • Artigo

[Arquivo de Boletins Informativos ^] [< Volume 1, Número 2] [Volume 1, Número 4 >]

O Boletim Informativo Interno de Sistemas Volume 1, Número 3

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

19 de junho de 1999 - Nesta edição:

  1. NOVIDADES NOS SISTEMAS INTERNOS

    • SDelete v1.1
    • Strings v2.0
    • LoggedOn
    • Filemon v4.13
    • DebugView/EE v3.1
    • "Inside NT Networking"
    • "NT Internals" de junho
    • Status da Atualização do NTFrob
    • Coisas não tão novas

  2. NOTÍCIAS INTERNAS

    • Numega DriverStudio Liberado
    • SDK da Plataforma de Junho Disponível
    • Protetor de Arquivos do Sistema Win2K (SFP)
    • Fechando arquivos abertos da rede

  3. O QUE ESTÁ POR VIR

    • Uma API "AWE"-some Win2K

PATROCINADOR: WINTERNALS SOFTWARE

O Boletim Informativo de Sistemas Internos é patrocinado pela Winternals Software, na Web em http://www.winternals.com. O Winternals Software é o principal desenvolvedor e provedor de ferramentas de sistemas avançados para Windows NT/2K. Os produtos winternals software incluem FAT32 para Windows NT 4.0, ERD Commander (capacidade de disco de inicialização para Windows NT) e NTRecover.

A Winternals Software anuncia o lançamento do Regmon e do Filemon Enterprise Editions. Esses utilitários oferecem toda a funcionalidade dos utilitários gratuitos Filemon e Regmon e adicionam esses recursos avançados:

  • exibir a atividade do Registro e do sistema de arquivos nos sistemas Win9x/NT remotos
  • saída de log de um arquivo em tempo real
  • copiar as linhas de saída para a área de transferência
  • realçar as linhas que correspondem a um filtro
  • exibir a saída dos diferentes computadores simultaneamente
  • imprimir a saída diretamente em uma impressora
  • lembre-se facilmente das suas últimas 5 seleções de filtro

Obter informações de pedidos e preços em http://www.winternals.com.

Olá, pessoal.

Bem-vindo à terceira edição do boletim dos Sistemas Internos. Atualmente, o boletim informativo tem 4400 assinantes.

No último boletim informativo, observei como a Microsoft eliminou a Tela Azul da Morte, como a conhecemos, ao passar para o Windows 2000 (Win2K). A nova Tela Azul do Win2K não tem as informações carregadas de despejo de driver e de pilha presentes na Tela Azul das versões anteriores do Windows NT. Perguntei se você acha que as informações que a Microsoft retirou são úteis e se gostaria que tivessem deixado as coisas como estavam. A resposta foi praticamente unânime, com todos os entrevistados (exceto um) se perguntando por que a Microsoft está optando pelo menor denominador comum. Eis uma opinião típica, enviada por Tony Lavinio:

Portanto, em outras palavras, essa é a resposta do cliente na qual a Microsoft está baseando sua decisão:

'Eu não entendo, então deve ser ruim; sumir com isso'.

Por que eles não tiram a tela inteira e colocam uma mensagem dizendo "Retire o Plugue, Reinsira o Plugue, Reinicie"? Por que estão tirando uma das poucas pistas que temos sobre por que as coisas deram errado?

Pelo menos antes, se fosse um antivírus, um desfragmentador ou um driver com defeito, teríamos um ponto de partida para iniciar a pesquisa.

Se essa ferramenta ajudar apenas 1 em cada 10.000 de nós, com a base ampla da implantação NT, vale a pena. Especialmente porque nós, 0,01%, sustentamos uma boa parte dos outros 99,99%.

Quem era o dissidente solitário? Não é de se surpreender que seja alguém da Microsoft que envie relatórios de falhas de tela azul. Veja a opinião deles sobre a mudança, o que confirma a especulação de Tony sobre o motivo dela:

Trabalho no grupo de Configuração do NT no PSS da MS (que lida com a solução de problemas de tela azul). Posso garantir que a maioria das pessoas com quem converso não sabe o que fazer com as informações em uma tela azul 4.0. Tenho certeza de que se você visse uma parada 0xA com NAIFILTR.SYS na pilha, saberia que deveria atualizar seu antivírus, mas a maioria das pessoas não faz essa conexão e, na verdade, não percebe que o código de parada e os parâmetros são úteis para elas. Pessoas que entendem como interpretar dados de tela azul provavelmente ficarão irritados, mas infelizmente são minoria.

Como afirmei no último boletim informativo, acho que a Microsoft deveria levar adiante a Tela Azul do NT 4.0, mantendo a lista de drivers carregados e o despejo de pilha. Também acho que eles poderiam tornar a Tela Azul melhor fornecendo mais informações, não menos. Por exemplo, por que não mostrar o nome do processo em execução no momento da falha? Ou fazer com que mais chamadas de bugCheck passem o endereço da falha, não apenas o endereço que falhou? Uma das principais razões pelas quais o PSS encontrou tantos clientes sem noção sobre a Tela Azul é que a Microsoft nunca escreveu a documentação sobre como lê-la. Assim, pelo menos parte da culpa pela ignorância do usuário recai sobre os ombros da própria Microsoft.

Se você quiser saber mais sobre como as Telas Azuis ocorrem e o que está na (NT 4.) Tela Azul, leia meu artigo de dezembro de 1997, "Inside the Blue Screen", da Revista Windows NT (você pode acessar a versão on-line de http://www.sysinternals.com/publ.htm).

Como de costume, passe o boletim informativo para amigos que você acha que pode achar interessante.

Agradecemos!

-Mark

NOVIDADES NOS SISTEMAS INTERNOS

SDELETE V1.1

No último boletim informativo, apresentei o SDelete, um utilitário de exclusão segura que você pode usar para destruir irremediavelmente os dados do arquivo, bem como para limpar o espaço livre de um disco de dados excluídos anteriormente. A primeira versão do SDelete não pôde substituir com segurança os nomes dos arquivos excluídos por ele. O nome de um arquivo geralmente revela informações confidenciais e o uso do SDelete para excluir um arquivo com um nome revelador pode deixar essas informações expostas. Para resolver essa brecha, atualizei o SDelete para não apenas substituir os dados dos arquivos com segurança, mas também os nomes dos arquivos. O SDelete exclui com segurança um nome de arquivo renomeando o arquivo 26 vezes, substituindo as letras no nome do arquivo por letras sucessivas do alfabeto, de 'A' a 'Z'.

Baixar o SDelete v1.1 com código-fonte completo em http://www.sysinternals.com/sdelete.htm.

STRINGS V2.0

Os executáveis e as DLLs geralmente têm cadeias de caracteres incorporadas que podem revelar valores não documentados do Registro e mensagens de erro que sugerem funcionalidades não documentadas. Infelizmente, a maioria das DLLs e EXEs do sistema Windows NT/2K são gravadas para usarem cadeias de caracteres Unicode, enquanto as ferramentas tradicionais de pesquisa de cadeia de caracteres, como o Grep, extraem apenas cadeias de caracteres ASCII. Escrevi a primeira versão do meu utilitário Strings há alguns anos para verificar arquivos binários em busca de cadeias de caracteres ASCII ou Unicode. Já usei muitas vezes em minha pesquisa de internos do NT para ajudar a descobrir coisas que a Microsoft não documenta.

Porém, O Strings sempre teve uma falha importante, que era a incapacidade de usar uma expressão coringa como especificador de arquivo para que você pudesse verificar vários arquivos de uma só vez. Eu queria esse recurso para que, dado o nome de um valor do Registro, por exemplo, eu pudesse determinar facilmente quais DLLs do sistema fazem referência a ele.

Por fim, atualizei o Strings para obter nomes de arquivo cartão completos, bem como para recursar diretórios. Se você especificar uma expressão coringa, o Strings prefixará automaticamente as linhas de saída com o nome do arquivo em que a cadeia de caracteres foi encontrada, de modo que você possa fazer algo assim:

strings *.dll | grep SafeBoot

A exibição da saída dessa expressão (uma versão do Grep está disponível nos utilitários do Kit de Recursos Posix do Windows NT) informa quais DLLs do sistema verificam a chave do Registro SafeBoot no Windows 2000. O Strings também é extremamente úteis para verificar quais novos valores do Registro são usados pelas DLLs, drivers e executáveis do sistema Win2K. Por exemplo, usei o Strings para comparar os valores do Registro referenciados na pilha TCP/IP do NT 4.0 SP4 (tcpip.sys) com aqueles referenciados pela pilha TCPIP do Windows 2000. Aqui estão cerca de metade dos valores que são novos na pilha TCPIP do Win2K (todos os quais presumo que estejam localizados em HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters):

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

Não vou ficar esperando que a Microsoft documente todos os novos parâmetros de configuração da pilha.

Você pode baixar o Strings v2.0 em http://www.sysinternals.com/misc.htm.

LOGGEDON

Você já quis saber quem estava conectado a um sistema NT remoto? Nesse caso, você quer baixar o LoggedOn. O LoggedOn é um utilitário simples que informará quais usuários estão conectados interativamente ao computador local ou a um remoto, bem como quais usuários estão conectados pelas conexões de recursos (por exemplo, um compartilhamento de arquivo ou impressora). Eis um exemplo de saída do LoggedOn:

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

O Windows NT e o Win2K não fornecem uma API que os aplicativos podem usar para determinar quem está conectado a um computador, mas o LoggedOn determina isso examinando as chaves do Registro carregadas na árvore do Registro de HKEY\USERS um sistema. Os perfis de qualquer usuário conectado interativamente são carregados nessa chave e os perfis possuem nomes que identificam o SID (ID de segurança) da conta de usuário associada do perfil. Por exemplo, se você abrir o Regedit e procurar na parte inferior HKEY_USERS, verá algo como:

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

Aqui, apenas um usuário está conectado interativamente. Você pode informar o administrador local ou de domínio porque o RID (ID Relativa) é 500, que é a reserva RID NT das contas de administrador.

Ao usar APIs que permitem que um sistema examine o Registro de outro sistema, o LoggedOn lê a chave HKEY_USERS de um computador remoto e converte os SIDs encontrados nos nomes das contas. Para determinar quem está conectado pelo compartilhamento de recursos, o LoggedOn usa a API NET, que está documentada no SDK. A ferramenta de linha de comando Net faz uso extensivo da API NET. Um efeito colateral do LoggedOn acessando o Registro de um sistema remoto é que a conta em que você executa o LoggedOn sempre aparecerá como conectada a um sistema remoto por um compartilhamento de recursos na saída do LoggedOn.

Você pode baixar o LoggedOn com código-fonte completo em http://www.sysinternals.com/misc.htm.

FILEMON V4.13

O Filemon v4.13 acaba de ser lançado, uma atualização que reflete as alterações no driver do arquivador do Windows NT e corrige um bug que introduzi inadvertidamente no driver 4.12. O driver de filtro 4.13 tem estas alterações:

  • ele usa o tipo de sincronização de recursos para proteger algumas das suas estruturas de dados internas
  • ele lida com o novo WIN2K IRP, IRP_MJ_PNP_POWER

O tipo de sincronização de Recursos praticamente não está documentado nos kits de desenvolvimento de driver de dispositivo (DDKs) do Windows NT 4.0 e do Win2K. O Guia de Design nem sequer menciona os Recursos, embora suas funções estejam documentadas na Referência, na seção "Rotinas de Suporte Executivo". Os Recursos são um mecanismo útil para proteger estruturas de dados que podem ser lidas simultaneamente por diferentes threads, mas que exigem acesso exclusivo de um thread durante uma atualização. Assim, são bloqueios de leitor/gravador adquiridos para acesso compartilhado por leitores e acesso exclusivo por gravadores. Os drivers do sistema de arquivos usam amplamente os Recursos, por isso achei adequado atualizar o Filemon para usá-los quando for apropriado.

O Filemon v4.13 também manipula o novo IRP_MJ_PNP_POWER IRP para que ele seja um driver de filtro amigável de plug-and-play e energia quando ele for executado no Win2K. O único requisito de um driver de filtro do sistema de arquivos no tratamento de IRPs desse tipo é passá-los para os dispositivos do sistema de arquivos aos quais o filtro está anexado.

Você pode baixar o Filemon v4.13 com código-fonte completo em http://www.sysinternals.com/filemon.htm.

DEBUGVIEW/EE V3.1

O DebugView/EE é um monitor de saída de depuração versátil que você pode usar para capturar a saída de depuração local ou remota gerada pelos programas Win32 ou drivers de dispositivo no modo kernel em Win95, Win98, WinNT e Win2K. Sua utilidade é limitada nos ambientes em que um usuário sofre uma falha usando um driver de dispositivo, porém - toda a saída de depuração DebugView captura antes que uma falha seja perdida. A versão mais recente do DebugView/EE resolve esse problema no Windows NT/2K. Se um usuário estiver capturando a saída do modo kernel gerada por um driver de dispositivo e o usuário tiver configurado o NT para salvar um despejo de memória, o DebugView/EE poderá extrair a saída de depuração do arquivo de despejo quando o sistema for reiniciado. Usar Edição do DebugView/EE|Processar a seleção de menu despejo de memória para que ele examine um despejo de memória na saída de depuração. Esse recurso permite que os usuários enviem de volta um arquivo de texto contendo a saída de depuração gerada pelo driver até o momento da falha.

Baixar o DebugView/EE v3.1 em http://www.sysinternals.com/debugview.htm.

"INSIDE NT NETWORKING"

Minha coluna "NT Internals" da Windows NT Magazine de março de 1999 já está on-line. Conheça a arquitetura de rede do NT de cima a baixo, incluindo as APIs que ele implementa, como as pilhas de protocolos interagem com as APIs e como os fornecedores de hardware gravam drivers de rede para trabalhar com drivers de protocolo. Além disso, saiba mais sobre alguns novos recursos da rede do Win2K, incluindo o NDIS desserializado e o suporte ao ATM.

Leia "Inside NT Networking" e outras colunas internas NT anteriores on-line em http://www.sysinternals.com/publ.htm.

"NT INTERNALS" DE JUNHO

A edição de junho da minha coluna da Windows NT Magazine é "Inside EFS, Part 1". Este artigo descreve a arquitetura do Sistema de Arquivos Criptografados (EFS) da Microsoft e o conduz por um passeio detalhado pelas etapas que o EFS segue quando criptografa um arquivo. O EFS fornece um recurso de criptografia transparente para unidades NTFS do Win2K e a Microsoft o desenvolveu especificamente para lidar com a capacidade da nossa ferramenta NTFSDOS de ler arquivos NTFS sem levar em conta a segurança deles. Esta coluna estará disponível on-line em três meses.

Dois boletins informativos atrás, falei sobre como as APIs do EFS necessárias para fazer backup e restaurar arquivos criptografados não estão documentadas. Infelizmente, essas APIs ainda não estão documentadas na edição atual do MSDN. No entanto, fui informado de que a Microsoft está enviando a documentação, que está marcada como "Confidential da Microsoft", para seus parceiros e para fazer backup dos fornecedores de software. Além disso, David Golds, Gerente de Programas de Sistemas de Arquivos da Microsoft, palestrou sobre aprimoramentos do sistema de arquivos para Win2K na recente conferência Microsoft TechEd, em Dallas. Na apresentação, nos slides que você pode ver on-line no http://www.teched99.com/slides/1-337.ppt, ele menciona que as APIs de backup não estão documentadas, mas que você pode contatá-lo caso queira a documentação. Infelizmente, seu endereço de email não está listado nos slides.

Visite http://www.winntmag.com para obter as informações de assinatura da Windows NT Magazine.

STATUS DE ATUALIZAÇÃO DO NTFROB

O NTFrob é um utilitário que lancei há alguns anos e que permite que você configure com precisão os comprimentos quânticos dos processos em primeiro e segundo plano no NT 4.0. O NTFrob modifica as estruturas de dados internas para o kernel NT, portanto, ele é altamente específico do Service Pack. Desde o lançamento do NT 4.0 Service Pack 5, tenho recebido muitas consultas perguntando quando lançarei o NTFrob v1.5, a atualização do SP 5. A resposta é que a atualização está próxima - estou aguardando que a Microsoft forneça aos assinantes do MSDN o SP5, incluindo informações de depuração. Preciso das informações de depuração para atualizar o NTFrob para novos Service Packs.

Você pode baixar o NTFrob para NT 4 SP0-4 em http://www.sysinternals.com/ntfrob.htm.

COISAS NÃO TÃO NOVAS

Há alguns meses, liberei um monitor de porta serial win9x/NT/2K e paralelo nos Sistemas Internos. O Portmon permite que você veja exatamente como os aplicativos interagem com portas serial e paralela, incluindo quais dados eles enviam e recebem. Você pode usá-lo para assistir sessões de discagem, conexões serial laplink ou atividade de impressora. O Portmon foi um grande sucesso e, recentemente, ganhou 5 estrelas da Biblioteca de Software da Ziff-Davis, a classificação mais alta possível. Outras ferramentas dos Sistemas Internos que ganharam cinco estrelas incluem Regmon, NTFSDOS e BlueSave.

Baixar o Portmon em http://www.sysinternals.com/portmon.htm.

NOTÍCIAS INTERNAS

DRIVERSTUDIO LIBERADO

O NuMega Labs da CompuWare lançou o DriverStudio, um kit de ferramentas abrangente para desenvolvedores de driver de dispositivos Windows 9x/NT/2K. Ele inclui SoftICE 4.0, BoundsChecker para Drivers, VtoolsD, DriverAgent, DriverWorks, FieldAgent for Drivers e, no futuro, adicionará TrueTime para Drivers e TrueCoverage para Drivers. Como eu disse no último boletim informativo, este é um kit de ferramentas de desenvolvedor obrigatório. O NuMega também lançou um site orientado para desenvolvedores do driver de dispositivo chamado "Driver Central" – http://www.numega.com/drivercentral/default.asp.

LANÇADO O SDK DA PLATAFORMA DE JUNHO

Você pode baixar a versão de junho do SDK da Plataforma da Microsoft agora em http://www.msdn.microsoft.com/developer/sdk/platform.asp.

PROTETOR DE ARQUIVOS DO SISTEMA WIN2K (SFP)

Uma das maiores reclamações dos administradores e usuários de sistemas NT é o "Inferno da DLL" da NT. O inferno da DLL é o resultado de muitos aplicativos atualizando DLLs do sistema de chaves com versões que eles agrupam. Normalmente, os aplicativos fazem isso para garantir que funcionem corretamente; contudo, quando substituem uma DLL, muitas vezes quebram outros aplicativos ao instalar versões incompatíveis, ou até mesmo "atualizam" uma DLL para uma versão mais antiga.

A Microsoft resolveu os problemas de controle de versão de DLL no Win2K com a introdução do Protetor de Arquivos do Sistema (SFP). Na verdade, seu nome será alterado em breve para Windows File Protector (WFP), mas a partir do Beta 3 (build 2031) ele ainda é SFP. O SFP é implementado em uma DLL chamada sfc.dll que o processo winlogon (winlogon.exe) carrega quando o sistema é inicializado. O SFP inclui uma lista integrada de cerca de 3.000 DLLs padrão do sistema Win2K, executáveis (.exe), arquivos de instalação (.inf), drivers (.sys) e arquivos de fonte (.fon) instalados em 30 a 40 diretórios diferentes. Quando o SFP inicializa, ele executa uma operação de diretório de notificação de alterações nos diretórios que contêm arquivos que ele protege. Quando detecta adulteração em um arquivo, ele abre uma caixa de diálogo informando o usuário atual, grava um evento no log de eventos e substitui o arquivo modificado por um backup armazenado em %systemroot%\system32\dllcache. Se o arquivo de backup que o SFP procura no dllcache estiver ausente ou também tiver sido adulterado, o SFP recuperará uma nova cópia da mídia de instalação do Win2K.

Para ver quais arquivos o SFP protege, você pode usar o utilitário Strings mencionado em outra parte deste boletim informativo para despejar os nomes de cadeias de caracteres Unicode incorporados no %systemroot%\system32\sfc.dll.

Os únicos utilitários que podem atualizar arquivos do sistema são hotfix.exe, service packs (update.exe), instalações de atualização e o serviço de Atualização do Win2K. Como essas ferramentas ignoram o SFP? Eles o desabilitam temporariamente chamando a função sfc.dll exportada SfcTerminateWatcherThread e fazem questão de refletir as atualizações no subdiretório dllcache. Você deve observar que o Win2K exige que todos os arquivos do sistema sejam assinados digitalmente pela Microsoft, por isso, geralmente não é possível atualizar um arquivo do sistema com uma versão arbitrária própria.

Os programas Win32 podem observar as alterações em um diretório usando as APIs FindFirstChangeNotification e FindNextChangeNotification Win32. Entretanto, essas APIs informam a um aplicativo que algo mudou; eles não informam ao aplicativo exatamente o que mudou. Portanto, um aplicativo é necessário para examinar um diretório inteiro para determinar quais arquivos ou subdiretórios podem ter sido alterados. O SFP usa a API nativa do NT para executar uma solicitação de notificação de alteração em que o NT informa exatamente quais arquivos ou subdiretórios foram alterados nos diretórios monitorados. A função que o SFP usa é chamada de NtNotifyChangeDirectoryFile e, como 90% da API Nativa do NT, ela não está documentada. Procure um applet nos Sistemas Internos em um futuro próximo que mostre como usar o NtNotifyChangeDirectoryFile.

Minha coluna "NT Internals" de setembro, "Inside Win2K Reliability Enhancements, Part 2" descreve o SFP com mais detalhes.

FECHANDO OS ARQUIVOS ABERTOS DA REDE

Uma das perguntas mais frequentes que recebo dos visitantes dos Sistemas Internos é "como faço para fechar arquivos que os usuários abriram da rede?" Se um usuário tiver um arquivo ou diretório aberto remotamente, não será possível excluir, renomear ou atualizar o arquivo ou diretório localmente. Uma pergunta semelhante é: "Como posso ver quais arquivos os usuários abriram na rede?" Ambas as perguntas são respondidas com o utilitário de linha de comando Net que vem com o Windows NT/2K. Para ver quais arquivos são abertos, basta digitar "net file". Você obterá uma listagem de nomes dos arquivo abertos, identificadores de nome de arquivos correspondentes e os nomes dos usuários que têm arquivos abertos. Para fechar um dos arquivos que você vir aberto, digite net file <id> /close. Para exibir os arquivos abertos localmente, você pode usar minhas ferramentas NTHandle ou HandleEx.

As APIs subjacentes à funcionalidade de visualização e fechamento de arquivos do comando Net estão documentadas no SDK da plataforma e na biblioteca do MSDN. Use a API NetFileEnum para enumerar os arquivos abertos e a API NetFileClose para fechar um arquivo aberto. As APIs realmente permitem enumerar os arquivos abertos nos servidores remotos, algo que o comando Net não permite.

O NTHandle está disponível em http://www.sysinternals.com/nthandle.htm. O HandleEx está disponível em http://www.sysinternals.com/handleex.htm.

O QUE ESTÁ POR VIR

Uma API "AWE"-some Win2K

O Win2K apresenta uma nova API chamada AWE (Extensões de Janela de Endereços) que os aplicativos com uso intensivo de memória podem usar para acessar e gerenciar diretamente grandes quantidades de RAM física - até mais de 3 GB, o limite máximo de RAM que um aplicativo do Windows NT pode endereçar no seu espaço de endereço virtual. Na verdade, se um sistema x86 tiver PSE (Extensões de Tamanho de Página) e mais de 4 GB de RAM, um aplicativo poderá usar a AWE para aproveitar toda a memória do computador. Portanto, essa API é ideal para os aplicativos que consomem muita memória, como servidores da Web e servidores de banco de dados. Da próxima vez, ensinarei como usar as APIs, tanto de aplicativos Win32 quanto de drivers de dispositivo.

Já que estou falando de aplicativos que consomem muita memória, segue uma dica para quem está escrevendo um aplicativo que armazena arquivos em cache (como um servidor Web). O Gerenciador de Cache do Windows NT divide sua memória de cache em slots de 256 KB chamados "modos de exibição". Se um arquivo com menos de 256 KB de tamanho for armazenado em cache, o Gerenciador de Cache ainda deverá atribuir ao arquivo um slot inteiro de 256 KB, o que significa que parte da memória virtual do Cache é desperdiçada. Assim, geralmente é mais eficiente em termos de desempenho armazenar em cache arquivos de tamanho inferior a 256 KB na memória virtual do seu próprio aplicativo e confiar no sistema de arquivos para armazenar em cache arquivos de tamanho superior a 256 KB. O IIS 5.0 usa esse truque.

Obrigado por ler o Boletim Informativo dos Sistemas Internos.

Publicado sábado, 19 de junho de 1999, 19:14, por ottoh

[Arquivo de Boletins Informativos ^] [< Volume 1, Número 2] [Volume 1, Número 4 >]