[ Kvizak_Hadarak @ 11.09.2006. 22:01 ] @
Pozdrav
Ovako imam jedan problem sa pisanjem jednog dll-a (C++) dva ustvari dll-a jedan poziva drugi koji je vec
neko napravio i koji radi odlicno kada samo njega pozivam iz exe aplikacije sa LoadLibrary ga ucitam i funkcije
fetch-am sa GetProcAddress medjutim moram da ja napisem dll koji ce da koristi taj dll tad problem nastupa
i to oblika:

Unhandled exception at 0x77f60b6f in S2_test.exe: 0xC0000005: Access violation writing location 0x00030fc0.

isti daj dio koda koji sam napisao u svom dll-u za poziv ovog drugog dll radi dobro kad ga zapisem u apilikaciju hmm vrlo cudno
mislio sam da ne mogu pozivati dll iz dll mada tamo pise moze na msdn proba sam napraviti ja neki dll pa ga pozvati u nekom
dll kojeg sam takodje napravio pa to sve pozvao iz test aplikacije sve radi hmm da poludis...
Funkcije u svom dll ssam exportovao sa __cdecspec(dllexport) moze li ko da pomogne, je li ko imao iskustva
sa slicnim problemom svaka pomoc bi dobro dosla .....
vozdra
[ yooyo @ 12.09.2006. 09:03 ] @
Mozes pozivati DLL iz DLL-a bez problema. Proveri podesavanja kompajlera i po mogucstvu definisi calling konvenciju (cdecl, stdcal, ....)
Bez nekog parceta source-a tesko mogu da utvrdim gde je problem. Ako je moguce... pokazi deklaracije funkcija koje exportujes, nacin kako ih fetchujes, i kako ih pozivas, pa da pogledam malo bolje.

[ itf @ 12.09.2006. 09:10 ] @
Citat:
yooyo: Mozes pozivati DLL iz DLL-a bez problema. Proveri podesavanja kompajlera i po mogucstvu definisi calling konvenciju (cdecl, stdcal, ....)
Bez nekog parceta source-a tesko mogu da utvrdim gde je problem. Ako je moguce... pokazi deklaracije funkcija koje exportujes, nacin kako ih fetchujes, i kako ih pozivas, pa da pogledam malo bolje.

Ako se koristi MSVC++ mislim da je defaultna konvencija _cdecl, a kod Borlanda je _stdcall. Preporučam korištenje _stdcall konvencije jer neki programski jezici poput VB-a traže da DLL funkcije koriste baš tu konvenciju da bi ih se moglo koristiti.

U svakom slučaju stavi dio koda pa da vidimo o čemu je točno riječ...
[ Kvizak_Hadarak @ 12.09.2006. 12:40 ] @
Hvala na kometarima evo koda
#include <iostream>
#include <windows.h>
#include "defs.h"
#include "CCOM.h"
using namespace std;

#define DllExport __declspec(dllexport)

