إلى متى ستستمر تطبيقات VB6 في العمل ── وضع دعم بيئة التشغيل والمسار العملي للترحيل إلى .NET

«إلى متى سيستمر هذا النظام المبني بـ VB6 في العمل؟» — هذا أحد الأسئلة الأكثر تكراراً في استشارات الأنظمة القائمة.

الإجابة أوضح مما يُتوقَّع: أصدرت مايكروسوفت سياسة دعم رسمية. لكن مضمونها غير متماثل: «بيئة التشغيل ستستمر في العمل لفترة. أما سند التطوير فلم يعد موجوداً». ومن دون فهم هذا عدم التماثل بشكل صحيح، ينتهي الأمر بالتأرجح بين استنتاجين متطرفين: «ما زال يعمل، فلا داعي للقلق» و«يجب إعادة بناء كل شيء الآن فوراً».

في هذه المدوّنة رتّبنا في مقال «إطالة عمر تطبيقات VB6 / Access وترحيلها ── جدول قرار الإبقاء والتغليف والاستبدال» القرار الخاص بـكيفية التعامل مع أصول VB6. يأتي هذا المقال استكمالاً له، ليتعمّق فيما يجب فعله فعلياً بعد اتخاذ قرار «الاستبدال (الترحيل)» — أو من أجل اتخاذه — أي كيفية تنفيذ الترحيل من VB6 إلى .NET عملياً.

المصطلحات المستخدمة في هذا المقال

قد يوجد قرّاء لا يعرفون جيل VB6 مباشرة، لذا نرتّب المصطلحات أولاً.

1. الخلاصة أولاً

• انتهى دعم بيئة تطوير VB6 (IDE) في 8 أبريل 2008. لم تعد هناك وسيلة مدعومة لإنشاء تطبيقات VB6 أو صيانتها، وتوصي مايكروسوفت بشدّة باستبدالها بتقنيات حديثة.³
• في المقابل، تبقى بيئة تشغيل VB6 مدعومة «طوال فترة دعم إصدار Windows الذي تُشحَن معه». تشمل قائمة أنظمة التشغيل المستهدَفة Windows 11 وWindows 10 وWindows Server 2025، والهدف أن تستمر التطبيقات القائمة في العمل كما هي (It Just Works).⁴ بعبارة أخرى، الإجابة عن سؤال «إلى متى سيعمل» هي: من ناحية التشغيل فقط، طالما استمر دعم Windows نفسه.
• غير أن نطاق هذا الدعم يقتصر على معالجة الانحدارات الخطيرة والمشكلات الأمنية الحرجة في التطبيقات القائمة. كما أن بيئة التشغيل مخصّصة لـ32bit فقط، وعلى Windows 64bit لا تُدعَم إلا داخل بيئة WOW64.⁴
• الخطر الحقيقي ليس «توقّف العمل»، بل فقدان القدرة على الإصلاح. الحصول على بيئة التطوير والحفاظ عليها يزداد صعوبة عاماً بعد عام، ودعم مورّدي OCX التي يعتمد عليها التطبيق ينقطع، والأشخاص القادرون على الكتابة يتقاعدون. هذه العناصر الثلاثة تتقدّم بمعزل عن فترة دعم Windows.
• توجد ثلاثة مسارات رئيسة لتنفيذ الترحيل: إعادة الكتابة الكاملة، والتحويل الآلي، والترحيل المرحلي. أول ما يجب تحديده ليس الأسلوب، بل الجرد، إذ يجب فهم عدد الشاشات والتكاملات الخارجية وكمية عناصر OCX وإعلانات API قبل اختيار الأسلوب.
• بالنسبة للغة الهدف، يُنصَح باستخدام C# لكل ما يُكتب من جديد. صرّحت مايكروسوفت رسمياً بأن VB.NET (Visual Basic) على مسار استقرار، ولن تُضاف إليها صياغات نحوية جديدة ولن تتوسّع نحو أحمال عمل جديدة.⁵

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 22، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. الإجابة الدقيقة عن «إلى متى سيعمل» ── كيفية قراءة سياسة الدعم

تشرح سياسة دعم VB6 من مايكروسوفت VB6 بتقسيمه إلى ثلاثة عناصر.⁴

في جدول أنظمة التشغيل المستهدَفة، يُذكر صراحة لـ Windows 11 وWindows 10 وWindows Server من 2012 إلى 2025 أن «بيئة التشغيل: مدعومة» و«بيئة التطوير: غير مدعومة».⁴

توجد ثلاث نقاط أساسية لقراءة هذا بشكل صحيح.

