Ele é leve, vem enrustido embutido na última versão e pode economizar alguns page ups/downs no prompt do DOS. Ah, sim, antes que comentem, eu não uso o Tortoise for Bazaar porque instalar shell extensions, só os muito bem feitos. (Do contrário, bem-feito para quem instalou.)

Para exibir a lista de comandos "amigáveis", digite no prompt os comandos do Bazaar filtrando-os para os que começam com "q":

bzr help commands | grep ^q.*

qadd                 GUI for adding files or directories. [qbzr]
qannotate            Show the origin of each line in a file. [qbzr]
qbranch              Create a new copy of a branch. [qbzr]
qbrowse              Show inventory. [qbzr]
qcat                 View the contents of a file as of a given revision. [qbzr]
qcommit              GUI for committing revisions. [qbzr]
qconfig              Configure Bazaar. [qbzr]
qdiff                Show differences in working tree in a GUI window. [qbzr]
qgetnew              Creates a new working tree (either a checkout or full branch) [qbzr]
qgetupdates          Fetches external changes into the working tree [qbzr]
qinfo                 [qbzr]
qinit                Initializes a new (possibly shared) repository. [qbzr]
qlog                 Show log of a repository, branch, file, or directory in a Qt window. [qbzr]
qmerge               Perform a three-way merge. [qbzr]
qpull                Turn this branch into a mirror of another branch. [qbzr]
qpush                Update a mirror of this branch. [qbzr]
qrevert              Revert changes files. [qbzr]
qtag                 Edit tags. [qbzr]

Os que eu mais uso no dia-a-dia são:

qlog e qbrowse

Diversão garantida. Por meio destes simples comandos podemos ver o histórico de commits e navegar pela árvore de pastas e arquivos com a anotação do último commit para cada elemento. Só para ter uma ideia de quanto uso isso, transformei-os em opções do Explorer.

Além da utilidade básica, de quebra, o qbrowse pode te levar para um qlog filtrado, e o qlog pode te levar a um diff gráfico, que é o próximo comando que eu iria mostrar.

qdiff

Coisa linda de Deus. Existem dois modos de exibição, mas o padrão já é show de bola, mostrando as mudanças em todos os arquivos de um commit de uma só vez ou do arquivo/pasta especificado pelo comando. É lógico que é possível especificar qualquer faixa de commits que você quiser ver.

Uma desvantagem desse comando é que ele oculta o resto das linhas do fonte e não mostra de jeito nenhum (pelo menos não descobri ainda como fazer isso). Sendo assim, para uma análise mais detalhada das diferenças no código-fonte sempre use um editor externo que consiga comparar arquivos inteiros (eu uso o WinMerge). Você pode colocar esse comando na forma de um diff personalizado, com o uso do qconfig.

 Bônus

Para quem não sabe fazer comandos de contexto no Explorer sem instalar Shell Extensions, deem uma olhada no REG exportado.  Bom proveito.

Ontem tive que resolver uma "situação" no cliente, e graças ao bom Deus (ele também é programador) existia um Notepad++ na bagagem que levávamos. Além, é claro, do Excel e do sistema batch do Windows.

O problema consistia basicamente em usar a saída do RegMon para identificar e restaurar algumas modificações que danificavam a instalação do Internet Explorer. O sistema de reparo do IE não existia no cliente, pois ele estava sem Service Pack (bem-vindo ao mundo real), mas podíamos nos guiar através dele na nossa máquina virtual para saber o que faríamos. O estrago era feito durante o registro e/ou desregistro de um componente COM.

Aliás, não, eu não preciso usar o onipresente e onipotente Process Monitor para resolver um detalhezinho no registro. Você talvez precise, já que a Microsoft já tirou o Reg e o File de circulação.

Para iniciar, filtramos os resultados do RegMon para apenas capturar escritas no registro, não importando se falharam ou deram resultado.

A partir disso executamos o registro e desregistro do componente, além da restauração do IE6, responsável por limpar a bagunça. O processo responsável por registrar componentes é o regsvr32 e o responsável por limpar a bagunça, rundll32.

Tendo a saída do RegMon exportada para formato texto, abrimos no Excel e filtramos o conteúdo pelo nome do processo. Note que existem duas instâncias de regsvr32 para usar, pois não sabemos em qual delas é danificado o registro.

Para cada um dos filtros copiamos apenas o endereço da chave alterada para dois arquivos texto: regsvr32.txt e ierestore.txt. Usaremos esse primeiro para encontrar ocorrências no segundo, provando que um modifica o que o outro consertou.

Existe um comando muito simplório em batch Windows que é o aplicativo find. Através dele podemos encontrar a ocorrência de uma string em um arquivo. Para transformar todas aquelas linhas do registro do arquivo regsvr32 em comandos find poderíamos elaborar algumas colunas no Excel ou usar o Notepad++ e suas macros, mais rápidas.