extern "C"
{
DllExport int GetSignalLevel()
{
HINSTANCE h;
DWORD AdapterHandle;
TTunerStatus TunerStatus;
char SS2Name[1000];

h=LoadLibrary("SkyDll.dll");
(FARPROC&)SkyOpen=GetProcAddress(h,"SkyOpen");
(FARPROC&)SkyClose=GetProcAddress(h,"SkyClose");
(FARPROC&)SkyAdapterGetHandle=GetProcAddress(h,"SkyAdapterGetHandle");
(FARPROC&)SkyAdapterTunerGet=GetProcAddress(h,"SkyAdapterTunerGet");



if(SkyOpen()) return 4;
if(SkyAdapterGetHandle(0, &AdapterHandle)) return 1;
if(SkyAdapterTunerGet(AdapterHandle, &TunerStatus, sizeof(TunerStatus))) return 2;

if(SkyClose()) return 3;
FreeLibrary(h);

return (int)TunerStatus.u64[2];

}

ima jos funkcija ali ova osnova nece da radi ali kad ovo stavi se u neki cpp sve radi hmm stvarno ne znam niti ovaj dll SkyDll.dll mogu koristi u C# ???
pozdrav
[ itf @ 12.09.2006. 13:38 ] @
Nisi provjerio da li LoadLibrary uopće vraća handle na dll, a bilo bi bolje i direktno nakon poziva GetProcAddress provjeriti je li se uspjela vratiti adresa funkcije.

U C# se to može koristiti. Evo malog primjera za npr. običnu funkciju sumiranja:
Code:
using System.Runtime.InteropServices;

[DllImport("MojDll.dll")]
static extern int Suma(int a, int b);
[ Kvizak_Hadarak @ 12.09.2006. 14:46 ] @
Da radio sam prije sa dll ovima u C# bas tako ali ovdje se javalja error kao gore sto sam napomenuo, sto se tice handle-a okay je i address-a funkcije je okay jer sam provjeravao sa disasemblerom sve je okay ali nece da radi ovako je pozivam

int (WINAPIV* GetSignalLevel)();
HMODULE h;

int max =0;

h=LoadLibrary("RASCore.dll");
(FARPROC&)GetSignalLevel = GetProcAddress(h,"GetSignalLevel");

max = GetSignalLevel();

Zakacio sam dll evo pa pogledajte ako mozete

[Ovu poruku je menjao Kvizak_Hadarak dana 12.09.2006. u 16:10 GMT+1]
[ yooyo @ 12.09.2006. 21:19 ] @
DllExport int GetSignalLevel() je kad se provuce kroz predprocesor:

Code:
extern "C" __declspec(dllexport) int GetSignalLevel();


Sto znaci da je calling konvencija _cdecl.

prototip za ovu func bi izgledao ovako:

Code:
typedef int (__cdecl * PFNGetSignalLevel)();
\

u DLL-u odakle pozivas GetSignalLevel uradi ovako:

Code:

PFNGetSignalLevel GetSignalLevel;
...
h = LoadLibrary("xxx.dll");
GetSignalLevel = (PFNGetSignalLevel)GetProcAddress(h, "GetSignalLevel");

int signal = GetSignalLevel();



[ Kvizak_Hadarak @ 14.09.2006. 00:31 ] @
Pa yooyoo u cemu je razlika to sto ja radim i to sto ti predlazes kad je to same shit hmhmm
da li se problem moze vezati za to sto nisam napisao DllMain funkciju tamo pise da je proizovljno to i da je sam generise kompailer ili vec ???
vozdra
[ yooyo @ 14.09.2006. 12:02 ] @
Hmm.. ni ja ne pishem DllMain, pa nemam takvih problema. Ukratko.. ako je ucitavanje DLL-a uspesno i mapiranje funkcije takodje uspesno, a poziv funkcije izaziva crash onda je ili funkcija bagovita ili imas problem sa calling konvencijom. Nemoj se oslanjati na WINAPIV i slicne konstrukcije jer im se menja znacenje od podesavanja projekta. Moze se desiti da su DLL-ovi kompajlirani sa razicitim podesavanjima i da to pravi problem.

Ja sam ti napisao kako ja radim i nemam problema. Ti mozes da probas moj nacin ili da i dalje trazis uzrok problema.
[ itf @ 14.09.2006. 12:03 ] @
Citat:
Kvizak_Hadarak: Pa yooyoo u cemu je razlika to sto ja radim i to sto ti predlazes kad je to same shit hmhmm
da li se problem moze vezati za to sto nisam napisao DllMain funkciju tamo pise da je proizovljno to i da je sam generise kompailer ili vec ???
vozdra
Meni par dll-ova nije radilo baš zato što nema DllMain funkcije.
[ Kvizak_Hadarak @ 14.09.2006. 15:40 ] @
Sve je to okay dobijem ja handle i pokazivac na funkciju ali se srusi nakon njenog pozivanja sve bi to bilo okay da on ne radi sam
ali kad ga covjek pozove iz neke aplikacije samog direktno radi dovraga....
ma okay je ta notacija yooyoo radi ona kao i ova direktno ali indirektno preko drugog dlla nece... nema resursa vise ni ideja hmm ne znam sta da se cini ...
vozdra
[ yooyo @ 14.09.2006. 16:49 ] @
hmmm SkyOpen, SkyClose, ... Mozda pokusavas da iskoristis neciji DLL? Da li imas prototipove funkcija koje pozivas? Mozda treba da odradis nesto pre poziva funkcije, (npr inicijalizacija COM-a) ili nesto slicno.

[ Kvizak_Hadarak @ 14.09.2006. 22:15 ] @
Pa naravno dakoristim tudji dll ko ga je napravio neam pojam a imam prototipe cojek zar ne citas sta pisem kazem ti da radi taj dll sve okay kad samo njega pozivam ali kad ga pozovem u aplikaciju kroz drugi dll nastane stranje ....
vozdra
[ itf @ 15.09.2006. 08:57 ] @
Citat:
Kvizak_Hadarak: Pa naravno dakoristim tudji dll ko ga je napravio neam pojam a imam prototipe cojek zar ne citas sta pisem kazem ti da radi taj dll sve okay kad samo njega pozivam ali kad ga pozovem u aplikaciju kroz drugi dll nastane stranje ....
vozdra
Izbaci bezobrazluk jer ovdje tebi ne vjerujem da je itko išta dužan. Ako hoćeš da te se razumije onda bi ti bolje preporučio da pišeš čitko, a ne da treba po pola sata da bi se ovo gore što nalikuje na tekst moglo dešifrirati.
[ Kvizak_Hadarak @ 15.09.2006. 22:32 ] @
Ne vidim razlog zbog cega nerviranje i vrijedjanje napisao sam vam sta mi se desava a vi mi predlazete nesto sto vec radi
ako ne zelis POMOC itf ne moras niko te ni nasta ne primorava ....
pozdrav
[ kiklop74 @ 16.09.2006. 00:35 ] @
Pogledao sam ono što si poslao u rar arhivi i te tvoje definicije su potpuno proizvoljne i netačne.

Način za dinamičko povezivanje funkcija iz dll-a koji si poslao je iz vremena windowsa 3.1 i ne koristi se u modernim verzijama windowsa. Sve funkcije iz dll-a koriste __cdecl konvenciju.

Tačan opis nekih funkcija može se naći ovde:

http://ss2.planetsat.ru/ss2api.htm

Evo ispravnog hedera sa funkcijama za bilo koji windows kompajler koji sam napisao i probao:

Code:

#ifndef SKYAPI_HH
#define SKYAPI_HH

#ifdef __cplusplus
extern "C" {
#endif

#ifndef WINAPIV
#define WINAPIV __cdecl
#endif

struct TTunerStatus
{  
   DWORD freq;       // khz 
   DWORD lof;        // khz 
   DWORD sr;         // ksym 
   DWORD fec; // 0=auto 1=1/2 2=2/3 3=3/4 4=5/6 5=7/8 6=auto
   DWORD pol; // 0=horizontal 1=vertical; 
   DWORD lnb_switch; // 0 
   DWORD diseqc;     // 0=none $10002=SimpleA $10006=SimpleB 
                          // $20002=Pos_A - Opt_A 
                          // $20006=Pos_B - Opt_A 
                          // $2000A=Pos_A - Opt_B 
                          // $2000E=Pos_B - Opt_B 
   DWORD u1;         // ? 
   DWORD sigq;       // value 3 if tuner locked / çíà÷åíèå 3 åñëè òþíåð çàëî÷åí
   DWORD u2;         // ? 
   DWORD u3;         // 1 - this value gets in time while switching tuner an another freq 
   DWORD u4;         // ? 
   DWORD u5;         // ? 
   DWORD sig_str;    // signal strength 0-100 (but realy there is something wrong (values like 0, 128, 255)) 
   DWORD u6;         // ? 
   DWORD u7;         // ? 
   BYTE u161;   // ? u16[1] - 232 unknown  if driver < 4.3.0 / 1
   BYTE u162;   // ? u16[2] - 3 = tuner locked = sigq   / 1
   BYTE u163;   // ? u16[3] - unknown   / signal level
   BYTE u164;   // ? u16[4] - unknown   / unknown
   BYTE u165;   // ? u16[5] - 1   / unknown
   BYTE u166;   // ? u16[6] - 1   / unknown
   BYTE u167;   // ? u16[7] - signal level = u64[3]
   BYTE u168;   // ? u16[8] - value = sig_str
  DWORD u64[30];   // ? u64[3] - real tuner signal level 0-100 / ðåàëüíûé óðîâåíü ñèãíàëà
          // u64[1]/1000 = SNR (if drivers >= 4.3.0)
};

struct DVBS
    {
        bool        Result;
        int            Frequency;   //
        int         SymbolRate;
        //int         Modulation;
        int         Polarity;
        int         LnbFreq;
        int            LnbKhz;
        int         Fec;
        int         AdapterCount;
        float         SNR;
        float         BER;        
        float         SignalQuality;
        int         TotalBlocks;
        int         Bandwidth;
        float       SignalLevel;
        int         MinTransponderFreqInKHz;
        int         MaxTransponderFreqInKHz;
        int         MinTunerFreqInKHz;
        int         MaxTunerFreqInKHz;
        int         MaxSymbolRateInBaud;
        int         MinSymbolRateInBaud;
        int         AutoSymbolRate;
};

typedef int (WINAPIV* SkyOpenType)(char*);

typedef int (WINAPIV* SkyCloseType)(void);

typedef int (WINAPIV* SkyGetNumAvailAdaptersType)(DWORD*);

typedef int (WINAPIV* SkyAdapterGetHandleType)(int, DWORD*);

typedef int (WINAPIV* SkyAdapterGetNameType)(int, char[38]);

typedef int (WINAPIV* SkyAdapterTunerGetType)(DWORD, TTunerStatus*,int);

typedef int (WINAPIV* SkyAdapterTunerSetType)(DWORD, TTunerStatus*,int);

#ifdef __cplusplus
}
#endif

#endif /* SKYAPI_HH */


A evo i kratkog primera kako ucitavati i pozivati funkcije:

Code:

void testskyapi()
{
  HINSTANCE libHandle_ = ::LoadLibrary("SkyDll.dll");
  if (NULL == libHandle_) {
    return;
  }// end if

  //
  SkyOpenType SkyOpen = reinterpret_cast<SkyOpenType>(::GetProcAddress(libHandle_,"SkyOpen"));
  SkyCloseType SkyClose = reinterpret_cast<SkyCloseType>(::GetProcAddress(libHandle_,"SkyClose"));
  SkyGetNumAvailAdaptersType SkyGetNumAvailAdapters = reinterpret_cast<SkyGetNumAvailAdaptersType>(::GetProcAddress(libHandle_,"SkyGetNumAvailAdapters"));
  char value[1000] = {0};
  int result = SkyOpen(value);
  if (result == 0) {
    ShowMessage(AnsiString(value));
    SkyClose();
  }
  
  ::FreeLibrary(libHandle_);

}


[ kiklop74 @ 16.09.2006. 15:53 ] @
Citat:

Ako se koristi MSVC++ mislim da je defaultna konvencija _cdecl, a kod Borlanda je _stdcall.


Ovo je netacno. Svi windows kompajleri (pa i Borlandov) po defaultu koriste __cdecl. Kao i sve drugo i ovo se moze promeniti pa je zato uvek preporucljivo definisati u hederima koja konvencija se koristi za neku funkciju/klasu/promenjivu itd.

[ Kvizak_Hadarak @ 17.09.2006. 00:21 ] @
Pozdrav kiklop74
Ovako meni funcija DWORD (WINAPIV* SkyOpen)(char *) nece da radi sobzirom na ovu definiciju oce ovako zato
DWORD (WINAPIV* SkyOpen)() tako je i prikazana u PEDisassembler-u tj kao DWORD SkyOpen() druga stvar nemam vise onog exception-a sada dobra stvar ali mi vraca da SkyOpen da ne moze da otvori karticu tj vrati 1 a treba 0.....
Da li Vi mozete importovati SkyDll.dll u C# meni nece vraca opet i tamo 1 funkcija SkyOpen()...
Pozdrav
[ kiklop74 @ 17.09.2006. 03:14 ] @
Ja sam probao dll koji si poslao i sa definicijom funkcija koje sam postovao sve funkcije se pozivaju kako treba.

E sad sto ne rade kako ti mislis da treba da rade - nemam pojma.

Ja nisam nicija besplatna tehnicka podrska, ovo sto sam postovao je bila cista dobra volja. Dalje ne mogu da pomognem moraces da se snadjes sam.

I ubuduce se trudi da pises preciznije. Nacin na koji pises poruke ti ni malo ne pomaze u komunikaciji ovde na forumu.



[ Kvizak_Hadarak @ 17.09.2006. 20:17 ] @
Pa nisam ni mislio da ste mi Vi tehnicka podrska niti bi zelio da budete, ljepo sam pitao ne vidim razlog sto ste svi vi nesto ljuti, napeti ja sam pitao za pomoc a ne zahtjevao. Jesam li ja igdje izricito zahjtevao sta ???????????
Ovo je valjda forum gdje bi osobe zelje da podjele iskustva sa ostalim hmmm ne znam kako ga Vi vidite nije ni bitno...
A sto se tice vaseg prvog odgovora vi meni niste nista odgovorili povodom datog problema samo ste mi rekli ono sto vec mi radi meni je problem iportovati taj SkyDll.dll u drugi dll nece tamo da radi ako niste upuceni....
hvala vam svima na pomoci........
[ itf @ 18.09.2006. 08:45 ] @
Citat:
kiklop74: Ovo je netacno. Svi windows kompajleri (pa i Borlandov) po defaultu koriste __cdecl. Kao i sve drugo i ovo se moze promeniti pa je zato uvek preporucljivo definisati u hederima koja konvencija se koristi za neku funkciju/klasu/promenjivu itd.
Ne bih se složio. Pogledaj što se točno nalazi u dll-u nakon compiliranja istog dll-a unutar BCBa i VC++a. Sasvim drukčiji nazivi funkcija i to baš zbog konvencije (isprobano). :)
[ kiklop74 @ 18.09.2006. 14:12 ] @
Ovaj put nisi u pravu. To o cemu govoris je nacin na koji msvc i borland eksportuju C funkcije sa __cdecl konvencijom i koji nije identican.

