Keresés

Részletes keresés

NevemTeve Creative Commons License 2016.05.02 0 0 47

A gcc-ben (mingw) két lehetőség van:

 

__declspec(dllexport) int expfun1 (int par1, int par2) {}
int __attribute__((dllexport)) expfun2 (int par1, int par2) {}

 

(Bővebben: mindkettő ugyanazt jelenti, és lehet a típus előtt, vagy a függvény neve előtt. Az '_export'-ot nem érti.)

 

Mindezek nem működnek unix alatt (mármint amikor unix alatt unixra fordítunk), ott csak ez működik: __attribute__ ((visibility ("default"))) ami a default is, szemben a __attribute__ ((visibility ("hidden"))) értékkel.

 

Továbba van egy olyan, hogy __stdcall -- ezt a Windows-os fordítókon kívül a gcc/mingw is érti, akár simán akár __attribute__(stdcall) szintaxissal. Natív gcc-ben egyik sem megy.

 

Ebből a következőt vélem levonhatni:

#if defined (__unix__)
    #define _export __attribute__ ((visibility ("default")))
    #define __stdcall

#else --> tf Windows
    #if defined (__GNUC__)
        #define _export __declspec(dllexport)
    #endif
#endif

int _export __stdcall expfun3 (int par1, int par2)
{
    return par1*par2;
}

 

NevemTeve Creative Commons License 2016.05.02 0 0 46

Kipróbáltam egy régebbi BC4.5-öt is, abban csak az _export működik:

<return_type> _export <function name>

Előzmény: NevemTeve (45)
NevemTeve Creative Commons License 2016.05.01 0 0 45

Kipróbáltam BCC55-ben az _export és __declspec(dllexport) eseteit, az alábbiak működtek:

 

int _export exp1 (int par1, int par2) { return par1+par2; }
int __declspec(dllexport) exp2 (int par1, int par2) { return par1-par2; }
__declspec(dllexport) int exp3 (int par1, int par2) { return par1*par2; }

szóval az _export csak a típus és a név között lehet, __declspec viszont a típus előtt is.

NevemTeve Creative Commons License 2015.06.29 0 0 44

A DLL-ek egyik érdekessége, hogy felhasználhatók thread-ek inditásának detektálására. Mondjuk ha a program úgy érzi, hogy nem akarja, hogy külső komponensek (plugin, debgger, malware) thread-eket indítsanak, akkor ezt egy DLL-ben tudja megoldani (DLL_THREAD_ATTACH)

Persze ha a haxor a DLL-t is lecserélheti egy sajátra (vö: search path), akkor ez sem sokat segít.

NevemTeve Creative Commons License 2015.06.25 0 0 43

Viszont van némi káosz galaktika azon a ponton, hogy hogyan kell az exportált függvények nevét eltorzítani, itt van például egy szép csúnya táblázat:

http://www.willus.com/mingw/yongweiwu_stdcall.html

NevemTeve Creative Commons License 2015.06.25 0 0 42

Ha viszont a DllEntryPoint-ot kivesszük, akkor a DllMain hívódik meg minden esetben; de a program akkor is működik, ha mindkettőt kivesszük.

NevemTeve Creative Commons License 2015.06.25 0 0 41

Csináltam egy DLL-t (compiler: BCC5.5), amiben van DllMain meg DllEntryPoint is, hogy vajon melyiket mikor hívja; statikus és dinamikus linkeléssel is kipróbáltam:

 

C:>mindsta.exe
DllEntryPoint: fwdReason=1
static main: start
Dll.SomeFun: running
static main: stop
DllEntryPoint: fwdReason=0

 

Szóval csak a DllEntryPoint hívódott meg

 

C:>minddyn.exe
dynamic main: before LoadLibrary
DllEntryPoint: fwdReason=1
dynamic main: after LoadLibrary
dynamic main: GetProcAddress("_SomeFun") returned 00431286
Dll.SomeFun: running
dynamic main: before FreeLibrary
dynamic main: after FreeLibrary
DllEntryPoint: fwdReason=0

 

