Barrapunto

Emular sistemas viejos tiene su interes para los nostálgicos o para los que quires seguir pasando un buen rato con los juegos de MSX, Spectrum, SNES... Pero cuando pretendemos emular un sistema cercano en el tiempo (y en potencia) el resultado final es poco atractivo. Hay pocos éxitos comerciales en esta dirección. Nadie va a querer que su Athlon XP 1800 ejecute bajo linux aplicaciones o juegos de Windows como si este fuera un PII a 300 : /

Y la compatibilidad

En todo caso la palabra "emulación" viene de que "emula" un entorno Windows.

Para usar el VMware no necesitas crear una partición VFAT, el te crea unos ficheros en tu directorio personal en los que 'simula' el sistema de ficheros del SO invitado.

También puedes decirle que use un SO que esté en una partición real, pero no es obligatario.

Yo lo uso para tener varias distribuciones de Linux, FreeBSD, ... en las que probar los programas, algo así como una granja de compilación sin salir de casa, y la verdad es que estoy encantado.

Más info aquí

Hasta hace un par de semanas tenía un PII 450 con 128 megas de ram, mandrake y debian y freeBSD iban bastante bien, aunque se notaba la lentidud, lo mismo pasaba con win98, win2k era demasido lento para usarlo sin volverse loco.

Ahora tengo un Athlon XP 1800+ con 512 megas de RAM y las cosas han mejorado bastante :)

Me parece que lo que tu dices, que las aplicaciones de 16 bits usan una máquina virtual independiente de la del sistema, es el comportamiento del Wine, de OS/2 y de NT.

En realidad la gestión de procesos del Windows 95 y la del Windows 3.x es prácticamente idéntica, sólo que en Windows 3.x la única aplicación que obtenía una máquina virtual própia es la ventana de Ms-DOS, y el planificador no permitía entrar más de dos máquinas virtuales en ready a la vez.

Todo esto estaba perfectamente explicado, con ejemplos prácticos (como ejecutar varias máquinas virtuales concurrentes en Windows 3.11) en el libro "Inside Microsoft Windows 95" (o algo similar, lo leí en la bilbioteca de la Escuela Técnica Superior de Ingeniería de la Universidad Rovira i Virgili de Tarragona).

El problema para que los usuarios migren a Linux es que la mayoría de los programas que usan son para Windows y de muchos no hay alternativas para Linux. Dichos programas no se portaran a Linux mientras no haya una cantidad de usuarios grande, que no usarán Linux mientras no puedan usar esos programas... el circulo vicioso se rompería con un wine funcional. Entonces podrían usar las aplicaciones de Windows con un rendimiento razonable, pudiendo plantearse abandonar Ms-Windows, y al haber muchos más usuarios de Linux, las empresas se plantearán migrar las aplicaciones a Linux para que esos usuarios no migren a aplicaciones alternativas que sean nativas.

No se si me he explicado bien, pero aseguro que si Wine ejecutase todos los juegos para Windows, aúnque el Ms-Office ni tan siquiera arrancase, todos mis amigos usarían exclusivamente Linux.

Yo creo que la mayoría no lo portan porque no pueden. El código de la mayor parte de las aplicaciones informáticas con varios años a sus espaldas es intratable y es más fácil reescribirlo de cero que intentar parchearlo para que soporte otros sistemas.

Yo mismo he tenido que portar una aplicación con sólo un cambio de base de datos, de access a mysql y es una tarea de chinos dependiendo como esté hecha la aplicación.

La única pega de wine es que como no tienen ayuda de M$ y muchas partes de windows no están documentadas hay partes de wine que "intuyen" lo que hace realmente la función del API pero pueden equivocarse, con lo que es bastante más inestable, si cabe, que una aplicación windows compilada con las librerías.

Un ejemplo de un uso del código de wine son los reproductores Aviplay y mplayer que usando las dlls de windows reproducen el video a una velocidad aceptable.

Mi M19 dejó de funcionar hace dos años... :-((((

Salud2 !!!