<Direto ao Ponto 39> Criando um código executável

Artigos desta série: ( < ) Anterior | Índice | Seguinte ( > )

Olá, dev!

Este é mais um artigo da série DIRETO AO PONTO, que eu estou escrevendo para a DIO. Ele vai tratar de como a gente pode criar um código executável e executá-lo no computador.

Sumário

1. Introdução
2. A era do cartão perfurado
3. A época dos terminais burros
4. O UNIX raiz
5. E chegaram os PCs!
6. O Windows, afinal!
7. A web
8. O Java virou moda
9. Os apps
10. Considerações finais
11. Referências

1 – Introdução

Eu criei a série de artigos DIRETO AO PONTO com o objetivo de apresentar, de forma simples e direta, conhecimentos básicos da programação e de computação, principalmente, para os iniciantes.

Aqui, são tratados de temas como lógica de programação, linguagens, hardware dos computadores, história da computação e assuntos relacionados à plataforma da DIO, como a escrita de artigos e os desafios de código.

Neste artigo, eu vou falar sobre as diversas formas que a gente pode criar um código executável, ao longo dos anos, e executá-lo no computador.

Basicamente, criar um programa executável é usar um código-fonte escrito em alguma linguagem de programação e executá-lo, de alguma forma, em um computador, para ver as ações dele serem realizadas.

Desde os primórdios do computador, na época dos cartões perfurados, a gente já codificava e executava programas, só que era de uma forma bem diferente da que é feita atualmente.

De lá pra cá, muita coisa mudou, mas a técnica mais comum que usamos no passado ainda é uma das mais usadas hoje em dia, a da compilação dos programas.

Só que a evolução tecnológica trouxe outras formas modernas de se criar um programa executável e de executá-lo.

Hoje, eu vou contar essa história e apresentar várias formas de se partir do código-fonte e de se chegar a executar o programa gerado por ele, tudo associado à minha própria carreira, ou como eu usei estas tecnologias ao longo dos anos, à medida que elas surgiam.

2 – A era do cartão perfurado

 Naquela época, a universidade (UFPB – Campus II, atual UFCG – Campus de Campina Grande-PB) só tinha um computador de grande porte, o mainframe IBM 360.

No primeiro semestre do meu curso (Engenharia Elétrica), cursei a disciplina Introdução à Ciência da Computação (ICC). O programa em FORTRAN, ainda na versão não estruturada (que usava comandos GO TO), era codificado usando cartões perfurados. Cada cartão tinha 1 linha de instrução, que era impressa no topo do cartão.

O programa todo ocupava uma pilha de cartões, que eram amarrados, em sequência, com uma borrachinha, e entregues ao Núcleo de Processamento de Dados – NPD para que ele fosse executado.

O setor entregava os resultados das execuções em horários definidos, de 2 em 2 horas, apenas a listagem impressa.

Nós, alunos, não tínhamos acesso ao executável, apenas à listagem da execução, que continha apenas as instruções, mensagens de erros de digitação, de compilação e de execução, e a saída da execução, caso ele rodasse sem erros.

Se houvesse algum erro, seja de digitação, compilação ou de execução, voltávamos à perfuradora de cartões para corrigir os erros, perfurando novos cartões e substituindo, na mesma ordem, os cartões que apresentassem as instruções que causaram os erros.

Entregávamos novamente a pilha de cartões ao setor, para execução, e esperávamos pelo próximo horário de entrega das listagens.

Às vezes, até que todos os erros fossem corrigidos levavam dias até que a gente conseguisse a listagem com a saída esperada do programa codificado.

Por isso, era muito importante fazer um teste de mesa antes de perfurar os cartões e submeter à execução no NPD. Quanto menos vezes a gente submetesse o programa à execução, mais rápido obteria a resposta correta.

No semestre seguinte, eu cursei a disciplina Cálculo Numérico, o computador era o mesmo, mas a versão do FORTRAN mudou para FORTRAN IV.

O processo de codificação e de obtenção dos resultados também continuou o mesmo.

3 – A época dos terminais burros

Em 1986, com o curso de Engenharia concluído, eu entrei direto na Pós-graduação e as coisas mudaram um bocado.

