12 de outubro de 1999 - Nesta edição:

  1. O QUE HÁ DE NOVO NOS SISTEMAS INTERNOS

    • NTFS para Windows 98/NTFSDOS Profissional
    • DebugVer v3.21
    • Filemon e Regmon v4.21
    • Diskmon v1.1
    • Sistemas Internos em www.microsoft.com
    • Outubro "NT Internals"
    • Coisas não tão novas
  2. NOTÍCIAS INTERNAS

    • Win2K RC2 DDK lançado
    • Novas APIs Win2K RC Kernel
    • Desenvolvimento de Software '99 Leste
    • Utilização de DiskEdit
  3. O QUE ESTÁ POR VIR

    • Explosão da API win2K

PATROCINADOR: SOFTWARE WINTERNALS

A Newsletter Sistemas Internos é patrocinada pela Winternals Software, na Web http://www.winternals.com. Winternals Software é o principal desenvolvedor e fornecedor de ferramentas avançadas de sistemas para Windows NT/2K. Os produtos de Software Winternals incluem FAT32 para Windows NT 4.0, Comandante ERD (capacidade de boot-disk para Windows NT) e NTRecover.

A Recuperação Remota do Software Winternals permite-lhe aceder às unidades de um computador inabitável via TCP/IP a partir de qualquer lugar da sua empresa. Economize tempo e suporte dólares corrigindo remotamente os problemas de controlador, sistema de ficheiros e configuração que mantêm os sistemas NT ou Win9x fora de linha. Pode até realizar operações remotas de chkdsk ou partição utilizando a Recuperação Remota, o que a torna uma ferramenta versátil de recuperação de desastres. Faça o download de uma versão de teste apenas de leitura gratuita em http://www.sysinternals.com/rrecover.htm , e compre a versão de leitura/escrita em http://www.winternals.com.

Olá a todos,

Bem-vindos à newsletter Sistemas Internos. O boletim tem atualmente 10.000 subscritores.

O lançamento de Windows 2000 (Win2K) parece seguir um padrão de tornar-se iminente e depois ser empurrado para trás. Os últimos rumores são de que estará disponível em fevereiro. E a única informação sobre a data da nave Win2K está em rumores, uma vez que a Microsoft nem sequer está a dizer aos OEMs ou parceiros quando irá enviar. Bem, eles são: "vai enviar quando estiver pronto" (não vou forçar o ditado datado sobre vender vinho em você aqui).

O mais irritante da Microsoft é que a imprensa que geram sobre os seus produtos faz sempre parecer que estão à beira do envio, mesmo quando os produtos são vaporware. O exemplo mais recente é a Millennium, a sucessora de Windows 98. A Microsoft não há muito tempo fez um grande impulso na imprensa como se fosse um produto acabado, pronto para converter todos os seus aparelhos domésticos em dispositivos inteligentes. A ironia é que os artigos pouco tempo depois revelaram que a Microsoft ainda não definiu totalmente o produto, e provavelmente demorará um ano ou mais até o vermos nas prateleiras das lojas.

Este padrão não é novo e não sou o primeiro a escrever sobre isso. Mas isso não me impede de especular quanto da serragem é um plano cuidadosamente orquestrado, e quanto é o resultado de uma total falta de diretores de engenharia de software. Se acreditares no primeiro ângulo, como fazem os teóricos da conspiração, a Microsoft sufoca brilhantemente a concorrência ao tentar os clientes com aquele produto incrível que, se esperarem um pouco mais, fará com que a sua espera valha a pena e obviar a qualquer necessidade de recorrer a um produto que não seja da Microsoft. Este último ângulo diz que a Microsoft nunca aprenderá o processo de desenvolvimento de software, e subestima continuamente o esforço de engenharia e sobrestima a qualidade do código beta.

Estou sentado na cerca sobre a teoria a que atribuo. Na verdade, acho que o padrão se deve a um pouco de ambos. Penso que ajudou a Microsoft a agir como se o Ative Directory estivesse quase pronto há dois anos. Certamente há clientes que teriam recenseado os Serviços de Diretório Novell há muito tempo se soubessem com antecedência quanto tempo teriam de esperar pelo Win2K. Por outro lado, a Microsoft tem recebido repetidos olhos negros na imprensa por prometer a entrega de produtos e depois atrasar. Acho que a gestão da Microsoft não entende como é difícil reproduzir, isolar e corrigir os últimos 5% dos bugs.

