DLL Hell

Dalam dunia komputasi, **DLL Hell** adalah istilah sehari-hari untuk komplikasi yang muncul ketika bekerja dengan *[[dynamic link library]]* (DLL) yang digunakan dalam sistem operasi Microsoft Windows, terutama edisi "warisan" (*legacy*) 16-bit. Meskipun istilah ini adalah hanya berlaku untuk sistem operasi Windows (istilah yang lebih umum adalah neraka dependensi) istilah ini juga sering digunakan untuk menggambarkan sebuah kasus neraka dependensi.

DLL hell sering muncul dalam *popup* peringatan Windows yang laporan sesuatu yang mirip dengan "*A Required DLL File, Z.DLL, was not found*" atau "*The procedure entry point Y couldn't be located in X.DLL*" saat pengguna mencoba untuk menjalankan sebuah aplikasi, atau ketika *startup*. Hal ini dapat juga terjadi saat aplikasi yang dijalankan tidak berfungsi sebagaimana mestinya.
## Masalah
Ada sejumlah masalah yang biasa ditemui dengan DLL - terutama setelah berbagai aplikasi yang telah diinstal ke dalam sistem atau dibuang dari sistem. Masalah-masalah tersebut termasuk konflik antar versi DLL, masalah tidak mendapatkan DLL yang dibutuhkan, dan memiliki banyak salinan DLL yang diperlukan.

;Versi yang tidak cocok: Sebuah versi khusus dari sebuah library dapat kompatibel dengan beberapa program tertentu yang menggunakannya (dan tidak sesuai dengan yang lain). Windows sangatlah rentan untuk hal ini karena penekanannya pada proses dynamic linking antara dari pustaka C++ dan objek-objek *[[Object Linking and Embedding]]* (OLE). Kelas-kelas C++ dapat mengekspor banyak metode, dan satu perubahan saja dalam kelas tersebut (seperti halnya menambahkan metode virtual yang baru) dapat membuatnya tidak kompatibel dengan program yang dibangun terhadap versi sebelumnya. *Object Linking and Embedding* memiliki beberapa aturan yang sangat ketat untuk mencegah hal ini, yakni antarmuka yang diperlukan haruslan stabil dan manajer memori tidak saling digunakan (share). Tapi hal ini tidaklah cukup, karena semantik dari sebuah kelas tertentu dapat berubah. Sebuah "*[[bugfix]]*" untuk satu aplikasi mungkin dapat menghilangkan "fitur" yang lain. Sebelum Windows 2000, Windows sangatlah rentan untuk hal ini karena tabel kelas *[[Component Object Model]]* (*COM class table*) dipakai secara bersamaan oleh semua pengguna dan proses. Hanya satu COM objek, dalam satu DLL/EXE yang dapat dinyatakan sebagai memiliki COM ClassID tersendiri. Jika ada program apapun yang diperlukan untuk membuat sebuah *instance* dari kelas tersebut, implementasinya bisa jadi apa pun yang telah terdaftar oleh Windows secara terpusat. Akibatnya, instalasi program yang menginstal versi baru dari objek yang umum mungkin secara tidak sengaja melanggar program lain yang diinstal sebelumnya.

;DLL stomping (penimpaan DLL): Masalah yang umum dan sulit terjadi bila program yang baru diinstal akan menimpa DLL yang sedang berkerja dengan versi sebelumnya yang sering tidak kompatibel. Sebuah contoh yang terkenal adalah perpustakaan `ctl3d.dll` dan `ctl3dv2.dll` untuk Windows 3.1, yang memiliki banyak versi update muncul secara bebas dan tidak terkontrol. DLL Stomping terjadi karena:
:* Microsoft di masa lalu mendistribusikan *[[runtime]]* DLL sebagai komponen sistem bersama, (awalnya `C:\WINDOWS` dan `C:\WINDOWS\SYSTEM`), sebagai sebuah cara untuk berbagi kode secara efisien dalam sistem operasi yang berbasis *shared-memory* (memori yang digunakan bersama) dengan ''Random Access Memory'' (RAM) dan ruang *disk* yang terbatas. Akibatnya, para pengembang pihak ketiga ini juga mendistribusikan pustaka dengan cara yang sama.
:* Walaupun tidak disarankan, aplikasi yang terinstal oleh siapapun dengan hak administrator mungkin memiliki kemampuan untuk menginstal DLL ke dalam direktori operasi, dan mengedit registry untuk mendaftarkan DLL baru sebagai sebuah objek COM yang baru. Hal ini dapat mengakibatkan versi lama menjadi hidup di versi Windows di mana *[[Windows File Protection]]* atau *[[Windows Resource Protection]]* tidak membuat sebuah *restore point* atau tidak bisa mengembalikan seperti sedia kala.
:* Aplikasi Windows yang diizinkan untuk memasukkan pembaruan sistem operasi pada program-program instalasi mereka sendiri. Hal ini disebabkan oleh banyak DLL yang dibuat oleh Microsoft sebagai *redistributable* (dapat disebarkan kembali), yang berarti aplikasi Windows bisa untuk memasukkan DLL tersebut jika mereka membutuhkan jasa perpustakaan tertentu.
:* Program instalasi program (program installer) dalam Windows merupakan produk komersial yang hanya bisa diperoleh dengan hanya tertentu, sehingga banyak orang berusaha untuk menulis installer mereka sendiri, menghadap masalah *versioning*.
:* Beberapa pengembang lalai untuk menyertakan versi sumber daya dalam library yang mereka buat. Mengecek kapan tanggal berkas DLL tersebut dibuat, lalu menimpa berkas yang sudah ada atau melewatinya begitu saja jika ada sebuah DLL sudah terinstal adalah satu-satunya pilihan yang tersedia. Jika ada sebuah dialog yang ditampilkan oleh Windows menawarkan opsi-opsi ini, aplikasi yang sedang diinstal harus mendapatkan perhatian ekstra. Jika salinan DLL diabaikan, lagi, maka memang sudah cukup banyak DLL yang ada di dalam sistem. Jika sudah DLL telah tertimpa, maka aplikasi Anda bekerja.
:* Kadang-kadang OS itu sendiri menimpa DLL. Sebagai contoh, Windows 2000 akan menginstal DLL printer warna hitam/putih di atas DLL printer yang dapat mengenali warna, jika sebuah printer yang hitam dan putih dipasang setelah printer berwarna.

## Pranala luar
* The End of DLL Hell di MSDN
* Getting Out of DLL Hell di Microsoft TechNet
* Simplifying Deployment and Solving DLL Hell with the .NET Framework di MSDN
* Avoiding DLL Hell: Introducing Application Metadata in the Microsoft .NET Framework oleh Matt Pietrek
* Dr. Dobb's on DLL Hell (details on LoadLibraryEx)
* Joel on Software discussion
* Great Article on DLL Hell