Da razjasnimo dve stvari:

1. calling conventions odredjuju nacin na koji ce parametri neke funkcije biti prosledjeni.
2. name mangling opisuje nacin na koji ce se generisati ime eksportovane funkcije i to delom zavisi i od konvencije funkcije.

Po pravilu C funkcije sa __cdecl konvencijom treba da budu eksportovane pod imenom _<imefunkcije> ALI microsoft je resio da uradi stvari drugacije od ostalih kompajlera tako da svaka eksportovana C funkcija u msvc ce imati eksportovano ime BEZ _ bas kao da je koriscena __stdcall konvencija i otuda zabuna.

Dakle ako imamo ovakvu funkciju:

Code:

#ifdef __cplusplus
extern "C" {
#endif

#ifdef DLLTEST_EXPORTS
#define DLLTEST_API __declspec(dllexport)
#else
#define DLLTEST_API __declspec(dllimport)
#endif

DLLTEST_API void __cdecl testcdecl(int intParam);
DLLTEST_API void __stdcall teststdcall(int intParam);

#ifdef __cplusplus
}
#endif


U MSVC ce biti eksportovane ovako:
Ordinal Name
2 _teststdcall@4
1 testcdecl

I sad se verovatno pitas kako onda svi sistemski dll'ovi kompajlirani sa msvc koji koriste konvenciju __stdcall nemaju ove kuke i kvake?