A disciplina era Métodos Numéricos, a gente passou a usar FORTRAN 77, na sua primeira versão estruturada e o computador ainda era um mainframe, mais moderno, um IBM 4341, com terminais burros IBM 3270.

Um terminal burro é aquele que não tem nenhum processamento, sendo apenas uma forma de se conectar ao computador principal por meio de um teclado e um monitor de tela textual (nada de mouse!), com tela monocromática verde (no nosso caso).

Agora, a gente já podia digitar o código do programa na tela do terminal e executá-lo, recebendo as mensagens de erro e as saídas ali mesmo. E podia executar o mesmo código várias vezes no terminal, pois o executável ficava gravado para usar novamente.

4 – O UNIX raiz

Durante a Pós-graduação, eu também aprendi a programar na linguagem C, usando computadores com o sistema operacional UNIX padrão, raiz. Ainda não havia computadores pessoais (com o sistema operacional DOS) disponíveis para os alunos da Universidade, nem existia o Windows, nem o linux!

A programação em C também era feita por compilação, como no caso do FORTRAN, só que a gente tinha que comandar todo o processo por comandos textuais e tinha acesso aos arquivos intermediários do processo.

 A codificação do programa era feito em um terminal de texto, usando o programa vi, um editor de textos baseado em comandos textuais minimalistas (em geral ativados por apenas uma letra). Ele não era nada usável, mas era o que havia na época e, ainda hoje, ele está disponível também no Linux, mas existem versões melhores atualmente (como o pico, por exemplo).

Para compilar, era usado o compilador cc, criado pelos inventores da linguagem C, Kernighan e Richie. Por exemplo, o comando para compilar o programa fonte helloworld.c era:

 cc helloworld.c

Ele gerava um arquivo executável, com o nome padrão a.out, que executava o programa do código-fonte.

Para gerar um executável com outro nome, diferente deste padrão, o comando deveria ser:

cc -o helloworld helloworld.c

E o executável helloworld seria criado, no lugar de a.out.

Este comando também oferecia a funcionalidade de gerar apenas os arquivos objeto, que são códigos de máquina, em binário, mas ainda não eram os executáveis do programa.

cc -c helloworld.o

Assim, o arquivo objeto helloworld.o seria gerado.

Outros arquivos objetos poderiam ser criados da mesma forma, listados no mesmo comando, para outros arquivos-fonte que fizessem parte do programa completo.

No final, após a compilação, era preciso realizar um processo de ligação (linkedição ou ainda, “linking”), que juntava vários arquivos do tipo objeto usados pelo programa e possíveis bibliotecas da linguagem, necessárias à geração do programa executável.

Para o exemplo acima, supondo que o programa tivesse outro arquivo objeto chamado interface.o, o comando para gerar o executável helloworld seria:

cc -o helloworld helloworld.o interface.o

No UNIX (e hoje, no Linux), um arquivo executável era indicado pelas suas permissões de acesso, não por uma extensão específica.

Por exemplo, para os arquivos do exemplo (sem o arquivo interface.o), veja que o executável helloworld possui as permissões “_rwxr_xr_x”, cujas letras x indicam que ele é executável por qualquer usuário (ver a figura):

5 – E chegaram os PCs!

Nesta mesma época, a universidade passou a contar com laboratórios de computadores pessoais, ainda com o sistema operacional DOS.

O processo de compilação de um programa na linguagem C era o mesmo visto acima (código-fonte -> código objeto -> executável). A grande diferença era que os arquivos executáveis tinham a extensão obrigatória “.exe” nos PCs, diferentemente do UNIX.

O primeiro compilador que eu usei foi o Microsoft C Compiler, mas logo surgiu o Turbo C, que passou a dominar as compilações da linguagem nos PCs.

Nesta época, também foi lançado o Turbo Pascal, da Borland, para a linguagem Pascal (extensão .pas), ainda para ambiente DOS, e fez muito sucesso!

6 – O Windows, afinal!

Em 1992, eu entrei no curso de Computação e a linguagem utilizada nas disciplinas iniciais era o Pascal.

Só que os laboratórios de computadores pessoais da universidade já contavam com PCs com Windows, ainda nas versões iniciais, mas era um salto gigantesco, dos terminais textuais para as interfaces gráficas (“habemus mouse!!!”).