Para quem não conhece macros, saiba que elas são muito úteis. Às vezes até mais úteis que "regexes", pois não é necessário pensar muito na expressão a ser usada. Macros apenas repetem os movimentos do teclado que fazemos enquanto as estamos gravando. Por exemplo, eu tenho o meu monte de linhas de registro assim:

HKLM\SOFTWARE\Microsoft\Cryptography\RNG
HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed
HKCR\AppID\{EE62DE09-3A23-46DB-8FA2-266088F329CD}
HKCR\AppID\{EE62DE09-3A23-46DB-8FA2-266088F329CD}\(Default)
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{C322BA70-E3E7-4737-821C-D25378A3F830}
HKCR\CLSID\{684E2452-19E1-42CC-9C93-A83044BA1AF2}
HKCR\CLSID\{684E2452-19E1-42CC-9C93-A83044BA1AF2}\Programmable
...

Quero transformar cada linha em um comando find. Iniciou a gravação da macro no início da primeira linha e digito o seguinte (em pseudo-alguma-coisa):

find, espaço, abre aspas, end, fecha aspas, espaço, ierestore.txt, linha abaixo, home

find "HKLM\SOFTWARE\Microsoft\Cryptography\RNG" ierestore.txt
HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed
HKCR\AppID\{EE62DE09-3A23-46DB-8FA2-266088F329CD}

Pronto. Parar macro. Terei que repetir isso dois milhões de vezes até o final do arquivo. Ora, então mando o Notepad++ repetir a minha macro até o final do arquivo e adio minha tendinite para os próximos anos.

Só preciso agora renomear meu arquivo para .bat e executar. Posso redirecionar a saída da tela para um terceiro arquivo, de onde irei formatar minha lista de entradas no registro que foram adulteradas por ambos os programas (o registro do componente COM e a restauração do Internet Explorer).

Nesse momento podemos ir tomar café. Bem melhor do que ficar horas e horas dando localizar, copiar, colar em todas as entradas do regsvr.

Terminada a operação, abrimos o terceiro arquivo, retiramos as entradas insignificantes (por exemplo, o gerador de sementes de números randômicos) e os cabeçalhos do comando, algo bem fácil já que se trata do mesmo arquivo.

---------- IERESTORE.TXT
---------- IERESTORE.TXT
---------- IERESTORE.TXT
---------- IERESTORE.TXT
...

A próxima tarefa seria analisar cada entrada e ver se ela é relevante. Essa parte foi manual, mas, encontrado um padrão, listamos rapidamente o que poderia estar dando errado e criamos uma lista de entradas para exportar do registro "sadio" a fim de gerar um .REG que corrigiria sistemas danificados.

Algumas passadas no Notepad++ para eliminar linhas duplicadas e algumas passadas pelo cérebro para eliminar chaves redundantes (chave dentro de chave) e tcharam!

...
HKCR\Interface\{3050F2E3-98B5-11CF-BB82-00AA00BDCE0B}
HKCR\Interface\{3050F2E5-98B5-11CF-BB82-00AA00BDCE0B}
HKCR\Interface\{3050F32D-98B5-11CF-BB82-00AA00BDCE0B}
HKCR\Interface\{3050F357-98B5-11CF-BB82-00AA00BDCE0B}
HKCR\Interface\{3050F35C-98B5-11CF-BB82-00AA00BDCE0B}
HKCR\Interface\{3050F37E-98B5-11CF-BB82-00AA00BDCE0B}
HKCR\Interface\{3050F38C-98B5-11CF-BB82-00AA00BDCE0B}
...

O próximo passo para nossa obra-prima é outra macro que irá reproduzir o comando reg, que pode realizar operações no registro do Windows.

...
reg export HKCR\Interface\{3050F240-98B5-11CF-BB82-00AA00BDCE0B} 3050F240-98B5-11CF-BB82-00AA00BDCE0B.reg
reg export HKCR\Interface\{3050F25A-98B5-11CF-BB82-00AA00BDCE0B} 3050F25A-98B5-11CF-BB82-00AA00BDCE0B.reg
reg export HKCR\Interface\{3050F25E-98B5-11CF-BB82-00AA00BDCE0B} 3050F25E-98B5-11CF-BB82-00AA00BDCE0B.reg
reg export HKCR\Interface\{3050F2E3-98B5-11CF-BB82-00AA00BDCE0B} 3050F2E3-98B5-11CF-BB82-00AA00BDCE0B.reg
reg export HKCR\Interface\{3050F2E5-98B5-11CF-BB82-00AA00BDCE0B} 3050F2E5-98B5-11CF-BB82-00AA00BDCE0B.reg
reg export HKCR\Interface\{3050F32D-98B5-11CF-BB82-00AA00BDCE0B} 3050F32D-98B5-11CF-BB82-00AA00BDCE0B.reg
...

E o último passo é juntar toda essa galera em um arquivo só.

copy *.reg ierestore.reg

Claro, não se esqueça de retirar os cabeçalhos duplicados (Windows Registry Editor Version X.XX). E Voilà! Fácil, não? Não?! Bom, então é por isso que eu sou bem pago =)

