re: Wine performance improvement

[Dan Kegel]

Interesting!Clearly a long ways off from production-ready, but
it's fun to see somebody trying this.

A few notes:

Please clean up the patch a bit to remove lines like this:
+//FIXME("handle : %ld \n", handle);
and extra files like
dlls/ws2_32/tests/test.sh

Please avoid hand-editing
include/wine/server_protocol.h
The start of the file even says:
 * This file is automatically generated; DO NO EDIT!
 * Edit server/protocol.def instead and re-run tools/make_requests

Please switch to plain text for future posts.  It's very
hard to read in the archive; see
http://www.winehq.org/pipermail/wine-devel/2009-December/080394.html

Please identify the author(s) of the new code for copyright purposes,
and ensure they agree to licensing their code under the LGPL (for Wine)
and GPL (for Linux kernel).

I'm sure other people will have more to say.

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

[Juan Lang]

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

[Nikolay Sivov]

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-patc...@winehq.org


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

[Alexander Almaleh]

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

Re: Wine sound discussion summary

[Maarten Lankhorst]

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

[Stefan Dösinger]

> Author: Maarten Lankhorst 

Re: Wine sound discussion summary

[Stefan Dösinger]

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

[Paul Vriens]

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.

[Joerg-Cyril.Hoehle]

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

[Alistair Leslie-Hughes]

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

[Robert Reif]

Maarten Lankhorst wrote:

Hi Reif,

2009/12/8 Robert 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

[Jacek Caban]

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]

[Alexandre Julliard]

Roderick Colenbrander  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
julli...@winehq.org

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

[Alistair Leslie-Hughes]

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

[Paul Vriens]

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: [PATCH] user32: Make DefWindowProc handle SHIFT+F10.

[Dmitry Timoshkov]

"Kusanagi Kouichi"  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: winetest + pbuffer + nvidia 190.18 drivers = X crash

[Henri Verbeet]

2009/12/8 Austin English :
> 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: Very long printernames and test failures

[Paul Vriens]

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

[Greg Geldorp]

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.