Thư Viện (máy Tính) – Wikipedia Tiếng Việt

Trong khoa học máy tính, thư viện là tập hợp các tài nguyên không biến động được sử dụng bởi các chương trình máy tính, thường để phát triển phần mềm. Chúng có thể bao gồm dữ liệu cấu hình, tài liệu, dữ liệu trợ giúp, mẫu thông báo, mã được viết sẵn và chương trình con, lớp, giá trị hoặc thông số kỹ thuật loại. Trong OS / 360 của IBM và những người kế nhiệm của họ, chúng được gọi là các tập dữ liệu được phân vùng.

Một thư viện cũng là một tập hợp các triển khai hành vi, được viết bằng ngôn ngữ, có giao diện được xác định rõ ràng theo đó hành vi được gọi. Chẳng hạn, những người muốn viết chương trình cấp cao hơn có thể sử dụng thư viện để thực hiện các cuộc gọi hệ thống thay vì thực hiện các cuộc gọi hệ thống đó nhiều lần. Ngoài ra, hành vi được cung cấp để tái sử dụng bởi nhiều chương trình độc lập. Một chương trình gọi hành vi do thư viện cung cấp thông qua cơ chế của ngôn ngữ. Ví dụ, trong một ngôn ngữ mệnh lệnh đơn giản như C, hành vi trong thư viện được gọi bằng cách sử dụng chức năng gọi bình thường của C. Điều phân biệt lời gọi là chức năng thư viện, so với chức năng khác trong cùng một chương trình, là cách mã được tổ chức trong hệ thống.

Mã thư viện được tổ chức theo cách có thể được sử dụng bởi nhiều chương trình không có kết nối với nhau, trong khi mã là một phần của chương trình được tổ chức chỉ được sử dụng trong một chương trình đó. Sự khác biệt này có thể đạt được một khái niệm phân cấp khi một chương trình phát triển lớn, chẳng hạn như một chương trình hàng triệu dòng. Trong trường hợp đó, có thể có các thư viện nội bộ được sử dụng lại bởi các phần phụ độc lập của chương trình lớn. Đặc điểm nổi bật là một thư viện được tổ chức cho các mục đích được sử dụng lại bởi các chương trình hoặc chương trình phụ độc lập và người dùng chỉ cần biết giao diện chứ không phải chi tiết bên trong của thư viện.

Giá trị của một thư viện nằm trong việc tái sử dụng hành vi. Khi một chương trình gọi một thư viện, nó có được hành vi được thực hiện bên trong thư viện đó mà không phải thực hiện chính hành vi đó. Các thư viện khuyến khích việc chia sẻ mã theo kiểu mô đun và dễ dàng phân phối mã.

Hành vi được thực hiện bởi một thư viện có thể được kết nối với chương trình gọi ở các giai đoạn vòng đời chương trình khác nhau. Nếu mã của thư viện được truy cập trong quá trình xây dựng chương trình gọi, thì thư viện được gọi là thư viện tĩnh.[1] Một cách khác là xây dựng chương trình thực thi của chương trình gọi và phân phối nó, độc lập với việc triển khai thư viện. Hành vi thư viện được kết nối sau khi thực thi đã được gọi để được thực thi, như là một phần của quá trình bắt đầu thực thi, hoặc ở giữa thực thi. Trong trường hợp này, thư viện được gọi là thư viện động (được tải trong thời gian chạy). Một thư viện động có thể được tải và liên kết khi chuẩn bị một chương trình để thực thi, bởi trình liên kết. Ngoài ra, ở giữa thực thi, một ứng dụng có thể yêu cầu rõ ràng rằng một mô-đun được tải.

Hầu hết các ngôn ngữ được biên dịch đều có thư viện chuẩn mặc dù các lập trình viên cũng có thể tạo thư viện tùy chỉnh của riêng họ. Hầu hết các hệ thống phần mềm hiện đại cung cấp các thư viện thực hiện phần lớn các dịch vụ hệ thống. Các thư viện như vậy đã thương mại hóa các dịch vụ mà một ứng dụng hiện đại yêu cầu. Như vậy, hầu hết các mã được sử dụng bởi các ứng dụng hiện đại được cung cấp trong các thư viện hệ thống này.

Lịch sử

[sửa | sửa mã nguồn]

Các khái niệm lập trình sớm nhất tương tự như các thư viện nhằm mục đích tách các định nghĩa dữ liệu khỏi việc thực hiện chương trình. JOVIAL đã đưa khái niệm"COMPOOL"(Nhóm truyền thông) được chú ý vào năm 1959, mặc dù nó đã áp dụng ý tưởng từ phần mềm hệ thống lớn SAGE. Theo các nguyên tắc khoa học máy tính về phân tách mối quan tâm và che giấu thông tin,"Mục đích của Comm Pool là cho phép chia sẻ Dữ liệu Hệ thống giữa nhiều chương trình bằng cách cung cấp mô tả dữ liệu tập trung."[2]

