[Borland c++] Hoe moet je informatie delen tussen twee apps

[Verwijderd]

Hoi,

Ik ben opzoek naar een eenvoudige manier om informatie te delen tussen twee aparte applicaties geschreven in borland c++. Ik wil dit niet doen met behulp van een tekstbestandje maar ik wil echte pointers, integers etc kunnen doorgeven. Bestaat er een eenvoudige manier om dit te doen. Bijvoorbeeld programma 1 (invoer.exe) daar voer ik een getal in en programma 2 (uitvoer.exe) print dat getal op het scherm. Ik moet integer arrays kunnen uitwisselen tussen twee applicaties. Als iemand zou weten hoe dit moet en een voorbeeldje kan geven dan zou ik dit heel erg fijn vinden

alvast bedankt

[Daspeed]

http://www.google.nl/sear...&btnG=Google+zoeken&meta=
Volgens mij staat bij de eerste hit wel wat.

[ Voor 22% gewijzigd door Daspeed op 06-06-2006 16:43 ]

[.oisyn]

Echte pointers doorgeven gaat natuurlijk niet werken. Je applicaties hebben beide hun eigen process space, en een pointer wijst altijd naar data binnen datzelfde proces, dus je zult zelf je marshalling moeten regelen. Maar het concept waar je naar zoekt is shared memory, dat in Windows wordt bewerkstelligd door memory mapped files.

Overigens, als het echt alleen om het doorgeven van gegevens gaat zonder dat beide processen het geheugen tegelijkertijd gebruiken, zou je ook kunnen overwegen om named pipes of sockets te gebruiken voor de communicatie. Dat hoef je ook niet na te denken over synchronisatie en alle valkuilen die daarbij komen kijken.

[ Voor 33% gewijzigd door .oisyn op 06-06-2006 16:45 ]

[NMe]

Probeer de zoekterm "application hooking" eens.

[RobIII]

-NMe- schreef op dinsdag 06 juni 2006 @ 16:43:
Probeer de zoekterm "application hooking" eens.

IPC oftewel Inter Process Communication lijkt me een correctere term

[.oisyn]

-NMe- schreef op dinsdag 06 juni 2006 @ 16:43:
Probeer de zoekterm "application hooking" eens.

En dat is dan weer heel wat anders

[ReverendBizarre]

Pointers tussen verschillende processen delen gaat niet lukken. Ieder proces heeft zijn eigen geheugen context dus een pointer binnen proces 1 is niet geldig in proces 2 (probeer het maar handmatig te doen door een een applicatie een pointer te dereferencen die in een andere applicatie geldig is, gegarandeerd dat je een memory access violation fout krijgt).

[edit: spuit 17]

[ Voor 3% gewijzigd door ReverendBizarre op 06-06-2006 16:47 ]

[NMe]

.oisyn schreef op dinsdag 06 juni 2006 @ 16:46:
En dat is dan weer heel wat anders

Heel wat anders dan shared memory ja, maar het is wel degelijk toepasbaar hier, lijkt me? Al ben ik het met jou en RobIII eens dat IPC waarschijnlijk makkelijker en logischer is.

[.oisyn]

Nou, application hooking gaat er meer om dat je bepaalde (API) calls naar functies hookt zodat ze eerst door je eigen functie gaan, waardoor je bijvoorbeeld paramaters en return-waardes kunt wijzigen of simpelweg de calls kunt monitoren (denk aan een application firewall die de socketfuncties hookt).

[NMe]

Hmm, dan heb ik zelf een verkeerd beeld van die term en moet ik zèlf maar even op die term gaan Googlen.

[RobIII]

-NMe- schreef op dinsdag 06 juni 2006 @ 17:02:
Hmm, dan heb ik zelf een verkeerd beeld van die term en moet ik zèlf maar even op die term gaan Googlen.

Je zou het kunnen (mis)bruiken om te communiceren tussen applicaties, dat heb je dan weer wel begrepen Bedoel jij niet gewoon window messages m.b.v. sendmessage e.d? En anders heb ik hier wat leesvoer over hooks

offtopic:
Who's your daddy?

[ Voor 60% gewijzigd door RobIII op 06-06-2006 17:10 ]

[Verwijderd]

ok bedankt.. nu weet ik ten minste waarna ik opzoek ben . Ik ga eens zoeken naar wat voorbeeldjes

[Verwijderd]

Je kan ook nog kijken naar de proxy pattern die iets soortgelijks implementeerd.

[RobIII]

Verwijderd schreef op woensdag 07 juni 2006 @ 00:37:
Je kan ook nog kijken naar de proxy pattern die iets soortgelijks implementeerd.

Binnen dezelfde applicatie ja. En daar ging het nou net niet om Ga je een proxy-pattern toepassen op losse applicaties dan kom je weer terug op IPC d.m.v. (named) pipes, shared memory, messagequeues, sockets, files etc. om die "proxy" met de andere applicatie te laten babbelen.

