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

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

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

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

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

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

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 غير مدعومة على أنظمة التشغيل الحاليّة، ويزداد الحفاظ على وسيلة رسميّة للحصول عليها وتثبيتها صعوبةً عامًا بعد عام. حالة «لا يوجد سوى جهاز واحد في الشركة قادر على الإصلاح» ليست نادرة.
• انقطع دعم موردي عناصر تحكّم OCX من طرف ثالث. تنصّ سياسة الدعم نفسها صراحةً على أنّ عناصر التحكّم من صنع طرف ثالث تقع ضمن نطاق مسؤوليّة المورّد.² كثيرًا ما تكون عناصر OCX الخاصّة بالشبكات (grids) أو التقارير غير متاحة أصلًا، وينطبق هنا مباشرةً ما تمّ تنظيمه في «كيف تتعامل مع ActiveX / OCX اليوم».
• يختفي الأشخاص القادرون على الكتابة. هذه ليست مسألة مواصفات لغويّة بل مسألة بشريّة. لا يكاد يتعلّم أيّ مهندس جديد VB6، لذا فإنّ عدد القادرين على الصيانة يتناقص باطّراد.
• تصطدم المتطلّبات المحيطة بحاجز 32bit. أصبحت حزم تطوير الأجهزة الجديدة، ومكتبات المصادقة، وتكاملات السحابة تفترض 64bit و.NET بشكل متزايد، وتتراكم المتطلّبات التي لا يمكن دمجها ضمن عمليّة VB6.

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

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

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

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

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

5. الجرد قبل الترحيل ── ما ينبغي فحصه قبل الكود

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

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

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

6. أهمّ نقاط عدم التوافق بين VB6 و.NET

VB6 وVB.NET/C# لغات أبعد عن بعضها ممّا توحي به أسماؤها. سواء اختُرت التحويل الآليّ أو إعادة الكتابة اليدويّة، تستلزم الفروق التالية دائمًا قرارات تصميميّة.

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

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

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

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

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

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

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

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

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

عند التعايش ضمن نفس العمليّة عبر التشغيل التبادليّ لـ COM، يصبح عدد البتّات (32bit/64bit) وانتقال الأعطال قيدًا. عند الحاجة إلى وظيفة جديدة بصيغة 64bit، أو الرغبة في فصل أعطال القديم عن الجديد، يُفصَل الأمر إلى عمليّات منفصلة تُربَط عبر الملفّات أو الأنابيب المُسمّاة (named pipes) أو اتّصال 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، يمكن للمجمّعات (assemblies) الخاصّة باللغتين أن تشير إلى بعضها بعضًا، فمزج اللغات بحدّ ذاته لا يُشكّل عائقًا.

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

9. الخلاصة

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

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

• إطالة عمر تطبيقات VB6 / Access وترحيلها - جدول قرار الإبقاء والتغليف والاستبدال
• كيف تتعامل مع ActiveX / OCX اليوم - جدول قرار الإبقاء والتغليف والاستبدال
• مثال عمليّ على جسر COM لاستدعاء DLL بصيغة 64bit من تطبيق 32bit
• استدعاء DLL في .NET 8 من VBA بأسلوب مُنمّط - 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)، وحصر قواعد العمل التي لا توجد إلّا في الكود نفسه. غالبًا ما تكشف نتائج هذا الجرد أنّ الترحيل التدريجيّ - عبر استخراج جزء فقط، أو نقل طبقة البيانات أوّلًا - أكثر واقعيّة من إعادة الكتابة الكاملة.

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

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

غو كومورا

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

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