[vlc-devel] Enhancement Request...

Andre Weber WeberAndre at gmx.de
Fri Apr 4 17:27:03 CEST 2008 

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

More information about the vlc-devel mailing list