VB6 aún funciona en 2026, pero el build es el riesgo

Una aplicación VB6 que se abre en Windows 11 solo ha demostrado algo muy concreto: su ejecutable actual encuentra una parte suficiente del entorno de ejecución para arrancar. No ha demostrado que la aplicación pueda volver a compilarse, repararse, instalarse en un equipo limpio ni recuperarse después del fallo de un disco. Son capacidades distintas, y la mayoría de los sistemas VB6 veteranos solo han probado la primera.

La fecha peligrosa no es aquella en la que Windows se niegue a ejecutar el EXE. Es el día en que deje de arrancar el último equipo con el compilador, Service Pack, archivos OCX, bibliotecas de tipos, estado del registro, revisión de código, proyecto de instalación, controlador de base de datos y memoria operativa correctos. Entonces, un cambio de negocio de una línea puede convertirse en un proyecto de recuperación. Trate la aplicación que funciona como una prueba que debe conservar, no como prueba de que no existe un problema.

El soporte del runtime no cubre el desarrollo con VB6

Microsoft aún mantiene el runtime principal de VB6 en las versiones de Windows con soporte, pero no mantiene el IDE de VB6. Esa diferencia explica tanto que las aplicaciones antiguas sigan funcionando como que mantenerlas resulte más difícil cada año. La declaración de soporte de Visual Basic 6.0 de Microsoft fija It Just Works como objetivo de compatibilidad para las aplicaciones existentes. El mismo documento dice que el desarrollo con el IDE carece de soporte desde 2008 y recomienda sustituir las aplicaciones VB6 por tecnología moderna.

El alcance también es más estrecho de lo que muchos directivos suponen. Microsoft limita el mantenimiento del runtime a regresiones graves y problemas críticos de seguridad de las aplicaciones existentes. No promete que un instalador antiguo, un control de terceros, un proveedor de datos abandonado o el compilador funcionen en todas las estaciones futuras. Microsoft separa los archivos principales del runtime incluidos en Windows, los archivos ampliados con soporte que debe distribuir la aplicación, los archivos sin soporte y los componentes de terceros sujetos a las condiciones de sus proveedores.

Por tanto, una prueba de compatibilidad con Windows que termina en verde no resuelve la cuestión de ingeniería. Dice que este binario y este conjunto de dependencias funcionaron durante la prueba. No dice si el código fuente todavía produce ese binario. Una aplicación compilada puede permanecer estable durante años mientras la capacidad de cambiarla desaparece en silencio.

En una revisión del parque uso cuatro estados independientes: ejecutable, instalable, compilable y explicable. Ejecutable significa que arranca una copia ya instalada. Instalable significa que una imagen limpia y compatible de Windows puede recibir la aplicación desde medios controlados. Compilable significa que un código fuente controlado produce un binario trazable. Explicable significa que el equipo conoce los sistemas externos, formatos de archivo y reglas de negocio de los que depende la aplicación. Llamar compatible a los cuatro oculta precisamente el riesgo que la revisión debe sacar a la luz.

El EXE depende de mucho más que MSVBVM60.dll

Un ejecutable VB6 normal depende del runtime de 32 bits, el registro COM, controles ActiveX, proveedores de acceso a datos, configuración externa al repositorio y supuestos sobre el equipo anfitrión. El conjunto real suele superar la lista del archivo de proyecto porque el código VB6 crea objetos por ProgID, carga complementos por convención, abre programas auxiliares y lee rutas del registro o de archivos INI.

Empiece por el límite compilado. VB6 suele generar código nativo de 32 bits o p-code, y los archivos del runtime siguen siendo de 32 bits. En Windows de 64 bits, el proceso se ejecuta bajo WOW64. Cualquier DLL u OCX que cargue dentro del proceso debe tener, por tanto, una versión compatible de 32 bits. Un sustituto de 64 bits registrado con un nombre parecido no sirve a un cliente COM de 32 bits. La arquitectura forma parte de la interfaz, aunque el código fuente nunca la mencione.

Después, tenga en cuenta la identidad COM. Los proyectos VB6 hacen referencia a bibliotecas de tipos y componentes por GUID, versión e identidad de clase. El registro asigna esas identidades a un servidor físico. Copiar un OCX junto a un EXE no lo registra necesariamente, y registrar la versión equivocada puede arreglar una aplicación y estropear otra. Los ajustes de compatibilidad binaria del proyecto también determinan si una DLL recompilada conserva los identificadores de clase e interfaz para sus clientes. Una compilación descuidada puede terminar sin errores y dejar bloqueados a todos los clientes.

El acceso a datos añade otra capa. Las aplicaciones pueden usar ADO, DAO, RDO, DSN ODBC, bases Jet, clientes de base de datos propietarios o nombres de proveedores construidos durante la ejecución. Una cadena de conexión en el código solo constituye una parte de la dependencia. Los DSN del equipo, alias, bibliotecas cliente, certificados y cuentas de servicio pueden vivir por completo fuera del control de versiones. La configuración regional puede afectar a la lectura de decimales, fechas literales y ordenación. Los controladores de impresora pueden cambiar la paginación de los informes. El software de escritorio antiguo tiende a convertir el estado de la estación en estado de la aplicación.

Por último, revise los archivos que parecen poco importantes: .vbp, .vbw, .res, .frx, .ctl, .ctx, .dsr, .pag, scripts de instalación y binarios de compatibilidad. Un archivo de formulario sin su .frx correspondiente puede perder imágenes incrustadas o datos de controles. Un proyecto que hace referencia a una DLL de compatibilidad binaria guardada en el disco de un desarrollador puede generar identidades COM nuevas cuando desaparece ese archivo. El código fuente, por sí solo, no es un archivo de compilación.

Windows 11 mantiene una isla de compatibilidad de 32 bits

Las aplicaciones VB6 funcionan en un Windows actual de 64 bits porque Microsoft distribuye y prueba el runtime principal y Windows aporta WOW64 para los procesos de 32 bits. Es un trabajo de compatibilidad deliberado, no una señal de que VB6 se haya convertido de nuevo en una plataforma de desarrollo vigente. El runtime, el IDE y cada componente externo tienen propietarios y estados de soporte distintos.

WOW64 también explica varias rutas confusas. Un proceso de 32 bits que intenta llegar al directorio del sistema puede ser redirigido, y el registro COM de 32 bits se ve a través de la ruta de registro de 32 bits. Los administradores que usan el regsvr32 de 64 bits con un OCX de 32 bits obtienen un error o registran el contexto de componente equivocado. En un sistema de 64 bits, la herramienta de registro de 32 bits suele estar en SysWOW64, pese al nombre. La denominación histórica ha malgastado muchas ventanas de mantenimiento.

No copie DLL al azar en los directorios del sistema hasta que arranque el programa. Eso modifica el estado global del equipo sin anotar qué aplicación posee el archivo, qué versión ganó ni cómo repetir el resultado. Empaquete exactamente las dependencias redistribuibles que tenga derecho a distribuir, instálelas de forma previsible y pruebe en una imagen limpia. Si la aplicación necesita un control de terceros sin soporte, regístrelo como restricción de la migración en vez de fingir que el soporte del runtime principal lo cubre.

Los despliegues en servidor necesitan otra comprobación. La declaración de Microsoft dice que el soporte de Windows Server que enumera se aplica a ediciones de 64 bits y excluye Server Core para VB6. Que un ejecutable de escritorio funcione bajo WOW64 en una instalación completa de servidor no significa que deba estar en una imagen Server Core sin interfaz. El límite de alojamiento compatible debe constar en el registro de despliegue de la aplicación.

Construya un inventario de dependencias con pruebas

Un inventario útil combina referencias estáticas, estado del equipo y comportamiento observado. Ninguna de esas fuentes basta por sí sola. Los archivos de proyecto muestran las referencias declaradas, el registro muestra qué resuelve la máquina de build y la observación en ejecución revela objetos de enlace tardío y procesos externos. Capture las tres mientras todavía funciona el equipo conocido.

En el equipo de build, ejecute estos comandos desde PowerShell y guarde las salidas con la instantánea del código fuente:

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

