[Arquivo de Boletins Informativos ^] [< Volume 1, Número 4] [Volume 2, Número 1 >]
O Boletim Informativo Interno de Sistemas Volume 1, Número 5
http://www.sysinternals.com
Direitos autorais 1999 Mark Russinovich
12 de outubro de 1999 – Nesta edição:
NOVIDADES NOS SISTEMAS INTERNOS
- NTFS para Windows 98/NTFSDOS Professional
- DebugView v3.21
- Filemon e Regmon v4.21
- Diskmon v1.1
- Sistemas internos em www.microsoft.com
- "NT Internals" de outubro
- Coisas não tão novas
NOTÍCIAS INTERNAS
- DDK do Win2K RC2 lançado
- Novas APIs de Kernel do Win2K RC
- Desenvolvimento de software '99 Leste
- Usando DiskEdit
O QUE ESTÁ POR VIR
- Explosão da API 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 Recuperação Remota do Winternals Software permite que você acesse as unidades de um computador não inicializável por meio de TCP/IP de qualquer lugar da sua empresa. Economize tempo e dê suporte a dólares corrigindo remotamente os problemas de driver, sistema de arquivos e configuração que estão mantendo os sistemas NT ou Win9x off-line. Você pode até mesmo executar operações remotas de chkdsk ou particionamento usando a Recuperação Remota, o que a torna uma ferramenta versátil de recuperação de desastre. Baixe uma versão de avaliação somente leitura gratuita em http://www.sysinternals.com/rrecover.htm, e compre a versão de leitura/gravação em http://www.winternals.com.
Olá, pessoal.
Bem-vindo ao boletim do Systems Internals. Atualmente, o boletim informativo tem 10.000 assinantes.
O lançamento do Windows 2000 (Win2K) parece seguir um padrão de se tornar iminente e, em seguida, ser empurrado para trás. Os últimos rumores são de que ele ficará disponível em fevereiro. E as únicas informações sobre a data de envio do Win2K estão em rumores, já que a Microsoft nem está informando aos OEMs ou parceiros quando ela será enviada. Bem, eles são: "ele vai enviar quando estiver pronto" (eu não vou forçar o ditado datado sobre a venda de vinho em você aqui).
A coisa irritante sobre a Microsoft é que a imprensa que eles geram sobre seus produtos sempre faz parecer que eles estão à beira do envio mesmo quando os produtos são vaporware. O exemplo mais recente é Millennium, o sucessor do Windows 98. A Microsoft não faz muito tempo atrás fez um grande push na imprensa para ele como se fosse um produto concluído, pronto para converter todos os seus dispositivos domésticos em dispositivos inteligentes. A ironia é que os artigos pouco tempo depois revelaram que a Microsoft ainda nem definiu totalmente o produto, e provavelmente será um ano ou mais antes de vê-lo nas prateleiras das lojas.
Esse padrão não é novo e não sou o primeiro a escrever sobre ele. Mas isso não me impede de especular quanto à serragem é um plano cuidadosamente orquestrado, e quanto é o resultado de uma total falta de entidades de engenharia de software. Se você comprar no antigo ângulo, como os teóricos da conspiração fazem, a Microsoft sufoca brilhantemente a concorrência, tentadora os clientes com esse produto incrível que, se eles esperarem um pouco mais, farão sua espera valer a pena e evitar qualquer necessidade de recorrer a um produto não Microsoft. O último ângulo diz que a Microsoft nunca aprenderá o processo de desenvolvimento de software e subestima continuamente o esforço de engenharia e superestima a qualidade do código beta.
Estou sentado na cerca sobre qual teoria eu ascrevo. Na verdade, acho que o padrão é devido a um pouco dos dois. Acho que ajudou a Microsoft a agir como se o Active Directory estivesse quase pronto há dois anos. Certamente há clientes que teriam voltado para os Serviços de Diretório Novell há muito tempo se soubessem antecipadamente quanto tempo teriam que esperar pelo Win2K. Por outro lado, a Microsoft tem repetido olhos negros na imprensa por prometer entrega de produtos e, em seguida, atrasar. Acho que o gerenciamento da Microsoft simplesmente não entende o quão difícil é reproduzir, isolar e corrigir esses últimos 5% dos bugs.
Falando nas práticas de desenvolvimento da Microsoft, seu esquema de nomenclatura de pré-lançamento é um dos mais desconcertantes que já vi. Seus Betas são realmente Alfas e seus Candidatos à Versão são na verdade Betas. E mesmo usando essas definições é um alongamento: a Microsoft não tem problemas em extrair recursos de seu software em ir de um Release Candidate para o outro ou até mesmo adicionar novos. Eles fizeram isso com o NT 4.0 e estão fazendo isso com Win2K. Essa prática certamente não acelera um ciclo de lançamento.
Então, o Win2K será enviado em fevereiro? Acho que estamos vendo a luz no fim do túnel. Afinal, há apenas um punhado de novas APIs no RC2...
Como acompanhamento do último boletim informativo em que falei sobre confusão de acrônimo na Microsoft, o leitor George Janczuk encontrou outro exemplo. Na seção intitulada: "Estendendo-se ao Mainframe Transaction-Processing World", o artigo em http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm refere-se a CISC – Computação complexa do conjunto de instruções. É óbvio para qualquer pessoa familiarizada com aplicativos de mainframe que o acrônimo pretendido é CICS – Sistema de Controle de Informações do Cliente. Uma sequência de letras invertida e você está em uma área de tecnologia totalmente diferente.
Como de costume, passe o boletim informativo para amigos que você acha que pode achar interessante.
Agradecemos!
-Mark
NOVIDADES NOS SISTEMAS INTERNOS
NTFS PARA WINDOWS 98/NTFSDOS PROFESSIONAL
Nós finalmente fizemos isso. Desde que Bryce e eu lançamos o NTFSDOS 1.0 na Primavera de 1996, estamos em busca do santo graal da compatibilidade do sistema de arquivos do Windows: acesso de leitura/gravação para NTFS do Windows 9x e DOS. Determinamos há muito tempo que a engenharia reversa do formato NTFS e a gravação de um driver para esse complexo sistema de arquivos de diário seriam uma proposta difícil e arriscada. Mesmo que se determine precisamente cada nuance do formato, uma atualização para o formato, como o NTFS v5.0 do Win2K, requer um esforço totalmente novo de engenharia reversa e desenvolvimento. Além disso, validar a correção de um driver do sistema de arquivos para um formato tão intrincado quanto o do NTFS é uma proposta assustadora.
Então nós trapaceamos.
O NTFS para Windows 98 fornece acesso completo de leitura/gravação a unidades NTFS do Windows 95 ou Windows 98, e o NTFSDOS Professional fornece acesso completo de leitura/gravação do NTFS do DOS. Nem o NTFS para Windows 98 nem o NTFSDOS Professional têm conhecimento do formato do sistema de arquivos NTFS. Em vez disso, eles dependem do driver NTFS de uma instalação do Windows NT ou do Windows 2000 para implementar esse conhecimento. Ambos os utilitários usam a mesma base de código que serve como um wrapper de ambiente para o driver do sistema de arquivos NTFS. O NTFS para Windows 98 fornece uma interface para a API do sistema de arquivos windows 9x acima do NTFS e os serviços de disco do Windows 9x abaixo do NTFS. A interface que o NTFS para Windows 98 apresenta ao NTFS se parece com o ambiente nativo do Windows NT/2K do NTFS, completa com IRPs, o Gerenciador de E/S, o Gerenciador de Cache, dispositivos de disco no estilo NT e outros subsistemas NT/2K com os quais o NTFS interage.
O NTFSDOS Professional funciona da mesma maneira que o NTFS para Windows 98, exceto pelo fato de que ele adapta o NTFS aos serviços dos DOS acima e os serviços de disco do BIOS Interrupt 13 abaixo. Para ajudar a criar o ambiente semelhante a NT/2K, contamos com muitas funções no NTOSKRNL, o arquivo kernel NT/2K. Ambos os utilitários carregam NTOSKRNL em conjunto com o NTFS, para que o NTFS possa usar diretamente os serviços nativos do kernel.
Nos divertimos tanto ao construir o ambiente NTFS que fomos um passo além: fizemos a mesma coisa com o utilitário chkdsk de tempo de inicialização da NT, o Autochk. O NTFSDOS Professional e o NTFS para Windows 98 vêm com um utilitário chkdsk NTFS chamado NTFSCHK. O NTFSCHK funciona na mesma entidade de segurança que o wrapper do sistema de arquivos NTFS, em que ele cria um ambiente semelhante a NT para o programa Autochk para que o Autochk seja executado no Windows 95/98 e NOS. O resultado desse truque é o suporte completo de leitura/gravação do NTFS para Windows 95/98 e para DOS.
Você pode baixar uma versão somente leitura gratuita do NTFS para Windows 98 em http://www.sysinternals.com/ntfs98.htm e uma versão somente leitura gratuita do NTFSDOS Professional em http://www.sysinternalscom/ntfspro.htm. Você pode comprar as versões completas de leitura/gravação de ambas as ferramentas no Winternals Software, http://www.winternals.com.
DEBUGVIEW V3.21
DebugView é um monitor de saída de depuração que captura a saída de depuração do kernel e do Win32 em Windows 95, Windows 98, NT 4.0 e Windows 2000. Ele tem recursos avançados de filtragem, realce e registro em log e pode até capturar a saída de depuração de um sistema em uma rede. Sua versão mais recente, 3.21, apresenta a capacidade de monitorar a saída OutputDebugString de 16 bits em Windows 95 e Windows 98.
Você pode baixar DebugView v3.21 em http://www.sysinternals.com/dbgview.htm.
FILEMON E REGMON V4.21
Filemon e Regmon são utilitários de espionagem do sistema de arquivos e do Registro para Windows 95, 98, NT 4.0 e Win2K. Eles continuam evoluindo com novos recursos de usabilidade e, com a versão 4.21 (Filemon e Regmon têm números de versão sincronizados), eles introduzem filtragem mais avançada com listas de filtros recentes, a capacidade de definir um filtro de realce (com cores personalizadas mesmo), fonte personalizável, suporte à área de transferência e mais hot-keys compatíveis com CUI. O código-fonte do driver também foi retrabalhado e inclui uma validação de parâmetro mais robusta nas funções GUI-interface.
Baixar Filemon v4.21 em http://www.sysinternals.com/filemon.htm e Regmon v4.21 em http://www.sysinternals.com/regmon.htm.
DISKMON V1.1
Diskmon é uma ferramenta que monitora e exibe atividades lógicas e físicas de disco. A versão 1.1 atualiza o Diskmon para trabalhar com o Windows 2000 e apresenta novos aprimoramentos de usabilidade. Além disso, o Diskmon agora interpreta um grande número de códigos de controle de E/S de disco e armazenamento em massa, traduzindo seus códigos hexadecimal em representações de texto na janela de saída Diskmon.
O Diskmon v1.1 não só funciona como um monitor de disco, mas também pode usá-lo como uma luz de disco baseada em software. Quando você o define no modo de luz de disco, Diskmon se minimiza na bandeja do sistema como uma luz verde quando há acesso de leitura em disco e vermelho quando há acesso de gravação em disco.
Baixar Diskmon v1.1 em http://www.sysinternals.com/diskmon.htm.
SISTEMAS INTERNOS EM WWW.MICROSOFT.COM
Considerando o histórico de Internos de Sistemas (anteriormente NT Internals), é muito lisonjeiro, de fato, que a Microsoft referencie sysinternals.com como um recurso para seus clientes. Há um número crescente de artigos da Base de Dados de Conhecimento da Microsoft que apontam para utilitários internos de sistemas. Aqui estão as últimas:
Q183060 INFO: Guia de solução de problemas para 80004005 e outras mensagens de erro http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
Este artigo descreve que você pode usar o Filemon para marcar para a causa de erros de acesso a dados no OLE DB, no ActiveX Data Objects e no Remote Data Service.Q196453 – Solução de problemas de erros de inicialização de NTVDM e WOW http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
Este artigo também aponta o Filemon como uma ferramenta para determinar quais arquivos ausentes estão causando erros de inicialização para o NTVDM (o ambiente de compatibilidade Win16/DOS no NT).Q216368 – PRB: Violação de acesso durante a instalação do aplicativo quando o arquivo está em uso http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP
HandleEx e DLLView são ferramentas recomendadas para determinar a causa dos oferrores durante a execução de programas de instalação gerados pelo Assistente de Instalação e Assistente de Implantação do Visual Basic.Q232830 – HOWTO: Determinar a propriedade do identificador de arquivo http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
HandleEx novamente obtém a indicação neste artigo que discute a descoberta de qual processo tem um arquivo ou diretório aberto.
"NT INTERNALS" de OUTUBRO
Minha coluna "NT Internals" na edição de outubro do Windows NT Magazine é "Inside Win2K Reliability Enhancements, Part 3". Este terceiro em uma série de três partes descreve dois recursos avançados do Win2K que ajudam desenvolvedores e administradores a identificar drivers de buggy: memória de kernel protegida por gravação e o Verificador de Driver.
Leitores russos agora podem ler meus artigos em sua língua nativa. Vá para a edição russa da Revista Windows NT em http://www.osp.ru/win2000/ e marcar a primeira coluna traduzida NT Internals, Inside the Boot Process (http://www.osp.ru/win2000/1999/10/59.htm). Obrigado a Ivan Rouzanov por me informar sobre isso.
A partir do início de agosto, as versões on-line dos artigos da Revista Windows NT são acessíveis somente aos assinantes, e os artigos são postados em linha com cada novo problema. Se você ainda não assinou, acesse o link da assinatura em http://www.sysinternals.com/publ.htm para obter o desconto de assinatura do Systems Internals.
COISAS NÃO TÃO NOVAS
O WinObj é uma ferramenta poderosa para explorar o namespace objeto NT/2K do Windows. O namespace Object é um dos três namespaces em NT/2K: o namespace Object, o namespace do Registro e o namespace do sistema de arquivos. Você chega aos namespaces do Registro e do sistema de arquivos por meio de objetos no namespace Objeto. Por exemplo, quando um programa Win32 abre a chave HKEY_LOCAL_MACHINE\Software\Microsoft do Registro, a biblioteca ADVAPI32.DLL transforma o nome para \Registry\Machine\Software\Microsoft antes de chamar o serviço kernel NtCreateKey. Se você examinar a raiz do namespace Object no WinObj, verá um objeto do tipo "chave" chamado Registro. O nome do Registro corresponde ao primeiro componente do nome da chave e, portanto, o Gerenciador de Objetos NT/2K passa o restante do nome, \Machine\Software\Microsoft, para o subsistema que define o objeto de chave. O Configuration Manager subsistema kernel mantém o Registro e os objetos de chave, portanto, analisa o restante do nome para localizar a chave desejada.
Você pode explorar o namespace objeto e exibir ou definir propriedades de segurança de objeto usando WinObj. Baixar Winobj em http://www.sysinternals.com/winobj.htm. Discuto o namespace do Gerenciador de Objetos e WinObj na minha coluna Internas do NT de outubro de 1997, "Dentro do Gerenciador de Objetos". Siga um link para a versão online da coluna em http://www.sysinternals.com/publ.htm.
NOTÍCIAS INTERNAS
DDK do Win2K RC2 lançado
Você pode baixar a versão Win2K RC2 do DDK (Device Driver Development Kit) da Microsoft agora em http://www.microsoft.com/ddk/ddkRC2.htm. Você pode baixar o kit gratuitamente ou procurar a documentação online.
NOVAS APIS DE KERNEL WIN2K RC2
As coisas parecem estar se estabilizando no kernel win2K mais recente. Há apenas quatro APIs de kernel novas e exportadas no RC3, em vez de cerca de uma dúzia que apareceu (e outra meia dúzia que desapareceu) indo do Beta 3 para o RC1. Várias das novas funções são um pouco interessantes, então decidi documentá-las para você. O primeiro é MmGetSystemRoutineAddress, e embora não esteja documentado, seu protótipo está incluído no arquivo de cabeçalho ntddk.h do DDK RC2:
NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
IN PUNICODE_STRING SystemRoutineName
);
Seu uso é tão simples quanto parece. Passe o nome de uma função que reside em NTOSKRNL.EXE ou HAL.DLL e você receberá de volta o endereço do ponto de entrada. Essa função é realmente inútil na primeira versão do Win2K, mas pode se tornar muito útil no futuro, e é uma função que a Microsoft deveria ter incluído na primeira versão do NT (3.1). Assim como GetProcAddress no espaço do usuário para aplicativos Win32, essa função permite que um driver verifique dinamicamente a disponibilidade de uma API. Se a Microsoft adicionar novas APIs aos service packs do Win2K (e tenho certeza de que eles serão), os drivers poderão ser gravados para aproveitar as APIs, mas também para falhar normalmente em versões mais antigas do Win2K ou para serem executados em um modo em que não usem as APIs. A chave para um driver ser capaz de fazer isso é a capacidade de marcar para a presença das APIs após o carregamento. Sem essa funcionalidade, um driver precisa se vincular estaticamente às funções que usa e, se as funções não estiverem presentes quando o driver for carregado, o carregador de kernel relatará um erro feio ao usuário e falhará ao carregar o driver.
A segunda nova API é MmGetPhysicalMemoryPages. Novamente, seu protótipo está no RC2 ntddk.h, mas não está documentado. Seu protótipo é:
NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
VOID
);
Onde PHYSICAL_MEMORY_RANGE está:
typedef struct _PHYSICAL_MEMORY_RANGE {
PHYSICAL_ADDRESS BaseAddress;
LARGE_INTEGER NumberOfBytes;
} PHYSICAL_MEMORY_RANGE, *PPHYSICAL_MEMORY_RANGE;
Essa função retorna uma matriz de PHYSICAL_MEMORY_RANGE entradas com o final da matriz marcado por uma entrada que tem 0 para BaseAddress e NumberOfBytes. Como MmGetSystemRoutineAddress, é uma API muito simples. Ele retorna a você uma descrição de toda a memória física que o Win2K conhece. O Win2K dá suporte à adição e remoção de memória em tempo real com as APIs MmAddPhysicalMemory e MmRemovePhysicalMemory. Isso motiva o motivo da existência de uma API que permite consultar intervalos de memória. MmAddPhysicalMemory foi adicionado no RC1 e MmRemovePhysicalMemory no RC2. Ambas as funções também são protótipos em ntddk.h.
Quais são as outras novas APIs RC2? PoShutdownBugCheck e RtlInvertRangeList. PoShutdownBugCheck permite que você falhe no sistema e execute uma ação relacionada à energia, como a suspensão. Ele é usado em alguns locais pelo kernel RC2. Os intervalos são especificações de start-end genéricas definidas pelo usuário e compatíveis com uma série de APIs de kernel para gerenciar, classificar e iterar sobre eles. Os árbitros de recursos do Win2K Plug-and-Play os usam para rastrear e organizar os requisitos de hardware-recurso. Embora as APIs de lista de intervalos não estejam documentadas, todos os protótipos e definições de estrutura estão incluídos no ntddk.h, portanto, você poderia presumivelmente usar a API para gerenciar seus próprios dados orientados para start-end.
Fique atento para se divertir mais com APIs não documentadas em boletins informativos subsequentes.
DESENVOLVIMENTO DE SOFTWARE 99 LESTE
A edição de 1999 da Costa Leste de Desenvolvimento de Software está acontecendo em Washington D.C. de 8 a 12 de novembro. Estou apresentando três palestras no último dia: Novidades no Windows 2000 Para Desenvolvedores, Dentro da Tela Azul do Windows NT/2000 e Dentro da Rede do Windows NT/2000. Além disso, Dave Solomon, autor de Inside Windows NT 2nd Edition e um vizinho (ele mora a meros 20 minutos de mim, de todos os lugares, Danbury, CT), e estou hospedando uma mesa redonda interna do Windows NT/2K. Estaremos juntos para responder às suas perguntas mais difíceis sobre os internos do Windows NT/2K. Diga olá e menção o boletim informativo e eu lhe darei uma camiseta gratuita do Systems Internals!
Visite o site desenvolvimento de software em http://www.sdexpo.com.
USANDO DISKEDIT
Talvez você não saiba, mas há um utilitário de editor de disco para Windows NT no estilo do venerável Norton Disk Edit for DOS. Além disso, o utilitário entende fat e NTFS e é gratuito. A Microsoft aparentemente enviou o DiskEdit acidentalmente, uma ferramenta que deve ser uma ferramenta de depuração interna para suas equipes de sistemas de arquivos, no CD do Service Pack 4 do Windows NT 4.0. DiskEdit tem uma interface peculiar que levaria um pequeno manual para documentar, mas vou começar com um passo a passo simples. Vou me concentrar em usar DiskEdit para desvendar o formato do sistema de arquivos NTFS, já que DiskEdit é a única ferramenta disponível publicamente que conheço que entende o NTFS.
Primeiro, você precisa obter DiskEdit do CD-ROM do Service Pack 4 (SP4). Basta copiá-lo do diretório \i386 para o disco rígido. Se você quiser usar o DiskEdit no Win2K, precisará criar um diretório privado para ele e copiar as seguintes DLLs de um diretório SP4 winnt\system32 (ou CD SP4) para o mesmo diretório que DiskEdit: IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL e UFAT.DLL. Agora você pode iniciar o DiskEdit.
Para este passo a passo, crie um diretório chamado TEMP na raiz de uma unidade NTFS e crie um arquivo chamado OUT.TXT nesse diretório digitando o seguinte comando em uma janela de prompt de comando com TEMP como o diretório atual: echo hello > out.txt. Selecione a unidade com seu novo arquivo OUT.TXT em DiskEdit escolhendo o Arquivo|Abra o item de menu e insira a letra da unidade no campo Nome do Volume da caixa de diálogo resultante. Inclua os dois-pontos, por exemplo, "d:". Praticamente todas as funcionalidades do DiskEdit exigem que você tenha aberto uma unidade.
Vamos localizar o arquivo OUT.TXT começando no diretório raiz da unidade NTFS. Selecione a entrada de menu Leitura|Registro de Arquivo NTFS para abrir uma caixa de diálogo que permite exibir qualquer entrada de registro MFT apenas inserindo seu número. As primeiras 16 entradas de registro MFT de cada unidade NTFS são reservadas e correspondem a arquivos de metadados NTFS predefinidos. Aqui estão as atribuições numéricas (observe que DiskEdit interpreta toda a entrada como hexadecimal):
0: $MFT - MFT
1: $MFTMirr - MFT Mirror (a copy of the first 4 entries of the MFT)
2: $LogFile - NTFS LogFile
3: $Volume - volume information file
4: $AttrDef - the attribute definition file
5: . - the root directory
6: $Bitmap - the volume allocation bitmap file
7: $Boot - the boot sector
8: $BadClus - the bad cluster database file
9: $Secure - new to SP4, the security attribute database
A: $UpCase - the lower-to-upper case mapping file
B: $Extend - new to Win2K, the directory that contains
the reparse, object ID, and quota metadata files
C-F: Unused as of NTFS v5.0 (Win2K)
Vá em frente e examine algumas dessas entradas MFT. Você começará a observar um tema comum: todos eles consistem em atributos como $INDEX_ROOT, $FILE_NAME e $DATA. Ele está em atributos em que os dados específicos de um arquivo são armazenados. Quando os dados de atributo são pequenos, o NTFS armazena os dados dentro do registro MFT do arquivo como dados "residentes" e quando os dados são grandes, o NTFS armazena os dados externos ao registro em clusters no disco como dados "não residentes".
Agora, insira "5" como o número do arquivo e você exibirá o arquivo do diretório raiz. Vamos examinar os arquivos e diretórios que estão no diretório raiz exibindo o atributo $INDEX_ALLOCATION do diretório, um atributo específico para diretórios que registram o conteúdo de um diretório. Para fazer isso, selecione Ler|Entrada de menu Atributo NTFS, que abre outra caixa de diálogo. DiskEdit é sensível a maiúsculas e minúsculas, portanto, insira o seguinte precisamente como eu o listei:
Base Frs Number: 5
Frs base (segmento de registro de arquivo base) é outro nome para o número MFT. Insira para 5 para especificar que deseja ler um atributo do diretório raiz.
Attribute Type: $INDEX_ALLOCATION
Isso indica ao DiskEdit que você deseja ler os dados de conteúdo do diretório. É recomendável usar o menu suspenso para escolher o atributo desejado, pois DiskEdit é muito exigente sobre a maneira como o tipo de atributo é inserido.
Attribute Name: $I30
Se você exibir o atributo $INDEX_ALLOCATION do diretório raiz, verá que "$I30" está listado como seu nome em sua linha "Type code, name", portanto, é isso que você insere como o nome do atributo.
Pressione OK e você verá um despejo hexadecimal do conteúdo do atributo. Queremos ver algo mais inteligível, portanto, selecione o modo de exibição |Entrada de menu do Buffer de Índice NTFS. Você verá a listagem do conteúdo do diretório. Role pela listagem até ver a entrada que tem o nome "TEMP". Se você não vê-lo, a entrada pode estar localizada no atributo $INDEX_ROOT do diretório raiz, um tipo de atributo também associado a diretórios e que sempre tem seu valor armazenado no registro MFT. Entradas raiz de índice e entradas de alocação juntas formam uma estrutura de árvore B+ armazenando todas as entradas de um diretório. Se você precisar exibir o atributo $INDEX_ROOT, basta seguir as mesmas etapas para exibir esse atributo como fez para exibir o atributo $INDEX_ALLOCATION. Ao rolar por um buffer de índice, você pode encontrar linhas duplas de asteriscos: eles designam o fim de um buffer de índice e o início do próximo.
Depois de encontrar a entrada do diretório TEMP, anote sua FRS (Referência de Arquivo). Selecione Ler|Registro de Arquivo NTFS e insira o FRS do TEMP. Agora você está examinando o registro MFT para o diretório TEMP. Queremos encontrar o arquivo OUT.TXT, portanto, teremos que examinar o conteúdo do TEMP para encontrá-lo. Exiba o atributo $INDEX_ALLOCATION (ou $INDEX_ROOT) do diretório TEMP, alterne para exibir os dados como um buffer de índice NTFS e localize o arquivo OUT.TXT. Lembre-se de inserir o FRS do TEMP como o número FRS base na caixa de diálogo de seleção de atributo. Se você acabou de criar o TEMP, ele terá apenas um $INDEX_ROOT (se você digitar algo incorretamente, terá o prazer de ver nas caixas de diálogo de erro vazias do DiskEdit).
Quando você encontrar OUT.TXT e determinar seu uso de FRS, leia|Registro de Arquivo NTFS para examinar sua entrada MFT. Role para baixo até encontrar o atributo $DATA. Agora você está examinando o local dos dados do OUT.TXT. Como fizemos um arquivo pequeno, os dados são armazenados no registro MFT. Se você tentar exibir o atributo de $DATA OUT.TXT usando DiskEdit, não verá nada, pois DiskEdit não mostra corretamente os dados residentes (um dos muitos bugs do DiskEdit). Portanto, copie um arquivo de texto largish (> 2KB) para \TEMP\ OUT.TXT. Agora você pode exibir os dados de OUT.TXT de uma das duas maneiras: você pode examinar o início dos dados (ou todos eles, se eles estiverem armazenados contíguamente no disco) usando Ler|Cluster NTFS e especificação do primeiro valor "lcn" que você vê no atributo "Extent List" do $DATA OUT.TXT; ou você pode usar Read|Atributo NTFS e insira "$DATA" como o tipo de atributo e nada (como em não digite nada nesse campo) como o nome do atributo.
Listas de extensões descrevem o local dos dados não residentes de um atributo. Cada bloco contíguo de dados de até 16 clusters de comprimento é descrito por uma entrada de lista de extensão. Uma entrada de lista de extensão especifica um número de cluster virtual (vcn), um número de cluster lógico (lcn) e um comprimento de execução. Um Vcn é o cluster dentro do arquivo no qual os dados descritos pela entrada são iniciados. Um Lcn designa o cluster lógico em que os dados são armazenados no disco e o runlength é o número de bytes de dados de atributo nesse local (lembre-se, DiskEdit está mostrando valores hexadecimal).
Eu o orientei no longo caminho para encontrar o registro MFT do arquivo OUT.TXT mostrando como verificar o conteúdo do diretório. No entanto, há um atalho: selecione Crack|Caminho NTFS e insira TEMP\OUT.TXT. Você verá o FRS do OUT.TXT e poderá usar Ler|Registro de Arquivo NTFS para ir direto para ele.
Isso me leva ao fim da minha cartilha DiskEdit. Eu encorajo você a brincar com essa ferramenta bacana navegando em suas unidades FAT ou NTFS. É altamente improvável que você encontre ocasiões para usar DiskEdit para modificar dados a fim de tirar o disco de um congestionamento, mas se você estiver curioso sobre o formato NTFS no disco (o formato FAT está bem documentado), essa é a ferramenta perfeita para investigar.
O QUE ESTÁ POR VIR
EXPLOSÃO DA API WIN2K
Embora haja apenas 4 NOVAS APIs exportadas no modo kernel que fizeram sua estreia no RC2, o número total de APIs que a Microsoft introduziu desde o NT 4.0, tanto no kernel quanto nas DLLs principais do Win32, explodiu. No próximo mês, vou lhe dizer exatamente quantas NOVAS APIs existem e onde elas apareceram, e infelizmente ao mesmo tempo dar às pessoas que acreditam que Win2K é um monstro inchado alguma grande munição para seus discursos alt.advocacy.linux Usenet.
Obrigado por ler o Boletim Informativo dos Sistemas Internos.
Publicado quarta-feira, 20 de outubro de 1999 19:10 pm por ottoh
[Arquivo de Boletins Informativos ^] [< Volume 1, Número 4] [Volume 2, Número 1 >]