Nabble - Wine - Devel

Re: winhttp/tests: Fix test error when run as non-administrator

2009-12-08T09:09:41Z

Hi Paul,

> I agree that ERROR_ACCESS_DENIED is a valid return value but I'd rather have
> some win_skip() or at least a skip() in there. win_skip() will work fine
> right now but as soon as we implement access rights to the registry (and
> multi-user) it should probably be a skip().

That's good feedback, I'll revise the patch.
--Juan

Re: The XFORM matrix in PlgBlt is calculated incorrectly

2009-12-08T09:08:37Z

Alexander Almaleh wrote:

> I'm talking about this code,
> from http://source.winehq.org/source/dlls/gdi32/bitblt.c, in function
> PlgBlt :
>
>
> I have a formula that so far seems to give always the correct matrix:
>
>
> xf.eM11 = (FLOAT)
> -(rect[1].y*plg[2].x+rect[0].y*(plg[1].x-plg[2].x)-rect[2].y*plg[1].x+plg[0].x*(rect[2].y-rect[1].y))
> /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x);
>

Hi, Alexander. This was my patch.

Feel free to correct this sending patch for review to
wine-patches@...

P.S. I don't see your point on inlining determinant expression.
>
> I found out about the bug by converting the rect points using the
> XFORM matrix, and checking that their the same as the plg points.

The XFORM matrix in PlgBlt is calculated incorrectly

2009-12-08T08:45:18Z

I'm talking about this code, from http://source.winehq.org/source/dlls/gdi32/bitblt.c, in function PlgBlt :

577     rect[0].x = nXSrc;
578     rect[0].y = nYSrc;
579     rect[1].x = nXSrc + nWidth;
580     rect[1].y = nYSrc;
581     rect[2].x = nXSrc;
582     rect[2].y = nYSrc + nHeight;
583     /* calc XFORM matrix to transform hdcDest -> hdcSrc (parallelogram to rectangle) */
584     /* determinant */
585     det = rect[1].x*(rect[2].y - rect[0].y) - rect[2].x*(rect[1].y - rect[0].y) - rect[0].x*(rect[2].y - rect[1].y);
586 
587     if (fabs(det) < 1e-5)
588     {
589         SetGraphicsMode(hdcDest,oldgMode);
590         return FALSE;
591     }
592 
593     TRACE("hdcSrc=%p %d,%d,%dx%d -> hdcDest=%p %d,%d,%d,%d,%d,%d\n",
594         hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hdcDest, plg[0].x, plg[0].y, plg[1].x, plg[1].y, plg[2].x, plg[2].y);
595 
596     /* X components */
597     xf.eM11 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y - rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det;
598     xf.eM21 = (rect[1].x*(plg[2].x - plg[0].x) - rect[2].x*(plg[1].x - plg[0].x) - rect[0].x*(plg[2].x - plg[1].x)) / det;
599     xf.eDx  = (rect[0].x*(rect[1].y*plg[2].x - rect[2].y*plg[1].x) -
600                rect[1].x*(rect[0].y*plg[2].x - rect[2].y*plg[0].x) +
601                rect[2].x*(rect[0].y*plg[1].x - rect[1].y*plg[0].x)
602                ) / det;
603 
604     /* Y components */
605     xf.eM12 = (plg[1].y*(rect[2].y - rect[0].y) - plg[2].y*(rect[1].y - rect[0].y) - plg[0].y*(rect[2].y - rect[1].y)) / det;
606     xf.eM22 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y - rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det;
607     xf.eDy  = (rect[0].x*(rect[1].y*plg[2].y - rect[2].y*plg[1].y) -
608                rect[1].x*(rect[0].y*plg[2].y - rect[2].y*plg[0].y) +
609                rect[2].x*(rect[0].y*plg[1].y - rect[1].y*plg[0].y)
610                ) / det;

I have a formula that so far seems to give always the correct matrix:

xf.eM11 = (FLOAT) -(rect[1].y*plg[2].x+rect[0].y*(plg[1].x-plg[2].x)-rect[2].y*plg[1].x+plg[0].x*(rect[2].y-rect[1].y)) /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x);

xf.eM12 = (FLOAT) -(rect[1].y*(plg[2].y-plg[0].y)+rect[0].y*(plg[1].y-plg[2].y)+rect[2].y*(plg[0].y-plg[1].y)) /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x);

xf.eM21 = (FLOAT) (plg[0].x*(rect[2].x-rect[1].x)-plg[1].x*rect[2].x+plg[2].x*rect[1].x+(plg[1].x-plg[2].x)*rect[0].x) /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x);

xf.eM22 = (FLOAT) ((plg[0].y-plg[1].y)*rect[2].x+(plg[2].y-plg[0].y)*rect[1].x+(plg[1].y-plg[2].y)*rect[0].x) /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x);