COBOL cũng bao gồm"các khả năng nguyên thủy cho một hệ thống thư viện"vào năm 1959,[3] nhưng Jean Sammet đã mô tả chúng là"cơ sở thư viện không đầy đủ"khi nhìn lại.[4]

Một đóng góp lớn khác cho khái niệm thư viện hiện đại xuất hiện dưới hình thức đổi mới chương trình con của FORTRAN. Các chương trình con FORTRAN có thể được biên dịch độc lập với nhau, nhưng trình biên dịch thiếu một trình liên kết. Vì vậy, trước khi giới thiệu các mô-đun trong Fortran-90, việc kiểm tra kiểu giữa các chương trình con FORTRAN[NB 1] là không thể.[5]

Cuối cùng, các nhà sử học của khái niệm nên nhớ Simula 67 có ảnh hưởng. Simula là ngôn ngữ lập trình hướng đối tượng đầu tiên và các lớp của nó gần giống với khái niệm hiện đại như được sử dụng trong Java, C++ và C#. Khái niệm lớp của Simula cũng là một tổ tiên của package trong Ada và mô-đun của Modula-2.[6] Ngay cả khi được phát triển ban đầu vào năm 1965, các lớp Simula có thể được bao gồm trong các tệp thư viện và được thêm vào lúc biên dịch.[7]

Liên kết

[sửa | sửa mã nguồn]

Thư viện rất quan trọng trong việc liên kết chương trình hay quá trình ràng buộc, trong đó giải quyết tài liệu tham khảo được gọi là link hoặc biểu tượng đến module thư viện. Quá trình liên kết thường được thực hiện tự động bởi một linker hoặc binder tìm kiếm một tập hợp các thư viện và các mô-đun khác theo một thứ tự nhất định. Thông thường, nó không được coi là lỗi nếu có thể tìm thấy mục tiêu liên kết nhiều lần trong một bộ thư viện nhất định. Liên kết có thể được thực hiện khi một file thực thi được tạo hoặc bất cứ khi nào chương trình được sử dụng trong thời gian chạy.

Các tham chiếu đang được giải quyết có thể là địa chỉ cho các bước nhảy và các lời gọi thông thường khác. Chúng có thể nằm trong chương trình chính, hoặc trong một mô-đun tùy thuộc vào mô-đun khác. Chúng được phân giải thành các địa chỉ cố định hoặc có thể định vị lại (từ một cơ sở chung) bằng cách phân bổ bộ nhớ thời gian chạy cho các phân đoạn bộ nhớ của mỗi mô-đun được tham chiếu.

Một số ngôn ngữ lập trình có thể sử dụng một tính năng gọi là liên kết thông minh, theo đó trình liên kết nhận biết hoặc tích hợp với trình biên dịch, để trình liên kết biết cách sử dụng các tham chiếu bên ngoài và mã trong thư viện không bao giờ được sử dụng, mặc dù được tham chiếu bên trong bị loại bỏ khỏi ứng dụng biên dịch. Ví dụ, một chương trình chỉ sử dụng số nguyên cho số học hoặc hoàn toàn không có hoạt động số học, có thể loại trừ các thói quen thư viện dấu phẩy động. Tính năng liên kết thông minh này có thể dẫn đến kích thước tệp ứng dụng nhỏ hơn và giảm mức sử dụng bộ nhớ.

Di chuyển

[sửa | sửa mã nguồn]

Một số tham chiếu trong mô-đun chương trình hoặc thư viện được lưu trữ ở dạng tương đối hoặc biểu tượng không thể giải quyết cho đến khi tất cả mã và thư viện được gán địa chỉ tĩnh cuối cùng. Di chuyển là quá trình điều chỉnh các tham chiếu này và được thực hiện bởi trình liên kết hoặc trình tải. Nói chung, việc di chuyển không thể được thực hiện cho các thư viện riêng lẻ vì các địa chỉ trong bộ nhớ có thể khác nhau tùy thuộc vào chương trình sử dụng chúng và các thư viện khác mà chúng được kết hợp với. Mã độc lập vị trí tránh tham chiếu đến các địa chỉ tuyệt đối và do đó không yêu cầu di chuyển.

Thư viện tĩnh

[sửa | sửa mã nguồn]

Khi liên kết được thực hiện trong quá trình tạo file thực thi hoặc file đối tượng khác, nó được gọi là liên kết tĩnh hoặc liên kết sớm. Trong trường hợp này, liên kết thường được thực hiện bởi một trình liên kết, nhưng cũng có thể được thực hiện bởi trình biên dịch. Một thư viện tĩnh, còn được gọi là một kho lưu trữ, là một dự định được liên kết tĩnh. Ban đầu, chỉ có các thư viện tĩnh tồn tại. Liên kết tĩnh phải được thực hiện khi bất kỳ mô-đun nào được biên dịch lại.

