Liên kết đến tệp DLL có thể diễn ra ngầm tại thời gian liên kết biên dịch hoặc rõ ràng vào thời gian chạy. Dù bằng cách nào, DLL kết thúc được tải vào không gian bộ nhớ quy trình và tất cả các điểm nhập đã xuất của nó đều có sẵn cho ứng dụng.
Nếu được sử dụng một cách rõ ràng tại thời điểm chạy, bạn sử dụng LoadLibrary()và GetProcAddress()để tải DLL theo cách thủ công và lấy các con trỏ đến các hàm bạn cần gọi.
Nếu được liên kết ngầm khi chương trình được xây dựng, thì các bản gốc cho mỗi lần xuất DLL được chương trình sử dụng sẽ được liên kết với chương trình từ một thư viện nhập và các bản gốc đó sẽ được cập nhật khi EXE và DLL được tải khi quá trình khởi chạy. (Vâng, tôi đã đơn giản hóa hơn một chút ở đây ...)
Các sơ khai đó cần đến từ đâu đó và trong chuỗi công cụ của Microsoft, chúng đến từ một dạng tệp .LIB đặc biệt được gọi là thư viện nhập . .LIB bắt buộc thường được xây dựng cùng lúc với DLL và chứa sơ khai cho mỗi hàm được xuất từ DLL.
Thật khó hiểu, một phiên bản tĩnh của cùng một thư viện cũng sẽ được chuyển dưới dạng tệp .LIB. Không có cách nào đơn giản để phân biệt chúng, ngoại trừ LIB là thư viện nhập cho các tệp DLL thường sẽ nhỏ hơn (thường nhỏ hơn nhiều) so với LIB tĩnh phù hợp.
Nếu bạn sử dụng chuỗi công cụ GCC, ngẫu nhiên, bạn không thực sự cần các thư viện nhập để khớp với các tệp DLL của mình. Phiên bản của trình liên kết Gnu được chuyển sang Windows hiểu trực tiếp các tệp DLL và có thể tổng hợp nhanh chóng hầu hết các sơ khai cần thiết.
Cập nhật
Nếu bạn không thể cưỡng lại việc biết tất cả các đai ốc và bu lông thực sự ở đâu và điều gì đang thực sự xảy ra, thì MSDN luôn có điều gì đó để giúp bạn. Bài viết của Matt Pietrek Tìm hiểu sâu về Định dạng tệp thực thi di động của Win32 là một tổng quan rất đầy đủ về định dạng của tệp EXE và cách nó được tải và chạy. Nó thậm chí còn được cập nhật để bao gồm .NET và hơn thế nữa kể từ khi nó xuất hiện lần đầu trên Tạp chí MSDN ca. Năm 2002.
Ngoài ra, có thể hữu ích nếu biết cách tìm hiểu chính xác những gì các tệp DLL được một chương trình sử dụng. Công cụ cho điều đó là Dependency Walker, hay còn gọi là depend.exe. Một phiên bản của nó được bao gồm trong Visual Studio, nhưng phiên bản mới nhất có sẵn từ tác giả của nó tại http://www.dependencywalker.com/ . Nó có thể xác định tất cả các DLL đã được chỉ định tại thời điểm liên kết (cả tải sớm và tải chậm) và nó cũng có thể chạy chương trình và theo dõi bất kỳ DLL bổ sung nào mà nó tải tại thời điểm chạy.
Cập nhật 2
Tôi đã sửa lại một số văn bản trước đó để làm rõ khi đọc lại, và sử dụng các thuật ngữ nghệ thuật liên kết ngầm và rõ ràng để nhất quán với MSDN.
Vì vậy, chúng ta có ba cách mà các hàm thư viện có thể được tạo sẵn để một chương trình sử dụng. Câu hỏi tiếp theo rõ ràng là: "Làm thế nào để tôi chọn cách nào?"
Liên kết tĩnh là cách phần lớn chương trình được liên kết. Tất cả các tệp đối tượng của bạn đều được liệt kê và được trình liên kết thu thập vào tệp EXE. Trong quá trình thực hiện, trình liên kết sẽ thực hiện các công việc nhỏ như sửa các tham chiếu đến các ký hiệu toàn cục để các mô-đun của bạn có thể gọi các chức năng của nhau. Các thư viện cũng có thể được liên kết tĩnh. Các tệp đối tượng tạo nên thư viện được thủ thư thu thập cùng nhau trong tệp .LIB mà trình liên kết tìm kiếm các mô-đun chứa các ký hiệu cần thiết. Một tác dụng của liên kết tĩnh là chỉ những mô-đun từ thư viện được chương trình sử dụng mới được liên kết với nó; các mô-đun khác bị bỏ qua. Ví dụ, thư viện toán học C truyền thống bao gồm nhiều hàm lượng giác. Nhưng nếu bạn liên kết chống lại nó và sử dụngcos(), bạn sẽ không nhận được bản sao mã cho sin()hoặc tan()trừ khi bạn cũng gọi các hàm đó. Đối với các thư viện lớn với nhiều tính năng phong phú, việc đưa vào các mô-đun một cách chọn lọc là rất quan trọng. Trên nhiều nền tảng như hệ thống nhúng, tổng kích thước của mã có sẵn để sử dụng trong thư viện có thể lớn so với không gian có sẵn để lưu trữ tệp thực thi trong thiết bị. Nếu không có sự bao gồm có chọn lọc, sẽ khó quản lý các chi tiết của việc xây dựng các chương trình cho các nền tảng đó.
Tuy nhiên, việc có một bản sao của cùng một thư viện trong mọi chương trình đang chạy sẽ tạo ra gánh nặng cho một hệ thống thường chạy nhiều quy trình. Với loại hệ thống bộ nhớ ảo phù hợp, các trang bộ nhớ có nội dung giống hệt nhau chỉ cần tồn tại một lần trong hệ thống, nhưng có thể được sử dụng bởi nhiều quá trình. Điều này tạo ra một lợi ích để tăng khả năng các trang chứa mã có khả năng giống với một số trang trong càng nhiều quy trình đang chạy khác càng tốt. Tuy nhiên, nếu các chương trình liên kết tĩnh với thư viện thời gian chạy, thì mỗi chương trình có một tổ hợp các chức năng khác nhau, mỗi chức năng được bố trí trong bản đồ bộ nhớ xử lý ở các vị trí khác nhau và không có nhiều trang mã có thể chia sẻ trừ khi nó là một chương trình tự nó là chạy trong nhiều hơn quá trình. Vì vậy, ý tưởng về một DLL đã đạt được một lợi thế khác.
Một DLL cho một thư viện chứa tất cả các chức năng của nó, sẵn sàng để sử dụng bởi bất kỳ chương trình khách hàng nào. Nếu nhiều chương trình tải DLL đó, tất cả chúng đều có thể chia sẻ các trang mã của nó. Mọi người đều thắng. (Chà, cho đến khi bạn cập nhật DLL với phiên bản mới, nhưng đó không phải là một phần của câu chuyện này. Địa ngục DLL của Google cho phần đó của câu chuyện.)
Vì vậy, lựa chọn lớn đầu tiên cần thực hiện khi lập kế hoạch cho một dự án mới là giữa liên kết động và liên kết tĩnh. Với liên kết tĩnh, bạn có ít tệp hơn để cài đặt và bạn không bị các bên thứ ba cập nhật DLL mà bạn sử dụng. Tuy nhiên, chương trình của bạn lớn hơn và nó không phải là công dân tốt của hệ sinh thái Windows. Với liên kết động, bạn có nhiều tệp hơn để cài đặt, bạn có thể gặp sự cố với bên thứ ba khi cập nhật DLL mà bạn sử dụng, nhưng nhìn chung bạn thân thiện hơn với các quy trình khác trên hệ thống.
Một lợi thế lớn của DLL là nó có thể được tải và sử dụng mà không cần biên dịch lại hoặc thậm chí khởi động lại chương trình chính. Điều này có thể cho phép nhà cung cấp thư viện bên thứ ba (chẳng hạn như Microsoft và C runtime) sửa lỗi trong thư viện của họ và phân phối nó. Sau khi người dùng cuối cài đặt DLL cập nhật, họ ngay lập tức nhận được lợi ích của việc sửa lỗi đó trong tất cả các chương trình sử dụng DLL đó. (Trừ khi nó phá vỡ mọi thứ. Xem DLL Hell.)
Lợi thế khác đến từ sự phân biệt giữa tải ngầm và tải rõ ràng. Nếu bạn cố gắng nhiều hơn để tải rõ ràng, thì DLL thậm chí có thể không tồn tại khi chương trình được viết và xuất bản. Điều này cho phép các cơ chế mở rộng có thể khám phá và tải các plugin chẳng hạn.
lib /list xxx.libvàlink /dump /linkermember xxx.lib. Xem câu hỏi Stack Overflow này .