La primera salida contiene una línea declarada Reference= u Object= con su archivo y número de línea. La segunda ofrece un hash de cada archivo de proyecto. El inventario de productos es imperfecto porque no todas las dependencias usan Windows Installer, pero proporciona un punto de comparación. No ejecute Win32_Product repetidamente en equipos de producción, ya que puede activar comprobaciones de coherencia del instalador. Esta es una captura única en la estación de build aislada.

Añada metadatos de cada DLL y OCX realmente referenciada: ruta original, hash SHA-256, versión de archivo, versión de producto, firmante, arquitectura, origen de la licencia y permiso de redistribución. Exporte las entradas pertinentes del registro COM de 32 bits solo después de resolver cada GUID desde el proyecto. Anote las versiones de clientes de base de datos, controladores ODBC y DSN, variables de entorno, fuentes, configuración regional, controladores de impresora, tareas programadas, recursos compartidos y cuentas de servicio. Los secretos pertenecen al almacén de secretos, no al inventario. Este debe nombrar el secreto y a su propietario sin copiar el valor.

Observe después una ejecución representativa con un monitor de actividad de archivos y registro. Pruebe el inicio, el acceso, una transacción normal, importaciones, exportaciones, informes, impresión, tratamiento de errores y cierre. Compare el acceso observado a archivos, registro, red y procesos con el inventario declarado. Cualquier ProgID de enlace tardío, EXE auxiliar, unidad de red o carpeta de instalación escribible que solo aparezca en ejecución debe entrar en el inventario.

Termine con una instalación limpia. Comience con una imagen desechable y compatible de Windows, aplique solo los requisitos documentados, instale la aplicación y ejecute el recorrido de aceptación. Si un ingeniero debe buscar un control en una estación antigua o recordar un comando de registro no documentado, la aplicación aún no es instalable. Anote el vacío en vez de reparar la imagen a mano y dar la prueba por concluida.

Cuando muere el último equipo de build, el código no basta

Si falla el único equipo cuyo build está probado, el equipo pierde un entorno resuelto, no solo un ordenador. Reconstruirlo implica redescubrir qué medios y Service Pack del compilador se usaron, qué componentes tenían licencia, cómo se resolvían las referencias, qué archivos de compatibilidad binaria fijaban las identidades COM, qué pasos previos o de instalación se ejecutaban y si el repositorio contiene la revisión que produjo la versión en producción.

El primer síntoma suele aparecer durante un cambio urgente. Cambia una regla fiscal, un endpoint, un certificado, una política de contraseñas de base de datos o un formato de archivo. Un ingeniero instala el IDE en una máquina virtual, abre el proyecto, cierra varios avisos de referencias ausentes, sustituye un control no disponible y obtiene una compilación correcta. El ejecutable arranca, así que se despliega. Después falla un formulario poco usado porque el nuevo control serializa las propiedades de otra forma, o un cliente COM no puede crear una clase recompilada cuya identidad de interfaz cambió. Se confundió una compilación correcta con la paridad de comportamiento.

Los controles ActiveX con licencia empeoran la recuperación. Algunos necesitan entradas de licencia de diseño para cargarse en el IDE, aunque la aplicación compilada funcione con una licencia de ejecución. El proveedor puede haber desaparecido, la activación puede no existir y copiar un OCX instalado puede infringir la licencia u omitir datos del registro. Ningún truco de ingeniería arregla la falta de derechos legales. Identifique la titularidad y las condiciones de redistribución mientras aún existan los registros de compras y la memoria del personal.

Una imagen de disco del equipo de build ayuda, pero no es una respuesta completa. Las imágenes conservan estado oculto, credenciales, riesgo de malware y un sistema operativo que acabará siendo inseguro conectar. Tampoco demuestran que un checkout limpio compile. Conserve una imagen restringida como prueba y puente de emergencia, y después cree un build automatizado y aislado a partir de entradas controladas. Si no puede reproducirlo sin la imagen, dígalo claramente en el registro de riesgos.

