فریمورک دات نت یک محیط اجراء با نام CLR)Common Language Runtime) را ارائه که مسئولیت مدیریت اجرای کد و تامین سرویس های لازم بمنظور پیاده سازی نرم افزار را برعهده دارد . CLR ، زیرساخت مستحکمی را بمنظورایجاد انواع نرم افزار در اختیار پیاده کنندگان قرار می دهد .
یک برنامه ASP.NET ، یک برنامه فرم های ویندوز ، یک سرویس وب ، یک برنامه مختص موبایل ، یک برنامه توزیعی و یا یک برنامه که چندین مدل از برنامه های فوق را با یکدیگر ترکیب می نماید ، نمونه هائی از برنامه هائی می باشند که می توان آنها را بر اساس زیرساخت ارائه شده ، پیاده سازی نمود.
CLR ، دارای مزایای متعددی بمنظور پیاده سازی سریع و آسان نرم افزار با قابلیت مهم ارتباط و یکپارچگی بین کدهای نوشته توسط زبانهای متفاوت برنامه نویسی است .
درمجموعه مقالاتی که در این زمینه ارائه خواهد شد به بررسی CLR ، خواهیم پرداخت .
CLR ، ابزاری ( Engine) است که دستورالعمل های IL)Intermediate Language) را بعنوان ورودی اخذ و در ادامه آنها را به دستورالعمل های زبان ماشین ترجمه و در نهایت آنان را اجراء می نماید. موضوع فوق ، بدین معنی نیست که CLR ، دستورالعمل ها را تفسیر می نماید. عبارت فوق ، بدین دلیل بیان شده است که بنوعی به این موضوع اشاره گردد که CLR ، محیط لازم بمنظور اجرای کد IL را فراهم می نماید. بمنظور نیل به اهداف مورد نظر خصوصا” : کارآمدی کدها و قابلیت حمل آنان ، هسته اجرائی می بایست، شرایط ومحیط لازم بمنظور ایجاد کد با لحاظ نمودن اهداف موردنظر ( کارآمد ، قابلیت حمل) را ارائه نماید. کارآمدی کدها ، یکی از مسائل کلیدی در رابطه با محیط اجراء خواهد بود. اگر کد، با سرعت قابل قبول اجراء نگردد ، تمام ویژگی های دیگر موجود در سیستم ، تحت الشعاع قرار خواهند گرفت .
قابلیت حمل ، امکان استفاده از نرم افزار را مستقل از نوع پردازنده و دستگاه فراهم می نماید. بنابراین افزایش تعداد پردازنده ها و دستگاههائی که CLR می تواند بر روی آنها اجراء گردد، همواره دارای اهمیت خاص خود خواهد بود. ماکروسافت و اینتل برای مدت زمان زیادی ، دارای همکاری مناسبی در عرصه تجارت بودند. ماکروسافت کم و بیش از خط پردازنده های اینتل بمنظور اجراء نرم افزارهای خود ، استفاده می کرد.بدین ترتیب ، ماکروسافت ، بدون وجود نگرانی ( حمایت از معماری چندین پردازنده ای و دستورالعمل های مربوطه ) ، اقدام به ایجاد و پیاد ه سازی نرم افزار می نمود. شرکت ماکروسافت هرگز نگران ارائه یک نسخه خاص از محصولات خود برای یک نسخه خاص از پردازنده های Motoral 68XXX ، نبود ، چراکه اصولا” آنها را حمایت نمی کرد . بروز محدودیت در حمایت از پردازنده ها در زمان انتقال از برنامه ها یمبتنی بر Win16 به Win32، بعنوان یک مسئله مهم ،مطرح گردید. ( ما عملا” دارای API با نام Win16 نبوده ایم ، ولی می توان این واژه را برای API قبل از Win32 استفاده کرد) . ماکروسافت اگر می خواهد همچنان بعنوان یکی از شرکت های فعال در زمینه تولید و طراحی نرم افزار در سطح جهان مطرح باشد ، می بایست تدابیر لازم در خصوص قابلیت حمل نرم افزارهای پیاده سازی شده خود را بر روی محیط های متفاوت فراهم نماید. باتوجه به تغییرات بنیادین و مهم در طراحی و پیاده سازی برنامه های مبتنی بر وب طی سالیان اخیر و ضرورت استفاده از دستگاههای متعدد بمنظور ارتباط به اینترنت و در نهایت استفاده از خدمات برنامه های موجود ، ما با واقعیت بزرگ دیگری نیز مواجه هستیم و آن اینکه هر یک از دستگاههای موجود ( تلفن های موبایل ، کامپیوترهای hand-held ، tablet ، ) دارای معماری و پردازنده اختصاصی خود می باشند. با توجه به وضعیت موجود، می بایست تمهیدات و تدابیر خاصی در رابطه با طراحی و پیاده سازی اندیشیده گردد که ماحصل آن قابلیت حمل نرم افزار از یک معماری خاص به معماری دیگر باشد .
ماکروسافت نیز در صدد حضوری فعال تر و ارائه نرم افزار در رابطه با دستگاه های فوق ، است ، بدیهی است می بایست اقدامی صورت می گرفت که پاسخگوی واقعیت های جدید صنعت نرم افزارباشد . ماکروسافت در پاسخ به محدودیت های موجود، خواسته های جدید و حل مشکل قابلیت حمل به سایر پردازنده ها ، تصمیم به ایجاد یک محیط اجراء و یا CLR نمود ه است .
در ادامه این مقاله ، قصد داریم بدون درگیر شدن به جزیئات مربوطه ، به بررسی محیط اجراء پرداخته امکانات آن را در رابطه با اجرای برنامه های managed ، بررسی نمائیم .
مروری بر Runtime
قبل از دات نت، یک برنامه اجرائی معمولا” بصورت یک فایل با انشعاب exe. ارائه می گردید ( برنامه صرفا” شامل یک فایل بود) . بمنظور اجراء کارآمد تمامی سیستم ، برنامه می بایست از کدهائی استفاده نماید که بصورت اشتراکی باشند ( معمولا” یک فایل با انشعاب dll. ) اگر در زمان استفاده از کد مشترک ، مسائلی ایجاد می گردید، می توان از یک کتابخانه وارداتی استفاده و یا یک DLL را در زمان اجراء ، load کرد ( با استفاده از LoadLibrary,LoadLibraryEx و GetProcAddress )
در دات نت ، واحد اجراء و بکارگیری ، اسمبلی (Assembly ) است . فرآیند اجراء، همواره با یک اسمبلی که دارای انشعاب exe . می باشد ، آغاز می گردد . برنامه می تواند از کد اشتراکی بکمک Importing اسمبلی که شامل کد مشترک بهمراه یک مرجع صریح است ، استفاده نماید ( برای اضافه نمودن مرجع ، می توان از AddReference در ویژوال استودیو دات نت استفاده کرد ) برنامه ها همچنین می توانند با استفاده از Assembly.Load و یا Assembly.loadForm ، اقدام به استقرار یک اسمبلی در حافظه نمایند .
در ادامه ، لازم است با برخی از اصطلاحات آشنا و تعریف مناسبی از آنها را ارائه نمائیم .
اسمبلی(Assembly ) . اسمبلی واحد اولیه بکارگیری نرم افزار در فریمورک دات نت است .یک اسمبلی می تواند شامل مراجعی به سایر اسمبلی ها و ماژول ها باشد .
ماژول( Module ) . ماژول، فایلی شامل محتویات اجرائی است . یک اسمبلی می تواند یک و یا بیش از یک ماژول را کپسوله نماید. یک ماژول بدون اینکه یک اسمبلی به آن مراجعه ای داشته باشد ، Stand alone نمی گردد . کلاسی در کنابخانه کلاس پایه ( System) ، مسئولیت کپسوله نمودن اکثر ویژگی های یک ” ماژول ” را برعهده دارد ( مشابه اسمبلی ). این کلاس Module ، نام دارد.
APPDomain ، بعنوان یک پردازه کم حجم ( سبک ) در نظر گرفته می شود.قبل از دات نت ، ایزولاسیون از طریق جداسازی پردازش ها از یکدیگر و بکمک سیستم عامل انجام می گردید. اگر پردازه ای ، عملیات نامشحص و تعریف نشده ای را انجام که باعث بروز مشکل برای ادامه حیات خود می گردید ، حرکت وی باعث بروز اختلال در تمام سیستم نشده و صرفا” مشکل بوجود آمده در ارتباط با پردازه خواهد بود . با توجه به اینکه “نوع ها” ،بصورت کاملا” هدایت شده توسط فریمورک دات نت کنترل می گردند ، می توان از روش هائی بمنظورپیاده سازی سطح مشابهی ایزولاسیون در ارتباط با یک پردازه استفاده کرد . این روش Application Domain ویا AppDomain نامیده می شود. همانند اسمبلی و ماژول ، یک کلاس در کتابخانه کلاس فریمورک دات نت ، اکثر ویژگی ها و پتانسیل های مربوط به یک Application Domain را کپسوله می نماید. کلاس فوق ، AppDomain نامیده شده و در namespace با نام System قرار دارد .
IL یا MSIL . واژه IL از Intermediate Language و MSIL از Microsoft Intermediate Language ، اقتباس شده اند . IL ، زبانی است که اسمبلی ها توسط آن نوشته شده و شامل مجموعه ای از دستورالعمل هائی است که کد مربوط به برنامه را ارائه می نمایند. به زبان فوق بدین دلیل بدین دلیل ” میانی ” ( Intermediate ) ، اطلاق می گردد ، چون هنوز بصورت native code درنیامده است . در زمان مورد نطر ، کدهای IL توسط کمپایلر JIT به native code ، ترجمه خواهند شد .
JIT . واژه JIT از کلمات Just-In-Time اقتباس شده است . از کمپایلر فوق ، بمنظور ترجمه کدهای IL به native code استفاده می شود.
پس ازاستقرار کد در حافظه ( Loading ) ، امکان اجرای آنان فراهم می گردد . از این مرحله به بعد ( آغاز عملیات اجراء کد ) ، تفاوت محسوسی را بین برنامه های قدیمی ( قبل از دات نت ) و برنامه های جدید ( دات نت ) ، شاهد خواهیم بود . در حالت کد غیرمدیریت یافته ( Unmanaged) ، کمپایلر و linker بر روی کدهای مربوطه عملیات خود را آغاز و آنها را به native code تبدیل می نمایند . بدین ترتیب ،دستورالعمل ها می توانند بلافاصله اجراء گردند. لازم است به این نکته مهم اشاره گردد که در صورتیکه قصد استفاده از برنامه نوشته شده بر روی محیط های متفاوت ( سایر پلات فرم ها ) وجود داشته باشد ، می بایست برای هر یک نسخه ای جداگانه را کمپایل کرد. در برخی حالات ، امکان ایجاد و ترجمه نسخه های متعدد بمنظور اجراء بر روی محیط های متفاوت ، امری مطلوب بنظر نمی رسد ، در چنین مواردی سعی می گردد ، صرفا” یک نسخه ارائه گردد. نسخه فوق ، بگونه ای طراحی و پیاده سازی می گردد که بتواند با محیط های متفاوت سازگار باشد . بدین ترتیب ، امکان اجراء نرم افزارهای تولیدی در محیط های متفاوت ، فراهم خواهد شد . وجود پتانسیل در بطن یک دستگاه سخت افزاری یک موضوع است و ارائه برنامه ای که زمینه بهره برداری از پتانسیل های مربوطه را فراهم و برنامه ای که از پتانسیل های دستگاه فوق ، در نهایت استفاده می نماید ، موضوعات دیگری است . مثلا” امروز ما کمتر شاهد ارائه نرم افزار از طرف شرکت های تولید کننده ای می باشیم که تاکید و اصرار بر استفاده از یک محیط سخت افزاری نظیر وجود یک ” شتاب دهنده گرافیک ” ، داشته باشند . در چنین موارد علاوه بر اینکه تولید کننده ” شتاب دهنده گرافیک ” ، می بایست برای هر ” کارت شتاب دهنده گرافیک ” ، برنامه ای خاص را ارائه نماید ، بلکه همچنین پیاده کنندگان می بایست از برناهه های مجزائی برای هر یک از کارت ها ی عرضه شده ، استفاده نمایند . ” شتاب دهنده گرافیک ” ، صرفا” یک نمونه در این رابطه بوده و می توان به مواردی دیگر نظیر : disk cache,memory cache ، شبکه های با سرعت بالا ، سیستم های مبتنی بر چندین پردازنده و سخت افزارهای خاص بمنظور پردازش تصاویر، اشاره کرد .
یکی از اولین مراحلی که CLR در ارتباط با اجراء یک برنامه انجام می دهد ، بررسی متدی است که می بایست اجراء گردد ( آیا به native code ،تبدیل شده است ؟) . در صورتیکه متد به native code ، تبدیل نشده باشد ، کد موجود در متد بصورت JITd) Just – In – time compild) خواهد بود . تاخیر در ترجمه یک متد ، دارای دو مزیت است :
یک شرکت می تواند نسخه ای از نرم افزار تولید ی خود را براحتی بر روی محیط مورد نظر خود منتقل ( در محیط فوق نسخه ای از CLR نصب شده است ) و از CLR بمنظور مدیریت و سفارشی نمودن کدها، متناسب با محیط سخت افزاری مربوطه ، استفاده نماید .
کمپایلرهای JIT قادر به استفاده از مزایای بهینه سازی می باشند . بدین ترتیب ، امکان اجراء سریعتر یک برنامه نسبت به یک برنامه همه منظور( نسخه unmanaged برنامه ) ، فراهم می گردد . سیستم هائی که دارای پردازنده های ۶۴ بیتی می باشند ، دارای یک مد ” سازگاری ” خواهند بود که به برنامه های سی و دو بیتی اجازه می دهد بدون اعمال تغییرات بر روی یک پردازنده ۶۴ بیتی اجراء گردند .اگر برنامه ای به IL ترجمه گردد ، می تواند از مزایای پردازش ۶۴ بیتی بهره مند گردد (موتور JIT ، قادر به target نمودن پردازنده جدید ۶۴ بیتی است) .
فرآیند استقرار یک متد در حافطه ( Loading ) و ترجمه آن ، در صورت نیاز تکرار تا زمانیکه تمام متدها ی موجود در برنامه ترجمه و یا برنامه متوقف گردد .
شروع یک متد
CLR ، درارتباط با هر متد به اطلاعات زیر نیاز خواهد داشت . تمامی اطلاعات مورد نیاز CLR از طریق متادیتا ( Metadate) موجود در هر اسمبلی در دسترس و ارائه خواهد شد .
دستورالعمل ها . CLR ، نیازمند لیستی از دستورالعمل های MSIL است . هر متد دارای اشاره گری به مجموعه دستوراتی است که بعنوان بخشی از متا دیتا ی مورد نظری است که به آن مرتبط شده است.
Signature . هر متد دارای یک Signature است و CLR نیازمند استفاده از یک signature برای هر متد است . signature ، برگرداندن نوع ، تعداد پارامتر و نوع پارامترها را تشریح می نماید.
Exception Handling Array . دستورالعمل خاصی از IL که مربوط به برخورد با exception باشد ، وجود ندارد . در این رابطه از دایرکتیوهائی خاص در مقابل دستورالعمل های IL ، استفاده می گردد . در مقابل دستورالمل های Exception-handling ، اسمبلی دارای لیستی از exceptions است . لیست فوق، شامل نوع exception ، یک آدرس offest به اولین دستورالعمل پس از بلاک exception try ، طول مربوط به بلاک try ، است . لیست فوق ، همچنین شامل آفست به handler code ، طول handler code ، و یک token که مسئول تشریح کلاسی است که از آن بمنظور کپسوله نمودن exception استفاده می گردد .
اندازه Evaulation stack . داده فوق ، از طریق متا دیتا اسمبلی قابل دسترس خواهد بود. می توان آن را از طریق maxstack x در لیست ILDASM مشاهده نمود. مقدار x ، اندازه پشته مورد نظر است . اندازه منطقی پشته که توسط x ، مشخص شده است ، حداکثر آیتم هائی را که می توان در پشته ، مستقر ( Push ) نمود ، مشخص می نماید. اندازه فیزیکی آیتم ها و پشته به CLR واگذار تا در زمان اجراء آن را مشخص نماید (زمانیکه متد JITd است ) .
تشریح بردارهای محلی . هر متد نیازمند تعریف و ذخیره سازی محلی آیتم های مورد نیاز است. evaluation stack ،( برداری منطقی از آیتم ها بهمراه نوع هر آیتم) و استفاده از یک flag در متادیتا بمنظور مشخص نمودن ضرورت مقداردهی اولیه ( مقدارصفر ) متغیرهای محلی در ابتدای فراخوانی یک متد ، نمونه هائی در این زمینه می باشند.
با استفاده از اطلاعات فوق ، CLR ، قادر به ایجاد یک abstraction از چیزی خواهد بود که native stack frame است. عموما” هر پردازنده و یا ماشین یک stack frame را شکل که شامل آرگومانها ( پارامترها ) و یا مرجع به آرگومانها ی مربوط به متد است . در وضعیتی مشابه ، متغیرهای برگردانده شده در stack frame بر اساس فراخوانی که وابسته به یک پردازنده و یا ماشین خاص است ، ذخیره می گردند. اولویت پارامترهای ورودی و خروجی در رابطه با یک ماشین خاص ، مشخص می گردد . با توجه به اینکه تمام اطلاعات مورد نیاز برای هر متد در دسترس است ، CLR ، قادر به تشخیص وضعیت مورد نظر stack frame ، در زمان اجراء است .
فراخوانی یک متد بگونه ای انجام خواهد شد که CLR دارای حداقل کنترل در رابطه با اجراء متد و حالت آن باشد .زمانیکه CLR ، یک متد را فرامی خواند ، متد و حالت آن تحت کنترل CLR خواهد بود ( Thread of control ) .
