Website patrocinador: Emergency Boot CD (somente em inglês)

Um guia para o DEBUG

( Programa Microsoft® DEBUG.EXE )
Direitos reservados©2004,2007,2009,2017 para Daniel B. Sedory

Esta página pode ser copiada gratuitamente apenas para uso pessoal !
( Não pode ser usada para qualquer outro propósito, a menos que você tenha
primeiro contatado (somente em inglês) e tenha recebido permissão do autor ! )

Sítio traduzido para a língua portuguesa por

Augusto Manzano com autorização expressa do autor
(vide fim da página 2).
Acesse aqui a versão original em inglês.

Uma História para o DEBUG

Início
Mudanças no DEBUG
Em Windows™ 9x/Me
Em Windows™ NT/2000/XP e posterior
Resumo
Mas o PCE ainda é executado no Windows 10!
O melhor DEBUG 'Clone' (também para 32-bits!)

As Limitações do DEBUG
Valores de inicialização importantes para o DEBUG
Usando DEBUG com arquivos .EXE

Localizações de memória especiais no MS-DEBUG

Área dinâmica da pilha do DEBUG

Você encontrou um 'bug' no DEBUG?

Notas importantes para usar o DEBUG

Todos os comandos -- Listados alfabeticamente

Acessos rápidos para o modo de auxílio aos comandos

PÁGINA DOIS:
Como usar os COMMANDS (comandos)
Significado dos parâmetros para os comandos

Auxílio detalhado para cada comando (inicie aqui)

Um exemplo de programa para você entrar, executar e editar no DEBUG.
Uma Nota sobre o string 'IHC' do Win 9x em setores de inicialização de disquetes

Apêndice
Os registradores da CPU 8086
Os registradores de FLAGS
O método de endereçamento Segment:Offset Addressing (endereço de SEGMENTO:DESLOCAMENTO) usado pelo DEBUG (somente em inglês)

Uma História para o MS-DEBUG

Início

Em 1980, Tim Paterson começou a trabalhar em um sistema operacional de 16 bits para a placa 8086 S-100 que ele havia projetado para a SCP (Seattle Computer Products) no ano anterior. Para o correto funcionamento de seu
sistema, chamado QDOS (posteriormente denominado 86-DOS) Tim criou um depurador e um chip de ROM: o código dessa ROM foi lançado no regime de domínio público. Mais tarde, Tim adaptou o código para ser executado como um
programa .COM em QDOS e adicionou a capacidade de desmontar o código de máquina do processador 8086. Enquanto isso, a Microsoft® estava comprando os direitos do sistema QDOS de Tim para a IBM® que projetava
'secretamente' seu PC. Tim foi contratado pela Microsoft como o principal autor de seu primeiro sistema operacional. Quando completou seu trabalho no IBM Personal Computer™ DOS 1.00 em 1981, seu utilitário DEBUG.COM foi
incluído nele. Todas as funcionalidades implementadas por Tim no DEBUG ainda estão no programa e pouco foi adicionado a ele (a principal exceção é o comando Assemble (montagem), implementado no DOS 2.0.
[ Agradeço ao próprioTim Paterson por ter analisado esta perspectiva no início do DEBUG. ]

Mudanças no DEBUG
Com o lançamento do DOS 2.0 o DEBUG ganhou a capacidade de montar instruções diretamente no código de máquina (comando A). Este é um dos comandos mais importantes para muitos de seus usuários. Embora falte muito da
funcionalidade de um Assembler autônomo, como por exemplo, executar Jumps (saltos) baseados em rótulos (só é aceito saltos com endereços hexadecimais), muitos programas .COM úteis foram escritos com este comando. No DOS
3.0 o comando P (Proceed) de prosseguir foi adicionado permitindo ao DEBUG executar sub-rotinas. Ao mesmo tempo, tornou-se possível fazer uso de Interrupções com o comando T (Trace) de acompanhamento. Quando o DOS
passou a fazer uso de funções EMS (Memória Expandida) sob o DOS 4.0, quatro novos comandos: xa, xd, xm e xs foram adicionados ao DEBUG e são raramente usados por nós programadores. Para a maioria de nós, a única
alteração notável no DEBUG foi a inclusão do comando de ajuda '?' no DOS 5.0.

O código DEBUG passou por uma série de mudanças (e também de 'correções de erros') ao longo dos anos. Algumas dessas alterações internas foram relacionadas às chamadas do sistema DOS e à saída da tela, então, houve a
alteração no suporte do tipo de arquivo .COM para .EXE no DOS 5.0. Apesar de todas essas mudanças e outras que se seguiram, o DEBUG nunca teve uma revisão oficial desde a versão 2.40 (esses dígitos foram incorporados em
todas as versões do DEBUG desde o DOS 3.0). Só podemos especular sobre os reais motivos pelos quais a Microsoft® nunca atualizou o DEBUG para lidar com instruções além dos processadores Intel® 8086/8087/8088. A
Microsoft® desenvolveu seu próprio Assembler (MASM), compilador 'C' e Debugger (CodeView) que também poderia ser usado, se você estivesse disposto a pagar um valor extra por isso de modo que poderia ter sido esse um dos
motivos para não focar o programa DEBUG. Ao invés de usar o MASM e o CodeView muitos optaram pelo montador Borland® (TASM) e pelo Turbo™ Debugger mais baratos quando lançados ou usaram outros produtos comerciais. No
entanto, os usuários e estudantes podem aprender muito sobre a linguagem Assembly ao utilizarem o programa DEBUG.

DEBUG no Windows® 9x/Me

As estruturas internas dessas versões do Windows® para o DEBUG parecem muito diferentes de qualquer estrutura usada anteriormente no DOS, pelo menos à primeira vista. No entanto, você encontrará a indicação "Vers 2.40" em um
local diferente. O próprio Windows® passou por muitas mudanças durante esse período, como lidar com o sistema de arquivos FAT32. Mas sem acesso ao código fonte não podemos ter certeza se houve grandes diferenças no DEBUG.
As mudanças podem ocorrer devido a algo simples como apenas reorganizar as mensagens de erro no código-fonte e/ou usar um novo Assembler/Linkeditor.

O DEBUG sempre foi uma ferramenta eficaz nas mãos de qualquer programador, mas algum tempo após a introdução do Windows™ 95 e especialmente com o Windows™ 98, essa eficácia diminuiu quando seus comandos de I/O se
tornaram menos confiáveis. Seja devido a um 'bug' no DEBUG propriamente dito ou no Windows®. O fato é que os comandos de I/O no Windows™ 9x/Me não são confiáveis para acesso direto a discos rígidos. Se você executar nosso
ATA drive ID script (somente em inglês) no Win9x/Me, verá que os dados retornados são tão interessantes quanto perturbadores: parece que todos os demais bytes ainda estão corretos. Então, a pergunta que não quer calar é: qual a
causa desse problema?

DEBUG no Windows® NT/2000/XP/2003

O programa DEBUG incluído no Windows® NT/2000/XP/2003 parece operar de maneira semelhante junto ao DOS 5.0, mas com duas principais exceções:

1) No DEBUG não é permitido carregar ou escrever em nenhum setor de HDD lógico. Somente os arquivos nomeados ainda podem ser lidos ou gravados em um sistema operacional do tipo NT. No entanto, é possível acessar
setores de disquete nas unidades de drives A:\ ou B:\ com o comando L (Load) de carregar e W (Write) de escrever, mas somente se os disquetes contiverem um sistema de arquivos que o sistema operacional host (2000, XP, 2003)
pode reconhecer.
(Consulte comando L na seção Tutorial [somente em inglês] para obter mais informações.)

[ Obs: O DEBUG nunca conseguiu acessar diretamente áreas de um disco rígido fora dos volumes de unidade, como uma tabela de partição estendida ou mesmo o setor MBR. No entanto, o DEBUG pode ser usado para acessar esses dados programando-os para
executar comandos INT13 ou usando um arquivo de script sob DOS (por exemplo, nosso antigo script CopyMBR [somente em inglês]). Note que nenhuma versão do Windows após o Win98/ME permitirá acesso aos comandos INT13. ]

2) Os comandos I e O são essencialmente inúteis, uma vez que a interface do programa com o resto do sistema só está sendo emulado sob essas versões do Windows® ao invés de ter acesso direto ao hardware. Isso já era
recorrente em versões anteriores do Windows®.

Isso pode surpreendê-lo: propositadamente mencionamos a versão do DOS 5.0 do DEBUG já que o arquivo DEBUG.EXE incluído no Windows® XP (e todas as outras versões da série NT são exatamente o mesmo arquivo de programa
criado para o MS-DOS 5.0 com md5sum = c17afa0aad78c621f818dd6729572c48). O DEBUG era apenas mais um dos pequenos programas do DOS 5.0 que não exigiam alterações para serem executados em um sistema operacional NT. É
quase irônico que outro desses programas seja o EDLIN, um editor de linha não apreciado pela maioria dos usuários do DOS. Embora o EDLIN tenha sido criado por Tim Paterson, ele fez isso em duas semanas e ficou chocado quando
soube que a IBM tinha incluído esse programa na versão 1.00 do PC-DOS. Sem sombra dúvida, Tim desejava que esse programa tivesse sido substituído por algo melhor em 1981. Isso não ocorreu até o lançamento do DOS 5.0,
quando o EDLIN foi efetivamente substituído pelo programa Microsoft EDIT.COM (v 1.0 no ano de 1991. Obs: A primeira versão do EDIT necessitava do programa QBASIC para ser executado). No entanto, o programa EDLIN foi mantido
para ser 'compatível' com versões anteriores de vários arquivos Batch de terceiros. Embora o NOTEPAD, mais avançado, esteja presente no Windows™, você pode usar a versão autônoma de 1995 do programa EDIT(v 2.0.026) no
prompt de comando do Windows™ XP: seus menus respondem adequadamento aos cliques do mouse.

Resumo
Embora tenha sido criado no início da era do processador de 16 bits (antes dos 80286 existirem) as versões mais recentes do DEBUG (como as encontradas no arquivo EBD.CAB do disquete de inicialização de emergência do
Windows™ Me ou 98SE) ainda são úteis para técnicos de PCs no que tange ao acesso direto a determinadas posições de memória em sistemas atuais como por exemplo (Intel® Pentium™ IV). O DEBUG também pode ser muito útil
para fins educacionais. E mesmo para depurar o código de montagem que é necessário durante o processo de inicialização: o software que verifica a tabela de partição em discos rígidos e carrega os setores de inicialização do sistema
operacional na memória. Infelizmente, muitos dos programas de inicialização de setores MBR mais recentes usam instruções que exigem uma CPU de classe 386 (ou mesmo 486) para funcionar, tornando difícil usar DEBUG para tal
propósito Devido às questões de compatibilidade com versões anteriores da maioria dos processadores Intel® e ao fato de que foi incluído no Microsoft® Windows™ XP e 2003 o DEBUG teve uma vida útil muito maior do que o
esperado. Embora a CPU ITANIUM™ não fosse x86-compatível o processador AMD64 era. Em 2005 a Intel® criou as chamadas CPUs "x64-based" que eram mais uma vez x86-compatíveis. Então o DEBUG continua a encontrar algum
uso em computadores de 64 bits, até mesmo nas máquinas baseada no Intel® Core™ 2 Quad (4 processors in one).

Capítulo final?
Sim, o programa DEBUG e alguns outros utilitários anteriores a época do DOS foram removidos da linha de comando da versão de 64 bits do Windows 7 e nunca mais serão usados no sistema operacional Microsoft. No entanto, é
possível há algum tempo executar o IBM PC DOS 1.x0, 2.x0 e 3.30 (e possivelmente outros) juntamente com suas versões do DEBUG em uma pequena janela no Windows XP (32-bit), Windows 7 (64-bit), 8 e até a última atualização do
Windows 10 (Anniversary). Leia aqui sobre o programa PCE (PC Emulator) de Hampa Hug (somente em inglês). Se você deseja executar a última versão do MS-DEBUG a partir do MS-DOS 6.22 ou executar o programa DEBUG de 32-
bits clone que é abaixo indicado, talvez seja necessário instalar o programa BOCHS, QEMU ou outro emulador como o VPC, VirtualBox, VMWare Player ou ainda outro tipo de programa de máquina virtual. Há o programa PCE que
possui uma característica interessante: você pode executar com este programa no seu computador um código de compatível com a ROM-BIOS de um computador IBM-PC original como se estivesse utilizando a máquina física da época..