Tất cả các mô-đun được yêu cầu bởi một chương trình đôi khi được liên kết tĩnh và sao chép vào file thực thi. Quá trình này và file độc lập kết quả, được gọi là bản dựng tĩnh của chương trình. Một bản dựng tĩnh có thể không cần di chuyển thêm nếu bộ nhớ ảo được sử dụng và không cần ngẫu nhiên bố trí không gian địa chỉ.[8]

Thư viện dùng chung

[sửa | sửa mã nguồn]

Thư viện dùng chung hoặc đối tượng dùng chung là một file được dự định chia sẻ bởi các file thực thi và các file đối tượng được chia sẻ thêm. Các mô-đun được sử dụng bởi một chương trình được tải từ các đối tượng chia sẻ riêng lẻ vào bộ nhớ khi tải hoặc thời gian chạy, thay vì được sao chép bởi một trình liên kết khi nó tạo một file thực thi nguyên khối duy nhất cho chương trình.

Thư viện dùng chung có thể được liên kết tĩnh, nghĩa là các tham chiếu đến các mô-đun thư viện được giải quyết và các mô-đun được cấp phát bộ nhớ khi file thực thi được tạo. Nhưng thường liên kết các thư viện chia sẻ bị hoãn cho đến khi chúng được tải. [Còn mơ hồ – thảo luận]

Hầu hết các hệ điều hành hiện đại [NB 2] có thể có các file thư viện dùng chung định dạng với các file thực thi. Điều này cung cấp hai ưu điểm chính: thứ nhất, nó yêu cầu chỉ tạo một bộ tải cho cả hai, chứ không phải hai (có bộ tải đơn được coi là có giá trị phức tạp thêm vào). Thứ hai, nó cho phép các file thực thi cũng được sử dụng làm thư viện dùng chung, nếu chúng có bảng ký hiệu. Các định dạng thư viện chia sẻ và thực thi kết hợp điển hình là ELF và Mach-O (cả trong Unix) và PE (Windows).

Trong một số môi trường cũ hơn như Windows 16 bit hoặc MPE cho HP 3000, dữ liệu chỉ dựa trên ngăn xếp (cục bộ) được cho phép trong mã thư viện dùng chung hoặc các hạn chế đáng kể khác được đặt trên mã thư viện dùng chung.

Chia sẻ bộ nhớ

[sửa | sửa mã nguồn]

Mã thư viện có thể được chia sẻ trong bộ nhớ bởi nhiều tiến trình, cũng như trên đĩa. Nếu bộ nhớ ảo được sử dụng, các quy trình sẽ thực thi cùng một trang RAM vật lý được ánh xạ vào các không gian địa chỉ khác nhau của các quy trình. Điều này có lợi thế. Chẳng hạn, trên hệ thống OpenStep, các ứng dụng thường chỉ có kích thước vài trăm kilobyte và được tải nhanh chóng; phần lớn mã của họ được đặt trong các thư viện đã được hệ điều hành tải cho các mục đích khác.[cần dẫn nguồn]

Các chương trình có thể thực hiện chia sẻ RAM bằng cách sử dụng mã độc lập với vị trí, như trong Unix, dẫn đến kiến trúc phức tạp nhưng linh hoạt hoặc bằng cách sử dụng các địa chỉ ảo phổ biến, như trong Windows và OS/2. Các hệ thống này đảm bảo, bằng nhiều thủ thuật khác nhau như ánh xạ trước không gian địa chỉ và vị trí đặt chỗ cho mỗi thư viện dùng chung, mã đó có xác suất lớn được chia sẻ. Một lựa chọn thay thế thứ ba là bộ nhớ một cấp, được sử dụng bởi Hệ thống IBM/38 và những người kế nhiệm của nó. Điều này cho phép mã phụ thuộc vào vị trí, nhưng không đặt giới hạn đáng kể về nơi có thể đặt mã hoặc cách chia sẻ mã.

Trong một số trường hợp, các phiên bản khác nhau của thư viện dùng chung có thể gây ra sự cố, đặc biệt là khi các thư viện của các phiên bản khác nhau có cùng tên file và các ứng dụng khác nhau được cài đặt trên một hệ thống, mỗi ứng dụng yêu cầu một phiên bản cụ thể. Một kịch bản như vậy được gọi là địa ngục DLL, đặt theo tên file DLL của Windows và OS/2. Hầu hết các hệ điều hành hiện đại sau năm 2001 đều có các phương pháp dọn dẹp để loại bỏ các tình huống đó hoặc sử dụng các thư viện"riêng tư"dành riêng cho ứng dụng.[9]