Itt is csak a DllEntryPoint hívódott meg

NevemTeve Creative Commons License 2012.10.15 0 0 40

Itt azt írják, hogy a regular/extension különbség csak az MFC-t használó DLL-ek esetén létezik.

Előzmény: NevemTeve (12)
DJG Creative Commons License 2012.06.21 0 0 39

Kellene neked erről egy jó tananyag... :-))

 

Azt jelenti, hogy az utasításoknak van egy alapértelmezett operandusmérete, értve ezalatt azt, hogy milyen méretű operandusokon dolgoznak (pl. 16-bites vagy 32-bites adatok). Ha egy eredetileg 16-bites utasítás elé odateszed ezt a prefixet, akkor az utasítás operandusmérete megváltozik, mondjuk, ezentúl 32-bites operandusra fog vonatkozni a művelet). Hogy mely utasításoknál mekkorából mekkorát csinál, azt a megfelelő utasítástáblázatokban találhatod meg.

Előzmény: finally (36)
NevemTeve Creative Commons License 2012.06.16 0 0 38

Vagy hozzászerkeszted az executable-hoz (esetleg egy import library használatával), vagy futásidőben a LoadLibrary-val (+GetProcAddress).

Előzmény: finally (37)
finally Creative Commons License 2012.06.16 0 0 37

hogy tudom egy dll változóit és függvényeit elérni külső programból? olyan dll-ről van szó, amit nem én írtam, tehát nem tudom változtatni, a külső programnak kéne tudnia használni.

finally Creative Commons License 2012.06.16 0 0 36

ezt hogy kell értelmezni?

"Operand-size override prefix" ezt jelentené a 66?

Előzmény: NevemTeve (33)
NevemTeve Creative Commons License 2012.06.15 0 0 35

ad2: Persze

Előzmény: szjozsi79 (34)
szjozsi79 Creative Commons License 2012.06.15 0 0 34

Te mindent tudsz? :-)

 

A "NevemTeve" a "NemTe"-ből származik minden magánhangzó helyére -v--t rakva?

Előzmény: NevemTeve (33)
NevemTeve Creative Commons License 2012.06.14 0 0 33
Előzmény: finally (32)
finally Creative Commons License 2012.06.13 0 0 32

"Ha van konkrét kérdésed, tedd fel bátran!"

 

eddig is bátran tettem fel a kérdéseimet:)

értesz a gépi kódhoz? pl. 32 bites intel procin mit jelent a 66 gépi kód? ez vesszős kód és a 66 a vessző? vagy az része az utasítások egy részének?

Előzmény: NevemTeve (31)
NevemTeve Creative Commons License 2012.06.11 0 0 31

Nem, nem ugyanúgy működik, hanem nagyon hasonlóan. Úgyanúgy azért sem működhet, mert a különféle unixokban sem működik egyformán. Ha van konkrét kérdésed, tedd fel bátran!

Előzmény: finally (30)
finally Creative Commons License 2012.06.10 0 0 30

és az akkor ugyanúgy működik, mint a windowsos megfelelője?

Előzmény: NevemTeve (29)
NevemTeve Creative Commons License 2012.06.10 0 0 29

Igen, a shared object.

Előzmény: finally (28)
finally Creative Commons License 2012.06.10 0 0 28

van a dll-nek a linux alatt megfelelője?

Előzmény: NevemTeve (27)
NevemTeve Creative Commons License 2012.04.19 0 0 27

Annyira unatkozom, hogy elhatároztam, egypár programot Win alatt is lefordítok (Borland 5.5 Command Line Tools), mégpedig, hogy viccesebb legyen, DLL-t csinálok belőle (illetve LIB-et és DLL-t is kellene, a unix-os *.a és *.so fájloknak megfelelően).

Most az a rettentő érzésem van, hogy csak az fog a DLL-ből exportálódni, ami elé odaírom, hogy __declspec(dllexport)... Esetleg lehetne találni egy módot, hogy ezt ne kelljen, hanem legyen egy 'mindenki export, aki nem statikus' opció?

