[Win32/C++] OpenURL via DLL

[Verwijderd]

Ik heb met Visual C++ een DLL gemaakt welke als parameter een url krijgt en de broncode van de ingelezen url teruggeeft. Nou werkt dit goed, tenzij de url niet bestaat.

Er wordt een CInternetSession instantie aangemaakt, welke eerst via SetOption de cache uitschakelt en daarna OpenURL (member van CInternetSession) aanroept:

code:

...

isSession.SetOption(INTERNET_OPTION_URL, 1, INTERNET_FLAG_DONT_CACHE);
if (!(fpUrlFile = isSession.OpenURL(URL))) {
    *size=-1;
    return retval;
}

...

Als ik deze DLL via LabWindows (van National Instruments aanroep) met een foute url, dan loopt de DLL tot aan OpenURL en krijg ik de foutmelding:

The program has caused a "Unknown" fault at 001B:77E4D756

De foutafhandeling na de OpenURL wordt niet uitgevoerd. Weet iemand waarom de fout al terug wordt gegeven voordat de foutafhandeling uit wordt gevoerd en hoe ik dit kan verhelpen?

[Olaf van der Spek]

Je moet de exception die wordt gegooid opvangen. Zie de docs als je wilt weten welke exceptie dat is.

[Verwijderd]

Dank je het is CInternetException. Het werkt nu wel!

code:

try { fpUrlFile = isSession.OpenURL(URL); }
catch (CInternetException *error) {
  *size=-1;
  return retval;
}

[ Voor 57% gewijzigd door Verwijderd op 09-06-2003 12:34 . Reden: code toegevoegd ]

[Olaf van der Spek]

Moet error niet gedelete worden?

C++:

error->Delete();

[ Voor 10% gewijzigd door Olaf van der Spek op 09-06-2003 13:30 ]

[Verwijderd]

Bij een voorbeeld op MSDN gebeurde dat niet en volgens mij wordt alles automatisch gedelete als de aanroep naar de functie in de DLL klaar is.

[Verwijderd]

Never let an exception escape your DLL!!!

Al je functies en procedures in een exception handler zetten.

[MSalters]

Verwijderd schreef op 09 June 2003 @ 18:31:
Never let an exception escape your DLL!

Waarom? Is bij mij nooit een probleem geweest.
Ook in DLLs kunnen foutsituaties ondekt worden, en exceptions zijn dan net zo goed op hun plaatn. Misschien zelfs beter, want een DLL is een logische grens waar je een duidelijke interface wil aanbieden.

[Verwijderd]

MSalters schreef op 09 juni 2003 @ 23:46:
[...]

Waarom? Is bij mij nooit een probleem geweest.
Ook in DLLs kunnen foutsituaties ondekt worden, en exceptions zijn dan net zo goed op hun plaatn. Misschien zelfs beter, want een DLL is een logische grens waar je een duidelijke interface wil aanbieden.

Een DLL is normaal gesproken een afgebakend gebied, waarbij ik alleen via de input en output parameters van een DLL-functie zou communiceren. De exception handler van de DLL kan anders werken dan de exception handler van de host.

Zolang de Exception en de afhandeling binnen de DLL zelf blijft is er niets aan de hand.

voorbeeld:

integer dllfunctie(integer foo1, integer foo2);
{post:
return waarde > 0 als alles goed gegaan is.
return waarde <= 0 als er een fout is opgetreden
}

[curry684]

sinaasappelsap: redelijk onzinning imho. Als een DLL een fout geeft, waarom zou je je dan beperken tot C-style integer resultaten terwijl je ook een exception object met tonnen meer aan informatie naar buiten kan mikken?

[Soultaker]

Misschien zeg ik domme dingen, want ik heb nooit precies begrepen hoe exception-mechanismen op implementatienivo werken, maar ik dacht altijd dat de compiler zelf bepaalt hoe exception handling precies werkt. Vergelijk het bijvoorbeeld met C++ name mangling en het gebruik van verschillende member alignments voor objecten: gebruik maken van een DLL die anders gecompileerd is dan de gebruikende applicatie, is dan fataal.

Als er dus geen (per-platform) standaard voor het afhandelen van exceptions is, kan ik me de kritiek van sinaasappelsap heel goed voorstellen, als je een DLL schrijft en je de gebruikende applicatie niet wilt beperken tot een bepaalde compiler(instelling).

[curry684]

Sja tis er natuurlijk wel vn afhankelijk of je een private of redistributable DLL schrijft.

[MSalters]