أولاً، دعم بيئة التشغيل تابع كلياً لدورة حياة Windows. لا يوجد تاريخ مستقل يُسمّى «تاريخ انتهاء دعم بيئة تشغيل VB6»؛ فانتهاء دعم إصدار Windows المستخدم هو الموعد النهائي بحد ذاته.

ثانياً، مضمون الدعم أقرب إلى ضمان «استمرار العمل». ما يُعالَج يقتصر على الانحدارات الخطيرة (حين يُفسد تحديث نظام التشغيل تطبيقاً قائماً) والمشكلات الأمنية الحرجة فقط، ولا يشمل التحقيقات الفردية أو تحسينات الميزات.⁴

ثالثاً، لن تتمكّن تطبيقات VB6 من العيش مستقبلاً إلا كعمليات 32bit. بيئة التشغيل مخصّصة لـ32bit فقط، وعلى أنظمة التشغيل 64bit لا تُدعَم إلا داخل بيئة محاكاة WOW64.⁴ فور ظهور الحاجة إلى التكامل مع DLL أو SDK مخصّص لـ64bit فقط، لن تعود عملية واحدة كافية لإنجاز المهمة بمفردها. تناولنا كيفية تجاوز هذا الحاجز في «مثال عملي على جسر COM لاستدعاء DLL بصيغة 64bit من تطبيق 32bit».

3. «يعمل» و«يمكن إبقاؤه» مشكلتان مختلفتان

إذا نظرتم إلى سياسة الدعم وحدها بدا أنه «لا حاجة إلى الاستعجال». لكن في العمل اليومي تنهار بيئة التطوير والصيانة قبل بيئة التشغيل.

• تعذّر توفير IDE. VB6 IDE خارج نطاق الدعم على أنظمة التشغيل الحالية، والحفاظ على وسيلة رسمية للحصول عليه وتثبيته يزداد صعوبة عاماً بعد عام. حالة «لا توجد إلا جهاز واحد داخل الشركة يمكن الإصلاح عليه» ليست نادرة.
• انقطاع دعم مورّدي OCX من أطراف ثالثة. تنص سياسة الدعم أيضاً على أن عناصر التحكّم من صنع طرف ثالث تقع في نطاق مسؤولية المورّد.⁴ حالات تعذّر الحصول أصلاً على OCX الشبكة أو التقارير كثيرة، وينطبق على هذا الحكم كما هو ما رتّبناه في «كيف نتعامل مع ActiveX / OCX اليوم».
• اختفاء من يستطيع الكتابة. ليست مشكلة مواصفات لغة بل مشكلة أشخاص. يكاد لا يُورَّد مهندسون يتعلّمون VB6 من جديد، لذا ينخفض عدد القادرين على الصيانة رتيباً.
• المتطلبات المحيطة تصطدم بحاجز 32bit. تصبح مجموعات تطوير الأجهزة الجديدة ومكتبات المصادقة والربط السحابي مفترِضة لـ64bit أو لـ.NET، فتزداد المطالب التي لا يمكن إدخالها في عملية VB6.

أي أن «إلى متى سيعمل» نصف المسألة فقط. النصف الآخر هو «هل تبقى هيئة قادرة على الإصلاح عندما تلزم التعديل التالية». يجب وضع خطة الترحيل لا بعد وقوع العطل، بل بينما ما يزال الأشخاص والبيئة القادرون على الإصلاح موجودين.

4. جدول قرار أساليب الترحيل

حتى بعد قرار «الاستبدال»، يتّسع نطاق كيفية المضي. نرتّب الأساليب الرئيسة.

ما يُختار لا يُحدَّد بعدد أسطر الكود وحده. مايكروسوفت نفسها ترشد عند الترحيل إلى استخدام أدلة رسمية وشركاء ترقية وترحيل (بما في ذلك مورّدي أدوات الترحيل)³، وخيار التحويل الآلي موجود فعلاً. غير أن الجرد في الفصل التالي لازم مشتركاً لأي أسلوب.

4.1 ما المقصود عملياً بـ«أداة التحويل»

كتبنا «أداة تحويل آلي» جملة واحدة، لكن مايكروسوفت تنشر صفحة ترشد بأسماء منتجات شركاء VB6. موقعها «أدوات وحلول مجانية ومدفوعة من شركاء تدعم ترحيلاً أكثر اكتمالاً من Visual Basic 6.0 إلى Visual Basic .NET»، وتُذكر الثلاثة التالية.⁶

ما سبق تلخيص للشرح الوارد في صفحة مايكروسوفت، وليس توصية أو ضماناً من شركتنا. يجب أن يتم الاختيار حتماً بعد التجربة على كودكم. الجوانب التي ينبغي النظر إليها كما يلي.

