Payamvdn/NorthPersian_fa_wiki huggingface dataset:
کسل های بیشتری وجود دارد، پیک (قله) در سطح روشنایی خاصی بالاتر است. ۲)هیستوگرام رنگ چیست؟. هیستوگرام رنگ یک تصویر نشان دهنده نحوهٔ توزیع ترکیب رنگ در تصویر است. بافت نگار رنگ، انواع مختلف رنگی هایی را که در تصویر ظاهر می شوند و تعداد پیکسل ها در هر نوع رنگ را نشان می دهد. رابطه بین یک هیستوگرام رنگ و یک هیستوگرام روشنایی این است که یک هیستوگرام رنگ نیز می تواند به عنوان «هیستوگرام سه نوره» بیان شود، که هر کدام نشان دهنده توزیع روشنایی در هر کانال رنگی قرمز / سبز / آبی است. ویژگی های هیستوگرام رنگ. هیستوگرام رنگ تنها بر نسبت تعداد انواع رنگ ها، صرف نظر از مکان فضایی رنگ ها تمرکز می کند. مقادیر هیستوگرام رنگ داده های آماری هستند. آن ها توزیع آماری رنگ ها و تناژ اصلی یک تصویر را نشان می دهند. به طور کلی، از آنجایی که توزیع رنگی پیش زمینه و پس زمینه در یک تصویر متفاوت است، ممکن است توزیع دوبعدی در هیستوگرام وجود داشته باشد. برای هیستوگرام روشنایی، به تنهایی هیچ هیستوگرام کاملی وجود ندارد و هیستوگرام تنها می تواند بگوید که آیا تصویر بیش از حد نوردهی شده است یا نه. اما در این حال نیز مواقعی وجود دارد که با مشاهدهٔ
هیستوگرام رنگ تصور می شود نوردهی تصویر بیش از حد است، اما در واقعیت اینگونه نیست. اصول تشکیل هیستوگرام رنگ. تشکیل یک هیستوگرام رنگ بسیار ساده است. از تعریف بالا، می توانیم به سادگی تعداد پیکسل ها را برای هر ۲۵۶ مقیاس در هر سه کانال RGB شمارش کنیم و آنها را بر روی ۳ نمودار ستونی مجزا قرار دهیم. به طور کلی یک هیستوگرام رنگی براساس یک فضای رنگ خاص مانند RGB یا HSV است. وقتی پیکسل های مختلف رنگ را در تصویر محاسبه می کنیم، اگر فضای رنگی بزرگ باشد، ابتدا می توانیم فضای رنگ را به تعداد مشخصی از فواصل کوچک تقسیم کنیم. هر یک از فواصل باینری نامیده می شود. این فرایند کوانتومی رنگ است. سپس، با شمارش تعداد پیکسل ها در هر سطل، هیستوگرام رنگ تصویر را دریافت می کنیم. مراحل به هم پیوستن اصول را می توان در مثال ۲ مشاهده کرد. مثال ها. مثال ۱. تصویر زیر یک گربه (یک نسخه اصلی و یک نسخه که برای آسان ساختن اهداف هیستوگرام به ۲۵۶ رنگ کاهش یافته است) را نشان می دهد. داده های زیر نشان دهنده یک هیستوگرام رنگی در فضای رنگی RGB، با استفاده از چهار سطل (باین) است. باین ۰ مربوط به شدت ۰–۶۳ است، باین ۱ ۶۴–۱۲۷ است، باین ۲ ۱۲۸–۱۹۱ است، و بای
ن ۳ است ۱۹۲–۲۵۵ است. مثال ۲. برنامه در دوربین: امروزه برخی از دوربین ها توانایی نمایش هیستوگرام ۳ رنگه را هنگام عکس گرفتن دارند. ما می توانیم در هر یک از هیستوگرام های ۳ رنگهٔ RGB برش هارا (مرزها را در قسمت سیاه یا سفید مقیاس) بررسی کنیم. اگر یک یا چند برش را فقط در یک کانال از ۳ کانال RGB پیدا کنیم، آنگاه جزئیات رنگ آن را از دست می دهیم. برای روشن شدن موضوع، این مثال را در نظر بگیرید: ۱ ما می دانیم که هر یک از سه کانال R, G، B دارای طیف وسیعی از مقادیر در بازهٔ ۰–۲۵۵ (۸ بیتی) است؛ بنابراین یک عکس با محدوده روشنایی ۰–۲۵۵ داریم. ۲ فرض کنید عکس ما از ۴ بلوک که در کنار هم قرار گرفته اند ساخته شده است و ما درجه روشنایی هر یک از ۴ بلوک را ،۱۰، ۱۰۰، ۲۰۵، ۲۴۵ تنظیم می کنیم؛ بنابراین، تصویر مانند اولین شکل در سمت چپ خواهد بود. ۳ سپس، تصویر را نور دهی می کنیم، با این کار میزان روشنایی هر بلوک به ۱۰ افزایش یافته است؛ بنابراین، مقیاس روشنایی برای هر یک از ۴ بلوک جدید عکس ۲۰، ۱۱۰، ۲۱۵، ۲۵۵ است. سپس، تصویر شبیه شکل دوم در سمت چپ است. تفاوت زیادی بین شکل ۸ و شکل ۹ وجود ندارد، تمام چیزی که ما می بینیم این است که کل تصویر رو
شن می شود (کنتراست برای هر یک از بلوک ها به همان صورت باقی می ماند). ۴ حالا ما دوباره عکس اصلی را نوردهی می کنیم، در این صورت میزان روشنایی هر بلوک به ۵۰ افزایش می یابد؛ بنابراین، مقیاس روشنایی برای هر یک از ۴ بلوک جدید عکس ۶۰، ۱۵۰، ۲۵۵، ۲۵۵ است. تصویر جدید اکنون به شکل سوم در سمت چپ ظاهر می شود. توجه داشته باشید که مقیاس برای بلوک آخر ۲۵۵ به جای ۲۹۵ است، ۲۵۵ حد بالاست و در نتیجه آخرین بلوک قطع می شود! هنگامی که این اتفاق می افتد، ما کنتراست ۲ بلوک آخر را از دست می دهیم و بنابراین نمی توانیم تصویر را با هیچ گونه تنظیمی بازیابی کنیم. به این نتیجه رسیدیم که هنگام عکس گرفتن با یک دوربین که قرار است هیستوگرام را نمایش دهد، همیشه بالاترین تناژ در تصویر باید زیر حد بالا یعنی ۲۵۵ در هیستوگرام نگه داشته شود تا جزئیات از دست نروند. نقاط ضعف و بقیهٔ رویکردها. نقطه ضعف اصلی هیستوگرام ها برای طبقه بندی این است که نمایشی وابسته به رنگ جسم مورد مطالعه دارد، و فرم شکل و بافت آن را نادیده می گیرد. هیستوگرام های رنگی که برای نمایش اطلاعات رنگی به کار می روند ممکن است برای دو تصویر با محتوای شیء مختلف یکسان باشد. برعکس، ممکن ا
ست تفاوت اشیا با اطلاعات فضایی یا فرمی مختلف، اما رنگ های یکسان براساس مقایسه هیستوگرام های رنگ، قابل تشخیص نباشد. در نتیجه، هیچ راهی برای تشخیص فنجان قرمز و سفید از یک بشقاب قرمز و سفید وجود ندارد. به بیان دیگر، الگوریتم های مبتنی بر هیستوگرام هیچ درکی از مفهوم «فنجان» ندارند که از روی آن یک مدل قرمز و سفید ساخته شده (و با توجه به آن)، یک فنجان آبی و سفید (به عنوان فنجان) تشخیص داده شود. مشکل دیگر این است که هیستوگرام های رنگی دارای حساسیت بالا نسبت به تداخل های noisy مانند تغییرات شدت نور و اشتباهات کوانتیزایی هستند. ابعاد زیاد (سطلها) در هیستوگرام های رنگی نیز یکی دیگر از مسائل هستند. برخی از ویژگی های فضایی هیستوگرام رنگ بیش از یک صد بعد را اشغال می کنند. برخی از راه حل های پیشنهادی، استفاده از تقاطع هیستوگرام رنگی، نشان دادن ثابت رنگ، هیستوگرام رنگ تجمعی، فاصله درجه دوم و همبستگی رنگ است. گرچه اشکالات استفاده از هیستوگرام ها برای نمایه سازی و طبقه بندی وجود دارد، استفاده از شاخصهٔ رنگ در یک سیستم زمان واقعی دارای مزایایی نیز هست. یکی از آن مزایا این است که اطلاعات رنگی در مقایسه با سایر متغیرها سریعتر اس
ت. در برخی موارد نشان داده شده است که رنگ می تواند یک روش کارآمد برای شناسایی اشیاء با مکان و ظاهر شناخته شده باشد. تحقیقات بیشتر پیرامون رابطهٔ بین داده های هیستوگرام رنگی با خواص فیزیکی اشیاء در یک تصویر نشان داده است که نه تنها رنگ و روشنایی شیء، بلکه میزان همواری سطح و هندسه تصویر نیز به هیستوگرام مربوط می شوند. در نتیجه با این نمودار (با توجه به داده ها) می توان تخمین پیشرفته ای از میزان روشنایی و رنگ شی ارائه داد. معمولاً برای محاسبه درجه بندی شباهت تصویر، از فاصله اقلیدس، تقاطع هیستوگرام، یا فاصله کوزین یا فاصله درجه دوم استفاده می شود. هر یک از این مقادیر، به تنهایی میزان شباهت دو تصویر را نشان نمی دهد؛ در نتیجه استفاده از آنها هنگامی مفید است که در مقایسه با سایر مقادیر مشابه استفاده شود. این به این دلیل است که تمام پیاده سازی های عملی تصویر بازیابی مبتنی بر محتوا باید محاسبات تمام تصاویر را از پایگاه داده کامل کند و این (عملیات)، ضعف اصلی این پیاده سازی ها است. یک روش دیگر برای نشان دادن محتوای تصویر رنگ هیستوگرام رنگ دو بعدی است. نمودار هیستوگرام دو بعدی رابطه بین رنگ های جفت پیکسل (نه تنها جزء نور
پردازی) را در نظر می گیرد. یک هیستوگرام رنگ دو بعدی آرایه ای دو بعدی است. اندازه هر بعد، تعداد رنگهایی است که در فاز سیگنال رنگ استفاده شده اند. این آرایه ها همانند ماتریس عمل می کنند، هر عنصر که تعدادی عادی از جفت پیکسل را ذخیره می کند، با هر رنگ متناظر با اندیس یک عنصر در هر محله پیکسل قرار می گیرند. برای مقایسه هیستوگرام های رنگ دو بعدی، پیشنهاد می شود محاسبات مربوط به همبستگی آنها را انجام دهید، زیرا همان طور که قبلاً شرح داده شد، یک بردار تصادفی (به عبارت دیگر، یک مقدار تصادفی چند بعدی) ساخته شده است. هنگام ایجاد مجموعه ای از تصاویر نهایی، تصاویر باید در جهت کاهش ضریب همبستگی مرتب شوند. ضریب همبستگی نیز ممکن است برای مقایسه هیستوگرام رنگ استفاده شود. نتایج بازیابی با ضریب همبستگی بهتر از سایر معیارهاست. هیستوگرام شدت داده های مداوم. ایده یک هیستوگرام شدت را می توان به داده های پیوسته (مانند) سیگنال های صوتی نشان داده شده توسط توابع حقیقی یا تصاویر نمایش داده شده توسط توابع با دامنه دو بعدی تعمیم داد. در نظر بگیرید: formula_1 سپس عملگر هیستوگرام تجمعی،formula_2، به شکل زیر تعریف می شود: formula_4 یک انداز
ه لبگ از مقادیر است. formula_5 در اینجا یک تابع حقیقی است. بافت نگار (هیستوگرام) غیر تجمعی، به عنوان مشتق آن تعریف می شود.
بن بن یک شیرینی شیرین یا کوچک است مشخصا نان کوچکی که در شکلات غلطانده شده. این واژه از زبان فرانسوی گرفته شده و از قرن هفدهم که این شیرینی ها در دربار فرانسه درست می شده رایج شده است. واژه بن در زبان فرانسوی به معنای خوب است و بن بن تکرار این واژه است.
راز جنایت () یا معمای قتل یک فیلم کمدی-معمایی به کارگردانی کایل نیواچک با بازی آدام سندلر، جنیفر آنیستون و لوک ایوانز است. فیلم زن و شوهری را دنبال می کند که در تحقیق یک قتل در قایق تفریحی یک میلیاردر گرفتار می شوند. این فیلم در ۱۴ ژوئن ۲۰۱۹ از طریقنتفلیکس منتشر شد و نقدهای متفاوتی از منتقدان دریافت کرد. دنباله این فیلم در سال ۲۰۲۳ با عنوان راز جنایت ۲ منتشر شد. چکیده داستان. یک بازرس پلیس نیویورک به همراه همسرش برای ماه عسل اروپا به سفر می رود. آنها در هواپیمای خود با مردی مرموز آشنا می شوند که آنها را به یک شب نشینی خانوادگی دعوت می کند که در گروه کوچکی در کشتی مجلل یک میلیاردر سالخورده برگزار می شود. هنگامی که مرد ثروتمند به قتل می رسد، آنها مظنون اصلی مأمور اینترپل لوران دلاکروا می شوند.
کتابخانه پیوند پویا (یا DLL)یک فرمت استاندارد پیاده سازی شده توسط مایکروسافت از مفهوم کتابخانه های مشترک در سیستم عامل های مایکروسافت ویندوز و OS / 2 است. این کتابخانه ها معمولاً دارای فایل های codice_1، codice_2 (برای کتابخانه های حاوی کنترل های اکتیو ایکس) یا codice_3 (برای رانندگان سیستم میراث) هستند. فرمت های فایل DLLها همانند فایل های ویندوز EXE است - یعنی قابل اجرا و قابل حمل (یا PE) برای ویندوزهای ۳۲ بیتی و ۶۴ بیتی و NE)New Executable) برای ویندوزهای ۱۶ بیتی. همانند EXEها، DLLها می توانند شامل کد، داده ها و منابع در هر ترکیبی از آن ها باشند. فایلهای داده با فرمت فایل DLL، اما با پسوندهای فایلی مختلف که احتمالاً هم فقط شامل بخش منابع باشند، می توانند "منابع DLL" نامیده شوند. نمونه هایی از چنین DLL شامل "آیکون کتابخانه هاست که" گاهی اوقات دارای پسوندcodice_4و فایل های فونت، که دارای پسوندهای codice_5 و codice_6 هستند، می شود. به عبارت دیگر برنامه نویسان می توانند توابعی مورد نیاز خود که در فایل های DLL قرار دارند را به برنامه خود لینک کنند و از آن استفاده کنند. از این فایل ها می توان در چندین برنامه به ص
ورت همزمان هم استفاده کرد و در نتیجه این کار باعث افزایش کارایی برنامه نویسان و استاندارد درسیستم عامل می شود. پس زمینهٔ DLL. اولین نسخه های مایکروسافت ویندوز، برنامه هارا در یک فضای آدرس واحد، باهم اجرا می کرد. هر برنامه برای این درست شده بود تا به این صورت همکاری کند که CPU را به برنامه های دیگر هم برساند (yield کند)، تا رابط کاربری گرافیکی (GUI) بتواند چند کا را با هم انجام دهد و حداکثر پاسخگویی را داشته باشد. تمام عملیات سیستم عامل توسط سیستم عامل پایه ارائه شده است: MS-DOS. تمام خدمات سطح بالا توسط کتابخانه های ویندوز، همان "DLL"ها، ارائه شده است. API طراحی، رابط گرافیکی دستگاه (GDI)، در یک DLL با نام codice_7 codice_8 پیاده سازی شده است، رابط کاربر در codice_9 codice_8 . این لایه های اضافی در بالای DOS باید در همه برنامه های در حال اجرای ویندوز به اشتراک گذاشته می شد، نه فقط برای فعال کردن ویندوز برای کار در یک ماشین با کمتر از یک مگابایت RAM، بلکه برای فعال کردن برنامه ها برای همکاری با یکدیگر. کد در GDI نیاز داشت تا دستورات رسم را به یکسری عملیات در دستگاه های خاص ترجمه کند. در صفحه نمایش، باید پیکسل
ها را در بافر فریم مورد استفاده قرار می داد. هنگام طراحی به یک چاپگر، درخواست API باید به درخواست هایی به یک چاپگر تبدیل می شد. اگر چه می توانست امکان پذیر باشد که پشتیبانی سخت افزاری برای مجموعه محدودی از دستگاه ها (مانند صفحه نمایش رنگی گرافیک آداپتور، پرینتر لیزریجت چاپگر فرمان زبان) فراهم شود، مایکروسافت رویکردی متفاوت انتخاب کرد. GDI با بارگیری قطعات مختلفی از کد، به نام " درایور دستگاه "، برای کار با دستگاه های خروجی مختلف کار می کرد. همان مفهوم معماری که GDI را قادر ساخت تا دستگاهای درایور مختلف بار شوند، همان است که به ویندوز شل (windows shell) اجازه داد تا برنامه های مختلف ویندوز را بارگذاری کند و برای این برنامه ها که بتوانند APIها را از کتابخانه های مشترک USER و GDI فراخوانی کنند. آن مفهوم «پیوند پویا» نام داشت. در یک کتابخانه «استاتیک» معمولی (که مشترک(shared) نباشد)، به سادگی بخش های کد به برنامهٔ فراخوانی شده اضافه می شوند، زمانی که فایل اجرایی آن در مرحله «اتصال» ساخته شده است؛ اگر دو برنامه با یک تابع را صدا بزنند، آن تابع در هر دو برنامه، در مرحله اتصال هر دو، گنجانده می شود. با پیوند پویا، ک
د مشترک، در یک فایل جداگانه قرار می گیرد. برنامه هایی که این پرونده را فراخوانی می کنند در زمان اجرا، با سیستم عامل (یا، در مورد نسخه های اولیه ویندوز، OS-extension)، با اتصال به آن، مرتبط می شوند. برای نسخه های اولیه ویندوز (۱٫۰ تا ۳٫۱۱)، DLLها پایه و اساس کل رابط های کاربری گرافیکی (GUI) بودند. به همین ترتیب، درایورهای نمایش صرفاً فقط DLLهایی با پسوند DRV بودند که برنامه های پیاده سازی شدهٔ سفارشی از همان طراحی API را از طریق یک دستگاه درایور متحد رابط (DDI) فراهم می کرد و "رسم (GDI)" و " USER) GUI)" همان APIها صرفاً یکسری فراخوانی تابع بودند که توسط GDI و USER و سیستم DLLها با پسوند .EXE صادر شدند. مفهوم ساخت سیستم عامل از مجموعه ای از کتابخانه های بارگذاری شده به صورت پویا، یک مفهوم اصلی ویندوز است که ادامه می یابد. DLLها مزایای استاندارد کتابخانه های به اشتراک گذاشته شده، مانند ماژولار بودن را فراهم می کنند. ماژولار بودن اجازه می دهد تا تغییرات در کد و داده ها در یک DLL خود درج و پر شده ای که توسط تعدادی نرم افزار مختلف بدون ایجاد هیچ تغییری در خود نرم افزارها به اشتراک گذاشته شده است، صورت گیرد. یکی دیگ
ر از مزایای ماژولار بودن استفاده از رابط های عمومی برای پلاگ-این ها است. یک رابط واحد ممکن است توسعه یابد، که اجازه می دهد که ماژول های قدیمی و جدید به طور یکپارچه با هم در زمان اجرا متحد شوند و تبدیل شوند به برنامه های از قبل وجود داشته، بدون هیچ گونه تغییری در خود نرم افزار. این مفهوم توسعه پویا به بیشترین حد خود، با مدل Object Component، پایهٔ ActiveX، رسیده است. در ویندوز x.1، 2.x و 3.x، تمام نرم افزارهای ویندوز یک فضای آدرس حافظه را به اشتراک می گذاشتند. یک DLL فقط یک بار به این فضای آدرس بارگذاری شد. از آن پس، تمام برنامه هایی که از کتابخانه استفاده می کردند می توانستند به آن دسترسی پیدا کنند. داده های کتابخانه در همه برنامه ها به اشتراک گذاشته شده است. این می تواند به عنوان یک شکل غیرمستقیم ارتباطات بین فرایند مورد استفاده قرار گیرد، یا می تواند به طور تصادفی برنامه های مختلف را فاسد کند. با معرفی کتابخانه های ۳۲ بیتی در ویندوز ۹۵، هر فرایند در فضای آدرس خود اجرا می شود. در حالی که کد DLL ممکن است به اشتراک گذاشته شود، داده ها خصوصی هستند مگر اینکه داده های به اشتراک گذاشته شده، به طور صریح از سوی کتاب
خانه درخواست شوند. با توجه به این موضوع، نوارهای بزرگی از کتابخانه های ۱۶ بیتی از ویندوز ۹۵، ویندوز ۹۸ و ویندوز می ساخته شد که عملکرد ریز پردازنده های پنتیوم پرو را در هنگام شروع محدود کرد و در نهایت ثبات و مقیاس پذیری نسخه های مبتنی بر DOS را محدود کرد. اگر چه DLLها هسته معماری ویندوز هستند، اما آن ها دارای نقایص متعددی هستند که به طور کلی " جهنم دی ال ال " نامیده می شود. ، مایکروسافت NET چارچوب را رواج می دهد، به عنوان یک راه حل برای مشکلات DLL hell، اگر چه آن ها در حال حاضر راه حل های مبتنی بر مجازی سازی را مانند مایکروسافت مجازی کامپیوتر و مایکروسافت برنامه مجازی سازی رواج می دهند و آن به دلیل انعطاف پذیری بالاتر بین برنامه های کاربردی است. راه حل جبران جایگزین برای DLL hell، اجرای اسمبلی کنار هم قرار گرفته است. ویژگی های DLL. از آنجائیکه DLLها اساساً همان EXEها هستند، انتخاب آن برای تولید به عنوان بخشی از روند پیوند برای وضوح است، به این دلیل که ممکن است توابع و داده ها را از هر دوی آن ها بفرستد. امکان اجرای مستقیم DLL وجود ندارد، زیرا برای سیستم عامل نیاز به یک EXE است، تا بتواند آن را از هر نقطه ورود ب
ارگذاری کند. از این رو، وجود امکانات مانند "RUNDLL. EXE" یا "RUNDLL32.EXE" که نقطه ورود و حداقل چارچوب را برای DLLها فراهم می کند که دارای قابلیت کافی برای اجرا بدون پشتیبانی زیاد است. DLLها مکانیسم لازم برای کد و داده مشترک را فراهم می کنند و با اینکار اجازه می دهند یک توسعه دهندهٔ کد/دادهٔ مشترک، بدون اینکه نیاز داشته باشد تا برنامه ها پیوند دوباره بخورند یا مجدداً کامپایل شوند، عملکرد خود را ارتقا دهد. از نقطه نظر توسعه نرم افزار، ویندوز و OS / 2 می توانند به عنوان مجموعه ای از DLLهایی که به روز رسانی شده اند، باشند که اجازه می دهد برنامه های کاربردی برای یک نسخه از سیستم عامل بدر یک نسخه دیگر آن نیز کار کند. در صورتی که فروشنده OS مطمئن شده است که رابط و قابلیت هر دو سازگار هستند. DLLها در فضای حافظه در فرایند فراخوانی اجرا می شوند و با مجوزهای دسترسی برابر، که بدین معناست که در استفاده، آن ها کم هزینه هستند، اما همچنین به این معناست که اگر DLL هر گونه مشکلی داشته باشد، هیچ حفاظتی در فراخوانی EXE وجود ندارد. مدیریت حافظه. در ویندوز API، فایل های DLL به "بخش"هایی سازماندهی شده اند. هر بخش مجموعه ای از ویژگ
ی های خاص خود را دارد، از قبیل قابل خواندن و نوشتن، اجرایی بودن (برای کد) یا غیرقابل اجرایی بودن (برای داده ها) و غیره. کد در DLL معمولاً در میان تمام فرایندهای که از DLL استفاده می کنند به اشتراک گذاشته می شود؛ یعنی، آن ها یک مکان را در حافظه فیزیکی اشغال می کنند و در فضای صفحه فضایی نمی گیرند. اگر حافظه فیزیکی اشغال شده توسط یک بخش کد بخواهد بازسازی شود، محتویات آن حذف می شود و بعد از آن به طور مستقیم از فایل DLL به صورت مجدد بارگیری می شود. برخلاف بخش های کد، بخش داده های یک DLL معمولاً خصوصی هستند؛ یعنی هر فرایندی که از DLL استفاده می کند، یک کپی مخصوص از تمام داده های DLL دارد. به صورت اختیاری، بخش های داده می توانند به اشتراک گذاشته شوند، به این ترتیب می توان اجازه داد ارتباطات فرایند از طریق این فضای حافظهٔ به اشتراک گذاشته شده، صورت گیرند. به هر جهت، به دلیل اینکه محدودیت های کاربر برای استفاده از حافظه DLL مشترک اعمال نمی شود، این یک سوراخ امنیتی ایجاد می کند؛ یعنی یک فرایند می تواند داده های مشترک را خراب کند، که احتمالاً باعث می شود همه فرایندهای به اشتراک گذاری غیرمعمول رفتار کنند. به عنوان مثال،
فرایندی که تحت یک حساب مهمان انجام می شود، می تواند به این ترتیب فرایند دیگری را که تحت یک حساب کاربری مجاز است خراب کند. این یک دلیل مهم برای جلوگیری از استفاده از بخش های مشترک در DLLها است. اگر یک DLL با برخی بسته بندی های اجرایی خاص فشرده شود (به عنوان مثال UPX)، تمام بخش های کد آن به عنوان خواندن و نوشتن مشخص شده اند و به اشتراک گذاشته نمی شوند. بخش های خواندن و نوشتن کد، شبیه به بخش های داده های خصوصی، برای هر فرایند خصوصی هستند؛ بنابراین، DLLها با بخش های داده مشترک، اگر آن ها برای این در نظر گرفته شده باشند که به طور همزمان توسط چندین برنامه استفاده شوند، نباید فشرده شوند؛ چرا که هر نمونه از برنامه باید یک کپی خود از DLL را حمل کند که در نتیجه افزایش مصرف حافظه خواهد بود. فراخوانی کتابخانه ها. همانند کتابخانه های استاتیک، کتابخانه های دخیل شده برای DLLها با فرمت فایل lib مشخص می شوند. به عنوان مثال، kernel32.dll، کتابخانه پویا اولیه برای توابع پایه ویندوز مانند ایجاد فایل و مدیریت حافظه، از طریق kernel32.lib مرتبط شده. پیوستن به کتابخانه های پویا معمولاً با اتصال به یک کتابخانه وارد شده و دخیل شده به
آن رسیدگی می شود؛ هنگام ساختن یا متصل شدن برای ایجاد یک فایل اجرایی. سپس فایل اجرایی ساخته شده، حاوی یک جدول آدرس های دخیل (IAT) است که توسط آن تمام فراخوانی های عملکرد DLL ارجاع می شود. (هر تابع اشاره شده DLL دارای ورودی خود در IAT است). در زمان اجرا، IAT با آدرس های مناسب پر می شود که مستقیماً به یک تابع در DLL ای که جداگانه بارگذاری شده، اشاره می کند. رفع نماد و الزام آن. هر تابعی که توسط یک DLL صادر می شود، توسط یک عدد ترتیبی و به صورت اختیاری، با یک نام شناسایی می شود. به همین ترتیب، توابع را می توان از یک DLL یا به ترتیب یا با نام وارد کرد. ترتیب آن نشان دهنده موقعیت نشانگر آدرس تابع در جدول آدرس های دخیل DLL یا همان IAT است. معمول است که توابع داخلی فقط به ترتیب صادر شوند نه با نام. برای اکثر توابع API ویندوزها، فقط نام ها در نسخه های مختلف ویندوز حفظ می شوند؛ آن اعداد ترتیبی در معرض تغییر هستند؛ بنابراین، یکنفر نمی تواند با اعتماد کامل توابع API ویندوز را با اعدادش وارد کند. فراخوانی توابع با اعدادشان، تنها عملکرد آن را به مقدار خیلی کمی بهتر می کند در مقایسه با فراخوانی آن ها با نامشان: جداول صادر کر
دن DLLها با نامشان ترتیب بندی شده اند؛ بنابراین از جستجو باینری می توان برای پیدا کردن یک تابع استفاده کرد. سپس فهرست نام پیدا شده در این جستجو، مورد استفاده قرار می گیرد تا عدد آن را در جدول اعداد صادره رپیدا کند. در ویندوز ۱۶ بیتی، جدول نام طبقه بندی نشده بود، بنابراین هزینهٔ جستجوی نام بسیار قابل توجه بود. همچنین ممکن است که یک فایل اجرایی را به یک نسخه خاص از یک DLL "متصل کنیم"، این کار برای این است که آدرس های توابع فراخوانی شده در زمان کامپایل حل و فصل شوند. برای توابع فراخوانی شدهٔ محدود، لینکر نشانهٔ زمانی و مجموع مقابله های DLL که فراخوانی در آن محدود است را ذخیره می کند. در زمان اجرا، ویندوز بررسی می کند که آیا همان نسخه از کتابخانه در حال استفاده است یا خیر، اگر اینطور بود، ویندوز از پردازش توابع فراخوانی شده جلوگیری می کند. در غیر این صورت، اگر کتابخانه با آن کتابخانه ای که به آن محدود شده بود متفاوت بود، ویندوز به طور عادی فراخوانده شده ها را پردازش می کند. فایل های اجرایی محدود شده به نحوی سریعتر بارگذاری می شوند اگر که در همان محیطی که برای کامپایل شدن آن ها بوده، اجرا شوند و دقیقاً در همان زما
ن اگر در محیطهای متفاوتی اجرا می شوند؛ بنابراین هیچ محدودیتی برای اتصال به فراخوانی شده ها وجود ندارد. به عنوان مثال، تمام برنامه های ویندوز استاندارد به DLLهای سیستم مربوط به آن نسخه از ویندوز محدود می شوند. یک فرصت خوب برای اتصال توابع فراخوانده شدهٔ یک نرم افزار به محیط هدف خود، در طول نصب نرم افزار است. این کار کتابخانه ها را تا ارسال نسخهٔ بعدی سیستم عامل محدود می کند؛ ولی مجموع مقابله های برنامهٔ اجرایی را تغییر می دهد؛ بنابراین چیزی نیست که بتوان با برنامه های امضا شده یا برنامه هایی که توسط یک ابزار مدیریت پیکربندی که از مجموع مقابله ها استفاده می کند (مانند چک های MD5) برای مدیریت نسخه های فایل انجام داد. همان طور که نسخه های جدید ویندوز دیگر آدرس های ثابت برای هر کتابخانه بارگذاری شده (به دلایل امنیتی) ندارند، فرصت و ارزش اتصال یک فایل اجرایی در حال کاهش است. پیوند صریح در زمان اجرا. فایل های DLL ممکن است به طور صریح در زمان اجرا بارگذاری شوند، یک فرایند به نام "Run-time dynamic linking" یا پیوندهای زمان اجرا توسط ماکروسافت، با استفاده از تابع codice_11 (یا codice_12). تابع codice_13 برای جستجوی علا
مت های صادر شده بر اساس نام و codice_14 برای این است که DLL را بارگیری یا خالی کند. این توابع مشابه هستند با codice_15، codice_16 و codice_17 در POSIX API استاندارد. فرایند پیوند صریح در زمان اجرا در هر زبانی که اشاره گرها به توابع را پشتیبانی می کند، یکی است. البته از آنجا که به API ویندوز بستگی دارد، نه به جای ساختارهای زبان. بارگیری تأخیری. به طور معمول، یک نرم افزار که در مقابله با یک کتابخانه DLL مرتبط شده، اگر DLL پیدا نشود، شروع به کار نمی کند؛ زیرا ویندوز برنامه را اجرا نخواهد کرد مگر آنکه بتواند تمام DLLهایی را که ممکن است برنامه به آن نیاز داشته باشد، پیدا کند. با این حال یک برنامه ممکن است در مقابله با یک کتابخانه DLL مرتبط شود تا بخواهد بارگذاری کتابخانه پویا را به تأخیر بیندازد. در این حالت سیستم عامل سعی نمی کند زمانی که برنامه شروع می شود DLL را پیدا کند یا آن را بارگذاری کند؛ در عوض، زمانی که یکی از توابع آن فراخوانده می شود یک خرده در نرم افزار به وسیلهٔ همان لینکر در نرم افزار اضافه شده است که سعی می کند DLL را از طریق LoadLibrary و GetProcAddress پیدا کند و آن را بارگذاری کند. اگر DLL را نت
وان یافت یا بارگذاری کرد، یا تابع فراخوانده شده وجود نداشت، برنامه یک استثنا(Exception) ایجاد می کند که ممکن است پیدا شود و به درستی به آن رسیدگی شود. اگر برنامه به استثنائی رسیدگی نکند، توسط سیستم عامل به دام افتاده است که برنامه را با یک پیام خطا خاتمه می دهد. مکانیزم بارگیری تأخیر دار نیز قلاب های اطلاع رسانی را فراهم می کند که اجازه می دهد برنامه پردازش های اضافی یا خطا در هنگام بارگذاری را هنگامی که DLL و/یا هر گونه تابع DLL ای فراخوانده شده باشد، انجام دهد. ملاحظات کامپایلر و زبان. دلفی. در یک فایل منبع، به جای کلمهٔ کلیدی codice_18، codice_19 استفاده می شود. در پایان فایل، توابع مورد نظر صادر شده در بند codice_20 ذکر شده اند. دلفی برای دسترسی به توابع از DLLها نیاز به فایل های codice_21 ندارد برای پیوند به یک DLL، کلمه کلیدی codice_22 در اعلامیه عملکرد برای نشان دادن نام DLL استفاده می شود، به دنبال آن codice_23 برای نامگذاری نماد (اگر متفاوت است) یا codice_24 برای شناسایی شاخص آن. مایکروسافت ویژوال بیسیک Microsoft Visual Basic. در ویژوال بیسیک(VB) تنها پیوند در زمان اجرا پشتیبانی می شود. اما علاوه بر
استفاده از codice_11 و codice_13 توابع API، "اعلامیه(declare کردن)" از توابع فراخوانده شده مجاز است. هنگام وارد کردن توابع DLL از طریق اعلان ها، VB یک خطای زمانی اجرا می کند اگر فایل codice_1 را پیدا نکند. توسعه دهنده می تواند خطا را دریافت و به درستی به آن رسیدگی کند. هنگام ایجاد DLLها در VB، آن IDE تنها به شما اجازه می دهد تا DLLهای ActiveX را ایجاد کنید، با این حال روشهای مورد نیاز ایجاد شده که به کاربران اجازه می دهد تا به صراحت به لینکر بگوید که یک DEF. اضافه کند که نام هر تابع و موقعیت و عدد آن را تعریف کند. این اجازه می دهد تا کاربر یک DLL استاندارد ویندوز را با استفاده از ویژوال بیسیک (نسخه ۶ یا پایین تر) ایجاد کند که می تواند از طریق بیانیه "اعلام(Declare)" اشاره شود. C و ++ C. مایکروسافت ویژوال سی + +(MSVC) چند پسوند را برای استاندارد C ++ فراهم می کند که اجازه می دهد توابع به عنوان وارد شده یا صادر شده به طور مستقیم در کد سی ++مشخص شوند؛ این ها توسط کامپایلرهای ویندوز C و C ++، از جمله نسخه های ویندوز GCC بکار رفته است. این پسوندها از ویژگی codice_28 قبل از اعلان تابع استفاده می کنند. توجه داشته با