کتابخانه پیوند پویا
پس زمینهٔ DLL

اولین نسخه‌های مایکروسافت ویندوز، برنامه هارا در یک فضای آدرس واحد، باهم اجرا می‌کرد. هر برنامه برای این درست شده بود تا به این صورت همکاری کند که CPU را به برنامه‌های دیگر هم برساند (yield کند)، تا رابط کاربری گرافیکی (GUI) بتواند چند کا را با هم انجام دهد و حداکثر پاسخگویی را داشته باشد. تمام عملیات سیستم عامل توسط سیستم عامل پایه ارائه شده‌است: MS-DOS. تمام خدمات سطح بالا توسط کتابخانه‌های ویندوز، همان "DLL"ها، ارائه شده‌است. API طراحی، رابط گرافیکی دستگاه (GDI)، در یک DLL با نام GDI. EXE پیاده‌سازی شده‌است، رابط کاربر در USER. EXE . این لایه‌های اضافی در بالای 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، اجرای اسمبلی کنار هم قرار گرفته‌است.