KomuraSoft LLC
Contáctenos
Menú

¿Hasta cuándo seguirán funcionando las aplicaciones VB6? — Estado del soporte del runtime y un camino práctico hacia la migración a .NET

· · VB6, .NET, C#, Tecnología heredada, Reutilización de activos existentes, Migración, Modernización, 32 bits, Desarrollo Windows, Tabla de decisión, Consultoría técnica

“Este sistema en VB6, ¿hasta cuándo va a seguir funcionando?” — es una de las preguntas más frecuentes en las consultorías sobre sistemas heredados.

La respuesta es sorprendentemente clara: Microsoft ha publicado una política de soporte oficial. Pero su contenido es asimétrico: “el runtime seguirá funcionando durante un tiempo, pero ya no hay respaldo del lado del desarrollo”. Sin entender correctamente esta asimetría, se termina oscilando entre dos conclusiones extremas: “todavía funciona, así que no hay problema” y “hay que reconstruirlo todo ahora mismo”.

En este blog, el artículo “Prolongar la vida y migrar aplicaciones de negocio VB6 / Access — una tabla de decisión entre conservar, envolver y reemplazar” organizó la decisión sobre qué hacer con los activos VB6. Este artículo es su continuación: una vez decidido “reemplazar (migrar)” —o para ayudar a decidirlo—, profundiza en cómo llevar a cabo realmente una migración de VB6 a .NET.

1. Primero, la conclusión

  • El soporte del IDE de VB6 (entorno de desarrollo) terminó el 8 de abril de 2008. Ya no existe ninguna forma compatible de crear o mantener aplicaciones VB6, y Microsoft recomienda encarecidamente reemplazarlas por tecnologías modernas.1
  • El runtime de VB6, en cambio, es compatible “mientras lo sea la versión de Windows con la que se distribuye”. La lista de sistemas operativos cubiertos incluye Windows 11, Windows 10 y Windows Server 2025, y el objetivo es que las aplicaciones existentes simplemente sigan funcionando (It Just Works).2 Dicho de otro modo, la respuesta a “hasta cuándo funcionará” es: solo en cuanto a ejecución, mientras el propio Windows sea compatible.
  • Sin embargo, ese soporte está limitado a atender regresiones graves y problemas de seguridad críticos en aplicaciones existentes. Además, el runtime es exclusivamente de 32 bits, y en Windows de 64 bits solo se admite dentro del entorno WOW64.2
  • El riesgo real no es “que deje de funcionar”, sino perder la capacidad de repararlo. Conseguir y mantener el IDE se vuelve más difícil cada año, el soporte de los proveedores de los controles OCX utilizados se agota, y las personas todavía capaces de escribir VB6 se jubilan o cambian de empleo. Estos tres factores avanzan con independencia de cuánto tiempo se mantenga el soporte de Windows.
  • Existen tres enfoques generales para la migración: reescritura completa, conversión automatizada y migración por etapas. Lo primero que hay que decidir no es el enfoque, sino el inventario: hay que conocer el volumen de pantallas, integraciones externas, controles OCX y declaraciones de API antes de elegir un enfoque.
  • Como lenguaje de destino de la migración, para todo lo que se escriba de nuevo se recomienda C#. Microsoft ha declarado oficialmente que VB.NET (Visual Basic) sigue una trayectoria de diseño estable, sin nueva sintaxis y sin extensión a nuevos tipos de carga de trabajo.3

2. La respuesta precisa a “hasta cuándo funcionará” — cómo leer la política de soporte

La política de soporte de VB6 de Microsoft explica VB6 dividiéndolo en tres componentes.2

Componente Contenido Estado del soporte
IDE de VB6 Entorno de desarrollo (Visual Studio 6.0) Terminó el 8 de abril de 2008
Runtime de VB6 La base de ejecución incluida con el sistema operativo (msvbvm60.dll y otros) Compatible mientras lo sea la versión de Windows con la que se distribuye
Archivos de extensión del runtime Los principales controles OCX (redistribuidos junto con la aplicación) Igual que arriba (la distribución debe correr por cuenta de la propia aplicación)

En la tabla de sistemas operativos cubiertos, Windows 11, Windows 10 y Windows Server de 2012 a 2025 aparecen explícitamente marcados como “runtime: compatible”, “IDE: no compatible”.2