Jednostavno - microsoft ovo resava koriscenjem DEF fajlova. Sa Def fajlovima se moze promeniti naziv eksportovane funkcije po potrebi. Ako se koristi def fajl za eksportovanje onda __declspec(dllexport) treba ukloniti. U ovom slucaju def fajl bi izgledao ovako:

Code:
LIBRARY    dlltest2
EXPORTS
  teststdcall = _teststdcall@4
  testcdecl


Posle kompajliranja eksporti izgledaju ovako:
Ordinal Name
2 teststdcall
1 testcdecl

Borlandov kompajler radi stvari na standardan nacin i nisu potrebne nikakve posebne egzibicije (osim u slucaju kada treba da se koristi neki dll kompajliran sa msvc).

Kod iz prethodnog primera kompajliran u Turbo C++ ce eksportovati funkcije ovako:
Ordinal Name
1 _testcdecl
2 teststdcall

Tako da na kraju mozemo da zakljuciti da je glavna razlika u nacinu na koji razliciti kompajleri generisu imena pod kojima se eksportuju funkcije.
[ itf @ 19.09.2006. 07:59 ] @
Sa ovolikim obrazloženjem moram da se složim :) Naravno, ja sam svoj zaključak donio isključivo na osnovu toga što sam primjetio na koji način oba compilera spremaju funkcije u dll i da se te razlike među imenima (underscore...) baš eliminiraju odabirom konvencije. Naravno, postoje opcije i u compileru, no to je manje bitno.