Mesmo assim, havia compiladores para C, C++ e Pascal rodando em Windows.

Foi nesta época que eu aprendi a programar em C++ também, com o objetivo de criar programas para o Windows, com base no livro do Charles Petzold, Programando para Windows 3.1.

É claro que a programação ficou muito mais fácil e divertida (menos trabalhosa!), os programas já eram gerados com interfaces e elementos gráficos. A obrigação tinha se transformado em diversão!

Os compiladores e os ambientes de desenvolvimento (“IDEs”) já integravam funcionalidades de arrastar e soltar elementos gráficos (de interface, por exemplo) e apenas editar suas características específicas para o seu programa em desenvolvimento.

Com o Windows, também surgiram as famosas DLLs (Dynamic Link Libraries), que eram bibliotecas de vínculo dinâmico, contendo código, dados e recursos que podiam ser usados simultaneamente por várias aplicações.

Elas não eram compiladas junto com o programa-fonte, mas ficavam disponíveis no mesmo diretório (pasta) do executável para serem acessadas. As DLLs permitiam reutilização de código, economia de memória e facilidade de atualização.

Algum tempo depois, chegou o Borland Delphi, que usava a linguagem Object Pascal e tinha a facilidade de se programar arrastando blocos visuais de elementos da interface e configuração de seus parâmetros para gerar programas com interfaces gráficas completas para Windows. Fez tanto sucesso que até hoje é usado!

7 – A web

Em 1993, eu passei em um concurso e fui trabalhar em uma empresa de Computação do governo do estado (CODATA), onde trabalho até hoje.

Fui lotado inicialmente no Laboratório de Meteorologia do Estado (LMRS-PB) e lá eu aprendi a programar em Delphi, usei estações de trabalho coloridas Sparc Station, da Sun, com UNIX, rede Novell, Windows NT e muitas outras tecnologias.

Em 1995, a web chegou e eu criei o primeiro site institucional do órgão, só com HTML 1.0 e figuras GIF. Era o executável passando para dentro dos navegadores de Internet.

