October 2007 - Wine-Devel - list.winehq.org

problem compiling dlls/ntdll/actctx.c

by sol11x86＠comcast.net

haven't built wine in a while, and ran into this on Solaris 10: actctx.c:76: error: `version' defined as wrong kind of tag gmake[2]: *** [actctx.o] Error 1 gmake[2]: Leaving directory `/export/src/wine/100607/wine/dlls/ntdll' gmake[1]: *** [ntdll] Error 2 gmake[1]: Leaving directory `/export/src/wine/100607/wine/dlls' gmake: *** [dlls] Error 2 starting line 74 of actctx.c, I see struct version { USHORT major; USHORT minor; USHORT build; USHORT revision; }; struct assembly_identity { WCHAR *name; WCHAR *arch; WCHAR *public_key; WCHAR *language; WCHAR *type; struct version version; BOOL optional; }; struct entity { DWORD kind; union { struct { WCHAR *tlbid; WCHAR *version; WCHAR *helpdir; } typelib; struct { WCHAR *clsid; } comclass; struct { WCHAR *iid; WCHAR *name; } proxy; struct { WCHAR *name; } class; struct { WCHAR *name; WCHAR *clsid; } clrclass; struct { WCHAR *name; WCHAR *clsid; } clrsurrogate; } u; }; But after some google searches and such, I can't come to a conclusion if it's a clash with a predefined version in a Solaris include file, or a clash with the version in the union which is a WCHAR. Ideas.?

Oct. 7, 2007

Re: PATCH: fix out of range array access in dlls/kernel32/relay16.c

by Gerald Pfeifer