Hay tres puntos clave para leer esto correctamente.

Primero, el soporte del runtime está enteramente subordinado al ciclo de vida de Windows. No existe una fecha independiente llamada “fin del soporte del runtime de VB6”: el fin del soporte de la versión de Windows que se esté usando es, directamente, el plazo.

Segundo, el contenido real del soporte se acerca más a una garantía de que las cosas “sigan funcionando” que a cualquier otra cosa. Lo que se atiende se limita a regresiones graves (cuando una actualización del sistema operativo rompe una aplicación existente) y problemas de seguridad críticos; no incluye investigaciones individuales ni mejoras de funcionalidad.2

Tercero, las aplicaciones VB6 solo podrán seguir existiendo en adelante como procesos de 32 bits. El runtime es exclusivamente de 32 bits, y en sistemas operativos de 64 bits solo se admite dentro del entorno de emulación WOW64.2 En el momento en que surge la necesidad de interoperar con una DLL o un SDK exclusivamente de 64 bits, un único proceso ya no basta por sí solo para resolver la tarea. Tratamos cómo salvar este obstáculo en “Un caso práctico de puente COM: llamar a una DLL de 64 bits desde una aplicación de 32 bits”.

3. “Funcionar” y “poder mantenerse” son problemas distintos

Si se mira solo la política de soporte, puede parecer que “no hay prisa”. Pero en la práctica, el entorno de desarrollo y mantenimiento se derrumba mucho antes que el entorno de ejecución.

  • No se puede conseguir el IDE. El IDE de VB6 no es compatible con los sistemas operativos actuales, y mantener una forma oficial de obtenerlo e instalarlo se vuelve más difícil cada año. No es raro encontrar empresas donde “solo queda una máquina en toda la compañía capaz de hacer correcciones”.
  • El soporte del fabricante para los controles OCX de terceros se ha agotado. La propia política de soporte establece claramente que los controles de terceros son responsabilidad del proveedor.2 Es habitual que los controles OCX de cuadrículas o informes ya no se puedan conseguir, y el criterio que expusimos en “Cómo tratar hoy ActiveX / OCX” se aplica aquí directamente.
  • Las personas capaces de escribirlo desaparecen. No es un problema de la especificación del lenguaje, sino un problema humano. Casi ningún ingeniero nuevo está aprendiendo VB6, así que el número de personas capaces de mantenerlo solo puede disminuir.
  • Los requisitos periféricos chocan con el muro de los 32 bits. Los nuevos SDK de dispositivos, bibliotecas de autenticación e integraciones en la nube asumen cada vez más los 64 bits y .NET, y los requisitos que no se pueden incorporar a un proceso VB6 siguen acumulándose.

En otras palabras, “hasta cuándo funcionará” es solo la mitad del problema. La otra mitad es: “cuando haga falta la próxima corrección, ¿quedarán todavía las personas y el entorno para hacerla?” Los planes de migración deben elaborarse no después de que ocurra un fallo, sino mientras aún existan las personas y el entorno capaces de repararlo.

4. Una tabla de decisión para los enfoques de migración

Incluso una vez decidido “reemplazar”, hay un abanico de formas de llevarlo a cabo. Aquí un resumen de los enfoques principales.

Enfoque Descripción Casos en los que encaja bien Riesgos principales
Reescritura completa Reorganizar las especificaciones y construir de nuevo en .NET Pocas pantallas / se quiere replantear el propio flujo de negocio / las especificaciones se pueden explicar Reglas de negocio ocultas que se pasan por alto, un período de desarrollo en paralelo que se alarga
Herramienta de conversión automatizada Conversión mecánica del código VB6 a código .NET mediante una herramienta, con acabado humano posterior Gran volumen de código en el que se quiere preservar la lógica tal cual / sin cambiar la disposición de las pantallas Calidad y legibilidad del código convertido, trabajo manual que igualmente termina quedando pendiente, coste de la herramienta
Migración por etapas (patrón strangler) Extraer funcionalidades una a una y reemplazarlas en secuencia mientras conviven lo antiguo y lo nuevo El negocio no puede detenerse / hay muchas pantallas y funciones / se quiere repartir el riesgo Complejidad durante el período de convivencia, exige una fuerte capacidad de diseño en la frontera (puntos de integración)
Mantener el estado actual + documentar No migrar; prolongar la vida útil fijando el entorno, haciendo copias de seguridad y documentando Casi no hay solicitudes de cambio / se puede fijar la máquina y el sistema operativo Los riesgos del capítulo anterior no se resuelven (solo se posponen)

