Pliki bibliotek Microsoft Windows - Microsoft Windows library files

Microsoft Windows System operacyjny obsługuje formy współdzielonych bibliotek znanych jako „ biblioteki dynamicznego łącza ”, które są biblioteki kodów, które mogą być używane przez wiele procesów, podczas gdy tylko jedna kopia jest ładowany do pamięci . Ten artykuł zawiera omówienie podstawowych bibliotek dołączonych do każdej nowoczesnej instalacji systemu Windows, na których budowana jest większość aplikacji systemu Windows.

Elementy wewnętrzne

HAL.DLL jest plikiem biblioteki trybu jądra i nie może być używany przez żaden program trybu użytkownika. NTDLL.DLL jest używany tylko przez niektóre programy, ale jest to zależność od większości bibliotek Win32 używanych przez programy.

HAL.DLL

Warstwa abstrakcji sprzętu systemu Windows (HAL) jest zaimplementowana w hal.dll . HAL implementuje szereg funkcji, które są implementowane na różne sposoby przez różne platformy sprzętowe, co w tym kontekście odnosi się głównie do chipsetu . Inne komponenty systemu operacyjnego mogą następnie wywoływać te funkcje w ten sam sposób na wszystkich platformach, bez względu na rzeczywistą implementację.

Na przykład odpowiedź na przerwanie jest zupełnie inna na maszynie z zaawansowanym programowalnym kontrolerem przerwań (APIC) niż na maszynie bez. HAL dostarcza do tego celu pojedynczą funkcję, która działa ze wszystkimi rodzajami przerwań z różnych chipsetów, dzięki czemu inne komponenty nie muszą się martwić różnicami.

HAL jest ładowany do przestrzeni adresowej jądra i działa w trybie jądra, więc procedury w warstwie HAL nie mogą być wywoływane bezpośrednio przez aplikacje, a żadne funkcje API trybu użytkownika nie odpowiadają bezpośrednio procedurom HAL. Zamiast tego warstwa HAL udostępnia usługi przede wszystkim dla systemu wykonawczego i jądra systemu Windows oraz sterowników urządzeń trybu jądra. Chociaż sterowniki większości sprzętu są zawarte w innych plikach, najczęściej typu .sys , kilka podstawowych sterowników jest wkompilowanych w hal.dll .

Sterowniki urządzeń trybu jądra dla urządzeń na magistralach, takich jak PCI i PCI Express, bezpośrednio wywołują procedury w warstwie HAL, aby uzyskać dostęp do portów we/wy i rejestrów ich urządzeń. Sterowniki używają procedur HAL, ponieważ różne platformy mogą wymagać różnych implementacji tych operacji. HAL implementuje operacje odpowiednio dla każdej platformy, dzięki czemu ten sam plik wykonywalny sterownika może być używany na wszystkich platformach przy użyciu tej samej architektury procesora CPU , a plik źródłowy sterownika może być przenośny we wszystkich architekturach.

W systemach x86 na nośniku instalacyjnym znajduje się kilka różnych plików HAL. Procedura instalacji systemu Windows określa, które z nich są odpowiednie dla bieżącej platformy i kopiuje je na dysk twardy, zmieniając w razie potrzeby nazwę na hal.dll . Wśród kryteriów tego wyboru są: obecność systemu BIOS zgodnego z ACPI , obecność interfejsu APIC oraz obecność i włączenie wielu procesorów. (Wiele rdzeni wielordzeniowego procesora , a nawet „procesory logiczne” zaimplementowane w procesorze hiperwątkowym , wszystkie liczą się w tym celu jako „procesory”.) Na platformach x86-64 i Itanium istnieje tylko jeden możliwy plik hal.dll dla każdej architektury procesora.

HAL jest scalany (lub statycznie połączony) z ntoskrnl.exe począwszy od wersji 2004 systemu Windows 10, a biblioteka dll służy tylko jako skrót dla zgodności wstecznej.

NTDLL.DLL

