O VB6 ainda funciona em 2026, mas o build é o risco

Uma aplicação VB6 que abre no Windows 11 provou apenas uma coisa muito específica: o executável atual encontra uma parte suficiente do ambiente de execução para arrancar. Não provou que a aplicação pode voltar a ser compilada, reparada, instalada numa máquina limpa ou recuperada após a falha de um disco. São capacidades distintas, e a maioria dos sistemas VB6 antigos só testou a primeira.

A data perigosa não é aquela em que o Windows se recusar a executar o EXE. É o dia em que a última máquina com o compilador, Service Pack, ficheiros OCX, bibliotecas de tipos, estado do registo, revisão do código, projeto de instalação, controlador de base de dados e memória operacional corretos deixar de arrancar. Nesse momento, uma alteração de negócio de uma linha pode tornar-se um projeto de recuperação. Trate a aplicação que funciona como prova a preservar, não como prova de que não existe problema.

O suporte do runtime não abrange o desenvolvimento em VB6

A Microsoft ainda suporta o runtime principal do VB6 nas versões suportadas do Windows, mas não suporta o IDE do VB6. Essa diferença explica por que as aplicações antigas continuam a funcionar e por que a manutenção fica mais difícil a cada ano. A declaração de suporte do Visual Basic 6.0 da Microsoft define It Just Works como objetivo de compatibilidade para aplicações existentes. O mesmo documento afirma que o desenvolvimento no IDE deixou de ter suporte em 2008 e recomenda a substituição das aplicações VB6 por tecnologia moderna.

O âmbito também é mais estreito do que muitos gestores supõem. A Microsoft limita a manutenção do runtime a regressões graves e problemas críticos de segurança em aplicações existentes. Não promete que um instalador antigo, um controlo de terceiros, um fornecedor de dados abandonado ou o compilador funcione em todas as estações futuras. A Microsoft separa os ficheiros principais do runtime incluídos no Windows, os ficheiros alargados suportados que a aplicação precisa de distribuir, os ficheiros sem suporte e os componentes de terceiros sujeitos às condições dos respetivos fornecedores.

Assim, um teste de compatibilidade com o Windows que termina a verde não resolve a questão de engenharia. Diz que este binário e este conjunto de dependências funcionaram durante o teste. Não diz se o código-fonte ainda produz esse binário. Uma aplicação compilada pode permanecer estável durante anos enquanto a capacidade de a alterar desaparece silenciosamente.

Numa revisão do portefólio uso quatro estados separados: executável, instalável, compilável e explicável. Executável significa que uma cópia já instalada arranca. Instalável significa que uma imagem limpa e suportada do Windows pode receber a aplicação a partir de suportes controlados. Compilável significa que código-fonte controlado produz um binário rastreável. Explicável significa que a equipa conhece os sistemas externos, formatos de ficheiro e regras de negócio dos quais a aplicação depende. Chamar suportado aos quatro estados esconde exatamente o risco que a revisão deve revelar.

O EXE depende de muito mais do que MSVBVM60.dll

Um executável VB6 típico depende do runtime de 32 bits, do registo COM, de controlos ActiveX, de fornecedores de acesso a dados, de configuração fora do repositório e de pressupostos sobre a máquina anfitriã. O conjunto real é muitas vezes maior do que a lista no ficheiro do projeto porque o código VB6 cria objetos por ProgID, carrega extensões por convenção, abre programas auxiliares e lê caminhos no registo ou em ficheiros INI.

Comece pela fronteira compilada. O VB6 produz normalmente código nativo de 32 bits ou p-code, e os ficheiros do runtime continuam a ser de 32 bits. No Windows de 64 bits, o processo corre sob o WOW64. Qualquer DLL ou OCX carregado dentro do processo precisa, portanto, de uma versão compatível de 32 bits. Um substituto de 64 bits registado com nome semelhante não serve um cliente COM de 32 bits. A arquitetura faz parte da interface, mesmo que o código-fonte nunca a mencione.

Depois, considere a identidade COM. Os projetos VB6 referenciam bibliotecas de tipos e componentes por GUID, versão e identidade de classe. O registo associa essas identidades a um servidor físico. Copiar um OCX para junto de um EXE não o regista necessariamente, e registar a versão errada pode corrigir uma aplicação e avariar outra. As definições de compatibilidade binária do projeto também determinam se uma DLL recompilada mantém os identificadores de classe e interface para os clientes. Um build descuidado pode compilar sem erros e deixar todos os clientes bloqueados.

