<FabioOlive> AlissonB_: :)

<FabioOlive> AlissonB: :)

<AlissonB> to baixando o dosbox aqui

<AlissonB> instalando

<FabioOlive> blz

<FabioOlive> hehe

<AlissonB> pronto FabioOlive

<FabioOlive> AlissonB: legal, executa o dosbox e vê se a configuração deu certo

<AlissonB> acho que deu

<AlissonB> como faço pra ter certeza?

<FabioOlive> ficou no C:> _

<FabioOlive> ?

<AlissonB> sim

<FabioOlive> beleza, roda aí DIR ou algo assim :)

<AlissonB> yeah

<AlissonB> funfando

<FabioOlive> AlissonB: legal

<FabioOlive> AlissonB: roda o debug :)

<AlissonB> running

<FabioOlive> AlissonB: já te passo um teste :)

<FabioOlive> no debug, só pra testar

<FabioOlive> digita isso:

<FabioOlive> e b800:0000 41 03 4c 07 49 03 53 07 53 03 4f 07 4e 03 20 07

<FabioOlive> note que provavelmente o teclado vai estar mapeado errado :)

<FabioOlive> o : vai estar no Ç :)

<FabioOlive> pra corrigir isso, rode “keyb br” no prompt do dos :)

<FabioOlive> ah, pra sair do debug digita q e enter :)

<AlissonB> esse comando não deu nada FabioOlive

<FabioOlive> qual comando?

<AlissonB> e b800…

<FabioOlive> tinha que ter escrito ALISSON na tela com letras de cores diferentes

<FabioOlive> ahh eu me enganei acho

<FabioOlive> no endereço

<FabioOlive> e b800:00a0 41 03 4c 07 49 03 53 07 53 03 4f 07 4e 03 20 07

<AlissonB> agora sim

<AlissonB> :D

<FabioOlive> hehe

<FabioOlive> ok

<FabioOlive> vamos pensar em algo mais elaborado

<FabioOlive> esse exemplinho não é um programa, é só usar o debug pra escrever direto na memória de vídeo

<Marlon_> Que loucura eh esta fabio?

<FabioOlive> AlissonB: saia do debug com q

<FabioOlive> entra no diretório ASM

<AlissonB> ok

<FabioOlive> vamos criar um programinha em assembly e montar ele com o NASM

<FabioOlive> Marlon_: o AlissonB está começando a estudar assembly x86 16bits

<FabioOlive> usando o DOSBox como máquina de testes (virtual, mas é legal mesmo assim)

<Marlon_> Bah muito legal (:

<FabioOlive> AlissonB: o bom de usar DOSBox é que a partir de agora, qualquer arquivo que tu criar naquele diretório dosc no teu ~ vai aparecer no DOS, então posso te mandar uns programinhas por email e tu grava ali :)

<FabioOlive> máquina.virtual++

<mibotz> máquina.virtual tem 1 pontos de karma

<AlissonB> legal

<FabioOlive> em comparação, meu laptop que tem FreeDOS instalado tem uns programinhas em asm lá que não tenho como tirar dali. o laptop não tem disquete, claro, e o DOS não tem suporte a muitas outras coisas :) pendrive? esquece!

<FabioOlive> haha

<AlissonB> bah, só copiando o código manualmente

<AlissonB> hehe

<FabioOlive> sim, trash né :)

<AlissonB> como diria o eliezerb: doidera low leve

<AlissonB> level*

<AlissonB> huauha

<FabioOlive> hahah pensei num programinha divertido agora

<FabioOlive> ainda usando a memória de vídeo do modo texto

<FabioOlive> pois é uma maneira divertida e imediata de ver que o programa funcionou

<FabioOlive> vamos fazer um programinha que vasculha a memória de vídeo e inverte maiúsculas e minúsculas de todos os caracteres

<eliezerb> AlissonB: low

<FabioOlive> … que estiverem na tela