xf.eDx = (FLOAT) -(rect[0].y*(plg[2].x*rect[1].x-plg[1].x*rect[2].x)+plg[0].x*(rect[1].y*rect[2].x-rect[2].y*rect[1].x)+(rect[2].y*plg[1].x-rect[1].y*plg[2].x)*rect[0].x) /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x);

xf.eDy = (FLOAT) (rect[0].y*(plg[1].y*rect[2].x-plg[2].y*rect[1].x)-rect[1].y*plg[0].y*rect[2].x+rect[2].y*plg[0].y*rect[1].x+(rect[1].y*plg[2].y-rect[2].y*plg[1].y)*rect[0].x) /(rect[0].y*(rect[2].x-rect[1].x)-rect[1].y*rect[2].x+rect[2].y*rect[1].x+(rect[1].y-rect[2].y)*rect[0].x);

The rect and plg arrays must be of FLOAT points for the formula to work well, like

struct

{

double x;

double y;

}

Otherwise sometimes the compiler will decide to divide integers.

I found out about the bug by converting the rect points using the XFORM matrix, and checking that their the same as the plg points.

Re: Wine sound discussion summary

2009-12-08T08:25:48Z

Hi Stefan,

Stefan Dösinger schreef:

> Am 08.12.2009 um 13:06 schrieb Robert Reif:
>
>> Yes, a single ring buffer for all the software mixed direct
>> sound buffers. A good driver implementation would
>> have a ring buffer for every direct sound buffer. Therefore
>> no requirement for any software mixing. That path is in
>> the direct sound dll now but is not used because no
>> driver supports it. In fact, when you rewrite the dll, you
>> should be removing all existing code paths excepts this one.
>>
> Maarten please correct me if I am wrong, but I think the reason why the Alsa driver does its own mixing is because Alsa does sample rate and similar conversions only when NOT using the mmap API. So you either get Alsa-side mixing or fast access using mmap. Back it the days it was considered that mixing ourselves and then using mmap was faster than not using mmap and then let Alsa mix things(which happens in Software as well in most cases)
>

Wrong :)

Alsa doesn't allow you to specify buffer sizes, or granularity.
Furthermore rate resampling in alsa results in horrible things
happening, you cannot set a alsa buffer in looping mode reliably, and if
you could you cannot randomly access its memory, furthermore buffer
notications don't work, and you cannot set per stream volume.. I
probably missed a few other reasons but those are the biggest ones.

Cheers,
Maarten.

Re: Author: Maarten Lankhorst

2009-12-08T05:09:50Z

> Author: Maarten Lankhorst <mlankhorst@patser.(none)
Did you forget to configure your email address in git?

Re: Wine sound discussion summary

2009-12-08T05:07:53Z

Am 08.12.2009 um 13:06 schrieb Robert Reif:
> Yes, a single ring buffer for all the software mixed direct
> sound buffers. A good driver implementation would
> have a ring buffer for every direct sound buffer. Therefore
> no requirement for any software mixing. That path is in
> the direct sound dll now but is not used because no
> driver supports it. In fact, when you rewrite the dll, you
> should be removing all existing code paths excepts this one.
Maarten please correct me if I am wrong, but I think the reason why the Alsa driver does its own mixing is because Alsa does sample rate and similar conversions only when NOT using the mmap API. So you either get Alsa-side mixing or fast access using mmap. Back it the days it was considered that mixing ourselves and then using mmap was faster than not using mmap and then let Alsa mix things(which happens in Software as well in most cases)

Re: shdocvw: Fix test for non-english IE MUI

2009-12-08T04:49:15Z

On 12/08/2009 01:29 PM, Alistair Leslie-Hughes wrote:

> Hi Jacek,
>
>> You don't need to delete the whole test. You can check for the system
>> language and do the compare only if it's English.
>>
> Is there an example that already does this?
>
> Just use function GetUILanguageInfo or similar?
>
> Best Regards
> Alistair Leslie-Hughes
>
>
>

Something like (advapi32/test/security.c):

if (PRIMARYLANGID(LANGIDFROMLCID(GetThreadLocale())) != LANG_ENGLISH)
{
skip("Non-english locale (test with hardcoded 'Everyone')\n");
}

--
Cheers,

Paul.

[PATCH] kernel32: Respect the LANG environment variable on Mac OS.

2009-12-08T04:39:22Z

Hi,

Ken Thomases wrote:

>Currently, Wine uses the LC_MESSAGES category to determine sCountry and
Locale.
Good to know.

>That's not quite what I proposed. I propose the following
[pseudo-code omitted]
>This results in the order I previously described:
>LC_ALL
>LC_* from the original environment
>Mac OS X settings
>LANG
In other words, LANG is completely ignored, since there presumably won't
be a Mac without settings.

I thought that was current behaviour. If it's not, then by all means,
please go ahead, implement this and document it.