«إمكان التكرار» الأخير جانب يسهل إغفاله. أثناء فترة الترحيل تدخل أيضاً استجابات أعطال في جانب VB6. إذا كانت الأداة لا تستطيع إلا تحويلاً مرة واحدة، ستظلّون تدخلون ذلك التعديل يدوياً في القديم والجديد معاً.

أما الجانب العملي عند اختيار «الإبقاء مع التوثيق» (تثبيت بيئة التشغيل، والنسخ الاحتياطي، وكيفية تحمّل المخاطر) فقد تناولناه في مقال VB6 / Access السابق.

5. الجرد قبل الترحيل ── ما يُبحث فيه قبل الكود

دقة التقدير واختيار الأسلوب تُحدَّد بدقة الجرد. كحد أدنى اسردوا ما يلي.

1. قائمة الشاشات والتقارير ── عدد النماذج، والشاشات المستخدمة فعلاً (ترحيل شاشة غير مستخدمة هدر)، وأنواع التقارير وجهة الإخراج (طباعة مباشرة على الطابعة أم عبر Excel)
2. قائمة التكاملات الخارجية ── قواعد البيانات (أي من ADO/DAO/RDO، وما جهة الاتصال)، وإدخال الملفات وإخراجها، والاتصال التسلسلي والمقابس، واستدعاء أنظمة أخرى
3. قائمة مراجع OCX / ActiveX / COM ── يمكن استخراجها آلياً من مراجع ملف المشروع (.vbp). إمكان الحصول على كل مكوّن ووجود بديل يرتبط مباشرة باختيار الأسلوب
4. قائمة إعلانات Win32 API (عبارات Declare) ── صُنّفوا حسب غرض API (طباعة، قراءة INI وكتابته، تشغيل النوافذ، إلخ) ما إذا كان يمكن استبداله بميزة قياسية في جانب .NET
5. قواعد العمل التي لا توجد إلا في الكود ── معالجة الكسور، وإغلاق التواريخ، والاستثناءات حسب الشريك، إلخ. المواضع التي «لا أحد يعرف لماذا كُتبت هكذا» هي مرتع الأعطال بعد الترحيل
6. وجود وسيلة اختبار ── بماذا ستقارنون صحة الترحيل. في حالات كثيرة يصبح مطابقة مخرجات النظام القديم (تقارير، CSV، محتوى قاعدة البيانات) أكثر وسائل التحقّق عملية

هذا الجرد لا يضيع حتى إن لم تختاروا إعادة الكتابة الكاملة. بالعكس، من العادي أن تكشف نتيجته مداخل ترحيل مرحلي مثل «ظننّا أنها إعادة كتابة كاملة، لكن منطق النواة يمكن إزاحته إلى جانب قاعدة البيانات» أو «إذا نقلنا هذه الشاشات العشر أولاً تجاوزنا حاجز 64bit».

5.1 مضمون «يمكن استخراجها آلياً» ── حصر المكوّنات المشار إليها من .vbp

كتبنا في البند الثالث «يمكن استخراجها آلياً من مراجع .vbp». نعرض الطريقة عملياً.

ملف المشروع (.vbp) ملف نص ASCII. تحمل وثائق مايكروسوفت الرسمية أيضاً مثالاً لمحتواه، وتُسجَّل إعدادات المراجع كسطر بالشكل التالي.⁷

Type=Exe
Form=B_Form.frm
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\WINDOWS\SYSTEM\STDOLE2.TLB#OLE Automation
Form=A_Form.frm
Module=CModule; C_Module.bas
Class=DClass; D_Class.cls
Startup="BForm"
Name="Project1"

قيمة Reference= مفصولة بـ #، وتترتّب GUID (معرّف مكتبة الأنواع) ← الإصدار ← الإعدادات المحلية ← مسار الملف ← الوصف (اسم المكتبة). في المثال أعلاه يقع OLE Automation في الوصف. عناصر تحكّم ActiveX (OCX) الملصقة على الشاشة تُسجَّل كسطر Object=، فإذا جمعتم هذين النوعين من الأسطر حصلتم على «قائمة المكوّنات الخارجية التي يعتمد عليها هذا المشروع».

في نظام فيه عشرات المشاريع، تُشفط دفعة واحدة بنص برمجي مثل التالي.