Por falar nas práticas de desenvolvimento da Microsoft, o seu esquema de nomeação pré-lançamento é um dos mais desconcertantes que já vi. As suas Betas são realmente Alfas e os seus candidatos a lançamento são na verdade Betas. E mesmo usar estas definições é um estiramento: a Microsoft não tem qualquer problema em arrancar funcionalidades do seu software ao passar de um Candidato de Lançamento para outro, ou mesmo adicionar novas. Fizeram isso com o NT 4.0 e estão a fazê-lo com o Win2K. Essa prática certamente não acelera um ciclo de libertação.

Então, o navio Win2K vai em fevereiro? Acho que estamos a ver a luz ao fundo do túnel. Afinal, há apenas um punhado de novas APIs no RC2...

Como seguimento à última newsletter onde falei sobre a confusão da sigla na Microsoft, o leitor George Janczuk encontrou outro exemplo. Na secção intitulada: "Estendendo-se ao Mainframe Transaction-Processing World", o artigo http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm refere-se ao CISC - Conjunto de Instruções Complexos. É óbvio para qualquer pessoa familiarizada com aplicações de computador principal que o acrónimo pretendido é CICS - Sistema de Controlo de Informação do Cliente. Uma sequência de letras invertidas e estás numa área de tecnologia totalmente diferente.

Como sempre, por favor, passe o boletim informativo para amigos que acha que pode achar interessante.

Obrigado!

- Marca

O QUE HÁ DE NOVO NOS SISTEMAS INTERNOS

NTFS PARA WINDOWS 98/NTFSDOS PROFISSIONAL

Finalmente conseguimos. Desde que o Bryce e eu lançámos o NTFSDOS 1.0 na primavera de 1996, temos procurado o Santo Graal de Windows compatibilidade do sistema de ficheiros: ler/escrever acesso para NTFS a partir de Windows 9x e DOS. Há muito tempo determinámos que a engenharia inversa do formato NTFS e a escrita de um motorista para este complexo sistema de ficheiros de diário seria uma proposta difícil e arriscada. Mesmo que se determine precisamente todas as nuances do formato, uma atualização ao formato, como o NTFS v5.0 da Win2K, requer um esforço de engenharia e desenvolvimento invertido inteiramente novo. Além disso, validar a correção de um controlador de sistema de ficheiros para um formato tão complexo como o do NTFS é uma proposta assustadora.

Então nós fizemos batota.

A NTFS para Windows 98 fornece acesso completo de leitura/escrita às unidades NTFS a partir de Windows 95 ou Windows 98, e o NTFSDOS Professional fornece acesso completo de leitura/escrita NTFS a partir de DOS. Nem o NTFS para Windows 98 nem o NTFSDOS Professional têm qualquer conhecimento do formato do sistema de ficheiros NTFS. Em vez disso, confiam no condutor do NTFS de uma instalação Windows NT ou Windows 2000 para implementar esse conhecimento. Ambos os utilitários usam a mesma base de código que serve como invólucro ambiental para o controlador do sistema de ficheiros NTFS. O NTFS para Windows 98 fornece uma interface para o sistema de ficheiros Windows 9x API acima do NTFS, e os serviços de disco Windows 9x abaixo do NTFS. A interface NTFS para Windows 98 apresenta ao NTFS parece o ambiente nativo Windows NT/2K da NTFS, completo com IRPs, o I/O Manager, o Gestor de Cache, dispositivos de disco estilo NT e outros subsistemas NT/2K com os que o NTFS interage.

O NTFSDOS Professional funciona da mesma forma que o NTFS para Windows 98, exceto que interliga NTFS aos serviços DOS acima e BIOS Interrompe 13 serviços de disco abaixo. Para ajudar a criar o ambiente semelhante ao NT/2K contamos com muitas funções dentro do NTOSKRNL, o ficheiro kernel NT/2K. Ambos os utilitários carregam NTOSKRNL em conjunto com o NTFS, de modo que o NTFS pode utilizar diretamente os serviços nativos do kernel.