<eliezerb> FabioOlive: Eu vou ir pro FLISOL em Chapecó

<FabioOlive> boa eliezerb ! vai ser legal

<eliezerb> Em Joaçaba temos uns problemas com Proxy na rede

<FabioOlive> sem flisol em joaçaba então, pelo menos esse ano :)

<eliezerb> E uma burocracia danada com espaço

<eliezerb> Ano passado fomos barrados nessa questão

<AlissonB> eliezerb, vamos ter uma sala de hardware livre e uma de software livre

<AlissonB> prepara alguma coisa pra aprensentar

<eliezerb> Firefox OS?

<eliezerb> Uma oficina de uma hora?!

<eliezerb> OpenWeb?

<AlissonB> acho que Firefox OS é legal

<AlissonB> já manja bem?

<eliezerb> Até lá já tivemos alguns encontros aqui em Joaçaba :) E é moleza FFOS

<eliezerb> Em uma oficina de 1 hora da quase pra fazer um aplicativo de média complexidade (se você manjar dos paranaues web)

<eliezerb> Submeter no MarketPlace

<eliezerb> E se pá, ter uns 300 downloads

* fba saiu (Read error: Connection reset by peer)

<FabioOlive> hahaha funcionou o INVERTE.COM

<FabioOlive> :D

<AlissonB> a minha pergunta é: vc está preparado para apresentar isso eliezerb?

<FabioOlive> AlissonB: vou te mandar o programa por email rapidinho

<FabioOlive> ou melhor

<AlissonB> blz FabioOlive :D

<eliezerb> AlissonB: Posso te dar essa resposta daqui 15 dias?

<FabioOlive> cat: src/dosbox/asm/inverte.asm: Arquivo ou diretório não encontrado

<FabioOlive> oops

<FabioOlive> peraí

<AlissonB> blz eliezerb :)

<AlissonB> quanto antes, melhor

<eliezerb> AlissonB: Vou fazer essa mesma oficina com a galerinha da paçoca aqui do curso

<AlissonB> quero ir fechando as atividades

<FabioOlive> section .text

<FabioOlive> org 0x0100

<FabioOlive> start:

<FabioOlive> mov ax, 0xb800

<FabioOlive> mov es, ax

<FabioOlive> mov di, 0

<FabioOlive> volta: mov al, [es:di]

<FabioOlive> xor al, 0x20

<FabioOlive> mov [es:di], al

<FabioOlive> add di, 2

<FabioOlive> cmp di, 4000

<FabioOlive> jnz volta

<FabioOlive> ret

<FabioOlive>

<FabioOlive> AlissonB: roda aí “edit inverte.asm” e digita esse programinha

<AlissonB> dá uma explicada nele enquanto em digito :D

* fba (~fba@177.183.223.164) entrou em #OeSC-Livre

<FabioOlive> AlissonB: depois “assembla” ele com: nasm -f bin -o inverte.com inverte.asm

<FabioOlive> eu tinha explicado que no modo “PC XT” em que o DOS funciona, o segmento de memória B800:0000 contém a memória de vídeo em modo texto <eliezerb> AlissonB: Mas se tu achar alguém pra falar de algo massa, coloca! Não espera por mim não :) É muito bom assistir a galera

<FabioOlive> esse programinha basicamente faz um loop, olhando cada um dos bytes (pulando de dois em dois) de 0 a 4000 a partir desse endereço <FabioOlive> ele pega o byte e inverte o bit 5 (operação xor al, 0x20), e escreve o byte de volta no mesmo lugar

<FabioOlive> a diferença binária entre caracteres maiúsculos e minúsculos sempre está no bit 5. tipo 'A' é 0100 0001, e 'a' é 0110 0001.

<FabioOlive> só muda o bit 0010 0000

<FabioOlive> se invertermos esse bit de uma sequência de carateres ASCII, vamos na verdade estar invertendo entre maiúsculas e minúsculas

<FabioOlive> 0x20 (20 em hexa) equivale a 0010 0000