Cuál elegir no lo determina únicamente el número de líneas de código. La propia Microsoft, además de sus guías oficiales, orienta hacia socios de actualización y migración (incluidos proveedores de herramientas de migración) para este tipo de proyecto1, por lo que la conversión mecánica es una opción real y viable. No obstante, sea cual sea el enfoque elegido, el inventario del siguiente capítulo es un requisito común.

Cabe señalar que los aspectos prácticos de elegir “mantener el estado actual + documentar” (fijar el entorno de ejecución, copias de seguridad, cómo asumir el riesgo) se tratan en el artículo anterior sobre VB6 / Access.

5. Inventario previo a la migración — qué investigar antes de tocar el código

La precisión de la estimación y de la elección del enfoque dependen ambas de la precisión del inventario. Como mínimo, elabore listas de lo siguiente.

  1. Una lista de pantallas e informes — el número de formularios, las pantallas realmente utilizadas (migrar pantallas no utilizadas es esfuerzo desperdiciado), los tipos de informes y su destino de salida (impresión directa o a través de Excel)
  2. Una lista de integraciones externas — cuál de ADO/DAO/RDO se usa para la base de datos y a qué se conecta, la entrada/salida de archivos, la comunicación serie o por socket, las llamadas a otros sistemas
  3. Una lista de referencias a OCX / ActiveX / COM — se pueden extraer mecánicamente de las referencias del archivo de proyecto (.vbp). La disponibilidad de cada componente y la existencia de alternativas influyen directamente en la elección del enfoque
  4. Una lista de declaraciones de API de Win32 (instrucciones Declare) — clasifique cada una según el uso de la API (impresión, lectura/escritura de archivos INI, manipulación de ventanas, etc.) y si puede sustituirse por una funcionalidad estándar de .NET
  5. Reglas de negocio que solo existen en el código — tratamiento de redondeos, fechas de cierre, excepciones específicas por cliente o proveedor, etc. Los lugares donde “nadie sabe por qué está escrito así” son precisamente el caldo de cultivo de los defectos posteriores a la migración
  6. La disponibilidad de un método de prueba — con qué se comparará el comportamiento migrado para confirmar su corrección. En la mayoría de los casos, contrastar con la salida del sistema anterior (informes, CSV, contenido de la base de datos) es el método de verificación más práctico

Este inventario no se desperdicia aunque finalmente no se elija la reescritura completa. De hecho, es habitual que los resultados del inventario revelen un ángulo para una migración por etapas: “pensábamos que hacía falta una reescritura completa, pero en realidad la lógica central se puede trasladar al lado de la base de datos”, o “basta con migrar antes solo estas diez pantallas para superar el muro de los 64 bits”.

6. Principales puntos de incompatibilidad entre VB6 y .NET

VB6 y VB.NET/C# son lenguajes más alejados entre sí de lo que sus nombres sugieren. Tanto con conversión mecánica como con reescritura manual, las siguientes diferencias siempre exigirán decisiones de diseño.

Área VB6 .NET Notas prácticas
Manejo de errores On Error GoTo / Resume Excepciones estructuradas (Try...Catch) No admite una sustitución directa. Hay que verificar la especificación en todos los puntos donde los errores se “tragaban y se seguía ejecutando”
Tipos Variant, Integer de 16 bits Tipado mayoritariamente estático, Integer de 32 bits Hay que identificar el código que depende de conversiones implícitas. Las diferencias de tamaño de los tipos numéricos son una fuente clásica de errores de compatibilidad
Propiedades predeterminadas Notación abreviada como Text1 = "abc" Eliminadas (se requiere ser explícito) Un punto habitual de mala interpretación por parte de las herramientas de conversión. Preste atención al código donde la distinción entre asignación de objeto y asignación de valor es ambigua
Acceso a datos ADO / DAO / RDO ADO.NET y posteriores Los conceptos de conexión, transacción y cursor son completamente distintos. La capa de datos debe tratarse como algo que hay que rediseñar, no simplemente “convertir”
Pantallas Formularios VB6 + OCX WinForms / WPF Los controles no se corresponden uno a uno. Los OCX como las cuadrículas necesitan que se elija una alternativa
Impresión / dibujo Objeto Printer, dibujo directo sobre el formulario GDI+ / API de impresión Los informes son un área en la que el esfuerzo de migración es difícil de estimar. Cambiar a informes en Excel también es una opción
Inicio / distribución EXE + runtime + registro de OCX También es posible una distribución autocontenida (self-contained) Librarse de operaciones que suponen el registro en el registro de Windows (regsvr32) es una de las ventajas de la migración

Lo importante aquí es no dejarse abrumar por el volumen de incompatibilidades hasta el punto de considerar la reescritura completa como la única opción. Al contrario, el simple hecho de que los activos del lado izquierdo de esta tabla (VB6) todavía funcionen correctamente hoy es, en sí mismo, la mejor especificación disponible para la migración. Hacer funcionar el sistema antiguo en paralelo como una “especificación viva” y contrastar las salidas sobre la marcha es, en la práctica, el camino más fiable.

7. Patrones prácticos de migración por etapas

Cuando se migra sin detener el negocio, la forma en que conviven lo antiguo y lo nuevo se convierte en el elemento central. Aquí tres patrones representativos.

7.1 Migrar primero la capa de datos

En esta configuración, los datos de la aplicación VB6 se migran primero desde un archivo Access o un formato propietario a, por ejemplo, SQL Server, mientras el lado VB6 sigue funcionando simplemente cambiando su destino de conexión. Una vez modernizados primero los datos, las nuevas pantallas (del lado .NET) pueden añadirse de forma incremental, apuntando todas a la misma base de datos. Para los pasos concretos relacionados con Access, consulte el capítulo sobre la actualización (upsizing) del artículo anterior.

7.2 Construir nuevas funciones y pantallas en .NET, conectadas mediante interoperabilidad COM

Esta es una configuración en la que las pantallas VB6 existentes se mantienen tal cual, y se construyen nuevas funciones en .NET para coexistir con ellas. Hay dos direcciones posibles.

  • Llamar a componentes del lado .NET desde VB6: al exponer una clase .NET como COM, VB6 puede referenciarla como un componente COM ordinario. Explicamos cómo exponerla de forma tipada incluso en .NET 8 y versiones posteriores en “Llamar a una DLL de .NET 8 desde VBA de forma tipada — dscom y el TLB”; la misma idea se aplica cuando quien llama es VB6 en lugar de VBA.
  • Llamar a activos del lado VB6 desde .NET: una DLL ActiveX construida en VB6 puede referenciarse desde .NET mediante interoperabilidad COM. Esto se usa cuando se quiere conservar la lógica intacta como bloque y modernizar primero solo las pantallas hacia .NET. Sin embargo, la restricción de los 32 bits sigue presente, así que hay que tratarlo como un puente para el período de migración, no como una solución permanente.

7.3 Separar procesos e integrarlos entre sí

Alojar lo antiguo y lo nuevo en el mismo proceso mediante interoperabilidad COM choca con restricciones relacionadas con la arquitectura (32 bits/64 bits) y con el alcance de los fallos compartidos. Cuando se necesita una nueva funcionalidad de 64 bits, o se quiere aislar los fallos entre lo antiguo y lo nuevo, se separan en procesos distintos y se integran mediante archivos, tuberías con nombre, comunicación por localhost, etc. Hemos resumido las opciones de integración entre procesos en “Una tabla de decisión para IPC en Windows”, y un ejemplo concreto de puente de 32 bits→64 bits en el “Caso práctico de puente COM”.

El principio común a todos los patrones es este: “concentrar la frontera entre lo antiguo y lo nuevo en un único lugar, y fijar el formato de los datos que la cruzan”. Si las fronteras se multiplican de forma dispersa por pantalla o por función, el coste del período de convivencia termina consumiendo el beneficio que se esperaba de la migración.

