Unidad de disquete virtual Second Life

Érase una vez una colección de versiones antiguas de Windows en máquinas virtuales, y tuve que usar un disquete para transferir archivos entre la máquina host y estas máquinas virtuales, porque la compatibilidad con carpetas compartidas solo aparecía en Windows para trabajo en grupo.



La transferencia de archivos a través de un disquete fue lenta y ruidosa, y mi entusiasmo no conoció límites cuando encontré el controlador de la unidad de disquete virtual, que le permite crear una "unidad de disquete virtual" y conectarla a la máquina virtual como de costumbre. Desafortunadamente, el interés del autor en su proyecto se desvaneció en 2005, y en 2010 su sitio web y su correo electrónico dejaron de existir. Desde entonces, se han producido muchos cambios en el mundo de Windows:

• El sistema operativo de 64 bits se usa ampliamente, en el que es imposible cargar el controlador de 32 bits compilado en 2005;
• Windows a partir de Vista SP1 comenzó a requerir una firma digital o manipulaciones aburridas que requieren un reinicio del sistema para cargar controladores;
• Un proyecto escrito en Visual C ++ 6 no se crea en las versiones modernas de Visual Studio después de la conversión automática.

Ya en 2011, la lista de correo de desarrolladores de ReactOS discutió la posibilidad de brindar soporte para un proyecto abandonado; pero sin el consentimiento del propio autor, esto no podría suceder, y en ese momento el autor no había dado señales de vida durante varios años. Al mismo tiempo, un tal Andriy G. Tereshchenko creó un espejo no oficial vfd.sourceforge.net con una copia del sitio web del autor desaparecido. SourceForge todavía tiene la versión 2005 allí, y todavía hay quejas de que esta versión no funciona en Windows 7+.



Quería seguir desarrollando VFD en github.com/tyomitch/vfd ; incluso si eres indiferente al VFD en sí, entonces mi historia puede ayudarte a "revivir" otros proyectos abandonados en Windows.

Compilacion

Visual Studio 2019 se compromete a abrir vfd.dswy convertir sus proyectos constituyentes a un formato moderno; pero la conversión es incompleta, por lo que los proyectos convertidos se niegan a compilar.



Encontré los siguientes problemas:

• La llamada de Message Compiler ( mc $(InputName)) se convirtió incorrectamente , en lugar de mc %(Filename)en VS2019 debería ser mc %(FullPath). Los nombres de los archivos producidos para el MC ( $(InputName).hy $(InputName).rc) no se convierten en absoluto; en VS2019, deberían verse como %(Filename).hy %(Filename).rc.
• Los nombres de archivo producidos para Resource Compiler ( $(IntDir)\$(InputName).res) tampoco se convirtieron; en VS2019 deberían verse así $(IntDir)\%(Filename).res.
• <TargetName>debe cambiarse de default ( $(ProjectName)) vfda project vfdliby vfdwinproject vfdwin, de lo contrario, intentan construir lib.dlly gui.exe.
• Para compilar VFD sin zlib, no solo debe agregar a las definiciones VFD_NO_ZLIB, sino también eliminar el #include "zlib.h"sub #ifndef VFD_NO_ZLIB- el autor por alguna razón se olvidó de esto; y debe ser eliminado zlibstat.libde <AdditionalDependencies>.

Después de estas correcciones, las versiones de 32 bits vfd.dlly vfdwin.exe; pero para construir versiones de 64 bits, necesita trabajar más.

Adaptación para x64

Primero, el código en sí es incompatible con x64, y debe reemplazarlo

• el tipo de retorno de todo DlgProcdesde BOOLhasta INT_PTR;
• todas las llamadas GetWindowLong(GWL_USERDATA)a GetWindowLongPtr(GWLP_USERDATA)y son similares para SetWindowLongy para DWL_MSGRESULTy DWL_USER.

En segundo lugar, no se utiliza en la configuración del proyecto convertido $(Platform), porque en el momento de VC6 solo podía haber una plataforma; y por lo tanto, los archivos de 32 y 64 bits intentan recopilarse en los mismos directorios. Para su raza, deben ser corregidos en los $(IntDir)valores <AssemblerListingLocation>, <PrecompiledHeaderOutputFile>, <ObjectFileName>, <ProgramDataBaseFileName>; <OutputFile>para el enlazador, fije a $(TargetPath); y elimine lo inútil <AdditionalLibraryDirectories>, agregue manualmente dependencias entre proyectos y <PostBuildEvent>copie manualmente los archivos compilados en el directorio de destino.



En tercer lugar, se vfdwinresiste activamente a intentar ejecutarse en Windows de 64 bits, así como a intentar ejecutarse en Windows 95/98 / Me. Para detener esto, debe eliminar la función VfdIsValidPlatform()y todas las referencias a ella.

Descarga del controlador

No tengo un DDK de Windows a mano, así que tomé uno de 64 bits vfd.syscompilado por un crítico0 y preguntédartraidenfírmelo al "estilo chino antiguo". Dicho controlador se carga y funciona correctamente si se vfdwininicia con derechos de administrador; para que esto suceda siempre, debe agregar sus opciones de enlace <UACExecutionLevel>RequireAdministrator.



Otro entusiasta, Igor Levicki, ha dedicado una publicación de blog completa a la compilación vfd.syspara x64 y afirma que su versión es vfd.sys mejor que la crítica0; pero está firmado con un certificado hecho en casa y no se cargará sin gestos adicionales. Además del certificado hecho en casa, el ambicioso Igor Levicki agregó una mención de sí mismo y de su blog al archivo del conductor; critic0 no hizo esas tonterías.

Utilizando

Además de los cambios mencionados, Acabo de cambiar la URL largo muertos en la ventana Acerca de github.com/tyomitch/vfd , y se fija un error en la cáscara, que es perceptible solamente durante la compilación de depuración: la función VfdGetLocalLinkpasa un parámetro de tipo CHARa isalpha()y vuelca en una línea _ASSERTE(c >= -1 && c <= 255);en la biblioteca estándar. Como se explica en un habrapost reciente , el comportamiento isalpha()no está definido para números negativos, pero CHARen Windows solo está firmado. A juzgar por el hecho de que se emiten 141 advertencias durante la compilación, todavía puede haber muchos errores de este tipo en el código; así tendré algo que ver con mis tardes libres.



Los binarios listos están en github.com/tyomitch/vfd/tree/master/x64/Debug