Um bom DEBUG Clone (para código de 32 bits)

Há uns anos usamos um "clone" do MS-DEBUG desenvolvido para o sistema operacional FreeDOS que vem melhorando ao longo deste tempo. Você pode baixar e usar este programa de graça. Atualmente recomendamos uma página
feita para ele em um sítio criado por Vernon C. Brooks, que tinha sido um programador sênior para o sistema operacional PC DOS 7.0 da IBM. O sítio em questão trata do histórico do IBM PC DOS, sendo este muito informativo (PC DOS
Retro):
Enhanced DEBUG (versão atual, desde dezembro de 2014, é 1.30b).

C:\DEBUG> DEBUGX
-?
assemble A [endereço]
compare C intervalo de endereços
dump D[B|W|D] [intervalo]
dump interrupt DI interrupção [contador]
dump LDT DL seletor [contador]
dump MCB chain DM
dump ext memory DX [endereço_físico]
enter E endereço [lista]
fill F lista de intervalos
go G [=endereço] [endereços]
hex add/sub H valor1 valor2
input I[W|D] porta
load file L [endereço]
load sectors L [endereço] [unidade] [primeiro setor] [número]
move M intervalo de endereços
set x86 mode M [x] (x=0..6)
set FPU mode MC [2|N] (2=287,N=não FPU)
name N [[unidade:][caminho]nome do arquivo [lista de argumentos]]
output O[W|D] byte da porta
proceed P [=endereço] [número]
proceed return PR
quit Q
register R [registrador [valor]]
MMX register RM
FPU register RN[R]
toggle 386 regs RX
search S lista de intervalos
trace T [=endereço] [contador]
trace mode TM [0|1]
unassemble U [lista]
write file W [endereço]
write sectors W [endereço] [unidade] [primeiro setor] [número]

prompts: '-' = real/modo-v86; '#' = modo-protegido

-

As Limitações do MS-DEBUG
O DEBUG foi originalmente projetado para trabalhar com programas .COM com tamanho máximo de 65.280 bytes [ (64 x 1024) - 256 ] ou menos. Quanto menos, dependia do número máximo de bytes que o programa poderia colocar
na Stack (pilha) ao mesmo tempo. A subtração de 256 bytes é necessária uma vez que o DEBUG geralmente usa a área do deslocamento 00 até FF hex para alguns dados internos como o nome do arquivo carregado. Lembre-se, de
que os programas.COM por definição devem caber dentro de um único segmento de memória (somente 64 KB).

Mesmo quando executado o MS-DEBUG no sistema operacional Windows® mais recente por ser um antigo aplicativo DOS de 16 bits. Você só poderá abrir arquivos cujos nomes foram salvos na convenção DOS 8.3, ou seja, 11
caracteres no total usando 8 caracteres para o nome e 3 caracteres para a extensão.

Posterior ao DOS 1.10 o DEBUG foi capaz de carregar arquivos maiores que 64 KB. Basicamente o tamanho de um arquivo que o DEBUG pode usar com segurança sem erros depende da quantidade de memória disponível e da
maneira como o sistema operacional gerencia a memória. Vamos ver mais sobre isso abaixo .

A. Uso do programa DEBUG iniciado sem a chamada de parâmetros na linha de comando:

1) Aloca todos os 64 KB do primeiro segmento de memória livre.

2) Os registros de segmentos CS, DS, ES e SS são definidos com os valores de localização do segmento de 64 KB (CS=DS=ES=SS=Local do Segmento).

3) O ponteiro de instrução (IP) fica definido para CS:0100 e o ponteiro de pilha (SP) fica definido como SS:FFEE (em DOS 3.0 ou superior).

4) Os registradores AX, BX, CX, DX, BP, SI e DI são sinalizados como zero juntamente com os bits de flags nos registradores de flags. Exceto: o flag Interrupts que fica configurado para Enable Interrupts. (Consulte o
Apêndice, The 8086 CPU Registers [somente em inglês] para mais informações.)

B. Uso do programa DEBUG iniciado com nome de arquivo (diferente de um .EXE):

1) Aloca pelo menos 64 KB do primeiro segmento de memória livre para depurar programas ou examinar arquivos especificados na linha de comando. [Obs: Desde a versão DOS 1.10 o DEBUG teve a capacidade de
carregar (e salvar) arquivos maiores que 64 KB. O tamanho de um arquivo manipulado depende do sistema operacional e da memória disponível. Mas antes de você fazer uso do DEBUG para salvar algum arquivo grande é
necessário saber a quantidade de memória limitada que está disponível na MEMÓRIA CONVENCIONAL. Lembre-se, se um arquivo pode ser depurado no seu sistema, não significa que outra pessoa poderá fazê-lo. ]

2) Os registradores de segmento CS, DS, ES e SS são definidos para os valores dos primeiros 64 KB dos segmentos (CS=DS=ES=SS=Local do Segmento). Para arquivos maiores que 64KB, você terá que definir diferentes
valores de segmento para acessar todos os bytes carregados na memória além dos primeiros 64 KB.

3) O ponteiro de instrução (IP) fica definido para CS:0100 e o ponteiro de pilha (SP) fica definido como SS:FFFE (versão 3.0+). [ OBS: Isto não é o mesmo que SS:FFEE in A. como indicado acima, há uma diferença de 16
bytes. ]

4) A maioria dos registradores segue o mesmo padrão acima, exceto para os registradores CX e às vezes BX, onde o tamanho do arquivo será colocado na combinação linear dos registradores BX e CX. Para arquivos com
menos de 64 KB - 256 bytes, apenas CX é usado. Exemplo: Se você carregar um arquivo de 360.247 bytes, então BX=0005 e CX=7F37 ( 57F37 hex = 360.247 ). Se você carregar um arquivo com exatamente 65.536
bytes a partir de um prompt, esses registradores serão: BX=0001 e CX=0000. Mas devido ao deslocamento automático de carga no endereço 100h os últimos 256 bytes do arquivo terão sido carregados no início do próximo
segmento de 64 KB.

Lembre-se: Os segmentos atribuídos ao DEBUG dependem da quantidade de memória em uso e não da memória disponível no computador. A mesma máquina DOS que possui 16 ou 4096 MB de memória geralmente carrega o
DEBUG nos mesmos segmentos, a menos que um programa 'termine e permaneça residente' ou quando a memória não é desabilitada antes de ser executado o DEBUG.

Usando DEBUG com arquivos .EXE

Qualquer versão do DEBUG do DOS 2.0 ou superior faz uso da função EXEC do sistema operacional, o que significa que é possível executar uma quantidade limitada de depuração em programas .EXE. No entanto, o DEBUG nunca
pode ser usado para salvar um .EXE ou um arquivo .HEX em disco, uma vez que ambos os tipos de arquivo contém dados extras que o DEBUG não foi programado para acessar após a função EXEC remover da memória esses dados.
É bem possível, porém, alterar a extensão de um arquivo .EXE, por exemplo, para .BIN, e então usar o DEBUG para editar esse arquivo e, em seguida, alterá-lo novamente para uma extensão .EXE. Normalmente, recomendamos usar
um editor Hexadecimal. É propício salientar que o DEBUG pode ser usado com arquivos de lote e scripts para atuar sobre essas edições automaticamente.

Um dos programas .EXE mais simples que você pode usar com o DEBUG é o DOS "Stub" encontrado em muitos executáveis do Windows®. Para saber mais sobre este assunto acesse as informações aqui (somente em inglês).
 Localização de memória especial no MS-DEBUG
Sempre haverá algum código e dados colocados nos primeiros 256 bytes do segmento para uso do próprio DEBUG. E, embora o DEBUG funcione geralmente como esperado se você desligar esta área poderá ocorrer alguns casos em
que você desejaria não ter feito isto. Os bytes de código são simples e sempre são encontrados nos mesmos locais: os dois primeiros bytes desta área ("CD 20") são o código de máquina para a interrupção do DOS: INT 20. Os
bytes de deslocamento 50h e 51h ("CD 21") formam um INT 21 e o byte "CB" no deslocamento 52h é uma instrução RETF.

Ao inicializar o DEBUG a partir de um disco de instalação de atualização MS-DOS 6.22 serão apresentados os seguintes dados (offsets 90h - FFh todos definidos com zero bytes):

A:\>debug
-d 0 8f
1787:0000 CD 20 C0 9F 00 9A EE FE-1D F0 4F 03 EB 11 8A 03 . ........O.....
1787:0010 EB 11 17 03 EB 11 38 0E-01 01 01 00 02 FF FF FF ......8.........
1787:0020 FF FF FF FF FF FF FF FF-FF FF FF FF 5F 0F 4E 01 ............_.N.
1787:0030 AB 16 14 00 18 00 87 17-FF FF FF FF 00 00 00 00 ................
1787:0040 06 16 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1787:0050 CD 21 CB 00 00 00 00 00-00 00 00 00 00 20 20 20 .!...........
1787:0060 20 20 20 20 20 20 20 20-00 00 00 00 00 20 20 20 .....
1787:0070 20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00 ........
1787:0080 00 0D 75 73 0D 0D 00 00-00 00 00 00 00 00 00 00 ..us............

Ao executar o DEBUG sem um nome de arquivo, o que for indicado na linha de comando, exceto o comando em si, será exibido a partir dos bytes dos offsets 82h em diante que são frequentemente referenciados como parâmetros ou parâmetros do DOS.
Assim sendo, o "us" na tela acima foi obtido a partir do comando "keyb us" no arquivo AUTOEXEC.BAT do disco de instalação do DOS 6.22. E se tivéssemos executado o comando "dir /w" antes de executar o DEBUG teria aparecido aqui um "/w" .
Obs: as utilizações sucessivas dos parâmetros do DOS nunca são removidas da memória, apenas substituídas. Assim, muitos caracteres de uma sequência de parâmetros muito longa ficam intactas e, como consequência, são copiadas para os bytes dos
offsets 82h por meio de FFh cada vez que DEBUG é executado.

Um desses locais de dados (o Word de offsets 36h - 37h) salva o segmento atribuído ao DEBUG para nosso uso. No entanto, se continuarmos a carregar o arquivo edit.com e despejarmos o início do segmento novamente, veremos que
o próprio valor do segmento muda de 1787h para 1798h (uma diferença de 11h ou 17 parágrafos, no valor de 256 + 16 = 272 bytes):

-n edit.com
-l
-d 0 8f
1798:0000 CD 20 C0 9F 00 9A F0 FE-1D F0 4F 03 EB 11 8A 03 . ........O.....
1798:0010 EB 11 17 03 EB 11 DA 11-01 01 01 00 02 FF FF FF ................
1798:0020 FF FF FF FF FF FF FF FF-FF FF FF FF 75 0F E8 49 ............u..I
1798:0030 EB 11 14 00 18 00 98 17-FF FF FF FF 00 00 00 00 ................
1798:0040 06 16 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1798:0050 CD 21 CB 00 00 00 00 00-00 00 00 00 00 45 44 49 .!...........EDI
1798:0060 54 20 20 20 20 43 4F 4D-00 00 00 00 00 20 20 20 T COM.....
1798:0070 20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00 ........
1798:0080 09 20 45 44 49 54 2E 43-4F 4D 0D 00 00 00 00 00 . EDIT.COM......

