none
Windows 10 y ejecutables en Visual Basic 6 RRS feed

  • Pregunta

  • Hola a todos:

    Llevo varios años desarrollando en lenguaje Visual Basic 6 y entorno Windows XP 32 bits. Me siento cómodo y puedo realizar la mayoría de los proyectos para Pc de sobremesa. Suelo trabajar con capturadoras de vídeo de diferentes fabricantes y uso las librerías Avicap32 de WDM. Los códigos llevan funcionando mas de 10 años sin problemas.

    Exposición del hecho:

    Después de varios meses de pruebas con W10 profesional 32 y 64 bits, he podido constatar que los programas ejecutables desarrollados en entornos XP, en Visual Basic 6, a pesar de que funcionan correctamente con TODAS las versiones de windows (XP, Vista, 7, 8, 8.1), no lo hacen en entornos W10 siempre.

    Da igual si se ensamblan en XP, y después en entorno de W10, se les da permisos de administrador, o/y si se establece compatibilidad de ejecución con  XP SP3, 7 o similar O si por el contrario se ensamblan con VB6 en una máquina con W10, y se les configura de igual manera.

    Aleatoriamente, se llega a la suspensión de la repuesta del programa en ejecución.

    Me explico: El ejecutable en cuestión, realiza una petición a la tarjeta capturadora para visionar la imagen dentro de un picture box, y la grabación del archivo de vídeo en disco para un tiempo en segundos preestablecido. Hasta aquí todo bien, pero si por ejemplo se solicitan 30 segundos de grabación de vídeo, en algunas ocasiones W10 deja el programa en suspenso, y presenta un mensaje del tipo "Este programa ha dejado de funcionar", con las opciones "Cerrar programa" o "Esperar". Lo curioso del caso es que si se deja transcurrir el tiempo de captura de vídeo y de grabación solicitado, W10 libera la "suspensión" del ejecutable y se puede constatar que  el vídeo se ha grabado correctamente. Pero se ha perdido la posibilidad de monitorizar lo que realmente estás grabando en tiempo real (función imprescindible para el usuario). Y el ejecutable sigue plenamente operativo en todas las demás funciones y prestaciones que permita.

    Es más, éste comportamiento se puede provocar (estando el formulario visible pero inactivo) si se pulsan repetidas veces con cualquiera de los dos botones del ratón mientras dura el intervalo de tiempo de la captura de vídeo. No obstante, el ejecutable se recupera después del tiempo solicitado.

    La "suspensión" del ejecutable en VB6 , cuando se produce, siempre ocurre cuando éste realiza la llamada a la librería correspondiente para que W10, se comunique con el Programa Driver de la capturadora, y éste a su vez lo haga con la propia tarjeta física.

    He verificado este comportamiento con diversos modelos de tarjetas capturadoras de vídeo (PCI o PCI express) de distinto fabricantes (Unos muy conocidos y otros menos), con diferentes placas de Hardware de primeras marcas, con equipos potentes y menos potentes. Los drivers de las capturadoras de vídeo también están verificados y funcionan bien. 

    No se trata tampoco de un error de código. El programa en cuestión está funcionado en muchos equipos, durante años y sin problemas constatados ni documentados.

    Se trata de un comportamiento errático y aleatorio.

    Consideraciones:

    Tengo la impresión, quizás errónea, de que cuando un ejecutable de las características descritas (escrito y ensamblado en Visual Basic 6) hace una petición a un dispositivo de captura de vídeo (tarjeta de captura, sintonizador TV, o una web cam), como queda durante un tiempo "parado" a la espera del regreso del flujo de control por parte de W10, una vez ha finalizado la petición de tiempo de captura (30 segundos por ejemplo), el Sistema Operativo W10 debe detectar que el programa no responde ante ningún evento del usuario (están deliberadamente bloqueados) a través del ratón o teclado, y debe interpretar que esta "colgado".

    W10 interviene con su mensaje y bloquea el refresco del visionado en tiempo real de la captura.

    No obstante, como NO está "colgado", transcurrido el tiempo previsto, el flujo de control pasa a la siguiente línea de código (al regresar de la funcíón de librería) y todo vuelve a la normalidad.

    Pregunta:

    ¿Alguien de la comunidad ha detectado comportamientos similares?

    ¿Ha encontrado alguna forma de evitar esta situación?

    Para finalizar, la solución que busco no pasa por reescribir el código nuevamente en una versión de Visual Basic 20??.

    Los nuevos proyectos, algunos, se realizan con herramientas nuevas, pero éste en concreto desearía mantenerlo en el entorno original de VB6 por su tamaño y complejidad.

    Gracias por vuestra atención e interés,

    Agustín (Spain)

    miércoles, 22 de junio de 2016 15:10

