[VB] Gebruik van C++ DLL lukt niet bij 'lange' LIBRARY naam?

[Verwijderd]

Hallo,

Ik heb onder Visual Studio 2005 een C++ DLL gemaakt mbv deze beschrijving:

http://www.codeproject.com/KB/DLL/XDllPt3.aspx

Dit voorbeeld werkt prima. Echter daarna heb ik een eigen DLL gemaakt, deze heet SWT-KL16-II.DLL. Mbv de regel:

Visual Basic .NET:

Private Declare Function CreateSwtKL16II Lib "SWT-KL16-II.dll" () As Long

en

Visual Basic .NET:

 Dim objptr As Long
        objptr = CreateSwtKL16II()

Maak ik hier gebruik van...maar dan gaat het dus fout, ik krijg de melding:

Unable to load DLL "SWT-KL16-II.dll": The specified module could not be found. (Exception from HRESULT: 0x8007007E)

uiteindelijk heb ik een 2e DLL gemaakt die heet:

SWT-KL16.DLL

En als ik op de plek van SWT-KL16-II.DLL deze neerzet gaat 'ie wel verder ?!?!??!

Dus dan wordt de regel:

Visual Basic .NET:

Private Declare Function CreateSwtKL16II Lib "SWT-KL16.dll" () As Long

Het lijkt erop dat het het gedeelte "-II" niet geaccepteerd wordt !?!?!?

Overigens zijn de functies dus in beide DLL's WEL gelijk, ook de functienamen en de .DEF bestanden zijn identiek (muv de '-II' erbij in de 'LIBRARY' naam).

Ik hoop dat iemand mij hier een verklaring voor kan geven, ik heb weliswaar een workaround, maar als ik het probleem niet begrijp maar wel de oplossing bestaat de kans dat het probleem vanzelf kan terugkomen...daar hou ik niet zo van, dus hopenlijk is er iemand die meer weet.

Gr.
Alfred.

[Alpha_Mouse]

Hi Alfred,

Volgens mij moet je het niet te moeilijk zoeken. Ik ben geen ster in programmeren maar wat mij altijd verteld is, is om bestandsnamen zo eenvoudig mogelijk te maken.

SWT-KL16-II.dll telt 11 charcters
SWT-KL16.dll precies 8 (wat volgens mij het maximum is)

Uit het dos tijdperk kon je altijd maar max 8 posities gebruiken en ik denk dat je het in die richting moet zoeken.

Ik zie dat Windows zelf geen dll produceert langer dan 8 (Ik kijk naar de standaard meuk van WinXP) maar programma zoals Itunes etc hebben dat weer wel. Misschien moet je een aparte module aanroepen om langere bestandsnamen te gebruiken?

succes

[MLM]

mja, als dit het enige verschil is denk ik aan een 8.3 restrictie die aan oudere API's hangt voor dynamische methode importing uit een DLL.

Houd in, max 8 tekens voor de punt, max 3 erna.

Of je moet zelf de LoadLibraryA/W en GetProcAddress functies uit kernel32.dll halen en zelf je methodes uit je DLL vissen

[farlane]

Geef voor de grap eens het complete pad naar de dll aan. Ik weet dat VB nogal vreemd doet mbt tot dit soort dingen, helemaal als je vanuit de ontwikkelomgeving zelf draait.

[unclero]

farlane schreef op dinsdag 25 november 2008 @ 11:19:
Geef voor de grap eens het complete pad naar de dll aan. Ik weet dat VB nogal vreemd doet mbt tot dit soort dingen, helemaal als je vanuit de ontwikkelomgeving zelf draait.

Als de DLL geregistered is, moet dat eigenlijk niets uitmaken. VB6 doet aan die dllcall en niet aan LoadLibrary().

[farlane]

unclero schreef op dinsdag 25 november 2008 @ 11:38:
Als de DLL geregistered is, moet dat eigenlijk niets uitmaken. VB6 doet aan die dllcall en niet aan LoadLibrary().