Para usar a tag de formulários (form action>, eu criei os executáveis cgi em C, para depois passar a usar a linguagem Perl, que era interpretada, não compilada.

Uma linguagem interpretada é aquela que não precisa ser compilada para gerar um arquivo executável, pois cada instrução é convertida em linguagem, de máquina de cada vez e executada.

Depois do Perl, passamos a usar o PHP como linguagem de comandos dentro do HTML, também interpretada, e o ASP, linguagem da Microsoft equivalente ao PHP.

Nesta época surgiu o Javascript (criado como Livescript, mas mudou de nome por causa do sucesso do Java), linguagem criada pela Netscape para permitir interação e dinâmica nas páginas web; a Microsoft logo criou uma linguagem equivalente chamada JScript, que integrava controles ActiveX.

OBS: O Javascript também é uma linguagem interpretada, mas ela pode ter trechos compilados por meio do JIT (“Just In Time”), que identifica as partes do código executadas com mais frequência e as compila em código de máquina nativo e o armazena em cache, para uso rápido posterior. A mesma coisa ocorre com o Python, interpretada, mas ele pode passar por um processo de compilação, em algumas implementações, como o PyPy, usando o JIT depois.

O Java tinha sido criado pela Sun Microsystems, com uma nova técnica de gerar executáveis, que será tratada na próxima seção.

Inicialmente, o Java passou a ser usado nas páginas web apenas para inserir pequenas animações (os famosos applets), tornando as páginas mais dinâmicas (e irritantes, com tantas animações chamando a atenção num lugar só, algumas sem relação nenhuma com o assunto do site).

Bem, era a web começando a virar o que a gente vê hoje.

8 – O Java virou moda

Eu concluí meu curso de Computação sem ter visto Java, mas a linguagem já tinha virado moda, para programas gerais, não por causa applets da web.

Ele passou a ser muito usado na geração de páginas baseadas em bancos de dados, via JDBC, lendo os dados em um banco e criando tabelas de dados em páginas web, bem como em programas de uso geral.

O Java trouxe uma nova técnica de criação de programas executáveis, baseada em bytecodes, que funcionava assim:

Um programa-fonte em Java (extensão .java) era compilado, mas não gerava um executável que já podia rodar no computador. Ele gerava um tipo de arquivo intermediário, em formato binário “bytecode”, com extensão .class.

Este arquivo precisava de um novo programa para ser executado, chamado de “Java Virtual Machine” – JVM.

O compilador Java gerava os mesmos bytecodes para qualquer sistema operacional (SO). Cada SO precisava ter uma JVM que rodasse nele, lendo um arquivo de bytecodes e executando-o no computador.

A JVM seria um programa de runtime, que executava os bytecodes em cada SO específico. Assim, em tese, um mesmo código em Java poderia rodar em qualquer SO, desde que ele tivesse uma JVM disponível para executar os bytecodes gerados.

Essa técnica quebrou a tradicional forma de compilar um código-fonte para gerar um executável.

A linguagem Java possui o paradigma de Programação Orientada a Objetos (POO), assim como a linguagem C++ e a linguagem C#, que é uma linguagem equivalente ao Java, desenvolvida pela Microsoft.

Eu não aprendi Java na universidade, mas fui atrás e aprendi de forma autodidata.

9 – Os apps

Depois das revoluções das linguagens orientadas a objeto, das janelas gráficas, dos bytecodes e da web, ainda faltava uma coisa para colocar os programas nas mãos das pessoas.

E ele chegou na forma de smartphones, que popularizou muito os programas para quem não tinha acesso a computadores. Foi o começo da era dos aplicativos, ou apps, como conhecemos.

Praticamente, todos os programas que rodavam nos computadores passaram a rodar em apps nos smartphones.

Eu vou falar de dois mundos de apps, Android (do Google) e iOS (da Apple).

No Android, por muito tempo, a linguagem recomendada era o Java, mas depois o Google mudou para a linguagem Kotlin. Embora a forma de se gerar um executável em Kotlin seja semelhante à do Java, o executável de um app Android tem sua própria estrutura particular.

O formato é chamado de APK (“Android Package”), cujo formato é .apk. Ele é um arquivo compactado que contém todos os componentes (código compilado, recursos, bibliotecas etc.) necessários para executar um aplicativo. 

No Java ou Kotlin, o formato das classes é .class, já no Android, o programa-fonte (em Java ou Kotlin) é compilado no formato das classes em bytecode Dalvik (ART), armazenado em um ou mais arquivos Dalvik Executable (extensão .dex).

NO iOS, os aplicativos são armazenados de uma forma semelhante, mas estrutura diferente. Os aplicativos são distribuídos em pacotes “iOS App Store Package” (extensão .iap).

10 – Considerações finais

Este é mais um artigo da série DIRETO AO PONTO, que eu estou escrevendo para a DIO. Desta vez, eu falei sobre as diversas formas de criação de programas executáveis, que rodarão em um computador.

Primeiro, falei dos cartões perfurados e FORTRAN, típico dos anos 70 e início dos anos 80. Depois, falei dos terminais textuais dos mainframes e dos sistemas UNIX.

Aí, a tecnologia foi avançando e vieram os PCs, depois o Windows. Mais recentemente, em 1995 a web chegou no Brasil, ainda com páginas só com HTML 1.0 e figuras, para depois chegar aos sistemas de bancos de dados na web.

Por último, vieram os smartphones e os apps, que literalmente, levaram os programas para as mãos de todo mundo.

Atualmente, eu aprendi Python, outra linguagem interpretada, e Kotlin, linguagem semelhante ao Java, e um subconjunto dela, mais simples e menos verbosa.

As tecnologias que eu falei aqui foram todas usadas por mim na minha jornada, portanto, não procurei falar sobre TODAS as opções ou as MELHORES opções. Estas são as que eu tive contato direto e trabalhei com elas, por isso elas estão acompanhando a minha história.

No próximo artigo, eu vou falar sobre as linguagens de programação, já que o assunto foi iniciado com este artigo

11 – Referências

Todo o conteúdo deste artigo foi tirado do que eu aprendi (e me lembro) sobre o assunto desde o início da minha carreira como programador, desde os anos 80 até agora. Por isso, não vou listar nenhum a referência de livros nem de sites.

Artigos desta série: ( < ) Anterior | Índice | Seguinte ( > )