Para quem programa para sistemas, então, só o fato de acontecer no mesmo processo toda vez que ele for executado já é o máximo (quem já programou serviços, plugins, GINAs e afins sabe do que eu estou falando).

Porém, saber que uma determinada situação é mel na chupeta (by Thiago) por si só não adianta de muita coisa. É preciso conhecer as verdadeiras técnicas ninjas que conseguem resolver um bug escabroso num instante, coisa de deixar seu gerente de projetos tão feliz ao ponto dele não botar nenhum defeito na solução.

Dentre as mais conhecidas entre os malloqueiros, temos:

• Comenta-descomenta-comenta
• Faz do zero

Essas duas técnicas são tão úteis e tão fáceis de usar que merecem um artigo a respeito.

Tira-põe-deixa-ficar

Essa técnica milenar corresponde em tirar pedaços do código-fonte que poderiam estar causando o problema até que seja possível criar uma versão em que o problema não ocorra mais. Quando chega-se nesse nível, então volta-se a descomentar o código retirado até que o problema ocorra novamente. O processo é um fluxo de tira-código com volta-código, sendo que é necessário o bom conhecimento do projeto para não gerar outros problemas com a mutilação temporária do projeto.

Projeto-esqueleto (Re-Main!)

Se o código começa a ser tão mutilado que chegamos quase em uma versão vazia (sem código), então talvez a melhor forma de atacar o problema seja criar um esqueleto que contenha apenas o código necessário para que ele não faça nada. Isso mesmo. Não fazendo nada, mas instalado. Com isso prova-se que é possível estar lá sem fazer cagadas. A partir daí vai colocando-se o código do projeto real aos poucos no projeto-esqueleto, até que ele apresente o problema. Ou não. Já vi casos em que todo o código foi migrado e o problema sumiu. Ce la vie.

Quais as semelhanças com a profissão de programador-depurador?

Em primeiro lugar, a busca por pistas. Se algo está errado com o programa, vivemos criando teorias mirabolantes a respeito do porquê tal função estar retornando zero. No entanto, como não temos tanta capacidade adivinhatória assim, geralmente nossos palpites estão errados, e o fundo do poço irá nos mostrar uma outra função que nem estava ainda na história.

Mas existem alguns pontos-comuns de conhecimento que sempre desenvolvemos no decorrer da carreira:

• Se a última instrução do código é zero (ou algo próximo disso), provavelmente a pilha foi corrompida por alguém que tentou zerar uma variável, e junto dela o ponto de retorno de alguma função chamadora.
• Se um programa trava em um determinado momento, voltando após um período previsível de tempo (30 segundos), automaticamente sabemos que existe algum evento/mutex usado de forma errada que, dadas as circunstâncias, apresentou uma espera longa demais.
• Se uma versão nova capota em um procedimento em que a versão antiga nunca capotou, podemos divagar rapidamente quais as características da nova versão que fizeram com que isso acontecesse, ainda sem olhar para o código.

Dessa forma é possível criar teorias a partir da análise mental do que o programa normal deveria estar fazendo, mas não está. É esse tipo de análise que é feita no seriado.

Porém, o lado bom: podemos testar todas nossas hipóteses. Na vida real! Se, por enquanto, matar pacientes para depois ressuscitá-los é coisa de ficção, matar sistemas e reiniciá-los não é. E, dependendo do problema, podemos sempre replicá-lo em "outro paciente".

Talvez isso faça a profissão tão realizadora e viciante: para resolver um problema, geralmente temos todas as cartas na mão, e se não temos, fazemos ter. Afinal de contas, somos nós que iremos ressuscitar o sistema perdido.

Leituras Relacionadas

• A Ciência Médica de House

Quando passamos um parâmetro por valor, estamos enviando um e-mail com um arquivo em anexo. Não importa o que o destinatário faça com o arquivo: nós não vamos saber o que foi mudado se ele não enviar uma outra cópia.

Por outro lado, ao passar um parâmetro por referência, estamos enviando um e-mail com um endereço de onde está o arquivo. Se o usuário alterar o arquivo diretamente do endereço que enviamos será possível ver essa alteração imediatamente, pois ambos estão olhando para o mesmo valor na memória.

A analogia pode ser levada mais longe, com ponteiros de ponteiros: enviamos um e-mail com o endereço de um arquivo; dentro desse arquivo existe um endereço para outro arquivo. Dessa forma é possível tanto alterar o arquivo final quanto o endereço de onde ele está; ou ainda "apontar" para outro arquivo, trocando o endereço de dentro do primeiro arquivo.

Assim é fácil de visualizar que os dados estão sempre em um arquivo que ocupa espaço na memória (do disco ou da RAM), mas endereços também podem ocupar espaço, se estiverem salvos em um arquivo.

Dessa forma, um e-mail que contenha um arquivo em anexo vai ser muito maior que um e-mail apenas com o endereço do arquivo, mas é porque todo o conteúdo do arquivo está dentro do e-mail no primeiro caso. No segundo caso, o endereço ocupa apenas alguns caracteres que identificam a localização do arquivo.