# フォルダー配下の全 .vbp から、参照している部品の行を抜き出してCSVにする
# 動作環境: Windows PowerShell 5.1
Get-ChildItem -Path . -Filter *.vbp -Recurse | ForEach-Object {
    $project = $_.FullName
    Get-Content -LiteralPath $project | Where-Object {
        $_ -like 'Reference=*' -or $_ -like 'Object=*'
    } | ForEach-Object {
        $kind, $value = $_ -split '=', 2
        [pscustomobject]@{
            Project = $project
            # Reference = 参照設定したタイプライブラリ / Object = 画面に貼ったActiveXコントロール
            Kind    = $kind
            Entry   = $value
        }
    }
} | Sort-Object Kind, Entry | Export-Csv .\vb6-components.csv -NoTypeInformation -Encoding UTF8

إذا رتّبتم CSV الناتج بعد إزالة التكرار، صارت «على أي مكوّنات COM يعتمد هذا النظام في النهاية» قائمة في نصف يوم. بعد ذلك يكفي ملء كل بند: هل يمكن الحصول عليه، هل يوجد دعم مورّد، هل يوجد بديل في جانب .NET. يصبح هذا الجدول كما هو أساس اختيار الأسلوب والتقدير في الفصل 4.

بالفكرة نفسها يمكن صنع قائمة عبارات Declare أيضاً بجمع الأسطر التي تضم Declare عبر .bas / .frm / .cls. ما ينبغي الاعتماد فيه على العمل اليدوي في الجرد هو «قواعد العمل التي لا توجد إلا في الكود» فقط، وما عداه يمكن أتمتته تقريباً.

5.2 كيفية تقدير الجهد والمدة

رقم من نوع «كم يوماً لكل شاشة» يتغيّر بسهولة مرتبة كاملة بحسب تعقيد الشاشة ووجود OCX وكثافة منطق العمل وصرامة الاختبار المطلوب. جلب أرقام حالات شركات أخرى كما هي لا يصيب. بدل ذلك نضع إجراء لصنع أرقامكم.

1. عُدّوا. في الجرد ثبّتوا عدد الشاشات والتقارير والتكاملات الخارجية وأنواع OCX وعدد عبارات Declare وعدد الجداول.
2. صنّفوا حسب الصعوبة. قسّموا الشاشات تقريباً إلى ثلاث درجات (شاشة قائمة/مرجع بسيطة / شاشة فيها إدخال وتحقّق / شاشة تضم شبكة أو معاينة تقرير).
3. جرّبوا ترحيل شاشة واحدة من كل درجة فعلياً (تجربة أولية). قيسوا الوقت الفعلي بما يشمل التصميم والتنفيذ واختبار الوحدة ومطابقة المخرجات مع النظام القديم. هنا يصير سعر وحدة التقدير.
4. اضربوا واجمعوا. اضربوا سعر الوحدة من 3 في أعداد 2 واجمعوا.
5. أضيفوا إطاراً منفصلاً. الأجزاء المشتركة (المصادقة، السجلات، أساس الطباعة، التوزيع، بناء البيئة) ووقت فك «قواعد العمل التي لا توجد إلا في الكود» لا تتناسب مع عدد الشاشات. التقدير الذي يُسقط هذا الإطار المنفصل ينقص حتماً.
6. إن لم يتوافق ارجعوا إلى الأسلوب. إذا كان القياس الفعلي للتجربة الأولية أسوأ بكثير من المتوقع، فهذه ليست خطأ تقدير بل إشارة خطأ في اختيار الأسلوب. ارجعوا إلى الفصل 4 وأعيدوا اختيار إعادة الكتابة الكاملة أو التحويل الآلي أو الترحيل المرحلي.

الخلاصة وضع أساس التقدير لا على أرقام حالات شركات أخرى بل على قياسكم الفعلي في التجربة الأولية. اعتبروا التجربة الأولية استثماراً لشراء دقة التقدير، لا تكلفة.

6. نقاط عدم التوافق الرئيسة بين VB6 و.NET

VB6 وVB.NET/C# أبعد مما يوحي به الاسم. سواء في التحويل الآلي أو إعادة الكتابة اليدوية، تحتاج الفروق التالية حتماً إلى قرار تصميم.

المهم هنا ألا تُغلبوا بكثرة عدم التوافق فتظنوا إعادة الكتابة الكاملة الخيار الوحيد. بالعكس، واقع أن أصول الجانب الأيسر من هذا الجدول (VB6) ما تزال تعمل بشكل صحيح هو أفضل مواصفات عند الترحيل. الأسلوب الأوثق عملياً تشغيل النظام القديم على التوازي بوصفه «مواصفات حية»، والمضي مع مطابقة المخرجات.

7. أنماط عملية للترحيل المرحلي

