Вторая жизнь Virtual Floppy Drive

Когда-то давно у меня была коллекция старинных версий Windows ^[1] в виртуалках, и для переноса файлов между хост-машиной и этими виртуалками приходилось использовать дискету, потому что поддержка shared folders появилась ^[2] только в Windows for Workgroups.

Перенос файлов через дискету был медленным и шумным, и моему восторгу не было предела, когда я нашёл драйвер Virtual Floppy Drive, позволяющий создать «виртуальный флопповод» и подключить его в VM как обычный. К сожалению, интерес автора к своему проекту угас в 2005, а в 2010 его сайт и емейл перестали существовать. С тех пор в мире Windows успело произойти много перемен:

• Повсеместно стала использоваться 64-битная ОС, в которую невозможно загрузить 32-битный драйвер, скомпилированный в 2005;
• Windows начиная с Vista SP1 стала требовать для загрузки драйверов либо цифровую подпись, либо муторные манипуляции, требующие перезагрузку системы;
• Проект, написанный в Visual C++ 6, не собирается в современных версиях Visual Studio после автоматической конвертации.

Уже в 2011 в рассылке разработчиков ReactOS обсуждалось ^[3] предоставление поддержки заброшенному проекту; но без согласия самого автора это произойти не могло, а автор к тому времени уже несколько лет как не подавал признаков жизни. Тогда же некий Andriy G. Tereshchenko создал неофициальное зеркало vfd.sourceforge.net ^[4] с копией исчезнувшего сайта автора. Там на SourceForge до сих пор лежит версия 2005 г., и до сих пор постятся жалобы на то, что в Windows 7+ эта версия не работает.

Я захотел продолжить разработку VFD на github.com/tyomitch/vfd ^[5]; даже если вам равнодушен сам 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 ^[6] подписать его «древне-китайским способом». Такой драйвер успешно загружается и работает, если vfdwin запущена с правами администратора; чтобы это происходило всегда, в её опции линковки нужно добавить <UACExecutionLevel>RequireAdministrator.

Другой энтузиаст, Igor Levicki, посвятил целый блогпост ^[7] компиляции vfd.sys под x64, и утверждает, что его версия ^[8] vfd.sys лучше, чем у critical0; но она подписана самодельным сертификатом, и не загружается без дополнительных телодвижений. Кроме самодельного сертификата, честолюбивый Igor Levicki добавил в файл драйвера упоминание себя и своего блога; critical0 такой ерундой не занимался.

Использование

Кроме перечисленных изменений, я лишь заменил в окне About давно мёртвый URL на github.com/tyomitch/vfd ^[5], и исправил один баг в оболочке, заметный только при отладочной компиляции: функция VfdGetLocalLink передаёт параметр типа CHAR в isalpha() и сваливается на строке _ASSERTE(c >= -1 && c <= 255); в стандартной библиотеке. Как объясняли в недавнем хабрапосте ^[9], поведение isalpha() не определено для отрицательных чисел, а CHAR в Windows как раз знаковый. Судя по тому, что при компиляции выдаётся 141 предупреждение, таких багов в коде может быть ещё немало; так что мне будет чем занять свободные вечера.

Готовые бинарники лежат в github.com/tyomitch/vfd/tree/master/x64/Debug ^[10]

Автор: Artyom Skrobov

Источник ^[11]