windbg -kl

Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Symbol search path is: SRV*c:\tools\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
*******************************************************************************
WARNING: Local kernel debugging requires booting with kernel
debugging support (/debug or bcdedit -debug on) to work optimally.
*******************************************************************************
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp3_gdr.090804-1435
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
Debug session time: Mon Jan 11 10:36:50.061 2010 (GMT-2)
System Uptime: 5 days 1:05:24.958

Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.

lkd> !process 0 0 notepad.exe
PROCESS 89068700  SessionId: 0  Cid: 0ec4    Peb: 7ffda000  ParentCid: 0b0c
    DirBase: 0ac80a80  ObjectTable: e143a7d8  HandleCount: 152.
    Image: notepad.exe

O comando !peb traz inúmeras informações sobre essa estrutura. Mas talvez estivéssemos interessados em coisas não mostradas por esse comando, mas que existem na estrutura.

Nesse caso, podemos criar um projeto vazio que contenha a definição da estrutura como acreditamos que esteja na versão do kernel que estamos depurando.

Compilamos e geramos um PDB (arquivo de símbolos) que contém a definição desse tipo. Tudo que precisamos fazer agora é carregar esse símbolo na sessão que estivermos depurando.

É claro que nosso executável não vai existir na sessão de kernel local, mas isso não importa. Podemos usar qualquer módulo carregado e usá-lo como host de nosso conjunto de símbolos:

lkd> lm
start    end        module name
804d7000 806e5000   nt         (pdb symbols)          c:\tools\symbols\ntkrpamp.pdb\D8743252F83B4F59985D6E19F33BFCAF1\ntkrpamp.pdb

Unloaded modules:
a5513000 a553e000   kmixer.sys
bac50000 bac57000   USBSTOR.SYS
a5711000 a5746000   truecrypt.sys
a5731000 a5746000   wudfrd.sys
a5a19000 a5a23000   wpdusb.sys
...
a5731000 a5746000   wudfrd.sys
a57a9000 a57b3000   wpdusb.sys
a571b000 a5746000   kmixer.sys
babf0000 babf5000   Cdaudio.SYS
ba489000 ba48c000   Sfloppy.SYS
babe8000 babed000   Flpydisk.SYS
babe0000 babe7000   Fdc.SYS 

------ Build started: Project: KernelTypes, Configuration: Debug Win32 ------
Compiling...
KernelTypes.cpp
Linking...
LINK : program database c:\Tests\KernelTypes\Debug\KernelTypes.pdb missing; performing full link
Embedding manifest...
Build log was saved at "file://c:\Tests\KernelTypes\Debug\BuildLog.htm"
KernelTypes - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Microsoft Windows XP [versÎáÎ÷Îýo 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Tests\KernelTypes\Debug>ren KernelTypes.pdb usbstor.pdb

lkd> .sympath C:\Tests\KernelTypes\Debug
Symbol search path is: C:\Tests\KernelTypes\Debug
lkd> .reload /i /f usbstor.sys
lkd> lm m usb*
start    end        module name
bac60000 bac66700   USBSTOR  M (private pdb symbols)  C:\Tests\KernelTypes\Debug\usbstor.pdb

Depois que o símbolo foi carregado em nosso módulo de mentirinha, tudo que temos a fazer é alterar o contexto do processo atual (para que os endereços de user mode façam sentido) e moldar nossa memória com o comando dt, usando o tipo importado do símbolo carregado.

lkd> .process 89068700
Implicit process is now 89068700
lkd> dt usbstor!_peb 7ffda000
   +0x000 InheritedAddressSpace : 0xdc ''
   +0x001 ReadImageFileExecOptions : 0xff ''
   +0x002 BeingDebugged    : 0x35 '5'
   +0x003 SpareBool        : 0x1 ''
   +0x004 Mutant           : 0x01360000
   +0x008 ImageBaseAddress : 0x0135e000
   +0x00c Ldr              : (null)
   +0x010 ProcessParameters : 0x00001e00 _RTL_USER_PROCESS_PARAMETERS
   +0x014 SubSystemData    : (null)
   +0x018 ProcessHeap      : 0x7ffda000
   +0x01c FastPebLock      : (null)
   +0x020 SparePtr1        : 0x00000efc
   +0x024 SparePtr2        : 0x000008b8
   +0x028 EnvironmentUpdateCount : 0
   +0x02c KernelCallbackTable : (null)
   +0x030 SystemReserved   : [1] 0x7ffde000
   +0x034 ExecuteOptions   : 0y00
   +0x034 SpareBits        : 0y000000000000000000000011111100 (0xfc)
   +0x038 FreeList         : (null)
   +0x03c TlsExpansionCounter : 0
...

Para que isso funcione, a estrutura definida tem que bater offset por offset com os dados na memória, o que envolve alinhamento (se lembre do pragma pack) e versionamento corretos. Se isso não ocorrer, logo aparecerá algum lixo nos membros da estrutura que não fará sentido. Se isso ocorrer, detecte onde o lixo começa e verifique se o membro existe nessa versão do sistema operacional, ou se o alinhamento está de acordo com o módulo analisado.

Acho que não é preciso dizer que isso não serve apenas para kernel mode =)

