Apa itu DLL dan bagaimana cara kerjanya?


87

Saya selalu mereferensikan DLL dalam kode C # saya, tetapi mereka tetap menjadi misteri yang ingin saya klarifikasi. Ini adalah semacam brain dump pertanyaan tentang DLL.

Saya memahami bahwa DLL adalah pustaka yang terhubung secara dinamis yang berarti bahwa program lain dapat mengakses pustaka ini pada saat dijalankan untuk mendapatkan "fungsionalitas". Namun, pertimbangkan proyek ASP.NET berikut dengan Web.dlldan Business.dll( Web.dlladalah fungsionalitas ujung depan dan referensi Business.dlluntuk jenis dan metode).

  1. Pada titik manakah Web.dlllink secara dinamis Business.dll? Anda melihat banyak di HDD Windows yang meronta-ronta untuk tugas yang tampaknya kecil saat menggunakan Word (dll.) Dan saya rasa Word akan mati dan secara dinamis menghubungkan fungsionalitas dari DLL lain?

    1a. Selain itu, apa yang memuat dan menautkan DLL - OS atau beberapa kerangka waktu berjalan seperti kerangka .NET?

    1b. Bagaimana proses "menghubungkan"? Apakah pemeriksaan kompatibilitas dilakukan? Memuat ke dalam memori yang sama? Apa sebenarnya arti menghubungkan?

  2. Apa yang sebenarnya mengeksekusi kode di DLL? Apakah itu dijalankan oleh prosesor atau ada tahap terjemahan atau kompilasi lain sebelum prosesor memahami kode di dalam DLL?

    2a. Dalam kasus DLL yang dibangun di C # .NET, apa yang menjalankan ini: kerangka .NET atau sistem operasi secara langsung?

  3. Apakah DLL dari Linux berfungsi pada sistem Windows (jika ada hal seperti itu), atau apakah sistem operasinya spesifik?

  4. Apakah DLL khusus untuk kerangka kerja tertentu? Dapatkah DLL yang dibangun menggunakan C # .NET digunakan oleh DLL yang dibangun dengan, misalnya, Borland C ++?

    4a. Jika jawaban ke 4 adalah "tidak" lalu apa gunanya DLL? Mengapa berbagai kerangka kerja tidak menggunakan formatnya sendiri untuk file tertaut? Misalnya: sebuah .exe bawaan .NET mengetahui bahwa jenis file .abc adalah sesuatu yang dapat ditautkan ke kodenya.

  5. Akan kembali ke Web.dll/ Business.dllcontoh - untuk mendapatkan jenis kelas pelanggan saya perlu referensi Business.dlldari Web.dll. Ini harus berarti bahwa Business.dllberisi semacam spesifikasi tentang apa sebenarnya kelas pelanggan itu. Jika saya telah menyusun fileBusiness.dll file di, katakanlah, Delphi: akankah C # memahaminya dan dapat membuat kelas pelanggan, atau apakah ada semacam info header atau sesuatu yang mengatakan "hei maaf Anda hanya dapat menggunakan saya dari DLL Delphi lain" ?

    5a. Hal yang sama berlaku untuk metode; dapatkah saya menulis CreateInvoice()metode dalam DLL, mengkompilasinya dalam C ++, dan kemudian mengakses dan menjalankannya dari C #? Apa yang menghentikan atau mengizinkan saya melakukan ini?

  6. Mengenai masalah DLL hijacking, tentunya DLL pengganti (jelek) harus mengandung signature dan type metode yang sama persis seperti yang sedang dibajak. Saya kira ini tidak akan sulit dilakukan jika Anda dapat mengetahui metode apa yang tersedia di DLL asli.

    6a. Apa dalam program C # saya yang memutuskan apakah saya dapat mengakses DLL lain? Jika DLL saya yang dibajak berisi metode dan tipe yang persis sama dengan aslinya tetapi dikompilasi dalam bahasa lain, apakah itu akan berhasil?

Apa itu pengimporan DLL dan pendaftaran DLL?


21
Pertanyaan ini mungkin akan menanyakan jawaban terpanjang dalam sejarah SO.
Matti Virkkunen

4
Seharusnya 12 Pertanyaan terpisah.
Henk Holterman