Divertimo-nos tanto a construir o ambiente NTFS que fomos um passo mais além: fizemos o mesmo com o utilitário chkdsk da NT, Autochk. NTFSDOS Professional e NTFS para Windows 98 vêm com um utilitário chkdsk NTFS chamado NTFSCHK. A NTFSCHK trabalha no mesmo principal que o invólucro do sistema de ficheiros NTFS, onde cria um ambiente nt-like para o programa Autochk de modo que o Autochk funciona sob Windows 95/98 e DOS. O resultado deste truque é o suporte completo de leitura/escrita NTFS para Windows 95/98 e para dos dos.

Você pode baixar uma versão gratuita do NTFS para Windows 98 http://www.sysinternals.com/ntfs98.htm e uma versão gratuita do NTFSDOS Professional emhttp://www.sysinternalscom/ntfspro.htm. Pode adquirir as versões completas de leitura/escrita de ambas as ferramentas na Winternals Software, http://www.winternals.com.

DEBUGVIEW V3.21

DebugView é um monitor de saída de depurg que captura a saída de depurg kernel e Win32 sob Windows 95, Windows 98, NT 4.0 e Windows 2000. Tem capacidades avançadas de filtragem, destaque e registo, e pode até capturar a saída de depuração de um sistema através de uma rede. O seu mais recente lançamento, 3.21, introduz a capacidade de monitorizar a saída de OutputDebugString de 16 bits sob 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 sistema de ficheiros e serviços de espionagem do Registo para Windows 95, 98, NT 4.0 e Win2K. Eles continuam a evoluir com novas funcionalidades de usabilidade e com o lançamento 4.21 (Filemon e Regmon têm números de versão sincronizados) introduzem uma filtragem mais avançada com listas de filtros recentes, a capacidade de definir um filtro de destaque (com até cores personalizadas), fonte personalizada, suporte de prancheta e mais teclas quentes compatíveis com CUI. O código fonte do controlador também foi reformulado e inclui validação de parâmetros mais robusta nas funções de interface GUI.

Baixar Filemon v4.21 at http://www.sysinternals.com/filemon.htm e Regmon v4.21 em http://www.sysinternals.com/regmon.htm.

DISKMON V1.1

Diskmon é uma ferramenta que monitoriza e exibe atividade lógica e física do disco. A versão 1.1 atualiza o Diskmon para trabalhar com Windows 2000 e introduz novos melhoramentos de usabilidade. Além disso, Diskmon agora interpreta um grande número de códigos de controlo de I/O de armazenamento em massa, traduzindo os seus códigos hexadémicos em representações de texto na janela de saída diskmon.

Diskmon v1.1 não só funciona como um monitor de disco, como também pode usá-lo como uma luz de disco baseada em software. Quando o coloca no modo de luz de disco, o Diskmon minimiza-se na bandeja do sistema como uma luz verde quando há acesso de leitura de disco e vermelho quando há acesso de escrita de disco.

Baixar Diskmon v1.1 em http://www.sysinternals.com/diskmon.htm.

SISTEMAS INTERNOS NA WWW.MICROSOFT.COM

Tendo em conta a história da Systems Internals (anteriormente NT Internals), é realmente uma grande lisonja que a Microsoft refere sysinternals.com como um recurso para os seus clientes. Há um número crescente de artigos da Microsoft Knowledge Base que apontam para os utilitários Systems Internals. Aqui estão as últimas:

  • Q183060 INFO: Guia de resolução de problemas para 80004005 & outras mensagens de erro http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
    Este artigo descreve que pode utilizar o Filemon para verificar a causa dos erros de acesso aos dados no OLE DB, ActiveX Objetos de Dados e Serviço de Dados Remotos.

  • Q196453 - Resolução de problemas NTVDM e ERROS de Startup WOW http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
    Este artigo também aponta para filemon como uma ferramenta para determinar que ficheiros em falta estão a causar erros de arranque para nTVDM (o ambiente de compatibilidade Win16/DOS em NT).

  • Q216368 - PRB: Violação de acesso durante a configuração da aplicação quando o ficheiro 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 configuração gerados por Visual Basic Assistente de Configuração e Assistente de Implementação.

  • Q232830 - HOWTO: Determine a propriedade do cabo de ficheiro http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
    O HandleEx recebe novamente a referência neste artigo que discute saber que processo tem um ficheiro ou diretório aberto.