La descompilación es una técnica de recuperación de último recurso, no un sustituto del control de versiones. Los ejecutables de código nativo pierden nombres y estructura, el p-code plantea otras posibilidades y ninguno recupera de forma fiable comentarios, scripts de build, formularios originales ni intención de diseño. Quizá recupere suficiente comportamiento para investigar un defecto. No base una modernización planificada en la esperanza de volver a convertir un binario en el proyecto original.

Conserve un build antes de cambiar la aplicación

La primera acción más segura consiste en congelar y reproducir el build actual, sin mezclar ese trabajo con nuevas funciones o cambios de migración. Necesita una base cuyas entradas, herramientas, salidas y comportamiento puedan compararse. Cambiar código mientras reconstruye el entorno destruye el punto de referencia.

Capture estos elementos como un paquete controlado:

1. La revisión completa del repositorio, incluidos recursos de formularios, fuentes del instalador y referencias de compatibilidad binaria.
2. Medios de instalación, Service Packs, controles redistribuibles, pruebas de licencia y sumas de comprobación.
3. Un inventario del equipo y una imagen restringida de la estación conocida.
4. Comandos exactos, orden de proyectos, símbolos de compilación condicional y pasos de empaquetado.
5. Hashes de los binarios de producción y un registro firmado de qué build está desplegado en cada lugar.

Ahora haga un checkout y un build limpios en una máquina virtual aislada. Mantenga la red desconectada salvo que una entrada documentada del build la exija. Compare archivos de salida, interfaces COM exportadas y contenido del instalador. La igualdad byte a byte puede ser imposible por marcas de tiempo y metadatos del compilador, así que defina qué significa igualdad antes de aceptar el resultado. Como mínimo, revise versiones, dependencias, identidades de clase y comportamiento con las pruebas de aceptación.

Mantenga un registro pequeño para cada intento. Puede ser JSON, CSV o un documento de texto firmado, pero debe contener revisión del código, identificador de la imagen, hashes de herramientas y dependencias, comandos, operador, fecha, hashes de salida y resultado de las pruebas. El objetivo es la trazabilidad. Seis meses después, otro ingeniero debe poder identificar exactamente qué produjo un ejecutable sin preguntar a la persona que lo creó.

No conecte la máquina virtual rescatada a la red corporativa normal y lo llame continuidad. Un IDE sin soporte y viejos instaladores de terceros amplían la superficie de ataque, mientras que clientes de base de datos antiguos pueden exigir protocolos que ya deberían haberse retirado. Aísle el build, transfiera entradas y salidas mediante controles, analice los artefactos, elimine credenciales permanentes y registre el acceso. Eso compra tiempo. No convierte en sana una cadena de herramientas sin soporte.

La antigüedad no fija por sí sola la fecha de migración

La prioridad de una aplicación VB6 depende de su capacidad de recuperación, presión de cambio y consecuencias del fallo, no de su edad. Dos programas compilados el mismo año pueden merecer decisiones opuestas. Una herramienta de consulta de solo lectura en un equipo aislado quizá tolere la contención, mientras que un cliente de pedidos con cambios semanales de reglas y escrituras directas en producción puede necesitar sustitución antes de la siguiente función.

Valore primero la recuperación. ¿Puede el equipo instalar el paquete publicado en una imagen limpia y compatible de Windows? ¿Puede compilar la revisión desplegada desde un checkout limpio? ¿Están contabilizados todos los controles, licencias y proveedores de datos? ¿Puede publicar una versión más de una persona? Un no al build limpio aumenta la urgencia aunque no existan defectos reportados, porque el plazo del próximo cambio es desconocido.

Después, mida la presión de cambio. Cuente solicitudes reales que requieren código, no el descontento general. Renovaciones de certificados, cambios de API, reglas fiscales, requisitos de autenticación, actualizaciones de base de datos y nuevos formatos consumen la misma cadena de herramientas menguante. Un listado de funciones importa, pero más una modificación externa obligatoria con fecha fija. La aplicación puede estar acabada funcionalmente y aun así recibir cambios impuestos por los sistemas que la rodean.

