Era uma vez eu tinha uma coleção de versões antigas do Windows em máquinas virtuais e, para transferir arquivos entre a máquina host e essas máquinas virtuais, precisava usar um disquete, porque o suporte a pastas compartilhadas só aparecia no Windows para Workgroups.
A transferência de arquivos via disquete era lenta e barulhenta, e minha empolgação não teve limites quando encontrei o driver da unidade de disquete virtual, que permite criar uma "unidade de disquete virtual" e conectá-la à VM como de costume. Infelizmente, o interesse do autor por seu projeto diminuiu em 2005, e em 2010 seu site e e-mail deixaram de existir. Desde então, muitas mudanças ocorreram no mundo do Windows:
- O SO de 64 bits é amplamente utilizado, no qual é impossível carregar o driver de 32 bits compilado em 2005;
- O Windows a partir do Vista SP1 começou a exigir uma assinatura digital ou manipulações monótonas que exigem a reinicialização do sistema para carregar os drivers;
- Um projeto escrito em Visual C ++ 6 não é criado em versões modernas do Visual Studio após a conversão automática.
Já em 2011, a lista de discussão dos desenvolvedores do ReactOS discutiu o fornecimento de suporte para um projeto abandonado; mas sem o consentimento do próprio autor, isso não poderia acontecer, e naquela época o autor não mostrava sinais de vida por vários anos. Ao mesmo tempo, um certo Andriy G. Tereshchenko criou um espelho não oficial vfd.sourceforge.net com uma cópia do site do autor desaparecido. SourceForge ainda tem a versão 2005 lá, e ainda há reclamações de que esta versão não funciona no Windows 7 ou superior.
Eu queria continuar desenvolvendo VFD em github.com/tyomitch/vfd ; mesmo que você seja indiferente ao próprio VFD, minha história pode ajudá-lo a "reviver" outros projetos abandonados no Windows.
Compilação
O Visual Studio 2019 concorda em abrir
vfd.dswe converter seus projetos constituintes em um formato moderno; mas a conversão está incompleta, então os projetos convertidos se recusam a compilar.
Encontrei os seguintes problemas:
- A chamada Message Compiler (
mc $(InputName)) foi convertida incorretamente - em vez demc %(Filename)no VS2019 deveria sermc %(FullPath). Os nomes dos arquivos produzidos para o MC ($(InputName).he$(InputName).rc) não são convertidos; no VS2019, eles devem ser semelhantes a%(Filename).he%(Filename).rc. - Nomes de arquivos produzidos para Resource Compiler (
$(IntDir)\$(InputName).res) também não foram convertidos; no VS2019 eles devem ser semelhantes$(IntDir)\%(Filename).res. <TargetName>precisa ser alterado de default ($(ProjectName))vfdpara projectvfdlibevfdwinprojectvfdwin, caso contrário, eles tentam construirlib.dllegui.exe.- Para compilar VFD sem zlib, você precisa não apenas adicionar às definições
VFD_NO_ZLIB, mas também remover o#include "zlib.h"sub#ifndef VFD_NO_ZLIB- o autor por algum motivo se esqueceu dele; e precisa ser removidozlibstat.liba partir de<AdditionalDependencies>.
Após essas correções, versões de 32 bits
vfd.dlle vfdwin.exe; mas para construir versões de 64 bits, você precisa trabalhar mais.
Adaptação para x64
Primeiro, o código em si é incompatível com x64, e você precisa substituir
- o tipo de retorno de todos
DlgProcdeBOOLparaINT_PTR; - todas as chamadas
GetWindowLong(GWL_USERDATA)paraGetWindowLongPtr(GWLP_USERDATA)e são semelhantes paraSetWindowLonge paraDWL_MSGRESULTeDWL_USER.
Em segundo lugar, não é utilizado nas configurações do projeto convertido
$(Platform), pois na época do VC6 só poderia haver uma plataforma; e, portanto, os arquivos de 32 bits e 64 bits tentam ser coletados nos mesmos diretórios. Para sua raça, deve ser corrigido nos $(IntDir)valores <AssemblerListingLocation>, <PrecompiledHeaderOutputFile>, <ObjectFileName>, <ProgramDataBaseFileName>; <OutputFile>para o vinculador, corrija para $(TargetPath); e remover o inútil <AdditionalLibraryDirectories>, adicionando manualmente dependências entre projetos e <PostBuildEvent>copiando manualmente os arquivos compilados para o diretório de destino.
Em terceiro lugar, ele
vfdwinresiste ativamente a tentar rodar no Windows de 64 bits, bem como tentar rodar no Windows 95/98 / Me. Para parar isso, você precisa excluir a função VfdIsValidPlatform()e todas as referências a ela.
Download do driver
Não tenho um Windows DDK disponível, então peguei um de 64 bits
vfd.syscompilado por um certo crítico0 e pergunteiDartraidenassine-o na "antiga maneira chinesa". Esse driver carrega e funciona com êxito se vfdwininiciado com direitos de administrador; para que isso sempre aconteça, você precisa adicionar em suas opções de link <UACExecutionLevel>RequireAdministrator.
Outro entusiasta, Igor Levicki, dedicou um post inteiro para compilar
vfd.syspara x64 e afirma que sua versão é vfd.sys melhor do que crítica0; mas é assinado com um certificado caseiro e não carrega sem gestos adicionais. Além do certificado feito em casa, o ambicioso Igor Levicki acrescentou uma menção a si mesmo e a seu blog ao arquivo do driver; critical0 não fez tal absurdo.
Usando
Além das alterações listadas, eu só substituiu o URL morto há muito tempo na janela Sobre a github.com/tyomitch/vfd , e fixa um bug no shell, o que só é percebido durante a compilação de depuração: a função
VfdGetLocalLinkpassa um parâmetro de tipo CHARde isalpha()e despeja em uma linha _ASSERTE(c >= -1 && c <= 255);na biblioteca padrão. Conforme explicado em um habrapost recente , o comportamento isalpha()não é definido para números negativos, mas CHARno Windows é apenas assinado. A julgar pelo fato de que 141 avisos são emitidos durante a compilação, ainda pode haver muitos desses bugs no código; então terei algo a ver com minhas noites livres.
Binários prontos estão em github.com/tyomitch/vfd/tree/master/x64/Debug