2
Ini adalah pertanyaan yang luar biasa, tetapi saya sangat setuju dengan @Chaos dan @Matti. Pertanyaan ini membutuhkan lebih banyak fokus dan dapat / harus dibagi menjadi beberapa pertanyaan berbeda.
Chris Thompson

3
Itu adalah sedikit
kesedihan

1
Seharusnya sudah menjadi wiki komunitas sekarang.
leppie

Jawaban:


74

Pertama-tama, Anda perlu memahami perbedaan antara dua jenis DLL yang sangat berbeda. Microsoft memutuskan untuk menggunakan ekstensi file yang sama (.exe dan .dll) dengan .NET (kode yang dikelola) dan kode asli, namun DLL kode yang dikelola dan DLL asli sangat berbeda di dalamnya.

1) Pada titik manakah web.dll secara dinamis menautkan ke business.dll? Anda melihat banyak di HDD Windows yang meronta-ronta untuk tugas-tugas yang tampaknya kecil saat menggunakan Word dll dan saya rasa Word ini mati dan secara dinamis menghubungkan fungsionalitas dari DLL lain?

1) Dalam kasus .NET, DLL biasanya dimuat sesuai permintaan ketika metode pertama mencoba mengakses apa pun dari DLL dijalankan. Inilah sebabnya mengapa Anda bisa mendapatkan TypeNotFoundExceptions di mana saja dalam kode Anda jika DLL tidak dapat dimuat. Ketika sesuatu seperti Word tiba-tiba mulai banyak mengakses HDD, kemungkinan besar itu bertukar (mendapatkan data yang telah ditukar ke disk untuk memberi ruang di RAM)

1a) Selain itu, apa yang memuat dan menghubungkan DLL - O / S atau kerangka runtime seperti kerangka .Net?

1a) Dalam kasus DLL terkelola, kerangka kerja .NET adalah yang dimuat, JIT mengkompilasi (mengompilasi bytecode .NET ke dalam kode asli) dan menautkan DLL. Dalam kasus DLL asli, ini adalah komponen sistem operasi yang memuat dan menautkan DLL (tidak diperlukan kompilasi karena DLL asli sudah berisi kode asli).

1b) Bagaimana proses "menghubungkan"? Apakah dilakukan pengecekan bahwa ada kompatibilitas? Memuat ke dalam memori yang sama? Apa sebenarnya arti menghubungkan?

1b) Menghubungkan adalah ketika referensi (misalnya panggilan metode) dalam kode panggilan ke simbol (misalnya metode) di DLL diganti dengan alamat sebenarnya dari hal-hal di DLL. Ini diperlukan karena alamat akhirnya dari hal-hal di DLL tidak dapat diketahui sebelum dimuat ke memori.

2) Apa yang sebenarnya mengeksekusi kode di DLL? Apakah itu dijalankan oleh prosesor atau ada tahap terjemahan atau kompilasi lain sebelum prosesor memahami kode di dalam DLL?

2) Di Windows, file .exe dan file .dll cukup identik. File .exe dan .dll asli berisi kode asli (hal yang sama yang dijalankan prosesor), jadi tidak perlu menerjemahkan. File .exe dan .dll yang dikelola berisi bytecode .NET yang merupakan JIT pertama yang dikompilasi (diterjemahkan ke dalam kode native).

2a) Dalam kasus DLL dibangun dari C # .net apa yang menjalankan ini? Kerangka .NET atau sistem operasi secara langsung?

2a) Setelah kode JIT dikompilasi, itu berjalan dengan cara yang persis sama seperti kode apapun.

3) Apakah DLL dari mengatakan Linux bekerja pada sistem Windows (jika ada hal seperti itu) atau apakah mereka spesifik sistem operasi?

3) DLL yang Dikelola mungkin berfungsi apa adanya, selama kerangka kerja pada kedua platform tersebut mutakhir dan siapa pun yang menulis DLL tidak dengan sengaja merusak kompatibilitas dengan menggunakan panggilan asli. DLL asli tidak akan berfungsi secara as-in, karena formatnya berbeda (meskipun kode mesin di dalamnya sama, jika keduanya untuk platform prosesor yang sama). Omong-omong, di Linux, "DLL" dikenal sebagai file .so (objek bersama).

4) Apakah mereka spesifik untuk kerangka tertentu? Dapatkah DLL yang dibangun menggunakan C # .Net digunakan oleh DLL yang dibangun dengan Borland C ++ (hanya contoh)?