O acesso a dados acrescenta outra camada. As aplicações podem usar ADO, DAO, RDO, DSN ODBC, bases Jet, clientes proprietários ou nomes de fornecedores construídos durante a execução. Uma string de ligação no código é apenas parte da dependência. DSN da máquina, aliases, bibliotecas cliente, certificados e contas de serviço podem existir totalmente fora do controlo de versões. As definições regionais podem afetar a interpretação de decimais, datas literais e ordenação. Os controladores de impressora podem mudar a paginação dos relatórios. O software antigo de desktop costuma transformar o estado da estação em estado da aplicação.

Por fim, examine os ficheiros que parecem pouco importantes: .vbp, .vbw, .res, .frx, .ctl, .ctx, .dsr, .pag, scripts de instalação e binários de compatibilidade. Um ficheiro de formulário sem o respetivo .frx pode perder imagens incorporadas ou dados de controlos. Um projeto que referencia uma DLL de compatibilidade binária no disco de um programador pode gerar novas identidades COM quando esse ficheiro desaparece. O código-fonte, por si só, não é um arquivo de build.

O Windows 11 mantém uma ilha de compatibilidade de 32 bits

As aplicações VB6 funcionam num Windows atual de 64 bits porque a Microsoft distribui e testa o runtime principal e o Windows fornece o WOW64 para processos de 32 bits. É trabalho deliberado de compatibilidade, não prova de que o VB6 voltou a ser uma plataforma de desenvolvimento atual. O runtime, o IDE e cada componente externo têm responsáveis e estados de suporte diferentes.

O WOW64 também explica vários caminhos confusos. Um processo de 32 bits que procura o diretório do sistema pode ser redirecionado, e o registo COM de 32 bits é visto pelo caminho de registo de 32 bits. Os administradores que usam o regsvr32 de 64 bits num OCX de 32 bits recebem um erro ou registam o contexto de componente errado. Num sistema de 64 bits, a ferramenta de registo de 32 bits costuma estar em SysWOW64, apesar do nome. Esta designação histórica já desperdiçou muitas janelas de manutenção.

Não copie DLL ao acaso para diretórios do sistema até o programa arrancar. Isso altera o estado global da máquina sem registar que aplicação possui o ficheiro, que versão venceu ou como repetir o resultado. Empacote exatamente as dependências redistribuíveis que tem direito de distribuir, instale-as de forma previsível e teste numa imagem limpa. Se a aplicação exigir um controlo de terceiros sem suporte, registe-o como restrição da migração em vez de fingir que o suporte do runtime principal o abrange.

As instalações em servidor exigem outra verificação. A declaração da Microsoft diz que o suporte indicado para Windows Server se aplica às edições de 64 bits e exclui o Server Core para VB6. Um executável de desktop a correr sob WOW64 numa instalação completa de servidor não pertence automaticamente a uma imagem Server Core sem interface. A fronteira de alojamento suportada deve constar no registo de instalação da aplicação.

Construa um inventário de dependências com provas

Um inventário útil combina referências estáticas, estado da máquina e comportamento observado. Nenhuma dessas fontes basta sozinha. Os ficheiros de projeto mostram as referências declaradas, o registo mostra o que a máquina de build resolve e a observação em execução revela objetos com ligação tardia e processos externos. Capture as três enquanto a máquina conhecida ainda funciona.

Na máquina de build, execute estes comandos numa consola PowerShell e guarde os resultados com a cópia do código-fonte:

Get-ChildItem -Recurse -Include *.vbp,*.mak |
  Select-String -Pattern '^(Reference|Object)=' |
  ForEach-Object { '{0}:{1}:{2}' -f $_.Path,$_.LineNumber,$_.Line } |
  Set-Content declared-com-references.txt

Get-ChildItem -Recurse -Include *.vbp |
  ForEach-Object { Get-FileHash $_.FullName -Algorithm SHA256 } |
  Export-Csv project-hashes.csv -NoTypeInformation