O comando .formats do WinDbg nos consegue trazer desse número a hora exata em que determinado componente foi compilado. Se, por exemplo, um driver faltoso apresentou um DateStamp igual a 49EE9758, podemos concluir que ele foi compilado no dia 22 de abril de 2009, uma linda quarta-feira.

0:000> .formats 49EE9758
Evaluate expression:
  Hex:     00000000`49ee9758
  Decimal: 1240373080
  Octal:   0000000000011173513530
  Binary:  00000000 00000000 00000000 00000000 01001001 11101110 10010111 01011000
  Chars:   ....I..X
  Time:    Wed Apr 22 01:04:40 2009
  Float:   low 1.95454e+006 high 0
  Double:  6.12826e-315

Quando fazemos algo muitas vezes seguidas temos o hábito inconsciente de observar certas idiossincrasias dos dados que sempre vem e vão. No caso dos Date Stamps, sempre me veio o fato deles iniciarem com 4 e estarem prestes a "virar o contador" para 5.

Isso aos poucos - entre uma tela azul e outra - me deixou curioso a respeito de quando seria o dia fatídico em que teríamos o DateStamp 50000000, um número cabalístico em nosso sistema decimal. E, imaginem só:

0:000> .formats 50000000
Evaluate expression:
  Hex:     00000000`50000000
  Decimal: 1342177280
  Octal:   0000000000012000000000
  Binary:  00000000 00000000 00000000 00000000 01010000 00000000 00000000 00000000
  Chars:   ....P...
  Time:    Fri Jul 13 08:01:20 2012
  Float:   low 8.58993e+009 high 0
  Double:  6.63124e-315

Pois é, meus amigos. O DateStamp para a virada do contador Unix se fará numa manhã de sexta. Para ser preciso, uma sexta-feira 13.

Curioso, não? Mais curioso que isso, só sabendo que o ano que isso vai ocorrer é o igualmente fatídico 2012. Felizmente antes de dezembro.

Beeeem legal. Tão legal quanto saber que o núcleo de um átomo representa 99,9% de sua masssa ou que uma borboleta bate duzentas mil vezes a asa por hora (só chutando, eu não sei realmente).

Ou saber, talvez, que o homem deciciu contar sua idade terrena através do número de vezes que esse planetinha gira em órbita de sua estrela. É o tipo de curiosidade mais que suficiente para comentar em sua quinquagésima festa de aniversário durante a rodinha do tédio (aquela em que você não tem  nada pra comentar porque já é a quinquagésima festinha do ano e as pessoas já estão cansadas de se verem).

Dr. House: Ah, my birthday. Normally I'd put on a festive hat and celebrate the fact that the Earth has circled the Sun one more time; I really didn't think it was going to make it this year, but darn it if it wasn't the little planet that could all over again. (1.06 The Socratic Method)

Do ponto de vista estatístico (sempre ela!), então, nem se fala. Na região onde eu moro vivem dez milhões de pessoas. Em uma conta de padaria, trinta mil fazem aniversário junto comigo. Na mesma hora, talvez umas mil. Bom, mas existem sessentas minutos em uma hora! Dessa forma, eu tenho a chance de ter nascido no mesmo minuto junto de cerca de vinte rebentos. Ah, e os segundos!?!? É verdade. Sou obrigado a torcer o nariz para o "fato" que tenho mais de 50% de chance de ser a única pessoa na região de São Paulo a ter nascido no mesmo segundo. Que especial! Bom, no mundo inteiro, é óbvio que não tenho nem um milissegundo pra mim, o que torna a data tão insignificativa quanto um alerta do orkut sobre a mesma.

• Se aplicarmos a mesma lógica matemática à morte e aos nascimentos chegaremos à inevitável (e óbvia) equação que a vida de um indivíduo para a nossa espécie hoje em dia vale menos que sua aposentadoria. Até porque, dessa imensa maioria de pessoas que nascem e morrem, a maioria é pobre e não tem condições de contribuir com uma boa parcela de gastos para o bem de nossa economia. A maioria é burra também, e pode contribuir menos ainda pelo valor agregado de nossa riqueza.

• Me foi contado que aniversários são eventos para celebrar a vida, principalmente do aniversariante. Ótimo! Isso quer dizer que a vida de cada um vale menos de 0,3% do ano inteiro, já que reservamos apenas um dia em 360 para confirmar que ainda estamos respirando.

Bom, esse artigo já devanou demais. E como meu objetivo nem foi chegar à uma conclusão, termino por aqui. Ah, para dar mais corda pra pensar: feliz natal!

PS: Mensagens de feliz aniversário serão devidamente descartadas. Ah, e feliz ano-novo pra você, também.