Liên kết động

[sửa | sửa mã nguồn]

Liên kết động hoặc liên kết trễ là liên kết được thực hiện trong khi chương trình đang được tải (loadtime) hoặc được thực thi (runtime), thay vì khi file thực thi được tạo. Thư viện được liên kết động (thư viện liên kết động hay DLL, trong Windows và OS/2; đối tượng chia sẻ động hay DSO, trong các hệ thống giống Unix) là thư viện dành cho liên kết động. Chỉ một lượng công việc tối thiểu được thực hiện bởi trình liên kết khi file thực thi được tạo; nó chỉ ghi lại những gì thư viện thường xuyên chương trình cần và tên chỉ mục hoặc số của các thường trình trong thư viện. Phần lớn công việc liên kết được thực hiện tại thời điểm ứng dụng được tải (loadtime) hoặc trong khi thực hiện (runtime). Thông thường, chương trình liên kết cần thiết, được gọi là"trình liên kết động"hoặc"trình tải liên kết", thực sự là một phần của hệ điều hành cơ bản. (Tuy nhiên, có thể, và không quá khó, để viết một chương trình sử dụng liên kết động và bao gồm trình liên kết động của chính nó, ngay cả đối với một hệ điều hành không hỗ trợ liên kết động.)

Các lập trình viên ban đầu đã phát triển liên kết động trong hệ điều hành Multics, bắt đầu từ năm 1964 và MTS (Michigan Terminal System), được xây dựng vào cuối những năm 1960.[10]

Tối ưu hóa

[sửa | sửa mã nguồn]

Vì các thư viện dùng chung trên hầu hết các hệ thống không thay đổi thường xuyên, nên các hệ thống có thể tính toán địa chỉ tải có khả năng cho mỗi thư viện dùng chung trên hệ thống trước khi cần và lưu trữ thông tin đó trong thư viện và các file thực thi. Nếu mọi thư viện chia sẻ được tải đã trải qua quá trình này, thì mỗi thư viện sẽ tải tại địa chỉ được xác định trước, giúp tăng tốc quá trình liên kết động. Tối ưu hóa này được gọi là prebinding trong macOS và prelinking trong Linux. Nhược điểm của kỹ thuật này bao gồm thời gian cần thiết để tính toán trước các địa chỉ này mỗi khi thư viện chia sẻ thay đổi, không thể sử dụng ngẫu nhiên bố cục không gian địa chỉ và yêu cầu đủ không gian địa chỉ ảo để sử dụng (một vấn đề sẽ được giảm bớt khi áp dụng kiến trúc 64-bit, ít nhất là trong thời điểm hiện tại).

Định vị thư viện trong thời gian chạy

[sửa | sửa mã nguồn]

Các trình tải cho các thư viện chia sẻ rất đa dạng về chức năng. Một số phụ thuộc vào các đường dẫn lưu trữ rõ ràng đến các thư viện. Bất kỳ thay đổi nào đối với việc đặt tên thư viện hoặc bố cục của hệ thống file sẽ khiến các hệ thống này bị lỗi. Thông thường hơn, chỉ có tên của thư viện (chứ không phải đường dẫn) được lưu trữ trong file thực thi, với hệ điều hành cung cấp phương thức để tìm thư viện trên đĩa, dựa trên một số thuật toán.

Nếu một thư viện dùng chung mà một file thực thi phụ thuộc vào sẽ bị xóa, di chuyển hoặc đổi tên hoặc nếu một phiên bản thư viện không tương thích được sao chép vào một vị trí sớm hơn trong tìm kiếm, thì file thực thi sẽ không tải được. Đây được gọi là địa ngục phụ thuộc, tồn tại trên nhiều nền tảng. Biến thể Windows (khét tiếng) thường được gọi là địa ngục DLL. Vấn đề này không thể xảy ra nếu mỗi phiên bản của mỗi thư viện được xác định duy nhất và mỗi chương trình chỉ tham chiếu các thư viện bằng các định danh duy nhất đầy đủ của chúng. Các vấn đề"địa ngục DLL"với các phiên bản Windows trước đó phát sinh từ việc chỉ sử dụng tên của các thư viện không được bảo đảm là duy nhất để giải quyết các liên kết động trong các chương trình. (Để tránh"DLL hell", các phiên bản Windows sau này chủ yếu dựa vào các tùy chọn cho các chương trình cài đặt DLL riêng - về cơ bản là rút lui một phần khỏi việc sử dụng các thư viện dùng chung - cùng với các cơ chế để ngăn thay thế DLL hệ thống dùng chung với các phiên bản trước đó.)

Microsoft Windows