Todas las respuestas

  • Proba a correrlo en compatibilidad xp sp3
    jueves, 23 de junio de 2016 1:29
  • Hola:

    Ya comprobé la opción de Compatibilidad con XP SP3 e inclusive 7.

    En ambos modos de compatibilidad, mejora la respuesta a los clicks de ratón, y sólo en algunas ocasiones se produce el mismo comportamiento (es decir: la suspensión del refresco del formulario por parte de W10).

    Por lo que aún siendo una mejora para el usuario, no se trata de una solución completa.

    Sigo pensando que el tema va de la forma con que W10 supervisa los procesos en ejecución.

    Gracias por la sugerencia.

    Agustín 

     

    jueves, 23 de junio de 2016 8:13
  • No se si esto te valdrá:

    Cómo ejecutar aplicaciones antiguas en Windows 10


    Saludos, Javier J

    jueves, 23 de junio de 2016 10:15
  • Muchas gracias por la información.

    La estudiaré y ya te comentaré los resultados que encuentre.

    Saludos, Agustín

    miércoles, 6 de julio de 2016 16:40
  • Buenas Agustín.

    No se si ya has solucionado el problema, pero a mi me pasaba algo parecido al hacer peticiones a SQL y llenar un grid, si devolvía muchos datos, al tardar más de lo normal en llanarse el grid, el w10 me sacaba el mensaje de "esta aplicación no responde"...

    Lo solucioné usando la instrucción "DoEvents" a cada vuelta del recordset, de manera que mi software cede el control al sistema operativo y de este modo w10 no me lo bloquea.

    Cuando dices que está "parado", esperando respuesta de la PCI, ¿a que te refieres?, ¿al debugar sólo lanzas la instrucción y ya se queda esperando respuesta? ¿O tienes puesto un sleep() o usas alguna función recurrente a la espera de respuesta?

    Un saludo,

    Miquel

    • Editado MMaick viernes, 19 de enero de 2018 15:07
    viernes, 19 de enero de 2018 15:07
  • Hola AgustinMV:

    ¿Por qué no te actualizas al Visual Basic .net y te dejas de tanto rollo?

    Saludos

    PD: Sin ofender. ;)




    • Editado Metaconta viernes, 6 de abril de 2018 14:24
    viernes, 6 de abril de 2018 5:00
  • Porque todavia en el mundo hay millones de aplicaciones corriendo con vb6.

    Porque compilando a codigo nativo es mas rapido que .net,porque se escribe menos y hace mas,porque no es tan enmarañado de clases que nunca se usan como bn .net, porque es escalable,porque hay miles de ocx que hacen cosas que en .net son imposibles y un largo etc.mas.

    martes, 10 de abril de 2018 23:31
  • Porque todavia en el mundo hay millones de aplicaciones corriendo con vb6.

    Porque compilando a codigo nativo es mas rapido que .net,porque se escribe menos y hace mas,porque no es tan enmarañado de clases que nunca se usan como bn .net, porque es escalable,porque hay miles de ocx que hacen cosas que en .net son imposibles y un largo etc.mas.

    La razón por la cual Microsoft descontinuó Visual Basic.

    En este artículo vamos a repasar un poco la historia reciente de Microsoft adaptando un post muy interesante de Tim Anderson, adentrándonos en las razones por las cuales Visual Basic 6 ha sido abandonado por Microsoft. En su día, Visual Basic fue el lenguaje de programación más extendido y popular del mundo y aún así Microsoft optó por congelar su continuidad a favor de un Visual Basic nuevo y diferente. A continuación explicaremos por qué Microsoft descontinuó Visual Basic. Hay detalles del artículo original que han quedado desfasados, pero la argumentación de base y toda la polémica en torno a la discontinuidad de Visual Basic y el complejo proceso de migración a .NET para algunos desarrolladores sigue muy vigente.

    Era una historia que sonaba perfecta. Microsoft tenía quizás la mayor comunidad de desarrolladores del mundo enganchados a un lenguaje que a su vez estaba enganchado a Windows. Aún así, Microsoft cogió este activo de valor incalculable y aparentemente lo echó a un lado. Allá por 2002 anunció que el lenguaje iba a ser reemplazado por algo nuevo, diferente e incompatible. Y desde ese día hasta hoy ese hecho ha provocado un estruendo constante. Muchos desarrolladores de Visual Basic reaccionaron con sentimientos que van desde la frustración hasta el resentimiento. Muchos se sintieron incluso traicionados. Ahora viene la explicación.

    Para analizar este suceso tenemos que tener en cuenta tres cosas:

    #1 La API de Windows

    En primer lugar está el tema de la API de Windows. Es el interfaz de programación de bajo nivel en Windows, tal y como se explica en los manuales como el clásico del autor Charles Petzol: Programming Windows. Es mayormente un interfaz de C. Toda herramienta de programación de Windows compila código que hace llamadas a la API de Windows.

    #2 COM, el Component Object Model

    En segundo lugar, está COM, el acrónimo de Component Object Model. ¿Qué es COM? Es en esencia un mecanismo para vincular y unir componentes de software. Es un estándar binario, así que funciona con código compilado en runtime. En realidad COM es una familia de tecnologías. Una de ellas son los controles ActiveX que se encuentran tanto en Internet Explorer y Visual Basic. También está COM automation, que se usa en Microsoft Office y demás para controlar una aplicación de otra. Un tercer estándar COM es OLE (Object Linking and Embedding),  que se usa cuando insertas una hoja de cálculo Excel en un documento Word.

    #3 El framework .NET

    El entorno .NET es el reemplazo de Microsoft para COM. Todos sabemos la lógica detrás de .NET: está un poco desfasado, pero en general es de gran utilidad. COM fue substituido porque fallaba. Es un estándar binario con un acoplado alto, lo que lo hace débil para aplicaciones web. Es altamente complejo, el cual era uno de los motivos principales por los que muchos desarrolladores se estaban pasando de Visual Basic a Java. También tenía problemas de versiones, provocando fallos en el software. En contraste, .NET tiene una arquitectura de acoplamiento bajo, ideal para Internet y aplicaciones móviles. También se ha diseñado para facilitar el desarrollo y tiene muchas funciones de seguridad y de versiones que no eran fáciles de implementar en COM.

    Es difícil subestimar lo que realmente supone el cambio de Microsoft de COM a .NET. Creo que debemos asumir que la empresa no lo hubiera hecho si hubiera tenido una alternativa mejor. Si la política de la industria lo hubiese permitido, podría haber cambiado a JAVA en vez de a .NET, pero el movimiento de alejarse de COM era necesario para que la plataforma de Microsoft siguiese siendo viable.

    Hoy en día, con la familia de tecnologías denominadas Indigo, el alcance de esta medida se hace más aparente. Indigo subsituye a COM+, el servidor de transacciones base de COM que es clave en aplicaciones de empresa distribuidas que funcionan en Windows. Indigo además es el nuevo estándar para web services XML, MSMQ (message queuing o cola de mensajes), gestión de transacciones y objetos remotos, e incluso comunicaciones entre procesos. Indigo está construida en la segunda versión del framework .NET.

    ¿Y qué tiene que ver esto con Visual Basic?

    Bueno ¿Y qué tiene que ver esto con Visual Basic? Asumo que en algún momento, allá por el año 2000, cuando los planes para sacar .NET estaban en ciernes, Microsoft se centró en Visual Basic 6.0 y valoraron qué hacer con él. VB6 fue lanzado en septiembre de 1998, así que en aquél año 2000 ya le tocaba una actualización. En  ese momento, VB6 era un producto extendido, pero también fuente de un descontento considerable. Los desarrolladores se quejaban de su falta de orientación a objetos de forma completa y muchas de sus anomalías. Otro problema era el muro que suponía VB en forma de obstáculo. Algunas de las cosas que se podían hacer en C++ o en Delphi no se podían hacer en VB, a no ser mediante unos hacks monstruosos.

    La verdad es que Visual Basic nunca fue concebida para ser un lenguaje de desarrollo completo. Se había diseñado para ser un lenguaje de composición de alto nivel para componentes de bajo nivel, un lenguaje de cohesión por decirlo de alguna manera. Por esta razón alrededor de Visual Basic se crearon una serie de componentes de mucho éxito por terceros, en us mayoría controles ActiveX. Estos componentes se programaron principalmente usando C++, pero utilizados principalmente desde Visual Basic. Sin ActiveX, Visual Basic tendría una falta de potencia grave.

    Visual Basic obtiene las habilidades de sus componentes  de COM. De hecho, Visual Basic se hizo usando COM. No es un simplemente un buen cliente o servidor COM; es un producto COM. La orientación a objetos de Visual Basic es del tipo de objetos COM, y por eso no realiza herencias (COM está basado en interfaces). Crea un módulo class en VB6, y fíjate en su propiedad Instancia. Prfeieres PublicNotCreatable o GlobalSingleUse? Estos términos tan extraños son características COM. En otras palabras, la tecnología sobre la cual se hizo Visual Basic fue la tecnología que .NET estaba substituyendo. De ninguna forma fácil se podría adaptar VB para convertirse en un lenguaje de .NET.

    Claramente Microsoft tuvo que implementar un nuevo Visual Basic. Sin embargo, tomó la única decisión factible desde mi punto de vista. La empresa creó un producto totalmente nuevo, haciéndolo compatible con VB6 únicamente en aquellos aspectos que se podían sin dañar al nuevo lenguaje. En uno o dos casos mantuvo funciones rotas en VB6 por el bien de la compatibilidad (me viene a la mente el extraño caso del dimensionado de arrays), pero en general hizo todo de cero.  El nuevo producto solucionó muchos de los problemas que se daban en VB6. Se carga la mayoría de las anomalías, soporta la orientación a objetos totalmente, elimina la dependencia de un solo entorno de desarrollo (VB.NET tiene un compilador de comando de linea) y de manera general elimina los muros y los obstáculos, equiparando a VB con cualquier otro lenguaje .NET.

    El problema de la compatibilidad

    Todo esto no ha venido gratis. Se ha pagado un precio muy caro. Pensemos un rato lo que esto ha supuesto. Imagínate que eres una gran empresa que ha usado VB6 para desarrollar aplicaciones que juegan un papel fundamental en tu empresa. Hay cientos de lineas de código de VB6. La arquitectura de la BBDD está basada en ADO, el último modelo de BBDD basado en COM. Y ahora viene Microsoft y dice que VB6 es un callejón sin salida. ¿Qué haces?

    Es un escenario malo, y no poco común. La recomendación oficial de Microsoft es que migres a .NET, o que congeles la aplicación y solo la mantengas, y que hagas las nuevas funciones en .NET usando técnicas de interoperabilidad para integrar lo viejo con lo nuevo. Ninguna de las dos opciones es muy atractiva. Migrar es un esfuerzo mayúsculo, y tus desarrolladores tienen conocimientos en VB6 y COM, no .NET. La interoperabilidad es otra posibilidad, pero a menudo acarrea problemas de rendimiento al igual que otros imprevistos de programación ingeniosa.

    Microsoft ofrece unas herramientas de migración… Francamente pueden ayudar un poco, pero hay muchos problemas intrínsecos. El mayor obstáculo no está en el lenguaje de programación, que convierte bastante bien en la mayoría de los casos. La madre del cordero está en la librería de clases, componentes y el interfaz gráfico. El motor de formularios de Visual Basic no tiene nada que ver con la  librería de formulario de .NET Windows. Los controles ActiveX funcionan hasta un punto en .NET, pero no son óptimos y a menudo causan problemas. Y peor aún, los programas avanzados en VB hacen un uso considerable de ingeniosos trucos  y llamadas API que evidentemente van a tropezar con cualquier herramienta de migración. Por último,  COM tiene una arquitectura totalmente distinta a .NET. ¿Cómo demonios va a rediseñar tu programa una herramienta de migración?

    Factores Mitigantes

    Puede haber factores mitigantes. En general, las aplicaciones que no son visuales se convierten o interoperan más fácilmente que los programas que sí son visuales. Los programas que siguen las mejores prácticas en términos de separar la lógica del negocio de la presentación del código, y que hacen uso de un diseño orientado a objetos son más fáciles de migrar o mantener que aquellas que no sean así. Sin embargo, incluso las aplicaciones mejor programadas siguen teniendo un problema…

    COM no está del todo muerto

    Personalmente me gusta mucho .NET. Mi instinto general a la hora de pensar en el futuro de una aplicación que tengo hecha en VB es hacerla de nuevo en .NET o quizá una aplicación en JAVA para reemplazarla. Sin embargo este enfoque no es siempre realista. Hay otra opción: continuar en VB6. Algunos temen el hecho de que Microsoft haya retirado el soporte. El soporte general se dejó de dar en Marzo de 2005 (nota: en el año 2014 se publicó que el runtime de VB6 tendrá soporte hasta el año 2024, Microsoft informó concretamente que el runtime es aún un componente del sistema operativo Windows 8.1 hasta como mínimo 2024).

    Sin embargo, el verdadero soporte para VB6 está en la comunidad y en la web. A día de hoy se sabe absolutamente todo sobre el producto y sabemos también que VB es muy ampliable: puedes hacer llamadas a la API de Windows, puedes tirar de controles ActiveX, puedes crear DLLs en otros lenguajes y hacer llamadas desde Visual Basic.

    Hasta no hace poco los programadores en Visual Basic se temían que alguna futura versión de Windows no soportara Visual Basic, atando a los desarrolladores de Visual Basic a sistemas operativos antiguos de Windows. Sin embargo, esto ya ha quedado solventado hasta al menos 2024. Microsoft informó concretamente que el runtime es aún un componente del sistema operativo Windows 8.1 hasta como mínimo 2024. En Microsoft no son estúpidos, ¿por qué iban a limitar la adopción de futuras versiones de Windows haciendo que no soportaran aplicaciones hechas en Visual Basic?

    Además, en Microsoft aún se usa Visual Basic. VBA sigue siendo el lenguaje macro de Microsoft Office. Y en realidad Office sigue estando basado en COM y no solo por el código heredado. El entorno .NET no tiene nada equivalente al “Object Linking and Embedding”, que se utiliza mucho en Office. COM no se va a ir ninguna parte de aquí a un unos años por lo menos.

    Tomemos como ejemplo en paralelo el soporte de aplicaciones de 16-bits. Las aplicaciones de 16-bit aún corren en Windows XP, incluso aplicaciones DOS. Sin embargo, no son ejecutables en Windows de 64-bits. No era práctico darle tres niveles de soporte simultáneamente a 16-bits, 32-bits y 64-bits en Windows. Creo que las aplicaciones hechas en VB6 funcionarán mientras exista soporte para aplicaciones de 32-bits en Windows. También creo que Windows de 32-bits tendrá un recorrido más largo que el de 16-bits ya que hay muchísimas aplicaciones por ahí de 32-bits y las ventajas de 64-bits sobre 32-bits no son tan importantes para la mayoría de los usuarios. Las aplicaciones de VB6 funcionarán hasta el 2024 como mínimo, por ejemplo.

    Yo no quiero decir que quedarse en VB6 ahora mismo sea una salida ideal. Está ya muy desfasado en alguna áreas y eso irá a más. Ya los últimos temas de Windows XP no eran soportados por aplicaciones en VB6. Es difícil a día de hoy seguir con VB6. Hacer nuevos desarrollos en VB6 no tiene mucho sentido ya. Otra cosa es que los clientes y las empresas con aplicaciones hechas ya en VB6 no les preocupe mucho todo esto. Solo quieren que su software y sus programas funcionen y punto.

    ¿Qué más podría haber hecho Microsoft?

    Para mi esta es la cuestión principal, cuestión que ha quedado desatendida por todos aquellos que sienten que Microsoft les ha abandonado al descontinuar VB6.

    Microsoft podría haber continuado con COM y no haber creado .NET. Personalmente pienso que esta opción no era viable. Si lo hubiera hecho, la migración de Microsoft a Java y a otras herramientas hubiese sido enorme.

    También podría haber creado un VB7 compatible de forma separada a .NET, como una forma de desarrollo aparte. Esto es lo que sucedió con FoxPro (y el final del camino también le ha llegado).  La principal desventaja aquí es no se hubiese ofrecido una senda de migración clara para aquellos que sí optaron por dar el salto de VB6 a .NET. Si Microsoft hubiera hecho esto nadie se hubiese tomado su estrategia de .NET en serio. O directamente podría haber creado en paralelo VB7 y VB.NET, lo que hubiese conducido a la confusión más absoluta. Podría haber sido una medida para apagar fuegos, pero no hubiese cambiado la dura realidad: un Visual Basic basado en COM no tiene cabida en el mundo de .NET.

    Creo que Microsoft tomó una decisión acertada al congelar VB6. La decisión acertada no implica que no haya creado angustia. Microsoft estaba en una encrucijada, y VB no le iba a ayudar a elegir el buen camino. Esta historia siempre iba a terminar en llanto.

    Si has llegado hasta aquí y estás buscando una alternativa a Visual Basic 6 (VB6) te recomendamos este artículo: Velneo como alternativa a Visual Basic.

    Fuente:

    https://velneo.es/por-que-microsoft-descontinuo-visual-basic/

    Hasta el 2024 como dicen, dejará de ser compatible con los futuros Windows. Además, no debe usarse.

    O renuevas, o mueres.

    VB .net y el más moderno C# es lo que hay. Si es por temas de velocidad, para eso está C++ Win32, que también está en .net, pero como hablabas de velocidad...

    Suerte con VB 6, muerte lenta y dolorosa, a pesar que me piden que haga tutoriales sobre VB 6 para hacer pequeños programas. 

    VB + no será tan largo y durarero como lo es Cobol.

    Espero que lo tengas bien claro la dura realidad.

    Saludos.


    http://electronica-pic.blogspot.com

    viernes, 13 de abril de 2018 8:40
  • El que escribio eso no tiene ni idea de nada,se ve que le daba pereza escribir tutoriales para vb6 y se lanzo ese mamarracho y de paso vender velneo (se ve que como decis que MS es una empresa que quiere ganar dinero pues este personaje tambien !!!!!!)

    La api de windows sigue siendo la misma al bajo nivel,en .net es el framewrok (una capa mas arriba de la api que hace perder tiempo) y en VB6 se accede directo,vb6 trabaja con dlls registradas y con no registradas tambien asi que eso no es problema.

    El modelo com++ sigue vigente,hasta sql en la ultima version y windows 2016 server lo utilizan.

    A sql incluso 2016,oracle y demas con ADO te puedes conectar y no perdes velocidad,ado.net tiene 3 capas arriba del ado normal que lo hacen mas lento.

    Ah !! Y velneo tiene en su motor de compilacion algunas cosas en codigo vb6......

    sábado, 14 de abril de 2018 0:24
  • Buenas:

    Estuvimos hablando este temas unos amigos y yo dentro del BUS.

    El C++ es el mejor preparado que Visual Basic 6 tanto en velocidad como en hacer más cosas.

    El tema de las API de Windows, perfectamente bien se usa en .net, llamándolas, jejejeje. Usar DLL hecho en C++ Win32 cargándola en C#, e incluso en VB 6. Siempre hay trucos del mendruco.

    Total, muchos se pasaron al VB .net, otros como curiosidad, directamente el que quiere Mcirosoft, el snato C#, que a mi me gusta pero sin abandonar C++.

    No quiero abandonar ni a Delphi, ese si que hoy en día solo lo uso para hacer tutoriales con Arduino.

    https://social.msdn.microsoft.com/Forums/es-ES/8264904f-d895-4307-ae26-f0a49a190dc9/tutorial-arduino-delphi-102-y-puerto-serie?forum=devcommes

    Saludos.


    http://electronica-pic.blogspot.com

    sábado, 14 de abril de 2018 10:10
  • C++ es para cosas de bajo nivel por su relacion con assembler,con c++ no se puede hacer un sistema de gestion,no esta preparado para eso,anda rapido cuando se usan modulos en asembler.

    Vb6 esta preparado para todo lo demas e incluso acepta modulos en asembler directamente escritos en un .bas no como C++ que hay que importarlos.

    En net las apis estan encapsuladas en el framework que es una capa mas para llegar a lo mismo,si se llaman con declaraciones a la funcion en cualquier dll no funciona igual porque .net esta preparado para el framework.

    Delphi (o visual pascal porque es eso) es mas anticuado que VB6 y sin embargo tambien se usa y veo que vos tambien lo usas en vez de .net o c# o c++.

    martes, 17 de abril de 2018 22:53
  • ¿Si tan lento es .net o le tienen rabia?

    ¿Por qué Microsoft apuesta por ello?

    Peor aún. ¿Por qué empresas grandes lo compran?


    http://electronica-pic.blogspot.com

    miércoles, 18 de abril de 2018 9:01