windows - Hvorfor fejler COM CoInitializeSecurity i min DLL?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg studerer for øjeblikket VSHADOW.EXE 3.0 fra MS Windows SDK 6.1. Jeg har lavet en version, som kan kompileres til en DLL, der kun eksporterer en ny skrevet funktion, der forventer kommandolinjen som en streng, tilkenker den og kalder derefter gamle wmain. DLL'en er ikke en COM-server.


Det virker nøjagtigt som den gamle, når den udarbejdes som en EXE, men fungerer ikke rigtigt, når den kompileres som en DLL, fordi dette opkald fejler:


 CoInitializeSecurity(NULL, -1, NULL, NULL, 
                      RPC\_C\_AUTHN\_LEVEL\_PKT\_PRIVACY, 
                      RPC\_C\_IMP\_LEVEL\_IDENTIFY, 
                      NULL, EOAC\_NONE, NULL);


som ikke fejler med HRESULT fejl 0x80010119 (RPC\_E\_TOO\_LATE, Sikkerhed skal initialiseres, inden grænsefladerne er marshallede eller uforandrede. Det kan ikke ændres, når de initialiseres. )


Jeg kører den eksporterede funktion fra et VB6-program, hvor funktionen importeres med Declare Function vss Lib vshadow.dll ....


Betyder fejlen, at VB6-programmet allerede hedder CoInitializeSecurity? Hvad kan jeg gøre imod fejlen?


Jeg har også et andet spørgsmål: Hvorfor blev præcis sikkerhedsværdierne RPC\_C\_AUTHN\_LEVEL\_PKT\_PRIVACY og RPC\_C\_IMP\_LEVEL\_IDENTIFY valgt? Hvilken indvirkning vil andre indstillinger have?

Bedste reference


Der er et par standard COM-opkald, der ikke hører til i en DLL. Ligesom CoInitializeEx (), det opkald, der initialiserer COM til en tråd. DLL'en ejer ikke tråden, det er magtløst at tilsidesætte den lejlighedstilstand, som EXE valgte.


CoInitializeSecurity () er en anden, det er EXE's opgave at kalde det. Kun det ved, at de rigtige værdier skal passere, det er den, der bestemmer sikkerhedspolitikken. En DLL kan ikke t noget om klientprocessen.