"Andrew Fenn" <andrewfenn(a)gmail.com> writes:
> +BOOL WINAPI DllMain(HINSTANCE inst, DWORD reason, LPVOID reserved)
> +{
> + switch(reason)
> + {
> + case DLL_WINE_PREATTACH:
> + return FALSE; /* prefer native version */
You need to do that for all the dlls, not just the 1_3 one. Also please
send one patch per dll.
--
Alexandre Julliard
julliard(a)winehq.org
Tony Wasserka <tony.wasserka(a)freenet.de> writes:
> + /* About This->flags:
> + != D3DXSPRITE_FLAGLIMIT+1 means we have already called ID3DXSprite_Begin
> + == D3DXSPRITE_FLAGLIMIT+1 means we have either called D3DXCreateSprite or ID3DXSprite_End
> + In the first case we return D3DERR_INVALIDCALL, in the other one we can continue.
> + For ID3DXSprite_Flush/Draw This->flags must be < D3DXSPRITE_FLAGLIMIT+1. */
> + if(flags>D3DXSPRITE_FLAGLIMIT || This->flags!=D3DXSPRITE_FLAGLIMIT+1)
> + return D3DERR_INVALIDCALL;
That's ugly, if you need to know if Begin has been called you should
store a separate flag for that.
--
Alexandre Julliard
julliard(a)winehq.org
There's a launchpad bugzilla plugin available now, made by bugzilla
developers: https://help.launchpad.net/Bugs/BugzillaPlugin
Having this seems like it would simplify things, as there wouldn't be a
need to forward comments on a launchpad bug to the one posted at WineHQ.
It can be quite annoying checking both pages once a bugzilla bug and a
launchpad bug are linked to eachother.
Thoughts?
Thanks,
Scott Ritchie
Sergey Khodych wrote:
>
>
> ------------------------------------------------------------------------
>
>
Sorry for the previous email (replied to the wrong patch email).
Hi,
Could you have a look at
http://test.winehq.org/data/3f4333d70c27a813b4d99e0daeeb613e9e941a9a/ as this
patch introduced a failure on all Windows platforms.
I guess it's just changing 183 to 185. But that 183 is there for a reason, not?
--
Cheers,
Paul.
Sergey Khodych wrote:
>
>
> ------------------------------------------------------------------------
>
>
Hi,
Could you have a look at
http://test.winehq.org/data/3f4333d70c27a813b4d99e0daeeb613e9e941a9a/ as this
patch introduced a failure on all Windows platforms.
I guess it's just changing 183 to 185. But that 183 is there for a reason, not?
--
Cheers,
Paul.
Alistair Leslie-Hughes wrote:
> Hi,
> Made functions for get/set.
>
> Changelog:
> mshtml: Implement IHTMLStyle get/put posLeft
+ for(ptr=value; isdigitW(*ptr); ptr++)
+ {
+ if(*ptr && !strcmpW(ptr, pxW)) {
This if expression will never be true. You should move it after for loop
and change !strcmpW to strcmpW.
Jacek
Hi Robert
--------------------------------------------------
From: "Robert Reif" <reif(a)earthlink.net>
Sent: Thursday, November 06, 2008 11:00 PM
To: "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com>
Cc: <wine-devel(a)winehq.org>
Subject: Re: winmm: Increase tolerance range in tests
>>
> On real hardware or on a virtual machine?
The data I was looking at comes from
http://test.winehq.org/data/
Some of these will be virtual machines but I cannot tell.
Best Regards
Alistair Leslie-Hughes
Patchwatcher is now working well enough to
depend on, I think, but doesn't send email yet.
You should see your patch appear at
http://kegel.com/wine/patchwatcher/results
under a minute after you post, and if
your patch is simple, test results should
show up about ten minutes later.
(Long patch series take longer,
since patchwatcher runs the test
suite after each patch in the series.)
Today's changes (from
http://code.google.com/p/winezeug/source/list ):
- Update the dashboard immediately upon receiving patches.
- Added qmgr timeout and winhttp:notification.c to blacklist.
Full blacklist at
http://winezeug.googlecode.com/svn/trunk/patchwatcher/blacklist.txt
Please fix your tests so I don't have to blacklist them.
(The d3d tests should start passing once I move
to the latest nvidia drivers, so don't worry about them.)
Alistair Leslie-Hughes wrote:
> Hi,
>
> Changelog:
> winmm: Increase tolerance range in tests
>
> Best Regards
> Alistair Leslie-Hughes
>
Please give an explanation why? If it's just to make the test pass,
then we need to know why the test is failing.
Is it only needed for wine? Could be a wine problem.
Is it only needed for specific versions of Windows or specific hardware
or drivers?
Is it only needed for Windows running on a virtual machine? Then it
could be a a virtual machine hardware emulation problem.
I think all Windows hardware test failures that only happen on virtual
machines should be considered suspect. It would be nice to detect if
Windows is running on real hardware or a virtual machine because of this
type of problem.