[Open source, Виртуализация, Visual Studio, C, Разработка под Windows] Вторая жизнь Virtual Floppy Drive
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Когда-то давно у меня была коллекция старинных версий 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
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление разработкой, Карьера в IT-индустрии] Взгляд с позиции работодателя на fullstack и специализацию
- [Go] Go: Как подключить внешнюю библиотеку и исключить ненужные зависимости (перевод)
- [JavaScript] Кастомные методы для массивов в JS
- [JavaScript, ReactJS] Новый механизм JSX трансформации в React 17 Release Candidate
- [IT-компании, Информационная безопасность, Разработка под Windows] Microsoft выпустила инструмент для обновления Defender в образах для установки Windows 10 и Windows Server 2016/2019
- [JavaScript, Программирование, ReactJS] Как использовать Axios в React
- [Godot, Разработка игр] Механики для реализации платформера на Godot engine. 2 часть
- [PHP, Глобальные системы позиционирования, JavaScript, Геоинформационные сервисы] Как высчитать ключи перехода от лобой системы координат к WGS с сантиметровой точностью?
- [Научно-популярное, Космонавтика] Грузовой корабль Cygnus для МКС. 2020 год: 77 всего, 69 успешных, 28 от США
- [Big Data, IT-компании] Data Fest: трек МегаФона по data science
Теги для поиска: #_open_source, #_virtualizatsija (Виртуализация), #_visual_studio, #_c, #_razrabotka_pod_windows (Разработка под Windows), #_abandonware, #_64bit, #_msvc, #_visual_c++, #_perenosimost (переносимость), #_reactos, #_sourceforge, #_open_source, #_virtualizatsija (
Виртуализация
), #_visual_studio, #_c, #_razrabotka_pod_windows (
Разработка под Windows
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:35
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Когда-то давно у меня была коллекция старинных версий Windows в виртуалках, и для переноса файлов между хост-машиной и этими виртуалками приходилось использовать дискету, потому что поддержка shared folders появилась только в Windows for Workgroups. Перенос файлов через дискету был медленным и шумным, и моему восторгу не было предела, когда я нашёл драйвер Virtual Floppy Drive, позволяющий создать «виртуальный флопповод» и подключить его в VM как обычный. К сожалению, интерес автора к своему проекту угас в 2005, а в 2010 его сайт и емейл перестали существовать. С тех пор в мире Windows успело произойти много перемен:
Уже в 2011 в рассылке разработчиков ReactOS обсуждалось предоставление поддержки заброшенному проекту; но без согласия самого автора это произойти не могло, а автор к тому времени уже несколько лет как не подавал признаков жизни. Тогда же некий Andriy G. Tereshchenko создал неофициальное зеркало vfd.sourceforge.net с копией исчезнувшего сайта автора. Там на SourceForge до сих пор лежит версия 2005 г., и до сих пор постятся жалобы на то, что в Windows 7+ эта версия не работает. Я захотел продолжить разработку VFD на github.com/tyomitch/vfd; даже если вам равнодушен сам VFD, то мой рассказ может вам помочь в «оживлении» других заброшенных проектов под Windows. Компиляция Visual Studio 2019 соглашается открыть vfd.dsw и сконвертировать составляющие его проекты в современный формат; но конвертация осуществляется не полностью, так что сконвертированные проекты отказываются компилироваться. Я обнаружил следующие проблемы:
После этих исправлений успешно собираются 32-битные версии vfd.dll и vfdwin.exe; но чтобы собрать 64-битные версии, нужно потрудиться ещё. Адаптация для x64 Во-первых, сам код несовместим с x64, и в нём нужно заменить
Во-вторых, в настройках сконвертированного проекта не используется $(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 =========== Источник: habr.com =========== Похожие новости:
Виртуализация ), #_visual_studio, #_c, #_razrabotka_pod_windows ( Разработка под Windows ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:35
Часовой пояс: UTC + 5