Partilhar via

  • Artigo

[Arquivo de boletins informativos ^] <[ Volume 1, Número 2] [Volume 1, Número 4 >]

The Systems Internals Newsletter Volume 1, Número 3

http://www.sysinternals.com
Direitos de autor (C) 1999 Mark Russinovich

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

  1. O QUE HÁ DE NOVO NA SYSTEMS INTERNALS

    • SDelete v1.1
    • Strings v2.0
    • LoggedOn
    • Filemon v4.13
    • DebugView/EE v3.1
    • "Por dentro da rede NT"
    • Junho "NT Internals"
    • Status de atualização do NTFrob
    • Coisas não tão novas

  2. NOTÍCIAS INTERNAS

    • Numega DriverStudio Lançado
    • SDK da plataforma de junho disponível
    • Protetor de arquivos do sistema Win2K (SFP)
    • Fechar ficheiros abertos a partir da rede

  3. O QUE VEM POR AÍ

    • Uma API Win2K "AWE"

PATROCINADOR: WINTERNALS SOFTWARE

A Newsletter Systems Internals é patrocinada pela Winternals Software, na Web em http://www.winternals.com. A Winternals Software é a principal desenvolvedora e fornecedora 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 das edições Regmon e Filemon Enterprise. Estes utilitários fornecem todas as funcionalidades do freeware Filemon e Regmon, e adicionar estes recursos poderosos:

  • exibir Registro e atividade do sistema de arquivos ocorrendo em sistemas remotos Win9x/NT
  • registrar saída para um arquivo em tempo real
  • copiar linhas de saída para a área de transferência
  • Realçar linhas que correspondem a um filtro
  • visualizar a saída de diferentes computadores simultaneamente
  • saída de impressão diretamente para uma impressora
  • Recupere facilmente as suas últimas 5 seleções de filtros

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

Olá a todos,

Bem-vindo à terceira edição da newsletter Systems Internals. A newsletter conta atualmente com 4400 subscritores.

Na última newsletter apontei como a Microsoft acabou com a Tela Azul da Morte como a conhecemos avançando para o Windows 2000 (Win2K). O novo Win2K Blue Screen não tem o driver carregado e informações de despejo de pilha que está presente na tela azul de versões anteriores do Windows NT. Eu perguntei se você acha a informação que a Microsoft despojou útil e gostaria que eles tivessem deixado as coisas em paz. A resposta foi praticamente unânime, com todos os entrevistados (exceto um) se perguntando por que a Microsoft está indo para o menor denominador comum. Aqui está uma opinião típica, enviada por Tony Lavinio:

Por outras palavras, esta é a resposta do cliente em que a Microsoft está a basear a sua decisão:

"Eu não entendo, então deve ser ruim; fazê-lo ir embora'.

Por que eles não simplesmente removem a tela inteira e colocam uma mensagem dizendo "Pull Plug, Reinsert Plug, Start Over"? Por que estão tirando uma das poucas pistas que temos sobre por que as coisas azedaram?

Pelo menos antes, se fosse um scanner de vírus ou desfragmentador ou driver buggy, teríamos um ponto a partir do qual começar a pesquisar.

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

Quem era o dissidente solitário? Não é muito surpreendente que seja alguém da Microsoft que campos relatórios de falhas de tela azul. Aqui está a sua inclinação sobre a mudança, que confirma a especulação de Tony sobre o motivo para isso:

Eu trabalho no grupo de instalação do NT no PSS no 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 que se você visse um stop 0xA com NAIFILTR.SYS em toda a pilha você saberia atualizar seu antivírus, mas a maioria das pessoas não faz essa conexão, e realmente eles não percebem que o código de parada e params são úteis para eles. As pessoas que entendem como interpretar dados de tela azul provavelmente ficarão irritadas, mas infelizmente são uma minoria.

Como afirmei na última newsletter, sinto que a Microsoft deve levar o NT 4.0 Blue Screen para a frente, mantendo a lista de drivers carregados e stack dump. Eu 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 mais chamadas BugCheck passam o endereço do defeituoso, não apenas o endereço que falhou? Uma das principais razões pelas quais o PSS encontrou tantos clientes que não têm noção sobre a tela azul é que a Microsoft nunca escreveu documentação sobre como lê-la. Pelo menos parte da culpa pela ignorância do usuário, portanto, recai sobre os próprios ombros da Microsoft.