Get-CimInstance Win32_Product |
  Select-Object Name,Version,Vendor |
  Export-Csv installed-products.csv -NoTypeInformation

O primeiro resultado contém uma linha Reference= ou Object= declarada, com o ficheiro de origem e o número da linha. O segundo fornece um hash de cada ficheiro de projeto. O inventário de produtos é imperfeito porque nem todas as dependências usam o Windows Installer, mas fornece um ponto de comparação. Não execute Win32_Product repetidamente nas máquinas de produção, pois pode desencadear verificações de consistência do instalador. Esta é uma captura única na estação de build isolada.

Acrescente metadados para cada DLL e OCX realmente referenciado: caminho original, hash SHA-256, versão do ficheiro, versão do produto, signatário, arquitetura, origem da licença e direito de redistribuição. Exporte as entradas relevantes do registo COM de 32 bits apenas depois de resolver cada GUID a partir do projeto. Registe as versões dos clientes de base de dados, controladores ODBC e DSN, variáveis de ambiente, tipos de letra, definições regionais, controladores de impressora, tarefas agendadas, partilhas e contas de serviço. Os segredos pertencem ao cofre de segredos, não ao inventário. Este deve indicar o nome e o proprietário do segredo sem copiar o valor.

Observe depois uma execução representativa com um monitor de atividade de ficheiros e do registo. Exercite o arranque, início de sessão, uma transação normal, importações, exportações, relatórios, impressão, tratamento de erros e encerramento. Compare os acessos observados a ficheiros, registo, rede e processos com o inventário declarado. Qualquer ProgID de ligação tardia, EXE auxiliar, unidade de rede ou pasta de instalação gravável que só apareça em execução entra no inventário.

Termine com uma instalação limpa. Comece com uma imagem descartável e suportada do Windows, aplique apenas os pré-requisitos documentados, instale a aplicação e execute o percurso de aceitação. Se um engenheiro tiver de procurar um controlo numa estação antiga ou recordar um comando de registo não documentado, a aplicação ainda não é instalável. Registe a falha em vez de reparar a imagem à mão e declarar o teste concluído.

Quando a última máquina de build morre, o código não basta

Se falhar a única máquina com um build comprovado, a equipa perde um ambiente resolvido, não apenas um computador. Reconstruí-lo implica redescobrir que suportes e Service Pack do compilador foram usados, que componentes tinham licença, como as referências eram resolvidas, que ficheiros de compatibilidade binária fixavam identidades COM, que passos prévios ou de instalação corriam e se o repositório contém a revisão que produziu a versão em produção.

O primeiro sintoma costuma surgir durante uma alteração urgente. Muda uma regra fiscal, um endpoint, um certificado, uma política de palavras-passe da base de dados ou um formato de ficheiro. Um engenheiro instala o IDE numa máquina virtual, abre o projeto, fecha alguns avisos de referências em falta, substitui um controlo indisponível e obtém uma compilação bem-sucedida. O executável arranca, por isso é instalado. Mais tarde, um formulário pouco usado falha porque o controlo substituto serializa propriedades de outra forma, ou um cliente COM não consegue criar uma classe recompilada cuja identidade de interface mudou. A compilação bem-sucedida foi confundida com paridade de comportamento.

Os controlos ActiveX licenciados pioram a recuperação. Alguns precisam de entradas de licença de design para carregar no IDE, embora a aplicação compilada funcione com uma licença de execução. O fornecedor pode ter desaparecido, a ativação pode já não existir e copiar um OCX instalado pode violar a licença ou omitir dados do registo. Nenhum truque de engenharia corrige a falta de direitos legais. Identifique a propriedade e os termos de redistribuição enquanto os registos de compra e a memória do pessoal ainda existem.

Uma imagem do disco da estação de build ajuda, mas não é uma resposta completa. As imagens transportam estado oculto, credenciais, risco de malware e um sistema operativo que acabará por ser inseguro ligar. Também não provam que um checkout limpo compila. Guarde uma imagem de acesso restrito como prova e ponte de emergência, e depois crie um build automatizado e isolado a partir de entradas controladas. Se não conseguir reproduzi-lo sem a imagem, indique isso claramente no registo de riscos.

