Gå til innhold

Koble seg til en prosess fra et annet program


Anbefalte innlegg

Folkens...

Vi har et Win32 program som bruker noen .NET komponenter som jeg har skrevet.  Dette funker veldig greit og på denne måten så kan jeg nyttiggjøre alt .NET måtte ha å tillby i vårt Win32 program

Så er det sånn at vi trenger å snakke med Office programmer.  Jeg har dermed laget en Addin til Office programmene som tar imot DragDrop eventer og skal også håndtere annen interaksjon mellom Office og vårt Win32 program.

Og det er her skoen klemmer.

Dagens "gamle" løsning er at vi har et VB6 program som kobler seg til Office på en litt gammeldags metode og dette programmet bruker et utvekslingsprogram skrevet i samme språg som vårt Win32 program, som igjen skriver til databasen for programmet.  Blir veldig sølete og vanskelig å vedlikeholde

 

Jeg tenkte at det måtte da være en mere elegant måte å gjøre dette på.  Kan jeg f.eks. provide et interface på tvers av prosesser?  Noe ala WebServices.

 

Eller er det andre måter som er enda bedre

Lenke til kommentar
Videoannonse
Annonse

Det fins mange måter du kan gjøre det på, du må bare vite hvilke som ikke fungerer så bra for deg. Jeg kan ramse opp noen metoder:

 

1. DLL med delt minne slik at flere prosesser har tilgang til samme data

2. Pipes

3. Winsock

4. Åpne prosessen direkte

5. Bruke windows registeret til å lagre data (eventuelt ini filer)

6. Lage en windows tjeneste

 

Lenke til kommentar

1: DLL med delt minne var nytt for meg.  Visste ikke engang at det var mulig??  Trodde hver prosess hadde sitt egne virtuelle område.  Er nysgjerrig på dette.  Har du noen linker du kan anbefale ut over det jeg eventuellt finner i google ?

 

2 :Pipes er vel det jeg har landet på så langt.  Da spesifikt på Mailslot da jeg stort sett kun trenger enveis komunikasjon.  Kikket litt på pipes generellt og ser jo nytten i dette. 

 

3: WinSock er jo nesten det samme som pipes egentlig.  Kunne brukt det og, men har en følelse av at jeg da må fiddle med brannmur greier.  Ikke noe problem så klart på egen utvikler boks, men ser for meg en rødglødende telefon på support når vi plutselig krever en eller annen port i brannmuren

 

4: Åpne prosessen direkte? 

5: Reg/Ini - nehhhhh

6: Windows service: tjja, kansje...

Lenke til kommentar

Du lager bare en section med minne og setter shared flagget på den, så kan alle prosesser som laster in dll'en bruke samme minneområde. Du kan ha både private og delte minneområder i dll'en samtidig. Det er ikke noe magisk som skal til, du endrer bare flagget på en page med minne når du kompilerer en dll. Du kan forøvrig endre på flaggene med VirtualProtect API og du kan bruke verktøy for å endre det direkte på fila hvis du ikke har kildekoden.

 

Ja det er ikke uten grunn at man har DLL'er, det er jo for å spare minne, så da lønner det seg å kunne dele visse områder av minnet den har mellom flere prosesser, men som sagt den har ikke "delt" flagget satt på som standard, det må du sette selv når du kompilerer dll'en. Sjekk options i linkeren din, der kan man ofte sette flags på sections.

Endret av VampireLord
Lenke til kommentar

Dette var veldig interresant, og helt ukjennt for meg..   Dette må jeg faktisk sjekke opp for det betyr jo at jeg kan utveksle data veldig enkelt. 

 

Men hva med klasser og metoder?  Jeg mener, hvis jeg f.eks. har en event deklrert i et object og to prosesser abonerer på dette eventet, vil det funke ?

Lenke til kommentar

I de aller fleste tilfeller, så er det ikke mulighetene som er problemet, men hva det er du skal gjøre for noe, må nesten vurdere ut ifra det. Personlig liker jeg ikke "spagetti systemer" hvor alt går i kryss og tvers, det lønner seg å ha et "interface" som du sa tidligere, hvor all makt er sentralisert, og forskjellige entiteter kan kalle opp denne makten, og denne makten igjen har tilgang på delte minneområder.

 

.NET er et veldig sterkt system, jeg vil anbefale å lage denne sentraliserte makten med vanlig Win32, så kan alle net applikasjoner kalle opp der uten å måtte gå i kryss og tvers, fordi Win32 er mer ubegrenset i hva du kan få til.

 

Husk at en server trenger skjeldent å være portabelt mellom systemer, den kjører som regel bare på èn maskin og da behøver du ikke net til selve tjenesten, derfor er win32 ypperlig til server-typer programmer.

Endret av VampireLord
Lenke til kommentar

ja, men i dette tilfellet er ikke en sentral server løsningen.  Eneste jeg skal ha til er å sende en beskjed fra en Office Addin til vårt program og omvendt.  Derfor hadde jo en DLL med shared memory vært knall.   En Mailslot løsning vil også fungere veldig bra, men krever litt mere programmering. 

 

Uansett, takker for alle tipsene

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...