<FabioOlive> lembra que na memória de vídeo em modo texto, cada dois bytes definem um caracter na tela

<FabioOlive> primeiro o código ASCII dele, depois os “atributos” (cores, se está piscando, etc)

<FabioOlive> por isso que o programinha vai pulando de dois em dois

<FabioOlive> assim pega só o código ascii de cada caractere e muda

<FabioOlive> eu conto até 4000, de 2 em 2, porque a tela em modo texto no DOS tem 80×25 == 2000 caracteres. 2000 caracteres com 2 bytes cada um dá 4000 bytes :)

<FabioOlive> AlissonB: eu uso o registrador DI como um “ponteiro” na memória de vídeo, é esse registrador que diz em qual endereço de caractere o loop está operando

<FabioOlive> e uso o registrador AL pra armazenar o byte lido do endereço de memória apontado por ES:DI. ES é um registrador de segmento que eu apontei pra memória de vídeo lá no início

<AlissonB> esses nomes de registradores foi vc que deu ou são esses mesmo?

<Marlon_> Alienígena essa coisa em assembly o.0

<FabioOlive> AlissonB: são assim mesmo, são os registradores padrão de um processador x86

<FabioOlive> AlissonB: depois que tu digitar esse programinha vamos explicar um pouco mais :)

<FabioOlive> desculpa o delay, o sinal da wifi tava fraquejando aqui :)

<FabioOlive> AlissonB: avisa quando tu conseguir terminar de digitar e compilar esse programinha :)

<AlissonB> já fiz FabioOlive, mas deu erro

<AlissonB> daí como o cursor tinha travado na tela do dosbox

<FabioOlive> legal, corrige o erro então :)

<AlissonB> tive que dar exit pra voltar pra cá

<FabioOlive> :)

* Marlon_ saiu (Quit: Saindo)

<FabioOlive> aqui tá funcionando o programinha :) vê se copiou algo errado

<FabioOlive> AlissonB: se tu clicar com o mouse na janela do dosbox, ele vai capturar o mouse pra ele, e não lembro como é que libera

<AlissonB> bom, agora compilou

<FabioOlive> se apertar Alt+Enter pra ficar em tela cheia e depois apertar de novo pra voltar pro modo janela, ele libera o mouse

<FabioOlive> AlissonB: ok, agora roda CLS, depois DIR, e depois roda INVERTE

<FabioOlive> :)

<AlissonB> ficou um monte de símbolos esquisitos

<AlissonB> hehe

<FabioOlive> hehe sim onde tiver números e outros símbolos vai ficar estranho

<FabioOlive> se rodares INVERTE de novo volta ao normal

<AlissonB> humm

<AlissonB> saquei

<FabioOlive> na época do DOS tinha uns vírus que manipulavam a memória de vídeo, fazendo os caracteres “caírem” pela tela até se amontoarem nas linhas de baixo hehehe

<FabioOlive> o “cascata”

<AlissonB> huauhahu, nossa

<FabioOlive> a gente podia fazer um programa que imita o vírus cookie, que basicamente mostra um pacman na tela que sai comendo os caracteres heheheh

<FabioOlive> se não tivesse nada na tela pra comer ele avisava que ia comer o disco

<FabioOlive> aí a pessoa tinha que ficar digitando coisas

<FabioOlive> pra ele comer

<FabioOlive> hahahaha

<FabioOlive> AlissonB: acho que o DOSBox vai ser uma maneira divertida de aprender arquitetura de computadores, e principalmente já usando como base uma arquitetura útil nos dias de hoje, que é a x86

<FabioOlive> o modo 32 ou 64 bits basicamente é a mesma coisa com registradores maiores hehehe

<AlissonB> essa era a minha dúvida

<AlissonB> qual a diferença em termos práticos?

<FabioOlive> só que obviamente sistemas operacionais como o linux usam um modelo de memória diferente, então não seria possível brincar assim