4) DLL Terkelola khusus untuk kerangka .NET, tetapi secara alami berfungsi dengan bahasa yang kompatibel. DLL asli kompatibel selama semua orang menggunakan konvensi yang sama (konvensi pemanggil (bagaimana argumen fungsi diteruskan pada level kode mesin), penamaan simbol, dll.)

5) Kembali ke contoh web.dll / business.dll. Untuk mendapatkan tipe pelanggan kelas, saya perlu mereferensikan business.dll dari web.dll. Ini berarti bahwa business.dll berisi spesifikasi tentang apa sebenarnya kelas pelanggan itu. Jika saya telah mengompilasi file business.dll saya, katakanlah Delphi akan C # memahaminya dan dapat membuat kelas pelanggan - atau apakah ada semacam info header atau sesuatu yang mengatakan "hei maaf, Anda hanya dapat menggunakan saya dari dll delphi lain" .

5) DLL Terkelola berisi deskripsi lengkap dari setiap kelas, metode, bidang, dll. Yang dikandungnya. AFAIK Delphi tidak mendukung .NET, jadi itu akan membuat DLL asli, yang tidak dapat digunakan di .NET secara langsung. Anda mungkin dapat memanggil fungsi dengan PInvoke, tetapi definisi kelas tidak akan ditemukan. Saya tidak menggunakan Delphi jadi saya tidak tahu bagaimana ia menyimpan informasi tipe dengan DLL. C ++, misalnya, bergantung pada file header (.h) yang berisi deklarasi tipe dan harus didistribusikan dengan DLL.

6) Mengenai DLL hijacking, tentunya DLL pengganti (jelek) harus mengandung signature method yang tepat, tipe seperti yang sedang dibajak. Saya kira ini tidak akan sulit dilakukan jika Anda dapat mengetahui metode apa dll yang tersedia di DLL asli.

6) Memang, hal itu tidak sulit dilakukan jika Anda dapat dengan mudah mengganti DLL. Penandatanganan kode dapat digunakan untuk menghindari hal ini. Agar seseorang dapat mengganti DLL yang ditandatangani, mereka harus mengetahui kunci penandatanganan, yang dirahasiakannya.

6a) Sedikit pertanyaan berulang di sini, tetapi ini kembali ke apa di program C # saya yang memutuskan apakah saya dapat mengakses DLL lain? Jika DLL saya yang dibajak berisi metode dan tipe yang persis sama dengan aslinya tetapi dikompilasi dalam bahasa lain, apakah itu akan berhasil?

6a) Ini akan berfungsi selama itu adalah DLL terkelola, dibuat dengan bahasa .NET apa pun.

  • Apa itu mengimpor DLL? dan pendaftaran dll?

"Pengimporan DLL" dapat berarti banyak hal, biasanya ini berarti mereferensikan file DLL dan menggunakan hal-hal di dalamnya.

Pendaftaran DLL adalah sesuatu yang dilakukan di Windows untuk mendaftarkan file DLL secara global sebagai komponen COM agar tersedia untuk perangkat lunak apa pun di sistem.


3
Saya akan menambahkan ke # 4 bahwa. NET dapat menerjemahkan DLL sehingga kompatibel dengan program asli yang memahami / menggunakan COM (Common Object Model). Jawaban yang sangat bagus.
MerickOWA

7

File .dll berisi kode terkompilasi yang dapat Anda gunakan dalam aplikasi Anda.

Terkadang alat yang digunakan untuk mengompilasi .dll penting, terkadang tidak. Jika Anda dapat mereferensikan .dll dalam proyek Anda, tidak masalah alat mana yang digunakan untuk mengkodekan fungsi .dll yang terbuka.

Penautan terjadi pada waktu proses, tidak seperti perpustakaan yang ditautkan secara statis, seperti kelas Anda, yang menautkan pada waktu kompilasi.

Anda dapat menganggap .dll sebagai kotak hitam yang menyediakan sesuatu yang dibutuhkan aplikasi Anda yang tidak ingin Anda tulis sendiri. Ya, seseorang yang memahami tanda tangan .dll dapat membuat file .dll lain dengan kode berbeda di dalamnya dan aplikasi panggilan Anda tidak dapat mengetahui perbedaannya.

HTH


6