The only point of dissension is about LANG. What you propose is
closer to POSIX than what's current, so it's still progress, even though
it both violates POSIX and deviates from Wine's behaviour on Linux.
We can revisit the LANG issue some time later.

Hmm, thinking about your pseudo-code (not quoted here), I'm not sure
that
implements the "LC_ALL takes priority over LC_xyz" correctly, does it?
Also, it omits the mapping that Bruno Haible hinted at:
"Note that these [MacOS X]
settings are similar but not entirely equal to Unix (glibc)
conventions (e.g. "zh-Hans" vs. "zh_CN"), therefore some mapping of
names has to be done."

Regards,
Jorg Hohle

Re: shdocvw: Fix test for non-english IE MUI

2009-12-08T04:29:51Z

Hi Jacek,

> You don't need to delete the whole test. You can check for the system
> language and do the compare only if it's English.
>
Is there an example that already does this?

Just use function GetUILanguageInfo or similar?

Best Regards
Alistair Leslie-Hughes

Re: Wine sound discussion summary

2009-12-08T04:06:17Z

Maarten Lankhorst wrote:

> Hi Reif,
>
> 2009/12/8 Robert Reif <reif@...>:
>
>> Francois Gouget wrote:
>>
>>> Also, as far as I know, DirectSound works on top of all our backend
>>> drivers.
>>>
>>>
>>>
>> It works through the WAVE API on most drivers which
>> requires software mixing and format conversions. Even
>> the direct sound drivers only implement a single
>> hardware buffer which means that even direct sound
>> goes through the software mixer and format conversions.
>>
> GASP, that's not such a problem that you make it out to be.
> Hell, winealsa even emulates a ring buffer with read calls, see f27d88e16fe..
>
>

Yes, a single ring buffer for all the software mixed direct
sound buffers. A good driver implementation would
have a ring buffer for every direct sound buffer. Therefore
no requirement for any software mixing. That path is in
the direct sound dll now but is not used because no
driver supports it. In fact, when you rewrite the dll, you
should be removing all existing code paths excepts this one.

>> If any direct sound driver implemented multiple buffers
>> of any format, there would be no software mixing done
>> in the direct sound dll. Everything would just pass through
>> the direct sound dll directly to the driver untouched. We
>> would also get multiple open support since it wouldn't
>> matter which application the buffers came from.
>>
> The dsound timer would still tick and most of the time the app would
> still use the crappy remixer in dsound since games use
> DSBCAPS_LOCSOFTWARE these days.. Even more fundamentally, our winmm
> drivers are crap, full of literally copied versions of wineoss, just
> renamed and sedded, but never maintained. Spot the similar #if 0's...
>
> The wavein/out drivers will be thrown out after we can forward to
> WASAPI, since the midi code is still handled in winmm afaict, a few of
> them will continue to live for that purpose..
>
> Can I please have some new discussion point instead of you trying to
> bring up the same over and over? I'm growing tired of having to repeat
> myself so much..
>
>

I know this discussion is academic at this point but sound in
wine is poor not because of a bad model but because of real poor
and incomplete driver implementations. With the right driver,
the current model for pre vista applications would have had
no issues. This is the same problem Microsoft had and is one
of the reasons they changed their audio system model.

With the introduction of vista, a new model is required but just
like vista, audio capabilities will be significantly reduced and
backwards compatibility will become a big issue requiring
workarounds. Also putting in new incomplete drivers that
don't support everything required will just be repeating
the same mistakes we already made. I don't want to see a new
implementation start out with the same problems that the old
system had because people didn't learn any lessons. We are
already talking about hacks to fix things before the new
implementation is even fully conceptualized. Not a good start.

Re: shdocvw: Fix test for non-english IE MUI

2009-12-08T03:38:31Z

Hi Alistair,

Alistair Leslie-Hughes wrote:
> Hi,
> Either use this patch or patch "Added support for non-enligh IE MUI".
>
> Changelog:
> shdocvw: Fix test for non-english IE MUI
- ok(!strcmp_wa(sName, "Microsoft Web Browser Control"), "got '%s', expected 'Microsoft Web Browser Control'\n", wine_dbgstr_w(sName));
+ ok(sName, "get_Name return a NULL string.'\n");

You don't need to delete the whole test. You can check for the system language and do the compare only if it's English.

Jacek

Re: 1/2 wined3d: print warning/error to winediag [try2]

2009-12-08T03:25:02Z

Roderick Colenbrander <thunderbird2k@...> writes:

> {
> - ERR("Direct3D%d is not available without opengl\n", dxVersion);
> + ERR_(winediag)("Unable to initialize Direct3D%d due to lack of OpenGL support.\nMake sure OpenGL drivers are installed on your system and that Wine was compiled with OpenGL support.\n", dxVersion);

I don't think you want that. One of the ideas behind winediag is that it
should be machine-parsable, and adding new lines in the middle of traces
will make that harder.

--
Alexandre Julliard
julliard@...

Re: shdocvw: Added support for non-english IE MUI

2009-12-08T02:53:41Z

Hi Paul,

> Although I can agree on adding this language support to the
> implementation, I'm not sure we want this in the tests. Someone has to
> keep the translations up-to-date in the tests. Next to that the new tests
> assume that our translation is exactly the same as Windows, not sure if we
> even want that.

I wasn't sure on what the best approach was, so I added resources to both.

Currently I see two options
1. Use the current patch and add resources as the test fail for each
language.

2. Change the test to "str", and "hres == S_OK", and wait for an app to
rely on the translated string to work before adding resources to
either.
(patch will be available shortly).

Either way, the control string will be exactly what we get from get_Name, so
translators
properly wouldn't need to directly translate it. (copy paste from error log
:) )

Best Regards
Alistair Leslie-Hughes

Re: shdocvw: Added support for non-english IE MUI

2009-12-08T02:26:21Z

On 12/08/2009 11:10 AM, Alistair Leslie-Hughes wrote:

> Hi,
> When IE has support to display non-english menus, its returns a
> translated string for the control name (get_Name) for the language being
> used.
>
>
> Changelog:
> shdocvw: Added support for non-english IE MUI
>
> Best Regards
> Alistair Leslie-Hughes
>

Hi Alistair,

Although I can agree on adding this language support to the
implementation, I'm not sure we want this in the tests. Someone has to
keep the translations up-to-date in the tests. Next to that the new
tests assume that our translation is exactly the same as Windows, not
sure if we even want that.

--
Cheers,

Paul.

Re: winetest + pbuffer + nvidia 190.18 drivers = X crash

2009-12-08T02:09:24Z

2009/12/8 Austin English <austinenglish@...>:

> Updated to 195.22 drivers, and it reappeared. Though it may have been
> disabled glsl that did it. I tried running those configs again, but no
> crash, so perhaps a race?
> Backtrace:
> 0: /usr/bin/X(xorg_backtrace+0x26) [0x4f00c6]
> 1: /usr/bin/X(xf86SigHandler+0x41) [0x4852c1]
> 2: /lib/libc.so.6 [0x7f349cbb4530]
> 3: /usr/bin/X [0x4b674a]
> 4: /usr/bin/X [0x4b6b37]
> 5: /usr/bin/X [0x49f17f]
> 6: /usr/bin/X [0x49f355]
> 7: /usr/bin/X(RRCrtcSet+0x162) [0x51d092]
> 8: /usr/bin/X(ProcRRSetScreenConfig+0x508) [0x522a88]
> 9: /usr/bin/X(Dispatch+0x394) [0x44e174]
> 10: /usr/bin/X(main+0x3b5) [0x434085]
> 11: /lib/libc.so.6(__libc_start_main+0xfd) [0x7f349cb9fabd]
> 12: /usr/bin/X [0x433509]
> Saw signal 11. Server aborting.
>

That looks related to resolution changes. I've seen similar backtraces
before, and I guess it's some interaction between the X server and the
video drivers. I don't think it's really specific to Wine, just that
we're more likely to change the resolution than other applications.

Re: [PATCH] user32: Make DefWindowProc handle SHIFT+F10.

2009-12-08T02:05:36Z

"Kusanagi Kouichi" <slash@...> wrote:

> According to MSDN[1], DefWindowProc generates the WM_CONTEXTMENU
> message when SHIFT+F10 is typed.
>
> [1] http://msdn.microsoft.com/en-us/library/ms647592.aspx

Usually MSDN statements/descriptions shouldn't be taken as an action
guide, a test case is required to see what happens in reality. At least
a quick test shows that if a menu is activated pressing Shift+F10 does
nothing. dlls/user32/tests/msg.c already has some tests for VK_APPS and
VK_F10 press/release, please add a new test there.

--
Dmitry.

Re: Very long printernames and test failures

2009-12-08T01:20:51Z

On 12/08/2009 08:03 AM, Paul Vriens wrote:

> On 12/07/2009 11:38 PM, Detlef Riekenberg wrote:
>> On So, 2009-12-06 at 19:28 +0100, Paul Vriens wrote:
>>
>>> Some test failures are shown on boxes with long printernames, for
>>> example:
>>>
>>> http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/vista_test-on-vista/winspool.drv:info.html
>>>
>>> http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/win7_153/winspool.drv:info.html
>>>
>>>
>>> And indeed if I create a local printer with a very long name the cutoff
>>> is one bigger than what the test is currently doing.
>>>
>>> The attached patch fixes that.
>>
>> I cant find a reason, why Windows is using 2 character for the
>> terminating zero.
>> This looks like an Windows bug.
>> I expect a different behavior on older Windows versions.
>>
>>> The best test would probably to add a printer in the tests
>>
>> An addprinter-test with a medium sized name is in my tree, but it needs
>> some
>> fixes in our Implementation.
>> I'm testing with AddPrinter in localspl, but the 16Bit separation got a
>> higher
>> priority.
>>
>>> Any thoughts?
>> Manual creating printers with the specific length
>> (CCHDEVICENAME -2 / -1 / +0 / +1) on older OS and run the tests is easy,
>> but I cant do that before the next weekend.
>>
>>
>
> I will add some printers with names of different length to my test boxes
> and see what the results are.
>