<FabioOlive> em termos práticos, a diferença pro assembly de um DOS pro Linux é o espaço de endereçamento, que no caso do Linux é muito maior, a proteção de memória, e a maneira de chamar os serviços do sistema operacional

<AlissonB> e o que muda de x86 pra x64?

<FabioOlive> basicamente o espaço de endereçamento, e em 64 bits tem mais alguns registradores na CPU, pra melhorar o desempenho do código

<FabioOlive> AlissonB: sabe esses AX, DI, ES, AL, e tal que usamos ali em cima?

<AlissonB> aham

<FabioOlive> esses são os registadores da CPU

<FabioOlive> cada um deles é como se fosse uma variável, ou um lugarzinho pra guardar um número

<FabioOlive> as operações do processador funcionam em cima desses registradores

<FabioOlive> e tem instruções pra ler dados da memória pra dentro dos registradores, e pra escrever registradores de volta na memória

<FabioOlive> alguns registradores tem funções especiais, como o IP, que é o Instruction Pointer

<FabioOlive> basicamente ele indica o endereço da memória onde o processador vai buscar a próxima instrução pra executar

<FabioOlive> só o que o processador faz é isso :)

<AlissonB> hummm

<AlissonB> isso sim é low level

<FabioOlive> quando tu liga o computador, todos os registradores da CPU estão zerados

<FabioOlive> e aí o processador, naturalmente, busca a instrução que estiver no endereço 0 de memória (porque IP tem o valor 0 quando liga) e executa ela

<FabioOlive> depois incrementa o IP e executa a próxima

<FabioOlive> depois incrementa o IP e executa a próxima

<FabioOlive> depois incrementa o IP e executa a próxima

<FabioOlive> depois incrementa o IP e executa a próxima

<FabioOlive> depois incrementa o IP e executa a próxima

<FabioOlive> depois incrementa o IP e executa a próxima

<FabioOlive> depois incrementa o IP e executa a próxima

<FabioOlive> depois incrementa o IP e executa a próxima

<FabioOlive> …

<FabioOlive> pra sempre :)

<FabioOlive> claro que algumas instruções alteram esse fluxo

<FabioOlive> então programas em assembly basicamente consistem em carregar valores em registradores, realizar operações neles, escrever de volta na memória e por aí vai

<FabioOlive> por exemplo

<FabioOlive> pra multiplicar dois números

<FabioOlive> tu usa uma instrução pra carregar o primeiro número em um registrador (AX, por exemplo)

<FabioOlive> depois outra instrução pra multiplicar o registrador AX pelo outro número

<FabioOlive> e depois provavelmente vais escrever o resultado (que está em AX) em algum outro lugar

<FabioOlive> é ridiculamente simples assim :)

<AlissonB> pois é, acho que o pessoal se assusta com assembly porque não sabe essas coisas

<AlissonB> mas seria legal ter uma tabela das funções de cada registrador

<FabioOlive> e se parares pra pensar, todos os programas são assim, pois só o que o computador executa é linguagem de máquina (que corresponde 1 pra 1 com assembly)

<AlissonB> tem isso por aí?

<FabioOlive> claro

<FabioOlive> tem milhares de páginas de manuais da Intel pra ler sobre isso :)

<AlissonB> a Intel fez manual pra x64 também?

<FabioOlive> AlissonB: quando tu rodas o programa debug, ele funciona como se fosse um console do processador

<FabioOlive> sim, os manuais da Intel incluem tanto 32 quanto 64 bits. a diferença não é muito grande entre eles, então 99% do assembly é o mesmo.

<FabioOlive> AlissonB: roda o debug aí

<FabioOlive> e no prompt digita r e enter

<FabioOlive> ele vai te mostrar o conteúdo dos registradores

<FabioOlive> quase tudo zerado :)

<FabioOlive> o debug funciona como se ele tivesse “congelado” a máquina na hora que ligou

<FabioOlive> e permite examinar o conteúdo da memória e dos registradores

* ubuntero (~ivan@177-137-54-145.cte.net.br) entrou em #OeSC-Livre

<FabioOlive> aí podes inserir código em assembly direto em pontos da memória RAM e mandar ele executar :)

<FabioOlive> é como se tu estivesse controlando o processador manualmente, saca?

<AlissonB> perfeitamente!

<FabioOlive> a barbada é que existem regiões de memóra que são mágicas :)

<AlissonB> vi os registradores zerados agora

<AlissonB> bacana

<FabioOlive> tu já viu a região da memória de vídeo, por exemplo

<FabioOlive> tudo o que tu escrever lá, aparece na tela

<FabioOlive> o mesmo se dá com modos gráficos, só que aí cada ponto na tela vai ter uma cor, que é representado por um ou mais bytes na memória de vídeo

<FabioOlive> que nesse caso fica no segmento A000:0000

<FabioOlive> se tu fizer um programa que muda o modo de vídeo pro modo gráfico e sair escrevendo na RAM a partir do endereço A000:0000, vão aparecer pontos coloridos na tela :)

<AlissonB> não tem como fazer isso no linux, por exemplo?

<FabioOlive> AlissonB: e aí também tem regiões de memória em que aparece o teclado, ou uma placa de rede, ou o controlador de disco, etc

<AlissonB> o segmento nem vai ser o A000 daí?

<FabioOlive> não, o Linux não vai deixar tu fazer isso :)

<FabioOlive> pois é, aí nem sei onde vai ficar hehehe :)

<FabioOlive> AlissonB: note que no tempo do DOS a gente usava modo gráfico 320×200 pontos com 256 cores :)

<FabioOlive> era um byte por pixel, hehehe

<FabioOlive> 64000 bytes pra descrever a tela gráfica :)

<FabioOlive> old school total :)

<AlissonB> pois é, pra gente é mais difícil absorver essa época

<AlissonB> nasci na época errada

<AlissonB> huahua

<FabioOlive> hahaha hoje em dia é mais difícil entender essas coisas

<AlissonB> agora tem que correr atrás da máquina pra aprender :)

<FabioOlive> tipo, uma tela full hd com 32 bits de cor (24 bits de cor mais 8 bits de canal alpha pra transparência) dá vários megabytes, que é mais RAM que o DOS sequer acessava :)

<FabioOlive> AlissonB: pra operar o hardware, basicamente precisamos saber em que endereço ele está, e que informação escrever onde.

<FabioOlive> isso se consegue com a documentação dos chips fornecidas pelo fabricante

<AlissonB> hummm

<FabioOlive> por exemplo, vamos imaginar que tem um chip controlador de disco no endereço C000

<FabioOlive> e na documentação diz que o primeiro byte serve pra indicar qual setor do disco é pra ser lido ou escrito, o segundo byte é pra mandar o comando de ler ou escrever o setor, e um terceiro byte serve de “status” pra indicar se uma operação está em andamento

<FabioOlive> e digamos que no endereço C100 até C300 (512 bytes) é a área de memória que o controlador usa pra escrever um setor no disco ou ler

<FabioOlive> então se quisermos ler o setor 15 do disco

<AlissonB> porque c100 até c300 são 512 bytes?

<FabioOlive> fazemos um programinha assembly que escreve 15 no endereço C000, digamos que 01 pra operação de leitura no endereço C001, e então o programinha fica em loop lendo o byte no endereço C002 até que ele seja zero. quando ele tiver o valor zero, indica que o controlador acabou a operação e o setor 15 foi lido e seu conteúdo está no endereço C100 a C300

<FabioOlive> é assim que se opera o hardware

<FabioOlive> :

<FabioOlive> :)

<FabioOlive> claro que estou simplificando um pouco, e criando exemplos fictícios de endereços e tal

<FabioOlive> mas a operação básica é assim