عند الترحيل دون إيقاف العمل يلزم تكوين تعايش بين القديم والجديد. نذكر ثلاثة أنماط ممثلة. الفرق بكلمة هو «أين تضعون الحد بين القديم والجديد».

flowchart TB
    subgraph P1["7.1 نقل طبقة البيانات أولاً ── الحد هو قاعدة البيانات"]
      A1["تطبيق VB6 ── يُبدَّل جهة الاتصال فقط"] --> DB["قاعدة البيانات بعد الترحيل ── SQL Server ونحوه"]
      A2["شاشات .NET الجديدة ── تُزاد تدريجياً"] --> DB
    end
    subgraph P2["7.2 الربط عبر COM interop ── الحد واجهة COM، العملية نفسها"]
      B1["تطبيق VB6 ── عملية 32bit"] --- B2["واجهة COM"]
      B2 --- B3["مكوّن .NET ── يلزم بناؤه بـ32bit"]
    end
    subgraph P3["7.3 فصل العمليات ── الحد IPC، عمليات منفصلة"]
      C1["تطبيق VB6 ── عملية 32bit"] --- C2["أنبوب مسمّى / ملف / اتصال localhost"]
      C2 --- C3["تطبيق .NET ── يجوز 64bit"]
    end

الشكل 1: ثلاثة أنماط للترحيل المرحلي ── أين يُوضع الحد بين القديم والجديد.

7.1 نقل طبقة البيانات أولاً

تكوين تُنقل فيه بيانات تطبيق VB6 أولاً من ملف Access أو صيغة خاصة إلى SQL Server ونحوه، بينما يستمر جانب VB6 بالعمل مع تبديل جهة الاتصال فقط. إذا حُدّثت البيانات أولاً، يمكن للشاشات الجديدة (جانب .NET) أن تنظر إلى قاعدة البيانات نفسها وتُزاد تدريجياً. للخطوات العملية المتعلقة بـ Access راجعوا فصل الـ upsizing في المقال السابق.

7.2 بناء وظائف وشاشات جديدة بـ .NET وربطها عبر COM interop

تكوين تبقى فيه شاشات VB6 القائمة كما هي، وتُبنى وظائف جديدة بـ .NET للتعايش معها. هناك اتجاهان.

• استدعاء مكوّنات جانب .NET من VB6: بتعريض فئة .NET كـ COM، يمكن لـ VB6 الإشارة إليها كمكون COM عادي. شرحنا طريقة تعريضها بشكل منمَّط حتى في .NET 8 وما بعده في «كيفية استخدام DLL في .NET 8 من VBA بشكل منمَّط - تعريض COM وdscom TLB»، والفكرة نفسها تنطبق حتى لو كان طرف الاستدعاء VB6.
• استدعاء أصول جانب VB6 من .NET: يمكن الإشارة إلى ActiveX DLL المصنوع بـ VB6 من .NET عبر COM interop. يُستخدم عندما يُراد الإبقاء على المنطق كتلة واحدة وتحويل الشاشات فقط إلى .NET أولاً. لكن قيد 32bit يبقى، فاعتبروه جسراً أثناء فترة الترحيل لا حلاً دائماً.

تنفيذ الجسر، في الحد الأدنى، بضعة أسطر. أولاً اتجاه استدعاء مكوّنات جانب .NET من VB6. تُضاف سمات إلى الواجهة والفئة المراد تعريضهما.⁸

// .NET側(C# / .NET 8)── VB6から呼べるようにCOM公開する
using System.Runtime.InteropServices;

[ComVisible(true)]
[Guid("fe103d6e-e71b-414c-80bf-982f18f6c1c7")]   // インターフェイスのIID。必ず自分で新規生成する
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface ITaxCalculator
{
    decimal CalcTax(decimal amount);
}

[ComVisible(true)]
[Guid("9f35b6f5-2c05-4e7f-93aa-ee087f6e7ab6")]   // クラスのCLSID。これも新規生成する
[ClassInterface(ClassInterfaceType.None)]
[ProgId("Komura.TaxCalculator")]
public class TaxCalculator : ITaxCalculator
{
    public decimal CalcTax(decimal amount) => Math.Floor(amount * 0.1m);
}

يُطلب في csproj توليد مضيف COM ثم يُبنى، ويُسجَّل .comhost.dll المولَّد من موجه أوامر بصلاحيات مدير.⁸

<PropertyGroup>
  <EnableComHosting>true</EnableComHosting>
</PropertyGroup>

regsvr32 TaxLib.comhost.dll

جانب VB6 المستدعي ككائن COM المعتاد.