Win9x/WinMe won't let me create a printername (manually) with a name >
(CCHDEVICENAME - 1)

On NT4/W2K I can create longer names but the dmDeviceName is still
nicely cut off at (CCHDEVICENAME - 1) so the tests still succeed.

As of XP when I create a printer with a name greater then (CCHDEVICENAME
- 1) it's cut of at 30 for dmDeviceName.

It will change the tests to deal with both. As this is the behavior of
XP and later I don't think we can talk about a bug so I won't mark this
as broken() for any of them.

--
Cheers,

Paul.

Free VMware Workstation licenses for Wine developers

2009-12-08T00:13:06Z

I already announced this at WineConf, but for people who were not there: VMware wants to support the Wine project by providing free of charge Workstation 7 licenses to Wine developers. We're not going to be too picky about the definition of "Wine developer". If you have been able to get a patch past Alexandre you've shown enough dedication to qualify ;-).
There are a few restrictions on these licenses:
- Not for resale
- Not upgradable
- No support entitlement
If you want a license, just send me an email (off-list).

Ge.

Re: How does --with-wine64 work?

2009-12-07T23:28:03Z

On Tue, Dec 8, 2009 at 1:01 AM, Maarten Lankhorst
<m.b.lankhorst@...> wrote:

> Austin English schreef:
>>
>> Vincent asked me to get add a --with-wine64 option to my build script.
>> I was testing around, and can't seem to get it to work:
>> $ mkdir - p $HOME/wine{32,64}
>> $ cd $HOME/wine64
>> $ ~/wine-git/configure --enable-win64
>> $ make -j4
>> $ cd $HOME/wine32
>> $ ~/wine-git/configure --with-wine64=~/wine64
>> ...
>>
>>>
>>> checking for the directory containing the Wine tools... configure: error:
>>> could not find Wine tools in ~/wine64/
>>>
>>
>> ~/wine-git/configure --with-wine64=~/wine64/tools/
>> ...
>> checking for the directory containing the Wine tools... configure:
>> error: could not find Wine tools in ~/wine64/tools/
>>
>> What am I missing? Perhaps it needs to be installed somewhere first?
>>
>
> Try --with-wine64=$HOME/wine64
> The ~ doesn't get expanded

I feel silly...I could have sworn I tried that. Thanks Maarten!

--
-Austin

Re: winhttp/tests: Fix test error when run as non-administrator

2009-12-07T23:10:20Z

On 12/08/2009 12:58 AM, Juan Lang wrote:
> - ok(ret, "WinHttpSetDefaultProxyConfiguration failed: %d\n", GetLastError());
> + ok(ret || GetLastError() == ERROR_ACCESS_DENIED,
> + "WinHttpSetDefaultProxyConfiguration failed: %d\n", GetLastError());
>
> - set_default_proxy_reg_value( saved_proxy_settings, len, type );
> + if (ret)
> + set_default_proxy_reg_value( saved_proxy_settings, len, type );
> }

Hi Juan,

I'm not a big fan of this. In theory we can now mess up our
implementation and return ERROR_ACCESS_DENIED without knowing that
something is wrong as the tests will still succeed.

I agree that ERROR_ACCESS_DENIED is a valid return value but I'd rather
have some win_skip() or at least a skip() in there. win_skip() will work
fine right now but as soon as we implement access rights to the registry
(and multi-user) it should probably be a skip().

--
Cheers,

Paul.

Re: Very long printernames and test failures

2009-12-07T23:03:10Z

On 12/07/2009 11:38 PM, Detlef Riekenberg wrote:

> On So, 2009-12-06 at 19:28 +0100, Paul Vriens wrote:
>
>> Some test failures are shown on boxes with long printernames, for example:
>>
>> http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/vista_test-on-vista/winspool.drv:info.html
>> http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/win7_153/winspool.drv:info.html
>>
>> And indeed if I create a local printer with a very long name the cutoff
>> is one bigger than what the test is currently doing.
>>
>> The attached patch fixes that.
>
> I cant find a reason, why Windows is using 2 character for the
> terminating zero.
> This looks like an Windows bug.
> I expect a different behavior on older Windows versions.
>
>> The best test would probably to add a printer in the tests
>
> An addprinter-test with a medium sized name is in my tree, but it needs
> some
> fixes in our Implementation.
> I'm testing with AddPrinter in localspl, but the 16Bit separation got a
> higher
> priority.
>
>> Any thoughts?
> Manual creating printers with the specific length
> (CCHDEVICENAME -2 / -1 / +0 / +1) on older OS and run the tests is easy,
> but I cant do that before the next weekend.
>
>

