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
are there any examples for Editor settings (e.g. emacs c-mode) resulting in
acceptable indentation?
http://wiki.winehq.org/HackingTips
has some useful bits for vim. Maybe they give you an idea for emacs (so
you could set up a similar page in the wiki ;))
Regards,
Wolfram
On Tue, Jan 26, 2010 at 4:32 AM, Uwe Bonnes
wrote:
> Hello,
>
> are there any examples for Editor settings (e.g. emacs c-mode) resulting in
> acceptable indentation?
>
Hello Uwe
In emacs c-mode, I find M-x c-toggle-electric-state is the best way to
not interfere with the surrounding indentation.
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
On 1/25/2010 20:09, Alexandre Julliard wrote:
Nikolay Sivov writes:
This applies over previous 2 patches series.
Add test for XML declaration parsing
It doesn't work:
../../../tools/runtest -q -P wine -M xmllite.dll -T ../../.. -p xmllite_test.exe.so
reader.c&& touch reader.ok
r
Hello,
are there any examples for Editor settings (e.g. emacs c-mode) resulting in
acceptable indentation?
Thanks
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06
Nikolay Sivov writes:
> This applies over previous 2 patches series.
>
> Add test for XML declaration parsing
It doesn't work:
../../../tools/runtest -q -P wine -M xmllite.dll -T ../../.. -p
xmllite_test.exe.so reader.c && touch reader.ok
reader.c:546: Test failed: Expected (0,0), got (0,17513
On Sun, Jan 24, 2010 at 6:13 PM, Stefano Guidoni wrote:
> One of the examples in the API doc of MPG123 states: "we are not in
> feeder mode, so MPG123_OK, MPG123_ERR and MPG123_NEW_FORMAT are the
> only possibilities"; however in winemp3 the function MPEG3_StreamOpen
> uses mpg123_open_feed(), so
Am Montag, den 25.01.2010, 12:49 +0100 schrieb Paul Vriens:
> > It shows only lines 3236 to 3250 being run - these are the tests that
> > are not protected by the broken is_win9x check.
> So are all these checks broken according to you or just specific ones?
The patch that started this thread cont
Am Montag, den 25.01.2010, 10:47 +0100 schrieb Paul Vriens:
> On 01/25/2010 09:37 AM, Michael Karcher wrote:
> > Am Montag, den 25.01.2010, 15:27 +0800 schrieb Dmitry Timoshkov:
> >>> The current code misdetects both Windows XP and Wine as Win9x and skips
> >>> some tests due to this. The SetParent
At first sight there's a strange behavior in SHELL_execute() (read
ShellExecuteEx() ): at tries to extract program path and arguments
from SHELLEXECUTEINFOW.lpFile, if it's unquoted.
http://source.winehq.org/source/dlls/shell32/shlexec.c?v=wine-1.1.37#L1709
On WinXP at least ShellExecuteExA() doesn
Hans Leidekker writes:
> See http://bugs.winehq.org/show_bug.cgi?id=21442
> ---
> dlls/winhttp/request.c |1 +
> dlls/winhttp/tests/winhttp.c | 16 +---
> 2 files changed, 14 insertions(+), 3 deletions(-)
It doesn't work:
../../../tools/runtest -q -P wine -M winhttp.dll
On 1/25/2010 15:13, Alexandre Julliard wrote:
Michael Stefaniuc writes:
Paul Vriens wrote:
On 01/24/2010 09:23 PM, гор Хакер wrote:
ukrainian-credui
I'm not sure if our automated patch watcher
(http://source.winehq.org/patches/) can cope with non-ascii characte
Michael Stefaniuc writes:
> Paul Vriens wrote:
>> On 01/24/2010 09:23 PM, гор Хакер wrote:
>>> ukrainian-credui
>>>
>> I'm not sure if our automated patch watcher
>> (http://source.winehq.org/patches/) can cope with non-ascii characters
>> in the "From:" field but your patches don't show up over
Eric Pouech writes:
> diff --git a/include/commctrl.h b/include/commctrl.h
> index 27bd745..c841d51 100644
> --- a/include/commctrl.h
> +++ b/include/commctrl.h
> @@ -2245,7 +2245,9 @@ static const WCHAR WC_PAGESCROLLERW[] = {
> 'S','y','s','P','a','g','e','r',0 };
> #define PGN_SCROLL
On 01/25/2010 11:30 AM, Michael Karcher wrote:
Am Montag, den 25.01.2010, 10:47 +0100 schrieb Paul Vriens:
On 01/25/2010 09:37 AM, Michael Karcher wrote:
Am Montag, den 25.01.2010, 15:27 +0800 schrieb Dmitry Timoshkov:
The current code misdetects both Windows XP and Wine as Win9x and skips
som
On 25 January 2010 10:38, Stefan Dösinger wrote:
> I think these if constructs in shader_glsl_get_sample_function are becoming
> ugly with more and more possibilities added. Isn't there a nicer way, like a
> table that is either searched, or a multi-dimensional array to look up the
> end result
On 01/25/2010 12:21 PM, Vladimir Pankratov wrote:
Hello all.
Fix use of uninitialized variable in dlls/advapi32/tests/eventlog.c
changed files:
dlls/advapi32/tests/eventlog.c
Thanks.
This is the same patch as you've sent a month ago.
This doesn't happen on a clean .wine as there we would n
On 01/25/2010 11:21 AM, Michael Stefaniuc wrote:
Paul Vriens wrote:
On 01/24/2010 09:23 PM, гор Хакер wrote:
ukrainian-credui
I'm not sure if our automated patch watcher
(http://source.winehq.org/patches/) can cope with non-ascii characters
in the "From:" field but your patches don't show up
Paul Vriens wrote:
> On 01/24/2010 09:23 PM, гор Хакер wrote:
>> ukrainian-credui
>>
> I'm not sure if our automated patch watcher
> (http://source.winehq.org/patches/) can cope with non-ascii characters
> in the "From:" field but your patches don't show up over there.
I would consider that a bug
On 01/24/2010 09:23 PM, гор Хакер wrote:
ukrainian-credui
Hi,
If you send a second (or higher) revision of a patch please mark it as
such. For example "(Try x)" at the end. This makes it easier to discard
older ones. This one supersedes the one that didn't have the pragma for
example.
A
On 01/25/2010 09:37 AM, Michael Karcher wrote:
Am Montag, den 25.01.2010, 15:27 +0800 schrieb Dmitry Timoshkov:
The current code misdetects both Windows XP and Wine as Win9x and skips
some tests due to this. The SetParent tests were not passing on XP, so
this patch also removes the tests that fa
Am 24.01.2010 um 21:16 schrieb Henri Verbeet:
> if(texrect) {
> if(lod) {
> sample_function->name = projected ?
> "texture2DRectProjLod" : "texture2DRectLod";
> -} else if(grad) {
> -sample_function->name = proje
Michael Karcher wrote:
> > And according to
> > http://test.winehq.org/data/e2af560aa3c23a672d8680f91f3e1b8793d5827f/index_XP.html#user32:win
> > SetParent tests pass under XP just fine.
>
> No, they don't pass on Windows XP. But they also don't fail on Windows
> XP, because they are not run at
Am Montag, den 25.01.2010, 15:27 +0800 schrieb Dmitry Timoshkov:
> > The current code misdetects both Windows XP and Wine as Win9x and skips
> > some tests due to this. The SetParent tests were not passing on XP, so
> > this patch also removes the tests that fail on XP SP3.
>
> These should be 2 s
34 matches
Mail list logo