Mja, je gaat er voor het gemak vanuit dat het een COM dll betreft, dat is niet het geval als ik die link bekijk.

[Verwijderd]

Ik heb zelf ook zo'n vermoeden gehad van die 8.3 filenaam lengte, maar ik kan genoeg DLL's vinden een langere naam hebben dan dit. Het is natuurlijk mogelijk dat dit de reden is, maar ik zou liever ergens lezen dat dit klopt, want ik heb een onderbuik gevoel dat er iets anders aan de hand is (nee, heb geen slechte shoarma gegeten ).

[Sebazzz]

Het zou mij niet verbazen als het een 8-tekens probleem is. Hoe oud is VB6? Windows 95 tijdperk?

[ Voor 12% gewijzigd door Sebazzz op 25-11-2008 21:38 ]

[MLM]

Waarom niet de simpele oplossing, rename de DLL Je linkt toch niet statically ofzo...

En anders heb je hier misschien iets aan, als aanvulling op mijn LoadLibrary/GetProcAddress verhaal:
http://www.ex-designz.net/apidetail.asp?api_id=617

[Verwijderd]

Hmm, ik blijf het allemaal raar vinden. In iedergeval bedankt voor de tips, ik heb besloten om voorlopig de weg van de minste weerstand te kiezen en de naam aan te passen naar: SWTKL16.dll. Ik kan dan tenminste even verder, maar blijf hopen op een goede verklaring voor mijn probleem.

Overigens mijn plan B is gebruik maken van LoadLibrary ...

[farlane]

Verwijderd schreef op dinsdag 25 november 2008 @ 21:32:
Ik heb zelf ook zo'n vermoeden gehad van die 8.3 filenaam lengte, maar ik kan genoeg DLL's vinden een langere naam hebben dan dit. Het is natuurlijk mogelijk dat dit de reden is, maar ik zou liever ergens lezen dat dit klopt, want ik heb een onderbuik gevoel dat er iets anders aan de hand is (nee, heb geen slechte shoarma gegeten ).

Hij kan je DLL niet vinden omdat deze niet in zijn zoekpad staat, het heeft niet met de ebstandsnaam zelf te maken.

- Maak je dll
- Maak je vb executable
- Zet ze in hetzelfde pad

Test je exe/dll. 10 tegen 1 dat het werkt.

[Verwijderd]

farlane schreef op dinsdag 25 november 2008 @ 23:13:
[...]


Hij kan je DLL niet vinden omdat deze niet in zijn zoekpad staat, het heeft niet met de ebstandsnaam zelf te maken.

- Maak je dll
- Maak je vb executable
- Zet ze in hetzelfde pad

Test je exe/dll. 10 tegen 1 dat het werkt.

Die weddenschap heb je verloren...vinden doet 'ie hem wel ..ik zette hem al op dezelfde plek als de executable ..

[farlane]

Verwijderd schreef op woensdag 26 november 2008 @ 11:08:
Die weddenschap heb je verloren...vinden doet 'ie hem wel ..ik zette hem al op dezelfde plek als de executable ..

Ik zou je niet kunnen zeggen wat je dan fout doet ( calling convention / name mangling zijn de fouten die het meest voorkomen ) maar ik heb een eigen dll gerenamed naar jouw "SWT-KL16-II.dll" en dat werkt prima.

Start je vb applicatie eens vanuit de dir war je exe staat vanuit een prompt, op die manier weet je zeker dat zijn currentdir hetzelfde is als de dir waar je exe + dll staat.

[edit]
Btw Afhankelijk van hoe je je project opent kan VB je dll wel of niet vinden: Open je je .vbp vanuit de verkenner dan zal je currentdir worden gezet naar de dir waar je vbp ( en dll ) staat. Open je je project vanuit file->open of recent lijst dan zal vb dat niet doen en kan dus ook de dll niet vinden.

Overigens ga ik er vanuit dat je met VB6 werkt maar dat blijkt eigenlijk helemaal niet uit je TS?

[ Voor 25% gewijzigd door farlane op 26-11-2008 16:42 ]