[sửa | sửa mã nguồn]

Microsoft Windows kiểm tra registry để xác định vị trí thích hợp để tải DLL thực hiện các đối tượng COM, nhưng đối với các DLL khác, nó sẽ kiểm tra các thư mục theo thứ tự xác định. Đầu tiên, Windows kiểm tra thư mục nơi nó tải chương trình (private DLL); bất kỳ thư mục nào được đặt bằng cách gọi hàm SetDllDirectory(); các thư mục System32, System và Windows; sau đó là thư mục làm việc hiện tại; và cuối cùng là các thư mục được chỉ định bởi biến môi trường PATH.[11] Ứng dụng viết cho .NET Framework (từ năm 2002), cũng kiểm tra Global hội Cache là kho lưu trữ chính của các Global Assembly Cache là kho lưu trữ chính của các file dll được chia sẻ để loại bỏ vấn đề về địa ngục DLL.

OpenStep

[sửa | sửa mã nguồn]

OpenStep đã sử dụng một hệ thống linh hoạt hơn, thu thập danh sách các thư viện từ một số vị trí đã biết (tương tự như khái niệm PATH) khi hệ thống khởi động lần đầu tiên. Di chuyển các thư viện xung quanh không gây ra vấn đề gì cả, mặc dù người dùng phải chịu chi phí thời gian khi lần đầu tiên khởi động hệ thống.

Các hệ thống tương tự Unix

[sửa | sửa mã nguồn]

Hầu hết các hệ thống tương tự Unix đều có "đường dẫn tìm kiếm" chỉ định các thư mục hệ thống file để tìm thư viện động. Một số hệ thống chỉ định đường dẫn mặc định trong file cấu hình, một số hệ thống khác mã hóa nó vào trình tải động. Một số định dạng file thực thi có thể chỉ định các thư mục bổ sung để tìm kiếm thư viện cho một chương trình cụ thể. Điều này thường có thể được ghi đè bằng một biến môi trường, mặc dù nó bị vô hiệu hóa cho các chương trình setuid và setgid, do đó người dùng không thể buộc chương trình đó chạy mã tùy ý với quyền gốc. Các nhà phát triển thư viện được khuyến khích đặt thư viện động của họ ở những nơi trong đường dẫn tìm kiếm mặc định. Mặt khác, điều này có thể làm cho việc cài đặt các thư viện mới gặp vấn đề và các vị trí"đã biết"này nhanh chóng trở thành nhà của số lượng file thư viện ngày càng tăng, khiến việc quản lý trở nên phức tạp hơn.

Tải động

[sửa | sửa mã nguồn]

Tảo động (Dynamic loading), một tập hợp con của liên kết động, bao gồm tải và dỡ tải thư viện được liên kết động tại thời gian chạy theo yêu cầu. Một yêu cầu như vậy có thể được thực hiện ngầm trong thời gian biên dịch hoặc rõ ràng vào thời gian chạy. Các yêu cầu ngầm được thực hiện tại thời điểm biên dịch khi một trình liên kết thêm các tham chiếu thư viện bao gồm các đường dẫn file hoặc chỉ đơn giản là tên file. Yêu cầu rõ ràng được thực hiện khi các ứng dụng thực hiện cuộc gọi trực tiếp tới API của hệ điều hành trong thời gian chạy.

Hầu hết các hệ điều hành hỗ trợ các thư viện được liên kết động cũng hỗ trợ tải động các thư viện đó thông qua API liên kết thời gian chạy. Ví dụ, Microsoft Windows sử dụng các hàm API LoadLibrary, LoadLibraryEx, FreeLibrary và GetProcAddress với Microsoft Dynamic Link Libraries; Các hệ thống dựa trên POSIX, bao gồm hầu hết các hệ thống tương tự Unix và Unix, sử dụng dlopen, dlclose và dlsym. Một số hệ thống phát triển tự động hóa quá trình này.

Thư viện đối tượng và lớp

[sửa | sửa mã nguồn]

Mặc dù ban đầu đi tiên phong vào những năm 1960, liên kết động không đến được các hệ điều hành được người tiêu dùng sử dụng cho đến cuối những năm 1980. Nó thường có sẵn ở một số dạng trong hầu hết các hệ điều hành vào đầu những năm 1990. Trong cùng thời gian này, lập trình hướng đối tượng (OOP) đã trở thành một phần quan trọng trong bối cảnh lập trình. OOP với ràng buộc thời gian chạy yêu cầu thông tin bổ sung mà các thư viện truyền thống không cung cấp. Ngoài tên và điểm nhập của mã nằm trong, họ cũng yêu cầu một danh sách các đối tượng mà chúng phụ thuộc. Đây là tác dụng phụ của một trong những lợi thế chính, sự kế thừa của OOP, có nghĩa là các phần của định nghĩa hoàn chỉnh của bất kỳ phương pháp nào có thể ở những nơi khác nhau. Điều này không chỉ đơn giản là liệt kê rằng một thư viện yêu cầu dịch vụ của người khác: trong một hệ thống OOP thực sự, bản thân các thư viện có thể không được biết đến tại thời điểm biên dịch và thay đổi tùy theo hệ thống.

