Re: xlive: add initial tests, make them pass under Wine
On Tue, Nov 2, 2010 at 7:15 AM, Marvin test...@testbot.winehq.org wrote: Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6708 Your paranoid android. Patch is fine, I forgot the 3/3. I'll resend it to unconfuse the bot. -- -Austin
Re: [PATCH 1/3] include: Add macros for retrieving control message headers (try 2).
Erich Hoover ehoo...@mines.edu writes: This patch adds the windows version of the macros for retrieving control message headers (such as IP_PKTINFO control header responses). This structure is required by later patches in this series in order to implement IP_PKTINFO. In this version the macros are moved to ws2def.h and WSA_CMSG_NXTHDR is an actual macro (dependent upon a couple custom macros for clarity), rather than an inline function. Please don't add custom macros that don't exist on Windows, it's not necessary. -- Alexandre Julliard julli...@winehq.org
Re: ddraw/tests: Fix compilation on systems that don't support nameless unions.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6710 Your paranoid android. === W98SE (32 bit dsurface) === dsurface: unhandled exception c005 at 00415109
Re: ddraw/tests: Remove a space before a '\n'.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6711 Your paranoid android. === W98SE (32 bit ddrawmodes) === ddrawmodes: unhandled exception c005 at 004122E8 === W7PROX64 (64 bit ddrawmodes) === Timeout
rasphone.exe, rasapi32.dll and rasdlg.dll
Hi, I want to contribute a rasphone.exe, rasapi32.dll and rasdlg.dll to the Wine project :-). The rasphone.exe is already completed, but I have still to do a lot of work for rasapi32.dll and rasdlg.dll. For the RAS-Connection I use wvdial. Right now all my work is coded into the rasphone.exe, but I will change that and use a rasapi32.dll and rasdlg.dll. I will post my code when it's ready... I hope you will all enjoy my work, best regards Gerold Jens Wucherpfennig -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
Re: [PATCH 1/2 resend] urlmon: Added IInternetProtocolEx support to BindProtocol.
Jacek Caban ja...@codeweavers.com writes: This patch was previously rejected due to test failure in gameux. The failure no longer happens for me. It's still failing here: ../../../tools/runtest -q -P wine -M gameux.dll -T ../../.. -p gameux_test.exe.so gameexplorer.c touch gameexplorer.ok gameexplorer.c:571: Test failed: IGameExplorer::AddGame failed (error 0x80004005) gameexplorer.c:589: Test failed: IGameExplorer::AddGame failed (error 0x80004005) gameexplorer.c:640: Test failed: IGameExplorer2::InstallGame failed (error 0x80004005) gameexplorer.c:643: Test failed: cannot find game with GDF path LZ:\\home\\julliard\\wine\\wine\\dlls\\gameux\\tests\\gameux_test.exe in scope 2 make: *** [gameexplorer.ok] Error 4 -- Alexandre Julliard julli...@winehq.org
Re: xlive: add initial stub dll (1/3)
Austin English austinengl...@gmail.com writes: This dll is not a core part of windows (at least, not yet), but I think it should be considered for inclusion in Wine. A bit of explanation is necessary: xlive.dll comes from Games for Windows (1,2), whose installer depends on .Net 3.5 (can be skipped with the /nodotnet parameter). Native fails on wine, however, unless a native msasn1.dll is provided, because xlive.dll is digitally signed (so implementing our own msasn1.dll won't help). As it currently stands, users can't play any 'Game for Windows' that doesn't have a Windows license. That's not a good enough reason, particularly considering how ugly the resulting code is. And it seems unlikely that this is ever going to move beyond the nasty hack stage, given the lack of documentation. -- Alexandre Julliard julli...@winehq.org
re: xlive and msasn1.dll
Austin wrote: xlive.dll comes from Games for Windows ... [and] fails on wine, however, unless a native msasn1.dll is provided, because xlive.dll is digitally signed (so implementing our own msasn1.dll won't help). That's interesting. I wonder what other modules Microsoft is checking signatures on, and whether they're planning on doing that more often in the future.
Re: xlive: add initial tests, make them pass under Wine
Austin English austinengl...@gmail.com wrote: Resend them all. The 'bot' cannot apply just one patch in a series (AJ has pointed this out as well as Ge.) James McKenzie
Voting for bugs (Was: Re: [Bug 20969])
Can/should voting for bugs be disabled if it is 'useless and does nothing except adding noise'? Thanks Tom On Tue, Nov 2, 2010 at 12:01 PM, wine-b...@winehq.org wrote: http://bugs.winehq.org/show_bug.cgi?id=20969 --- Comment #19 from Dmitry Timoshkov dmi...@codeweavers.com 2010-11-02 12:01:23 CDT --- (In reply to comment #18) Those of you with this issue, make sure you vote for this in bugzilla so that it can be confirmed, if you haven't already. Voting for bugs in Wine bugzilla is useless and does nothing except adding noise. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Voting for bugs (Was: Re: [Bug 20969])
Tom Spear speeddy...@gmail.com wrote: [Message arranged in top to bottom posting order to comply with mailing list rules/guidelines] On Tue, Nov 2, 2010 at 12:01 PM, wine-b...@winehq.org wrote: http://bugs.winehq.org/show_bug.cgi?id=20969 --- Comment #19 from Dmitry Timoshkov dmi...@codeweavers.com 2010-11-02 12:01:23 CDT --- (In reply to comment #18) Those of you with this issue, make sure you vote for this in bugzilla so that it can be confirmed, if you haven't already. Voting for bugs in Wine bugzilla is useless and does nothing except adding noise. Can/should voting for bugs be disabled if it is 'useless and does nothing except adding noise'? Thanks Tom Tom: Voting for bugs does two things, and I don't think Dmitry wants to do the first: 1. It confirms that a bug does exists and possibly on multiple platforms. 2. It advises developers that more than one system/configuration is affected by a bug. I agree that adding thousands of votes to a long standing bug is 'noise'. Given that we have a limited resource of developers, having users verify bugs and to vote for them to give an idea of how severe a bug is might be helpful. Just my .02 USD here. James McKenzie
Quick Question About GDI
Hello, I was searching online to find more info about GDI and I came across your information. Can you tell me, are you still involved with GDI? If you are, how are things going for you? Please let me know. Sincerely, Aaron Tyler
Re: [4/4] msxml3: Implement domdoc schema validation (resend)
On 11/02/2010 07:15 AM, Alexandre Julliard wrote: Adam Martinsonamartin...@codeweavers.com writes: --- dlls/msxml3/domdoc.c | 127 dlls/msxml3/tests/domdoc.c |2 +- 2 files changed, 93 insertions(+), 36 deletions(-) This one breaks on libxml 2.6.16 too: gcc -m32 -c -I. -I. -I../../include -I../../include -I/usr/include/libxml2 -I/usr/include/libxml2 -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wpointer-arith -g -O2 -o domdoc.o domdoc.c domdoc.c: In function 'domdoc_validateNode': domdoc.c:2496: error: 'struct _xmlDoc' has no member named 'properties' domdoc.c:2496: error: 'XML_DOC_WELLFORMED' undeclared (first use in this function) domdoc.c:2496: error: (Each undeclared identifier is reported only once domdoc.c:2496: error: for each function it appears in.) make: *** [domdoc.o] Error 1 Looks like that stuff was added in 2.7.0 .
[no subject]
Re: xlive: add initial stub dll (1/3)
On Tue, Nov 2, 2010 at 12:34 PM, Alexandre Julliard julli...@winehq.org wrote: Austin English austinengl...@gmail.com writes: This dll is not a core part of windows (at least, not yet), but I think it should be considered for inclusion in Wine. A bit of explanation is necessary: xlive.dll comes from Games for Windows (1,2), whose installer depends on .Net 3.5 (can be skipped with the /nodotnet parameter). Native fails on wine, however, unless a native msasn1.dll is provided, because xlive.dll is digitally signed (so implementing our own msasn1.dll won't help). As it currently stands, users can't play any 'Game for Windows' that doesn't have a Windows license. That's not a good enough reason, particularly considering how ugly the resulting code is. And it seems unlikely that this is ever going to move beyond the nasty hack stage, given the lack of documentation. Fair enough. You never know until you try and have the code in hand. For those interested, I've put an initial fork at http://github.com/austin987/wine/ . If you've got any games that need xlive, please test against it and report any bugs to me directly or at http://bugs.winehq.org/show_bug.cgi?id=23532. I plan to expand the tests next, to try and get some documentation, so that it can possibly be implemented in the future in a clean way (by someone else, if need be). -- -Austin
Re: Voting for bugs (Was: Re: [Bug 20969])
On Tue, Nov 2, 2010 at 7:23 PM, James Mckenzie jjmckenzi...@earthlink.netwrote: Tom Spear speeddy...@gmail.com wrote: [Message arranged in top to bottom posting order to comply with mailing list rules/guidelines] On Tue, Nov 2, 2010 at 12:01 PM, wine-b...@winehq.org wrote: http://bugs.winehq.org/show_bug.cgi?id=20969 --- Comment #19 from Dmitry Timoshkov dmi...@codeweavers.com 2010-11-02 12:01:23 CDT --- (In reply to comment #18) Those of you with this issue, make sure you vote for this in bugzilla so that it can be confirmed, if you haven't already. Voting for bugs in Wine bugzilla is useless and does nothing except adding noise. Can/should voting for bugs be disabled if it is 'useless and does nothing except adding noise'? Thanks Tom Tom: Voting for bugs does two things, and I don't think Dmitry wants to do the first: 1. It confirms that a bug does exists and possibly on multiple platforms. 2. It advises developers that more than one system/configuration is affected by a bug. I agree that adding thousands of votes to a long standing bug is 'noise'. Given that we have a limited resource of developers, having users verify bugs and to vote for them to give an idea of how severe a bug is might be helpful. Just my .02 USD here. I think that voting for bugs is a great feature, otherwise there would have been many annoying comments like: it happens to me too and what info you can get out of it? Voting helps setting priorities for bugs without nonsense comments. This is my 7 Agorot... James McKenzie
Re: xlive: add initial stub dll (1/3)
Am 02.11.2010 20:46, schrieb Austin English: On Tue, Nov 2, 2010 at 12:34 PM, Alexandre Julliard julli...@winehq.org wrote: Austin English austinengl...@gmail.com writes: This dll is not a core part of windows (at least, not yet), but I think it should be considered for inclusion in Wine. A bit of explanation is necessary: xlive.dll comes from Games for Windows (1,2), whose installer depends on .Net 3.5 (can be skipped with the /nodotnet parameter). Native fails on wine, however, unless a native msasn1.dll is provided, because xlive.dll is digitally signed (so implementing our own msasn1.dll won't help). As it currently stands, users can't play any 'Game for Windows' that doesn't have a Windows license. That's not a good enough reason, particularly considering how ugly the resulting code is. And it seems unlikely that this is ever going to move beyond the nasty hack stage, given the lack of documentation. Fair enough. You never know until you try and have the code in hand. For those interested, I've put an initial fork at http://github.com/austin987/wine/ . If you've got any games that need xlive, please test against it and report any bugs to me directly or at http://bugs.winehq.org/show_bug.cgi?id=23532. I plan to expand the tests next, to try and get some documentation, so that it can possibly be implemented in the future in a clean way (by someone else, if need be). @All: There are already some Projects which reimplement non-windows dlls like e.g. cuda. I totally see the reason to not integrate them into Wine, but maybe we could start a small Project hosting all that stuff at _one_ point and not spread over the www. Maybe my upcoming CE dlls will also fall into that catagory... Then we also could pack the .dll.so's up into one nsis installer, where you can select which subproject you want to install. (Maybe 32-bit and 64-bit? And possibly in some other way also for ARM?) Your opinions? -- Best Regards, André Hentschel
Re: Transparent windows
On 02/11/2010 02:12 πμ, Vincent Povirk wrote: It is probably a layered window, in which case the following functions in user32 are relevant: SetLayeredWindowAttributes, GetLayeredWindowAttributes, UpdateLayeredWindowIndirect, and UpdateLayeredWindow Most of user32 is implemented based on gdi32, wineserver, and winex11.drv. When you see USER_Driver in user32, that indicates a function in winex11.drv. So USER_Driver-pSetLayeredWindowAttributes is really X11DRV_SetLayeredWindowAttributes. Wine requires a compositing window manager to implement layered windows properly. It does not matter whether the window manager provides any 3D effects or uses opengl. Thank you very much for the directions. They certainly put me on the right track. WINEDEBUG=+win does the trick and shows relevant information. My application still displays black instead of transparent. I took the liberty and augment the trace message with the BLENDFUNCTION struct members like this --- a/dlls/user32/win.c +++ b/dlls/user32/win.c @@ -3531,7 +3531,7 @@ BOOL WINAPI UpdateLayeredWindowIndirect( HWND hwnd, const UPDATELAYEREDWINDOWINF } if (info-pblend !(info-dwFlags ULW_OPAQUE)) alpha = info-pblend-SourceConstantAlpha; -TRACE( setting window %p alpha %u\n, hwnd, alpha ); +TRACE( setting window %p alpha %u BlendOp %u, BlendFlags %x SourceConstantAlpha %u AlphaFormat %x \n, hwnd, alpha, info-pblend-BlendOp, info-pblend-BlendFlags, info-pblend-SourceConstantAlpha, info-pblend-AlphaFormat); USER_Driver-pSetLayeredWindowAttributes( hwnd, info-crKey, alpha, info-dwFlags (LWA_ALPHA | LWA_COLORKEY) ); return TRUE; and I got output like this trace:win:UpdateLayeredWindowIndirect setting window 0x10060 alpha 255 BlendOp 0, BlendFlags 0 SourceConstantAlpha 255 AlphaFormat 1 The BLENDFUNCTION structure is documented in MSDN http://msdn.microsoft.com/en-us/library/dd183393%28VS.85%29.aspx and is defined in include/wingdi.h So from MSDN BlendOp = 0 == AC_SRC_OVER (the only option) BlendFlags = 0 (the only option) SourceConstantAlpha = 255 = 0xff AlphaFormat = 1 == AC_SRC_ALPHA (the only option) then the documentation branches depending on if the SourceConstantAlpha is 0xff or not, if there is source alpha if there is destination alpha. Just to be sure I hardcoded another value for SourceConstantAlpha and I did get some kind of transparency but not the right kind :-( Is it possible that wine's implementation has a bug in the alpha blending handling in some subcase? It is late now. I will hunt it down some more tomorrow. .bill
Re: xlive and msasn1.dll
Am 02.11.2010 um 14:37 schrieb Dan Kegel: Austin wrote: xlive.dll comes from Games for Windows ... [and] fails on wine, however, unless a native msasn1.dll is provided, because xlive.dll is digitally signed (so implementing our own msasn1.dll won't help). That's interesting. I wonder what other modules Microsoft is checking signatures on, and whether they're planning on doing that more often in the future. How does this work? Does xlive.dll check the signature of msasn1.dll? Or vice versa?
Re: Use of uninitialized variable in combine_uri()
Hi Gerald,
On Tue, Nov 2, 2010 at 6:51 PM, Gerald Pfeifer ger...@pfeifer.com wrote:
Hi Thomas,
the following change of yours
commit bced2e21dbc548ef9d41e3ff11384d7ad964c929
Author: Thomas Mullaly thomas.mull...@gmail.com
Date: Sat Oct 9 11:02:17 2010 -0400
urlmon: Implemented base case for CoInternetCombineIUri.
introduces a new warning, use of uninitialized variable in the line
marked HERE below.
+static HRESULT combine_uri(Uri *base, Uri *relative, DWORD flags, IUri
**result
+ Uri *ret;
+ HRESULT hr;
+ parse_data data;
+
+ /* Base case is when the relative Uri has a scheme name,
+ * if it does, then 'result' will contain the same data
+ * as the relative Uri.
+ */
+ if(relative-scheme_start -1) {
+ DWORD create_flags = 0;
+
+ memset(data, 0, sizeof(parse_data));
+
+ data.uri = SysAllocString(relative-raw_uri);
+ if(!data.uri) {
+ IUri_Release(URI(ret)); == HERE
+ *result = NULL;
+ return E_OUTOFMEMORY;
+ }
From all I can tell this is a legitimate warning, that is, the code
really invokes undefined behavior. Would you mind having a look?
Gerald
Whoa! Good catch, I'll submit a new patch set here in a few minutes fixing that.
Thank you for the heads up.
--
Thomas Mullaly
thomas.mull...@gmail.com
Re: xlive: add initial stub dll (1/3)
On 11/02/2010 01:34 PM, André Hentschel wrote: Am 02.11.2010 20:46, schrieb Austin English: On Tue, Nov 2, 2010 at 12:34 PM, Alexandre Julliard julli...@winehq.org wrote: Austin English austinengl...@gmail.com writes: This dll is not a core part of windows (at least, not yet), but I think it should be considered for inclusion in Wine. A bit of explanation is necessary: xlive.dll comes from Games for Windows (1,2), whose installer depends on .Net 3.5 (can be skipped with the /nodotnet parameter). Native fails on wine, however, unless a native msasn1.dll is provided, because xlive.dll is digitally signed (so implementing our own msasn1.dll won't help). As it currently stands, users can't play any 'Game for Windows' that doesn't have a Windows license. That's not a good enough reason, particularly considering how ugly the resulting code is. And it seems unlikely that this is ever going to move beyond the nasty hack stage, given the lack of documentation. Fair enough. You never know until you try and have the code in hand. For those interested, I've put an initial fork at http://github.com/austin987/wine/ . If you've got any games that need xlive, please test against it and report any bugs to me directly or at http://bugs.winehq.org/show_bug.cgi?id=23532. I plan to expand the tests next, to try and get some documentation, so that it can possibly be implemented in the future in a clean way (by someone else, if need be). @All: There are already some Projects which reimplement non-windows dlls like e.g. cuda. I totally see the reason to not integrate them into Wine, but maybe we could start a small Project hosting all that stuff at _one_ point and not spread over the www. Maybe my upcoming CE dlls will also fall into that catagory... Then we also could pack the .dll.so's up into one nsis installer, where you can select which subproject you want to install. (Maybe 32-bit and 64-bit? And possibly in some other way also for ARM?) Your opinions? From a usability perspective we're not going to be doing much good unless this happens near-automatically with a typical Wine installation. That means either including them in Wine directly or including hooks to download them when needed (this could also be done in the packaging layer) -Scott Ritchie