Primeiro, meus motivos primários:
- Estava escutando Tatu;
- Costumava conversar pelo ICQ com uma amiga de Moscou (em inglês, apesar dela falar mais três ou quatro idiomas; e ela só tinha 19 anos!);
- Estava querendo aproveitar parte do meu cérebro que fica inerte a maior parte do tempo porque meu emprego basicamente só mexe com coisas (quase) lógicas, como programação;
- Achava uma língua bem bonita e exótica;
- Gosto de jogar xadrez (o que isso tem a ver?).

Bom, no início comecei aprendendo o alfabeto. Alguns podem dizer que não há nenhum segredo no cirílico, e de fato não há. Porém, uma coisa é saber interpretar mais ou menos aquelas letrinhas derivadas do grego; outra completamente diferente é saber escrever em letra de base e em letra de mão todos os 33 caracteres, e ainda saber de cor o leiaute do teclado russo. Isso leva um pouco de tempo, e é bem divertido!

A partir daí passei cerca de seis meses apenas treinando a escrita e leitura do cirílico, aprendendo a diferença de som dependendo do contexto, um caderno a tiracolo no meio do ônibus, do trem e do metrô escrevendo infinitas linhas incompreensível provavelmente por 99% das pessoas que cruzavam meu caminho e olhavam curiosas.

Depois, o idioma em si. Nessa fase resolvi apelar para um curso disponível no mosteiro S. Bento ministrado por uma russa autência, de S. Petersburgo. Ela não falava muito bem português, o que para mim era um "plus".

Passei mais seis meses de curso com ela e com alguns textos que ia baixando da internet. Depois do curso comprei um curso em áudio e texto que fui acompanhando morosamente pelo resto dos dois anos que passei me aventurando pelo idioma.

No meio do caminho um amigo meu achou o podcast Spoonful of Russian, o que foi uma diversão só, especialmente pelo conhecimento cultural e musical do povo russo. Minha amiga também me enviou alguns CDs de bandas russas famosas, e fiquei especialmente encantando com Ivan Kupala, que até hoje escuto. Se trata de uma banda que pegou músicas do folclore russo e adaptou para os tempos atuais, mas cantado ainda por velhinhas e velhinhos que aparentemente parecem ter saído de uma aldeia dos Montes Urais.

O cinema e a BBC russa também representaram um instrumento de aprimoramento do listening do dia-a-dia. Uma coisa é escutar um russo falando devagar durante uma aula de declinação do futuro por aspecto. Outra coisa é ver alguém usando isso enquanto atravessa a rua conversando com um amigo no meio do barulho da cidade grande, ou uma mulher que mais parece uma metralhadora disparando 500 notícias de uma vez no podcast de um jornal da internet.

Infelizmente, essa fase esmaeceu. Agora estou muito interessado em finanças e isso fez com que o russo ficasse cada vez mais para trás. Se me pedir hoje para falar algo em russo vou conseguir apenas balbuciar as mais "comunzinhas", pois esqueci todo o resto. Foi perda de tempo? Claro que não! Foi uma experiência que mostra que podemos aprender qualquer coisa a qualquer hora, independente do quão estranho ou bizarro isso seja.

до свидание!

Podemos espetar o depurador e fazê-lo parar assim que conectado. Se estiver rodando antes do próprio sistema operacional, teremos um sistema sem processos e sem threads, pois ele irá parar assim que o executivo puder enviar o sinal de início pela porta serial, após carregar na memória os módulos básicos.