NTDLL.DLL eksportuje Windows Native API . Natywny interfejs API to interfejs używany przez składniki systemu operacyjnego w trybie użytkownika, który musi działać bez obsługi ze strony Win32 lub innych podsystemów interfejsu API. Większość tego interfejsu API jest zaimplementowana w NTDLL.DLL i na górnej krawędzi ntoskrnl.exe (i jego wariantów), a większość eksportowanych symboli w tych bibliotekach ma prefiks Nt , na przykład NtDisplayString . Natywne interfejsy API są również używane do implementacji wielu „interfejsów API jądra” lub „podstawowych interfejsów API” eksportowanych przez KERNEL32.DLL. Zdecydowana większość aplikacji systemu Windows nie wywołuje bezpośrednio NTDLL.DLL.

Mówi się, że aplikacje, które są połączone bezpośrednio z tą biblioteką, używają podsystemu natywnego ; głównym powodem ich istnienia jest wykonywanie zadań, które muszą zostać uruchomione na wczesnym etapie sekwencji uruchamiania systemu, zanim będzie dostępny podsystem Win32. Oczywistym, ale ważnym przykładem jest utworzenie procesu podsystemu Win32, csrss.exe . Zanim proces csrss.exe istnieje, nie może zostać utworzony żaden proces Win32, dlatego proces, który go tworzy (Smss.exe, „menedżer sesji”) musi korzystać z podsystemu natywnego. Sam csrss.exe jest taką aplikacją.

Pomimo rozszerzenia pliku „.exe”, aplikacje natywne nie mogą być wykonywane przez użytkownika (ani żaden program w Win32 lub innych podsystemach). Przykładem jest plik binarny autochk.exe, który uruchamia program chkdsk podczas inicjalizacji systemu „niebieski ekran”. Innymi wybitnymi przykładami są usługi, które implementują różne podsystemy, takie jak csrss.exe .

W przeciwieństwie do aplikacji Win32, aplikacje natywne tworzą instancje w kodzie środowiska wykonawczego jądra ( ntoskrnl.exe ) i dlatego muszą mieć inny punkt wejścia ( NtProcessStartup , a nie (w)(Win)MainCRTStartup, jak w aplikacji Win32), uzyskaj ich polecenie -line argumenty za pomocą wskaźnika do struktury w pamięci, zarządzają własną pamięcią za pomocą interfejsu API sterty Rtl (którego API sterty Win32 są po prostu owijane - nie ma tu prawdziwej różnicy) i zwracają wykonanie z wywołaniem NtTerminateProcess (w przeciwieństwie do do ExitProcess ). Powszechną biblioteką połączoną z aplikacjami natywnymi jest nt.lib, która zawiera kod startowy dla aplikacji natywnych, podobnie jak środowisko wykonawcze C udostępnia kod startowy dla aplikacji Win32.

Chociaż większość interfejsu API jest nieudokumentowana, aplikacje natywne można tworzyć przy użyciu zestawu Windows Driver Development Kit ; wielu dostawców oprogramowania antywirusowego i innych narzędzi zawiera aplikacje natywne w swoich produktach, zwykle w celu wykonania jakiegoś zadania podczas uruchamiania, którego nie można wykonać w przestrzeni użytkownika .

Win32 API

Dalsze informacje: Windows API

Każda z bibliotek w tej sekcji implementuje różne podzbiory interfejsu Win32 API.

KERNEL32.DLL

KERNEL32.DLL udostępnia aplikacjom większość podstawowych interfejsów API Win32, takich jak zarządzanie pamięcią , operacje wejścia/wyjścia (I/O) , tworzenie procesów i wątków oraz funkcje synchronizacji. Wiele z nich jest zaimplementowanych w KERNEL32.DLL przez wywołanie odpowiednich funkcji w natywnym API , ujawnianych przez NTDLL.DLL.

GDI32.DLL

GDI32.DLL eksportuje funkcje interfejsu GDI (Graphics Device Interface), które wykonują proste funkcje rysowania w celu wyprowadzenia ich na ekrany wideo i drukarki. Jest używany na przykład w wersji XP programu Paint. Aplikacje wywołują funkcje GDI bezpośrednio w celu wykonywania rysowania na niskim poziomie (linia, prostokąt, elipsa), wyświetlania tekstu, zarządzania czcionkami i podobnych funkcji.