I will add some printers with names of different length to my test boxes
and see what the results are.

--
Cheers,

Paul.

Re: How does --with-wine64 work?

2009-12-07T23:01:40Z

Austin English schreef:

> Vincent asked me to get add a --with-wine64 option to my build script.
> I was testing around, and can't seem to get it to work:
> $ mkdir - p $HOME/wine{32,64}
> $ cd $HOME/wine64
> $ ~/wine-git/configure --enable-win64
> $ make -j4
> $ cd $HOME/wine32
> $ ~/wine-git/configure --with-wine64=~/wine64
> ...
>
>> checking for the directory containing the Wine tools... configure: error: could not find Wine tools in ~/wine64/
>>
> ~/wine-git/configure --with-wine64=~/wine64/tools/
> ...
> checking for the directory containing the Wine tools... configure:
> error: could not find Wine tools in ~/wine64/tools/
>
> What am I missing? Perhaps it needs to be installed somewhere first?
>

Try --with-wine64=$HOME/wine64
The ~ doesn't get expanded

Re: Wine sound discussion summary

2009-12-07T22:48:36Z

Hi Reif,

2009/12/8 Robert Reif <reif@...>:

> Francois Gouget wrote:
>>
>> Also, as far as I know, DirectSound works on top of all our backend
>> drivers.
>>
>>
>
> It works through the WAVE API on most drivers which
> requires software mixing and format conversions. Even
> the direct sound drivers only implement a single
> hardware buffer which means that even direct sound
> goes through the software mixer and format conversions.

GASP, that's not such a problem that you make it out to be.
Hell, winealsa even emulates a ring buffer with read calls, see f27d88e16fe..

> If any direct sound driver implemented multiple buffers
> of any format, there would be no software mixing done
> in the direct sound dll. Everything would just pass through
> the direct sound dll directly to the driver untouched. We
> would also get multiple open support since it wouldn't
> matter which application the buffers came from.
The dsound timer would still tick and most of the time the app would
still use the crappy remixer in dsound since games use
DSBCAPS_LOCSOFTWARE these days.. Even more fundamentally, our winmm
drivers are crap, full of literally copied versions of wineoss, just
renamed and sedded, but never maintained. Spot the similar #if 0's...

The wavein/out drivers will be thrown out after we can forward to
WASAPI, since the midi code is still handled in winmm afaict, a few of
them will continue to live for that purpose..

Can I please have some new discussion point instead of you trying to
bring up the same over and over? I'm growing tired of having to repeat
myself so much..

Re: wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)

2009-12-07T20:39:12Z

Peter Kovacs wrote:
> I think Austin is right, stopping Hacks would slow down development.
> And we need people hacking.
I'm not against hacks. I'm against dirty hacks, especially going into bugzilla!

What's a dirty hack? Something that adds commented out code, comments out
original code instead of removing / changing it, have loads of white-space
changes all over the place. Touches (in any way) parts that have nothing to
do with the actual problem. In short - something that person didn't even
bothered to look over and clean up before making it public.

If anyone still wants to maintain that sort of code - do it outside of
Wine's bugzilla. There are loads of free git repositories where one can dump
anything they pleased.

Also I'm having issues with people coming to bugzilla and asking how to
compile Wine, and other people trying to explain how to use patch. We have
forum/mailing list/IRC/wiki for this sort of stuff. Bugzilla is for bug
related information and discussions on how to fix it for example, not user
noise. Please keep it that way.

> There are some Ideas about splitting Hacks from patches.
Easy - patches go to wine-patches. Hacks can stay in bugzilla/private GIT
repos/wiki for long term stuff. Dirty hacks - should stay on PCs of their
creators until cleaned.

Vitaliy.

Re: How does --with-wine64 work?

2009-12-07T18:32:13Z

On Mon, Dec 7, 2009 at 9:30 PM, Steven Edwards <winehacker@...> wrote:
> This looks similar to the cross-compile build for mingw where you need
> a checkout with the normal tools built for your host and then another
> checkout for your target. You then run and point the target configure
> at the host wine path to get the host tools.

Doh I read that wrong. You had it right if it follows the same
structure as the mingw port. No idea, I'll try a build here in a bit

--
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

Re: How does --with-wine64 work?

2009-12-07T18:30:16Z

On Mon, Dec 7, 2009 at 7:44 PM, Austin English <austinenglish@...> wrote:
>> checking for the directory containing the Wine tools... configure: error: could not find Wine tools in ~/wine64/
> ~/wine-git/configure --with-wine64=~/wine64/tools/
> ...
> checking for the directory containing the Wine tools... configure:
> error: could not find Wine tools in ~/wine64/tools/
>
> What am I missing? Perhaps it needs to be installed somewhere first?