OUTUBRO "NT INTERNALS"

A minha coluna "NT Internals" na edição de outubro da revista NT Windows é "Inside Win2K Reliability Enhancements, Part 3". Este terceiro de uma série de três partes descreve duas poderosas funcionalidades win2K que ajudam os desenvolvedores e administradores a identificar os condutores de buggy: a memória de kernel protegida por escrito e o Verificador de Condutor.

Os leitores russos podem agora ler os meus artigos na sua língua nativa. Dirija-se à edição russa da revista NT Windows http://www.osp.ru/win2000/ e confira a primeira coluna NT Internals traduzida, Inside the Boot Process ( Inside the Boot Process).http://www.osp.ru/win2000/1999/10/59.htm). Graças a Ivan Rouzanov por me ter informada sobre isto.

A partir do início de agosto, as versões on-line de Windows artigos da NT Magazine só estão acessíveis a assinantes, e os artigos são publicados on-line com cada nova edição. Se ainda não subscreveu, consulte o link de subscrição http://www.sysinternals.com/publ.htm para obter o desconto de subscrição Systems Internals.

COISAS NÃO TÃO NOVAS

WinObj é uma ferramenta poderosa para explorar o Windows espaço de nomes do objeto NT/2K. O espaço de nomes object é um dos três espaços de nome em NT/2K: o espaço de nome do objeto, o espaço de nomes de registo e o espaço de nome do sistema de ficheiros. Você chega ao registro e espaço de nomes de sistema de ficheiros através de objetos no espaço de nomes objeto. Por exemplo, quando um programa Win32 abre a chave de HKEY_LOCAL_MACHINE\Software\Microsoft registo, a biblioteca ADVAPI32.DLL transforma o nome antes de ligar para \Registry\Machine\Software\Microsoft o serviço kernel NtCreateKey . Se olhar para a raiz do espaço de nome object no WinObj, verá um objeto de tipo "chave" chamado Registo. O nome de registo corresponde ao primeiro componente do nome chave e assim o Gestor de Objetos NT/2K passa o resto do \Machine\Software\Microsoft nome, para o subsistema que define o objeto chave. O subsistema de kernel do Gestor de Configuração mantém o Registo e os objectos-chave, pelo que analisa o resto do nome para localizar a chave desejada.

Pode explorar o espaço de nomes do Objeto e visualizar ou definir propriedades de segurança de objetos usando o WinObj. Baixar Winobj em http://www.sysinternals.com/winobj.htm. Discuto o espaço de nomes do Object Manager e o WinObj na minha coluna NT Internals de outubro de 1997, "Inside the Object Manager". Siga um link para a versão on-line do colum em http://www.sysinternals.com/publ.htm.

NOTÍCIAS INTERNAS

WIN2K RC2 DDK LANÇADO

Você pode baixar o lançamento Win2K RC2 do Kit de Desenvolvimento de Dispositivos da Microsoft (DDK) agora em http://www.microsoft.com/ddk/ddkRC2.htm. Pode descarregar o kit gratuitamente ou navegar na documentação on-line.

NOVO WIN2K RC2 KERNEL APIS

As coisas parecem estar a estabilizar no último núcleo win2K. Existem apenas quatro novas APIs de kernel exportadas em RC3, em oposição a cerca de uma dúzia que apareceu (e outra meia dúzia que desapareceu) indo de Beta 3 para RC1. Várias das novas funções são um pouco interessantes, por isso decidi documentá-las para si. A primeira é MmGetSystemRoutineAddress , e embora não documentado o seu protótipo está incluído no ficheiro de cabeçalho ntddk.h do RC2 DDK:

NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
    IN PUNICODE_STRING SystemRoutineName
    );

A sua utilização é tão simples quanto parece. Passe em nome de uma função que reside em NTOSKRNL.EXE ou HAL.DLL e receberá de volta o seu endereço de ponto de entrada. Esta função é realmente inútil no primeiro lançamento do Win2K, mas pode tornar-se muito útil na estrada, e é uma função que a Microsoft deveria ter incluído na primeira versão de NT (3.1). Tal como GetProcAddress no espaço de utilizador para aplicações Win32, esta função permite que um condutor verifique dinamicamente a disponibilidade de uma API. Se a Microsoft adicionar novas APIs aos pacotes de serviço Win2K (e tenho a certeza que o farão), os controladores podem ser escritos para tirar partido das APIs, mas também para falhar graciosamente em versões mais antigas do Win2K ou para funcionar num modo em que não utilizem as APIs. A chave para um condutor poder fazê-lo é a capacidade de verificar a presença das APIs após o carregamento. Sem esta funcionalidade, o controlador tem de se ligar estáticamente às funções que utiliza e, se as funções não estiverem presentes quando o condutor carrega, o carregador de núcleo reporta um erro feio ao utilizador e não carrega o controlador.