A descompilação é uma técnica de recuperação de último recurso, não substitui o controlo de versões. Os executáveis de código nativo perdem nomes e estrutura, o p-code oferece possibilidades diferentes e nenhum recupera de forma fiável comentários, scripts de build, formulários originais ou intenção de desenho. Pode recuperar comportamento suficiente para investigar uma falha. Não baseie uma modernização planeada na esperança de converter um binário de volta no projeto original.

Preserve um build antes de alterar a aplicação

A primeira ação mais segura é congelar e reproduzir o build atual, sem misturar esse trabalho com novas funcionalidades ou alterações de migração. Precisa de uma base cujas entradas, ferramentas, saídas e comportamento possam ser comparados. Alterar código enquanto reconstrói o ambiente destrói o ponto de referência.

Capture estes elementos num único pacote controlado:

1. A revisão completa do repositório, incluindo recursos dos formulários, fontes do instalador e referências de compatibilidade binária.
2. Suportes de instalação, Service Packs, controlos redistribuíveis, provas de licença e somas de verificação.
3. Um inventário da máquina e uma imagem de acesso restrito da estação conhecida.
4. Comandos exatos, ordem dos projetos, símbolos de compilação condicional e passos de empacotamento.
5. Hashes dos binários de produção e um registo assinado do build instalado em cada local.

Faça agora um checkout e um build limpos numa máquina virtual isolada. Mantenha a rede desligada, exceto quando uma entrada documentada do build a exigir. Compare os ficheiros de saída, interfaces COM exportadas e conteúdo do instalador. A igualdade byte a byte pode não ser possível devido a marcas de tempo e metadados do compilador, por isso defina o que significa igualdade antes de aceitar o resultado. No mínimo, examine versões, dependências, identidades de classes e comportamento nos testes de aceitação.

Mantenha um registo pequeno para cada tentativa. Pode ser JSON, CSV ou um documento de texto assinado, mas deve conter revisão do código, identificador da imagem, hashes de ferramentas e dependências, comandos, operador, data, hashes das saídas e resultado dos testes. O objetivo é a rastreabilidade. Seis meses depois, outro engenheiro deve conseguir identificar exatamente o que produziu um executável sem perguntar a quem o criou.

Não ligue a máquina virtual resgatada à rede normal da empresa e chame a isso continuidade. Um IDE sem suporte e instaladores antigos de terceiros aumentam a superfície de ataque, enquanto clientes antigos de base de dados podem exigir protocolos que já deveriam ter sido retirados. Isole o build, transfira entradas e saídas através de controlos, analise os artefactos, remova credenciais permanentes e registe os acessos. Isso compra tempo. Não torna saudável uma cadeia de ferramentas sem suporte.

A idade não define sozinha a data da migração

A prioridade de uma aplicação VB6 resulta da possibilidade de recuperação, da pressão de mudança e das consequências de uma falha, não da idade. Dois programas compilados no mesmo ano podem justificar decisões opostas. Uma ferramenta de consulta em modo de leitura numa estação isolada pode tolerar contenção, enquanto um cliente de encomendas com alterações semanais de regras e escritas diretas em produção pode precisar de substituição antes da próxima funcionalidade.

Avalie primeiro a recuperação. A equipa consegue instalar o pacote publicado numa imagem limpa e suportada do Windows? Consegue compilar a revisão instalada a partir de um checkout limpo? Todos os controlos, licenças e fornecedores de dados estão registados? Mais de uma pessoa consegue publicar uma versão? Um não ao build limpo aumenta a urgência mesmo sem erros comunicados, porque o prazo da próxima alteração é desconhecido.

Depois, meça a pressão de mudança. Conte pedidos reais que exigem alterações ao código, não insatisfação geral. Renovações de certificados, mudanças de API, regras fiscais, requisitos de autenticação, atualizações da base de dados e novos formatos consomem a mesma cadeia de ferramentas cada vez menor. Uma lista de funcionalidades conta, mas uma mudança externa obrigatória com data fixa conta mais. A aplicação pode estar funcionalmente concluída e continuar sujeita a alterações impostas pelos sistemas que a rodeiam.

As consequências precisam de modos de falha concretos. Pergunte o que acontece se a aplicação não arrancar durante um dia, calcular mal, perder uma transação ou não puder ser instalada depois de substituir uma estação. Dê um nome ao processo manual e teste-o com o volume atual. Um plano que depende de um funcionário reformado ou de uma caixa fechada de suportes de instalação não pode ser orçamentado com seriedade.