This looks similar to the cross-compile build for mingw where you need
a checkout with the normal tools built for your host and then another
checkout for your target. You then run and point the target configure
at the host wine path to get the host tools.

--
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

Re: wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)

2009-12-07T18:23:08Z

2009/12/8 Peter Kovacs <legine@...>:
> I think Austin is right, stopping Hacks would slow down development.
> And we need people hacking.

Bugzilla is not the right place for hacks. There is a wine-hacks
repository (naturally, completely unsupported by WineHQ). If a hack
developer wants the hack to be considered seriously, wine-patches is
the place to send it.

> There are some Ideas about splitting Hacks from patches. I think this maybe an aproach
> to solve this. Lets see:
-- snip --
> Thinking on it, it may be better put into a maintained Wikki with different Sections to go on.

Wiki has been suggested for AppDB before. It's not a solution there
and it's certainly not an appropriate bug tracker.

A wiki replacing bugzilla would need a *lot* more man-power from the
developers/maintainers to make sure the bug pages remain relevant to
the bug. It would also require all the admins to have in-depth
knowledge of all facets of the bugs they are maintaining. For
something like this Xinput/mouse issue, that basically means someone
who's working on the Xi2 driver. For the DIB engine, it's virtually
impossible.

> Closed Discussions can be deleted.

This does not account for regressions.