Las consecuencias necesitan modos de fallo concretos. Pregunte qué ocurre si la aplicación no arranca durante un día, calcula mal, pierde una transacción o no puede instalarse tras sustituir una estación. Nombre el procedimiento manual y pruébelo con el volumen actual. Un plan que depende de una persona jubilada o de una caja de medios sin abrir no puede presupuestarse con seriedad.

La exposición de seguridad también cambia la respuesta. Una herramienta local que lee archivos controlados tiene un riesgo distinto de un cliente que acepta documentos de internet, se conecta con amplios permisos de base de datos o requiere protocolos de red obsoletos. No califique todo software VB6 de inseguro solo por el lenguaje. Siga sus entradas, privilegios, dependencias y rutas de red. El IDE sin soporte debe estar en un entorno de build aislado, con independencia de dónde funcione la aplicación.

Documento la decisión con responsable, fecha de las pruebas y desencadenante, no con un vago estado rojo. La contención puede seguir siendo válida hasta que el sistema anfitrión pierda soporte, no pueda renovarse una licencia, falle el build limpio o una integración identificada anuncie un cambio incompatible. Revise esos desencadenantes. Así evita tanto reescrituras precipitadas como el fallo más habitual: renovar una excepción temporal para siempre sin que nadie asuma el riesgo.

La comparación de costes debe abarcar más que horas de desarrollo. Añada mantener imágenes antiguas, zonas de red restringidas, conocimiento escaso de componentes, despliegue manual, recuperación de incidentes y cambios de negocio retrasados. Para sustituir, incluya conciliación de datos, funcionamiento en paralelo, formación, cambio y retirada. Una estimación honesta aún puede favorecer la contención. No debe borrar el trabajo del sistema antiguo porque figure en operaciones y no en un presupuesto de proyecto.

Las salidas realistas tienen perfiles de riesgo distintos

Hay cinco caminos defendibles, y el adecuado depende del ritmo de cambio, la exposición operativa y cuánto comportamiento pueda observar. Dejarlo como está solo es una decisión cuando el ejecutable tiene una vida restante limitada, el build es recuperable, el anfitrión está controlado y el negocio acepta el plan de fallo. Seguir por inercia no es la misma elección.

Virtualizar conserva un entorno antiguo y puede separarlo de la renovación de estaciones. Resulta útil para herramientas internas que cambian poco, sobre todo con escasa integración de hardware. También congela antiguas debilidades, restricciones de licencia y conocimiento operativo dentro de una imagen. Protege la disponibilidad frente al cambio de un portátil, pero no moderniza la aplicación ni recupera el soporte del proveedor.

Encapsular el sistema VB6 detrás de una API puede reducir el acceso directo a su base y ofrecer a clientes nuevos un límite estable. Funciona cuando el programa antiguo ya expone operaciones de negocio invocables o puede controlarse mediante un adaptador. Funciona mal cuando la automatización depende de tiempos de la interfaz, diálogos modales, archivos compartidos o estado global del equipo. Automatizar la interfaz es un puente temporal con fecha de retirada, no una arquitectura de integración.

La sustitución progresiva mueve una capacidad delimitada cada vez. Puede reducir el riesgo de despliegue cuando las fronteras de módulos son reales y el equipo puede ejecutar rutas antiguas y nuevas a la vez. También puede crear años de escrituras dobles, interop COM, reglas duplicadas y conciliación si las fronteras solo existen en un dibujo. Defina incrementos alrededor de transacciones de negocio observables, no de carpetas de código.

Una reescritura completa está justificada cuando el sistema está muy acoplado, el build falla, la arquitectura objetivo cambia el modelo operativo o mantener dos sistemas supera el riesgo de transición. La objeción habitual dice que una reescritura pierde reglas ocultas. Es cierto cuando el equipo toma el código como especificación y solo prueba casos normales. La reescritura resulta defendible cuando el comportamiento registrado, los datos y casos límite forman un oráculo ejecutable de comparación.

Me opongo a la conversión automática línea por línea. Es popular porque parece conservar el alcance y ofrece un porcentaje medible. Normalmente arrastra estado global, acoplamiento a la interfaz y comportamiento accidental de la base a otro lenguaje, y añade pegamento de interop donde falla. El resultado es arquitectura heredada más difícil de diagnosticar porque ha cambiado la semántica de ejecución conocida. Conserve el comportamiento, no la vieja organización de archivos y formularios.