Đồng thời, nhiều nhà phát triển đã thực hiện ý tưởng về các chương trình nhiều tầng, trong đó một "hiển thị" chạy trên máy tính để bàn sẽ sử dụng các dịch vụ của máy tính lớn hoặc máy tính mini để lưu trữ hoặc xử lý dữ liệu. Chẳng hạn, một chương trình trên máy tính dựa trên GUI sẽ gửi tin nhắn đến một máy tính mini để trả về các mẫu nhỏ của một tập dữ liệu khổng lồ để hiển thị. Các lời gọi thủ tục từ xa (RPC) đã xử lý các tác vụ này, nhưng không có hệ thống RPC tiêu chuẩn.

Chẳng mấy chốc, phần lớn các nhà cung cấp máy tính mini và máy tính lớn đã thúc đẩy các dự án kết hợp cả hai, tạo ra một định dạng thư viện OOP có thể được sử dụng ở bất cứ đâu. Các hệ thống như vậy được gọi là thư viện đối tượng hoặc đối tượng phân tán, nếu chúng hỗ trợ truy cập từ xa (không phải tất cả đã làm). COM của Microsoft là một ví dụ về một hệ thống như vậy để sử dụng cục bộ, DCOM là phiên bản sửa đổi hỗ trợ truy cập từ xa.

Trong một số thời gian, các thư viện đối tượng giữ trạng thái"điều lớn tiếp theo"trong thế giới lập trình. Có một số nỗ lực để tạo ra các hệ thống sẽ chạy trên các nền tảng và các công ty đã cạnh tranh để cố gắng khiến các nhà phát triển bị khóa trong hệ thống của riêng họ. Các ví dụ bao gồm System Object Model (SOM / DSOM) của IBM, Distributed Objects Everywhere (DOE) của Sun Microsystems, Portable Distributed Objects (PDO) của NeXT, ObjectBroker của Digital, Component Object Model (COM / DCOM) của Microsoft và bất kỳ số lượng các hệ thống dựa trên CORBA.

Sau sự hạ nhiệt không thể tránh khỏi của tiếp thị cường điệu, các thư viện đối tượng tiếp tục được sử dụng trong cả lập trình hướng đối tượng và hệ thống thông tin phân tán. Các thư viện lớp là tương đương OOP thô của các loại mã thư viện cũ. Chúng chứa các lớp, mô tả các đặc điểm và định nghĩa các hành động (phương thức) liên quan đến các đối tượng. Các thư viện lớp được sử dụng để tạo các thể hiện hoặc các đối tượng với các đặc tính của chúng được đặt thành các giá trị cụ thể. Trong một số ngôn ngữ OOP, như Java, sự khác biệt rất rõ ràng, với các lớp thường có trong các file thư viện (như định dạng file JAR của Java) và các đối tượng được khởi tạo chỉ nằm trong bộ nhớ (mặc dù có khả năng tồn tại trong các file riêng biệt). Trong những ngôn ngữ khác, như Smalltalk, các thư viện lớp chỉ là điểm khởi đầu cho một hình ảnh hệ thống bao gồm toàn bộ trạng thái của môi trường, các lớp và tất cả các đối tượng được khởi tạo.

Thư viện từ xa

[sửa | sửa mã nguồn]

Một giải pháp khác cho vấn đề thư viện đến từ việc sử dụng các file thực thi hoàn toàn riêng biệt (thường ở dạng nhẹ) và gọi chúng bằng cách sử dụng một lời gọi thủ tục từ xa (RPC) qua mạng đến một máy tính khác. Cách tiếp cận này tối đa hóa việc sử dụng lại hệ điều hành: mã cần thiết để hỗ trợ thư viện là cùng một mã được sử dụng để cung cấp hỗ trợ và bảo mật ứng dụng cho mọi chương trình khác. Ngoài ra, các hệ thống như vậy không yêu cầu thư viện tồn tại trên cùng một máy, nhưng có thể chuyển tiếp các yêu cầu qua mạng.

Tuy nhiên, cách tiếp cận như vậy có nghĩa là mọi lời gọi thư viện đòi hỏi một lượng chi phí đáng kể. Các lời gọi RPC đắt hơn nhiều so với việc gọi một thư viện chia sẻ đã được tải trên cùng một máy. Cách tiếp cận này thường được sử dụng trong kiến trúc phân tán, sử dụng nhiều các cuộc gọi từ xa như vậy, đáng chú ý là các hệ thống máy chủ-máy khách và máy chủ ứng dụng như Enterprise JavaBeans.