On Wed, 3 Oct 2007, Alexandre Julliard wrote: > This can't happen. If there's no ret instruction in the entry point > we'll have much bigger problems than an out of range access... Fair point, I guess you're right. How about the following patch then? Gerald Index: relay16.c =================================================================== RCS file: /home/wine/wine/dlls/kernel32/relay16.c,v retrieving revision 1.5 diff -u -3 -p -r1.5 relay16.c --- relay16.c 30 Aug 2007 11:21:56 -0000 1.5 +++ relay16.c 6 Oct 2007 23:28:29 -0000 @@ -320,7 +320,9 @@ static int relay_call_from_16_no_debug( for (j = 0; j < sizeof(call->ret)/sizeof(call->ret[0]); j++) if (call->ret[j] == 0xca66 || call->ret[j] == 0xcb66) break; - if (call->ret[j] == 0xcb66) /* cdecl */ + if( j >= sizeof(call->ret)/sizeof(call->ret[0]) ) + ERR("failed to find ret instruction in entry point"); + else if (call->ret[j] == 0xcb66) /* cdecl */ { for (i = 0; i < 20; i++, nb_args++) { @@ -424,7 +426,9 @@ int relay_call_from_16( void *entry_poin for (j = 0; j < sizeof(call->ret)/sizeof(call->ret[0]); j++) if (call->ret[j] == 0xca66 || call->ret[j] == 0xcb66) break; - if (call->ret[j] == 0xcb66) /* cdecl */ + if( j >= sizeof(call->ret)/sizeof(call->ret[0]) ) + ERR("failed to find ret instruction in entry point"); + else if (call->ret[j] == 0xcb66) /* cdecl */ { for (i = 0; i < 20; i++, nb_args++) {

Oct. 6, 2007

Re: Wine 1.0 bugs, release criteria

by Louis Lenders

Ok, here one on my wish-list: All apps that currently fail on wine due to shdocvw/mshtml disfunctionality. Almost all of these apps start fine using ies4linux. I did quite a lot of testing of demo's, and many of them fail because of this (in most cases you just end up with a white screen). Actually i figured out what exact dlls make them fail in wine, and run in ies4linux. I currently use the script below to work around this , and in most cases it works quite fine (native shlwapi and urlmon are probably only needed for dll-dependancy, jscript and msls31 are not implemented by wine) (/sda3/native/ is where i've put my dlls from my windows-partition) unalias cp cp /sda3/native/shdocvw.dll ~/.wine/drive_c/windows/system32/ cp /sda3/native/shlwapi.dll ~/.wine/drive_c/windows/system32/ cp /sda3/native/urlmon.dll ~/.wine/drive_c/windows/system32/ cp /sda3/native/mshtml.dll ~/.wine/drive_c/windows/system32/ cp /sda3/native/mshtml.tlb ~/.wine/drive_c/windows/system32/ cp /sda3/native/jscript.dll ~/.wine/drive_c/windows/system32/ cp /sda3/native/MSLS31.DLL ~/.wine/drive_c/windows/system32/ cp /sda3/native/mlang.dll ~/.wine/drive_c/windows/system32/ regsvr32 jscript (then run the app with native shdocvw, shlwapi,urlmon,mshtml,mlang).

Oct. 6, 2007

Re: [Bug 2680] Wine should report 32bit color depth instead of 24bit

by James Hawkins

On 10/6/07, wine-bugs(a)winehq.org <wine-bugs(a)winehq.org> wrote: > http://bugs.winehq.org/show_bug.cgi?id=2680 > > > Roderick Colenbrander <thunderbird2k(a)gmx.net> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Depends on| |9918 > > > > > --- Comment #14 from Roderick Colenbrander <thunderbird2k(a)gmx.net> 2007-10-06 15:56:29 --- > This appears to be the 'original' bug 9918. I wasn't aware of it but various > bugs have already been attached to 9918. So I'll attach this one to 9918 too. > > bug 9918: GetDeviceCaps BPP should use XVisualInfo which is synonymous with bug 2680: Wine should report 32bit color depth instead of 24bit blocks: * bug 2680: Wine should report 32bit color depth instead of 24bit (DAZ studio) * bug 3319: GetDeviceCaps: BITSPIXEL returning 15 on 15bit graphics (no app) * bug 4278: Splinter Cell: Pandora Tomorrow fails with need 32bit color * bug 4935: IHP Kitchen: Unhandled page fault on read access * bug 5671: qtracker crashes before first screen This is exactly why metabugs are a bad idea. With very few exceptions, Wine's bugzilla bug reports should be about apps only. If any apps fail because of the exact same cause (bug), then the appropriate bugs need to be marked as duplicates of the original bug report. Topics like "Wine should report 32bit color depth instead of 24bit" and "GetDeviceCaps: BITSPIXEL returning 15 on 15bit graphics" are development planning information, and as such this information belongs in the wiki. Unless I'm mistaken, the formerly quoted bugs are all about the fact that Wine returns 24bit color depth instead of 32bit. Why are there at least 6 bug reports about one bug? bug 3319 should be closed as invalid, moving the information to the wiki. bugs 9918, 4278, 4935 and 5671 need to be marked as duplicates of bug 2680. > This appears to be the 'original' bug 9918. I wasn't aware of it but various > bugs have already been attached to 9918. So I'll attach this one to 9918 too. I'm sorry, but that's just really lazy. As of this writing, there are 3218 open bugs in our bugzilla. Countless many of those bugs are invalid or duplicates, so we don't need to knowingly add to the clutter. Make sure you understand the difference between blocker and duplicate. Thanks, James Hawkins

Oct. 6, 2007

WineHQ for Wine 1.0

by Alex Waite

Awhile ago I sent a few patches in to cleanup some HTML and CSS on WineHQ. I didn't continue with writing more patches since it seemed like we didn't have a clear idea of what direction we wanted to pursue. I am more than happy to help with a rewrite or update of the site, but as long as we have an plan of what we want to accomplish and how to go about it. With the release of Wine 1.0 coming... sometime... in the future, it would make sense if we had an updated website to accompany that release. From my point of view, the following are some big problems with the current site: * Not pretty: while not awful, there are better color schemes and layouts in the world. We can also look at some usability improvements. If people are partial to it, we can still use the winish-red color, but I think we can use it in a more attractive way than we do now. * Table-hell: This is where I tout the joys of <div>'s and CSS. Tables are a pain to deal with and bloat the code quite a bit. Not to mention that they make pages pretty inaccessible. * Accessibility: Tables are the big culprit here, but there's also simple things like making the code valid. There's also some fairly straightforward ways of writing code which help a lot (precede lists with headers, nest headers correctly, etc). While accessibility doesn't have to be perfect, I think it promotes well written code and makes pages more accessible to more people. * Valid code: This is a principal to me. I think if code is to be written, it should be written correctly. Wine is known for not accepting hacks or improper fixes; I think our website should reflect that, especially since the spec is not hard to conform to. Let me know if you are interested in help. I hope everyone is having fun at WineConf. ---Alex

Oct. 6, 2007

Re: make test drill

by Paul Vriens

Jeremy White wrote: > So, in a radical break from tradition, we're trying to > accomplish something useful at Wineconf. > > Specifically, we're making 'make test' work for everyone, > not just Alexandre. > > Maarten Lankhorst is maintaining a tree of all of our > test related patches. > > So, for those that want to play, the thing to do is to > git fetch git://repo.or.cz/wine/testsucceed.git master:testsucceed > git rebase testsucceed > > Then you can do a make test (with a clean .wine directory) > and share your results. It's useful to use Dan's filter: > egrep '__test|make.*ok|Backtrace' <your-log-file-here> > > Up through the end of day tomorrow, you can send me the results > of that egrep and I'll tally and triage. > > If you have a patch, send it in, and CC Maarten so he can > update it. > > The goal is to have the number of failures as close to 0 > as possible, and for the non 0 cases, to at least understand > each failure. > > Cheers, > > Jeremy > > > > > Hi, It's nice to fix all the test failures when running them in Wine. We however have several tests that still fail on Windows so how can we be sure the test results in Wine are correct? Some that are failing on a lot of Windows boxes: advpack:advpack advpack:files comctl32:monthcal crypt32:encode gdi32:font kernel32:actctx kernel32:process usp10:usp10 wintrust:softpub I've just picked some that fail on different versions of Windows. There are also several tests that consistently fail on a particular version of Windows. -- Cheers, Paul.

Oct. 6, 2007

Re: Wine 1.0 bugs, release criteria

by Evil Jay

http://bugs.winehq.org/show_bug.cgi?id=6155 also holds up quite a few apps (some listed at http://wiki.winehq.org/IoCompletionPorts) Fixing it would make Wine feel a lot more 1.0ish to me. -J, Klaus Layer wrote: > On Saturday 06 October 2007 13:41:43 Dan Kegel wrote: > >> At Wineconf 2007, I was appointed to be the guy who decides >> (with Alexandre's approval) what bugs are 1.0 bugs and what aren't. >> So I've started adjusting the "Target Release" fields on a few >> bugs in Bugzilla. >> Over the next month or so, I'd like Wine developers to nominate important >> bugs for 1.0 by setting their "target release" field to 1.0. Later on we'll >> clean up and freeze the list somehow. >> >> Also, I've put together a draft wiki page with our 1.0 release criteria; >> > it's at > >> http://wiki.winehq.org/WineReleaseCriteria >> >> Comments? >> - Dan >> >> >> > > Hi Dan, > > can you please consider http://bugs.winehq.org/show_bug.cgi?id=9484 for 1.0. > > Thanks, > > Klaus > > > > ------------------------------------------------------------------------ > > >

Oct. 6, 2007

make test drill

by Jeremy White

So, in a radical break from tradition, we're trying to accomplish something useful at Wineconf. Specifically, we're making 'make test' work for everyone, not just Alexandre. Maarten Lankhorst is maintaining a tree of all of our test related patches. So, for those that want to play, the thing to do is to git fetch git://repo.or.cz/wine/testsucceed.git master:testsucceed git rebase testsucceed Then you can do a make test (with a clean .wine directory) and share your results. It's useful to use Dan's filter: egrep '__test|make.*ok|Backtrace' <your-log-file-here> Up through the end of day tomorrow, you can send me the results of that egrep and I'll tally and triage. If you have a patch, send it in, and CC Maarten so he can update it. The goal is to have the number of failures as close to 0 as possible, and for the non 0 cases, to at least understand each failure. Cheers, Jeremy

Oct. 6, 2007

Re: [PATCH] HTMLDocument adjust error handling

by Jacek Caban

Hi Marcus, Marcus Meissner wrote: > Hi, > > sometime we have failure cases where we > still return S_OK. > > I am not sure this is a good idea. > NULL is a valid return value of these function, so it's fine to return S_OK here (also you've changed non-error code paths). Thanks, Jacek

Oct. 6, 2007

Re: Wine 1.0 bugs, release criteria

by Dan Kegel

On 10/6/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > > http://wiki.winehq.org/WineReleaseCriteria > > Can find get a timeline for the feature freeze and the 1.0 release? As the wiki page says, we hope to have a "final" list of bugs by the end of the year. There have been some murmurings about trying to do the release by June, but they're just rumors. > Also are we going to have a stable branch and a development branch > post 1.0? That way I can know the window for merging the DIB engine. > It'll likely be post 1.0 because I'm too busy in school at the moment. > It doesn't need to be a 1.0 bug because it only affects performance > mainly. Yeah, I think post 1.0 is fine. We can call it 1.1 for now.

Oct. 6, 2007