ذات مرة ، كان لدي مجموعة من الإصدارات القديمة من Windows في الأجهزة الافتراضية ، وكان علي استخدام قرص مرن لنقل الملفات بين الجهاز المضيف وهذه الأجهزة الافتراضية ، لأن دعم المجلدات المشتركة ظهر فقط في Windows for Workgroups.
كان نقل الملفات عبر القرص المرن بطيئًا وصاخبًا ، ولم تكن حماسي تعرف أي حدود عندما وجدت برنامج تشغيل محرك الأقراص المرنة الافتراضي ، والذي يسمح لك بإنشاء "محرك أقراص مرنة افتراضي" وتوصيله بجهاز 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. $(IntDir)\$(InputName).resلم يتم أيضًا تحويل أسماء الملفات المنتجة لـ Resource Compiler ( ) ؛ في 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يقاوم بنشاط محاولة التشغيل على Windows 64 بت ، بالإضافة إلى محاولة التشغيل على Windows 95/98 / Me. لوقف هذا ، تحتاج إلى إزالة الوظيفة VfdIsValidPlatform()وجميع الإشارات إليها.
تنزيل برنامج التشغيل
ليس لدي Windows DDK في متناول اليد ، لذلك أخذت نسخة 64 بت
vfd.sysتم تجميعها بواسطة حرجة معينة 0 وسألتdartraidenوقع عليه "بالطريقة الصينية القديمة". يتم تحميل برنامج التشغيل هذا ويعمل بنجاح إذا تم vfdwinتشغيله بحقوق المسؤول ؛ لكي يحدث هذا دائمًا ، تحتاج إلى إضافة خيارات الارتباط الخاصة به <UACExecutionLevel>RequireAdministrator.
متحمس آخر، إيغور Levicki، خصصت ل بلوق وظيفة كاملة ل تجميع
vfd.sysلx64 و والمطالبات التي روايته هو vfd.sys أفضل من critical0. لكنها موقعة بشهادة محلية الصنع ولن يتم تحميلها بدون إيماءات إضافية. بالإضافة إلى الشهادة محلية الصنع ، أضاف الطموح إيغور ليفيكي إشارة عن نفسه ومدونته إلى ملف السائق ؛ حرجة 0 لم تفعل مثل هذا الهراء.
باستخدام
بالإضافة إلى التغييرات المدرجة ، لقد قمت للتو باستبدال عنوان URL الذي توقف منذ فترة طويلة في نافذة "حول" في github.com/tyomitch/vfd ، وقمت بإصلاح خطأ واحد في shell ، والذي يمكن ملاحظته فقط أثناء تجميع تصحيح الأخطاء: تقوم الوظيفة
VfdGetLocalLinkبتمرير معلمة النوع CHARإلى isalpha()سطر _ASSERTE(c >= -1 && c <= 255);في المكتبة القياسية وتفريغها. كما هو موضح في habrapost حديثًا ، isalpha()لم يتم تعريف السلوك للأرقام السالبة ، ولكن CHARفي Windows تم توقيعه للتو. بالحكم على حقيقة أنه تم إصدار 141 تحذيرًا أثناء التجميع ، فقد لا يزال هناك الكثير من هذه الأخطاء في الكود ؛ لذلك سيكون لديّ علاقة بأمسياتي المجانية.
الثنائيات الجاهزة موجودة في github.com/tyomitch/vfd/tree/master/x64/Debug