<div>Hi André,</div>
<div> </div>
<div>You are right, you can use GetModuleFilename from inside a staticaly linked DLL as well. But if libvlc-control wants to load libvlc using this scheme it also needs to delay load libvlc. Otherwise the error that libvlc-control can't find libvlc will happen *before* it evens has time to get the path. The problem that we are looking at here is the fact that loading libvlc-control when the vlc directory is not in the path fails because libvlc is not found. </div>

<div> </div>
<div>In my case I have simply solved this problem by loading manually both DLLs using the VLC install path in the registry. Since Windows will look in memory for DLLs before searching the disk, they are easily found. It is easy for me to do this since I haven't found a way to use the ,lib from the VLC build with Visual Studio and thus don't statically link to libvlc-control. </div>

<div> </div>
<div>I actually have no real problem with this loading error. I am just trying to help others with any knowledge of Windows I can provide. Since there aren`t many (if any) Windows developer on the VLC team, it is great if I can help in this small way. Hopefuly my experience may be benificial to others.</div>

<div> </div>
<div>Jacques<br><br></div>
<div class="gmail_quote">On Fri, Apr 4, 2008 at 11:27 AM, Andre Weber <<a href="mailto:WeberAndre@gmx.de">WeberAndre@gmx.de</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hallo Jacques,<br>
<div class="Ih2E3d"><br>>this solution only works if the library is not linked with the<br>>application and entry points are found using GetProcAddress. Not the<br>>case with libvlc-control and libvlc.<br><br></div>
I think this method to find the path from where the dll was loaded<br>works also if the dll was static linked to the application - in the documentation<br>to this function is no limitation written - that this works only for DLL<br>
which are loaded with LoadLibrary.  (there is only a note - that the DLL<br>must be loaded before - but not which way - that makes me assume that<br>it must work ...)<br><br>an other reason why it must work is:<br><br>It must also be possible to retrieve modulehandle (GetModuleHandle) by<br>
this way - because a lot of other Windows API's require the module handle<br>f.e. to load resources  - so it should not make a difference how / when the<br>DLL was mapped/loaded into the process?<br>(the only difference so far I know that with static linking means only that<br>
 the processloader from Windows will load the DLL into the process<br>memory - when the application or the other DLL is loaded... ?)<br><br>--- the only problem which still exists is -- that libvlc-control.dll is static linked<br>
to libvlc.dll ... to resolve this in your application try to change the load order<br>I'am not sure if this works...<br><br>1. LoadLibrary("<path to vlc>\libvlc.dll");<br>2. LoadLibrary("<path to vlc>\libvlc-control.dll")<br>
<br>usually windows will look if a required DLL is allready loaded into the<br>process space... may be that works also for static linked libraries?<br>(that they aren't loaded twice)<br><br>if not you must use the kludge to modify the searchpaths for you application,<br>
or change temporarily the working directory of you app to the folder<br>where the DLL's of VLC are located -- I think that will also work - and<br>you can revert this - immediately after loading the VLC dlls...?<br><br>
(I'am speak only from my point as windows people - and not from the<br> view of a java developer... were other problems may be there...)<br><br><br>with best regards...<br><br>André<br><font color="#888888">--<br>atmo<br>
</font>
<div class="Ih2E3d"><br><br>----- Original Message -----<br>From: jboileau<br>To: Mailing list for VLC media player developers<br></div>
<div>
<div></div>
<div class="Wj3C7c">Sent: Friday, April 04, 2008 5:03 PM<br>Subject: Re: [vlc-devel] Enhancement Request...<br><br><br>Hum I should be carefull when I respond. The response below was to André.<br><br><br>On Fri, Apr 4, 2008 at 10:24 AM, jboileau <<a href="mailto:jboileau@gmail.com">jboileau@gmail.com</a>> wrote:<br>
<br>Hi,<br><br>This solution only works if the library is not linked with the<br>application and entry points are found using GetProcAddress. Not the<br>case with libvlc-control and libvlc.<br><br>Jacques<br><br><br>On Fri, Apr 4, 2008 at 9:57 AM, André Weber <<a href="mailto:WeberAndre@gmx.de">WeberAndre@gmx.de</a>> wrote:<br>
> Hello,<br>><br>> just my 2cents ...<br>><br>> on windows it would be not very difficult for the DLL to find out from where<br>> it was loaded - so that the DLL knows where it is located ... and there is<br>
> no<br>> need to change search pathes or such things.<br>><br>> Only the application which tries to load the vlc-dll's must know where these<br>> files are located - f.e. by reading the registry to find the installation<br>
> folder - there<br>> is no other options - without adding new options to the external programs.<br>><br>> But the VLC DLL's itself - can find out for themself where they are located<br>> with the code below - and use that information to load the plugins and co.<br>
> from the right folders relative to the VLC DLL's ...<br>><br>><br>> char psz_filename[MAXPATH];<br>> HMODULE h_vlccontrol = GetModuleHandle("libvlc-control.dll");<br>> if( h_vlccontrol )<br>
> {<br>>    if( GetModuleFileName( h_vlccontrol , psz_filename,<br>> sizeof(psz_filename) ) )<br>>   {<br>>     /*<br>>         psz_filename = should now contain the complete filename of<br>> "libvlc-control.dll"<br>
>         put this code inside "libvlc-control.dll" - to derive from there<br>> the other pathes to<br>>         the plugins and co.<br>>     */<br>>   }<br>> }<br>><br>><br>><br>> André<br>
> --<br>> Atmo<br>><br>><br>><br>> ----- Original Message -----<br>> From: "Remi Denis-Courmont" <<a href="mailto:rdenis@simphalempin.com">rdenis@simphalempin.com</a>><br>> To: "Mailing list for VLC media player developers" <<a href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a>><br>
> Sent: Friday, April 04, 2008 3:22 PM<br>> Subject: Re: [vlc-devel] Enhancement Request...<br>><br>><br>> > hmm, that does not work, I think. LibVLC!could learn its install path and<br>> > infer the locations of plugins (and even shared data files) from it.<br>
> > Because it calls dlopen or the non-portable equivalent for these. I did<br>> > file an enhancement ticket for this a while ago.<br>> ><br>> > However, it is NOT possible for LibVLC-control to learn the location of<br>
> > LibVLC. The earlier is linked to the latter at build link-time, not<br>> > run-time. It is hence the OS loader that needs to know the path, not<br>> > LibVLC-control.<br>> ><br>> > Remi Denis<br>
> ><br>> > -- message original --<br>> > Sujet: Re: [vlc-devel] Enhancement Request...<br>> > De: jboileau <<a href="mailto:jboileau@gmail.com">jboileau@gmail.com</a>><br>> > Date: 04.04.2008 13:03<br>
> ><br>> > Well we don't really package anything. The application I work on is<br>> > embedded and I create compact flash images to hold everything. So its<br>> > not a really big problem for me and its transparent to the end user. I<br>
> > offer my experience mostly to help if it can. I see all the hard work<br>> > you guys put in, its the least I can when I read emails I can comment<br>> > on to do so.<br>> ><br>> > But the only way to package everything up to not have the path problem<br>
> > would be to put VLC in the same directory as our application. Which I<br>> > would rather not. It is nice to have VLC in its own directory and our<br>> > stuff in another. Easier to update one without the other. And easier<br>
> > in the development stage. Visual Studio creates directories for<br>> > release and debug builds. I would have to add post-build steps to copy<br>> > the VLC files to the target dir when I run the app from the IDE. Do I<br>
> > want this copy to happen every time I build? No way!<br>> ><br>> > It ain't a big deal to do a set current dir to the VLC install dir so<br>> > that the VLC DLLs can find each other. I could also add the VLC dir to<br>
> > the environment path. But it would also be easy to have<br>> > libvlc-control.dll know its dir and use it to find libvlc.dll. This<br>> > problem is very minor and easily circumventable in my environment. I<br>
> > am sure there are more important issues.<br>> ><br>> > Jacques Boileau<br>> ><br>> > On Thu, Apr 3, 2008 at 9:05 PM, Pierre d'Herbemont <<a href="mailto:pdherbemont@free.fr">pdherbemont@free.fr</a>><br>
> > wrote:<br>> >><br>> >> On Apr 3, 2008, at 8:48 PM, jboileau wrote:<br>> >> > Hi,<br>> >> ><br>> >> > I can probably help since I develop on Windows. It is true that there<br>
> >> > is problem loading libvlc-control.dll on Windows. Personaly for the<br>> >> > moment I am reading the VLC install path from the registry, do a set<br>> >> > current dir to there, load libvlc and finally load libvlc-control (see<br>
> >> > code below). This is the only way I have found to make it work without<br>> >> > problems.<br>> >><br>> >> Why don't you package libvlc and plugin with your own app?<br>
> >><br>> >><br>> >> Pierre.<br>> >> _______________________________________________<br>> >> vlc-devel mailing list<br>> >> To unsubscribe or modify your subscription options:<br>
> >> <a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br>> >><br>> ><br>> ><br>> ><br>> > --<br>> > Jacques Boileau<br>
> > _______________________________________________<br>> > vlc-devel mailing list<br>> > To unsubscribe or modify your subscription options:<br>> > <a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br>
> ><br>> > _______________________________________________<br>> > vlc-devel mailing list<br>> > To unsubscribe or modify your subscription options:<br>> > <a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br>
><br>> _______________________________________________<br>> vlc-devel mailing list<br>> To unsubscribe or modify your subscription options:<br>> <a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br>
><br><br><br><br><br>--<br>Jacques Boileau<br><br><br><br><br>--<br>Jacques Boileau<br><br><br><br>_______________________________________________<br>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br>
<a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br><br>_______________________________________________<br>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br>
<a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br></div></div></blockquote></div><br><br clear="all"><br>-- <br>Jacques Boileau