1) Pada titik manakah web.dll secara dinamis menautkan ke business.dll? Anda melihat banyak di HDD Windows yang meronta-ronta untuk tugas-tugas yang tampaknya kecil saat menggunakan Word dll dan saya rasa Word ini mati dan secara dinamis menghubungkan fungsionalitas dari DLL lain?

1) Saya pikir Anda bingung menautkan dengan memuat. Linknya adalah ketika semua check and balances diuji untuk memastikan bahwa apa yang diminta tersedia. Pada waktu buka, bagian dari dll dimuat ke memori atau ditukar ke file halaman. Ini adalah aktivitas HD yang Anda lihat.

Tautan dinamis berbeda dari tautan statis dalam tautan statis, semua kode objek dimasukkan ke dalam .exe utama pada saat tautan. Dengan tautan dinamis, kode objek dimasukkan ke dalam file terpisah (dll) dan dimuat pada waktu yang berbeda dari .exe.

Penautan dinamis bisa implisit (misalnya, tautan aplikasi dengan lib impor), atau eksplisit (misalnya, aplikasi menggunakan LoadLibrary (ex) untuk memuat dll).

Dalam kasus implisit, / DELAYLOAD dapat digunakan untuk menunda pemuatan dll hingga aplikasi benar-benar membutuhkannya. Jika tidak, setidaknya beberapa bagian dimuat (dipetakan ke dalam ruang alamat proses) sebagai bagian dari initilazasi proses. DLL juga dapat meminta agar tidak pernah diturunkan saat proses sedang aktif.

COM menggunakan LoadLibrary untuk memuat dll COM. Perhatikan bahwa bahkan dalam kasus implisit, sistem menggunakan sesuatu yang mirip dengan LoadLibrary untuk memuat dll baik pada saat proses startup atau pada penggunaan pertama.

2) Apa yang sebenarnya mengeksekusi kode di DLL? Apakah itu dijalankan oleh prosesor atau ada tahap terjemahan atau kompilasi lain sebelum prosesor memahami kode di dalam DLL?

2) DLL berisi kode objek seperti .exes. Format file dll hampir identik dengan format file exe. Saya pernah mendengar bahwa hanya ada satu bit yang berbeda di header kedua file.

Dalam kasus DLL yang dibangun dari C # .net, kerangka kerja .Net yang menjalankannya.

3) Apakah DLL dari mengatakan Linux bekerja pada sistem Windows (jika ada hal seperti itu) atau apakah mereka spesifik sistem operasi?

3) DLL adalah platform khusus.

4) Apakah mereka spesifik untuk kerangka tertentu? Dapatkah DLL yang dibangun menggunakan C # .Net digunakan oleh DLL yang dibangun dengan Borland C ++ (hanya contoh)?

4) DLL dapat beroperasi dengan kerangka lain jika perawatan khusus dilakukan atau kode perekat tambahan ditulis.

DLL sangat berguna ketika perusahaan menjual banyak produk yang memiliki kemampuan tumpang tindih. Misalnya, saya memelihara raster i / o dll yang digunakan oleh lebih dari 30 produk berbeda di perusahaan. Jika Anda memasang beberapa produk, satu pemutakhiran dll dapat meningkatkan semua produk ke format raster baru.

5) Kembali ke contoh web.dll / business.dll. Untuk mendapatkan tipe pelanggan kelas, saya perlu mereferensikan business.dll dari web.dll. Ini berarti bahwa business.dll berisi spesifikasi tentang apa sebenarnya kelas pelanggan itu. Jika saya telah mengompilasi file business.dll saya, katakanlah Delphi akan C # memahaminya dan dapat membuat kelas pelanggan - atau apakah ada semacam info header atau sesuatu yang mengatakan "hei maaf, Anda hanya dapat menggunakan saya dari dll delphi lain" .

5) Bergantung pada platformnya, kemampuan dll disajikan dalam berbagai cara, melalui file .h, file .tlb, atau cara lain di .net.

6) Mengenai DLL hijacking, tentunya DLL pengganti (jelek) harus mengandung signature method yang tepat, tipe seperti yang sedang dibajak. Saya kira ini tidak akan sulit dilakukan jika Anda dapat mengetahui metode apa dll yang tersedia di DLL asli.

6) dumpbin / ekspor dan dumbin / import adalah alat yang menarik untuk digunakan pada .exe dan .dlls


3) DLL khusus untuk platform
Henk Holterman
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.