Once upon a time I had a collection of old versions of Windows in virtual machines, and to transfer files between the host machine and these virtual machines, I had to use a floppy disk, because shared folders support appeared only in Windows for Workgroups.
Transferring files via floppy was slow and noisy, and my excitement knew no bounds when I found the Virtual Floppy Drive driver, which allows you to create a "virtual floppy drive" and connect it to the VM as usual. Unfortunately, the author's interest in his project faded away in 2005, and in 2010 his website and email ceased to exist. Since then, many changes have occurred in the Windows world:
- The 64-bit OS is widely used, into which it is impossible to load the 32-bit driver compiled in 2005;
- Windows starting from Vista SP1 began to require either a digital signature or dreary manipulations that require a system reboot to load drivers;
- A project written in Visual C ++ 6 is not built in modern versions of Visual Studio after automatic conversion.
Already in 2011, the ReactOS developers mailing list discussed providing support for an abandoned project; but without the consent of the author himself, this could not happen, and by that time the author had not shown signs of life for several years. Then a certain Andriy G. Tereshchenko created an unofficial mirror vfd.sourceforge.net with a copy of the disappeared author's website. SourceForge still has version 2005 there, and there are still complaints that this version does not work in Windows 7+.
I wanted to continue developing VFD at github.com/tyomitch/vfd ; even if you are indifferent to VFD itself, then my story can help you to "revive" other abandoned projects under Windows.
Compilation
Visual Studio 2019 agrees to open
vfd.dswand convert its constituent projects to a modern format; but the conversion is incomplete, so the converted projects refuse to compile.
I found the following problems:
- The Message Compiler (
mc $(InputName)) call was converted incorrectly - instead ofmc %(Filename)in VS2019 it should bemc %(FullPath). Names of files produced for the MC ($(InputName).hand$(InputName).rc) do not convert at all; in VS2019 they should be%(Filename).hand%(Filename).rc. - Produced filenames for Resource Compiler (
$(IntDir)\$(InputName).res) were also not converted; in VS2019 they should look like$(IntDir)\%(Filename).res. <TargetName>needs to be changed from default ($(ProjectName))vfdto projectvfdlibandvfdwinprojectvfdwin, otherwise they try to buildlib.dllandgui.exe.- To compile VFD without zlib, you need to not only add to the definitions
VFD_NO_ZLIB, but also remove the#include "zlib.h"sub#ifndef VFD_NO_ZLIB- the author for some reason forgot about it; and needs to be removedzlibstat.libfrom<AdditionalDependencies>.
After these fixes, 32-bit versions
vfd.dlland vfdwin.exe; but to build 64-bit versions, you need to work more.
Adaptation for x64
First, the code itself is incompatible with x64, and you need to replace
- the return type of all
DlgProcfromBOOLtoINT_PTR; - all calls
GetWindowLong(GWL_USERDATA)toGetWindowLongPtr(GWLP_USERDATA)and are similar forSetWindowLongand forDWL_MSGRESULTandDWL_USER.
Secondly, it is not used in the settings of the converted project
$(Platform), because at the time of VC6 there could be only one platform; and therefore 32-bit and 64-bit files try to collect in the same directories. To their breed, must be corrected on the $(IntDir)values <AssemblerListingLocation>, <PrecompiledHeaderOutputFile>, <ObjectFileName>, <ProgramDataBaseFileName>; <OutputFile>for the linker, fix to $(TargetPath); and remove the useless <AdditionalLibraryDirectories>, manually adding dependencies between projects, and <PostBuildEvent>manually copying the compiled files to the target directory.
Thirdly, it
vfdwinactively resists trying to run on 64-bit Windows, as well as trying to run on Windows 95/98 / Me. To stop this, you need to delete the function VfdIsValidPlatform()and all references to it.
Driver download
I don't have a Windows DDK at hand, so I took a 64-bit
vfd.sysone compiled by a certain critical0 and askeddartraidensign it in the "ancient Chinese way". Such a driver loads and works successfully if vfdwinlaunched with administrator rights; for this to always happen, you need to add in its link options <UACExecutionLevel>RequireAdministrator.
Another enthusiast, Igor Levicki, has dedicated an entire blog post to compiling
vfd.sysfor x64, and claims that his version is vfd.sys better than critical0; but it's signed with a homemade certificate and won't load without additional gestures. In addition to the homemade certificate, the ambitious Igor Levicki added a mention of himself and his blog to the driver file; critical0 didn't do such nonsense.
Using
In addition to the above changes, I just replaced the long-dead URL in the About window at github.com/tyomitch/vfd , and fixed one bug in the shell, which is noticeable only during debug compilation: the function
VfdGetLocalLinkpasses a type parameter CHARto isalpha()and dumps on a line _ASSERTE(c >= -1 && c <= 255);in the standard library. As explained in a recent habrapost , the behavior is isalpha()not defined for negative numbers, but CHARin Windows it is just signed. Judging by the fact that 141 warnings are issued during compilation, there may still be a lot of such bugs in the code; so I will have something to do with free evenings
Ready binaries are in github.com/tyomitch/vfd/tree/master/x64/Debug