' VB6側 ── ProgIdを使った遅延バインド呼び出し
Dim calc As Object
Set calc = CreateObject("Komura.TaxCalculator")
MsgBox calc.CalcTax(12345)
Set calc = Nothing

هنا مطبّان تتعثّرون فيهما حتماً. كلاهما مكتوب في الوثائق الرسمية.⁸

• افتراضياً لا يمكن الاستخدام إلا من عميل 64bit. بخلاف عصر .NET Framework، في .NET Core / .NET 5 فما بعده حتى إن بُني بـ «Any CPU» فإن *.comhost.dll المرافق 64bit افتراضياً. VB6 عملية 32bit، لذا لا يمكن تحميله كما هو (هذا قيد WOW64 نفسه¹). وافقوا تكوين البناء حتى يخرج comhost.dll بنسخة 32bit.
• مكوّن COM بتوزيع مكتفٍ ذاتياً (self-contained) غير مدعوم. المدعوم توزيع معتمد على الإطار فقط. حدّدوا طريقة التوزيع أولاً ثم صمّموا.

الاتجاه الآخر، استدعاء أصول VB6 من .NET، هو مجرد إضافة ActiveX DLL المصنوع بـ VB6 كمرجع COM.

// .NET側 ── VB6製ActiveX DLLをCOM参照して呼ぶ
// 事前準備: プロジェクトに「COM参照」を追加し、32bit(x86)ビルドにしておく
var legacy = new LegacyBiz.OrderCalc();      // VB6で書かれたクラス
decimal total = legacy.CalcTotal(orderId);   // 業務ロジックはVB6側のまま
Marshal.ReleaseComObject(legacy);            // COMオブジェクトは明示的に解放する

هنا أيضاً يلزم بناء جانب .NET المستدعي بـ32bit (x86). لأن ActiveX DLL في VB6 هو DLL بـ32bit، وعملية 64bit لا تستطيع تحميل DLL بـ32bit من أجل التنفيذ.¹ مطلب «نريد إدخال وظيفة جديدة بـ64bit ونريد أيضاً استدعاء منطق VB6» لا يقوم في العملية نفسها عند هذه النقطة. هنا يأتي دور 7.3 التالي.

7.3 فصل العمليات والربط بينها

عند التعايش في العملية نفسها عبر COM interop يصبح عدد البتات (32bit/64bit) وانجرار الأعطال قيداً. عند الحاجة إلى وظيفة جديدة بـ64bit، أو الرغبة في فصل أعطال القديم عن الجديد، تُفصل العمليات وتُربَط عبر الملفات أو الأنابيب المسمّاة أو اتصال localhost ونحوه. خيارات الربط بين العمليات مرتَّبة في «جدول قرار IPC في Windows»، ومثال جسر 32bit→64bit في «مثال جسر COM».

المبدأ المشترك بين جميع الأنماط هو «تجميع الحد بين القديم والجديد في موضع واحد، وتثبيت صيغة البيانات العابرة لهذا الحد». إذا تكاثرت الحدود متفرقة حسب الشاشة أو الوظيفة، التهمت تكلفة فترة التعايش أثر الترحيل نفسه.

8. لغة الهدف ── C# أم VB.NET

يُظن غالباً أن «من VB6 يكون VB.NET طبيعياً»، لكن الأمر ليس بهذه البساطة في ضوء استراتيجية مايكروسوفت اللغوية الحالية.

في الاستراتيجية اللغوية الرسمية تُموضَع Visual Basic (VB.NET) بوصفها «لغة سهلة الفهم ومألوفة تحافظ على تصميم مستقر»، مع تصريح بأن الميزات الجديدة مبدئياً استهلاك فقط (consumption-only) دون إضافة صياغة نحوية جديدة، ودون التوسّع نحو أحمال عمل جديدة. في المقابل يُذكر استمرار الاستثمار في السيناريوهات الأساسية مثل Windows Forms والمكتبات، وتحسين تجربة التطوير على Visual Studio.⁵

بقراءة هذا من زاوية الترحيل يصير كما يلي.

• حتى إن اختيرت VB.NET، ستقوم السيناريوهات القائمة (تطبيقات أعمال WinForms) بلا مشكلة في الأمد القريب. اختيار منطقي للفرق التي تضم كثيراً من ذوي الخبرة في VB6، حيث يقلّل قرب الصياغة تكلفة التعلّم.
• غير أنه يُنصَح بـ C# كأساس للأصول التي ستُكتب جديداً من الآن. فتطوّر اللغة والمنظومة مستمر، وتتركّز الأمثلة والمكتبات وتوريد الأشخاص حول C#. هذا اختيار لتجنّب تكرار مشكلة «لا يوجد من يصون VB6» بعد عشر سنوات كمشكلة «لا يوجد من يصون VB.NET».
• كحل وسط يمكن أيضاً استقبال مخرجات أداة التحويل بـ VB.NET وكتابة التطوير الجديد بـ C#. في .NET يمكن لتجميعات اللغتين الإشارة إحداهما إلى الأخرى، فمزج اللغات نفسه ليس عائقاً.

لاختيار إطار الشاشات (WinForms / WPF / WinUI) راجعوا «جدول قرار WinForms وWPF وWinUI»، ولما ينبغي التحقّق منه عند الترحيل مباشرة إلى .NET الحالي بدل .NET Framework راجعوا «قائمة تحقّق ما قبل الترحيل من .NET Framework إلى .NET». لا سبب لاعتماد .NET Framework 4.8 هدفاً جديداً عمداً عند الترحيل من VB6، ما لم توجد قيود من مكتبات مرجعية.

9. الخلاصة

• الإجابة عن «إلى متى يعمل VB6» هي أن بيئة التشغيل ضمن نطاق التشغيل طوال فترة دعم Windows (بما في ذلك Windows 11). غير أن دعم IDE انتهى سنة 2008، والسند الرسمي لوسيلة إعادة البناء أو الإصلاح لم يعد موجوداً، وهذا وضع غير متماثل.⁴³
• الموعد النهائي الحقيقي ليس نظام التشغيل، بل بقاء البيئة والأشخاص القادرين على الإصلاح. تُوضع خطة الترحيل لا بعد وقوع العطل، بل بينما يمكن استخدام النظام القديم كـ«مواصفات حية».
• مسارات التنفيذ ثلاثة: إعادة كتابة كاملة، وتحويل آلي، وترحيل مرحلي. قبل اختيار الأسلوب يُجرى جرد للشاشات والتكاملات الخارجية وOCX وإعلانات API وقواعد العمل التي لا توجد إلا في الكود.
• في الترحيل دون إيقاف العمل يُعايَش القديم والجديد بأحد: طبقة بيانات أولاً، أو COM interop، أو فصل العمليات، مع تجميع الحد في موضع واحد.
• يُنصَح بـ C# لما يُكتب جديداً. مسار الاستقرار في VB.NET سياسة رسمية⁵، وC# أنفع كأساس للصيانة طويلة الأمد.

9.1 الخطوة التالية ── ما يُفعل في الأسبوع الأول

قائمة تحقّق بحجم يمكن الشروع به حتى لا يتوقف الأمر عند «ندرس الترحيل». لا تُكتب سطر كود واحد.

• تأكيد موضع مجموعة الشيفرة المصدرية. مطابقتها مع أحدث ملف تشغيل إنتاجي، والتأكّد من أن تلك الشيفرة هي النسخة الحالية فعلاً (كما في الفصل 3، إذا اختلف هذا ذهب كل ما بعده هدراً)
• تأكيد جهاز يعمل عليه VB6 IDE. كم جهازاً، وما نظام تشغيله، وهل يمكن إعادة بنائه إن تعطّل
• سرد المكوّنات المشار إليها من .vbp. تمرير نص الفصل 5 كما هو وصنع CSV
• إضافة ثلاثة أعمدة لكل مكوّن في القائمة وملؤها: «إمكان الحصول / دعم المورّد / بديل جانب .NET». الخلايا التي لا تُملأ هي مواضع صعوبة الترحيل
• عدّ الشاشات والتقارير. ثم تأكيد «الشاشات المستخدمة فعلاً» في الميدان. عدم ترحيل الشاشات غير المستخدمة وحده يغيّر الجهد كثيراً
• استخراج عبارات Declare عرضياً. تصنيفها حسب الغرض، وفرز ما يمكن استبداله بميزة قياسية في .NET
• تثبيت مرجع التحقّق. تقرير واحد بماذا ستقارنون الصحة بعد الترحيل (تقارير، CSV، محتوى قاعدة البيانات)
• التأكّد مما إذا وُجد متطلّب يعاني من 32bit. إن وُجد، تصبح تلك النقطة الواحدة الشرط الأعلى لأولوية اختيار الأسلوب

بهذا تكتمل مواد المضي إلى اختيار الأسلوب في الفصل 4 والتجربة الأولية في الفصل 5.

مقالات ذات صلة