Początkowo GDI obsługiwało 16 i 256 kolorowych kart graficznych EGA / VGA oraz drukarek monochromatycznych . Funkcjonalność rozwinęła się z biegiem lat i teraz obejmuje obsługę takich elementów, jak czcionki TrueType , kanały alfa i wiele monitorów .

USER32.DLL

Dalsze informacje: Windows UŻYTKOWNIK

USER32.DLL implementuje składnik Windows USER, który tworzy i manipuluje standardowymi elementami interfejsu użytkownika Windows, takimi jak pulpit, okna i menu. W ten sposób umożliwia programom zaimplementowanie graficznego interfejsu użytkownika (GUI), który pasuje do wyglądu i działania systemu Windows. Programy wywołują funkcje użytkownika Windows USER w celu wykonywania operacji, takich jak tworzenie i zarządzanie oknami, odbieranie komunikatów okiennych (które są głównie danymi wejściowymi użytkownika, takimi jak zdarzenia myszy i klawiatury, ale także powiadomienia z systemu operacyjnego), wyświetlanie tekstu w oknie i wyświetlanie wiadomości pudła.

Wiele funkcji w USER32.DLL odwołuje się do funkcji GDI wyeksportowanych przez GDI32.DLL w celu wykonania rzeczywistego renderowania różnych elementów interfejsu użytkownika. Niektóre typy programów będą również wywoływać funkcje GDI bezpośrednio w celu wykonania operacji rysowania niższego poziomu w oknie utworzonym wcześniej za pomocą funkcji USER32.

COMCTL32.DLL

COMCTL32.DLL implementuje szeroką gamę standardowych kontrolek systemu Windows, takich jak okna dialogowe Otwórz plik, Zapisz i Zapisz jako, paski postępu i widoki list. Wywołuje funkcje z obu USER32.DLL i GDI32.DLL do tworzenia i zarządzania oknami dla tych elementów interfejsu użytkownika, umieszczania w nich różnych elementów graficznych i zbierania danych wejściowych użytkownika.

COMDLG32.DLL

COMDLG32.DLL , biblioteka wspólnych okien dialogowych, implementuje szeroką gamę okien dialogowych Windows przeznaczonych do wykonywania tego, co Microsoft uważa za "zwykłe zadania aplikacji". Począwszy od wydania systemu Windows Vista firma Microsoft uważa, że ​​okna dialogowe „Otwórz” i „Zapisz jako” udostępniane przez tę bibliotekę są przestarzałe i zastąpione przez „Wspólny interfejs API okna elementów”.

WS2_32.DLL

WS2_32.DLL implementuje Winsock API, który zapewnia funkcje sieciowe TCP/IP i zapewnia częściową, uszkodzoną kompatybilność z innymi API sieciowymi. wsock.dll i wsock32.dll to starsze wersje dla kompatybilności z Win3.11 i Win95.

ADVAPI32.DLL

ADVAPI32.DLL zapewnia wywołania bezpieczeństwa i funkcje do manipulowania Rejestrem Windows .

NETAPI32.DLL

NETAPI32.DLL udostępnia funkcje do odpytywania i zarządzania interfejsami sieciowymi.

OLE32.DLL

OLE32.DLL udostępnia Component Object Model oraz Object Linking and Embedding .

Inne interfejsy API

SHSCRAP.DLL

SHSCRAP.DLL jest częścią mechanizmu łączenia i osadzania obiektów (OLE) . Implementuje obsługę plików złomu powłoki , które są tworzone automatycznie podczas przeciągania wybranej zawartości z aplikacji obsługującej OLE do okna Eksploratora lub pulpitu, ale do ich tworzenia można również użyć programu Object Packager . Można je następnie przeciągnąć do innej aplikacji obsługującej technologię OLE.

Ta funkcja została usunięta z systemu Windows Vista (a zatem z nowszych wersji), aby poprawić bezpieczeństwo i pozbyć się ogólnie nieużywanych funkcji systemu operacyjnego. Pliki złomu (.shs) były używane przez wirusy, ponieważ mogą zawierać wiele różnych plików (w tym kod wykonywalny), a rozszerzenie pliku nie jest wyświetlane, nawet jeśli opcja „Ukryj rozszerzenia plików znanych typów plików” jest wyłączona. Funkcjonalność można przywrócić, kopiując wpisy rejestru i bibliotekę DLL z systemu Windows XP .