windbg -k com:pipe,port=\\.\pipe\com_1 -b

Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \\.\pipe\com_1
Waiting to reconnect...
Connected to Windows XP 2600 x86 compatible target at (Tue Sep  8 22:33:27.267 2009 (GMT-3)), ptr64 FALSE
Kernel Debugger connection established.  (Initial Breakpoint requested)
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
*                                                                   *
* The Symbol Path can be set by:                                    *
*   using the _NT_SYMBOL_PATH environment variable.                 *
*   using the -y <symbol_path> argument when starting the debugger. *
*   using .sympath and .sympath+                                    *
*********************************************************************
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntkrnlpa.exe -
Windows XP Kernel Version 2600 UP Free x86 compatible
Built by: 2600.xpsp_sp2_rtm.040803-2158
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805531a0
System Uptime: not available
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
*                                                                             *
*   You are seeing this message because you pressed either                    *
*       CTRL+C (if you run kd.exe) or,                                        *
*       CTRL+BREAK (if you run WinDBG),                                       *
*   on your debugger machine's keyboard.                                      *
*                                                                             *
*                   THIS IS NOT A BUG OR A SYSTEM CRASH                       *
*                                                                             *
* If you did not intend to break into the debugger, press the "g" key, then   *
* press the "Enter" key now.  This message might immediately reappear.  If it *
* does, press "g" and "Enter" again.                                          *
*                                                                             *
*******************************************************************************
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntkrnlpa.exe -
nt!DbgBreakPointWithStatus+0x4:
80526da8 cc              int     3
kd> lm
start    end        module name
804d7000 806ce300   nt         (export symbols)       ntkrnlpa.exe
806cf000 806ef380   hal        (deferred)
f96f0000 f970a580   Mup        (deferred)
f970b000 f9737a80   NDIS       (deferred)
f9738000 f97c4480   Ntfs       (deferred)
f97c5000 f97db780   KSecDD     (deferred)
f97dc000 f97edf00   sr         (deferred)
f97ee000 f980c780   fltMgr     (deferred)
f980d000 f9824800   SCSIPORT   (deferred)
f9825000 f983c480   atapi      (deferred)
f983d000 f985bb80   ftdisk     (deferred)
f985c000 f986cd80   pci        (deferred)
f986d000 f989b000   ACPI       (deferred)
f999c000 f99a4d80   isapnp     (deferred)
f99ac000 f99b6500   MountMgr   (deferred)
f99bc000 f99c9000   VolSnap    (deferred)
f99cc000 f99d4e00   disk       (deferred)
f99dc000 f99e8200   CLASSPNP   (deferred)
f99ec000 f99f6580   agp440     (deferred)
f9c1c000 f9c22200   PCIIDEX    (deferred)
f9c24000 f9c28900   PartMgr    (deferred)
f9dac000 f9daf000   BOOTVID    (deferred)
f9db0000 f9db2480   compbatt   (deferred)
f9db4000 f9db7700   BATTC      (deferred)
f9db8000 f9dbab00   vmscsi     (deferred)
f9e9c000 f9e9db80   kdcom      (deferred)
f9e9e000 f9e9f100   WMILIB     (deferred)
f9ea0000 f9ea1600   intelide   (deferred)
kd> .sympath
Symbol search path is: <empty>
Expanded Symbol search path is: <empty>
kd> .symfix
kd> .sympath
Symbol search path is: srv*
Expanded Symbol search path is: cache*C:\Tools\DbgTools\sym;SRV*http://msdl.microsoft.com/download/symbols
kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
NT symbols are incorrect, please fix symbols
kd> .reload
Connected to Windows XP 2600 x86 compatible target at (Tue Sep  8 22:34:41.661 2009 (GMT-3)), ptr64 FALSE
Loading Kernel Symbols
...........................
Loading User Symbols

kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
NULL value in PsActiveProcess List  <-- Nenhum processo por aqui
kd> !thread0 0
No export thread0 found
kd> !thread 0 0
00000000: Unable to get thread contents  <-- Nenhuma thread também!
kd> r
eax=00000001 ebx=80087000 ecx=80548c74 edx=80548c44 esi=80087000 edi=00000000
eip=80526da8 esp=80548c60 ebp=80548de8 iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000202
nt!RtlpBreakWithStatusInstruction:
80526da8 cc              int     3
kd> k
ChildEBP RetAddr
80548c5c 80682baa nt!RtlpBreakWithStatusInstruction
80548de8 8068fd48 nt!ExpInitializeExecutive+0x350
80548e3c 8068d99b nt!KiInitializeKernel+0x3b2
00000000 00000000 nt!KiSystemStartup+0x2bf
kd> kv
ChildEBP RetAddr  Args to Child
80548c5c 80682baa 00000001 80551920 00000000 nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
80548de8 8068fd48 00000000 80087000 8003fc00 nt!ExpInitializeExecutive+0x350 (FPO: [2,93,4])
80548e3c 8068d99b 80551b80 80551920 80549100 nt!KiInitializeKernel+0x3b2 (FPO: [Non-Fpo])
00000000 00000000 00000000 00000000 00000000 nt!KiSystemStartup+0x2bf

Todos os módulos carregados antes dessa fase são os drivers que tiveram seu Start definido em zero no registro. Todos os programadores que desenvolvem esses drivers gostariam de um dia poder usar o WinDbg. Mas não podem. Quem inicia a comunicação serial com o depurador é o kernel, que só recebe o controle do ntldr depois que os drivers básicos foram carregados.

Brincadeira. É claro que esses programadores usam o WinDbg, usam até demais. Mas só a partir desse ponto. Se algum problema evitar que o sistema chegue nessa fase, o desenvolvedor terá que usar métodos alternativos de depuração, como teste de mesa (risos incontroláveis).

De qualquer forma, estamos aí. Agora podemos depurar a criação de qualquer thread, qualquer processo, o carregamento de qualquer módulo, e a chamada a qualquer função do kernel.

Para depurar a criação de qualquer thread: coloque um breakpoint na função PsCreateSystemThread.

kd> bp PsCreateSystemThread
kd> bl
 0 e 805c732e     0001 (0001) nt!PsCreateSystemThread

kd> g
Breakpoint 0 hit
nt!PsCreateSystemThread:
805c732e 8bff            mov     edi,edi
kd> k
ChildEBP RetAddr
805499a8 8069c17e nt!PsCreateSystemThread
80549a4c 8069c419 nt!PspInitPhase0+0x3f0
80549a58 8068509c nt!PsInitSystem+0x33
80549be8 80691f28 nt!ExpInitializeExecutive+0x742
80549c3c 8068fa9f nt!KiInitializeKernel+0x3b2
00000000 00000000 nt!KiSystemStartup+0x2bf

