Compatibilidade de Aplicações Visual Basic 6.0 no Windows 7

  • Article


 

Nos últimos trabalhos realizados para garantir a compatibilidade de aplicações no Windows 7, encontrei uma quantidade significativa de aplicações desenvolvidas em Visual Basic 6.0. O Visual Basic 6.0 apresenta alguns problemas de compatibilidade quando executado no Windows 7.

Os tópicos a seguir descrevem os problemas mais comuns encontrados durante o processo de migração das aplicações do Windows XP para o Windows 7.

1. Acesso Negado

O Process Monitor (PROCMON) é uma boa opção para diagnosticar as atividades do sistema de arquivos, do Registro e de processos e threads em tempo real. Na Figura 1 é possível verificar, através do PROCMON, que o erro de acesso negado ocorre devido à aplicação tentar gravar um arquivo texto no diretório da
aplicação localizado em C:\Program Files (x86) . A partir do Windows Vista, é necessário ter privilégio administrative para realizar modificações por se tratar de um diretório protegido.

 

Figura 1 - Erro de Acesso Negado

 

Na maioria dos casos, esse problema ocorre devido o UAC estar desativado (prática não recomendada pela Microsoft). As aplicações VB6 são virtualizadas quando o UAC está habilitado. Consequentemente, com o UAC habilitado, o erro de acesso negado não irá ocorrer quando a aplicação tentar gravar o arquivo no diretório da aplicação, pois essa ação será automaticamente redirecionada (REPARSE) para a pasta VirtualStore localizada em %LOCALAPPDATA%, conforme ilustrado na Figura 2.
 
 

Figura 2 - Virtualização de arquivo para aplicações legadas

 

Para maiores detalhes sobre UAC consulte o artigo Controle de Conta de Usuário (UAC).

 

2. Permissão Negada

No Windows 7, o uso do método SendKeys gera o erro “Run-tine error '70': Permission denied” quando o UAC está habilitado. A Figura 3 exibe um DUMP coletado, para uma das aplicações diagnosticadas, no momento em que o erro ocorre. Através do DUMP é possível verificar que o erro ocorreu devido ao uso da função SendKeys:


  
Figura 3 - Permissão Negada devido o uso do método SendKeys

 

Um dos usos mais frequentes do SendKeys no VB6 é simular a tecla tab, conforme o exemplo a seguir:

 

Figura 4- Uso do SendKeys

 

Existem algumas soluções para esse corrigir esse problema sem a necessidade de executar a aplicação com privilégio elevado ou desativar o UAC. Sendo algumas delas: 

  • Recompilar a aplicação VB6 no Windows 7. Esse problema de incompatibilidade foi corrigido na última versão do runtime do VB6 (MSVBVM60.DLL) que agora utiliza um método interno diferente para realizar a ação. Essa solução corrige o problema de acesso negado do código compilado, entretanto, não elimina o erro durante o debug do código através da IDE do VB6. 

 

  • Substituir o SendKeys pela API PostMessage, conforme:
 Public Declare Function PostMessage Lib "user32" Alias "PostMessageA" (ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long 
 
 Private Sub Text1_KeyPress(KeyAscii As Integer) 
 
 If KeyAscii = 13 Then 
 SendKeys "{tab}" '13 = Enter Key 
 PostMessage hwnd, &H100, &HD&, &H1C0001 
 End If 
 
 End Sub

 

3.  Tipo Incompatível

Encontrei esse erro em algumas aplicações VB6. Observando apenas a mensagem de erro fica difícil identificar que o erro de incompatibilidade de dados ocorria devido à falta do runtime do VB5 (que possui como DLL principal a MSVBVM50.DLL)

 

Figura 5 - Mensagem Run-time error 13 Type mismatch

 Em poucos casos a mensagem de erro informava corretamente que o motivo do erro era a falta da MSVBVM50.DLL.

 

Figura 6 - Mensagem de erro informando que o runtime do VB5 não foi encontrado.

 O Process Monitor pode ser utilizado para confirmar que o problema realmente se refere à falta do runtime do VB5.


 
Figura 7 - Aplicação VB6 que possui dependência do runtime do VB5

 

O runtime do Visual Basic 5.0 funciona no Windows 7, apesar de não ser mais suportado, e está disponível para download no Centro de Download da Microsoft: https://support.microsoft.com/kb/180071.

4.  ConnectionString Incorreta

 A seguinte mensagem de erro é exibida quando a aplicação não é executada com privilégio de administrador:

  Error: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified Code: 80004005 Source: Microsoft OLE DB Provider for ODBC Drivers

A mensagem equivalente no Windows 7 em português seria: Nome da fonte de dados não encontrado e nenhum driver padrão especificado.

Durante o debug da aplicação foi possível diagnosticar que a ConnectionString utilizada para retornar as informações de conexão estava incorreta, ou seja, retornava  apenas o provider da conexão.

               

Valor retornado

Valor esperado

Provider=MSDASQL.1;

DRIVER=XX;SERVER=XX;DataBase=XX;UID=XX;PWD=XX;

  

O motivo do valor da conexão estar truncado ocorre devido um FIX de segurança que foi lançado a partir do Windows Vista. O objetivo do FIX é esconder as informações que expõem a segurança. É necessário adicionar na ConnectionString a informação “PersistSecurity Info=true” para que o ADO entenda que as informações sensíveis (Extended Properties) são necessárias e devem ser mantidas.

 

Links Úteis          

Visual Basic 6.0 Resource Center - https://msdn.microsoft.com/en-us/vstudio/ms788229.aspx