A exposição de segurança também muda a resposta. Uma ferramenta local que lê ficheiros controlados tem um risco diferente de um cliente que aceita documentos da internet, liga com permissões amplas à base de dados ou exige protocolos de rede obsoletos. Não classifique todo o software VB6 como inseguro apenas por causa da linguagem. Siga as entradas, privilégios, dependências e caminhos de rede. O IDE sem suporte deve ficar num ambiente de build isolado, independentemente de onde a aplicação corre.

Registo a decisão com responsável, data das provas e gatilho, não com um vago estado vermelho. A contenção pode continuar válida até o sistema anfitrião perder suporte, uma licença deixar de poder ser renovada, o build limpo falhar ou uma integração identificada anunciar uma mudança incompatível. Reveja esses gatilhos. Assim evita reescritas em pânico e o erro mais comum: uma exceção temporária renovada para sempre sem alguém assumir o risco.

A comparação de custos precisa de incluir mais do que horas de desenvolvimento. Acrescente a manutenção de imagens antigas, zonas de rede restritas, conhecimento raro dos componentes, instalação manual, recuperação de incidentes e mudanças de negócio atrasadas. Para a substituição, inclua conciliação de dados, funcionamento paralelo, formação, transição e desativação. Uma estimativa honesta ainda pode favorecer a contenção. Não deve fazer desaparecer o trabalho do sistema antigo só porque está nas operações e não no orçamento do projeto.

As saídas realistas têm perfis de risco diferentes

Existem cinco caminhos defensáveis, e o certo depende da frequência de mudanças, exposição operacional e quantidade de comportamento observável. Deixar como está só é uma decisão quando o executável tem uma vida restante limitada, o build é recuperável, o anfitrião está controlado e a empresa aceita o plano de falha. Continuar por inércia não é a mesma escolha.

A virtualização preserva um ambiente antigo e pode separá-lo da renovação das estações. É útil para ferramentas internas que mudam pouco, sobretudo com reduzida integração de hardware. Também congela antigas fraquezas, restrições de licenciamento e conhecimento operacional numa imagem. Protege a disponibilidade perante a troca de um portátil, mas não moderniza a aplicação nem recupera o suporte do fornecedor.

Colocar o sistema VB6 atrás de uma API pode reduzir o acesso direto à base de dados e dar aos novos clientes uma fronteira estável. Funciona quando o programa antigo já expõe operações de negócio invocáveis ou pode ser controlado por um adaptador. Funciona mal quando a automatização depende de tempos da interface, diálogos modais, ficheiros partilhados ou estado global da máquina. Automatizar a interface é uma ponte temporária com data de remoção, não uma arquitetura de integração.

A substituição gradual move uma capacidade delimitada de cada vez. Pode reduzir o risco de instalação quando as fronteiras dos módulos são reais e a equipa consegue executar caminhos antigos e novos em conjunto. Também pode criar anos de escritas duplas, interop COM, regras duplicadas e conciliação se as fronteiras só existirem num desenho. Defina os incrementos em torno de transações de negócio observáveis, não de pastas de código.

Uma reescrita completa justifica-se quando o sistema está muito acoplado, o build está a falhar, a arquitetura de destino muda o modelo operacional ou manter dois sistemas custa mais do que o risco da transição. A objeção habitual diz que as reescritas perdem regras de negócio ocultas. É verdade quando a equipa trata o código como especificação e testa apenas os casos normais. Uma reescrita torna-se defensável quando comportamento registado, dados e casos extremos formam um oráculo executável de comparação.

Sou contra a conversão automática linha a linha. É popular porque parece preservar o âmbito e oferece uma percentagem mensurável. Normalmente transporta estado global, acoplamento à interface e comportamento acidental da base de dados para outra linguagem, e acrescenta cola de interop onde falha. O resultado é arquitetura antiga mais difícil de diagnosticar porque a semântica de execução conhecida mudou. Preserve o comportamento, não a antiga disposição de ficheiros e formulários.

O comportamento registado é o contrato da migração