A segunda nova API MmGetPhysicalMemoryPages é. Mais uma vez, o seu protótipo está no RC2 ntddk.h, mas não está documentado. O 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;

Esta função devolve uma série de PHYSICAL_MEMORY_RANGE entradas com a extremidade da matriz marcada por uma entrada que tem 0 para ambos BaseAddress e NumberOfBytes . É MmGetSystemRoutineAddress uma API muito simples. Devolve-lhe uma descrição de toda a memória física que o Win2K sabe. Win2K suporta a adição e remoção da memória no voo com as MmAddPhysicalMemory APIs e MmRemovePhysicalMemory APIs. Isso motiva a razão para a existência de uma API que permite consultar os intervalos de memória. MmAddPhysicalMemory foi adicionado no RC1 e MmRemovePhysicalMemory no RC2. Ambas as funções são também protótipos em ntddk.h.

Quais são as outras novas APIs do RC2? PoShutdownBugCheck e RtlInvertRangeList. PoShutdownBugCheck permite-lhe falhar o sistema e executar uma ação relacionada com a energia como suspender. É usado em alguns lugares pelo núcleo RC2. As gamas são especificações genéricas de início que são definidas pelo utilizador e suportadas por uma série de APIs de kernel para gerir, classificar e iterar sobre elas. Os árbitros de recursos Plug-and-Play Win2K usam-nos para rastrear e organizar os requisitos de recursos de hardware. Mesmo que as APIs da lista de gama não estejam documentadas, todos os seus protótipos e definições de estrutura estão incluídos em ntddk.h, pelo que poderá utilizar a API para gerir os seus próprios dados orientados para o início.

Fique atento para mais diversão com APIs não documentados em newsletters subsequentes.

DESENVOLVIMENTO DE SOFTWARE 99 LESTE

A edição de 1999 da Costa Leste do Desenvolvimento de Software está a decorrer em Washington D.C. de 8 a 12 de novembro. Apresento três palestras no último dia: O que há de novo em Windows 2000 Para Desenvolvedores, Inside the Windows NT/2000 Blue Screen, e Inside Windows NT/2000 Networking. Além disso, Dave Solomon, autor de Inside Windows NT 2nd Edition e um vizinho (ele vive a escassos 20 minutos de mim em, de todos os lugares, Danbury, CT), e eu estou a organizar uma mesa redonda interna Windows NT/2K. Estaremos juntos para responder às suas perguntas mais difíceis sobre Windows internos NT/2K. Diga olá e mencione o boletim informativo e eu lhe darei uma t-shirt gratuita da Systems Internals!

Visite o web site de desenvolvimento de software em http://www.sdexpo.com.

USANDO DISKEDIT

Podes não saber, mas há um utilitário de editor de discos para Windows NT no estilo da venerável Edição de Disco Norton para dos DOS. Além disso, a utilidade compreende a FAT e a NTFS e é gratuita. Aparentemente, a Microsoft enviou o DiskEdit acidentalmente, uma ferramenta que deve ser uma ferramenta interna de depuração para as suas equipas de sistemas de ficheiros, no Windows NT 4.0 Service Pack 4 CD. O DiskEdit tem uma interface peculiar que levaria um pequeno manual para documentar, mas vou começar com uma simples passagem. Vou focar-me em usar o DiskEdit para desvendar o formato do sistema de ficheiros NTFS, uma vez que o DiskEdit é a única ferramenta publicamente disponível que conheço que compreende o NTFS.