Exceptions vanuit een DLL betekent dat de DLL in C++ geschreven is. In dat geval moet je sowieso vanwege name mangling en object layout dezelfde compiler gebruiken voor de DLL en de EXE, exceptions voegen daar niets aan toe. Op het Win32 platform is er wel een uniforme ABI voor C, (alleen) daarom kan een C DLL gebruikt worden door alle C compilers.

De Itanium heeft wel een compiler-independent C++ ABI voor UNIX/Linux, dus daar kun je wel .so's mixen van Intel en GCC

[ Voor 15% gewijzigd door MSalters op 20-08-2003 17:08 ]

[Olaf van der Spek]

MSalters schreef op 20 August 2003 @ 17:06:
Exceptions vanuit een DLL betekent dat de DLL in C++ geschreven is. In dat geval moet je sowieso vanwege name mangling en object layout dezelfde compiler gebruiken voor de DLL en de EXE, exceptions voegen daar niets aan toe. Op het Win32 platform is er wel een uniforme ABI voor C, (alleen) daarom kan een C DLL gebruikt worden door alle C compilers.

De Itanium heeft wel een compiler-independent C++ ABI voor UNIX/Linux, dus daar kun je wel .so's mixen van Intel en GCC

Dat de DLL in C++ geschreven is betekent toch niet dat de interface functies gebruik maken van name mangling?
Ook betekent het niet dat er objects in de interface gebruikt worden.

[.oisyn]

OlafvdSpek schreef op 20 August 2003 @ 17:47:
[...]

Dat de DLL in C++ geschreven is betekent toch niet dat de interface functies gebruik maken van name mangling?
Ook betekent het niet dat er objects in de interface gebruikt worden.

Globale functies worden gemangled. Als je met classes/structs werkt is eenzelfde compiler sowieso aan te raden, omdat je niet de layout van een class kunt bepalen met code. Vaak is dat wel hetzelfde hoor, en volgen de members elkaar op de manier waarom je ze declareert, maar een compiler kan ervoor kiezen om dat om te gooien

Maar dan zit je nog met vtable implementatie, typeid implementatie, etc.

C wordt niet voor niets zo vaak als interface-taal gebruikt, dat is zo'n beetje overal wel mee te gebruiken

[Olaf van der Spek]

.oisyn schreef op 21 August 2003 @ 04:04:
Globale functies worden gemangled.

Maar dat is met extern "C" toch te voorkomen?

Als je met classes/structs werkt is eenzelfde compiler sowieso aan te raden, omdat je niet de layout van een class kunt bepalen met code. Vaak is dat wel hetzelfde hoor, en volgen de members elkaar op de manier waarom je ze declareert, maar een compiler kan ervoor kiezen om dat om te gooien

Maar dan zit je nog met vtable implementatie, typeid implementatie, etc.

Maar als je in de interface geen objects gebruikt is dat toch allemaal irrelevant?

[Verwijderd]

Verwijderd schreef op 09 June 2003 @ 10:45:
Als ik deze DLL via LabWindows (van National Instruments aanroep) met een foute url, dan loopt de DLL tot aan OpenURL en krijg ik de foutmelding:

The program has caused a "Unknown" fault at 001B:77E4D756

De foutafhandeling na de OpenURL wordt niet uitgevoerd. Weet iemand waarom de fout al terug wordt gegeven voordat de foutafhandeling uit wordt gevoerd en hoe ik dit kan verhelpen?

In het geval van de topic starter gaat het blijkbaar om een soort plugin dll. De topicstarter heeft gekozen voor C, maar had deze net zo goed in Delphi ofzo kunnen maken. Als ik een plugin maak voor bijvoorbeeld Winamp wil ik ook niet dat Winamp crasht door een fout van mij. Of als ik een driver (is eigenlijk een apart verhaal, maar het gaat om het idee) maak voor Windows en er zit een foutje in, dan mag de driver best wel crashen, maar moet Windows gewoon doordraaien. In dit soort gevallen zijn pre- en post-condities heel belangrijk.
Daarom de statement: "Never let an exception escape your DLL".

Het is een ander verhaal als de dll altijd één geheel is met de host applicatie. In dat geval kun je gewoon lekker doen wat je zelf wilt.

[curry684]

Maar dat is met extern "C" toch te voorkomen?

Ja, en daarom exposen de meeste DLL's, al zijn ze voor 100% C++, alleen een C-interface Classmethods kun je op zich ook exporten maar die moeten verplicht manglen wegens overloading, en dat is dus uitnodigen tot problemen.

Tevens kun je een C-interface wel vanuit iedere taal benaderen, en C++ alleen vanuit C++ dezelfde compiler dus.