<AlissonB> mas isso no dia a dia é complexo de implementar, ou só precisa de prática (como qualquer outra coisa)?

<FabioOlive> escreve um valor mágico em um certo lugar, espera que outro valor mágico apareça em outro lugar, e aí o hardware fez alguma coisa que o valor mágico que foi escrito indicou

<FabioOlive> AlissonB: olha, hoje em dia escrever drivers pra dispositivos é bem complexo

<FabioOlive> o hardware anda bem complexo hoje em dia

<FabioOlive> AlissonB: MAS a barbada é que não precisas fazer isso, já que tens um sistema operacional pra usar :)

<FabioOlive> o Sistema Operacional é exatamente o programa que implementa todas essas funções e apresenta uma interface simples pros programas :)

<FabioOlive> mas é interessante saber que é esse tipo de coisa que o Sistema Operacional faz :)

<FabioOlive> AlissonB: sobre 512 bytes entre c100 e c300, abre um shell aí e digita: echo $¹⁾

<FabioOlive> :)

<FabioOlive> o prefixo 0x indica hexadecimal, e 0x100 é 256 em decimal :) entre 0xc100 e 0xc300 tem 0x200 bytes, que é 512 bytes em decimal :)

<AlissonB> hum, show

<AlissonB> é bastante coisa pra absorver

<AlissonB> hehe

<FabioOlive> AlissonB: estás aos poucos entendendo? :)

<FabioOlive> é bastante coisa, ainda mais de forma remota assim hehehe

<AlissonB> aham, eu costumo aprender por meio de repetição

<FabioOlive> :)

<FabioOlive> AlissonB: como eu disse, o processador só sabe ir buscando instruções da memória e executando

<FabioOlive> isso significa que, quando tu liga o computador e toda a RAM está zerada, e todos os registradores estão zerados, alguma coisa tem que existir na memória que faça algo de útil

<FabioOlive> a RAM está zerada, mas não é só a RAM que tem ali né

<FabioOlive> AlissonB: quando a gente liga o computador, qual é a primeira coisa que executa?

<FabioOlive> começa com B :)

<FabioOlive> e termina com IOS :)

<FabioOlive> bootloader vem depois

<FabioOlive> o BIOS é quem carrega o bootloader

<AlissonB> o pessoal confunde muito bios com cmos

<eliezerb> E esse não tem nada de ignorante

<eliezerb> rsrsrs

<FabioOlive> o BIOS vem gravado de fábrica, é uma memória não volátil, ou seja, não se perde quando desliga a energia

<FabioOlive> antigamente era uma ROM mesmo, hoje em dia é uma Flash que pode ser regravada

<FabioOlive> AlissonB: “CMOS” é a memóriazinha RAM não volátil que tem no circuitinho de “relógio de tempo real” pro computador saber as horas quando boota :)

<FabioOlive> CMOS na verdade é Complementary Metal-Oxide Semiconductor, que é o nome do processo de fabricação daquela memóriazinha

<FabioOlive> mas aí imperou o princípio Gilette, e ninguém mais chamou de lâmina de barbear, saca?

<FabioOlive> a memória CMOS virou “a CMOS” :)

<FabioOlive> bom

<FabioOlive> eu tava falando do BIOS

<FabioOlive> AlissonB: tu já sabes agora que quando o processador liga ele sai executando instruções da memória

<FabioOlive> mas que a RAM está zerada quando liga, então não tem nada de útil pra executar lá

<FabioOlive> então a barbada é que o projeto da placa mãe tem que mapear no endereço inicial do processador exatamente a memória que contém o BIOS, e assim quando liga o processador sai executando o BIOS

<FabioOlive> :)

<AlissonB> excelente

<AlissonB> ele sempre vai buscar o BIOS

<FabioOlive> aí o BIOS, que é o Basic Input/Output System, sabe fazer o básico que é inicializar o hardware básico da máquina (RAM, tela, teclado, disco) e carregar o setor 0 do primeiro disco configurado, e aí saltar pro código desse setor