Primeiro, precisa de obter o DiskEdit do Cd-ROM do Pack de Serviço 4 (SP4). Basta copiá-lo do diretório \i386 para o seu disco rígido. Se quiser utilizar o DiskEdit em Win2K, terá de criar um diretório privado para o mesmo e copiar os seguintes DLLs de um diretório SP4 winnt\system32 (ou CD SP4) para o mesmo diretório que o DiskEdit: IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL e UFAT.DLL. Agora podes começar o DiskEdit.

Para este walkthrough criar um diretório chamado TEMP na raiz de uma unidade NTFS e criar um ficheiro chamado OUT.TXT nesse diretório, digitando o seguinte comando numa janela de comando-prompt com TEMP como o diretório atual: echo hello > out.txt . Selecione a unidade com o seu novo ficheiro OUT.TXT no DiskEdit escolhendo o Ficheiro| Abra o item do menu e introduza a letra da unidade no campo Nome de Volume da caixa de diálogo resultante. Certifique-se de incluir o cólon, p. p. d: " ". Praticamente toda a funcionalidade do DiskEdit requer que tenhas aberto uma unidade.

Vamos localizar o ficheiro OUT.TXT começando no diretório de raiz da unidade NTFS. Selecione a entrada do menu Leia| Registo de ficheiros NTFS para abrir uma caixa de diálogo que permite visualizar qualquer entrada de registo MFT apenas introduzindo o seu número. As primeiras entradas de registo MFT de cada unidade NTFS são reservadas e correspondem a ficheiros de metadados NTFS pré-definidos. Aqui estão as atribuições de números (note que o DiskEdit interpreta todas as entradas 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 veja algumas destas entradas MFT. Vai começar a notar um tema comum: todos eles consistem em atributos como $INDEX_ROOT$FILE_NAME , e $DATA . Está em atributos onde os dados específicos de um ficheiro são armazenados. Quando os dados de atributos são pequenos NTFS armazenam os dados dentro do registo MFT do ficheiro como dados "residentes", e quando os dados são grandes, o NTFS armazena os dados externos ao registo em clusters em discos como dados "não residentes".

Agora introduza o "5" como número do ficheiro e estará a ver o ficheiro do diretório. Vamos ver os ficheiros e diretórios que estão no diretório de raiz, visualizando o atributo do $INDEX_ALLOCATION diretório, um atributo específico para diretórios que registam o conteúdo de um diretório. Para tal, selecione a Leitura| Entrada do menu NTFS Attribute, que abre outra caixa de diálogo. O DiskEdit é sensível ao caso, por isso insira o seguinte precisamente como eu o listei:

        Base Frs Number: 5

Base Frs (Base File Record Segment) é outro nome para número MFT. Introduza a 5 para especificar que pretende ler um atributo a partir do diretório de raiz.

        Attribute Type: $INDEX_ALLOCATION

Isto indica ao DiskEdit que pretende ler os dados de conteúdo do diretório. Recomendo que utilize o menu pull-down para escolher o atributo que deseja, uma vez que o DiskEdit é muito exigente com a forma como o tipo de atributo é introduzido.

        Attribute Name: $I30

Se você ver o $INDEX_ALLOCATION atributo do diretório de raiz você verá que " $I30 " " está listado como o seu nome na sua linha " " " de modo Type code, name que é isso que você insira como o nome do atributo.

Pressione OK e verá uma descarga hexadómica do conteúdo do atributo. Queremos ver algo mais inteligível, por isso selecione o View| Entrada do menu do tampão do índice NTFS. Será apresentado com a listagem do conteúdo do diretório. Percorra a listagem até ver a entrada que tem o nome " TEMP " Se não o vir, a entrada pode estar localizada no atributo do $INDEX_ROOT diretório de raiz, um tipo de atributo também associado a diretórios, e que tem sempre o seu valor armazenado no registo MFT. As entradas de raiz de índice e as entradas de atribuição em conjunto formam uma estrutura de árvore B+ que armazena todas as entradas de um diretório. Se tiver de ver o $INDEX_ROOT atributo basta seguir os mesmos passos para visualizar esse atributo como fez para visualizar o $INDEX_ALLOCATION atributo. Ao percorrer um tampão de índice, poderá encontrar linhas duplas de asteriscos: estes designam o fim de um tampão de índice e o início do seguinte.

Uma vez encontrada a entrada do diretório TEMP, tome nota da sua Referência de Ficheiro (FRS). Selecione Ler| NTFS File Record e insira o FRS da TEMP. Agora estás a ver o registo da MFT para o diretório TEMP. Queremos encontrar o ficheiro OUT.TXT, por isso temos de ver o conteúdo da TEMP para o encontrar. Ver o $INDEX_ALLOCATION$INDEX_ROOT (ou) atributo do diretório TEMP, mudar para ver os dados como um tampão de índice NTFS e localizar o ficheiro OUT.TXT. Lembre-se de introduzir o FRS da TEMP como o número de BASE FRS no diálogo de seleção de atributos. Se acabou de criar o TEMP, então só terá um $INDEX_ROOT (se tiveres o prazer de ver os diálogos de erro vazios do DiskEdit).

Quando tiver encontrado OUT.TXT e determinado o seu frs use Read| NTFS File Record para ver a sua entrada MFT. Desça até encontrar o atributo $DATA. Está agora a ver a localização dos dados do OUT.TXT. Desde que fizemos um pequeno ficheiro, os dados são armazenados no registo da MFT. Se tentar visualizar o atributo de OUT.TXT $DATA usando o DiskEdit, não verá nada, uma vez que o DiskEdit não mostra corretamente os dados residentes (um dos muitos bugs do DiskEdit). Então, copie um ficheiro de > texto largish (2KB) para \TEMP\ OUT.TXT . Agora pode ver os dados OUT.TXT de uma de duas formas: pode examinar o início dos dados (ou todos os mesmos se o seu armazenamento contíguo no disco) utilizando o Read| Cluster NTFS e especificando o primeiro valor "LCN" que vê no atributo de OUT.TXT $DATA "Lista de Extensão"; ou pode utilizar Read| NTFS Atribua e introduza $DATA " como o tipo de atributo e nada (como não digitar nada nesse campo) como o nome de atributo.

As listas de extensão descrevem a localização dos dados não residentes de um atributo. Cada bloco contíguo de dados de até 16 aglomerados de comprimento é descrito por uma extensão de entrada na lista. Uma entrada na lista de extensão especifica um número de cluster virtual (vcn), número de cluster lógico (LCN) e comprimento de execução. Um Vcn é o cluster dentro do ficheiro no qual os dados descritos pela entrada começam. Um Lcn designa o cluster lógico onde os dados são armazenados no disco, e o comprimento de execução é o número de bytes de dados de atributos nesse local (lembre-se, DiskEdit está mostrando-lhe valores hexadémicos).

Atrevi-te a encontrar o registo da MFT do OUT.TXT ficheiro, mostrando-te como digitalizar conteúdos de diretórios. Há um atalho, no entanto: selecione Crack| Caminho NTFS e entrar TEMP\OUT.TXT. Você será apresentado com o FRS de OUT.TXT e você pode usar Read| NTFS File Record para ir direto para ele.

Isso leva-me ao fim do meu primer DiskEdit. Encorajo-o a brincar com esta ferramenta elegante navegando nas suas unidades FAT ou NTFS. É altamente improvável que alguma vez encontres a oportunidade de usar o DiskEdit para modificar dados de forma a tirar o disco de uma compota, mas se tiveres curiosidade sobre o formato NTFS no disco (o formato FAT está bem documentado) esta é a ferramenta perfeita para investigar.

O QUE ESTÁ POR VIR

EXPLOSÃO DE WIN2K API

Embora existam apenas 4 novas APIs exportadas em modo kernel que se estrearam no RC2, o número total de APIs que a Microsoft introduziu desde NT 4.0, tanto no núcleo como nos DLLs do core Win32, explodiu. No próximo mês, vou dizer-vos exatamente quantas novas APIs existem e onde apareceram, e infelizmente ao mesmo tempo dão às pessoas que acreditam que o Win2K é um monstro inchado, algumas grandes munições para os seus discursos alt.advocacy.linux Usenet.


Obrigado por ler a Newsletter Sistemas Internos.

Publicado quarta-feira, 20 de outubro de 1999 19:10 pm by ottoh

[Newsletters Archive ^][ Volume 1, Número 4][Volume 2, Número 1 ]

[Newsletters Archive ^][ Volume 1, Número 4][Volume 2, Número 1 ]

A Newsletter Sistemas Internas Volume 1, Número 5

http://www.sysinternals.com
Copyright 1999 Mark Russinovich