February 2009 - Wine-Devel - list.winehq.org

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Dan Kegel

On Tue, Feb 17, 2009 at 7:10 AM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: > On Tue, Feb 17, 2009 at 8:56 AM, Dan Kegel <dank(a)kegel.com> wrote: >> They really are very simple wrappers around Unix system >> calls. There's no reason you can't write your own wrappers >> in assembly inside your winegate, they would probably >> only be ten lines or so each. > > According to the man page, dlopen() is a library call, not a system > call. And a real .dll can't link to a native library, which is the > problem we're trying to solve. *blush* OK, so maybe we're back to the question: should wine be exporting wine_dlopen etc. via a PE DLL?

Feb. 17, 2009

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > On Tue, Feb 17, 2009 at 6:47 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> No. Find a better way. >> >> For instance, investigate the possibility of checking version >> resources. > > Which version resources are you thinking of? The version of the native dll, compared to the builtin. I could imagine a heuristic where if the major version of native is higher than builtin you default to native or something like that. I'm sure there are other possibilities too. -- Alexandre Julliard julliard(a)winehq.org

Feb. 17, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Vincent Povirk

On Tue, Feb 17, 2009 at 8:56 AM, Dan Kegel <dank(a)kegel.com> wrote: > They really are very simple wrappers around Unix system > calls. There's no reason you can't write your own wrappers > in assembly inside your winegate, they would probably > only be ten lines or so each. According to the man page, dlopen() is a library call, not a system call. And a real .dll can't link to a native library, which is the problem we're trying to solve.

Feb. 17, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Martin Hinner

On Tue, Feb 17, 2009 at 3:56 PM, Dan Kegel <dank(a)kegel.com> wrote: >> The above doesn't work ... LoadLibraryA fails (returns NULL). > > Aha, you're right. libwine is shipped as an .so, not as a .dll.so. > > But have a look at wine_dlopen and wine_dlsym, > http://source.winehq.org/source/libs/wine/loader.c#L677 > http://source.winehq.org/source/libs/wine/loader.c#L742 > They really are very simple wrappers around Unix system > calls. There's no reason you can't write your own wrappers > in assembly inside your winegate, they would probably > only be ten lines or so each. > That would let you compile it as a real .dll instead of a winelib dll. > It's possible this would be less of a maintenance > hassle than shipping winegate as a winelib dll. How do I get address of wine_dlopen/dlsym for the "assembly" part .DLL ? If I import it, how does PE loader know where to import from? I don't think this is possible ... except searching through memory, some Linux-only syscalls, etc. The solution I have created is the cleanest possible way I think. If you decide to provide some GetProcAddress method to obtain any function location (or load library), let me know, we'll remove WINEGATE.DLL and change it to your way. Otherwise I think it's waste of time as you are not accepting that Win32 application should be able to load native Linux lib. Martin

Feb. 17, 2009

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by Dan Kegel

On Tue, Feb 17, 2009 at 6:47 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > No. Find a better way. > > For instance, investigate the possibility of checking version > resources. Which version resources are you thinking of?

Feb. 17, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Dan Kegel

On Tue, Feb 17, 2009 at 6:42 AM, Martin Hinner <martin(a)hinner.info> wrote: >> hdll = LoadLibraryA("libwine.dll"); >> wine_dlopen = GetProcAdress(hdll, "wine_dlopen"); >> wine_dlsym = GetProcAdress(hdll, "wine_dlsym"); >> wine_dlclose = GetProcAdress(hdll, "wine_dlclose"); > > The above doesn't work ... LoadLibraryA fails (returns NULL). Aha, you're right. libwine is shipped as an .so, not as a .dll.so. But have a look at wine_dlopen and wine_dlsym, http://source.winehq.org/source/libs/wine/loader.c#L677 http://source.winehq.org/source/libs/wine/loader.c#L742 They really are very simple wrappers around Unix system calls. There's no reason you can't write your own wrappers in assembly inside your winegate, they would probably only be ten lines or so each. That would let you compile it as a real .dll instead of a winelib dll. It's possible this would be less of a maintenance hassle than shipping winegate as a winelib dll. - Dan

Feb. 17, 2009

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > OK, but that leaves Office 2007 broken for the average user, > which can't be good. A whitelist of apps for which specific > private DLLs are needed would solve this particular case. > That's a hack, and against winehq policy, but > because of the overwhelming popularity of the app, > it's probably worth it for us to hold our noses and do that. No? No. Find a better way. For instance, investigate the possibility of checking version resources. -- Alexandre Julliard julliard(a)winehq.org

Feb. 17, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Martin Hinner

On Tue, Feb 17, 2009 at 3:34 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Tue, Feb 17, 2009 at 4:35 AM, Martin Hinner <martin(a)hinner.info> wrote: >> Just to add few comments at once, the problem is solved for us >> (libwinegate.dll.so is shipped with the software, we'll have to >> recompile it when libwine/libc changes...), > > Wait, what can winegate do that > > hdll = LoadLibraryA("libwine.dll"); > wine_dlopen = GetProcAdress(hdll, "wine_dlopen"); > wine_dlsym = GetProcAdress(hdll, "wine_dlsym"); > wine_dlclose = GetProcAdress(hdll, "wine_dlclose"); > > can't do? You really shouldn't need to ship winelib dlls. > Can't you compile winegate as a real windows DLL that > just knows about these special wine functions? The above doesn't work ... LoadLibraryA fails (returns NULL). Tested both on fresh install from a package + latest source code build. M.

Feb. 17, 2009

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by James Mckenzie

Austin English <austinenglish(a)gmail.com> wrote: >Sent: Feb 17, 2009 7:27 AM >To: Alexandre Julliard <julliard(a)winehq.org> >Cc: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org>, Dan Kegel <dank(a)kegel.com> >Subject: Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one? > >On Tue, Feb 17, 2009 at 6:07 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Dan Kegel <dank(a)kegel.com> writes: >> >>> See http://bugs.winehq.org/show_bug.cgi?id=14980 >>> >>> Essentially, to run Office 2007, you have to set an override >>> for riched20. Since Office installs a new, spiffier version >>> of riched20 in its own private directory, and expects to >>> find it there, isn't it a bug that we don't let it have it? >> >> There's no guarantee that using the private version would help. In some >> cases it does, in other cases it makes things worse. So defaulting to >> builtin is preferable, this way at least when it doesn't work we have a >> chance of fixing it. >> > >What happened to 'bug for bug compatibility'? > Austin: These are considered private dlls as they extend functions that do not exist in the original system dll. When they are incorporated into the standard system dlls, then the new functions, and bugs, should be incorporated into the Wine versions. I think this is what AJ and Dan K are saying. James McKenzie

Feb. 17, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Dan Kegel

On Tue, Feb 17, 2009 at 4:35 AM, Martin Hinner <martin(a)hinner.info> wrote: > Just to add few comments at once, the problem is solved for us > (libwinegate.dll.so is shipped with the software, we'll have to > recompile it when libwine/libc changes...), Wait, what can winegate do that hdll = LoadLibraryA("libwine.dll"); wine_dlopen = GetProcAdress(hdll, "wine_dlopen"); wine_dlsym = GetProcAdress(hdll, "wine_dlsym"); wine_dlclose = GetProcAdress(hdll, "wine_dlclose"); can't do? You really shouldn't need to ship winelib dlls. Can't you compile winegate as a real windows DLL that just knows about these special wine functions? - Dan

Feb. 17, 2009