آنچه در آگوست 2026 تغییر کرد
قبل از این کار ، من مهندسی معکوس دستی زیادی انجام داده بودم. من یک تابع را بررسی می کردم تا زمانی که یک توضیح داشتم ، سپس آن توضیح را در برابر برنامه تست می کردم. ادامه دادن به این معنی بود که بیشتر وقت خودم را صرف کار بعدی می کردم. همچنین به این معنی بود که یک تصویر بزرگ در ذهنم نگه دارم.
بسیاری از دوباره کار من در بازی است. من آنها را بازسازی می کنم تا رفتارشان درک شود و در نهایت به یک پورت نرم افزار یا یک مود منتقل شود. این تجربه پشت این مقاله است. این روش می تواند در جای دیگر مفید باشد ، اما هر فیلد باید مشخص کند که چه چیزی را می تواند با یک مرجع قابل اعتماد بررسی کند.
در اوت 2026, من شروع به کاوش دوباره عامل محور جدی. ميخواستم ببينم که يه مامور چقدر ميتونه با دسترسي به برنامه و ابزار توسعه معمولي به اينجا برسه بازسازی توهو به من یک پروژه قابل توجهی داد که در آن می توانستم بفهمم.
پیشرفت اولیه شگفت انگیز بود. يه تحقيق ميتونه بدون اينکه من هر قدم رو انتخاب کنم ادامه پيدا کنه يه مقايسه شکست خورده ممکنه مامور رو به يه تماس گيرنده ديگه بفرسته می تواند یک تشخیص کوچک بنویسد و از نتیجه استفاده کند تا تصمیم بگیرد که چه چیزی را امتحان کند. دادن این آزادی به آن تفاوت ایجاد کرد: من می توانم توجه بیشتری به جهت پروژه و اینکه آیا چک های آن قابل اعتماد است ، صرف کنم.
سرعت اول توجه من رو جلب کرد بعد شروع کردم به فکر کردن که چه چیزی فراتر از پروژه فعلی زنده می ماند. آیا بازی بعدی از هر چیزی که تازه یاد گرفته بودیم سود می برد ؟
TH08: ساخت بر روی کار انسانی
TH08 ، شب فاسد نشدنی ، به عنوان ادامه بازسازی GensokyoClub. منبع عمومی آنها به من یک پایه قابل توجهی داد. با دانش ساخت و ساز و سابقه کمک هایی که در ادامه حفظ کردم ، همراه بود.
تاریخ وارداتی در بازرسی عمومی 10 آگوست به پایان می رسد. ادامه مستقل من در 13 آگوست آغاز شد. تا 19 آگوست ، دفتر کل منبع ثبت شده برای تمام 1107 عملکرد بازی شناسایی شده بود.
یک پورت بازسازی Linux قابل بازی در 24 اوت ، تقریبا یازده روز پس از شروع ادامه ، انجام شد. یک نسخه وب به دنبال آن بود. نسخه بومی Linux 64 بیتی در 30 اوت وارد شد.
چیزی که مرا تحت تاثیر قرار داد این بود که کار به برنامه ای رسیده بود که مردم می توانستند اجرا کنند. رسیدن به آنجا نیاز به دنبال مشکلات فراتر از یک عملکرد فردی دارد. حتی وقتی دو تابع به صورت جداگانه درست به نظر می رسیدند ، می توانستند به طور تصادفی از نسخه های جداگانه ای از حالت استفاده کنند که باید به اشتراک گذاشته می شد.
این باعث شد که چک های مرجع در مرکز کار قرار بگیرند. من بهشون ميگم مراجع تأیید (اوراکل). یک مقایسه کد می تواند به ما بگوید که آیا یک تابع بازسازی شده دستورالعمل های اصلی را بازتولید می کند. یک بررسی زمان اجرا می تواند به ما بگوید که آیا یک مسیر تمرین شده به حالت مورد انتظار می رسد. مامور توضیح می دهد و آن را آزمایش می کند ؛ عدم تطابق چیزی خاص برای تحقیق به آن می دهد.
مطابقت دقیق با ثابت اشتباه
یک مرجع تأیید (اوراکل) نرم افزاری است که کسی نوشته است. TH08 به من یادآوری روشنی داد که چقدر می تواند به این نرم افزار بستگی داشته باشد.
در ماه سپتامبر ، یک اشکال گزارش شده توسط یک پورت سوئیچ پایین جریان منجر به جمع آوری خودکار آیتم شد. منبع بازسازی شده قدرت بازیکن را در برابر 0.0. اصل مورد استفاده 128.0، حد حداکثر قدرت
قدرت طبیعی منفی نیست ، بنابراین بررسی قدرت بازسازی شده به طور موثر همیشه راضی بود. بالاتر از خط جمع آوری ، بازی می تواند بدون نیاز به حداکثر قدرت ، آیتم ها را جذب کند. استثناهای دیگر در این شرایط درست بود. این یکی ثابت رفتار را تغییر داد.
با این حال تابع قبلا مقایسه دقیق را پشت سر گذاشته بود.
بازسازی می تواند ثابت را در آدرس دیگری قرار دهد. ابزار مقایسه این را با تنظیم آدرس ها در دستورالعمل های کامپایل شده قبل از مقایسه آنها با اصل توضیح می دهد. اما هرگز ارزش نقطه شناور ذخیره شده در آدرس مرجع را بررسی نکرد.
که يه سوراخ توي چک جا گذاشت ممکنه دستورالعمل بازسازی شده رو به سمت اصل نشون بده 128.0 در حالی که منبع هنوز گفت 0.0. بایت های دستورالعمل با هم مطابقت داشتند. منبع به معنی چیز دیگری بود.
این 2 سپتامبر ثابت منبع را اصلاح کرد و مقایسه را انجام داد بایت های واقعی ثابت مرجع را بررسی کنید. A حسابرسی گسترده تر سپس 1548 مرجع ثابت نقطه شناور را بررسی کرد. این دوازده مرجع نادرست دیگر را در پنج تابع پذیرفته شده پیدا کرد.
این مقایسه اکنون هر ثابت نقطه شناور را بررسی می کند. تست های آن شامل مقادیر عمدا اشتباه برای اطمینان از رد شدن آنها است. ما همچنین مجبور بودیم نتایج را که از چک ضعیف تر عبور کرده بود ، دوباره بررسی کنیم.
مرجع تأیید (اوراکل) نیز نیاز به بازسازی داشت. تعمیر آن بخشی از تعمیر بازی بود.
این مهم است وقتی که تیم بیشتر یک نفر است که با ماموران کار می کند. من شخصا نمی توانم هر خطی را که تولید می کنند بازرسی کنم ، بنابراین اعتماد به نفس من بر روی چک های آنها استوار است. نقطه کور یک مرجع تایید مشترک (اوراکل) می تواند بسیاری از تحقیقات را قبل از اینکه متوجه آن شوم ، تحت تاثیر قرار دهد. باید بفهمم که چک کننده واقعا چه چیزی را تایید می کند و آن را در برابر مواردی که باید شکست بخورند تست می کند.
با ادامه کار ، این چک ها بخشی از مخزن شدند. همچنین دلایل تغییر منبع و یادداشت هایی که اجازه می داد جلسه بعدی از جایی که جلسه قبلی متوقف شده بود ، شروع شود. مخزن کد منبع به حافظه کاری پروژه تبدیل شده بود.
یک دسته موفق به ما کد بازیابی شده و یک محیط بهتر برای دسته بعدی را داد.
دو ایده متفاوت از بازسازی
GensokyoClub عمومی README مخالفتش با این نوع کار را صریح می کند. این اطلاعیه اعلام می کند که توسعه بیشتر به صورت خصوصی تا زمان تکمیل اتفاق خواهد افتاد. در یکی از این بخش ها آمده است:
ظهور grifters (تجزیه هوش مصنوعی و پورت ها) در این فضا گرفتن از کار ما یک تصویر بد برای تلاش های تجزیه آینده را نقاشی می کند…
این اطلاعیه همچنین تلفات روانی را بر روی نگهدارنده ها توصیف می کند. سیاست مشارکت آنها درخواست های pull را که عمدتا با هوش مصنوعی تولید شده است ، حذف می کند. آنها وقت آزادشان را به کار سختی اختصاص داده اند ، و این کار به ادامه من کمک کرد. من به تلاش پشتش احترام ميذارم اختلاف نظر که می خواهم در مورد آن بحث کنم این است که بازسازی چگونه باید ادامه یابد و چگونه باید یک سهم را قضاوت کرد.
در جریان کاری دستی که می شناختم ، توسعه درک یک تابع و بازسازی آن معمولا به همان شخص می رسید. یک پروژه به شدت به تخصص آن شخص متکی بود. اعتماد به کمک کننده مهم بود چون خیلی از استدلال ها در حالی که کار می کردند اتفاق می افتاد.
پروژه های موجود در حال حاضر دانش را در منبع خود حفظ می کنند و ابزار می سازند. چیزی که برای من تغییر کرد این بود که یک مامور می توانست از این دانش برای پیگیری تحقیقات بعدی به تنهایی استفاده کند.
در ادامه ، من هدف و استاندارد پذیرش نتیجه را تعیین می کنم. مامور آزادی گسترده ای برای تحقیق داره بازسازی پیشنهادی آن باید از چک های مربوطه جان سالم به در ببرد. من می خواهم شخص دیگری بتواند بررسی کند که چرا ما یک پیاده سازی را انتخاب کردیم ، حتی اگر یک نماینده بیشتر کار را انجام دهد.
این می تواند یک انتقال دشوار باشد. سالها کار دقیق ممکن است پایه ای برای ادامه ای باشد که بسیار سریعتر حرکت می کند. این سوال های واقعی در مورد اعتبار را مطرح می کند. همچنین آنچه را که نگهدارندگان باید قبل از پذیرش سهم بدانند تغییر می دهد.
تشبیه صنعتی به من کمک می کند تا در مورد این فکر کنم. در یک کاردستی ، بیشتر فرآیند به مهارت فرد انجام دهنده آن بستگی دارد. ماشین آلات در جایی که این مهارت مورد نیاز است تغییر می کند. کسی هنوز باید فرآیند را طراحی کند و تشخیص دهد که خروجی آن اشتباه است. جوامع مختلف می توانند انتخاب کنند که چه مقدار از این تغییر را می خواهند انجام دهند.
انتخاب من اينه که به طور علني ادامه بدم ، با کار ارثي که اعتبار داده شده و تاريخش حفظ شده. ميخوام کار جديد قابل بازنگري باشه این به ما راهی می دهد تا بپرسیم این رویکرد تا چه حد می تواند پیش برود و از آنچه در طول مسیر اشتباه است یاد بگیریم.
منبع: GensokyoClub اطلاعیه README، در 10 اکتبر 2026 بررسی شد و سیاست مشارکت. نقل قول یک گزیده کوتاه است. TH08 اعتبارات و منشأ مرز ادامه را ثبت کنید.
TH095: تجربه شروع به ترکیب می کند
TH095 ، گلوله رو شلیک کن ، ارزش اون تجربه رو خیلی راحت تر دید. مخزن آن در 29 اوت با صفر عملکرد بازی تایید شده در دفتر کل آغاز شد. ما هنوز باید بازی را یاد می گرفتیم. اما ما قبلا خیلی بیشتر در مورد چگونگی شروع بازسازی و چگونگی حرکت آن می دانستیم.
تا 7 سپتامبر ، تمام 697 تابع بازی شناسایی شده منبع داشتند. تا 8 سپتامبر ، 696 مورد به عنوان مقایسه دقیق پذیرفته شده بود. کل برنامه در 9 سپتامبر به هم متصل شد. بازسازی Windows i386 در 10 سپتامبر ، حدود دوازده روز پس از شروع ، قابل بازی بود.
من این را هیجان انگیزتر از سرعت پروژه اول یافتم. یک هدف تازه می تواند از کار انجام شده در یک بازی دیگر بهره مند شود. این تجربه قبلا در ابزارها و نحوه سازماندهی پروژه وجود داشت.
به عنوان مثال ، TH08 به ما آموخته بود که زودتر به برنامه مونتاژ شده توجه کنیم. اگر چندین تابع بازیابی شده به همان حالت بستگی داشته باشند ، مقایسه های جداگانه آنها یک سوال مهم را باز می گذارد. ما باید ببینیم که اونا با هم کار می کنن این درس به شکل گیری نحوه ی نزدیک شدن ما به ساخت کل برنامه ی TH095 کمک کرد.
درسی که در ذهنم باقی می ماند در حالی که من آنجا هستم مفید است. وقتی که به یک چک تبدیل شد که یک جلسه دیگر می تواند اجرا شود ، می تواند کمک کند بعد از اینکه من حرکت کردم. عامل بعدی می تواند نتیجه را بدون تکرار تحقیقات منجر به آن استفاده کند.
باگ ثابت نقطه شناور هم به اون حافظه تعلق داره این توضیح می دهد که چرا بررسی یک مرجع نیز نیاز به بررسی داده های پشت آن دارد. حفظ این اصلاح با کد به پروژه های بعدی کمک می کند تا از ارث بردن نقطه کور چک قدیمی جلوگیری کنند.
این روش بخشی از مواد اولیه برای بازی بعدی می شود. ما می توانیم بیشتر از تلاش پروژه بعدی را صرف آنچه در واقع جدید در مورد هدف آن است.
همین مزایا برای افرادی که بعدا به این گروه می پیوندند ، در دسترس است. آنها می توانند قبل از ادامه کار ، یک تصمیم را بازرسی کرده و چک آن را مجددا اجرا کنند. آنها مجبور نیستند کل تاریخچه پروژه را بازسازی کنند تا بفهمند چرا منبع به این شکل به نظر می رسد.
TH04: جریان کار از یک معماری متفاوت جان سالم به در می برد
TH04 ، داستان سرزمین لوتوس ، این کار را به دوران PC-98 dos برد. هدف در حال حاضر یک محیط 16 بیتی با چهار برنامه همکاری بود. درک رفتار سخت افزاری آن نیاز به شواهد متفاوتی از بازی های Windows داشت. موجود کار ReC98 ما دانش ارزشمندی و منبع مواد را در اینجا نیز به ما داد.
بازسازی DOS در حال حاضر کار می کند. در تست دستی من ، من مسیرهای عادی کامل را از طریق پایان آنها بازی کردم و ذخیره ها را بررسی کردم. کار فعلی یک پورت 64 بیتی بومی است. ایجاد یک نسخه dos کار برای اولین بار به آن پورت یک مرجع می دهد.
معماری چیزی که ما برای تحقیق نیاز داشتیم را تغییر داد. همچنین کامپایلر و زمان اجرا را تغییر داد که با آن کار خود را بررسی کردیم. اما مامور هنوز می تواند یک سوال را تا نتیجه دنبال کند و اجازه دهد که نتیجه آزمایش بعدی را هدایت کند.
انتقال از گیم پلی به پایان را در نظر بگیرید. ما باید بدانیم که چه ایالتی از این مرز عبور می کند و کدام برنامه مسئول آن است. اين چيزيه که ما ميتونيم در مورد محصول DOS تحقيق کنيم هنگامی که شواهد و چک ها در دسترس هستند ، یک نماینده می تواند از طریق سوال کار کند ، همانطور که در عنوان Windows انجام شده است.
به همین دلیل TH04 برای استدلال مهم است. تغییر قابل توجهی در پلتفرم ما را مجبور نکرد که با یک روش جدید کار شروع کنیم. معماری مشکل را تعریف کرد ؛ جریان کار هنوز راهی برای حل آن به ما داد.
برای پورت 64 بیتی ، ما اکنون می توانیم پیاده سازی جدید را با رفتاری که قبلا در DOS بازیابی شده است ، بررسی کنیم. دانش از بازسازی به بندر چیزی برای ساخت می دهد.
وضعیت پروژه از 10 اکتبر 2026: بازسازی DOS و تست دستی · پورت 64 بیتی. بندر همچنان در حال توسعه است.
از کد دقیق تا کد قابل خواندن
وقتی بازسازی جواب داد ، میخوام یه نفر دیگه بتونه درکش کنه.
برای من ، مونتاژ و جبران خام می تواند مانند دوستان قدیمی احساس شود. میدونم که این یه تعریف کمی غیرمعموله از "قابل خواندن""اکثر مردم ترجیح می دهند منطق بازی را بدون نگه داشتن طرح حافظه اجرایی در سر خود دنبال کنند.
اینجاست که بازسازی معنایی وارد می شود. یک میدان بازیابی شده هنوز هم ممکن است عمدتا با جبران آن شناخته شود. ما دنبال می کنیم که چگونه بازی از آن استفاده می کند تا زمانی که بتوانیم نقش آن را توضیح دهیم. سپس می توانیم یک نام معنی دار و نوعی متناسب با شواهد به آن بدهیم. ما استدلال را با منبع نگه می داریم تا فرد بعدی بتواند ببیند که این تفسیر از کجا آمده است.
این امر به ویژه برای یک پورت نرم افزار مهم می شود. یک آدرس مطلق به من می گوید که چیزی در فایل اجرایی قدیمی کجا زندگی می کرد. این یک پیاده سازی 64 بیتی را در تصمیم گیری در مورد اینکه کدام شی باید مالک آن حالت باشد ، کمک کمی می کند. برای حرکت ایمن رفتار ، باید رابطه پشت دسترسی به حافظه قدیمی را بازیابی کنیم.
سفارشي که الان ازش استفاده ميکنم:
- یک خط پایه دقیق را بازیابی کنید. قطعات بازسازی شده را با کامپایلر تاریخی کامپایل کنید. کد و داده های مربوطه را با فایل اجرایی اصلی مقایسه کنید. تفاوت های حل نشده را ثبت کنید تا مرحله بعدی نقطه شروع مشخصی داشته باشد.
- ساخت و پخش آن بر روی پلت فرم اصلی. این قطعات را با استفاده از معماری اصلی و کامپایلر به برنامه واقعی پیوند دهید. مسیرهای مهم گیم پلی را تمرین کنید. این جایی است که ما می توانیم مشکلات را با حالت مشترک یا شروع که یک مقایسه تابع جدا شده از دست داده است پیدا کنیم.
- معناشناسی را در برابر هر دو مرجع بازسازی کنید. یک قسمت منسجم از بازی را در یک زمان بگیرید و مشخص کنید که منبع بازیابی شده آن به چه معناست. بهبود نمایش آن در حالی که حفظ مقایسه دقیق و ساخت تاریخی قابل بازی.
- بندر مدرن را بسازید. رفتار ثابت شده را به محیط جدید منتقل کنید ، مانند ساخت 64 بیتی بومی. بازی اصلی-پلتفرم بازسازی شده همچنان مرجع مقایسه رفتار بندر است.
ساخت قابل پخش از مرحله دوم به یک مرجع تأیید دوم (اوراکل) در طول سوم. اولین مرجع تأیید (اوراکل) بررسی می کند که آیا منبع تغییر یافته ما هنوز کد و داده های اصلی مربوطه را بازتولید می کند یا خیر. دوم بررسی می کند که برنامه بازسازی شده هنوز در مسیرهایی که ما تمرین می کنیم درست می سازد و رفتار می کند.
آنها اشتباهات مختلفی را می گیرند. تغییر نوع می تواند دستورالعمل های تولید شده را تغییر دهد. تغییر مالکیت می تواند دو قسمت از بازی را با استفاده از نسخه های مختلف حالت ترک کند. نگه داشتن هر دو چک در دسترس به عامل یک شکست مشخص برای تحقیق قبل از حمل یک refactor بیشتر می دهد.
يه اسم به شواهد خودش نياز داره مقایسه دقیق نمی تواند به ما بگوید که آیا یک میدان واقعا به معنی "زمان آسیب پذیری است. ما باید این را از نحوه نوشتن و استفاده از بازی ثابت کنیم. اگر معنی نامشخص باقی بماند ، یک نام بی طرف برای خواننده بعدی مفیدتر از یک حدس مطمئن است.
ما این نظم را از طریق پروژه ها یاد گرفتیم. TH08 قبل از برخی از حسابرسی های بعدی پلتفرم تاریخی خود ، پورت های قابل بازی داشت. این باعث شد که دیدن نقص های خاصی سخت تر شود. این جریان کاری فعلی کارخانه ساخت پلتفرم اصلی را در اولویت قرار می دهد ، بنابراین کار معنایی می تواند از آن به عنوان مرجع قبل از شروع پورت استفاده کند.
بازسازی دقیق به ما مرجع می دهد. بازسازی معنایی دانش بازیابی شده را قابل استفاده می کند. سپس یک پورت می تواند بر روی هر دو ساخته شود.
چه چیزی این را به یک تغییر صنعتی تبدیل می کند ؟
این پروژه ها جایی که من توجهم را صرف کردم تغییر کردند. وقتی ماموران می توانستند تحقیقات زیادی را به جلو ببرند ، بهبود محیط کارشان یکی از مفیدترین کارهایی بود که می توانستم انجام دهم. یک ابزار بهتر می تواند در هر عملکرد بعدی که به آن نیاز دارد کمک کند.
استقلال اینجا مهمه مرحله بعدی مفید اغلب تنها پس از یک آزمایش شکست خورده روشن می شود. یک مامور به آزادی کافی برای پیروی از این نتیجه در جایی غیر منتظره نیاز دارد. اگر باید منتظر بمانم تا هر مرحله را تجویز کنم ، بیشتر کار به توجه من وابسته است.
انتظار دارم که مامور فرضيه هاي اشتباهي بکنه مهم این است که آیا ما می توانیم آنها را آزمایش کنیم و از نتیجه یاد بگیریم. چک شکست خورده باید به آن کمک کند تا اشتباه را به اندازه کافی خوب درک کند تا دوباره امتحان کند. هنوز بايد تصميم بگيرم که آيا شواهد جمع شده از يک نقطه عطف پروژه حمايت ميکنه يا نه
REA به عامل دسترسی به ابزارهای تجزیه و تحلیل را می دهد. یک سوال در مورد تماس گیرنده یک تابع می تواند مستقیما به بازرسی آن تماس گیرنده منجر شود. پروژه بازسازی کامپایلر و چک های مرجع خود را تامین می کند. مامور می تواند از آن ها برای تست منبع پیشنهادی خود استفاده کند و ببیند که توضیح آن در کجا قرار دارد.
باگ TH08 نشان می دهد که چرا این چک ها مستحق توجه مهندسی خود هستند. هنگامی که همان مقایسه در صدها تابع استفاده می شود ، شکاف در آن می تواند بسیار بیشتر از یک اشتباه در یک پیاده سازی گسترش یابد. تست چک کننده بازخورد موجود برای تمام کارهای بعدی را بهبود می بخشد.
تشبیه صنعتی در اینجا یک مثال تاریخی مفید دارد. بولتون و وات یک نشانگر موتور بخار در سال 1796 برای کمک به تنظیم دریچه های موتور. نسخه ضبط شده فشار را از طریق ضربه پیستون ردیابی می کرد. رفتار داخلی موتور را برای بازرسی در دسترس قرار داد. ابزار مقایسه ما به یک هدف مشابه خدمت می کند: آنها به ما اجازه می دهند تا بررسی کنیم که ماشین آلات چه کاری انجام می دهند در حالی که ما آن را بهبود می بخشیم.
ما در مراحل اولیه این تغییر صنعتی هستیم. بخش عمده ای از زیرساخت ها هنوز نابالغ هستند. ماموران می توانند سریع تر از چک های ما حرکت کنند که برای پشتیبانی طراحی شده اند ، بنابراین این فرآیند باید در کنار آنها توسعه یابد. وقتی یک نقص در یک ابزار مشترک پیدا می کنیم ، باید آن را تعمیر کنیم و نتایج تحت تاثیر آن را دوباره بررسی کنیم. پروژه بعدی می تواند یک ابزار قوی تر را به ارث ببرد.
همچنین یک محدودیت عملی برای هر مکالمه وجود دارد. قبل از اینکه یک بازسازی بزرگ به پایان برسد ، پایان خواهد یافت. مخزن کد منبع باید امکان ادامه جلسه دیگری را بدون از دست دادن دلیل تصمیم قبلی فراهم کند.
این کارخانه بازسازی توهو از این نیاز رشد کرد. این به پروژه ها یک راه مشترک برای حمل چک ها و درس های خود را به جلو می دهد. کار بر روی یک بازی می تواند شرایط شروع را برای دیگری بهبود بخشد.
این چیزی است که تشبیه صنعتی را برای من معنی دار می کند. تجربه شروع به تبدیل شدن به بخشی از ابزارهایی می کند که دیگران می توانند از آن استفاده کنند. بهبود این ابزارها ، میزان کاری که فرد بعدی یا نماینده بعدی می تواند انجام دهد را تغییر می دهد.
پروژه هایی که اکنون می توانیم در نظر بگیریم
سرعت مهم است چون تصمیم برای شروع را تغییر می دهد. یک بازی می تواند برای مهندسی معکوس جذاب باشد و هنوز هم نیاز به توجه بیشتر از آنچه که من می توانم به طور واقع گرایانه به آن بدهم. بسیاری از پروژه ها ایده ها را حفظ می کنند.
حالا می توانم راهی برای ادامه چنین پروژه ای در تحقیقات مکرر ببینم. بازسازی کار یک پورت نرم افزار را عملی تر می کند. بازیابی معناشناسی قابل خواندن ، کشف یک مود را برای شخص دیگری آسان تر می کند. تلاش برای درک بازی می تواند پس از اجرای نسخه اول ادامه یابد.
حالا به برنامه ای ناآشنا نگاه می کنم و می پرسم: چه دسترسی ، بازخورد و دانش انباشته شده ای به یک نماینده اجازه می دهد تا به طور قابل اعتماد روی این کار کند ؟
این سوال باعث می شود پروژه هایی را در نظر بگیرم که قبلا تنها می ماندم. هرکدام می توانند روش برخورد ما با روش بعدی را بهبود ببخشند. ميخوام به کاوش ادامه بدم که چقدر ميتونه ما رو ببره
نقاط عطف و منابع پروژه
این تاریخ ها نقاط بازرسی ثبت شده پروژه را توصیف می کنند که در تاریخ 10 اکتبر 2026 با تاریخچه عمومی GitHub بررسی شده است. زمان سپری شده زمان تقویم بین commits است. حضور منبع ، مقایسه دقیق ، ساخت و نتیجه زمان اجرا هر نام یک نقطه عطف متفاوت است.
- TH08 : 13 آگوست ادامه, 19 آگوست منبع دفتر کل, 24 اوت Linux پورت, 26 آگوست نسخه وب و 30 آگوست نسخه 64 بیتی Linux.
- TH095 : 29 آگوست دفتر اولیه, 7 سپتامبر منبع دفتر کل, 8 سپتامبر مقایسه, 9 سپتامبر ارتباط و 10 سپتامبر قابل پخش-رکورد ساخت.
- TH04 : 10 اکتبر تحویل بازسازی dos کاری ، تست کامل مسیر عادی نگهدارنده و مرحله 64 بیتی فعلی را ثبت می کند.
- TH08 مرجع تأیید (اوراکل) اصلاح: گزارش شده باگ جمع آوری خودکار, منبع و اصلاح مقایسه و حسابرسی مداوم کامل نقطه شناور.
- بازسازی معنایی: کتاب بازی قابلیت خواندن TH08 و سفارش فاز کارخانه و دو مسیر اعتبارسنجی.
- تاریخچه صنعتی: رکورد شاخص موتور بخار گروه موزه علوم مقدمه سال 1796 و مکانیسم ضبط فشار را توصیف می کند.
- روش: کارخانه خودمختاری عامل و دانش بازی های متقابل اسناد اصول و درس های کاری را حفظ می کنند.