<AlissonB> pq ele sabe onde o BIOS está!

<FabioOlive> o setor zero tu já sabes que é o MBR, o Master Boot Record

<FabioOlive> ele contém um boot loader que vai saber carregar o sistema operacional

<FabioOlive> e aí tudo funciona :)

<AlissonB> todo mundo sabe quem chamar e o negócio funciona, hehe

<FabioOlive> AlissonB: na verdade a CPU não sabe nada, ela sempre começa a executar o mesmo endereço quando boota :) mas o projetista da placa mãe tem que saber fazer o chipset da placa mapear o BIOS nesse endereço certo

<FabioOlive> eu te falei que a CPU começa no endereço 0, mas isso foi só pra simplificar. processadores antigos de 8 bits começavam no endereço 0.

<FabioOlive> as CPUs x86 bootam em modo 16 bits, e saem executando no endereço FFFF:0000, que dá o endereço físico FFFF0 :)

<FabioOlive> então é lá no FFFF0 que os projetistas de chipsets mapeiam a ROM (ou Flash) do BIOS :)

<FabioOlive> AlissonB: aliás, até dá pra comprovar isso

<FabioOlive> entra no debug aí no DOSBox

<AlissonB> ok

<FabioOlive> e digita: u ffff:0000

<FabioOlive> u de unassemble, disassemblar

<FabioOlive> no meu aqui, a instrução em FFFF:0000 é JMP F000:12C0

<FabioOlive> ou seja, “JUMP to F000:12C0”

<FabioOlive> lá em F000:12C0 deve ter o início verdadeiro do BIOS :)

<AlissonB> que doidera =x

<AlissonB> pra mim é o mesmo endereço

<FabioOlive> sim, deve ser padrão da BIOS do DOSBox

<FabioOlive> o DOSBox não usa o BIOS da tua própria máquina :) ele tem um BIOS próprio pra máquina virtual que ele cria :)

<FabioOlive> AlissonB: estão caindo algumas fichas? :)

<AlissonB> claro :D

<FabioOlive> legal :)

<FabioOlive> como o BIOS sabe operar o básico, tipo interagir com a tela e teclado, e interagir com os discos, o próprio sistema operacional simples como o DOS usa funções do BIOS pra operar

<FabioOlive> então os programas em assembly (ou qualquer programa) não precisam acessar o hardware direto, mas podem pedir para o BIOS ou o DOS fazerem isso

<FabioOlive> tipo “Ô BIOS, lê um caracter do teclado e me retorna no registrador AL”

<FabioOlive> e aí o teu programa só precisa saber como fazer esse pedido pro BIOS

<FabioOlive> e isso é padronizado e publicado em manuais, livros, etc

<AlissonB> humm

<AlissonB> legal ter documentação de tudo

<AlissonB> :)

<FabioOlive> sim, se não for assim não tem como :) não é mágico, tudo tem que ser operado da maneira correta

<FabioOlive> e só se sabe qual é se for documentado e publicado

<FabioOlive> agora tu vais entender outra coisa interessante

<FabioOlive> imagina que a Broadcom– faz um novo chip de wireless

<mibotz> Broadcom tem -1 pontos de karma

<FabioOlive> aí eles mesmos fazem um driver pra windows e mandam pra mickeysoft o driver binário, sem código fonte nem documentação

<FabioOlive> funciona legal no windows, pois eles criaram o driver que mexe no hardware deles, que só eles sabem mexer, e integrando com as funções do windows, na interface padrão de drivers

<FabioOlive> e funciona legal

<FabioOlive> MAS ninguém na mickeysoft sabe como o hardware funciona, eles só usam o driver que veio pronto

<FabioOlive> se eles não publicarem a informação de como mexer no hardware deles, só vai existir esse driver que eles mesmos fizeram

<AlissonB> mickeysoft++

<mibotz> mickeysoft tem 1 pontos de karma