8. El lenguaje de destino de la migración — ¿C# o VB.NET?

Es tentador suponer que “viniendo de VB6, VB.NET es la elección natural”, pero dada la estrategia de lenguajes actual de Microsoft, no es tan sencillo.

La estrategia de lenguajes oficial posiciona a Visual Basic (VB.NET) como “un lenguaje accesible y familiar que mantiene un diseño estable”, y declara explícitamente que, en principio, las nuevas funciones se limitan al consumo (consumption-only), que no se añadirá nueva sintaxis y que no se extenderá a nuevos tipos de carga de trabajo. Al mismo tiempo, se afirma que continuará la inversión en escenarios centrales como Windows Forms y las bibliotecas, así como las mejoras en la experiencia de desarrollo en Visual Studio.3

Leído desde el punto de vista de la migración, esto se traduce en lo siguiente.

  • Aunque se elija VB.NET, los escenarios existentes (aplicaciones de negocio en WinForms) seguirán funcionando sin problemas en el futuro previsible. Para equipos con muchas personas con experiencia en VB6, donde la cercanía sintáctica reduce el coste de aprendizaje, es una elección razonable.
  • Sin embargo, se recomienda C# como base para todo lo que se escriba de nuevo a partir de ahora. Su lenguaje y su ecosistema siguen evolucionando, y la oferta de ejemplos, bibliotecas y talento se concentra en C#. Es una elección hecha para no repetir dentro de diez años el problema de “no queda nadie que mantenga VB6” convertido en “no queda nadie que mantenga VB.NET”.
  • Como solución intermedia, también se puede recibir la salida de la herramienta de conversión en VB.NET mientras el desarrollo nuevo se escribe en C#. En .NET, los ensamblados de ambos lenguajes pueden referenciarse mutuamente, por lo que mezclar lenguajes en sí mismo no constituye un obstáculo.

Para la elección del framework de interfaz (WinForms / WPF / WinUI), consulte “Una tabla de decisión para WinForms, WPF y WinUI”; para lo que hay que verificar al migrar directamente al .NET actual en lugar de a .NET Framework, consulte la “Lista de verificación previa a la migración de .NET Framework a .NET”. Salvo restricciones impuestas por bibliotecas referenciadas, no hay ninguna buena razón para adoptar deliberadamente .NET Framework 4.8 como nuevo destino al migrar desde VB6.

9. Resumen

  • La respuesta a “hasta cuándo funcionará VB6” es: el runtime es compatible mientras lo sea el propio Windows (incluido Windows 11). Pero el soporte del IDE terminó ya en 2008, por lo que ya no existe ningún respaldo oficial para reconstruir o corregir el código: una situación asimétrica.21
  • El plazo real no lo fija el sistema operativo, sino si siguen disponibles el entorno y las personas necesarios para repararlo. Elabore el plan de migración no después de que ocurra un fallo, sino mientras el sistema antiguo todavía pueda usarse como “especificación viva”.
  • Existen tres enfoques: reescritura completa, conversión automatizada y migración por etapas. Antes de elegir uno, haga un inventario de pantallas, integraciones externas, controles OCX, declaraciones de API y reglas de negocio que solo existen en el código.
  • Para las migraciones que no pueden detener el negocio, utilice la prioridad de la capa de datos, la interoperabilidad COM o la separación de procesos para que convivan lo antiguo y lo nuevo, y concentre la frontera en un único lugar.
  • Para todo lo que se escriba de nuevo, se recomienda C#. La trayectoria estable de VB.NET es política oficial3, y C# tiene ventaja como base para el mantenimiento a largo plazo.

Artículos relacionados

Áreas de consultoría relacionadas

KomuraSoft LLC (合同会社小村ソフト) se encarga del inventario de activos existentes, incluido VB6, y de la elaboración de la estrategia de migración, del diseño e implementación de arquitecturas de convivencia entre lo antiguo y lo nuevo mediante puentes COM y separación de procesos, así como de proyectos de reemplazo progresivo hacia .NET.