Um teste de migração deve comparar efeitos de negócio na fronteira de uma transação, não apenas ecrãs ou valores devolvidos. Para cada operação representativa, capture o pedido normalizado, dados iniciais, configuração relevante, respostas externas, alterações na base, ficheiros gerados, mensagens e resultado visível. Reproduza o mesmo caso no substituto e compare os efeitos depois de remover campos variáveis como marcas de tempo e identificadores gerados.

Um caso compacto de paridade pode ter este aspeto:

{
  "case": "invoice-credit-partial",
  "input": {"invoice_id": 4812, "amount": "37.50"},
  "expected": {
    "status": "partially_credited",
    "ledger_delta": "-37.50",
    "document_type": "credit_note"
  }
}

O nome do caso importa menos do que a origem. Registe que fluxo de produção o forneceu, remova dados pessoais, versione o conjunto e mantenha determinista a comparação. Inclua casos normais e difíceis: strings vazias contra nulos, decimais locais, dias bissextos, submissões duplicadas, tempos esgotados, falhas parciais e novas tentativas. As aplicações VB6 codificam muitas vezes o tratamento de erros na ordem dos eventos e no estado partilhado, por isso teste sequências além de operações isoladas.

Os testes de referência, sozinhos, podem preservar erros. Classifique as diferenças como correção pretendida, diferença de representação inofensiva, comportamento em falta ou defeito do teste. Um responsável de produto tem de aprovar alterações pretendidas, porque os engenheiros não podem decidir pela leitura do código se uma regra contabilística estranha é acidental. Guarde o resultado original ao lado da nova expectativa aprovada para tornar a decisão auditável.

O tráfego de produção dá melhor cobertura do que casos unitários inventados quando pode ser registado legalmente e em segurança. A CodeHero usa um sistema de paridade com tráfego de produção gravado enquanto moderniza a arquitetura em vez de transliterar o código. O princípio vale sem um fornecedor específico: capture os pedidos reais dos utilizadores, limpe-os, reproduza-os e compare os efeitos duradouros.

Escolha o destino a partir da fronteira do sistema

O destino deve seguir as fronteiras de instalação, falha e propriedade, não a moda das linguagens. Uma aplicação de desktop que sobretudo valida dados e chama uma base central pode tornar-se um cliente TypeScript com serviços e Postgres. Um módulo intensivo em cálculo pode justificar Rust num pequeno núcleo numérico. Um serviço transacional com concorrência e operação simples pode encaixar em Go. São conclusões de desenho, não substituições automáticas da sintaxe VB6.

Desenhe primeiro a fronteira atual de execução. Marque que trabalho deve ocorrer na máquina do utilizador, o que pertence perto da base de dados, que integrações exigem chamadas ordenadas e que saídas precisam de permanecer compatíveis byte a byte. Decida onde ficam identidade, autorização, repetição e registos de auditoria. Se dois componentes substitutos precisam de partilhar uma transação de base de dados e ser instalados juntos, chamar-lhes serviços separados apenas acrescentou uma falha de rede, não independência.

A migração dos dados exige a mesma disciplina do código. Preserve identificadores, precisão decimal, codificação, tratamento de nulos e estados históricos antes de melhorar o esquema. Execute consultas de conciliação sobre totais e transições, não apenas contagens de linhas. Se a aplicação antiga escreve diretamente em tabelas a partir de muitos formulários, coloque uma fronteira de escrita controlada em torno desse comportamento antes de dividir a propriedade.

Para um sistema que precisa de deixar o VB6 rapidamente, a CodeHero lê todo o código, reescreve-o em Go, Rust e TypeScript com Postgres onde fizer sentido, e entrega cada projeto em menos de 30 dias. Quer escolha esse caminho ou a sua equipa, exija as mesmas provas: uma base de código reproduzível, decisões de arquitetura explícitas e resultados de paridade ligados a comportamento registado.

Não espere que uma versão do sistema operativo decida por si. A compatibilidade do Windows pode manter o EXE vivo enquanto desaparecem o conhecimento do build, os direitos dos componentes e a memória da equipa. Demonstre já um build limpo, capture o inventário de dependências e registe transações reais. Depois escolha contenção, substituição gradual ou reescrita enquanto o sistema que funciona ainda consegue dizer exatamente o que o novo deve fazer.