Thư viện tạo mã

[sửa | sửa mã nguồn]

Thư viện tạo mã là các API cấp cao có thể tạo hoặc chuyển đổi mã byte cho Java. Chúng được sử dụng bởi lập trình hướng theo khía cạnh, một số khung truy cập dữ liệu và để thử nghiệm để tạo các đối tượng proxy động. Chúng cũng được sử dụng để chặn truy cập trường.[12]

Đặt tên file

[sửa | sửa mã nguồn]

Hầu hết các hệ thống tương tự Unix hiện đại

[sửa | sửa mã nguồn]

Các kho hệ thống file libfoo.a và libfoo.so trong thư mục như /lib, /usr/lib hoặc /usr/local/lib. Tên file luôn bắt đầu bằng lib và kết thúc bằng hậu tố .a (kho lưu trữ, thư viện tĩnh) hoặc .so (đối tượng chia sẻ, thư viện được liên kết động). Một số hệ thống có thể có nhiều tên cho thư viện được liên kết động, với hầu hết các tên là tên cho các liên kết tượng trưng cho tên còn lại; những tên đó có thể bao gồm phiên bản chính của thư viện hoặc số phiên bản đầy đủ; ví dụ, trên một số hệ thống libfoo.so.2 sẽ là tên file cho lần sửa đổi giao diện chính thứ hai của thư viện libfoo được liên kết động. Các file .la đôi khi được tìm thấy trong các thư mục thư viện là kho lưu trữ libtool, không thể sử dụng được bởi hệ thống.

macOS

[sửa | sửa mã nguồn]

Hệ thống kế thừa các quy ước thư viện tĩnh từ BSD, với thư viện được lưu trữ trong file .a và có thể sử dụng các thư viện được liên kết động theo kiểu .so (với hậu tố .dylib thay thế). Tuy nhiên, hầu hết các thư viện trong macOS đều bao gồm"khung", được đặt trong các thư mục đặc biệt gọi là"bundles"bao bọc các file và siêu dữ liệu cần thiết của thư viện. Ví dụ: một khung có tên MyFramework sẽ được triển khai trong một gói có tên MyFramework.framework, với MyFramework.framework/MyFramework là file thư viện được liên kết động hoặc là một liên kết tượng trưng đến file thư viện được liên kết động trong MyFramework.framework/Versions/Current/MyFramework.

Windows

[sửa | sửa mã nguồn]

Các thư viện liên kết động thường có hậu tố *.DLL,[13] mặc dù các phần mở rộng tên file khác có thể xác định các thư viện được liên kết động theo mục đích cụ thể, ví dụ: *.OCX cho các thư viện OLE. Các bản sửa đổi giao diện được mã hóa trong tên file hoặc được trừu tượng hóa bằng giao diện đối tượng COM. Tùy thuộc vào cách chúng được biên dịch, file *.LIB file có thể là thư viện tĩnh hoặc biểu diễn của các thư viện có thể liên kết động chỉ cần trong quá trình biên dịch, được gọi là"thư viện nhập". Không giống như trong thế giới UNIX, sử dụng các phần mở rộng file khác nhau, khi liên kết với file .LIB trong Windows phải biết đó là thư viện tĩnh thông thường hay thư viện nhập. Trong trường hợp sau, file .LL phải có mặt trong thời gian chạy.

Xem thêm

[sửa | sửa mã nguồn]

• Thư viện liên kết động
• Plug-in
• Thư viện thành phần Lazarus (LCL)
• Thư viện chuẩn C
• Lập trình chung (được sử dụng bởi thư viện chuẩn C ++)

Ghi chú

[sửa | sửa mã nguồn]

1. ^ It was possible earlier between, e.g., Ada subprograms.
2. ^ Some older systems, e.g., Burroughs MCP, Multics, also have only a single format for executable files, regardless of whether they are shared.

Chú thích

[sửa | sửa mã nguồn]

