[Arquivo de Boletins Informativos ^] [< Volume 2, Número 2] [Volume 2, Número 4 >]
O Boletim Informativo de Sistemas Internos Volume 2, Número 3
http://www.sysinternals.com
Copyright © 2000 Mark Russinovich
14 de junho de 2000 - Nesta edição:
EDITORIAL
NOVIDADES NO SYSINTERNALS
- Regmon v4.25
- ListDlls v2.22
- TDImon v1.0
- AutoRuns v1.1
- LDMDump v1.0
- Colunas internas de abril/junho
INFORMAÇÕES INTERNAS
- Histórico de build do Windows NT
- Resolução de temporizador do Windows NT/2000
- Remapeando o teclado
- Mapeamento de memória do sistema seguro
- Log oculto do sistema de arquivos do Windows 98
- WinDev '00 West
O QUE ESTÁ POR VIR
- Chaves do Registro do Windows 98 "Seguras"
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 Professional Edition (funcionalidade avançada de disco de inicialização para Windows NT) e Recuperação Remota.
O TCPView Pro recém-lançado permite monitorar a atividade TCP/IP nos sistemas Windows NT 4.0, Windows 2000 e Windows 95/98. Ao contrário das ferramentas internas de monitoramento de TCP/IP que vêm com o Windows (como netstat), o TCPView Pro mostra qual processo está associado a cada endereço TCP/IP, facilitando a determinação de qual aplicativo é responsável por conexões e atividades específicas. O TCPView Pro fornece uma exibição dinâmica e uma exibição estática. A exibição estática mostra os endereços IP locais abertos no momento, o processo associado a cada ponto de extremidade e o endereço IP remoto ao qual um ponto de extremidade está conectado. A exibição dinâmica, não disponível com nenhum outro utilitário, permite que você veja a atividade TCP/IP por processo em tempo real.
Obter informações sobre preços e baixar uma versão de avaliação de 14 dias em http://www.winternals.com/products/tcpview.shtml.
Olá, pessoal.
Bem-vindo ao boletim do Systems Internals. Atualmente, o boletim informativo tem 22.000 assinantes.
Dave Solomon e eu estamos nos estágios finais de encerrar "Inside Windows 2000, 3rd Ed.", o que significa que o livro estará disponível em meados de agosto em vez do final de julho (não seria um produto da Microsoft sem um deslize na data do envio). Agora que o livro está em forma finalizada, posso dar-lhe um resumo sobre o que está nele. Primeiro, ele tem cerca de 50% mais conteúdo do que a edição anterior e inclui quatro novos capítulos. Este é o sumário:
- Introdução
- Arquitetura
- Mecanismos do sistema
- Inicialização e Desligamento
- Mecanismos de gerenciamento
- Processos e threads
- Gerenciamento de memória
- Segurança
- Sistema de E/S
- Armazenamento
- Gerenciador de Cache
- Sistemas de Arquivos
- Rede
Assim como a 2ª edição, o livro está cheio de experimentos que demonstram os conceitos que descrevemos. O livro também inclui um CD que tem uma cópia de todo o site do SysInternals, além de um punhado de ferramentas que usamos em experimentos.
Duas ferramentas que escrevi especificamente para o livro foram muito bem recebidas pelos revisores de livros. O primeiro é denominado LiveKD e permite executar qualquer um dos depuradores de kernel do Windows 2000 (i386kd, kd, WinDbg) em um sistema dinâmico. Isso significa que você inicia o LiveKd, especificando qual depurador deseja hospedar e insere o depurador e disponibiliza todos os comandos do depurador que você faria se estivesse depurando um despejo de memória. Praticamente todos os experimentos baseados em depurador no livro podem ser executados usando o LiveKD, o que significa que você não precisa de um segundo sistema ou um cabo serial para executá-los.
A segunda ferramenta é uma extensão de monitor de performance que permite exibir os valores dinâmicos de qualquer variável de kernel. Se você quisesse monitorar a quantidade de reserva de memória não paginável em uso com PerfMon, por exemplo, selecionaria a variável MmAllocatedNonPagedPool.
Vou informá-lo no boletim informativo quando o livro sair, mas você pode pré-encomendar agora por meio do link Amazon.com em www.sysinternals.com/links.htm. Como de costume, passe o boletim informativo para amigos que você acha que pode acharia interessante.
Agradecemos!
-Mark
NOVIDADES NOS SISTEMAS INTERNOS
REGMON V4.25
Esta atualização mais recente para a ferramenta de monitoramento do Registro Regmon inclui suporte para o novo KeyNameInformation tipo de consulta do Windows 2000 para os serviços do sistema ZwEnumerateKey e ZwQuerykey. Essa funcionalidade não é exportada para uso por aplicativos Win32, mas é usada pelas funções do Registro no ADVAPI32 como parte do uso do sistema de hives do Registro de Classe por usuário.
Há duas maneiras pelas quais os aplicativos Win32 no Windows 2000 podem abrir a parte Registro de Classe do Registro: eles podem especificar HKEY_CLASS_ROOT ou especificar HKLM\Software\Classes. O primeiro retorna um identificador para a chave de classe por usuário combinada com a chave de classe global e o segundo retorna um identificador apenas para as informações globais. A função registro ADVAPI32 só pode determinar qual usuário especificou examinando o nome subjacente do identificador de chave do Registro passado por um usuário, daí o requisito para o novo tipo de consulta. Consulte a documentação do SDK em RegOpenKeyEx para obter mais informações.
Baixe o Regmon v4.25 em http:www.sysinternals.com/regmon.htm.
LISTDLLS V2.22
Quando um desenvolvedor cria uma DLL (biblioteca de vínculo dinâmico), ele informa ao vinculador o "endereço base" da DLL, que é o endereço para o qual o vinculador cria informações de endereço relativo no arquivo de imagem da DLL. Se uma DLL for carregada em um endereço diferente de seu endereço base, o carregador deverá corrigir todos os endereços relativos na imagem DLL carregada para considerar a diferença.
Essas correções, ou realocações, podem aumentar o tempo de inicialização de um aplicativo, portanto, os desenvolvedores obviamente querem impedir que as realocações ocorram. No entanto, é entediante examinar a saída de um programa como ListDLLs, comparando endereços de carga com endereço base. Portanto, fiz com que a versão 2.22 de ListDLLs aceitasse uma nova opção, -r, que o fez observar DLLs realocadas em sua saída.
Baixar o ListDLLs v2.22 em http://www.sysinternals.com/listdlls.htm.
TDIMON V1.0
O TDImon é o mais recente no poderoso pacote de ferramentas de monitoramento do SysInternals, mostrando a atividade TCP e UDP em seu sistema à medida que ele ocorre. A ferramenta usa seu nome do fato de monitorar a atividade TCP e UDP na interface para a pilha TCP/IP, e essa interface é chamada de TDI (Interface de Driver de Transporte). Todas as atividades TCP e UDP de aplicativo e driver devem passar por essa interface, o que significa que nenhuma atividade TCP ou UDP desliza por TDImon não detectada.
A TDIMon compartilha a mesma GUI que seus primos, Filemon, Regmon, Portmon e DebugView e, assim como as outras ferramentas de monitoramento, mostra os nomes dos processos que executam atividades, carimbos de data/hora e tem capacidade de filtragem e realce. Isso torna o TDIMon uma ferramenta ideal de solução de problemas de rede para administradores e a ferramenta de depuração TCP/IP para desenvolvedores de aplicativos. O TDImon funciona no Windows 95, 98, NT 4 e Windows 2000.
Baixar o TDImon v1.0 em http://www.sysinternals.com/tdimon.htm.
LDMDUMP V1.0
O Windows 2000 inclui um novo formato de particionamento chamado particionamento flexível que supera algumas das desvantagens do particionamento no estilo MS-DOS que todos os sistemas operacionais Windows usaram até agora. Um componente chamado LDM (Gerenciador de Disco Lógico) gerencia volumes em discos formatados com partições suaves, que são chamados de discos dinâmicos (discos com particionamento de estilo MS-DOS são chamados de discos básicos). Além de serem mais robustos devido ao espelhamento de partição que eles implementam, os discos dinâmicos têm a vantagem de que você pode criar volumes de várias partições sem precisar reinicializar o sistema para que eles sejam reconhecidos e montados por drivers do sistema de arquivos.
A Microsoft não documentou o formato do banco de dados de particionamento LDM – na verdade, como eles licenciaram a tecnologia da Veritas, que usou o mesmo banco de dados em seu software de gerenciamento de volume UNIX, os contratos de licenciamento podem impedir a Microsoft de documentá-la. Eventualmente, pode haver uma interface IOCTL Win32 para o LDM, mas enquanto isso, descobri o formato e escrevi uma ferramenta chamada LDMDump que você pode usar para emparelhar dentro do banco de dados de um disco dinâmico. O LDMDump apresenta aproximadamente as mesmas informações que a ferramenta DmDiag do Kit de Recursos do Windows 2000, mas o LDMDump apresenta as informações de uma maneira muito mais limpa. Não ofereço código-fonte para essa ferramenta no momento, mas se você estiver interessado em licenciar para seus próprios aplicativos, entre em contato comigo.
Leia sobre o Banco de Dados LDM na coluna "Inside Storage, Part 2" da Revista Windows 2000 em http://www.sysinternals.com/publ.htm.
Baixar o LDMDump v1.0 em http://www.sysinternals.com/ldmdump.htm.
AUTORUNS V1.1
Talvez você já esteja familiarizado com AutoRuns, que lançamos nos últimos dois meses. AutoRuns mostra as configurações de execução automática para cada local no Registro e .INI arquivos em que essas informações são especificadas (ou assim pensamos). Os comentários dos usuários nos mostraram alguns locais em que as AutoRuns estavam ausentes, e esta versão mais recente agora os mostra.
Baixar AutoRuns v1.1 em http://www.sysinternals.com/misc.htm.
COLUNAS INTERNAS DE JUNHO/JULHO
Você já se perguntou exatamente como os serviços Win32 diferem dos aplicativos Win32 padrão? Ou talvez você esteja curioso sobre o que faz a sequência de inicialização ou desligamento do NT demorar tanto. Respondo a essas perguntas e muito mais na minha série de duas partes junho/julho sobre serviços Win32 no Windows 2000 Magazine.
Na Parte 1, levo você para dentro da estrutura de um serviço Win32, explicando como eles aceitam comandos de aplicativos cliente. Em seguida, começo a descrever o SCM (Gerenciador de Controle de Serviço), que é responsável por gerenciar serviços Win32, incluindo a inicialização e o desligamento. Na Parte 2, conclua minha descrição do processo de inicialização do serviço, que ocorre durante a inicialização do sistema e, em seguida, informe como o SCM desliga os serviços. Também dou uma olhada nas melhorias que a Microsoft fez no SCM no Windows 2000 e levo você para dentro da ferramenta SrvAny Resource Kit.
Os assinantes do Windows 2000 Magazine podem ler as colunas online em http://www.sysinternals.com/publ.htm.
INFORMAÇÕES INTERNAS
HISTÓRICO DE BUILD DO WINDOWS NT
Como você aprendeu com boletins informativos anteriores, o número de build do Windows NT (agora Windows 2000) é incrementado todos os dias quando a equipe de build gera um novo build com as verificações de código do dia. Usando meus antigos CDs beta e release candidate, bem como a ajuda de outras pessoas que têm usado o Windows NT por mais tempo do que eu, Compilei uma lista dos números de build que correspondem a versões públicas (betas, release candidates e versões completas). Observe que as datas são a data do build, não a data de lançamento do build. Por exemplo, a compilação final do Win2K, 2195, foi feita em dezembro, mas foi lançada ao público em fevereiro.
| Build | Versão | Data |
|---|---|---|
| 297 | PDC | 1992 |
| 340 | NT 3.1 Beta 1 | outubro de 1992 |
| 397 | NT 3.1 Beta 2 | marco de 1993 |
| 511 | NT 3.1. | Julho de 1993 |
| 611 | NT 3.5 Beta 1 | Abril de 1994 |
| 683 | NT 3.5 Beta 2 | Junho de 1994 |
| 756 | NT 3.5 RC 1 | Agosto de 1994 |
| 807 | NT 3.5 | Setembro de 1994 |
| 944 | NT 3.51 Beta 1 | Fevereiro de 1995 |
| 1057 | NT 3.51 | Maio de 1995 |
| 1234 | NT 4.0 Beta 1 | Janeiro de 1996 |
| 1314 | NT 4.0 Beta 2 | Maio de 1996 |
| 1381 | NT 4.0 | Julho de 1996 |
| 1671 | NT 5.0 Beta 1 | Setembro de 1997 |
| 1877 | NT 5.0 Beta 2 | Setembro de 1998 |
| 1946 | Win2K RC0 da Versão Beta 3 | Dezembro de 1998 |
| 2000.3 | Win2K RC1 da Versão Beta 3 | Março de 1999 |
| 2031 | Win2K Beta 3 | Abril de 1999 |
| 2072 | Win2K RC1 | Julho de 1999 |
| 2128 | Win2K RC2 | Setembro de 1999 |
| 2183 | Win2K RC3 | Novembro de 1999 |
| 2195 | Win2K | Dezembro de 1999 |
RESOLUÇÃO DE TEMPORIZADOR DO WINDOWS NT/2000
Embora o Windows NT/2000 forneça serviços, incluindo QueryPerformanceCounter, que permitem medir tempos até a resolução do contador de ciclo Pentium, seus serviços de intervalo de tempo têm uma resolução um pouco menor. Na verdade, a resolução de temporizador padrão é a mesma que o intervalo de relógio do sistema, que é de 10 ms em sistemas x86 uniprocessadores (geralmente são 7,5 ms ou 15ms em sistemas SMP). Os aplicativos podem usar as funções de temporizador multimídia no espaço do usuário para aumentar a resolução para 1ms, mas os drivers estão fora do frio se quiserem resoluções mais altas - até o Windows 2000, ou seja.
O Windows 2000 introduz uma nova função DDK, ExSetTimerResolution, que os drivers podem usar para diminuir o intervalo do temporizador do sistema para 1ms. Quer saber o que acontece sob os bastidores dos temporizadores multimídia e ExSetTimerResolution? Consulte "Dentro de temporizadores de alta resolução do Windows NT" em http://www.sysinternals.com/timer.htm.
MAPEAMENTO DE MEMÓRIA DE SISTEMA SEGURO
Embora estejamos no tópico de novas funções de kernel do Windows 2000 para desenvolvedores de driver, vale a pena mencionar MmGetSystemAddressForMdlSafe. Em versões anteriores do Windows NT, um desenvolvedor de driver que quer obter um ponteiro de espaço de endereço do sistema para o buffer de um usuário ou parte da memória física tinha que passar MDL (Lista de Descritores de Memória) que descrevia o buffer físico para MmGetSystemAddressForMdl.
A criação de um mapeamento virtual no espaço de endereço do sistema usa um recurso chamado System Page Table Entries (System PTEs), em que um PTE do Sistema é necessário para cada página física mapeada. Infelizmente, os PTEs do Sistema são recursos limitados e podem se esgotar se os drivers estiverem mapeando grandes quantidades de memória. O que acontece quando MmGetSystemAddressForMdl não é possível obter os PTEs do sistema necessários? Você acha que isso faria algo útil, como retornar um NULL como o endereço virtual mapeado. Mas não, ele desiste e telas azuis do sistema. Um comportamento como esse reflete mal no driver que está fazendo a solicitação.
O Windows 2000's MmGetSystemAddressForMdlSafe faz o que MmGetSystemAddressForMdl deveria ter feito: ele retorna um NULL se não houver PTEs do sistema suficientes para criar o mapeamento para o buffer. Use essa função para evitar um despejo embaraçoso que aponte para seu driver. Se você tiver um driver executado no NT 4 e no Windows 2000, vale a pena lançar duas versões diferentes, uma para cada plataforma, para que você possa aproveitar essa nova API quando estiver no Windows 2000.
REMAPEANDO O TECLADO
Se você é como eu, você começou em um teclado UNIX em que uma tecla ctrl estava presente no teclado na posição ocupada nos teclados do computador pela tecla caps-lock. Para melhorar minha taxa de digitação e aprender algo sobre o desenvolvimento de driver de dispositivo no Windows 9x e no Windows NT, um dos meus primeiros projetos de driver em ambos os sistemas operacionais foi implementar um driver de remapeamento de teclado. Você pode encontrar a versão do Windows 9x em http://www.sysinternals.com/c2cap95.htm e a versão do Windows NT/2K em http://www.sysinternals.com/ctrl2cap.htm.
No Windows NT/2K, há uma alternativa ao uso de um driver de filtro de teclado. Ao definir entradas de remapeamento de código de verificação no Registro, você pode reprogramar completamente o comportamento do teclado. Na verdade, o Kit de Recursos do Windows 2000 inclui uma ferramenta chamada RemapKey que permite trocar teclas usando uma representação gráfica do teclado. Este artigo no site da Microsoft fala sobre o remapeador de teclado e como ele funciona: http://www.microsoft.com/HWDEV/input/W2kscan-map.htm. Observe que a ferramenta também funciona no NT 4.
Portanto, vamos dizer que você não tem o Kit de Recursos do Windows 2000 e prefere não gastar o dinheiro para ele (eu recomendo que você faça isso, está cheio de todos os tipos de ferramentas e documentação legais). Se esse for o caso, você poderá remapear manualmente o teclado. O artigo da Microsoft que acabei de referenciar informa o formato da chave do Registro em que o driver de teclado procura códigos de remapeamento (HKLM\ SYSTEM\CurrentControlSet\Control\Keyboard Layout\Scancode Map) e este artigo, também disponível na Microsoft, informa os códigos de verificação que correspondem às teclas: http://www.microsoft.com/hwdev/download/desinit/scancode.zip.
Se tudo o que você deseja é trocar o caps-lock e o controle (observe que meus filtros de teclado acabarão totalmente com a tecla caps-lock, pois eu nunca a uso), você pode copiar o texto a seguir (sem incluir os separadores "----") para um arquivo (nomeie-o como swapcaps.reg) e clique duas vezes no arquivo. As configurações serão importadas para o Registro e, após uma reinicialização, entrarão em vigor.
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,03,00,00,00,3a,00,1d,00,1d,00,3a,00,\
00,00,00,00
Se você quiser desfazer o mapeamento, basta excluir o valor do Mapa do Scancode do Registro e reinicializar.
LOG OCULTO DO SISTEMA DE ARQUIVOS DO WINDOWS 98
Você já navegou no diretório do sistema Windows 98 e notou um subdiretório chamado \Windows\Applog? Dentro desse diretório, você provavelmente encontrará arquivos com nomes correspondentes aos de aplicativos executados recentemente e extensões como . LGC e . LGD. Abra um dos arquivos no Bloco de Notas e você verá claramente um rastreamento de atividade do sistema de arquivos, completo com nomes de arquivo, deslocamentos e chamadas abertas e fechadas. Um vírus está gerando esses logs ou é um utilitário secreto incluído no Windows 98 que relata à Microsoft os padrões de uso do aplicativo? Nenhum dos dois (se fosse um dos dois, você estaria lendo sobre isso na imprensa comercial, não no boletim informativo da SysInternals). Sua parte do recurso "carrega seus aplicativos usados com mais frequência até 36% mais rápido" do Windows 98.
Devido à entrada Taskmon no HKLM\Software\Microsoft\Windows\CurrentVersion\Run, o Windows 98 inicia um programa de serviço durante a inicialização denominada Taskmon. O Taskmon carrega um VxD chamado FioLog (\Windows\System\FioLog.Vxd) para instalar um gancho de atividade do sistema de arquivos para que ele possa ver o uso do arquivo durante a inicialização do aplicativo. O Taskmon monitora a atividade do sistema de arquivos de todos os aplicativos executados enquanto eles são iniciados, exceto os listados em HKLM\Software\Microsoft\Windows\CurrentVersion\Taskmon\ExcludeApps. O FioLog registra a atividade do sistema de arquivos de inicialização do aplicativo no diretório Applog. Os arquivos de log que ele cria começam com a extensão . LGA. Não está claro como ele determina quando excluir um log e quando criar um novo para um aplicativo com uma nova extensão com a última letra incrementada. Aqui está uma parte de um arquivo de log de exemplo:
{
o da3034d0 d000 "C:\WINDOWS\NOTEPAD.EXE"
R da3034d0 0 40
R da3034d0 80 f8
R da3034d0 80 1c0
R da3034d0 7000 1000
R da3034d0 6000 e00
o da2b2610 156000 "C:\WINDOWS\SYSTEM\SHELL32.DLL"
R da2b2610 83000 1000
o da2b2f40 45110 "C:\WINDOWS\SYSTEM\SHLWAPI.DLL"
R da2b2f40 3c000 1000
R da2b2f40 3c000 1000
...
As linhas são divididas em quatro campos: o primeiro é o código de operação, em que o está aberto, R é lido e C é fechado. Você não verá um W (para gravação), pois o FioLog registra apenas operações de leitura durante a inicialização do aplicativo para que a inicialização do aplicativo possa ser otimizada. O segundo campo é o ponteiro de arquivo interno. O terceiro e o quarto campos devem ser interpretados de acordo com o código de operação da linha. Se o código de operação for R, o terceiro campo será o deslocamento do arquivo e o quarto campo será o comprimento da leitura. No entanto, se o código de operação for o, o terceiro campo será sinalizadores abertos e o quarto será o nome do arquivo aberto. No exemplo de rastreamento, a abertura de notepad.exe retorna o ponteiro de arquivo da3034d0, que você pode ver sendo usado em operações de leitura subsequentes.
Quando você inicia uma operação de desfragmentação, o programa Defrag.Exe executa um programa chamado CvtApLog (\Windows\System\Cvtaplog.exe) para processar os arquivos de log. CvtApLog usa uma DLL chamada ClusAlgo.Dll (\Windows\System\Clusalgo.dll) para descobrir o posicionamento ideal do cluster, considerando os arquivos de log que lê e registra essas informações em arquivos chamados \Windows\Applog\Applog.d* que orientam o processo de desfragmentação. CvtApLog também gera um arquivo chamado \Windows\Applog\Optlog.txt que resume as otimizações de inicialização do aplicativo ditadas pelos arquivos de log. Aqui estão o conteúdo parcial de um arquivo de Optlog.txt:
Program Launch Optimization Log - Created Tue Jun 13 11:42:52 2000
Programs Eligible for Optimization:
Ord Flag ProgName Uses LastExecDate Program Path
1 RUNDLL32 65 2000.06.13 C:\WINDOWS\RUNDLL32.EXE
2 ATIPTAAB 31 2000.06.13 C:\WINDOWS\SYSTEM\ATIPTAAB.EXE
3 NOTEPAD 22 2000.06.13 C:\WINDOWS\NOTEPAD.EXE
4 PING 9 2000.06.10 C:\WINDOWS\PING.EXE
…
17 IEXPLORE 2 2000.06.01 C:\PROGRAM FILES\INTERNET EXPLORER\IEXPLORE.EXE
Programs Ineligible for Optimization:
Ord Flag ProgName Uses LastExecDate Program Path
18 S GREP 5 2000.06.13 C:\BIN\GREP.EXE
19 S STRINGS 12 2000.06.13 C:\BIN\STRINGS.EXE
20 S ATI2CWXX 31 2000.06.13 C:\WINDOWS\SYSTEM\ATI2CWXX.EXE
Control Parameters:
Use app profile = Yes
Minimum log size = 1000
Maximum no use days = 90
Maximum apps = 50
Flags for Ineligible Programs:
S = Log size smaller than <Minimum log size>
U = Program not used for more than <Maximum no use days>
P = No profile for program
E = Associated program no longer exists
D = Log deleted (may be combined with one of the above)
A capacidade do Windows 98 de mover as partes dos arquivos usados durante o lançamento de um aplicativo para uma área contígua em disco é a tecnologia licenciada pela Microsoft da Intel (para ver isso, execute Defrag.exe manualmente e você receberá o texto "Acelerador de Inicialização de Aplicativo Intel").
WINDEV '00 WEST
WinDev '00 East ocorreu na semana passada para um público recorde de 660 pessoas (isso é tudo o que o hotel poderia conter). Os palestrantes presentes na conferência representam os grandes nomes em todas as áreas de desenvolvimento do Windows, incluindo todos, desde o deus COM Don Box até os especialistas em driver Jamie Hanrahan e Brian Catlin. Minhas sessões incluíam "Windows 2000 Internals", "Advanced Drivers", "Windows NT/2000 File System Drivers" e "Cluster Server".
Se você sente muito por ter perdido, você está com sorte porque você tem uma segunda chance. WinDev '00 West está sendo realizado em Santa Clara, CA de 11 a 15 de setembro, e todos os mesmos palestrantes estarão lá. Vou dar as mesmas sessões, e como no WinDev East, vou dar camisetas SysInternals gratuitas aos participantes que respondem às minhas perguntas ou fazem particularmente perspicazes. Você pode encontrar mais informações em http://www.butrain.com/windev/west/default.htm.
O QUE ESTÁ POR VIR
Chaves do Registro do Windows 98 "Seguras"
Embora o Registro do Windows 98 não dê suporte à segurança, a Microsoft implementou um mecanismo para definir chaves ocultas do Registro. Qual aplicativo usa essa tecnologia furtiva? Internet Explorer, é claro. Da próxima vez, direi quais chaves o IE oculta e como o Windows 98 as implementa.
Obrigado por ler o Boletim Informativo dos Sistemas Internos.
Publicado quarta-feira, 14 de junho de 2000 19:08 por ottoh
[Arquivo de Boletins Informativos ^] [< Volume 2, Número 2] [Volume 2, Número 4 >]