> If some real approach is found all Info can be back posted into Bugzilla by some "Officer".
> With that a solution is accepted and likely to enter the main tree when ready.
> The Idea seems to be quite flexible, but maybe it won't be structured enough. Which means
> more work for Maintainers (I would install community maintainers :( *sight* Maybe that Idea
> is not good enough, what do you think?

The problem here is that community maintainers are much less likely to
understand the bugs than the devleopers. For AppDB, it's ideal, as
maintainers are people who run the apps and know what to expect. For
Bugzilla (or any other bug tracker), only developers can be truly
effective maintainers - and not just any developers, but devlopers who
have or are working on related components.

Re: Wine sound discussion summary

2009-12-07T18:18:21Z

Francois Gouget wrote:
> Also, as far as I know, DirectSound works on top of all our
> backend drivers.
>
>
It works through the WAVE API on most drivers which
requires software mixing and format conversions. Even
the direct sound drivers only implement a single
hardware buffer which means that even direct sound
goes through the software mixer and format conversions.

If any direct sound driver implemented multiple buffers
of any format, there would be no software mixing done
in the direct sound dll. Everything would just pass through
the direct sound dll directly to the driver untouched. We
would also get multiple open support since it wouldn't
matter which application the buffers came from.

OpenAL and pulseaudio probably have the capabilities to
implement a direct sound driver that supports multiple
opens and mixing of multiple streams of different formats
which would bypass the software mixing and format
conversion path in the current direct sound dll implementation
but I guess we will never know. Unfortunately OSS and alsa
don't except under very limited conditions (if the drivers
implemented it which they don't).

Re: Wine sound discussion summary

2009-12-07T17:55:38Z

On Mon, 7 Dec 2009, Robert Reif wrote:
[...]
> Can we drop all current audio drivers now that don't have midi?
> Any driver that doesn't implement the complete winmm API and
> direct sound shouldn't be in the current tree anyway.

I don't see why drivers that don't support MIDI should be dropped. Lack
of MIDI support does not hamper games, media players and email arrival
notifiers. So a driver without MIDI support is still useful for a good
90% of the applications out there.

As for not implementing the 'complete winmm API' I'm not sure what you
mean. Also, as far as I know, DirectSound works on top of all our
backend drivers.

--
Francois Gouget <fgouget@...> http://fgouget.free.fr/
War doesn't determine who's right. War determines who's left.

How does --with-wine64 work?

2009-12-07T16:44:52Z

Vincent asked me to get add a --with-wine64 option to my build script.
I was testing around, and can't seem to get it to work:
$ mkdir - p $HOME/wine{32,64}
$ cd $HOME/wine64
$ ~/wine-git/configure --enable-win64
$ make -j4
$ cd $HOME/wine32
$ ~/wine-git/configure --with-wine64=~/wine64
...
> checking for the directory containing the Wine tools... configure: error: could not find Wine tools in ~/wine64/
~/wine-git/configure --with-wine64=~/wine64/tools/
...
checking for the directory containing the Wine tools... configure:
error: could not find Wine tools in ~/wine64/tools/

What am I missing? Perhaps it needs to be installed somewhere first?

--
-Austin

Re: Wine sound discussion summary

2009-12-07T16:28:27Z

Maarten Lankhorst wrote:
> The lack of an accelerated dsound interface isn't that big, just means
>
>
I wish accelerated direct sound had been a big issue. Both OSS and alsa
theoretically could support it under very limited circumstances but
there was no guarantee that it could be supported under all circumstances.

With full direct sound hardware acceleration in the low level driver, all
software mixing would be bypassed in the current direct sound
implementation. Direct sound would just forward calls from the
application to the driver. That's where the direct in direct sound
originally
came from in the old days.

Re: winetest + pbuffer + nvidia 190.18 drivers = X crash

2009-12-07T16:25:22Z

On Sun, Nov 29, 2009 at 11:37 PM, Austin English
<austinenglish@...> wrote:

> On Sun, Nov 29, 2009 at 5:45 AM, Henri Verbeet <hverbeet@...> wrote:
>> 2009/11/20 Austin English <austinenglish@...>:
>>> Been happening for a few days...not sure what triggered it, but when
>>> coming back from work I see my login screen, which explains the lack
>>> of 64-bit tests/appinstall results. I don't know if any of the D3D
>>> guys could take a look, but I'd appreciate it...
>>>
>> What does your Xorg log look like?
>
> Doesn't seem to want to crash now...strange. I'll keep an eye on it
> and if it happens again I'll get the log.

Updated to 195.22 drivers, and it reappeared. Though it may have been
disabled glsl that did it. I tried running those configs again, but no
crash, so perhaps a race?
Backtrace:
0: /usr/bin/X(xorg_backtrace+0x26) [0x4f00c6]
1: /usr/bin/X(xf86SigHandler+0x41) [0x4852c1]
2: /lib/libc.so.6 [0x7f349cbb4530]
3: /usr/bin/X [0x4b674a]
4: /usr/bin/X [0x4b6b37]
5: /usr/bin/X [0x49f17f]
6: /usr/bin/X [0x49f355]
7: /usr/bin/X(RRCrtcSet+0x162) [0x51d092]
8: /usr/bin/X(ProcRRSetScreenConfig+0x508) [0x522a88]
9: /usr/bin/X(Dispatch+0x394) [0x44e174]
10: /usr/bin/X(main+0x3b5) [0x434085]
11: /lib/libc.so.6(__libc_start_main+0xfd) [0x7f349cb9fabd]
12: /usr/bin/X [0x433509]
Saw signal 11. Server aborting.

I've installed xserver-xorg-core-dbg, so if it crashes again, should
have a better log.

--
-Austin

Xorg.0.log.old (30K) Download Attachment

Re: Wine sound discussion summary

2009-12-07T16:02:12Z

Hello,

2009/12/8 Robert Reif <reif@...>:
...
> Can we drop all current audio drivers now that don't have midi?
> Any driver that doesn't implement the complete winmm API and
> direct sound shouldn't be in the current tree anyway.
I wish, but aj wouldn't even let me delete winenas.drv that has been
obviously broken for many years, even after I pointed out it even
failed 'play test sound' in winecfg after you set it up. I guess it
has to wait until after wine7audio hits.
The lack of an accelerated dsound interface isn't that big, just means
1 more copy of the primary buffer kept around, wine dsound should
handle it correctly, tested on windows some time back too.

Our dsound won't run on windows though, mingw gets horribly confused
by DirectSoundCreate8@24 and DirectSoundCreate@24, and no matter what
I tried, either dynamic linking or static linking would fail (or
both..)

Cheers,
Maaten.

Re: Wine sound discussion summary

2009-12-07T15:31:29Z

Francois Gouget wrote:

> On Sun, 6 Dec 2009, Stefan Dösinger wrote:
> [...]
>
>> So you mean keeping the existing infrastructure around just for midi
>> and have something entirely different for the rest of the audio
>> features?
>>
>
> That might nt be too bad in that we could still drop all the current
> current winmm audio backends that don't support Midi. At first glance:
> wineaudioio, wineesd, winejack, and winenas. So we'd just keep the Midi
> portion of winealsa, winecoreaudio and wineoss.
>
>

Can we drop all current audio drivers now that don't have midi?

Any driver that doesn't implement the complete winmm API and
direct sound shouldn't be in the current tree anyway.

Re: Very long printernames and test failures

2009-12-07T14:38:02Z

On So, 2009-12-06 at 19:28 +0100, Paul Vriens wrote:

> Some test failures are shown on boxes with long printernames, for example:
>
> http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/vista_test-on-vista/winspool.drv:info.html
> http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/win7_153/winspool.drv:info.html
>
> And indeed if I create a local printer with a very long name the cutoff
> is one bigger than what the test is currently doing.
>
> The attached patch fixes that.

I cant find a reason, why Windows is using 2 character for the
terminating zero.
This looks like an Windows bug.
I expect a different behavior on older Windows versions.

> The best test would probably to add a printer in the tests

An addprinter-test with a medium sized name is in my tree, but it needs
some
fixes in our Implementation.
I'm testing with AddPrinter in localspl, but the 16Bit separation got a
higher
priority.

> Any thoughts?
Manual creating printers with the specific length
(CCHDEVICENAME -2 / -1 / +0 / +1) on older OS and run the tests is easy,
but I cant do that before the next weekend.

--

By by ... Detlef