Enlaces de referencia

  1. Microsoft Learn, Visual Basic 6.0 Support Announcement. Sobre el hecho de que el soporte del IDE de VB6 / IDE de Visual Studio 6.0 terminó el 8 de abril de 2008, que no existe ninguna forma compatible de crear o mantener aplicaciones VB6, por lo que se recomienda encarecidamente pasar a tecnologías modernas, y que para la migración se ofrecen guías de actualización y socios de migración. ↩ ↩2 ↩3

  2. Microsoft Learn, Support Statement for Visual Basic 6.0 on Windows. Sobre el hecho de que el runtime de VB6 es compatible mientras lo sea la versión de Windows con la que se distribuye, que Windows 11, Windows 10, Windows Server 2025 y otros están incluidos entre los sistemas operativos cubiertos, que el alcance del soporte se limita a regresiones graves y problemas de seguridad críticos, que el runtime es exclusivamente de 32 bits y solo se admite en el entorno WOW en sistemas operativos de 64 bits, y que los controles de terceros son responsabilidad del proveedor. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  3. Microsoft Learn, Annotated Visual Basic language strategy y Microsoft .NET language strategy. Sobre el hecho de que Visual Basic mantiene un diseño estable, que las nuevas funciones se centran en el consumo (consumption-only) evitando añadir nueva sintaxis, que no se extenderá a nuevos tipos de carga de trabajo, y que la inversión en escenarios centrales como Windows Forms y las bibliotecas, así como en la experiencia de Visual Studio, continúa. ↩ ↩2 ↩3

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Las aplicaciones VB6 siguen funcionando en Windows 11?
Sí, están dentro del alcance del soporte. Según la política de soporte de Microsoft, el runtime de VB6 (msvbvm60.dll y archivos relacionados) permanece compatible mientras lo esté la versión de Windows con la que se distribuye, y la lista de sistemas operativos cubiertos incluye Windows 11, Windows 10 y Windows Server 2025. Sin embargo, ese soporte se limita a atender regresiones graves y problemas de seguridad críticos en aplicaciones existentes. Además, el runtime de VB6 es exclusivamente de 32 bits, y en Windows de 64 bits solo se admite dentro del entorno de compatibilidad WOW64.
¿Se puede completar una migración de VB6 a .NET solo con una herramienta de conversión automatizada?
Conviene asumir que no se puede. Las herramientas de conversión pueden reducir el trabajo de reescribir definiciones de pantalla y lógica sencilla, pero cosas como el manejo de errores basado en On Error, el código que depende del tipo Variant o de propiedades predeterminadas, los controles ActiveX y las declaraciones de API de Win32 requieren decisiones de diseño y correcciones humanas. En lugar de llevar la salida bruta de la herramienta directamente a producción, hay que estimar el proyecto completo incluyendo el 'trabajo humano de acabado tras la conversión', y decidir de antemano el método para verificar el resultado convertido, por ejemplo mediante operación en paralelo o comparación de salidas.
¿Conviene elegir VB.NET o C# como destino de la migración?
Para todo lo que se escriba de nuevo, se recomienda C#. La estrategia de lenguajes de Microsoft posiciona a Visual Basic (VB.NET) como un lenguaje que mantiene un diseño estable, y declara explícitamente que no se añadirá nueva sintaxis ni se extenderá a nuevos tipos de carga de trabajo. La inversión en escenarios existentes como Windows Forms continúa, por lo que VB.NET no se vuelve inutilizable, pero como base para código que habrá que mantener durante la próxima década, C# —cuyo lenguaje y ecosistema siguen evolucionando— tiene ventaja a la hora de conseguir talento. Los equipos con muchos desarrolladores con experiencia en VB6 pueden optar razonablemente por pasar por VB.NET dada la cercanía de su sintaxis.
Antes de una reescritura completa, ¿qué hay que hacer primero?
Hay que hacer un inventario antes de escribir una sola línea de código. En concreto: una lista de pantallas e informes, una lista de integraciones externas (bases de datos, archivos, comunicación serie, otros sistemas), una lista de los controles OCX/ActiveX y componentes COM referenciados, una lista de declaraciones de API de Win32 (instrucciones Declare), y un relevamiento de las reglas de negocio que solo existen en el código. Los resultados de este inventario muestran muy a menudo que una migración por etapas —extrayendo solo una parte del sistema, o migrando primero la capa de datos— es más realista que una reescritura completa.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Contactar
Volver al blog