<AlissonB> ri disso

<AlissonB> :D

<FabioOlive> é praticamente impossível ler o assembly do driver pra descobrir como o hardware funciona

<FabioOlive> resultado: esse hardware não teria driver pra Linux

<FabioOlive> a não ser que se faça uma engenharia reversa furiosa no driver pra windows

<FabioOlive> pois nessa situação, nem a microsoft sabe como funciona

<FabioOlive> só a broadcom

<FabioOlive> e a broadcom não conta pra ninguém

<FabioOlive> e só faz o driver pra windows e manda pronto

<FabioOlive> foda isso né?

<FabioOlive> aí fica todo mundo refém do driver porco da broadcom

<FabioOlive> esse é o caso de alguns hardwares da broadcom e dos chips gráficos da nvidia

<FabioOlive> não publicam como a porcaria funciona, e como não existe mágica, não funciona e pronto :)

<FabioOlive> a própria microsoft, se tivesse que fazer o driver pro windows, não conseguiria

<AlissonB> puts, que triste

<AlissonB> poderiam pelo menos liberar a documentação né

<AlissonB> a broadcom

<AlissonB> daí alguém faria o serviço sujo

<FabioOlive> e é por isso que geralmente quando um “gurizinho de TI” formata uma máquina com aquele CD velho de Windows XP, nada funciona direito, e aí tem que passar um tempo “baixando drivers”

<FabioOlive> aí começa a funcionar

<FabioOlive> em geral o Windows contém apenas drivers genéricos que conseguem operar o básico

<FabioOlive> tipo, gráfico 1024×768 sem aceleração 3D

<FabioOlive> rede básica sem muito desempenho

<FabioOlive> mas é o suficiente pra ficar catando drivers dos fabricantes até o negócio funcionar

<FabioOlive> no caso dos sistemas operacionais livres, só o que podemos fazer é brigar com essas empresas até eles liberarem

<FabioOlive> a documentação

<FabioOlive> hoje em dia a maioria já se entregou e liberou, ou mandou os seus próprios drivers em código fonte em C pro Linux

<FabioOlive> mas ainda tem umas nVidias que continuam na mesma :)

<AlissonB> então a nvidia faz frente a esse tipo de liberação?

<AlissonB> é uma das poucas?

<FabioOlive> sim, eles são uns fiadaspu

<FabioOlive> uma coisa engraçada é que, no tempo em que essas empresas só faziam driver pra windows, eles tinham uma vantagem: ninguém ficava sabendo o quão RUIM são os chips deles

<FabioOlive> pois eles maquivam a mula bem bonita no driver, resolvendo os bugs e tentando fazer de conta que funcionava bem

<FabioOlive> quando começaram a ter que liberar suas documentações e drivers livres, caiu a máscara

<FabioOlive> e ficou muito clara a quantidade de bugs do *hardware* que essas empresas fazem :)

<AlissonB> hummm

<FabioOlive> por isso que muitas empresas relutavam muito em liberar documentação

<FabioOlive> frequentemente o hardware nem se comporta exatamente como está documentado

<FabioOlive> :)

<FabioOlive> aí tem que ter remendos no driver, tipo ahhh se for o chip versão tal e eu mandei o comando tal, a documentação manda ler o status no bit tal do registrador tal, mas está errado e vou ler no outro lugar tal

<FabioOlive> por isso que tem tantos fucks, shits e etc no código fonte do Linux :)

<FabioOlive> bom,

<FabioOlive> acho que a aula está boa já por hoje né AlissonB :)

<FabioOlive> 1am já :)

<FabioOlive> como passa né?

<AlissonB> sim, passou voando

<AlissonB> com certeza, show de bola FabioOlive++

<mibotz> FabioOlive tem 109 pontos de karma

<AlissonB> já bateu o sono violento aqui

<AlissonB> ahuha

<FabioOlive> duas horas de aula de assembly hehehe

<FabioOlive> nocauteou!