Your Bugs ..
باگهای شما
Even if pointing out bugs is not a great problem in Assembly, you may have to face some difficult cases.
حتی اگر اشاره کردن به باگها یک مسئله ی بزرگ در زبان اسمبلی ، نباشد ؛ شما ممکن است مجبور شوید با برخی از موارد دشوار روبرو شوید .
RosAsm's syntax and editing features help a lot at preventing errors before the actual Run time.
گرامر روسسم و ویژگیهای ویرایش ، ، به جلوگیری از بروز خطاهای قبل از زمان اجرای واقعی، کمک بزرگی می نمایند .
In most cases, faulty statements will be properly pointed out either by the Compiler or, if not, by the integrated Debugger.
در بیشتر موارد ، احکام معیوب به طرز شایسته ای توسط کامپایلر یا دیباگر توکار مورد اشاره قرار می گیرند .
Other than that, when you encounter no cue hanging Bugs, think first of these:
به غیر از آن ، هنگامیکه شما با باگهای هنگ بدون نشانه روبرو می شوید ، اول از همه به این چیزها فکر کنید :
Unpaired push / pop that leave a wrong return Address on the Stack.
دستورات جفت نشده ی push و pop که یک آدرس بازگشتی غلط را روی پشته ( بخشی از حافظه ی RAM کامپیوتر ) باقی می گذارند .
( منظور اینست که اگر روش صحیح استفاده از دستورات push و pop را ندانید و آنها را طبق قوانین مربوطه ننویسید یا یکی از آنها را فراموش کنید این اتفاقات خطرناک رخ می دهند . وحیدمی)
The Debugger is unable to point out this error, because the exception is raised out only after the Return.
دیباگر در اشاره کردن به این خطا ناتوان است زیرا ، استثنا فقط بعد از برگشت ، دفع می شود .
Then, you see the Debugger pointing usually to the last line of your Source because the pointed Code to be executed is then out of your real Code space, or, if hazard achieves in some Address really inside your Code, the pointed Instruction may be at any location in your Source.
آنگاه ، شما می بینید که دیباگر معمولا در حال اشاره به آخرین خط سورس تان می باشد زیرا کد مورد اشاره که باید اجرا شود در آن لحظه ، خارج از فضای واقعی کدتان می باشد و دستور مورد اشاره می تواند در هر مکانی در سورس برنامه تان باشد .
Confusion between Variables and Addresses.
اغتشاش بین متغیرها و آدرسها
RosAsm (and NASM) simplified notation help a lot at preventing such errors, but you may be confused when, for example, managing Variables that hold pointers to tables of Pointers.
راهنمای علامتگذاری ساده شده ی روسسم ( و نسم ) در جلوگیری از بروز این خطاها تا حد زیادی کمک می کند ، اما شما ممکن است در هنگام ، مثلا ، مدیریت متغیرهایی که اشاره گرهای به جدول اشاره گرها را نگه می دارند ، گیج و سردرگم شده باشید .
Then, there are many chances you will see the Debugger pointing you to a read or write Instruction with an Access-Violation Message.
آنگاه ، شانس های زیادی وجود دارند برای شما که ببینید دیباگر در حال اشاره کردن به شما به خواندن یا نوشتن دستورات با یک پیام خطای - دسترسی ، می باشد .
Bad Parameter in an API call.
پارامتر بد در یک فراخوانی تابع ویندوز .
(یعنی غلط نوشتن نام پارامترهای هر تابع و یا نوشتن آنها در جای غلط و به ترتیب غلط )
There is no medicine against this.
هیچ دارویی برای درمان این مشکل وجود ندارد .
( البته تحت ویندوز ، به دلیل سیستمهای چند لایه ی حفاظتی ، معمولا خطر چندانی بوجود نمی آید خصوصا در ویندوز 10 که شدیدا در مقابل قدرت زبان اسمبلی مقاومت می کند و اجازه نمی دهد زبان اسمبلی به مغز سیستم نفوذ کند . ولی احتیاط شرط عقل است زیرا بهرحال اسمبلی ، قدرتمندترین و با نفوذترین و انعطاف پذیرترین زبان برنامه نویسی دنیا می باشد و ممکن است بتواند به کرنل ویندوز 10 نفوذ کند پس باید با احتیاط رفتار کرد . وحیدمی)
Just test your new calls and carefully read the API Documentation.
در چنین شرایطی فقط فراخوانی های جدیدتان را آزمایش نمایید و با دقت مستندات مربوط به توابع ویندوز را مطالعه نمایید .
This documentation is sometimes bad, because it has been written by documentalists, instead of programmers, but my own experience has proven to me that I was, at least, as bad a reader than the documentalists were bad writers... Explaining such complicated stuff is not very easy.
این مستندات و اسناد توابع ویندوز ، برخی اوقات بد هستند زیرا توسط مستندنویسان نوشته شده اند ، بجای اینکه توسط برنامه نویسان نوشته شوند . اما تجربه ام به من ثابت کرده که این مستندات ، دستکم خودشان بد بودند نه اینکه مستندنویسان نویسندگان بدی بوده باشند . توضیح دادن چنین مواد پیچیده ای کار چندان آسانی نیست .
Bad Parameters Number in an API call.
تعداد غلط پارامتر در فراخوانی توابع ویندوز .
This results in the same error as the aforementioned Unpaired push / pop error, with the same (un)expected effect.
نتیجه ی این اشتباه ، ایجاد خطایی شبیه به خطای push/pop نامزدوج شده ی مذکور با همان تاثیر مورد انتظار یا غیرمورد انتظار می باشد .
Bad indices when scanning a flow of Data.
نشانها ( نمایه ها)ی بد در هنگام اسکن جریانی از داده .
Asm programmers have regularly to face the '+1/-1' dilemma.
برنامه نویسان اسمبلی معمولا مجبورند با معمای غیرقابل حل '+1/-1' روبرو شوند .
The Human brain (mine, at least) is poorly designed to deal with this problem:
مغز بشر ( حداقل ، در مورد من ) بطرز فقیرانه ای برای رسیدگی به این مشکل ، طراحی شده است (!!!) .
We have a Table beginning at 0A0000 Address. 5 Bytes of Data are stored in this Table.
ما یک جدول داریم که با آدرس 0A0000 شروع می شود . تعداد 5 بایت از داده در این جدول نگهداری می شوند .
At what Address is the last Value?
در چه آدرسی ، آخرین مقدار وجود دارد ؟
What is the next free Address?
آدرس آزاد بعدی چه هست ؟
What is the length of the Data Set?
طول مجموعه ی داده چقدر است ؟
... despite the fact that I began programming more than 30 years ago, I must say that I still solve these problems just like a baby would: Paper / Pencil / Mark-Points / Count.
با وجود این حقیقت که من برنامه نویسی را در بیش از 30 سال پیش شروع کردم ، من باید بگویم که من هنوز حل می کنم این مسائل را مانند یک کودک بدین روش: کاغذ / مداد/ نقاط نشانه گذاری / شمردن .
Generally speaking the best Debugger I ever wrote is the Hexprint Routine I provide in all BaseX.exe Files.
بهترین دیباگری که من تاکنون نوشته ام ، روتین Hexprint است که من آنرا در تمام فایلهای خانواده ی Base.exe عرضه کرده ام .
For bug hunting , Debuggers are usually a waste of time.
برای شکار باگ ، دیباگرها معمولا عامل اتلاف وقت هستند .
In most cases Hexprint will point out quickly, at least what is hanging (if not why, which may be a more complicated problem... but no Debugger will ever tell you why, as you may know...).
در بیشتر موارد ، روتین Hexprint ، به سرعت اشاره خواهد کرد ، حداقل به اینکه چه چیزی در حال هنگ کردن است ( اگر نگوید که چرا هنگ کرده است ؛ که می تواند یک مشکل پیچیده تری باشد ... اما هیچ دیباگری حتی به شما نمی گوید چرا چنین باگی رخ داده است ، نظر به اینکه شما ممکن است علت اش را بدانید.... )
The cases when you will have to spend more than two Minutes for fixing a bug, with Hexprint, will be very exceptional cases and very rare indeed.
موارد در زمانیکه شما مجبورید بیش از دو دقیقه وقت برای رفع یک باگ با کمک روتین Hexprint تلف کنید ، جزو موارد خیلی استثنایی و حقیقتا خیلی نایاب خواهند بود .
( یعنی با کمک این روتین Hexprint ، شما می توانید بسیاری از انواع باگها را به سرعت برطرف کنید و امکان اینکه این روتین قادر به رفع باگهای پیچیده نباشد جزو موارد نایاب و استثنایی می باشد . من خودم شخصا هیچ چیزی از این روتین نفهمیده ام و ترجیح می دهم که از دیباگر اصلی اسمبلر روسسم که دارای یک پنجره و محیط حرفه ای و دقیق است استفاده نمایم . چون در این پنجره می توانم چیزهای زیادی را کشف کرده و بسیاری از اسرار درون توابع ویندوز و حتی فایلهای کرنل ویندوز و اسرار درون پردازنده ی اینتل و حافظه رم کامپیوتر را متوجه می شوم . نمی خواهم بگویم که این روتین به درد نمی خورد بلکه می خواهم بگویم که این روتین هیچ چیزی را بصورت گرافیکی به ما نشان نمی دهد زیرا فقط از چند خط کد نامفهوم و گنگ تشکیل شده و هیچ پنجره و محیط گرافیکی برای دیباگر ایجاد نمی کند . ولی دیباگر اصلی روسسم با محیط حرفه ای که دارد عملا بصورت بصری ما را با کاربرد دقیق تمام دستورات زبان اسمبلی و توابع ویندوز و نیز با دستورات اسمبلی درون هر تابع ویندوز و دستورات اسمبلی مربوط به کرنل ویندوز و وقایع و رخدادهای حین باگ و سایر موارد مهم و ضروری ، آشنا می کند . لذا من خودم ترجیح می دهم که از دیباگر اصلی خود روسسم برای کشف اسرار و نیز دیباگ کردن استفاده نمایم که البته این روش یک روش استاندارد در میان تمام زبانهای برنامه نویسی سطح بالا و سطح پایین دنیا می باشد . روتین مذکور یکی از ابهامات اسمبلر روسسم می باشد و بسیاری از کارشناسان نتوانسته اند آنرا به درستی درک کنند . ضمنا معمای بالایی اصلا دشوار نیست و حتی بصورت ذهنی می توانید به تک تک سوالات پاسخ صحیح بدهید . عملا این بخش و این معما موجب فرار کاربران از زبان اسمبلی می شود و این اصلا کار خوبی نبود که ایشان انجام داد ضمنا اسمبلی می تواند هر نوع معما و رمز را برای ما حل کند و در دنیای نرم افزار ، غیرممکن ، غیرممکن است و امثال این معما را می توان براحتی حل کرد و چیز عجیبی نیست طرح کردن این معما از نظر من کار اشتباهی بود که رنه تورنویس مرتکب شد و موجب شد که برنامه نویسان از روسسم فراری شوند . کاری ندارم که در جای جای راهنمای اسمبلر روسسم آثار دیکتاتوری و به چالش کشاندن کاربران دیده می شود و این باعث شد خیلی ها از این اسمبلر متنفر شوند . وحیدمی )
~~~~~~~
sitemap:
https://vahidmy.blog.ir/sitemap.xml