WINMM.DLL

WINMM.DLL zapewnia dostęp do oryginalnego API audio WinMM .

IMM32.DLL

IMM32 jest odpowiedzialny za wywoływanie i interakcję z edytorem Input Method Editor .

Biblioteki uruchomieniowe

MSVCRT.DLL, MSVCP*.DLL i CRTDLL.DLL

MSVCRT.DLL to standardowa biblioteka C dla kompilatora Visual C++ (MSVC) od wersji 4.2 do 6.0. Dostarcza programy skompilowane przez te wersje MSVC z większością standardowych funkcji biblioteki C. Obejmują one manipulację ciągami, alokację pamięci, wywołania wejścia/wyjścia w stylu C i inne. MSVCP*.DLL jest odpowiednią biblioteką C++.

Jest dostarczany z wersjami Windows od Windows 95 OSR2.5 do użytku przez inne składniki Windows; wcześniejsze wersje dostarczane z biblioteką CRTDLL.DLL . W starszych wersjach systemu Windows programy, które łączyły się z MSVCRT.DLL, miały zainstalować kompatybilną kopię w folderze System32, ale przyczyniło się to do DLL Hell, ponieważ wiele instalatorów nie sprawdziło wersji biblioteki z zainstalowaną wersją przed jej wymianą.

Wersje MSVC przed 4.0 i od 7.0 do 13.0 używały różnie nazwanych bibliotek DLL dla każdej wersji (MSVCR20.DLL, MSVCR70.DLL, MSVCR71.DLL, MSVCP110.DLL itd.). Do zainstalowania odpowiedniej wersji wymagane są aplikacje, a firma Microsoft oferuje w tym celu pakiety redystrybucyjne Visual C++ , chociaż system Windows zazwyczaj ma już zainstalowaną jedną wersję.

W wersji 14.0 większość środowiska wykonawczego C/C++ została przeniesiona do nowej biblioteki DLL, UCRTBASE.DLL. Jednak programy C/C++ używające UCRTBASE.DLL są zmuszone do łączenia się z inną nową biblioteką DLL, VCRuntime, której nazwa zmienia się z każdą wersją MSVC (np. VCRUNTIME140.DLL).

Kod źródłowy bibliotek wykonawczych jest zawarty w Visual C++ w celach informacyjnych i debugowania (np. w C:\Program Files\Microsoft Visual Studio 11.0\VC\crt\src).

Ta biblioteka uruchomieniowa jest używana przez programy napisane w Visual C++ i kilka innych kompilatorów (np. MinGW ). Niektóre kompilatory mają własne biblioteki wykonawcze.

Inne biblioteki wykonawcze

  • ATL*.DLL – Aktywna Biblioteka Szablonów
  • MFC*.DLL — Microsoft Foundation Classes
  • MSVBVM60.DLL — maszyna wirtualna Visual Basic 6.0 ( programy Visual Basic.NET wymagają zamiast tego platformy .NET Framework )
  • VCOMP*.DLL — środowisko uruchomieniowe Microsoft OpenMP
  • VCRUNTIME*.DLL — Microsoft VCRuntime, dla MSVC 14.0+
  • MSVCIRT.DLL — Microsoft C++ Library, zawiera przestarzałe klasy C++ z <iostream.h> (zwróć uwagę na rozszerzenie pliku) dla MS C 9 i 10 (MSVC 2.x, 4.x) (wtedy projekt C++ Standard Library został zintegrowany z MSVCRT.DLL (podzielony wraz z wydaniem Visual C++ 5.0)

Biblioteki .NET Framework

Programy napisane w C# , Visual Basic.NET , C++/CLI i innych językach .NET wymagają .NET Framework . Posiada wiele bibliotek (jedną z nich jest mscorlib.dll  – Multilanguage Standard Common Object Runtime Library, dawniej Microsoft Common Object Runtime Library) oraz tzw. zestawy (np. System.Windows.Forms.dll ).

Zobacz też

Bibliografia

Zewnętrzne linki