Para depurar a criação de qualquer processo: coloque um breakpoint na função PspCreateProcess, logo no começo. Será possível capturar a criação do processo System, o processo onde roda a primeira thread do kernel, que inicializa o resto dos componentes.

kd> bp PspCreateProcess
kd> bl
 0 e 805c6a8c     0001 (0001) nt!PspCreateProcess

kd> g
Breakpoint 0 hit
nt!PspCreateProcess:
805c6a8c 681c010000      push    11Ch
kd> k
ChildEBP RetAddr
805499a0 8069c0dc nt!PspCreateProcess
80549a4c 8069c419 nt!PspInitPhase0+0x34e
80549a58 8068509c nt!PsInitSystem+0x33
80549be8 80691f28 nt!ExpInitializeExecutive+0x742
80549c3c 8068fa9f nt!KiInitializeKernel+0x3b2
00000000 00000000 nt!KiSystemStartup+0x2bf

E não é lindo ver que, após a chamada ao Process Manager o processo REALMENTE foi criado e está na lista de processos?

kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
TYPE mismatch for process object at 8055a0d0
kd> gu
nt!PspInitPhase0+0x34e:
8069c0dc 85c0            test    eax,eax
kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
PROCESS 81bcc830  SessionId: none  Cid: 0004    Peb: 00000000  ParentCid: 0000
    DirBase: 00319000  ObjectTable: e1000cc0  HandleCount:   1.
    Image: System Process

É nesse momento que percebemos que um processo, uma thread, um qualquer-coisa dentro do kernel não é nada mais nada menos que um item em uma lista. Quase tudo no kernel será um item numa lista com um monte de ponteiros referenciando outras estruturas. É isso que mantém a lógica e a coerência no sistema inteiro. Tudo isso é basicamente software, construído como castelos no ar.

O próximo processo a ser criado, logo após carregar todos os drivers, é o nosso amigo SMSS, o Gerenciador de Sessão, o primeiro pedacinho do iceberg que desponta no oceano. É ele que irá iniciar toda a "parte user-mode do kernel".

Nota: Apesar de parecer contraditório, algumas partes do kernel são de fato implementadas em user mode. Os motivos podem variar, mas geralmente são maior segurança (código que não precisa rodar em um ring privilegiado) e desempenho (código que não precisa de muita prioridade).

Breakpoint 0 hit
nt!PspCreateProcess:
805c6a8c 681c010000      push    11Ch
kd> kv
ChildEBP RetAddr  Args to Child
f9dc365c 805c73e1 f9dc3858 001f0fff f9dc37c0 nt!PspCreateProcess (FPO: [Non-Fpo])
f9dc36b0 805c745d f9dc3858 001f0fff f9dc37c0 nt!NtCreateProcessEx+0x77 (FPO: [Non-Fpo])
f9dc36dc 8053d638 f9dc3858 001f0fff f9dc37c0 nt!NtCreateProcess+0x3d (FPO: [Non-Fpo])
f9dc36dc 804fe155 f9dc3858 001f0fff f9dc37c0 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f9dc3704)
f9dc3774 8069caa3 f9dc3858 001f0fff f9dc37c0 nt!ZwCreateProcess+0x11 (FPO: [8,0,0])
f9dc3818 80686681 f9dc38b0 00000040 00040000 nt!RtlCreateUserProcess+0x125 (FPO: [Non-Fpo])
f9dc3dac 805c6160 80087000 00000000 00000000 nt!Phase1Initialization+0x1059 (FPO: [Non-Fpo])
f9dc3ddc 80541dd2 80685628 80087000 00000000 nt!PspSystemThreadStartup+0x34 (FPO: [Non-Fpo])
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
kd> !ustr f9dc38b0
String(58,520) at f9dc38b0: \SystemRoot\System32\smss.exe

kd> gu
kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
PROCESS 81bcc830  SessionId: none  Cid: 0004    Peb: 00000000  ParentCid: 0000
    DirBase: 00319000  ObjectTable: e1000cc0  HandleCount:  52.
    Image: System

PROCESS 81a2a430  SessionId: none  Cid: 0218    Peb: 7ffd6000  ParentCid: 0004
    DirBase: 08500020  ObjectTable: e1584818  HandleCount:   0.
    Image: smss.exe

Como podemos ver, isso é muito divertido e muito extenso. Poderíamos ir para qualquer lado da evolução do boot. Talvez em artigos futuros daremos uma olhada no processo de logon de um usuário, o que nos obrigaria a ter uma leve noção de como o Windows autentica e autoriza as pessoas. ou talvez daremos uma passadinha no sistema de escalonamento de threads do kernel, um assunto pra lá de complicado e esotérico.

Nota: Eu pessoalmente recomendo acompanhar o processo de boot descrito por Russinovich e depurar passo-a-passo um boot de verdade. Serão horas e mais horas de puro conhecimento empírico catalogado em seu cérebro-depurador.

Então até lá. Com licença que eu preciso ver a criação do System mais uma vez.

.reboot