Se você quiser saber mais sobre como as telas azuis ocorrem e o que está no (NT 4.) Blue Screen, veja meu artigo de dezembro de 1997, "Inside the Blue Screen", da Windows NT Magazine (você pode chegar à versão on-line de http://www.sysinternals.com/publ.htm).

Como de costume, por favor, passe a newsletter para amigos que você acha que podem achar interessante.

Obrigado!

-Marcar

O QUE HÁ DE NOVO NA SYSTEMS INTERNALS

SDELETE V1.1

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

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

STRINGS V2.0

Executáveis e DLLs geralmente têm cadeias de caracteres incorporadas neles que podem revelar valores do Registro não documentados e mensagens de erro que sugerem funcionalidade não documentada. Infelizmente, a maioria das DLLs e EXEs do sistema Windows NT/2K são escritas para usar cadeias de caracteres Unicode, enquanto as ferramentas tradicionais de pesquisa de cadeia de caracteres como Grep extraem apenas cadeias de caracteres ASCII. Eu escrevi a primeira versão do meu utilitário Strings alguns anos atrás para digitalizar arquivos binários para cadeias de caracteres ASCII ou Unicode. Eu usei-o muitas vezes em minha pesquisa de NT internos para ajudar a descobrir coisas que a Microsoft não documenta.

No entanto, as cadeias de caracteres sempre tiveram uma grande falha, que foi sua incapacidade de usar uma expressão curinga como um especificador de arquivos para que você pudesse digitalizar 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 Strings para obter nomes completos de arquivos curinga, bem como para recursar diretórios. Se você especificar uma expressão curinga Strings prefixará automaticamente as linhas de saída com o nome do arquivo em que uma cadeia de caracteres é encontrada, para que você possa fazer algo assim:

strings *.dll | grep SafeBoot

A visualização da saída desta expressão (uma versão do Grep está disponível nos utilitários Posix do Windows NT Resource Kit) informa quais DLLs do sistema verificam a chave do Registro SafeBoot no Windows 2000. Strings também é extremamente útil para ver quais novos valores do Registro Win2K DLLs, drivers e executáveis do sistema usam. Por exemplo, usei Strings para comparar os valores do Registro referenciados na pilha TCP/IP (tcpip.sys) do NT 4.0 SP4 com aqueles referenciados pela pilha TCPIP do Windows 2000. Aqui estão cerca de metade dos valores que são novos para a pilha TCPIP do Win2K (todos os quais eu sou assum estão 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 prender a respiração esperando que a Microsoft documente todos os novos parâmetros de configuração da pilha.

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

LOGGEDON

Você já quis saber quem estava conectado a um sistema NT remoto? Se sim, então você vai querer baixar LoggedOn. LoggedOn é um utilitário simples que lhe dirá quais usuários estão conectados interativamente ao computador local ou remoto, bem como quais usuários estão conectados por meio de conexões de recursos (por exemplo, um compartilhamento de arquivo ou impressora). Aqui está o exemplo de saída 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 possam usar para determinar quem está conectado a um computador, mas o LoggedOn determina isso examinando as chaves do Registro que são carregadas na árvore do Registro do HKEY\USERS sistema. Os perfis de qualquer usuário conectado interativamente são carregados nessa chave e os perfis têm nomes que identificam o SID (ID de segurança) da conta de usuário associada ao perfil. Por exemplo, se você abrir o Regedit e olhar por baixo 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 dizer que é o administrador local ou de domínio porque o RID (ID relativo) é 500, que é o NT RID reserva para contas de administrador.

Usando 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 em nomes de conta. Para determinar quem está conectado por meio do 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 na qual você executa o LoggedOn sempre aparecerá como conectada a um sistema remoto por meio de um compartilhamento de recursos na saída do LoggedOn.

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

FILÃO V4.13

Filemon v4.13 acaba de ser lançado, uma atualização que reflete as alterações no driver do filer 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 de 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 documentado no Windows NT 4.0 e Win2K Device Driver Development Kits (DDKs). O Guia de Design nem sequer menciona Recursos, enquanto as suas funções estão documentadas na Referência na secção "Rotinas de Apoio 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 por um thread durante uma atualização. Assim, são fechaduras de leitor/escritor que são adquiridas para acesso compartilhado por leitores e acesso exclusivo por escritores. Os drivers do sistema de arquivos fazem uso extensivo de Recursos, então eu senti que era apropriado atualizar o Filemon para usá-los quando apropriado.

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

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

DEBUGVIEW/EE V3.1

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 por programas Win32 ou drivers de dispositivo de modo kernel em Win95, Win98, WinNT e Win2K. Sua utilidade é limitada em ambientes onde um usuário experimenta uma falha usando um driver de dispositivo, no entanto - toda a saída de depuração DebugView captura antes que uma falha seja perdida. A versão mais recente do DebugView/EE resolve este 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 falha, o DebugView/EE poderá extrair a saída de depuração do arquivo de despejo quando o sistema for reinicializado. Use DebugView/EE's Edit|Selecionar o menu Despejo de falha do processo para que ele verifique um despejo de memória para 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.

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

"POR DENTRO DA REDE NT"

A minha coluna "NT Internals" da Windows NT Magazine de março de 1999 está agora em linha. Saiba mais sobre a arquitetura de rede da NT de cima para baixo, incluindo quais APIs ela implementa, como as pilhas de protocolo interagem com APIs e como os fornecedores de hardware escrevem drivers de rede para trabalhar com drivers de protocolo. Além disso, descubra alguns novos recursos da rede do Win2K, incluindo NDIS desserializado e suporte a ATM.

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

JUNHO "NT INTERNALS"

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 com Criptografia (EFS) da Microsoft e leva você a um passo detalhado pelas etapas que o EFS segue quando criptografa um arquivo. O EFS fornece um recurso de criptografia transparente para unidades NTFS Win2K e a Microsoft o desenvolveu especificamente para abordar a capacidade de nossa ferramenta NTFSDOS de ler arquivos NTFS sem levar em conta sua segurança. Esta coluna estará disponível on-line dentro de três meses.

Dois boletins informativos atrás, falei sobre como as APIs 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 "Confidencial da Microsoft", para seus parceiros e fornecedores de software de backup. Além disso, David Golds, File Systems Program Manager da Microsoft, apresentou uma palestra sobre melhorias do sistema de arquivos para o Win2K na recente conferência Microsoft TechEd em Dallas. Na apresentação, os slides para os quais você pode ver on-line em http://www.teched99.com/slides/1-337.ppt, ele menciona que as APIs de backup não estão documentadas, mas que você pode bugá-lo de você quer a documentação. Infelizmente, seu endereço de e-mail não está listado nos slides.

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

STATUS DE ATUALIZAÇÃO DO NTFROB

NTFrob é um utilitário que lancei há alguns anos que permite configurar com precisão os comprimentos quânticos de processos em primeiro plano e em segundo plano no NT 4.0. O NTFrob modifica estruturas de dados internas ao kernel do NT, por isso é altamente específico do Service Pack. Desde o lançamento do NT 4.0 Service Pack 5, tenho sido inundado com consultas perguntando quando vou lançar o NTFrob v1.5, a atualização do SP 5. A resposta é que a atualização está próxima - estou esperando que a Microsoft forneça aos assinantes do MSDN o SP5, incluindo informações de depuração. Preciso de informações de depuração para atualizar o NTFrob para novos Service Packs.

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

COISAS NÃO TÃO NOVAS

Alguns meses atrás, lancei um monitor de porta serial e paralela Win9x/NT/2K na Systems Internals. O Portmon permite que você veja exatamente como os aplicativos interagem com portas seriais e paralelas, incluindo quais dados eles enviam e recebem. Você pode usá-lo para assistir a sessões dial-up, conexões seriais laplink ou atividade da impressora. Portmon tem sido um grande sucesso, e recentemente ganhou 5 estrelas da Biblioteca de Software de Ziff-Davis, a mais alta classificação possível. Outras ferramentas do Systems Internals que ganharam 5 estrelas incluem Regmon, NTFSDOS e BlueSave.

Download Portmon em http://www.sysinternals.com/portmon.htm.

NOTÍCIAS INTERNAS

DRIVERSTUDIO LANÇADO

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

SDK DA PLATAFORMA DE JUNHO LANÇADO

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 de sistemas e usuários do NT é o "DLL Hell" da NT. DLL hell é o resultado de muitos aplicativos atualizando DLLs do sistema de chaves com versões que eles agrupam. Os aplicativos normalmente fazem isso para que possam garantir que funcionam corretamente, no entanto, quando substituem uma DLL, muitas vezes quebram outros aplicativos instalando versões incompatíveis, ou até mesmo "atualizam" uma DLL para uma versão mais antiga.

A Microsoft resolveu problemas de versionamento de DLL no Win2K com a introdução do System File Protetor (SFP). Na verdade, seu nome mudará em breve para Windows File Protetor (WFP), mas a partir do Beta 3 (build 2031) ainda é SFP. SFP é implementado em uma DLL chamada sfc.dll que o processo Winlogon (winlogon.exe) carrega quando o sistema é inicializado. SFP inclui uma lista interna de cerca de 3000 DLLs padrão do sistema Win2K, executáveis (.exe), arquivos de instalação (.inf), drivers (.sys) e arquivos de fonte (.fon) que são instalados em 30-40 diretórios diferentes. Quando o SFP é inicializado, ele executa uma operação de diretório de notificação de alteração em cada diretório que contém arquivos que ele protege. Quando ele deteta adulteração de um arquivo, ele exibe uma caixa de diálogo informando o usuário atual, grava um par 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 outro lugar deste boletim informativo para despejar os nomes de cadeia de caracteres Unicode incorporados em %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 Win2K Update. Como essas ferramentas ignoram o SFP? Eles o desabilitam temporariamente chamando a função de sfc.dll exportada SfcTerminateWatcherThread e certificam-se de refletir as atualizações no subdiretório dllcache. Você deve observar que o Win2K requer que todos os arquivos do sistema sejam assinados digitalmente pela Microsoft, portanto, geralmente não é possível atualizar um arquivo de sistema com uma versão arbitrária própria.

Os programas Win32 podem observar alterações em um diretório usando as APIs Win32 FindFirstChangeNotification e FindNextChangeNotification. No entanto, essas APIs simplesmente informam um aplicativo de que algo mudou; eles não dizem ao aplicativo exatamente o que mudou. Um aplicativo é, portanto, necessário para verificar 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 mudam nos diretórios monitorados. A função que o SFP usa é chamada NtNotifyChangeDirectoryFile e, como 90% da API nativa da NT, não está documentada. Procure um applet em Systems Internals em um futuro próximo que mostre como usar NtNotifyChangeDirectoryFile.

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

FECHAR FICHEIROS ABERTOS A PARTIR DA REDE

Uma das perguntas mais frequentes que recebo dos visitantes do Systems Internals é "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 da 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 lista de nomes de arquivos abertos, identificadores de nome de arquivo correspondentes e os nomes dos usuários que têm arquivos abertos. Para fechar um dos ficheiros que vê abrir, escreva net file <id> /close. Para visualizar 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 Platform SDK e na Biblioteca MSDN. Use a API NetFileEnum para enumerar arquivos abertos e a API NetFileClose para fechar um arquivo aberto. As APIs realmente permitem enumerar os arquivos abertos em servidores remotos, algo que o comando Net não permite.

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

O QUE VEM POR AÍ

UMA API WIN2K "IMPRESSIONANTE"

O Win2K apresenta uma nova API chamada AWE (Address Window Extensions) que os aplicativos que consomem muita memória podem usar para acessar e gerenciar diretamente grandes quantidades de RAM física - até mesmo mais de 3 GB, o limite superior de RAM que um aplicativo do Windows NT pode endereçar em seu espaço de endereço virtual. Na verdade, se um sistema x86 tiver PSE (Page Size Extensions) e mais de 4GB de RAM, um aplicativo pode usar AWE para aproveitar toda a memória do computador. Esta API é, portanto, ideal para aplicações que consomem muita memória, como servidores Web e servidores de banco de dados. Da próxima vez vou dizer-lhe como usar as APIs, tanto de aplicativos Win32 e de drivers de dispositivo.

Embora eu esteja falando sobre aplicativos que consomem muita memória, aqui está uma dica para quem escreve um aplicativo que armazena arquivos em cache (como um servidor Web). O Gerenciador de cache do Windows NT divide sua memória cache em slots de 256KB chamados "views". 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 será desperdiçada. Assim, geralmente é mais eficiente em termos de desempenho armazenar em cache arquivos com menos de 256 KB de tamanho na memória virtual do seu próprio aplicativo e confiar no sistema de arquivos para armazenar em cache arquivos com mais de 256 KB de tamanho. O IIS 5.0 usa esse truque.

Obrigado por ler a Newsletter da Systems Internals.

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 >]