.exe en .dll directory

[Verwijderd]

hallo daar,

ik heb een klein estetisch vraagje. als ik mijn programma draai vanuit mn IDE zoekt hij de benodigde .dll's in mijn mingw/bin/ directory. als ik de .exe van mn programma draai vanuit explorer of command line wil hij graag de .dll's in de 'working directory', dus dezelfde dir als de .exe. ik vind het alleen erg lelijk om alle dll's (het zijn er nogal wat) in de root van mijn project te distribueren, ik heb ze graag in een ./lib/ directory. is er een mogelijkheid om mn .exe in die subdir de dll's te zoeken ipv in de working dir?

[BtM909]

Dit is meer een Windows vraag, aangezien je de oplossing binnen Windows moet zoeken.

Wat je het beste kan doen is je bin directory aan de Environment Variabel Path toevoegen. Als het goed is wordt er automatisch gekeken of de dll's zich in een de eigen directory bevat, of de dll in de directories in je PATH variabele of in een van je windows directories (Windows root, System en System32).

[Verwijderd]

ah ja bedankt... maar daar is dus weinig aan te doen (ik kan moeilijk bij de installatie van mijn programma het path van de gebruiker lopen aanpassen )

[Onbekend]

Je kan meestal de dll's ook mee compileren in de .exe.
Hierdoor hoef je niet te zoeken naar dll's en heb je geen problemen met versieconflicten.

[BtM909]

Verwijderd schreef op vrijdag 26 september 2008 @ 22:46:
ah ja bedankt... maar daar is dus weinig aan te doen (ik kan moeilijk bij de installatie van mijn programma het path van de gebruiker lopen aanpassen )

Oh my bad, ik dacht even dat het alleen om je eigen (test) omgeving ging... Welke IDE gebruik je precies en welke taal, want er zijn toch meerdere mogelijkheden om dll's in exe's te "injecteren"?

[Sebazzz]

Onbekend schreef op vrijdag 26 september 2008 @ 22:51:
Je kan meestal de dll's ook mee compileren in de .exe.
Hierdoor hoef je niet te zoeken naar dll's en heb je geen problemen met versieconflicten.

1. Indien je meerdere uitvoerbare bestanden hebt is dat niet zo handig. Dan gebruik je meer ruimte.
2. Soms wil je DLL functies uitvoeren via rundll.
3. Makkelijker te patchen indien er losse dll's zijn.

[cowgirl]

Het was even zoeken, maar het stond me toch bij dat dit zelfs op een examen gevraagd is...

quote: http://msdn.microsoft.com/en-us/library/823z9h8w.aspx

The following example shows how to specify application base subdirectories the runtime should search for assemblies.

HTML:

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="bin;bin2\subbin;bin3"/>
      </assemblyBinding>
   </runtime>
</configuration>

[D-Raven]

Je info is een beetje vaag. Maar indien je visual studio gebruikt (.net) Dan kun je op bij project eigenschappen een probing dir instellen.

[Robtimus]

Geen idee of het werkt, maar wat als je je DLL registreert dmv regsvr32? En natuurlijk bij de uninstall weer deregistreren.

[SKiLLa]

DLLs registreren met REGSVR32 kan alleen als het COM(-visible) dlls zijn. En die xml config-optie is alleen voor .Net assemblies zover mij bekend; een kale (non .Net) C++ app ondersteunt dat imho niet. Windows zoekt standaard altijd in de 'working dir', de %system32% dir en wat je opgeeft in de %path% variabele.

Als je DLLs zelf laadt, kun je ze plaatsen waar je wil, net zoals bij COM dlls die je middels hun GUID/Naam initieert. Het packen tot 1 .exe is vaak niet eens zo'n gekke oplossing voor kleinere, standalone projecten ...

[MSalters]

SetDllDirectory

Overigens komt je programma als het goed is in SHGetFolderPath(CSIDL_PROGRAM_FILES). Windows probeert gebruikers uit die directory te houden, dus so what dat er daar een paar DLLs bij staan? 't Is nog sneller ook.

[ Voor 56% gewijzigd door MSalters op 27-09-2008 13:37 ]

[.oisyn]

Punt is alleen dat het opgegeven pad bij SetDllDirectory() natuurlijk alleen wordt gebruikt ná die aanroep, wat voor automatisch ingeladen dlls (door te linken met de .lib) geen nut heeft tenzij je van delay loading gebruik maakt. Een andere optie is dan eventueel om je main app ook in een dll te gieten, en je exe die dll dan in laat laden middels LoadLibrary() danwel delay loading, na een call naar SetDllDirectory().

[MSalters]

Of je duwt die call in de DllMain van de eeste DLL, die je dan wel in je EXE directory plaatst

Het probleem is inderdaad dat je niet op code kunt vertrouwen om dingen te doen voordat je code runt. En de TS wil dingen die ongebruikelijk zijn - EXEs starten vanuit Explorer.

[Verwijderd]

hmja klopt, officieel zou je het horen te installeren, maar ik houd zelf meer van programma's die gewoon kopieerbaar en daarna uitvoerbaar zijn (dus die ook zonder install werken). dus ik wil mijn eigen programma (spel in dit geval) het liefst ook zo hebben.

ik gebruik trouwens mingw32, dus de gnu c++ voor windows. zijn de mogelijkheden geopperd in dit topic (waarvoor bedankt trouwens!) daarmee ook mogelijk? zoals bijvoorbeeld de dll's in de exe packen?

hoewel het dan wel een massive exe wordt; ik gebruik nogal wat libs maargoed.. dat is misschien overkomelijk..

misschien kan ik beter alle libs die ik gebruik - voornamelijk open source - opnieuw compilen als static lib. heeft dit eigenlijk nog nadelen boven dynamische libs?