--- On Wed, 27/1/10, Alexandre Julliard wrote:
> The first step would probably be to explain why you need to
> have an app
> with the same name as an existing builtin.
ddiwrapper provides its own gdi32.dll.so winspool.drv.so , so that bitmap
generated by the host's ghostscript is fed into the p
Alexandre Julliard wrote:
Michael Ost writes:
I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so
all users from any .wine directory can launch it with a script that
contains 'exec wine APP.exe'. I'm mimicking how, say, regedit works.
During development I want to run a devel
Michael Ost writes:
> I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so
> all users from any .wine directory can launch it with a script that
> contains 'exec wine APP.exe'. I'm mimicking how, say, regedit works.
>
> During development I want to run a development-local APP.exe
Alexandre Julliard wrote:
Michael Ost writes:
The first step would probably be to explain why you need to have an app
with the same name as an existing builtin.
Right, ok.
I'm not replacing a builtin. I install APP.exe.so in /usr/lib/wine so
all users from any .wine directory can launch it w
Michael Ost writes:
> Alexandre Julliard wrote:
>> Actually the current way is precisely what LD_LIBRARY_PATH does for
>> relocatable installs. The loader first looks in the rpath $ORIGIN path,
>> then in LD_LIBRARY_PATH, then in system directories. Wine does exactly
>> the same thing.
>
> I did
Alexandre Julliard wrote:
Michael Ost writes:
I agree. And that's what your patch does, right? Would you like to
submit it to the wine-patches list? I think the case for it is strong,
especially since (1) you found that it fixes a behavior change in
WINEDLLPATH from November 2006 --- arguably
--- On Tue, 26/1/10, Alexandre Julliard wrote:
> Michael Ost
> writes:
>
> > I agree. And that's what your patch does, right? Would
> you like to
> > submit it to the wine-patches list? I think the case
> for it is strong,
> > especially since (1) you found that it fixes a
> behavior change in
--- On Tue, 26/1/10, Ben Klein wrote:
> For DLLs at least, you should be able to rename the .dll.so
> to a .dll
> and stick it in the application's directory. I don't recall
> the last
> time I tried this, but it certainly worked (I was using a
> hacked
> ddraw.dll.so to get Diablo and Worms Arma
Michael Ost writes:
> I agree. And that's what your patch does, right? Would you like to
> submit it to the wine-patches list? I think the case for it is strong,
> especially since (1) you found that it fixes a behavior change in
> WINEDLLPATH from November 2006 --- arguably a regression; and (2)
Hin-Tak Leung wrote:
--- On Mon, 25/1/10, Michael Ost wrote:
Alexandre Julliard wrote:
Not necessarily, the behavior could probably be
tweaked, feel free to
suggest changes. You can't require users to set
WINEDLLPATH for normal
usage though, including running from the build tree or
fro
2010/1/26 Hin-Tak Leung :
> --- On Mon, 25/1/10, Michael Ost wrote:
>
>> Alexandre Julliard wrote:
>
>> > Not necessarily, the behavior could probably be
>> tweaked, feel free to
>> > suggest changes. You can't require users to set
>> WINEDLLPATH for normal
>> > usage though, including running fro
--- On Mon, 25/1/10, Michael Ost wrote:
> Alexandre Julliard wrote:
> > Not necessarily, the behavior could probably be
> tweaked, feel free to
> > suggest changes. You can't require users to set
> WINEDLLPATH for normal
> > usage though, including running from the build tree or
> from a relocat
2010/1/26 Michael Ost :
> Ben Klein wrote:
>> WINEDLLPATH should certainly behave more like LD_LIBRARY_PATH than
>> PATH, but wine should always follow the same DLL search pattern as
>> Windows. How would Windows handle adding a directory to the DLL search
>> path? (Is this even possible?)
>
> I'm
--- On Mon, 25/1/10, Michael Ost wrote:
> Hin-Tak Leung wrote:
> > I asked about the same problem a while ago without any
> response, but
> > I have a patch for it:
> >
> > https://www.linuxfoundation.org/en/User:Htl10#Ddiwrapper_.28a.k.a._.22Using_Vendor_win32_printer_driver_in_Linux.22.29
>
>
I asked about the same problem a while ago without any response, but I have a
patch for it:
https://www.linuxfoundation.org/en/User:Htl10#Ddiwrapper_.28a.k.a._.22Using_Vendor_win32_printer_driver_in_Linux.22.29
I reckon it is because the wine devs don't want people to override certain
things. W
Ben Klein wrote:
2010/1/26 Michael Ost :
Alexandre Julliard wrote:
I think it makes more sense to require, as Hin-Tak Leung's patch does, that
a user put /usr/lib/wine in WINEDLLPATH if they use WINEDLLPATH. This is how
LD_LIBRARY_PATH works for ld and PATH works in bash --- so it's expected
beh
2010/1/26 Michael Ost :
> Alexandre Julliard wrote:
>> Note that you can always specify the full exe path on the command line.
>
> That doesn't work without a wine drive that includes APP.exe.so --- we run
> without z:/.
This sort of configuration is impossible to support. You should have a
wine d
Alexandre Julliard wrote:
Michael Ost writes:
I think it makes more sense to require, as Hin-Tak Leung's patch does,
that a user put /usr/lib/wine in WINEDLLPATH if they use
WINEDLLPATH. This is how LD_LIBRARY_PATH works for ld and PATH works
in bash --- so it's expected behavior.
Also, from
Michael Ost writes:
> I think it makes more sense to require, as Hin-Tak Leung's patch does,
> that a user put /usr/lib/wine in WINEDLLPATH if they use
> WINEDLLPATH. This is how LD_LIBRARY_PATH works for ld and PATH works
> in bash --- so it's expected behavior.
>
> Also, from my reading of the
Alexandre Julliard wrote:
Michael Ost writes:
Is this on purpose? It doesn't seem right at first glance. I would
assume that WINEDLLPATH would take precedence. Otherwise what purpose
would it serve?
It serves as an extra path where dlls can be found, but dlls from the
current running install
Hin-Tak Leung wrote:
I asked about the same problem a while ago without any response, but
I have a patch for it:
https://www.linuxfoundation.org/en/User:Htl10#Ddiwrapper_.28a.k.a._.22Using_Vendor_win32_printer_driver_in_Linux.22.29
I can see how that patch would work. Though I can also see why
Michael Ost writes:
> Is this on purpose? It doesn't seem right at first glance. I would
> assume that WINEDLLPATH would take precedence. Otherwise what purpose
> would it serve?
It serves as an extra path where dlls can be found, but dlls from the
current running installation are used first. Th
Hi,
I am wanting to direct wine to launch a specific APP.exe.so program by
using WINEDLLPATH during the development of APP.exe.
Unfortunately (and undocumented-ely if you know what I mean) WINEDLLPATH
is superseded by /usr/lib/wine. So if /usr/lib/wine/APP.exe.so exists,
WINEDLLPATH will fin
23 matches
Mail list logo
