LoadLibrary Problem

Win32Noob

Hi Leute,

ich habe mal wieder ein seltsames, für mich unergründliches Problem mit einer meiner DLL´s:

Und zwar lade ich zur Laufzeit *.dll in mein Prog mit LoadLibrary.
Jetzt kommt es aber bei einer (und nur bei dieser) zu einem Ladefehler.

GetLastError();

spuckt 126 aus also "The specified module could not be found." Das verwundert mich allerdings ein bissel sehr, weil der Pfad vollkommen in Ordnung ist. (backslahes, etc...)

Hat jemand Erfahrung mit diesem ErrorCode und weiss vielleicht Rat?

CMatt

weil der Pfad vollkommen in Ordnung ist.

Laut felhermeldung ist er das net
Hast mal gedebugt und überprüft oder die dll auch WIRKLICH da liegt? Sehr viele andere ursachen für den errorcode gibts nählich net.

code_pilot

Ach und da bist du dir sicher?
Ich habe grade selbes Problem - und gebe den ABSOLUTEN Pfad der DLL an.

Sonst noch ne Idee?

code_pilot

Nachtrag: Das Laden der DLL klappt. Wenn man das Programm ausserhalb von VC2005 aufruft. Wenn man es innerhalb VC2005 mit Debug startet, klappt's nicht!!! Konfigfehler? Falscher PATH???

code_pilot

Aha.

Nach über 1 Stunde rumtesten hab ich herausgefunden, das es daran liegt, das mein Programm mit UNICODE übersetzt wird. Was ist denn dann an dem Aufruf verkehrt bzw. was muss ich beachten?? UNICODE würde ich schon gerne beibehalten...

code_pilot

Undertaker

entweder
LoadLibraryA ("meine_dll.dll");
oder
LoadLibraryW (L"meine_dll.dll");
beide tun das gleiche, aber es gibt keine verwechselung mehr mit char und wchar_t

Martin Richter

Außer man macht solche einen Blödsin:

LoadLibrary((wchar_t*)"meine.dll");

code_pilot

Danke für deine Hilfe!

Hmm was muss ich denn generell beachten wenn ich Unicode-Programme schreibe? Muss ich dann anstatt char immer wchar_t benutzen? Wie ist es dann mit den Standard-String Funktionen wie strcpy(), sprintf(), strncpy() usw?

Wäre dann wohl sinnig diese Funktionen durch die wchar_t-Varianten überzudefinieren?

Gruß
code_pilot

Undertaker

code_pilot schrieb:

Hmm was muss ich denn generell beachten wenn ich Unicode-Programme schreibe?

z.b. dass du keine string-literale aus 'char' benutzt.
msvc hat so'n paar macros (TEXT, TCHAR, _T, usw.) die das ganze ein wenig portabel machen, so dass man sein progrämmchen als wide-char und normal-char version builden kann.
für die meisten string-funktionen gibt es auch eine unicode-version (z.b. strlen <---> wcslen) musst du mal in's msdn gucken.

CStoll

Am besten du nimmst, TCHAR - das wird je nach Einstellungen passend ersetzt.

(btw, zu strcpy() und Co. gibt es auch UNICODE-Versionen namens wcscpy() (für wchar_t) bzw. _tcscpy() (für TCHAR's))

Martin Richter

C-Casts meiden wie die Pest

code_pilot

Hallo zusammen!

Danke für eure Antworten.

Auch wenn das so langsam off-topic wird (es hat ja eigentlich nix mehr mit dem Problem von oben zu tun), wenn ich also mein Programm so portabel wie möglich gestalten will wäre es sinnvoll, ein paar defines àlà

#ifdef UNICODE
#define strcpy wcscpy
#define strlen wcslen
.
.
.
#endif

zu definieren? Ich habe nämlich vor, mein Prog später auch nach Unix zu portieren, unda da möchte ich mich nicht allzu abhängig von Microsoft machen.

Muss ich also nurnoch die tchar.h includen und dann kann's los gehen? Gibt es dann noch was zu beachten im Bezug auf FILE*-Dateizugriffe? Wie ist das mit fprintf(), gibt es dafür auch WideChar-Pendants?

Hmm sorry das ich so viel frage, ich habe mich mit Unicode bisher noch nie beschäftigt, würde es aber gerne nutzen.

Lg
code_pilot

CStoll

Nein, das ist nicht notwendig - nimm einfach die TCHAR-Varianten der Funktionen (_tsccpy() und Co), das ist sicherer als wenn du existierende Namen überschreibst).

(wobei - ein Unix-Compiler könnte Probleme mit Microsoft's UNICODE-Funktionen haben)