[ Voor 79% gewijzigd door .oisyn op 07-06-2006 12:04 . Reden: reactie op een verwijderde post weggehaald :) ]

[Verwijderd]

RobIII schreef op woensdag 07 juni 2006 @ 00:59:
[...]

Binnen dezelfde applicatie ja. En daar ging het nou net niet om Ga je een proxy-pattern toepassen op losse applicaties dan kom je weer terug op IPC d.m.v. (named) pipes, shared memory, messagequeues, sockets, files etc. om die "proxy" met de andere applicatie te laten babbelen.

En @Hieronder:

[...]

<zucht>
Mensen, lees nou eens gewoon... Wat denk je dat er met sockets wordt bedoelt?

De proxy pattern kan je distributeren door simpelweg de communicatie via het Subject door een socket naar de proxy te laten lopen waardoor de proxy dan de methode op het RealSubject uitvoerd. Evt. return waarden kunnen dan weer terug gestuurd worden door het socket. Een generiek protocolletje voor de communicatie moet er wel zelf verzonnen worden.

.Net Remoting is bijv een (transparante) implementatie van het proxy pattern over sockets.

[RobIII]

Het gaat in dit topic over het communiceren tussen twee apps. Daar heeft het proxy pattern geen <piep> mee te maken. Dat je proxy babbelt d.m.v. sockets is hier de clue. En of dat dan sockets of pipes, shared memory of voor mijn part emails of bestanden zijn is dan om het even. Wat jij in feite zegt is dat je SOAP moet gebruiken, maar je vergeet even dat het (doorgaans) over sockets naar buiten gaat (en naar binnen komt).

Los daarvan vind ik sockets nog een van de mindere oplossingen gezien de overhead. Ga dan voor semaphores, (named)pipes of shared memory als je weet waar je mee bezig bent.

[ Voor 42% gewijzigd door RobIII op 07-06-2006 01:59 ]

[Wim-Bart]

De beste methode is "memory mapped" bestanden of "Named pipes". Je applicatie of .dll hooken in een andere app gaat wel, maar je app kan ook leuk dood gaan door DEP.

[RobIII]

wim-bart schreef op woensdag 07 juni 2006 @ 02:10:
De beste methode is "memory mapped" bestanden of "Named pipes".

En wederom worden de reeds 15 maal gegeven antwoorden herhaald...

wim-bart schreef op woensdag 07 juni 2006 @ 02:10:
Je applicatie of .dll hooken in een andere app gaat wel, maar je app kan ook leuk dood gaan door DEP.

En waarom zou DEP zich bemoeien als je netjes hooked? Als DEP ingrijpt heb je ergens iets niet goed gedaan en moet je (doorgaans althans, wellicht dat DEP nukken heeft waar ik geen weet van heb) het probleem bij jezelf zoeken als "programmeur" van betreffende applicatie. Het principe achter DEP heeft niks te maken met "je app....dood gaan" omdat je hooked. Je wil niet weten hoeveel "hooks" er in een "kaal systeem" al gaande zijn, dan kunnen jouw paar "hookjes" er ook nog wel bij hoor mits ze zich gedragen

Zou DEP problemen geven met hooks dat zou zo'n beetje elke virusscanner, (application)firewall, keylogger en meer van dat soort "applicaties" die tussen OS en user (of tussen OS en "buitenwereld") gaan zitten bij voorbaat al "dood gaan". En dan heb ik het alleen nog maar over de hooks die je je wat makkelijker kunt voorstellen, en niet over hooks voor bijv. debug doeleinden of window hooks.

[ Voor 53% gewijzigd door RobIII op 07-06-2006 02:23 ]

[RobIII]

Ik zal het nog een keertje samenvatten, want de link die ik hier al 4x ofzo heb gepost is schijnbaar niet bereikbaar voor de rest van de wereld:

quote: http://en.wikipedia.org/wiki/Inter-process_communication

Method	Provided by (Operating systems or other environments)
File	All operating systems.
Signal	Most operating systems; some systems, such as Windows, only implement signals in the C run-time library and do not actually provide support for their use as an IPC technique.
Socket	Most operating systems.
Pipe	All POSIX systems.
Named pipe	All POSIX systems.
Semaphore	All POSIX systems.
Shared memory	All POSIX systems.
Message passing (shared nothing)	Used in MPI paradigm, Java RMI, CORBA and others.
Memory map	All POSIX systems; may carry race condition risk if a temporary file is used. Windows also supports this technique but the APIs used are platform specific.
Message queue	Most operating systems.
Mailbox	Some operating systems.

[ Voor 112% gewijzigd door .oisyn op 07-06-2006 12:03 ]

[.oisyn]

Modbreak:

Ik heb even de bezem door het topic gehaald. Mensen, LEES DE DRAAD VOOR JE BLAAT! De topicstarter wordt heus niet geholpen door dingen oeverloos te herhalen. Als je gewoon geen zin hebt om eerst de topic door te lezen, post dan gewoon niet, ookal weet je het antwoord