De la cine și cum să obțineți obținerea unui obiect COM
Este posibil ca, în acest stadiu, nu este încă prea interesant, dar vreau să repet cuvintele mele - cunoașterea exactă a filozofiei interacțiunii obiectelor, cunoașterea instrumentelor și a instrumentelor utilizate în diferitele etape ale acestui proces este inevitabil. COM nu este posibil să se „reconstrui toate“ sau de a începe debugger și urmăriți orice parte a programului - parte a pachetului software va fi obiecte „străine“, cu care vor fi tratate în același mod ca și cu propria valoare. Și aflați "ce este în interiorul lor" și nu puteți "repara" ceva, va trebui să vă bazați doar pe respectarea exactă a protocolului de interacțiune.
Pentru a face acest lucru, avem nevoie de câteva cunoștințe despre detaliile "distrugerii DLL". Anterior sa spus că sistemul de operare se referă în mod standard la modulul numit COM-server și îl încurajează să emită o referință la obiectul COM. Întrebarea la care vreau să primesc un răspuns este cum?
Dacă vă întoarceți la detalii tehnice, probabil că ați auzit că DLL nu este doar o bucată de cod. În interiorul DLL există tabele speciale care descriu funcții care sunt "externe" din punctul de vedere al limitei acestui DLL. Primul tabel se numește IMPORTURI - acestea sunt funcțiile pe care DLL le cere. dar care nu sunt implementate în DLL în sine. Al doilea tabel se numește EXPORTS. descrie funcțiile care sunt implementate în DLL și sunt oferite tuturor utilizatorilor.
În oferta Visual Studio, există un instrument foarte util pentru explorarea fișierelor binare - programul dumpbin.exe. Acesta este localizat în directorul ". \ Program Files \ Microsoft Visual Studio \ VC98 \ Bin" și este controlat de interfața de linie de comandă. Scopul acestui program este de a scoate conținutul tabelelor conținute în fișierele binare în formă lizibilă de om. O folosim astfel cum este aplicată în mod deliberat COM -Server, am găsit într-un articol anterior - la Dao350.dll, care pe mașina mea se află în directorul „C: \ Program Files \ Common Files \ Microsoft Shared \ DAO“.
Rulați dumpbin cu următoarea comandă din linia de comandă:
dumpbin.exe / exports C: \ Program Files \ Common Files \ Microsoft Shared \ DAO \ DAO350.DLL> tttt.txt
Redirecționarea ieșirii dumpbinului la fișierul tttt.txt se face din motive de conveniență. În mod implicit, programul iese în consola și vreau să obțin ieșirea astfel încât să poată fi examinată după ce este terminată. Să vedem ce avem în dosar. Și am obținut (cu câteva abrevieri):
Microsoft (R) COFF Binar File Dumper Versiunea 6.00.8447
Dumpul fișierului DAO350.DLL
Secțiunea conține următoarele exporturi pentru DAO350.dll
Acesta este exact ceea ce dorim - tabelul EXPORTS. Acest DLL are doar cinci funcții exportate! Făcând înainte, voi spune - toate sunt folosite exclusiv pentru funcționarea COM. și anume în fața noastră este un server COM pur, care nu are intenția de a face altceva.
Și din aceste cinci funcții în momentul de față există doar un singur lucru - DllGetClassObject. Este aceeași funcție care determină sistemul să spună serverului ce obiect ar trebui să facă și să ofere sistemului. Un apel către MSDN oferă următorul prototip al acestei funcții:
Dar de aici vine argumentul și ce înseamnă? Și această întrebare și răspunsul au fost evitate cu diligență de la începutul prezentării noastre, dar între timp, programarea componentelor începe, în general, cu un răspuns la această întrebare. riid este ID-ul interfeței. În paragraful 5 al expunerii noastre filosofice au stat - "cum să interacționăm unul cu celălalt, obiectele însăși știu". De fapt, obiectele COM interacționează între ele prin interfețe și - nimic altceva.
Trimiteți-le prietenilor: