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: http://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 - http://msdn.microsoft.com/en-us/vstudio/ms788229.aspx