1. ^ “Static Libraries”. TLDP. Lưu trữ bản gốc ngày 3 tháng 7 năm 2013. Truy cập ngày 3 tháng 10 năm 2013.
2. ^ Wexelblat, Richard (1981). History of Programming Languages. ACM Monograph Series. New York, NY: Academic Press (A subsidiary of Harcourt Brace). tr. 369. ISBN 0-12-745040-8.
3. ^ Wexelblat, op. cit., p. 274
4. ^ Wexelblat, op. cit., p. 258
5. ^ Wilson, Leslie B.; Clark, Robert G. (1988). Comparative Programming Languages. Wokingham, England: Addison-Wesley. tr. 126. ISBN 0-201-18483-4.
6. ^ Wilson and Clark, op. cit., p. 52
7. ^ Wexelblat, op. cit., p. 716
8. ^ Christian Collberg, John H. Hartman, Sridivya Babu, Sharath K. Udupa (2003). “SLINKY: Static Linking Reloaded”. Department of Computer Science, University of Arizona. Lưu trữ bản gốc ngày 23 tháng 3 năm 2016. Truy cập ngày 17 tháng 3 năm 2016.Quản lý CS1: sử dụng tham số tác giả (liên kết)
9. ^ Anderson, Rick (ngày 11 tháng 1 năm 2000). “The End of DLL Hell”. microsoft.com. Bản gốc lưu trữ ngày 5 tháng 6 năm 2001. Truy cập ngày 15 tháng 1 năm 2012. Private DLLs are DLLs that are installed with a specific application and used only by that application.
10. ^ “A History of MTS”. Information Technology Digest. 5 (5).
11. ^ “Dynamic-Link Library Search Order”. Microsoft Developer Network Library. Microsoft. ngày 6 tháng 3 năm 2012. Lưu trữ bản gốc ngày 9 tháng 5 năm 2012. Truy cập ngày 20 tháng 5 năm 2012.
12. ^ “Code Generation Library”. http://sourceforge.net/: Source Forge. Lưu trữ bản gốc ngày 12 tháng 1 năm 2010. Truy cập ngày 3 tháng 3 năm 2010. Byte Code Generation Library is high level API to generate and transform JAVA byte code. It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access.
13. ^ Bresnahan, Christine; Blum, Richard (ngày 27 tháng 4 năm 2015). LPIC-1 Linux Professional Institute Certification Study Guide: Exam 101-400 and Exam 102-400. John Wiley & Sons (xuất bản 2015). tr. 82. ISBN 9781119021186. Lưu trữ bản gốc ngày 24 tháng 9 năm 2015. Truy cập ngày 3 tháng 9 năm 2015. Linux shared libraries are similar to the dynamic link libraries (DLLs) of Windows. Windows DLLs are usually identified by .dll filename extensions.Đã bỏ qua tham số không rõ |df= (trợ giúp)

Liên kết ngoài

[sửa | sửa mã nguồn]

• Shared Libraries - 'Linkers and Loaders' Lưu trữ 2015-05-27 tại Wayback Machine by John R. Levine
• Dynamic Linking and Loading - 'Linkers and Loaders' Lưu trữ 2014-09-06 tại Wayback Machine by John R. Levine
• Article Beginner's Guide to Linkers by David Drysdale
• Article Faster C++ program startups by improving runtime linking efficiency by Léon Bottou and John Ryland
• How to Create Program Libraries Lưu trữ 2021-04-28 tại Wayback Machine by Baris Simsek
• BFD - the Binary File Descriptor Library
• 1st Library-Centric Software Design Workshop LCSD'05 Lưu trữ 2019-08-28 tại Wayback Machine at OOPSLA'05
• 2nd Library-Centric Software Design Workshop LCSD'06 at OOPSLA'06
• How to create shared library by Ulrich Drepper (with much background info)
• Anatomy of Linux dynamic libraries at ibm.com

Tiêu đề chuẩn	GND: 4121521-7 LCCN: sh2008001447 NKC: ph170667

x t s Hệ thống nhúng
Thuật ngữ chung	ASIC Gói hỗ trợ bo mạch Trình tải khởi động Điện tử tiêu dùng Trình biên dịch chéo Cơ sở dữ liệu nhúng Hypervisor nhúng HĐH nhúng Phần mềm nhúng FPGA IoT Memory footprint Vi điều khiển Máy tính bo mạch đơn Raspberry Pi SoC
Firmware vàhệ thống điều khiển	Firmware Firmware tùy chỉnh Firmware sở hữu độc quyền Nền tảng đóng Crippleware Defective by Design Hacking of consumer electronics Homebrew Jailbreak iOS Jailbreak PlayStation 3 Root (Android) Khóa nhà cung cấp
Trình tải khởi động	U-Boot Barebox
Thư viện phần mềm	uClibc dietlibc Embedded GLIBC lwIP musl
Công cụ lập trình	Almquist shell BitBake Buildroot BusyBox OpenEmbedded Stand-alone shell Toybox Yocto Project
Hệ điều hành	Linux trên hệ thống nhúng Linux cho thiết bị di động Bản phân phối Linux nhẹ Hệ điều hành thời gian thực Windows IoT Win CE
Ngôn ngữ lập trình	Ada Hợp ngữ CAPL Embedded C Embedded C++ Embedded Java MISRA C MicroPython
Trình duyệt nhẹ Danh sách phần cứng nguồn mở Robot học nguồn mở