[Hazar]

Pikalt pead murdnud selle üle aga ei mõtle välja.. siiamaani on

char * juku = "Tere";
LPVOID juhan = &juku;

ning nüüd on vaja lpvoidist tagasi saada char* (oletades et pikkus on teada)

milleks? programmA kirjutab programmB mällu byte array juku ning annab progammB'le array aadressi ning pikkuse, nüüd vaja programmBs sellega edasi toimetada kuid kuidagi ei saa datat kätte

[troglodyte]

LPVOID on ilmselt void pointer (void *)? Kui nii siis void pointerisse salvestatud mäluaadressil olevad andmed saab kätte *(char **)juhan abil.

[i8080]

char* juku = "Tere";
LPVOID juhan = &juku;

char* tuhajuhan = (char*)*juhan;

ja nüüd võid datat bait haaval näppida näiteks stiilis
char a = tuhajuhan[0];
või
char a = *(tuhajuhan + 0);

LPVOID alusel oletan kasutad win32 api.
ja kas protsesside (programmA ja programmB) mälu kopeerimiseks ikka kasutad ReadProcessMemory(..)
niisama pointerid teises protsessis ei viita samale data massiivile. igal protsessil on oma aadressruum ja teise ruumi pääsuks peab enne ligipääsu tekitama

[wigry]

Siin tekib jah pigem küsimus protsesside vahelises andmevahetuses. Win32 API-s peaks olema ka natuke elegantsemaid võimalusi kui lihtsalt teise protsessi aadress space'i baitide kirjutamine (kuigi mul tekib väike kahtlus, kas ikka niisama saab teise protsessi aadressruumi kätte, kui me just win98-st ei räägi)

[Hazar]

kirjutan VirtualAllocEx -> WriteProcessMemory, siia maani pole keegi vastu tõrkunud
kui oleks teada elegantsem võimalus siis kasutaks seda kuid mindagi muud (peale failile kirjutamise) pähe ei tulnud (tegu pole tingimata programmide vahelise suhtlusega vaid threadide ning need ei taha peale ühe lpvoidi millestki kuulda)

[wigry]

Nimetades mõningaid:

- Shared memory
- named pipe
- WinSock
- Mailslot

http://www.codeproject.com/KB/threads/Win32IPC.aspx

ja alati on võimalik kasutada MSMQ-d

[Hazar]

need näevad välja nii pirakad võrreldes minu 3 reaga saatja ja 2 reaga saaja poolel (oletades, et handle on mul naguinii olemas ja juba eelnevalt kasutuses)

[murka_]

Siiamaani olen kasutanud _beginthread() funktsiooni, millega annan kaasa argumendid void pointeriga. Olenevalt vajadusest on selleks argumendiks muutuja, struktuur või midagi enamat. Teises threadis teen lihtsa casti ja ongi mul ühised muutujad.

[wigry]

No jah, eks tööriist sõltub probleemist, et kui on vaja teha keerukas mitmest protsessist koosnev süsteem, siis arhitektuuriliselt on mõistlik valida siis korralik IPC lahendus. Kui aga vaja vaid kahe tillukese threadi vahel infot vahetada siis korrektne viis oleks seda teha läbi sünkroniseeritud globaalsete muutujate, millele on mõlemal threadil ligipääs. Siit kohe veel küsimus, et kui need threadid nii tillukesed on ja üldse lahendus tilluke, siis kas ikka peab mitu protsessi/threadi olema... Äkki overkill?

[murka_]

Äkki peab üks asi kestvalt midagi tegema ja teine thread annab ainult infot kas jätkata või peatuda, samas alati olema valmis kasutajalt sisestust vastu võtma?

[Hazar]

thread asub teises programmis CreateRemoteThread (mõte polegi performancis vaid pigem triggerina kasutades)

kui oleks kohalik siis teeb LPVOID automaatselt talle antud asjandusest pointeri ja püüdev funkt saab sedapidi kohe data juurde kuid oma address spaces tehtud pointeris pole teises protsessis tolku, siis peab refereerima target protsessis ehitatud tüüp pointerile kuid mul on saatjaks vb.net ja see ei jaga matsu laiali seega piirdusin vaid mälu aadressi saatmisega ja lasin target functil koha peal välja nuputada

[wigry]

Hmm, saadad mäluaadresse ja oled sunnitud tegema musta maagiat, selle asemel, et otse ühelt protsessilt andmeid teise protsessi saata. Et kuna ma olen aastaid integratsiooni valdkonnas toimetanud, siis taoline mäluaadressidega toimetamine tundub natuke kehvakese kodukootud IPC quickhackina. Mina analüüsiks situatsiooni ja panustaks õigele arhitektuurile. On ju hetkel tegu lisaks erinevate protsessidele ka erinevate keeltega, seega oleks vaja mingit kõrgema taseme toru, millega andmed ühest teise toimetada. Samas puudub mul muidugi igasugune info, kas korraliku lahenduse jaoks aega, ressurssi ja tahtmist kah oleks

[Hazar]

heh aega ja ressurssi oleks kuid tegu on "kärab küll" lahendusega vbl tulevikus kui asjast piisavalt kasu teen ümber

[mikk36]

Enamus ajutisi lahendusi on jääva loomuga.