Em primeiro lugar, não estávamos seguros por qual motivo o DEBUG estava fazendo isso, sabíamos que não tinha nada a ver com o tamanho do programa, que é de apenas 413 bytes. Isto ocorreu pelo fato de ser o "programa" (EDIT.COM) em vez de ser
outro tipo de arquivo. O DEBUG não fez isso ao carregar arquivos maiores de outros tipos, mas fez isso novamente ao carregar qualquer um dos programas *.EXE. Em seguida, confirmamos uma alteração semelhante ao carregar programas *.COM ou
*.EXE no DEBUG em uma máquina XP, mas a mudança foi maior: ele adicionou até 91 parágrafos. Após mais testes, usando os comandos SET e PATH, descobrimos que o DEBUG precisava carregar uma cópia das "variáveis de ambiente" do DOS entre
sua "área de dados" inicial e uma nova área de dados de 256 bytes que ele cria ao depurar apenas no DOS arquivos de "programas". Mesmo quando não existe nenhuma variável PATH o DEBUG precisa criar uma nova "área de dados" para arquivos
*.COM ou *.EXE.

Ao executar o DEBUG em uma janela DOS do Windows® (em CMD.exe) o despejo dos seus primeiros 256 bytes quase sempre mostrará o mesmo string fragmentado (mostrado abaixo em texto na cor branca). Os caracteres
apresentados são os restos da execução do programa Ntvdm (que é iniciado assim que qualquer comando de 16 bits é executado) quando lida cada uma das linhas do arquivo AUTOEXEC.NT (localizado na pasta [diretório]
C:\WINDOWS\system32), ou seja, a mesma área de memória onde os parâmetros da linha de comando são armazenados. A linha mais longa nesse arquivo, incluindo seu byte 0Dh (carriage return) é sucessivamente substituída por
linhas mais curtas do arquivo até o processo resultar no que foi copiado para os offsets 82h por meio de CEh do segmento do DEBUG:

C:\>debug
-d 0 cf
0B20:0000 CD 20 FF 9F 00 9A EE FE-1D F0 4F 03 84 05 8A 03 . ........O.....
0B20:0010 84 05 17 03 84 05 25 04-01 01 01 00 02 FF FF FF ......%.........
0B20:0020 FF FF FF FF FF FF FF FF-FF FF FF FF 28 05 4E 01 ............(.N.
0B20:0030 44 0A 14 00 18 00 20 0B-FF FF FF FF 00 00 00 00 D..... .........
0B20:0040 05 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0B20:0050 CD 21 CB 00 00 00 00 00-00 00 00 00 00 20 20 20 .!...........
0B20:0060 20 20 20 20 20 20 20 20-00 00 00 00 00 20 20 20 .....
0B20:0070 20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00 ........
0B20:0080 00 0D 20 20 20 53 45 54-20 42 4C 41 53 54 45 52 .. SET BLASTER
0B20:0090 3D 41 30 0D 64 64 72 65-73 73 2E 20 20 46 6F 72 =A0.ddress. For
0B20:00A0 20 65 78 61 6D 70 6C 65-3A 0D 20 6F 6E 20 4E 54 example:. on NT
0B20:00B0 56 44 4D 2C 20 73 70 65-63 69 66 79 20 61 6E 20 VDM, specify an
0B20:00C0 69 6E 76 61 6C 69 64 0D-20 6F 6E 6C 79 2E 0D 00 invalid. only...

Nenhum dos line feeds (0Ah) no final de cada instrução do arquivo AUTOEXEC.NT será apresentado devido o carriage returns (0Dh) os proceder. Isto faz com que o cursor seja enviado sempre para o início das linhas todas as vezes que 0Dh é encontrado
ou quando ocorrer a existência do caractere espacial (20h). É devido a isso que o "REM" das últimas três linhas não é apresentado neste local.

O byte no deslocamento 81h é sempre 0Dh, mesmo se o arquivo AUTOEXEC.NT contiver um único byte de qualquer valor.

Obs: Se você renomear ou excluir AUTOEXEC.NT não poderá executar o DEBUG (nem qualquer outro programa de 16 bits, o qual deve ser executado em Ntvdm). No entanto, você pode salvar uma cópia do AUTOEXEC.NT para depois editá-lo
e ver como suas alterações afetam o que foi copiado para o DEBUG. Você pode reduzir seu tamanho apenas para um único byte. No entanto, para ver qualquer coisa além de zero bytes nos offsets 82h e posterior, pelo menos um byte especial (20h) deve ser colocado
entre um byte não-especial no início de uma linha e o que você deseja ver. Se o arquivo contiver apenas 3 bytes: "T", espaço e "S", 0s offsets 82h e 83h serão "S" seguidos de 0Dh.

Área "Dynamic Stack" do DEBUG

Esta seção está "em desenvolvimento", mas se estiver vendo isso antes de seu término poderá imaginar do que se trata?

Você encontrou um "Bug" no DEBUG?

Embora quase todos os códigos utilizados pelos programadores funcionem como esperados, uma vez que eles eliminaram seus próprios erros de lógica, ocasionalmente, poderá acontecer o surgimento de resultados inesperados porque
os programadores não foram a fundo o suficiente na leitura aprofundada dos manuais do processador usado em um PC. Programadores profissionais sempre testarão seus códigos de diversas maneiras de um ponto de vista razoável,
mas é fundamental estudar os detalhes de programação do processador, especialmente as seções relacionadas a qualquer tarefa a ser executada, tendo este objetivo no topo de sua lista. OBS: Se você deseja ser um hacker melhor, o
exemplo aqui mostrado pode fazer com que você mergulhe de cabeça nos detalhes técnicos do processor Intel e sobre como suas CPUs lidam com as diversas instruções que possui.

Você encontrou duas linhas distintas de instruções assembly que o DEBUG executa sem nunca parar na segunda linha? O exemplo seguinte é um dos muitos exemplos que podemos listar nesta situação. Abra qualquer instância do
DEBUG (DOS ou Windows - qualquer versão), copie e cole o pequeno código seguinte por meio do comando E (Enter) a partir do prompt (-):

e 100 8C C8 8E D0 B0 74 90 90

Após entrar o código anterior execute "u 100 107" e observe o que é apresentado:
xxxx:0100 8CC8 MOV AX,CS <- Deixe o segimento CS na pilha.
xxxx:0102 8ED0 MOV SS,AX <- Uma instrução da tecla!
xxxx:0104 B074 MOV AL,73 <- Pode ser qualquer coisa.
xxxx:0106 90 NOP
xxxx:0107 90 NOP

Agora, execute o comando "r" e na sequência execute o comando (t). Assim que você entrar no comando t notará que o deslocamento usado fica definido de 0102h, até o deslocamento 0106h. Será este um "bug" nunca tratado? A
instrução do offset (deslocamento) 0104h ff poderia ser qualquer dado de: 1-, 2-, 3- ou mesmo 4- bytes. Escolhemos propositadamente uma ação que afeta o conteúdo do registrador, neste caso (AL) para que você pudesse ver que
essa instrução realmente foi executada pela CPU, sem que o usuário tenha a opção de fazê-lo.

Este efeito sempre será observado independentemente da versão do DEBUG nos sistemas operacionais MS-DOS 7.1, 5.0 ou qualquer versão anterior, mesmo no IBM PC DOS 1.0. Se você expandir sua pesquisa para outras
ferramentas de depuração perceberá que cada versão de duas ou mais ferramentas apresentam o mesmo "erro": muita coincidência. Então, por que será que esse código afeta as habilidades de ação sobre a interrupção de certo
depurador?

Se você ainda não obteve o conjunto de manuais de referência de instruções do processador Intel®. É melhor obtê-los. Procure pelas palavras chave: Intel, IA32, Software, Instruction. Pelo menos faça o download de uma cópia
digital PDF do conjunto de referência dos manuais (Geralmente encontrados em dois arquivos separados: Volume 2A: Instruction Set Reference, A-M e Volume 2B: Instruction Set Reference, N-Z). Na cópia que eu obtive em janeiro de 2006 para
"MOV—Move", foi encontrado: " Loading the SS register with a MOV instruction inhibits all interrupts until after the execution of the next instruction. (Carregar o registro SS com uma instrução MOV inibe todas as
interrupções até a execução da próxima instrução). Esta operação permite que um ponteiro de pilha seja carregado no registrador ESP com a próxima instrução (MOV ESP, valor do ponteiro de pilha) antes da ocorrência de
uma interrupção1." (IA-32 Intel® Architecture Software Developer’s Manual, Volume 2A: Instruction Set Reference, A-M, 253666-018, Jan 2006, "MOV—Move," páginas 3-584). A nota de rodapé 1 afirma claramente que: " If a code instruction
breakpoint (for debug) is placed on an instruction located immediately after a MOV SS instruction, the breakpoint may not be triggered. [Se um ponto de interrupção de instruções de código (para depuração) for
colocado em uma instrução localizada imediatamente após uma instrução de MOV SS , o ponto de interrupção pode não ser acionado]" (páginas 3-585). Para os novatos no uso de programas depuradores a operação no
"ponto de interrupção da instrução" a que se refere não é um ponto de interrupção definido pelos usuário, mas sim, um ponto de interrupção definido automaticamente pelo próprio depurador. Então, de acordo com a documentação dos
manuais, o que você julga ser um "bug" do DEBUG é de fato uma ação realizada pelo processador naquilo em que foi projetado para fazer.

Devido a isto acreditamos que o MS-DEBUG é completamente livre de "bugs"? Não. No futuro, publicaremos alguns exemplos de 'bugs' reais do programa DEBUG.

Antes de usar qualquer um dos comandos de depuração (Trace, Procedure) ou Register, você deve se familiarizar com as abreviaturas dos Registradores da CPU referenciados pelo programa DEBUG (Veja o Apêndice, Os
registradores da CPU 8086 para maiores detalhes.)

Você também deve saber sobre o método de endereçamento SEGMENT:OFFSET usado pelo DEBUG (e por outros programas utilitários).

Uma nota sobre onde e como DEBUG é usado na memória de um computador.

 Usar o DEBUG em uma janela prompt do Windows® pela primeira pode facilmente confundir você. Se você abrir duas instâncias do DEBUG (uma por janela DOS) e examinar toda a memória que pode ser acessada, notará a
existência de dados completamente diferentes em muitas das mesmas localizações de memória em ambas as janelas. A razão disso advém do fato de que cada aplicação sob o sistema operacional Windows™ é
(teoricamente) executada de forma separada como se fosse um "computador virtual" de 4 Gigabytes para reproduzir uma cópia dos dados críticos dentro do primeiro Megabyte de memória da máquina feito em cada
instância em execução do DEBUG. Somente abaixo do DOS de 16 bits o DEBUG realmente tem acesso aos locais reais de memória nos quais o próprio sistema operacional está sendo executado, tornando muito mais fácil
travar todo o sistema se um erro ocorrer. No Windows® a teoria diz que tais erros devem travar apenas a janela do aplicativo CMD que causou o problema, mas não no computador inteiro. Pelo menos é assim que o
Windows® deve operar. Por experiência, parece que o Windows™ 2000/XP faz um trabalho muito melhor para manter o controle de seus sistemas nas mesmas circunstâncias que muitas vezes terminaram em Blue Screen
(famosa tela azul) como ocorre com versões anteriores.

OBS: Se você decidir usar um programa de emulação como PCE emulation (somente em inglês) o DEBUG existirá inteiramente dentro do espaço de memória configurado pelo emulador para qualquer sistema operacional que
você esteja executando. Vamos tentar localizar e apontar quaisquer inconsistências ao usar o PCE com as versões iniciais do DEBUG, mas apreciaremos os comentários dos nossos leitores.

Links rápidos para todos os comandos

(Listados em ordem alfabética)
Recomendamos ler todo o Tutorial do DEBUG antes de usar esses links de comandos rápido.

Para obter ajuda sobre todos os comandos disponíveis dentro do DEBUG, basta inserir um ponto de interrogação (?) no prompt do DEBUG ao fazer uso do DOS 5.0 ou superior.

Clique em um dos comando a seguir para obter mais detalhes:

-?
assemble A [endereço]
compare C intervalo de endereço
dump D [intervalo]
enter E endereço [lista]
fill F lista de intervalos
go G [=endereço] [endereços]
hex H valor1 valor2
input I porta
load L [endereço] [unidade] [primeiro setor] [número]
move M intervalo de endereços
name N [caminho] [lista de argumentos]
output O byte da porta
proceed P [=endereço] [número]
quit Q
register R [registrador]
search S lista de intervalos
trace T [=endereço] [valor]
unassemble U [intervalo]
write W [endereço] [unidade] [primeiro setor] [número]

Página Dois

Atualizado: 9 de dezembro de 2007 (09/12/2007); 12 de fevereiro de 2009 (12/02/2009); 24 de agosto de 2009 (24/08/2009); 20 de abril de 2015 (20/04/2015).
Última atualização: 18 de fevereiro de 2017. (18/02/2017)

Página: The Starman's Realm Assembly (somente em inglês)

 Website patrocinador: Emergency Boot CD (somente em inglês)

Espero que você goste dos exemplos de codificação em linguagem assembly usados nesta página. Se você tiver alguma dúvida sobre eles, utilize este formulário on-line para me enviar um e-mail somente em inglês. ( Abre uma nova janela. )

Um guia para o DEBUG

(Página Dois)

Tutorial do DEBUG
Copyright©2005,2009 para Daniel B. Sedory

Esta página pode ser copiada gratuitamente apenas para uso pessoal !
( Não pode ser usada para qualquer outro propósito, a menos que você tenha
primeiro contatado (somente em inglês) e tenha recebido permissão do autor ! )

Sítio traduzido para a língua portuguesa por

Augusto Manzano com autorização expressa do autor
(vide fim desta página).
Acesse aqui a versão original em inglês.

Cada comando - listado alfabeticamente

Links rápidos para os comandos de Ajuda

Como usar os COMANDOS

Significado dos Parâmetros dos Comandos

Ajuda detalhada de cada Comando (começa aqui)

Um exemplo de programa para você entrar, executar e editar em DEBUG.
Uma nota sobre o string 'IHC' do Win 9x em seteroes de inicialização de disquete

Apêndices
Os Registradores da CPU 8086
Os Registradores de FLAGS
O método de endereçamento Segment:Offset usado pelo DEBUG

Ajuda dos comandos DEBUG

Para obter auxílio dos comandos (e a maioria dos parâmetros) disponíveis dentro do DEBUG basta inserir um ponto de interrogação (?) na linha de prompt do DEBUG quando estiver em uso o sistema operacional DOS 5.0 ou
superior. ( Obs: Os comandos de memória expandida raramente são usados e não serão discutidos.)

Links alfabéticos rápidos

Clique em um dos seguintes comandos para acessar seus detalhes:

-?
assemble A [endereço]
compare C intervalo de endereços
dump D [intervalo]
enter E endereço [lista]
fill F lista de intervalos
go G [=endereço] [endereços]
hex H valor1 valor2 (Consulte isto, antes dos demais comandos)
input I porta
load L [endereço] [unidade] [primeiro setor] [número]
move M intervalo de endereços
name N [caminho] [lista de argumentos]
output O byte da porta
proceed P [=endereço] [número]
quit Q . . . . . . . . . (Consulte este comando primeiro!)
register R [registrador]
search S lista de intervalos
trace/step T [=endereço] [valor]
unassemble U [intervalo]
write W [endereço] [unidade] [primeiro setor] [número]

Como usar os
COMANDOS

Parâmetros

OBS: Os parâmetros listados entre colchetes ( [ ] ) são opcionais. Os parâmetros opcionais normalmente indicam que existe várias maneiras diferentes de usar um comando. Eu listei os significados de todos os parâmetros aqui
para você:

endereço - Local da memória indicado em hexadecimal. Você pode usar um valor de Offset (Deslocamento) simples (nesse caso, o segmento de código CS será assumido automaticamente) ou pode inserir o endereço do
segmento de forma completa: utilizando números hexadecimais como indicação do local de deslocamento ou substituindo o nome de um registrador de segmento por um número. Não são necessários inserir zeros iniciais: assim, 1F, é o
mesmo que indicar 'CS: 001F' (a indicação CS significa determinar o que se deseja que ocorra no registrador CS no momento de sua definição). Exemplos:
100 DS:12 SS:0 198A:1234

Para mais detalhes, consulte: notação Segment:Offset (Segmento:Deslocamento).

intervalo - Dois endereços hexadecimais separados por um espaço que definem um segmento completo. Pode ser usado pares de deslocamento ou apenas um deslocamento (nesse caso, o segmento é assumido como
segmento de código CS). OBS: Alguns comandos, como Compare (C) podem exigir que o segundo endereço seja fornecido como deslocamento.

lista - Uma sequência de bytes hexadecimais separados por espaço ou dados do tipo ASCII incluídos em cadeias definidas com aspas simples ou aspas inglesas. Você pode listar qualquer número de bytes em uma única
linha com qualquer quantidade de definições antes de pressionar a tecla Enter. Um byte único, como 00, é usado com maior frequência com o comando FILL (f) enquanto um comando ENTER (e) provavelmente terá uma sequência de
varios bytes hexadecimais ou caracteres ASCII em uma linha. Por exemplo:
e 100 31 C0 B4 09 BA 50 02 CD 21 B8 4C 00 CD 21

e 250 'This is an ASCII data string.$'

número - Lembre-se que todos os valores numéricos utilizados em qualquer comando DEBUG são entendidos como hexadecimais. Isso inclui o número de setores nos comandos LOAD ou WRITE e até mesmo o número de
instruções que você deseja que DEBUG passe nos comandos TRACE ou PROCEED. Os valores usados são sempre do tipo HEX quando se usa o DEBUG.

Um Tutorial DEBUG simples

Detalhes de cada comando
OBS: Nos Exemplos a seguir os comandos inseridos por um usuário são mostrados em negrito e os dados exibidos em resposta pelo DEBUG estão grafados com tipo de fonte normal. O programa DEBUG do MS-DOS 5.0 ou superior
(sendo isto válido para a versão DEBUG existente no Windows™ XP) exibirá a mensagem de ajuda após acionar enter quando executado debug /? no prompt do DOS:
C:\WINDOWS>debug /?
Runs Debug, a program testing and editing tool.

DEBUG [[drive:][path]filename [testfile-parameters]]

[drive:][path]filename Specifies the file you want to test.

testfile-parameters Specifies command-line information required by
the file you want to test.

Quit: Q
Encerra imediatamente o programa Debug. Nenhuma pergunta é feita no encerramento. Deve ser o primeiro comando a ser lembrado juntamente com o comando de ajuda "?".
Volta para TOC

Hex: H valor1 valor2

Uma calculadora hexadecimal simples que apenas adiciona e subtraí valores. Nunca se esqueça de que todos os números dentro do DEBUG são valores expressos na forma hexadecimal. Informe dois valores hexadecimais (com no
máximo quatro dígitos de tamanho cada valor) e o DEBUG mostra primeiro o resultado da SOMA e em seguida o resultado da DIFERENÇA dos valores informados. Exemplos:
-h aaa 531 -h fff 3 -h dbf ace
0FDB 0579 1002 0FFC 188D 02F1
- - -

O resultado da diferença sempre será o valor do segundo termo subtraído do primeiro termo: AAA - 531 = 579.

A aritmética de Complemento de Dois é usada nesta calculadora na representação de resultados de valores negativos com limitação operacional de cálculo para valores no intervalo máximo de 7FFFh (+32.767) positivo e mínimo de
8000h (-32.768) negativo. Os valores positivos são representados pelos mesmos dígitos usados para rerpresentar os valores entre 0000h e 7FFFh. O valor negativo 7FFFh é representado pelos dígitos hexadecimais 8001 e o valor
negativo 1h (-1) é representado pelos dígitos hexadecimais FFFF. Assim, a saída no DEBUG após entrar "h 4 fffc" será zero e 8, uma vez que FFFC representa um valor negativo 4h (-4) e 4 - (-4) = 8. Exemplo:

-h 4 fffc -h 100 123 -h 7fff 8000

0000 0008 0223 FFDD FFFF FFFF
- - -

Observe a diferença entre 100h e 123h. O que representa FFDD? Para determinar o valor de um número baseado em complemento de dois é necessário primeiro inverter cada bit (ou encontrar seu inverso lógico). Neste caso, 0022 e
então adiciona-se 1 e ter-se-á um valor negativo 23h. Tanto a soma como a diferença de 7FFFh e 8000h podem ser um valor negativo (ou valor positivo FFFF) que podem ser usados para representar: 7FFFh como positivo (ou
negativo 8000h quando = -1). No entanto, é mais prático pensar que os montantes não têm nada a ver com a notação de complemento de dois. Assim, 7FFFh + 8000h = FFFFh (32,767 + 32,768 = 65,535). Esse mesmo valor poderá
ser válido para o resultado da diferença se o segundo valor for menor que o primeiro valor. No entanto, qualquer diferença que produza um valor negativo deve ser representada com a notação de complemento de dois.

Volta para TOC

Dump: D [intervalo]
D [endereço] [comprimento]

Exibe o conteúdo de um bloco de memória. Os locais de memória na imediação do segmento C000 (mesmo para Windows 2000/XP) devem exibir informações sobre o tipo de placa de vídeo instalada no PC. O primeiro exemplo a
seguir mostra o que uma placa de vídeo Matrox no nosso sistema exibiu.

Exemplos:

-d c000:0010
C000:0010 24 12 FF FF 00 00 00 00-60 00 00 00 00 20 49 42 $.......`.... IB
C000:0020 4D 20 43 4F 4D 50 41 54-49 42 4C 45 20 4D 41 54 M COMPATIBLE MAT
C000:0030 52 4F 58 2F 4D 47 41 2D-47 31 30 30 20 56 47 41 ROX/MGA-G100 VGA
C000:0040 2F 56 42 45 20 42 49 4F-53 20 28 56 31 2E 32 20 /VBE BIOS (V1.2
C000:0050 29 00 87 DB 87 DB 87 DB-87 DB 87 DB 87 DB 87 DB )...............
C000:0060 50 43 49 52 2B 10 01 10-00 00 18 00 00 00 00 03 PCIR+...........
C000:0070 40 00 12 10 00 80 00 00-38 37 34 2D 32 00 FF FF @.......874-2...
C000:0080 E8 26 56 8B D8 E8 C6 56-74 22 8C C8 3D 00 C0 74 .&V....Vt"..=..t
-

-d 100 130
xxxx:0100 EB 24 0D 0A 54 68 69 73-20 69 73 20 6D 79 20 66 .$..This is my f
xxxx:0110 69 72 73 74 20 44 45 42-55 47 20 70 72 6F 67 72 irst DEBUG progr
xxxx:0120 61 6D 21 0D 0A 24 B4 09-BA 02 01 CD 21 B4 00 CD am!..$......!...
xxxx:0130 21 !
-

O segundo exemplo acima é o que você verá após inserir o código sob o comando Assemble. Poderia ter sido utilizado como facilidade a opção de comprimento com o comando 'd 100 l31' (que é um 'L' a frente de "31") para
produzir os mesmos resultados acima. O exemplo a seguir mostra a sequência de exibição terminada em "$" que tem um comprimento de bytes de 24h bytes (os valores numéricos operacionalizados no DEBUG são sempre
hexadecimais). Então é 36 em decimal:
-d 102 l24
xxxx:0100 0D 0A 54 68 69 73-20 69 73 20 6D 79 20 66 ..This is my f
xxxx:0110 69 72 73 74 20 44 45 42-55 47 20 70 72 6F 67 72 irst DEBUG progr
xxxx:0120 61 6D 21 0D 0A 24 am!..$
-

Volta para TOC

Search: S lista de intervalos

Pesquisas dentro de um intervalo de endereços para um ou mais valores de bytes definidos em uma lista. A lista pode ser composta por números ou cadeias de caracteres definidas entre aspas simples ou aspas inglesas. [ OBS: Nos
exemplos abaixo poderá ocorrer que na apresentação de seus dados os pontos apresentados serem diferentes dos aqui indicados. ]

Exemplos:

-s fe00:0 ffff "BIOS"

FE00:0021
FE00:006F

-d fe00:0
FE00:0000 41 77 61 72 64 20 53 6F-66 74 77 61 72 65 49 42 Award SoftwareIB
FE00:0010 4D 20 43 4F 4D 50 41 54-49 42 4C 45 20 34 38 36 M COMPATIBLE 486
FE00:0020 20 42 49 4F 53 20 43 4F-50 59 52 49 47 48 54 20 BIOS COPYRIGHT
FE00:0030 41 77 61 72 64 20 53 6F-66 74 77 61 72 65 20 49 Award Software I
FE00:0040 6E 63 2E 6F 66 74 77 61-72 65 20 49 6E 63 2E 20 nc.oftware Inc.
FE00:0050 41 77 03 0C 04 01 01 6F-66 74 77 E9 12 14 20 43 Aw.....oftw... C
FE00:0060 1B 41 77 61 72 64 20 4D-6F 64 75 6C 61 72 20 42 .Award Modular B
FE00:0070 49 4F 53 20 76 34 2E 35-31 50 47 00 DB 32 EC 33 IOS v4.51PG..2.3

-s 0:0 dff 'A20'

0000:0C42

-d 0:c40
0000:0C40 0D 0A 41 32 30 20 68 61-72 64 77 61 72 65 20 65 ..A20 hardware e
0000:0C50 72 72 6F 72 2E 20 20 43-6F 6E 74 61 63 74 20 74 rror. Contact t
0000:0C60 65 63 68 6E 69 63 61 6C-20 73 75 70 70 6F 72 74 echnical support
0000:0C70 20 74 6F 20 69 64 65 6E-74 69 66 79 20 74 68 65 to identify the
0000:0C80 20 70 72 6F 62 6C 65 6D-2E 0D 0A 24 1A 00 BA F6 problem...$....

-s 0:0 dff 43 4f 4d
0000:0774
0000:07C2
0000:07D4
0000:07E6

-d 0:770
0000:0770 7A 02 A6 02 43 4F 4D 31-20 20 20 20 8E 00 70 00 z...COM1 ..p.
0000:0780 C0 A0 7A 02 91 02 4C 50-54 31 20 20 20 20 A0 00 ..z...LPT1 ..
0000:0790 70 00 C0 A0 7A 02 98 02-4C 50 54 32 20 20 20 20 p...z...LPT2
0000:07A0 2D 01 70 00 C0 A0 7A 02-9F 02 4C 50 54 33 20 20 -.p...z...LPT3
0000:07B0 20 20 11 EA 27 27 3F FD-CA 00 70 00 00 80 7A 02 ..''?...p...z.
0000:07C0 AC 02 43 4F 4D 32 20 20-20 20 DC 00 70 00 00 80 ..COM2 ..p...
0000:07D0 7A 02 B2 02 43 4F 4D 33-20 20 20 20 00 00 6B 03 z...COM3 ..k.
0000:07E0 00 80 7A 02 B8 02 43 4F-4D 34 20 20 20 20 E8 D2 ..z...COM4 ..

Volta para TOC

Compare: C intervalo de endereços

Compara dois blocos de memória. Se não houver diferenças, então o DEBUG simplesmente exibe outro prompt (-). Aqui está um exemplo do que acontece quando há diferenças:
 -c 140 148 340
127D:0143 30 6D 127D:0343
127D:0146 10 63 127D:0346
127D:0148 49 30 127D:0348

Os bytes nos locais 140 a 148 estão sendo comparados aos bytes do local de 340 ( até implicitamente 348, ). Os bytes são exibidos lado a lado para aqueles que são diferentes (com seus locais exatos, incluindo o segmento em
ambos os lados).

Volta para TOC

Fill: F lista de intervalos

Este comando também pode ser usado para limpar a todo um segmento de memória, além de preencher áreas menores com uma sequência de caracteres de repetição contínua ou um byte único. Exemplos:

-f 100 12f 'BUFFER'

-d 100 12f
xxxx:0100 42 55 46 46 45 52 42 55-46 46 45 52 42 55 46 46 BUFFERBUFFERBUFF
xxxx:0110 45 52 42 55 46 46 45 52-42 55 46 46 45 52 42 55 ERBUFFERBUFFERBU
xxxx:0120 46 46 45 52 42 55 46 46-45 52 42 55 46 46 45 52 FFERBUFFERBUFFER

-f 100 ffff 0

Este exemplo preenche quase todo o segmento atribuído com zero bytes (o que também pode ser considerado como o encerramento do segmento). Você deve usar este comando sempre que quiser ter certeza de que os bytes que
você olha no segmento do DEBUG são os que você inseriu ou carregou ou os bytes DEBUG que foram alterados. Se não quiser a existência de bytes da memória e necessita examinar um arquivo em disco em um segmento 'limpo',
primeiro você deve iniciar o DEBUG sem qualquer nome de arquivo, depois limpar o segmento usando o comando: f 100 ffff 0 e então na sequência carregar o arquivo usando os comandos Name (n) e Load (L) nessa ordem.

OBS: Preencher (limpar) quaisquer bytes na área de 00h até FFh do segmento em uso pode às vezes levar a problemas, especialmente quando está em uso arquivos I/O. O DEBUG armazena dados para seu próprio uso nesse
endereço, assim, recomendamos que você nunca substitua bytes nessa área. A menos que você tenha um forte motivo para fazê-lo.

Exemplo: um aluno de linguagem Assembly foi informado para inserir uma sequência de comandos no DEBUG, sendo o último comando JMP 0. Foi orientado que em seguida executasse o comando Trace (T) para depois executar a
instrução INT 20. Na maioria das vezes isso é verdade. O DEBUG sempre define os dois primeiros bytes de seu segmento de trabalho para "CD 20" apenas para este propósito. Vamos testar isso: primeiro abra uma nova instância do
DEBUG e, em seguida, insira os seguintes comandos:

-f 100 ffff 0 [Limpando o segmento com zeros de 100 até FFFF]

-e 100 e9 fd fe [Inserido 'JMP 0' no local 100]
-u 100 102 [Verificando a entrada correta]
xxxx:0100 E9FDFE JMP 0000
-r
AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=xxxx ES=xxxx SS=xxxx CS=xxxx IP=0100 NV UP EI PL NZ NA PO NC
xxxx:0100 E9FDFE JMP 0000
-u 0 1
xxxx:0000 CD20 INT 20

Caso não veja "INT 20" após entrar "u 0 1", então reinicie o DEBUG e tente novamente.

-t [O comando "T"(Trace)]

AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000

DS=xxxx ES=xxxx SS=xxxx CS=xxxx IP=0000 NV UP EI PL NZ NA PO NC
xxxx:0000 CD20 INT 20
-p [Certifique-se em usar o comando "P"(Proceed) para Interrupções.]

Program terminated normally

-q [Quit]

Bom, isso nunca funcionou para o estudante. Por quê? Porque o professor havia dito erroneamente para limpar com Fill o segmento inteiro com zero bytes (f 0 ffff 0). Em essência, o professor disse para excluir a própria instrução que
ele queria que os alunos executassem.

Volta para TOC

Enter: E endereço [lista]

Usado para inserir dados ou instruções (como código da máquina) diretamente nas localizações de memória.
Exemplo. Primeiro, mudaremos um único byte no local CS:FFCB que antes era D2 :
-e ffcb d2

O próximo exemplo mostra que as definições de aspas simples (') ou aspas inglesas (") são aceitáveis para a entrada de dados no formato ASCII. Ao permitir que ambos as formas de definição de cadeias possam ser definidas para
inclusão de qualquer tipo de marcação para os dados:
-e 200 'An "ASCII-Z string" is always followed by '
-e 22a "a zero-byte ('00h')." 0

Mas, para inserir mais do que uma linha de dados ASCII, o comando A (Assemble) é mais prático, pois calcula automaticamente o próximo deslocamento. (Veja esse comando para os despejos de memória desses bytes.) Agora,
vejamos uma sequência de 11 octetos hexadecimais que você pode inserir na memória nos locais CS: 0100 da seguinte forma:
-e 100 B4 09 BA 0B 01 CD 21 B4 00 CD 21

Este é realmente o código de máquina para um programa que exibirá os caracteres ASCII encontrados a partir da localização CS: 010B até encontrar o valor de byte 24h (um sinal de $). Se você quiser executar este programa,
recomendamos que entre o valor 24h na posição de deslocamento 7EAh do segmento para que o programa termine:
-e 7ea 24
-g =100

Você verá a indicação da mensagem: "Program terminated normally" no monitor de vídeo (ecrã). Por que escolhemos 7EAh? Como muitas telas do DOS estão configuradas para exibir apenas 25 linhas de caracteres com 80 (50h) posições
de texto, esse valor é o que permite a você visualizar o número máximo de caracteres de uma única vez na tela entre as linhas de terminação do prompt ("-") após executar o comando "Go,".

Aqui há algo um pouco mais interessante para você observar: é essencialmente o mesmo programa, mas os dados incluem todos os valores de bytes de 00h até FFh, exceto para 24h que foi colocado no final da última linha. O símbolo
do prompt DEBUG, - , foi propositalmente excluído das linhas abaixo para que você possa copiar e colar todo o bloco em uma janela DEBUG no prompt do CMD do Windows (A ajuda sobre o uso dos controles do DOS em Windows
estão aqui [em inglês]):
e 100 B4 09 BA 0B 01 CD 21 B4 00 CD 21 0D 0A 0D 0A 00 01 02
e 112 03 04 05 06 07 08 09 20 0B 0C 20 0E 0F 10 11 12 13 14
e 124 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 20 25 26
e 136 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38
e 148 39 3A 3B 3C 3D 3E 3F 0D 0A 0D 0A 40 41 42 43 44 45 46
e 15a 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58
e 16c 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A
e 17e 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C
e 190 7D 7E 7F 0D 0A 0D 0A 80 81 82 83 84 85 86 87 88 89 8A
e 1a2 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C
e 1b4 9D 9E 9F a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aA aB aC aD aE
e 1c6 aF b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 bA bB bC bD bE bF 0D
e 1d8 0A 0D 0A c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 cA cB cC cD cE
e 1ea cF d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 dA dB dC dD dE dF e0
e 1fc e1 e2 e3 e4 e5 e6 e7 e8 e9 eA eB eC eD eE eF f0 f1 f2
e 20e f3 f4 f5 f6 f7 f8 f9 fA fB fC fD fE fF 0D 0A 0D 0A 24

Os bytes 0Dh e 0Ah produzem um retorno de carro (tecla Enter) e mudança de linha na tela, então substituímos na lista acima por 20h, um byte do tipo SPACE. O byte 24h foi movido para o final do programa com mais 20h ocupando
seu lugar. Os bytes mostrados acima em azul (0D 0A 0D 0A) formam as linhas em branco no início da saída e após cada 64 bytes para uma exibição formatada mais agradável.

Portanto, quando o programa é executado, devemos ver quatro linhas separadas de 64 caracteres cada (alguns desses espaços em branco como mencionado acima),correto? Bem, vamos descobrir. Comece o DEBUG em uma janela
do DOS-Window, copie e cole as linhas acima no seu símbolo de prompt e então digite o comando:

g =100 ( 'g' seguido de um espaço em branco, então definido com '=100')

Isso será executado imediatamente (veja o comando Go) do programa exibindo as linhas de saída conforme: "Program terminated normally" [ Não saia do DEBUG, deixe a janela aberta. Vou mostrar como "corrigir" este código e
salvar os resultados como um pequeno programa do console ].

Você ficou surpreso ao encontrar mais de quatro espaços na primeira linha, começando pelo primeiro byte? E o fato de parecemos ter caracteres desaparecidos no final dessa linha? Explicarei brevemente por que os caracteres
apareceram dessa maneira na tela, mas, para criar programas próprios, você precisará estudar sobre caracteres de controle, interrupções e os efeitos que as diferentes funções de BIOS e DOS video têm sobre o modo ASCII. Aqui
está o que aconteceu:

Primeiro, o byte zero também é exibido como um espaço em branco. O byte 07 pode gerar um beep ou ding como sinal sonoro (mas não exibe nada tela), o byte 08 executa um BACKSPACE (apagando um caractere de 06 bytes) e o
byte 09 que é um TAB -- pode pular até oito colunas para a direita antes de chegar ao próximo 'Tab Stop.' Mas uma vez que é iniciado na coluna sete, ele apenas move uma coluna para a direita onde o programa coloca um espaço que
foi substituído por 0Ah. Finalmente, por algum motivo, ao usar a função 09 com a interrupção INT 21h ("Que exibe uma sequência de caracteres até que seja encontrado o caractere de finalização de cadeia '$' "), o caractere ESC (1Bh;
27 decimal) não exibe ou faz nada. Então, depois de chegar ao final da primeira linha, só apareceu como se muitos dos caracteres que esperávamos ver nunca fossem exibidos. Na realidade, os três últimos caracteres estão lá. É por
causa dos bytes 07h (não exibe nada), 08h (apenas backspaced 06h), 09h (não exibe nada, mas move o cursor para frente um byte) e 1Bh (não exibe nada) que foi possível perceber o que fizemos.

Informe as duas linhas seguintes no DEBUG (que faz uso de mais substituições com espaços em branco). Execute o programa novamente e você percebera a indicação de todos os caracteres imprimíveis na primeira linha em suas
posições corretas:

e 10F 00 01 02 03 04 05 06 20 20 20 20 0B 0C 20
e 11D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 20

Todas as quatro linhas serão exibidas uniformemente. Mas o último caractere FFh (255 decimal), assim como o primeiro caractere é exibido, neste local, como um espaço em branco. Você pode verificar esta ocorrência inserindo outro
byte, como 2Eh (um período '.') após FFh. Veja o seguinte trecho de código que efetivamente move o restante do programa após FFh, efetivando uma correção:

e 21b 2e 0d 0a 0d 0a 24

Depois de efetivar a correção e executar o programa novamente a saída do programa deverá assim ser:

Se você quiser, poderá salvar este código como um programa executável indicando um caminho e nome de arquivo (como, C:\TEMP\ASCIIDSP.COM; veja o comando Name) e para escrever os bytes (veja o comando Write) como, por
exemplo:
-n c:\temp\asciidsp.com
-rcx
CX0000
:121 [ Comprimento do programa = 220h - 100h + 1 = 121h ]
-w

Se você verificar as propriedades do arquivo ASCIIDSP.COM verá que seu tamanho será de 289 bytes.

Volta para TOC

Go: G [=endereço] [endereços]

Comando usado para executar um programa e definir os breakpoints (pontos de interrupção) no código do programa.

Como visto em um Exemplo para o comando ENTER, a opção '= endereço' é usada para dizer ao DEBUG onde começar a executar o código. Se você usar 'g' apor si só a execução começará em qualquer localidade apontada pelos
registradores CS:IP.

Os breakpoints (pontos de interrupção) são usados para a ação HALT que determina o ponto de interesse de um programa antes de seu término. Podem ser definidos opcionalmente até 10 endereços ponto de interrupção a
partir da linha de comando '-g' separando os endereços por espaços em branco. O DEBUG interrompe a execução imediatamente antes de qualquer um dos endereços do ponto de interrupção que está prestes a ser executado e todos
os pontos poderão ser "verificados". (Caso seja informado mais de 10 valores de endereço como pontos de interrupção o DEBUG responderá com a mensagem: bp Error.

OBS: Os pontos de interrupção só podem ser configurados em um ponto de endereço que tenha o primeiro byte de um endereço válido de opcode 8088/8086. Portanto, não se surpreenda se escolher algum endereço arbitrário e o
programa não mais parar, especialmente se você estiver tentando executar no DEBUG um programa que contenha opcodes não suportados pelo DEBUG (como instruções que necessitarem de uma CPU acima do modelo de
processador 8088/8086).

Ao usar "Go" depois da definição de pontos de interrupção o programa DEBUG entenderá que essa será a maneira de obter mais ação do programa em uso. Por exemplo, ao depurar o código "real" de um Master Boot Record escrito
para um processador 80386 ou acima o DEBUG não poderá desmontar e nem executar esse código, mas poderá percorrer o código na CPU de forma imediata e ainda parar nos pontos de interrupção definidos para qualquer
instrução que o DEBUG entende.

ATENÇÃO: O DEBUG substitui as instruções originais de qualquer endereço de ponto de interrupção listado com CCh (com INT 3). As instruções nesses locais são restauradas somente para seus bytes originais se um dos pontos de
interrupção for encontrado. Se o DEBUG não parar em nenhum dos pontos de interrupção estabelecidos, eles permanecerão habilitados. Então, nunca salve o código, a menos que você tenha certeza de que todos os pontos de
interrupção foram apagados. (Salvar seu trabalho em uma cópia de backup antes de usar um ponto de interrupção é a melhor maneira de evitar a corrupção do código).

Notas técnicas: O ponteiro da pilha "User" deve ser válido e ter 6 bytes disponíveis para que este comando funcione corretamente. Uma instrução iret é usada para saltar para o primeiro ponto de interrupção encontrado. O DEBUG
define o ponteiro de pilha do usuário e envia os flags ao registro do segmento e o ponteiro da instrução para a pilha. Portanto, se a pilha não for válida ou for muito pequena a operação poderá falhar.

Volta para to TOC

Assemble: A [endereço]

Cria o código executável na memória começando em CS: 0100 (ou o endereço especificado) das instruções 8086/8088 (e 8087) referentes a linguagem Assembly. Embora não sejam reconhecidas instruções de macro com rótulos, é
possível usar pseudo-instruções 'DB' e 'DW'.

O comando 'A' O comando 'A' lembra o último local onde todos os dados foram montados. Então sucessivos comandos 'A' (quando nenhum endereço é especificado) sempre fará com que seja considerado o próximo endereço de
instrução. Este aspecto é semelhante ao comando Dump que lembra a localização de seu último despejo (se nenhum endereço novo for especificado).

O processo de montagem irá parar após ser com ENTER informada uma nova linha vazia.

Exemplos:

Usando a sequência de caracteres do comando E (Enter) acima:

-a 200
xxxx:0200 db 'An "ASCII-Z string" is always followed by '
xxxx:022A db "a zero-byte ('00h').", 0
xxxx:023F
-d 200 23e
xxxx:0200 41 6E 20 22 41 53 43 49-49 2D 5A 20 73 74 72 69 An "ASCII-Z stri
xxxx:0210 6E 67 22 20 69 73 20 61-6C 77 61 79 73 20 66 6F ng" is always fo
xxxx:0220 6C 6C 6F 77 65 64 20 62-79 20 61 20 7A 65 72 6F llowed by a zero
xxxx:0230 2D 62 79 74 65 20 28 27-30 30 68 27 29 2E 00 -byte ('00h')..

Informe os caracteres grafados na cor azul. Não. é necessário inserir os comentários após os símbolos de ponto e vírgula (;):
-a 100
xxxx:0100 jmp 126 ; Jump over data that follows:
xxxx:0102 db 0d,0a,"This is my first DEBUG program!"
xxxx:0123 db 0d,0a,"$"
xxxx:0126 mov ah,9 ; Function 09 of Int 21h:
xxxx:0128 mov dx,102 ; DS:DX -> $-terminated string.
xxxx:012B int 21 ; Write String to STD Output.
xxxx:012D mov ah,0 ; Function 00 of Int 21h:
xxxx:012F int 21 ; Terminate Program.
xxxx:0131
-g =100

This is my first DEBUG program!

Program terminated normally

-

OBS: Você pode definir de forma simples linhas de comentários 8086/8088 Assembly após cada instrução definida após o uso do símbolo de ; (ponto e vírgula) na maior parte das
instruções Por algum motivo linhas de comentários não são permitidas nas linhas DB / DW. Por exemplo, você pode copiar e colar o seguinte código no DEBUG (após inserir um
comando inicial "a") e obter os mesmos resultados anteriores:
jmp 126 ; Jump over data that follows:
db 0d,0a,"This is my first DEBUG program!"
db 0d,0a,"$"
; End of string marker above: "$"=24h
mov ah,9 ; Function 09 of Int 21h:
mov dx,102 ; DS:DX -> $-terminated string.
int 21 ; Write String to STD Output.
mov ah,0 ; Function 00 of Int 21h:
int 21 ; Terminate Program.

O DEBUG usa a convenção de anexar operandos que se referem a locais de memória entre colchetes '[ ]' (em oposição a um valor imediato como um operando).

DEBUG pode exigir que você diga explicitamente se um operando se refere ou não a uma word ou byte na memória. Nesses casos, o tipo de dados deve ser indicado usando os
prefixos 'WORD PTR' ou 'BYTE PTR'.
 Em relação ao coprocessador 8087, para seu uso é indicado a definição dos prefixos WAIT ou FWAIT.
Volata para TOC

Unassemble: U [intervalo]
Desmonta as instruções 8086 de código de máquina de um programa. Sem o [intervalo opcional], o programa usa o Offset 100 como seu ponto de partida, desmontando cerca de 32 bytes e depois desloca para o
próximo byte caso o comando venha a ser usado novamente.

OBS: O usuário deve decidir se os bytes que DEBUG desmonta são todos relacionados a instruções 8086, dados oou quaisquer instruções x86 mais recentes (aquelas voltadas para o 80286, 80386 que estão além
da capacidade do DEBUG entender).
Exemplo:

-u 126 12F
xxxx:0126 B409 MOV AH,09
xxxx:0128 BA0201 MOV DX,0102
xxxx:012B CD21 INT 21
xxxx:012D B400 MOV AH,00
xxxx:012F CD21 INT 21
-

Volta para TOC

Input: I porta

O uso de comandos de I/O ao serem executados no Windows™9x/Me simplesmente não é confiável. Isto é especialmente verdadeiro ao se tentar acessar diretamente os discos rígidos. No Win NT/2000/XP os
comando de I/O são apenas uma emulação. Então não confie neles. Embora o exemplo abaixo ainda funcione no Win2000/XP é muito provável que utilize algum código WinAPI para mostrar o que está na área de
relógio do Windows e não diretamente de um chip RTC.

Há muito tempo (quando o DOS era o único sistema operacional para PC), havia dezenas de programas BASIC que usavam comandos de I/O para lidar com tarefas através de portas paralelas e serial (por exemplo,
para alterar a fonte usada por uma impressora ou valores no controle de um modem). Sob o DOS esses recursos ainda podem ser usados para comunicações diretas com teclados ou chips de controle de uma
unidade de disquete, juntamente com muitos outros dispositivos de hardware.
Aqui está um exemplo de como ler horas e minutos do "relógio de tempo real" (RTC) de um computador:

-o 70 04 <-- Verificação das horas.

-i 71
18 <----- 18 horas (ou 6 p.m.)
-o 70 02 <-- Verificação dos minutos.
-i 71
52 <----- 52 minutos

O primeiro espaço não é necessário na maioria das versões do DEBUG; Então você pode tentar sair com apenas "o70" e "i71" em vez disso. Aqui está uma página de exemplos mais complexos sobre os discos
rígidos e os comandos ATA para leitura de informações diretamente de um controlador de disco (somente em inglês).
Volta para TOC

Output: O byte da porta

Veja os comentários no comando Input .

Voltar para TOC

Load: L [endereço] [unidade] [primeiro setor] [número]

ou programa. (Veja o comando N para obter mais informações sobre isso)

Este comando carrega o número selecionado de setores da unidade lógica de qualquer disco sob o controle do MS-DOS ou do Windows na memória. O argumento endereço é o local da memória onde os dados
serão copiados (use apenas 4 dígitos hexadecimais para mantê-los dentro da memória alocada para o DEBUG). O argumento unidade indica o número de mapeado dos drives de disco do computador, como: 0=A:,
1=B:, 2=C:, e assim por diante. O argumento primeiro setor conta de ZERO para o maior setor do volume e finalmente o argumento número especifica em hexadecimal o número total de setores que serão copiados
para a memória (assim, um disquete de 0 a 2,879 setores será definido de: 0 a B3F em hexadecimal).

Os termos 'Volume' ou 'Unidade lógica' acima usados significam que você não pode usar o comando 'L' para carregar ou examinar o MBR ou qualquer outro setor fora dos Volumes Primários ou letras de unidade
lógica atribuídas pelo DOS ou Windows. Por exemplo (no Windows™ 9x/ME) se você usar o comando: L 100 2 0 1 no DEBUG em vez de ver o primeiro setor do disco rígido (o MBR) você verá o primeiro setor do
Boot Record para a unidade lógica C: (ou seja, a primeira partição que pode ser acessada por um sistema operacional compatível com MS-DOS ou Windows). Os seguintes comentários sobre disquetes mostram que
o DEBUG sempre foi muito limitado em comparação com um bom editor de disco ou programa UNIX 'dd'.

O processo efetuado pelo comando de carregamento é útil para examinar Disquetes, mesmo no Windows™ 2000/XP, mas (infelizmente), apenas se o disco puder ser lido pelo MS-DOS ou Windows. Mais uma vez, isso
mostra como o DEBUG é limitado se comparado a qualquer utilitário que possa visualizar os dados brutos de um disco rígido ou disquete. (Para aqueles que desejam examinar o conteúdo real de um disco rígido no
Windows#153; XP, existem editores de disco (página em inglês) gratuitos, como o HxD.)

Ao contrário dos discos rígidos, o primeiro setor de um disquete é um setor de inicialização do sistema operacional. Aqui está o que você pode ver em um setor de disco lógico e alguns dumps de alguns disquetes.

Exemplos:
-l 100 2 0 1 [ unidade de disco rígido C:. ]
-d 100 10f
xxxx:0100 EB 58 90 4D 53 57 49 4E-34 2E 31 00 02 08 20 00 .X.MSWIN4.1... .
-d 280 2ff
xxxx:0280 01 27 0D 0A 49 6E 76 61-6C 69 64 20 73 79 73 74 .'..Invalid syst
xxxx:0290 65 6D 20 64 69 73 6B FF-0D 0A 44 69 73 6B 20 49 em disk...Disk I
xxxx:02A0 2F 4F 20 65 72 72 6F 72-FF 0D 0A 52 65 70 6C 61 /O error...Repla
xxxx:02B0 63 65 20 74 68 65 20 64-69 73 6B 2C 20 61 6E 64 ce the disk, and
xxxx:02C0 20 74 68 65 6E 20 70 72-65 73 73 20 61 6E 79 20 then press any
xxxx:02D0 6B 65 79 0D 0A 00 00 00-49 4F 20 20 20 20 20 20 key.....IO
xxxx:02E0 53 59 53 4D 53 44 4F 53-20 20 20 53 59 53 7E 01 SYSMSDOS SYS~.
xxxx:02F0 00 57 49 4E 42 4F 4F 54-20 53 59 53 00 00 55 AA .WINBOOT SYS..U.
-
-l 100 0 0 1 [ unidade de disquete A:. ]
-d 100 13d
xxxx:0100 EB 3C 90 29 47 38 71 33-49 48 43 00 02 01 01 00 .<.)G8q3IHC.....
xxxx:0110 02 E0 00 40 0B F0 09 00-12 00 02 00 00 00 00 00 ...@............
xxxx:0120 00 00 00 00 00 00 29 40-16 D8 13 4E 4F 20 4E 41 ......)@...NO NA
xxxx:0130 4D 45 20 20 20 20 46 41-54 31 32 20 20 20 ME FAT12
-
-l 100 0 0 1 [ um disquete diferente na unidade A:. ]
-d 100 13d
xxxx:0100 EB 3C 90 53 59 53 4C 49-4E 55 58 00 02 01 01 00 .<.SYSLINUX.....
xxxx:0110 02 E0 00 40 0B F0 09 00-12 00 02 00 00 00 00 00 ...@............
xxxx:0120 00 00 00 00 00 00 29 7E-CF 55 3C 20 20 20 20 20 ......)~.U<
xxxx:0130 20 20 20 20 20 20 46 41-54 31 32 20 20 20 FAT12
-
-d 2d0 2ff
xxxx:02D0 42 3B 16 1A 7C 72 03 40-31 D2 29 F1 EB A7 42 6F B;..|r.@1.)...Bo
xxxx:02E0 6F 74 20 66 61 69 6C 65-64 0D 0A 00 00 00 00 4C ot failed......L
xxxx:02F0 44 4C 49 4E 55 58 20 53-59 53 F4 3C 82 3A 55 AA DLINUX SYS.<.:U.

No disco de inicialização Linux acima (observe a palavra: SYSLINUX) formatado como disquete do MS-DOS e não como um verdadeiro Linux (como ext2 ou ext3). Se tivesse sido formatado este disco com algum
outro tipo de sistema de arquivos ou tivesse um setor de inicialização defeituoso, o MS-DEBUG não seria capaz de lê-lo. Em vez disso, você verá a mensagem de erro "General failure reading drive A /
Abort, Retry, Fail?". E quando você sair dessa mensagem de erro você será saudado com a mesagem de erro "Disk error reading drive A". Isso faz com que o DEBUG seja quase inútil na tentativa de
corrigir um erro no setor de inicialização de um disquete. No entanto, se você mantiver uma cópia binária de um bom setor de inicialização de disquete em algum lugar, você poderia usar DEBUG para substituir o que
está no primeiro setor de disquete defeituoso (veja o comando Write). Mas se você realmente precisa ver o que está em um setor de Boot (ou seja, o que está impedindo o DEBUG de reconhecê-lo como válido),
você precisará usar um editor de disco como o programas Symantec's Norton DiskEdit (apenas no modo de disco Físico).

OBS: Só porque um disquete não pode ser lido pelo DOS ou aberto no DEBUG, NÃO significa necessariamente que esteja com defeito. Pode simplesmente ter sido formatado com um sistema de arquivos que não
pode ser reconhecido (como o ext2 do Linux) e pode facilmente ser utilizado, o que é por si só um bom motivo para que você rotule seus discos. (ATENÇÃO: Nunca inicialize seu sistema com um disco do qual não
se tem certeza que seja 100% compatível, a menos que você desconecte todos os discos rígidos e não tenha nenhuma BIOS gravada em memória flash, pois se houver um vírus de boot ) será uma experiência
eminentemente desagradável.
[ Muitos disquetes têm as letras IHC em seu campo OEM ID. Que tipo de nome OEM é esse? Nenhum. Alguém na Microsoft decidiu que era aí que eles colocariam um novo tipo de identificação pseudo-aleatório para garantir que qualquer
informação armazenada em cache pelo 'Windows 9x' de um disco não fosse misturada com informações de uma unidade de disco diferente se você trocasse os discos na unidade. O string completo começa com cinco bytes hexagonais pseudo-
aleatórios e sempre termina com os caracteres IHC. Todos os disquetes que não estão protegidos contra gravação terão qualquer ID OEM original substituído. Uma vez que é o Windows quem escreve esta sequência de caracteres, ele manterá o
mesmo ID para qualquer leitura ou escrita de discos futuros. No entanto, executar mesmo uma rápida leitura alterará os cinco octetos hexadecimais toda vez.
LEMBRE-SE: se você deseja preservar todo o conteúdo de um disquete importante, você não poderá fazer uma simples leitura em um sistema operacional Windows, a menos que o disco esteja "protegido contra gravação". ]

Volta para TOC

 Move: M intervalo de endereços
Este comando poderia ser chamado COPY (não Move) uma vez que copia todos os bytes dentro do intervalo especificado para um novo endereço.

Exemplos:
1) -m 7c00 7dff 600

Copia os 512 (200h) bytes entre os Offsets 7C00 e 7DFF (inclusive) a partir do Offset 0600 e seguintes.
2) -m 100 2ff 200

Este segundo exemplo mostra que é muito fácil substituir grande parte da mesma área de origem da qual você está copiando ao usar o comando Move. No entanto, o DEBUG deve armazenar todos os bytes de
origem na memória antes de os escrever, caso contrário, este exemplo causaria um problema ao substituir uma área da qual ainda não havia copiado os dados, se copiado apenas um byte de cada vez dessa área de
origem. O exemplo acima copia todos os 512 bytes de deslocamento 100h até 2FFh (inclusive) para o Offsets 0200h e os seguintes substituindo os últimos 256 (2FF-200 + 1 hex) bytes da fonte nesta ação. Isso
também é verdadeiro no modo real DOS de 16 bits.

Obs: Se o comando Move produzir uma situação em que o offset FFFFh já tenha sido escrito e há ainda mais dados para escrever você experimentará resultados inesperados. Lembre-se que o DEBUG é
tecnicamente atribuído apenas a um segmento de 64 KiB. Assim, os dados serão envolvidos no entorno do início do segmento, possivelmente substituindo alguns dos bytes de origem que você tenha copiado. Mas
outros sintomas estranhos podem ocorrer uma vez que a primeira área a ser substituída após o envolvimento (00h por meio de FFh) por vezes é usado pelo DEBUG para acompanhar ações de si mesmo. Então, faça
as contas sempre que copiar bytes para uma localização mais alta na memória no sentido de ter certeza de que não ficará sem espaço de trabalho no final do segmento.

Copiar bytes para uma localização mais baixa no segmento é bastante simples, pois o DEBUG pode copiar apenas um byte de cada vez nessa direção e nunca substituir um byte de origem antes copiado.
Volta para TOC

Name: N [caminho] [lista de argumentos]

Este comando pode ser usado para carregar arquivos na memória do DEBUG após ter iniciado o programa. No entanto, a principal função do comando é criar um novo arquivo sob o controle do Sistema
Operacional ao qual o DEBUG pode ESCREVER dados.
Normalmente, para "depurar" um arquivo, inicia-se o DEBUG com um comando como este: C:\WINDOWS>debug test.com . Mas também é possível carregar um arquivo na Memória do DEBUG de dentro do
próprio DEBUG, usando o comando 'N' e em seguida o usando o comando 'L' (with sem parâmetros) semelhante a:
-n c:\temp\test.com
-l
Que irá carregar o arquivo test.com na memória do DEBUG começando no local CS:0100 (você não pode especificar qualquer outro local ao usar o comando L como este.).

O comando 'N' facilita a salva guarda de dados ou mesmo um programa Assembly criado com o DEBUG para um arquivo em seu disco rígido. Por exemplo, os comandos a seguir (mostrados em formato negrito na
cor azul) criarão um arquivo de 68 bytes chamado DOSWINOK.COM na pasta C:\TEMP, mesmo executando o DEBUG em uma janela DOS. Os nomes dos arquivos, no entanto, estão limitados aos oito caracteres
mais três caracteres para a extensão (geralmente chamado de nome de arquivo 8.3):

-n c:\temp\doswinok.com
-a 100
cs:0100 jmp 138
cs:0102 db 0d,0a,"It's OK to run this "
cs:0118 db "program under DOS or Windows!"
cs:0135 db 0d,0a,24
cs:0138 mov dx,102
cs:013B mov ah,9
cs:013D int 21
cs:013F mov ax,4c01
cs:0142 int 21
cs:0144 [Acione ENTER aqui.]
-rcx
CX 0000
:44
-w
Writing 00044 bytes [ 68 bytes in decimal ]
-q

Como chegamos ao valor de "44" para colocar no registro CX para escrever esses bytes para nosso novo arquivo? Bem, se você montar um programa em DEBUG usando o comando Assemble tal como feito acima,
você pode subtrair a localização do início da programação a partir da localização na linha em que você parou o assembly acionando a tecla ENTER. Essa ação poupa um pouco de trabalho uma vez que não é
necessário lembrar quanto deve ser subtraído da primeira localização do byte (da primeira instrução) em relação a última localização do byte (da última instrução), sendo ambos os bytes inclusivos, deve-se adicionar
um 1 ao resultado para obter o número total de bytes do seu programa ou então colocar isso em termos dos dígitos envolvidos: (144h - 100h ) = (143h - 100h + 1) = 44h = 68 decimal.

OBS: Ao contrário de outros programas listados nesta página, este último usou a função 4Ch em vez da Função 00 da Interrupção 21h para encerrar sua execução. Esta é a função de rescisão preferida para a maioria
dos programas do DOS, pois pode enviar um "Código de retorno" (um valor ERRORLEVEL, do que está no registro AL), e também fechará todos os arquivos abertos e liberará toda a memória pertencente ao
processo. No entanto, quando você usa essa função para encerrar um programa ele tende a encerrar o DEBUG em si, sendo este o motivo pelo qual raramente a usamos.

Tarefa de casa: siga os passos indicados acima para o Assemble e salve o programa no DEBUG, então use o DEBUG para depurar o programa. Use o comando P(roceed) para percorrer a maioria das instruções. Isso
impedirá que se entre acidentalmente em uma instrução INT(errupt). Se você usar o comando T(race) para executar um INT acabará dentro de um emaranhado de rotinas da BIOS que muitas vezes falha no DEBUG.
Volta para TOC

Register: R [registrador]
Ao entrar com o comando ' r ' você terá acesso a todos os conteúdos dos registradores 8086 e as instruções que são indicadas pelo registrador IP (Assembly Language). Por exemplo, se você iniciar o DEBUG e m
uma janela Windows 95B DOS-box com a linha de comando:
>debug c:\windows\command\choice.com
e então escrever o comando ' r ' no prompt DEBUG será exibido algo semelhante a:
AX=0000 BX=0000 CX=1437 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=0ED8 ES=0ED8 SS=0ED8 CS=0ED8 IP=0100 NV UP EI PL NZ NA PO NC
0ED8:0100 E90E01 JMP 0211

Para obter uma explicação dos nomes dos registros (AX, BX, CX, etc. e os símbolos de flags: NV UP EI PL NZ NA PO NC), consulte o Apêndice: The 8086 CPU Registers (somente em inglês). A última linha mostra a
próxima instrução da CPU (na verdade o primeiro neste caso) a ser executada, começa na localização da memória 100 h (valor do deslocamento) no segmento 0ED8 h (0ED8: 0100) e os bytes hexadecimais E90E01
representam o código da máquina (op code) binário real da instrução da CPU (JMP 0211 em Assembly) que será executado pelo DEBUG se você inserir um comando Trace (t) ou Proceed (p).

Se você inserir o ' r ' seguido da abreviatura de um registrador 8086, como: 'rcx', então o DEBUG exibirá apenas o conteúdo desse registrador seguido de uma linha com um símbolo de dois pontos (:) no qual você
pode inserir um valor hexadecimal para alterar o conteúdo desse registrador. Se você simplesmente pressionar a tecla ENTER, o conteúdo permanece o mesmo. Por exemplo:

-rcx
CX 0100
:273
-

Significa que o comando R (registrador) foi usado para alterar o conteúdo do registrador CX de 0100 para 0273. O comando rcx também pode ser usado novamente para verificar se a mudança realmente ocorreu.

OBS: TO comando o comando do registrador só opera com registros de valores que sejam de 16 bits, incluindo os registradores de flags (bandeiras). Se informado o nome do registrador de 8 bits ou um valor
inválido será apresentada a mensagem: br Error.

Informando a letra f (para Flags) após o comando r: rf, fará com que o DEBUG exiba todos os bits dos registradores de FLAGs e o símbolo do 'prompt' na mesma linha. Este prompt permite que seja alterado todos,
ou nenhum dos bits das bandeiras individuais. Por exemplo, veja como exibir os sinalizadores e alterar apenas os bits da bandeira Zero e Carry do valor binário zero (0 bit) para o valor binário um (1 bit) e verificá-los
sem fazer mais alterações:

-rf
NV UP EI PL NZ NA PO NC -zr cy
-rf
NV UP EI PL ZR NA PO CY -
-
Como mostrado, os sinalizadores Zero e Carry foram alterados de NZ e NC (ambos desmarcados) para ZR e CY (ambos definidos). Veja no apêndice: The FLAGS Register (somente em inglês) para obter maiores
explicações de todas abreviaturas do registradores de flags.

A alteração de valores dos registradores de flags pode ser executado com ou sem espaços após o 'prompt' (como: -zrupcy).

A tentativa de inserir uma abreviatura incorreta para um valor de sinalizador (mesmo com um ou mais nomes corretos) resulta em: bf Error .
A tentativa de inserir as abreviaturas para a limpeza e a configuração do mesmo sinalizador, no mesmo prompt, causará a apresentação da mensagem: df Error.
Volta para TOC

Trace: T [=endereço] [valor]

O comando T é usado para rastrear (percorrer) as instruções da CPU uma de cada vez. Se você inserir o comando T por si só, ele normalmente passará por uma única instrução que começa no local especificado
pelos registradores CS: e IP, após sua ação este interrompe a execução do programa e mostra todos os registradores da CPU mais a indicação da próxima instrução a ser executada. Este é o modo 'padrão' do
comando TRACE. No entanto, caso haja o desejo de fazer com que o DEBUG rastreie e execute sete instruções iniciadas no endereço CS: 0205, entre:

-t =205 7
Lembre-se de que o valor do número de instruções para executar deve ser fornecido em hexadecimal, assim como todos os outros valores usados com o DEUBG. (Uma vez que o comando T usa o "modo de
rastreamento de hardware" da CPU, é possível passar pelas instruções em um chip ROM - Read Only Memory ou entrar no código BIOS que foi adicionado em partes somente de memória). OBS: Se você ficar dentro
de uma longa instrução de LOOP ou REPeat insira um comando P (Proceed) para completar a operação e passar para a próxima instrução..

Volta para TOC

Proceed: P [=endereço] [número]

O comando P age exatamente como o comando T (Trace) para a maioria das instruções executadas. O comando P executa imediatamente todas as instruções (em vez de passar por cada uma) dentro de qualquer
sub-rotina CALL, LOOP, REP com instruções de cadeias ou qualquer instrução INT. Você ainda pode entrar em um INT ou executar todo o código contido em uma sub-rotina se precisar, mas com o comando Proceed
(P) isto não é necessário.
Isso significa que o comando Proceed será provavelmente o comando escolhido para a execução da maioria das tarefas de depuração e o comando Trace será usado apenas para passar por uma sub-rotina
desconhecida ou então verificar a lógica das primeiras iterações de longas instruções de cadeia REP ou LOOPs, sendo obrigatório quando se trata de Interrupções.
Volta para TOC

Escreva:
W [endereço] [unidade] [setor] [número]

ATENÇÃO
NÃO use o comando W - write no DEBUG. Este comando pode ser usado efetivamente para criar novos arquivos no disco rígido, mas somente se você souber usá-lo corretamente. O uso adequado deste recurso é
RECONHECIDO quando se faz a escrita direta de um setor em um disco rígido.

A tentativa de escrever diretamente dados em um disco rígido usando números de setor provavelmente resultará na perda de dados ou mesmo obter um
sistema sem inicialização! (Embora o Windows XP e outras versões mais recentes evitem que ocorra a escrita direta de setores em disco rígido. Esta possibilidade é permitida para mídias de unidade de
disquete identificadas pelas letras A: ou B:)

O comando WRITE (W) é usado frequentemente para salvar um programa em seu disco rígido dentro do DEBUG. Mas a única maneira segura de fazê-lo, especialmente no Windows, é permitindo que o sistema
operacional determine onde criar fisicamente esse arquivo no disco. Isso é feito usando primeiro o comando Name (N) para configurar um caminho opcional e nome de arquivo arquivo para criar um novo arquivo (ou
substituir o arquivo que já existe). O DEBUG começará automaticamente a salvar o programa ou os bytes de dados do Offset 0100 do segmento de 64 KiB no sistema operacional alocado para ele. Um único
requisito a ser considerado é a definição do tamanho do arquivo que se deseja escrever colocando o número total de bytes nos registrados combinados BX e CX * antes de executar o comando WRITE. O comando
Register é usado para alterar o valor no registrador CX no exemplo a seguir do nosso programa MyMBR Batch/Debug Script Program.

EXEMPLO:
Depois de criar e executar um pequeno programa dentro do DEBUG que copia o Master Boot Record (MBR) do Offset 0000h até 01FFh salve o MBR em um arquivo no disco rígido:
-n mymbr.bin
-rcx
CX 0001
:200
-w 0
Writing 00200 bytes [ 512 bytes em decimal ]
-

O registrador BX já havia sido ajustado para zero por uma instrução anterior, então o registrador CX foi simplesmente configurado para 200 e o comando WRITE foi executado com endereço 0 (se nenhum endereço
for usado o comando Write começará a salvar bytes no Offset 100).

O comando WRITE pode ser usado de forma relativamente segura com disquetes. Por exemplo, você pode usar o comando Load (L):
l 7c00 0 0 1
para carregar o primeiro setor de um disquete do MS-DOS ou do Windows na memória do DEBUG no local 7C00 mude algum código e/ou mensagem (se você souber como fazer) e use o comando 'W':
w 7c00 0 0 1
para escrever as alterações de volta no primeiro setor do disquete.

___________________
*Embora os registradores BX e CX sejam frequentemente referenciados em livros de linguagem Assembly como BX:CX quando discutidos para a ação de gravação estes registradores não estão sendo usados como Segment:Offset
(Segmento:Deslocamento) neste caso. Esses registradores são uma verdadeira combinação de bytes superiores e inferiores que formam um "double word" para um total, em tese, de cerca de 4 GB (FFFF FFFFh = 4,294,967,295 bytes) que pode
ser gravado em um arquivo. Se é ou não verdade para todas as versões do DEBUG, no DOS 7.1 conseguimos carregar arquivos de imagens de várias centenas de KiB e escrever o arquivo completo para uma nova localização.
Por exemplo, se você carregar um arquivo de imagem de 360 KiB no DEBUG em um prompt DOS poderá verificar os registradores BX com valor 0005 e o registrador CX com valor A000. O principal problema aqui é o fato
do DEBUG é usar MEMÓRIA CONVENCIONAL, sentão tentar carregar um arquivo maior que cerca de 400 KiB provocará um erro "Memória insuficiente".
[ Clique aqui para voltar ao texto acima ]

Volta para TOC

NOTA:
Você pode ter acessado esta página a partir de: The Windows™ DOS Stub Program. E há mais exemplos de outros comandos nestas páginas de x86 tutorial: FIRE.com: Some MS-DEBUG Tricks e The EICAR Standard AV
Test Program.
As páginas externas desta nota e os demais links indicados para consulta além do que é apresentado na primeira e segunda páginas deste tutorial estão escritas em inglês. Isto decorre do pedido de autorização ao senhor
Daniel B. Sedory referenciar apenas o tutorial do programa DEBUG.

AUTORIZAÇÃO PEDIDA (30/07/2017)

Hello, Mr. Daniel B. Sedory.

My name is Augusto Manzano. I teach in the area of computer science in Brazil. Work for the Brazilian government at the Federal Institute of Education, Science and Technology (IFSP).

I hereby request if possible permission to translate the text of the site: http://thestarman.pcministry.com/asm/debug/debug.htm into the Portuguese language in order to make the information available to the students and the
Brazilian public..

My proposal is to maintain the same structure and layout of your site.

Kind regards.

AUTORIZAÇÃO CONCEDIDA
Hello Augusto,

Provided full credit and Copyright notices are not removed, you may also add that you translated the page into your language.
Please provide a link to the web site page when you have completed translation of my DEBUG page.

Sincerely,
Daniel B. Sedory

Atualizado: 28 de setembro de 2007. (28.09.2007)

Atualização anterior: 23 de agosto de 2010. (23.08.2010)
Última atualização: 19 de setembro de 19, 2010. (19.09.2010)

Um guia para o DEBUG (Página Um)

The Starman's Realm Assembly Page