Visual Basic 6 no ano 2026: Uma chamada para a Microsoft

O C# como linguagem de programação não é de forma alguma pior que o VB6, nem mesmo o VB.NET.

Mas: o ambiente de desenvolvimento .NET parece um passo atrás na Idade da Pedra para um programador VB6:

1. Não tem as capacidades mágicas de depuração que tornaram a "programação em tempo real" no VB6 um verdadeiro impulso para a programação: Começa com um rascunho e optimiza-o em tempo de execução.
2. O .NET reúne o que parecem ser centenas de tecnologias sob o mesmo teto, mas a interface sobrecarregada afasta qualquer recém-chegado ou que queira mudar logo à partida e a curva de aprendizagem para te familiarizares com o IDE é enorme.
3. O IDE .NET parece muito menos reativo e iniciar uma pequena aplicação Hello World pode demorar 10 segundos de tempo de compilação antes de um programa simples sequer começar...
4. O IDE .NET parece ser extremamente ávido de recursos. Instalar rapidamente um ambiente de desenvolvimento .NET num portátil Surface com 250 GB de espaço no disco rígido torna-se rapidamente como executar uma rota de cuspo quando se trata de libertar os recursos necessários.

O meu apelo à Microsoft: o VB6 tem de se tornar OpenSource para que possa ser mais desenvolvido pela comunidade e transferido para o ano 2026.

O VB6 continua a viver no ano 2026

A comunidade nunca desistiu do Visual Basic 6. Kr00l transpôs os Controlos Comuns da Microsoft frequentemente utilizados em VB6 para 2026 e criou os mesmos componentes completamente sensíveis a DPI e com capacidade Unicode/UTF-8.

O TwinBasic está a evoluir para um compilador de 64 bits que pode ser iniciado mesmo para programas existentes. A abordagem da comunidade é louvável e extremamente ambiciosa, especialmente porque ninguém tem acesso ao código fonte do VB6 e a comunidade tem de desenvolver tudo a partir do zero.

Infelizmente, a abordagem é de facto tão ambiciosa que vale a pena perguntar: que outras alternativas temos realmente?

Muitos dos pontos fracos do VB6, como o multithreading genuíno, poderiam ser resolvidos em 2026 com componentes Rust adicionais que poderiam ser acoplados, se necessário.

O grau de OOP no Visual Basic é um compromisso engenhoso entre a redução da complexidade e a utilização opcional de classes como contentores de métodos e dados, onde realmente promove a eficiência da programação. Esta abordagem não deve ser alterada de todo.

O instalador do IDE VB6 pode e deve ser completamente reconstruído, por exemplo, com o Inno Setup.

A completa consciência de DPIA, a capacidade total de UTF8 e até mesmo um compilador de 64 bits poderiam ser incorporados diretamente no código fonte do VB6.

Onde o VB6 ainda chama métodos Ansi na API Win32 (por exemplo, WriteTextA), poderíamos substituí-los por métodos W com capacidade UTF8 (WriteTextW).

Nós, a comunidade, tomaríamos conta desta tarefa e levaríamos a engenhosa abordagem do Visual Basic 6 até ao ano 2026. Porque nenhum dos antigos fãs do VB6 está atualmente a utilizar o Visual Basic .NET com verdadeira paixão.

E isto deve ser uma admissão para a Microsoft: a decisão de descontinuar o VB6 e posicionar o .NET como seu sucessor falhou.

Muitos dos restantes programadores de VB6 terão de se reorientar lentamente, perder a paciência e depois, lenta mas seguramente, mudar para Linux e Rust.

Ou a Microsoft lançará o código fonte do Visual Basic 6 e nós, a comunidade, levaremos este brilhante ambiente de desenvolvimento para Windows até ao ano 2026.

Esta última opção seria uma grande vitória para a comunidade, para os programadores, para os utilizadores e até para todo o sector tecnológico.

E, por último, mas não menos importante, seria uma grande vantagem para a Microsoft, uma vez que a decisão de disponibilizar o código-fonte do Visual Basic 6 como código-fonte aberto também aumentará a reputação da Microsoft e trará de volta muitos fãs e programadores, ligando-os ao ecossistema Microsoft.

Diria que seria uma grande vitória para a Microsoft.