[vlc-devel] Enhancement Request...

jboileau jboileau at gmail.com
Fri Apr 4 17:47:25 CEST 2008 

Hi André,

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.

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.

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.

Jacques

On Fri, Apr 4, 2008 at 11:27 AM, Andre Weber <WeberAndre at gmx.de> wrote:

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



-- 
Jacques Boileau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080404/6486e286/attachment.html>

More information about the vlc-devel mailing list