NevemTeve Creative Commons License 2010.08.13 0 0 26
De őszintén, mit lehet erre mondani, azon kívűl, hogy majd meglátod?
Bővebben itt: http://tvtropes.org/pmwiki/pmwiki.php/Main/UnpredictableResults
Előzmény: bandesz22 (25)
bandesz22 Creative Commons License 2010.08.13 0 0 25

Köszönöm a segítséget!!!

Nekem jó volt a windows, 10-es directx-et raktam fel (hivatalosat) és nyomta a hibaüzeneteket. átneveztem dwmapi.dll-t  volt_dwmapi.dll-re és mindek tökéletesen jó! Ettől ugye nem fog fagyni a gépem?

 

Előzmény: NevemTeve (17)
blade36 Creative Commons License 2010.04.16 0 0 24
Okés elnézést. Ujrapakoltam a windowst és tökéletes most. Ha valakit felzaklattam sajnálom:P, és köszi minden segitséget.
DJG Creative Commons License 2010.03.21 0 0 23
Nem segít, persze, hogy nem segít. De mégis, mit vársz el tőlünk (eltekintve attól, amit NevemTeve is mond, hogy itt aztán egyáltalán nem jó topikban vagyunk ehhez, hiszen programozáshoz ennek semmi köze)?

Vannak ötleteink eredeti, rendes Windowsra. De amibe valaki belebuherált, arra milyen ötletünk legyen? Honnan tudjuk, mit buherált bele, mit szedett ki, mit tett bele feleslegesen (hiszen a kiindulási pont, hogy aki buherált Windowst csinál, az nem ért hozzá, hozzáértő ember ilyen ostobaságot nem követ el). Olyan, mintha egy autós topikban kérdeznéd, hogy mi a baj a kocsid motorjával, csak éppen senki nem tudja, mi mindent cseréltek ki benne ahhoz képest, amilyen gyári állapotról mindenki tud, tehát amihez viszonyítva lehetne véleménye, tapasztalata.

Egyetlen használható javaslat van ilyenkor, buherált Windows komplett törlése, eredeti Windows telepítése. Onnantól kezdve semmilyen kodekcsomag (az a buhera minősített esete), semmilyen gyanús, ismeretlen, ellenőrizetlen program, és menni fog. És ha egyszer majd valami mégis elromlik, akkor lesz hozzá segítség is, hidd el.
Előzmény: blade36 (21)
NevemTeve Creative Commons License 2010.03.21 0 0 22
Az segítene, ha értelmesen leírnád, hogy mit csináltál, segített-e a dwmapi.dll átnevezése, mi a pillanatnyi állapot... és persze az se ártana, ha ráébrednél, hogy ennek semmi köze a Programozás fórumhoz...
Előzmény: blade36 (21)
blade36 Creative Commons License 2010.03.21 0 0 21
Jó ez télleg segit a helyzetemen...
Előzmény: DJG (20)
DJG Creative Commons License 2010.03.21 0 0 20
"Buherált Windwos XP"? Akkor nincs válasz. Ilyet sose szabad feltenni, ha fegyverrel kényszerítenek, akkor se.
Előzmény: blade36 (18)
blade36 Creative Commons License 2010.03.20 0 0 19
még annyit hogy nem tudod lehet olyat hogy amiket utólag telepitettem direct x azt letörölni csak ami alapbol fenn volt az maradjon? Lehet elég low kérdés de a direct x a gyengém:D
Előzmény: NevemTeve (17)
blade36 Creative Commons License 2010.03.20 0 0 18
ez egy buherált windows xp amiben alapbol benne volt a direct x 10 es. A lejátszóim mikor elinditottam egy filmet el se kezdték lefagyott a gép. Ezután (én hülye) ujraraktam a direct x et, mer ez régebben segitett ezen... azután kezdte ezt a hibaüzenetet kiirni.. Nem tudom ezek hogy függhetnek össze. Esetleg vmi tipped van? MEgpróbálom amit mondtálés köszönöma gyors segitséget.
Előzmény: NevemTeve (17)

Ha kedveled azért, ha nem azért nyomj egy lájkot a Fórumért!