windows - Korrekt navn for ikke-COM, non.NET DLL?

Indlæg af Hanne Mølgaard Plasc

Problem



I Windows verden, hvad er det rigtige navn til en god. gammeldags C ++ DLL med eksporterede funktioner? Ikke en COM DLL, ikke en. NET DLL. Den slags DLL, som vi plejede at påberåbe ved at kalde LoadLibrary () og GetProcAddress ()?


Jeg har altid kaldt dem 'flade DLL'er', fordi opkalderen ikke kan instantiere objekter fra DLL'en, men hvad er det korrekte navn?


REDIGERE


Tak for svarene.


Bare 'DLL' kan være teknisk korrekt, men hvor jeg arbejder, går alle ud fra, at 'DLL' betyder COM, eller måske på et push .NET, så jeg har brug for et begreb, der adskiller præcis hvad jeg mener.

Bedste reference


'Native' er nok den mest almindelige betegnelse, selvom 'windows' eller 'console' er mere teknisk korrekte, da det er de delsystemer, der sandsynligvis vil blive brugt (delsystemet 'indbygget' er noget andet). Jeg har også hørt 'C DLL' anvendt, hvilket betyder det samme som din brug af 'flat DLL'.


Et dynamisk link bibliotek er et generisk koncept - et 'Windows dynamisk link bibliotek' er differentieret fra * nix ækvivalent, og også fra administrerede biblioteker.


COM er lidt mere end en indkapslingskonvention i denne sammenhæng - Windows DLL'er kan indeholde COM-servere, ligesom bærbare eksekverbare (PE) -filer.

Andre referencer 1


A. Dll? Alle de andre ting bruger den grundlæggende funktionalitet, der leveres af en .dll til at gøre deres respektive ting. Måske en rå .dll hvis du vil være pedantisk, men .dll skal være fint.

Andre referencer 2


Der er ikke længere et 'korrekt' navn, der er et 'rigtigt' navn til 'almindelig bil'. (Jeg bruger 'almindelige DLL'er'.


COM DLL'er, OCX'er, .NET DLL'er, ... de er alle DLL'er, med yderligere funktioner på dem. Intet forhindrer dig fra at sige, at have en DLL, der kan fås både via COM eller manuel LoadLibrary/GetProcAdress. Jeg har set det. Du kan endda udsætte det samme objekt via en 'ren' ikke-objektiveret API.

Andre referencer 3


Jeg er med Charles Graham. De er bare DLL'er. Intet mere, intet mindre.


Nogle DLL'er afslører API'er, der tillader dem at blive brugt med bestemte programmeringsmønstre (for eksempel DLL'er, der eksponerer DllGetClassObject og DllCanUnloadNow kan bruges til at være vært for COM-objekter (men der er andre måder, COM-objekter kan hostes)).

Andre referencer 4


Kan være 'En almindelig DLL'. Dette er det udtryk, vi bruger, men 'DLL' virker også.

Andre referencer 5


Det er et 'dynamisk link bibliotek'. Nogle gange kaldes et 'dynalink bibliotek'. I modsætning til et 'statisk link bibliotek', hvor du vælger dit eget gift. I stedet tager du giften du tilfældigt installeret af brugeren et sted på udførelsesvejen.

Andre referencer 6


Jeg har altid lige kaldt dem DLL'er, men jeg har ikke været i C ++/VB6 verden for længe.

Andre referencer 7


Jeg er enig i, at der er behov for terminologi til at beskrive en DLL, der ikke kan udføres som administreret kode (med andre ord kræver interop til brug af administreret kode), og det kan ikke bruges som COM-objekt. Mange gange udviklere siger bare DLL, og det er tvetydigt. Ja, det er helt gyldigt at kalde et. Net Class-bibliotek en DLL og kalde en COM in-process-server en DLL, men med det formål at kommunikere er det tvetydigt at bare sige DLL.


Se min artikel Native Windows Dynamic Link Libraries (DLL'er) for mere. [1]