• إطالة عمر تطبيقات VB6 / Access وترحيلها - جدول قرار الإبقاء والتغليف والاستبدال
• كيف نتعامل مع ActiveX / OCX اليوم - جدول قرار الإبقاء والتغليف والاستبدال
• مثال عملي على جسر COM لاستدعاء DLL بصيغة 64bit من تطبيق 32bit
• كيفية استخدام DLL في .NET 8 من VBA بشكل منمَّط - تعريض COM وdscom TLB
• قائمة تحقّق ما قبل الترحيل من .NET Framework إلى .NET
• جدول قرار WinForms وWPF وWinUI
• ما هي VBA - القيود، المستقبل، الحالات التي ينبغي استبدالها، وأنماط الترحيل الواقعية

مجالات الاستشارة ذات الصلة

تتولّى شركة كومورا سوفت ذ.م.م. جرد الأصول القائمة بما فيها VB6 وترتيب سياسة الترحيل، وتصميم وتنفيذ تكوينات التعايش بين القديم والجديد عبر جسور COM وفصل العمليات، والاستبدال التدريجي نحو .NET.

• الاستفادة من الأصول القائمة ودعم الترحيل
• تعديل وصيانة برمجيات Windows القائمة
• تطوير تطبيقات Windows
• الاستشارة التقنية ومراجعة التصميم
• تواصل معنا

روابط مرجعية

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل تعمل تطبيقات VB6 على Windows 11؟

نعم، هي ضمن نطاق التشغيل المستهدف. بحسب سياسة الدعم الرسمية من مايكروسوفت، تبقى بيئة تشغيل VB6 (مثل msvbvm60.dll) مدعومة طوال فترة دعم إصدار Windows الذي تُشحَن معه، وتشمل قائمة أنظمة التشغيل المستهدَفة Windows 11 وWindows 10 وWindows Server 2025. غير أن نطاق هذا الدعم يقتصر على معالجة الانحدارات الخطيرة والمشكلات الأمنية الحرجة في التطبيقات القائمة. كما أن بيئة تشغيل VB6 مخصّصة لـ32bit فقط، وعلى Windows 64bit لا تُدعَم إلا داخل بيئة التوافق WOW64.

هل يمكن إنجاز الترحيل من VB6 إلى .NET بأداة تحويل آلي فقط؟

ينبغي افتراض أن ذلك غير ممكن. يمكن لأدوات التحويل أن تقلّل عبء إعادة كتابة تعريفات الشاشات والمنطق البسيط، لكن أموراً مثل معالجة الأخطاء عبر On Error، والكود المعتمد على نوع Variant أو الخصائص الافتراضية، وعناصر تحكّم ActiveX، وإعلانات Win32 API، تحتاج كلها إلى قرارات تصميم وتصحيحات يدوية. بدل استخدام مخرجات الأداة مباشرة في بيئة الإنتاج، يجب تقدير المشروع كاملاً بما يشمل «الجهد البشري اللازم بعد التحويل لإنهاء العمل»، وتحديد كيفية التحقّق من نتيجة التحويل مسبقاً (كالتشغيل المتوازي أو مقارنة المخرجات).

هل ينبغي اختيار VB.NET أم C# كهدف للترحيل؟

يُنصَح باستخدام C# لكل ما يُكتب من جديد. تموضع استراتيجية مايكروسوفت اللغوية لغة Visual Basic (VB.NET) كلغة تحافظ على تصميم مستقر، مع تصريح واضح بعدم إضافة صياغات نحوية جديدة وعدم التوسّع نحو أحمال عمل جديدة. يستمر الاستثمار في السيناريوهات القائمة مثل Windows Forms، فلن تصبح VB.NET غير قابلة للاستخدام، لكن كأساس لكود سيُصان لعقد قادم تتمتّع C# بميزة أكبر في تأمين الكفاءات لأن اللغة ومنظومتها في تطوّر مستمر. الفرق التي تضم عدداً كبيراً من ذوي الخبرة في VB6 قد تختار المرور عبر VB.NET نظراً لتقارب الصياغة.

قبل إعادة الكتابة الكاملة، ما الذي ينبغي فعله أولاً؟

ينبغي إجراء جرد شامل قبل البدء بكتابة أي كود. وتحديداً: قائمة الشاشات والتقارير، قائمة التكاملات الخارجية (قواعد البيانات، الملفات، الاتصال التسلسلي، الأنظمة الأخرى)، قائمة عناصر تحكّم OCX/ActiveX ومكوّنات COM المشار إليها، قائمة إعلانات Win32 API (عبارات Declare)، وحصر قواعد العمل التي لا توجد إلا في الكود نفسه. غالباً ما تكشف نتائج هذا الجرد أن الترحيل المرحلي عبر استخراج جزء فقط، أو نقل طبقة البيانات أولاً، أكثر واقعية من إعادة الكتابة الكاملة.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.