c - Hvordan kan jeg koordinere forskellige DLL'er i samme proces uden hjælp fra værtsprogrammet?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg leder efter en måde at koordinere DLL'er i samme proces for at give en data-delingsmekanisme mellem dem. Målet er at have samme delingskode for alle DLL'er, og at få dem til at koordinere på en sådan måde, at den første, der er indlæst af hovedprogrammet, vil fungere som leder for delte emner, mens de andre vil bruge denne manager. Jeg kan ikke ændre hovedapplikationen, så det er ikke muligt at have det, der er oprettet, og deling af hukommelsesadressen med de andre DLL'er. Sættet af DLL'er, der bruger denne mekanisme, kan variere, så jeg kan ikke udtrykkeligt antage, at en af ​​dem bliver indlæst.


En løsning, jeg overvejede, er at tilføje hukommelsesadressen til miljøvariablerne i processen. Den første DLL ville se, at miljøvariablen ikke er indstillet endnu, lav lederobjektet og indstil variablen til sin adresse. De andre DLL'er ville se variablen og skabe en pointer til lederobjektet fra det.


Dette kommer tæt på hvad jeg vil, men det virker lidt rå, da der ikke er nogen garanti for, at miljøvariablen ikke allerede er af en eller anden grund, og SetEnvironmentVariable/GetEnvironmentVariable kan mislykkes af forskellige årsager.


Er der en bedre måde at håndtere dette på? Jeg leder efter en måde at gemme og tilbagekalde en navngivende peger i forbindelse med en proces, men hvis du har en bedre løsning på det underliggende problem med at få DLL'erne til at samarbejde, vil jeg også godt acceptere dette.

Bedste reference


Kombiner GetModuleHandle() med GetProcAddress() for at opnå dette. De afhængige DLL'er vil få håndtaget til manager DLL'en og derefter bruge GetProcAddress() for at hente pointers fra de symboler, som den eksporterer. [7] [8]


Eller bare link dynamisk de afhængige DLL'er mod DLL'erne i DLL'en og brug en headerfil til de eksterne definitioner.





Jeg fejlede først dit spørgsmål Den ovenstående tilgang kan dog stadig være nyttig.


Du kan kræve, at disse DLL'er alle eksporterer et identisk symbol, der vil pege på en eller anden struktur eller funktion. Så når en af ​​bibliotekerne initialiseres, kan den opregne de indlæste moduler i processen og se efter det pågældende symbol. Hvis dereferreringsmarkøren returneres af GetProcAddress() returnerer en nullpeger, så er dette modul den første indlæst og skal oprette den nødvendige struktur og indstille sin egen variabel. Ellers bruger den værdien opnået fra markøren.


Denne metode er fyldt med raceforhold, men hvis disse moduler kan initialiseres samtidigt. Du ville hellere have et enkelt vejledningsmodul, som hvert modul kan bruge som kommunikationspunkt.

Andre referencer 1


hvad med at skabe en navngivet delt hukommelse? [9]


det ville give dig mulighed for at dele en del af hukommelsen uden besværet med at få en adresse, der er gyldig i proceskonteksten. den første DLL-indlæsning skaber den delte hukommelse, den næste DLL kan derefter direkte få adgang til hukommelsen, og du kan opbygge dit eget messaging API oven på dette.

Andre referencer 2


cdhowie giver nogle gode grunde til, at dette er en dårlig idé.


Men hvis du virkelig vil gøre dette uden at forurene den globale delte hukommelses navneområde: Registrér en vinduesklasse i dit DLL-indgangspunkt, men send EXE s eksempel som feltet hInstance i vinduesklassen.


Hver DLL kan kontrollere, om klassen allerede er registreret; Hvis ikke, registrer dig selv. Den første DLL til at registrere vinduesklassen bliver master. For at få en peger til en struktur, der initialiseres af masteren i de efterfølgende indlæste DLL'er, skal du danne et vindue med kun besked af denne klasse og bruge SendMessage til at påberåbe sig dets vindueprocedure (i master DLL).