Когда-то давно у меня была коллекция старинных версий Windows в виртуалках, и для переноса файлов между хост-машиной и этими виртуалками приходилось использовать дискету, потому что поддержка shared folders появилась только в Windows for Workgroups.
Перенос файлов через дискету был медленным и шумным, и моему восторгу не было предела, когда я нашёл драйвер Virtual Floppy Drive, позволяющий создать «виртуальный флопповод» и подключить его в VM как обычный. К сожалению, интерес автора к своему проекту угас в 2005, а в 2010 его сайт и емейл перестали существовать. С тех пор в мире Windows успело произойти много перемен:
- Повсеместно стала использоваться 64-битная ОС, в которую невозможно загрузить 32-битный драйвер, скомпилированный в 2005;
- Windows начиная с Vista SP1 стала требовать для загрузки драйверов либо цифровую подпись, либо муторные манипуляции, требующие перезагрузку системы;
- Проект, написанный в Visual C++ 6, не собирается в современных версиях Visual Studio после автоматической конвертации.
Уже в 2011 в рассылке разработчиков ReactOS обсуждалось предоставление поддержки заброшенному проекту; но без согласия самого автора это произойти не могло, а автор к тому времени уже несколько лет как не подавал признаков жизни. Тогда же некий Andriy G. Tereshchenko создал неофициальное зеркало vfd.sourceforge.net с копией исчезнувшего сайта автора. Там на SourceForge до сих пор лежит версия 2005 г., и до сих пор постятся жалобы на то, что в Windows 7+ эта версия не работает.
Я захотел продолжить разработку VFD на github.com/tyomitch/vfd; даже если вам равнодушен сам VFD, то мой рассказ может вам помочь в «оживлении» других заброшенных проектов под Windows.
Компиляция
Visual Studio 2019 соглашается открыть vfd.dsw
и сконвертировать составляющие его проекты в современный формат; но конвертация осуществляется не полностью, так что сконвертированные проекты отказываются компилироваться.
Я обнаружил следующие проблемы:
- Некорректно сконвертировался вызов Message Compiler (
mc $(InputName)
) — вместоmc %(Filename)
в VS2019 должно бытьmc %(FullPath)
. Имена производимых файлов для MC ($(InputName).h
и$(InputName).rc
) не сконвертировались вообще; в VS2019 они должны иметь вид%(Filename).h
и%(Filename).rc
. - Имена производимых файлов для Resource Compiler (
$(IntDir)$(InputName).res
) также не сконвертировались; в VS2019 они должны иметь вид$(IntDir)%(Filename).res
. <TargetName>
нужно изменить со значения по умолчанию ($(ProjectName)
) наvfd
для проектаvfdlib
иvfdwin
для проектаvfdwin
, иначе они пытаются собрать файлыlib.dll
иgui.exe
.- Чтобы скомпилировать VFD без zlib, нужно не только добавить к определениям
VFD_NO_ZLIB
, но и убрать#include "zlib.h"
под#ifndef VFD_NO_ZLIB
— автор об этом почему-то забыл; и нужно убратьzlibstat.lib
из<AdditionalDependencies>
.
После этих исправлений успешно собираются 32-битные версии vfd.dll
и vfdwin.exe
; но чтобы собрать 64-битные версии, нужно потрудиться ещё.
Адаптация для x64
Во-первых, сам код несовместим с x64, и в нём нужно заменить
- возвращаемый тип всех
DlgProc
сBOOL
наINT_PTR
; - все вызовы
GetWindowLong(GWL_USERDATA)
наGetWindowLongPtr(GWLP_USERDATA)
и аналогично дляSetWindowLong
и дляDWL_MSGRESULT
иDWL_USER
.
Во-вторых, в настройках сконвертированного проекта не используется $(Platform)
, потому что во времена VC6 платформа могла быть только одной; и поэтому 32-битные и 64-битные файлы пытаются собраться в одни и те же каталоги. Чтобы их развести, надо исправить на $(IntDir)
значения <AssemblerListingLocation>
, <PrecompiledHeaderOutputFile>
, <ObjectFileName>
, <ProgramDataBaseFileName>
; <OutputFile>
для линкера исправить на $(TargetPath)
; и удалить бесполезные <AdditionalLibraryDirectories>
, вручную добавлявшую зависимость между проектами, и <PostBuildEvent>
, вручную копировавшие скомпилированные файлы в целевой каталог.
В-третьих, vfdwin
активно сопротивляется попытке запуска на 64-битной Windows, наравне с попыткой запуска на Windows 95/98/Me. Чтобы это пресечь, надо удалить функцию VfdIsValidPlatform()
и все её упоминания.
Загрузка драйвера
У меня под рукой нет Windows DDK, так что я взял 64-битный vfd.sys
, скомпилированный неким critical0, и попросил dartraiden подписать его «древне-китайским способом». Такой драйвер успешно загружается и работает, если vfdwin
запущена с правами администратора; чтобы это происходило всегда, в её опции линковки нужно добавить <UACExecutionLevel>RequireAdministrator
.
Другой энтузиаст, Igor Levicki, посвятил целый блогпост компиляции vfd.sys
под x64, и утверждает, что его версия vfd.sys
лучше, чем у critical0; но она подписана самодельным сертификатом, и не загружается без дополнительных телодвижений. Кроме самодельного сертификата, честолюбивый Igor Levicki добавил в файл драйвера упоминание себя и своего блога; critical0 такой ерундой не занимался.
Использование
Кроме перечисленных изменений, я лишь заменил в окне About давно мёртвый URL на github.com/tyomitch/vfd, и исправил один баг в оболочке, заметный только при отладочной компиляции: функция VfdGetLocalLink
передаёт параметр типа CHAR
в isalpha()
и сваливается на строке _ASSERTE(c >= -1 && c <= 255);
в стандартной библиотеке. Как объясняли в недавнем хабрапосте, поведение isalpha()
не определено для отрицательных чисел, а CHAR
в Windows как раз знаковый. Судя по тому, что при компиляции выдаётся 141 предупреждение, таких багов в коде может быть ещё немало; так что мне будет чем занять свободные вечера.
Готовые бинарники лежат в github.com/tyomitch/vfd/tree/master/x64/Debug
Автор: Artyom Skrobov