El comportamiento registrado es el contrato de migración

Una prueba de migración debe comparar efectos de negocio en el límite de una transacción, no solo pantallas o valores devueltos. Para cada operación representativa, capture la petición normalizada, datos iniciales, configuración pertinente, respuestas externas, cambios en base, archivos generados, mensajes y resultado visible. Reproduzca el mismo caso en el sustituto y compare los efectos tras eliminar campos variables como fechas e identificadores generados.

Un caso compacto de paridad puede ser así:

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

El nombre importa menos que la procedencia. Registre qué flujo de producción lo proporcionó, elimine datos personales, versione el conjunto y mantenga determinista la comparación. Muestree casos rutinarios e incómodos: cadenas vacías frente a nulos, decimales locales, días bisiestos, envíos duplicados, tiempos agotados, fallos parciales y reintentos. Las aplicaciones VB6 suelen codificar errores en el orden de eventos y el estado compartido, así que pruebe secuencias además de operaciones aisladas.

Las pruebas de referencia por sí solas pueden conservar errores. Clasifique las diferencias como corrección prevista, variación de representación inocua, comportamiento ausente o defecto de prueba. Un responsable de producto debe aprobar los cambios previstos, porque un ingeniero no puede decidir leyendo código si una regla contable extraña es accidental. Conserve el resultado original junto a la nueva expectativa aprobada para que la decisión sea auditable.

El tráfico de producción ofrece mejor cobertura que casos unitarios inventados cuando puede registrarse de forma legal y segura. CodeHero usa un sistema de paridad con tráfico de producción grabado mientras moderniza la arquitectura en vez de transliterar el código. El principio vale sin un proveedor concreto: capture lo que piden los usuarios, límpielo, reprodúzcalo y compare efectos duraderos.

Elija el destino desde el límite del sistema

El destino debe seguir los límites de despliegue, fallo y propiedad, no las modas de lenguajes. Una aplicación de escritorio que principalmente valida entradas y llama a una base central puede convertirse en un cliente TypeScript, servicios y Postgres. Un módulo intensivo en cálculos puede justificar Rust alrededor de un pequeño núcleo numérico. Un servicio transaccional con concurrencia y operación sencillas puede encajar en Go. Son conclusiones de diseño, no sustituciones automáticas de sintaxis VB6.

Dibuje primero el límite actual de ejecución. Marque qué trabajo debe ocurrir en el equipo del usuario, cuál pertenece cerca de la base, qué integraciones exigen llamadas ordenadas y qué salidas deben seguir siendo compatibles byte a byte. Decida dónde viven identidad, autorización, reintentos y registros de auditoría. Si dos componentes sustitutos deben compartir una transacción de base y desplegarse juntos, llamarlos servicios separados solo ha añadido un modo de fallo de red, no independencia.

La migración de datos necesita la misma disciplina que el código. Conserve identificadores, precisión decimal, codificación, tratamiento de nulos y estados históricos antes de mejorar el esquema. Ejecute consultas de conciliación sobre totales y transiciones, no solo recuentos de filas. Si la aplicación antigua escribe directamente en tablas desde muchos formularios, coloque un límite controlado de escritura antes de dividir la propiedad.

Para un sistema que debe dejar VB6 deprisa, CodeHero lee todo el código, lo reescribe en Go, Rust y TypeScript con Postgres donde corresponda, y entrega cada proyecto en menos de 30 días. Tanto si elige esa ruta como su propio equipo, exija las mismas pruebas: una base de código reproducible, decisiones de arquitectura explícitas y resultados de paridad vinculados a comportamiento registrado.

No espere a que una versión del sistema operativo decida por usted. La compatibilidad de Windows puede mantener vivo el EXE mientras desaparecen el conocimiento del build, los derechos de componentes y la memoria del personal. Demuestre ahora un build limpio, capture el inventario de dependencias y registre transacciones reales. Después elija contención, sustitución progresiva o reescritura mientras el sistema que funciona todavía puede decir exactamente qué debe hacer el nuevo.