February 2009 - Wine-Devel - list.winehq.org

Re: Wine64 : Trying to load PE image for unsupported architecture (I386)

by Ben Klein

2009/2/12 Joel Holdsworth <joel(a)airwebreathe.org.uk>: > On Wed, 2009-02-11 at 23:34 +0100, Alexandre Julliard wrote: >> Not really, you'll of course still need to build a full 32-bit version >> of Wine, the 64-bit Wine will never be able to run 32-bit apps. What >> needs to be improved is that the 64-bit loader should be able to forward >> automatically to the 32-bit one when encountering a 32-bit app. > > So there's no plans for implementing a clone of WoW64? > I would imagine that the end goal is to implement a side-by-side 64bit and 32bit wine, with some sort of wrapper to send the app to the appropriate version. From what I understand, this is what a WoW64 clone would look like anyway. See David's comment: 2009/2/12 David Gerard <dgerard(a)gmail.com>: > 2009/2/11 Erik de Castro Lopo <mle+win(a)mega-nerd.com>: > >> I realise that the Win64 stuff is experimental but I'm curions, in >> the longer term is it expected that one executable will be able to >> run both Win32 and Win64 executables? > > Not yet. You're welcome to write it though ;-)

Feb. 12, 2009

Re: Wine64 : Trying to load PE image for unsupported architecture (I386)

by Alexandre Julliard

Erik de Castro Lopo <mle+win(a)mega-nerd.com> writes: > So there will need to be two executables wine and wine64 and if either is > started with the wrong kind of binary, it will need to run the binary with > the other version? > > Would it not be possible to have a single light weight binary that has just > enough code to detect i386 vs amd64 and then execs either wine32 or wine64? sure, that would be possible. I don't know yet how it will be done, but that's a minor implementation detail. -- Alexandre Julliard julliard(a)winehq.org

Feb. 12, 2009

Re: Wine64 : Trying to load PE image for unsupported architecture (I386)

by Joel Holdsworth

On Wed, 2009-02-11 at 23:34 +0100, Alexandre Julliard wrote: > Not really, you'll of course still need to build a full 32-bit version > of Wine, the 64-bit Wine will never be able to run 32-bit apps. What > needs to be improved is that the 64-bit loader should be able to forward > automatically to the 32-bit one when encountering a 32-bit app. So there's no plans for implementing a clone of WoW64?

Feb. 12, 2009

ntdll: Avoid Potential Infinite Loop

by Paul Bryan Roberts

Hi, I expect this patch will be accepted due to precedent - a few months ago I submitted the same patch for the same problem in a different routine in a different compilation unit of ntdll. Yes, I guess the infinite loop does not occur in practice (someone would have noticed) and I guess it has been there a very long time. But it isn't exactly hard to spot - I was speed reading the code looking for something else. I've seen a lot of chatter recently about something called Coverity. I looked it up on Wikipedia (after checking the spelling). Apart from it's obvious use as a conversation piece, is it proving useful to the project ? Is there a feedback policy ? Something like "We think your product is superlative .... but someone may wonder if your code not finding this bug in our code might be a bug in your code." Security :); false sense of security :( Paul Bryan Roberts >From dd2f31b0176e795edf5b1eb081410de7ed5ed03d Mon Sep 17 00:00:00 2001 From: Paul Bryan Roberts <pbronline-wine(a)yahoo.co.uk> Date: Thu, 12 Feb 2009 08:09:17 +0000 Subject: ntdll: avoid potential infinite loop --- dlls/ntdll/nt.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/dlls/ntdll/nt.c b/dlls/ntdll/nt.c index 879a324..dc81648 100644 --- a/dlls/ntdll/nt.c +++ b/dlls/ntdll/nt.c @@ -293,17 +293,20 @@ NTSTATUS WINAPI NtQueryInformationToken( char stack_buffer[256]; unsigned int server_buf_len = sizeof(stack_buffer); void *buffer = stack_buffer; - BOOLEAN need_more_memory = FALSE; + BOOLEAN need_more_memory; /* we cannot work out the size of the server buffer required for the * input size, since there are two factors affecting how much can be * stored in the buffer - number of groups and lengths of sids */ do { + need_more_memory = FALSE; + SERVER_START_REQ( get_token_groups ) { TOKEN_GROUPS *groups = tokeninfo; + req->handle = wine_server_obj_handle( token ); wine_server_set_reply( req, buffer, server_buf_len ); status = wine_server_call( req ); -- 1.5.4.3

Feb. 12, 2009

Re: wintrust(3/3): Fix a couple tests on a variety of systems

by Paul Vriens

Juan Lang wrote: > --Juan > > > ------------------------------------------------------------------------ > > This is of course on boxes where people dont' run winetest as a administrator. I'm not sure if ERROR_ACCESS_DENIED is thus actually an acceptable failure. In other tests we have used skip() for this. -- Cheers, Paul.

Feb. 12, 2009

Re: Is the test.winehq.org front page too pessimistic?

by Paul Vriens

Juan Lang wrote: > The front page of test.winehq.org shows statistics about failed tests, > but it doesn't seem to take into account the number of individual > tests that passed and failed, rather the number of files that had any > failures. > > So, for example, about a week ago I got a fix committed for some > failing mapi32 tests. Looking at the machines with test failures, > before the fix was committed, 139 tests were run, with 134 of them > failing, whereas after the fix was committed, the same number of tests > were run, with only 6 of them failing. Nonetheless, the 4th of > February shows a higher failure rate (14.6%) than the 3rd of February > (12.4%). > > I know other tests could have started failing in the interim, but it > seems like we've been putting a fair amount of effort into reducing > test failures lately, while the percent of failed tests isn't going > down, at least not on the main page. If you look at a particular > day's results, the numbers look a bit better over time. > > I'm not sending a patch, because there may be different opinions on > this. That is, perhaps some people like to see a statistic on the > number of files with failing tests on any machine, which the front > page appears to show, while others may like to see the number of > failures in a particular file, which a day's results show. My own > opinion is that it's hard to get motivated to fix something without > some sort of positive feedback for it, so changing the front page > would be better. > > My own feeling is that there are far fewer failing tests now than > there used to be, and I'd sure like to see that reflected somewhere at > a quick glance. Thoughts? > --Juan > > > I don't think that showing individual tests (the actual counts inside dll:name) will help as the error rate will be marginal (as pointed out by AJ). If you look at the main page you will see a number for Win95 for example. This number shows you how many dll:name tests had a failure on one or more Win95 boxes. This means that 1 box can mess up the platforms stats quite badly. If I have 10 Win95 boxes with no failures and one with all dll:name tests failing, the failure rate for that platform would be equal to the total number of tests (dll:name again). The cumulative number 'Failures' however is a differently calculated number. It's just an adding of 'overall platform failures' for each platform divided by 'different platforms on that line on the main page' x 'total number of unique dll:name tests'. So maybe (and it's been discussed in the past) the 'Failures' number should be the number of unique tests (dll:name) that fail on one or more boxes (just like the platform ones but than overall). That way we get an indication how many dll:name tests need some fixing. It will however won't do any good to our figures. My 6 boxes for example show 5.0% failure on the main page but using this other approach it would have been 14.7%. So I don't think our numbers are too pessimistic. We are bitten by the fact that more and more people run winetest and that raises the possibility of failing tests of course (non-administrator, different locales, no C-drive .....). -- Cheers, Paul.

Feb. 12, 2009

Fwd: Need Your Help about "dll" on linux

by Jigar Joshi

---------- Forwarded message ---------- From: Jigar Joshi <jigarjm(a)gmail.com> Date: Mon, Feb 9, 2009 at 6:53 PM Subject: Need Your Help about "dll" on linux To: wine-devel(a)winehq.org Respected sir, i refered your post at http://www.winehq.org/pipermail/wine-devel/2007-April/055855.html i want to know have you completed successfully that project? (using dll on linux) please reply soon . actually i have dlls derived from c , i dont have c code and i need to use those dlls on linus using java (JNI), first i tried to convert dll to ".so" bt i couldn't. . . read your post and got some moral support please reply soon . . . Regards Jigar

Feb. 12, 2009

Re: Error on CVS server: no space left on device

by Jeremy Newman

Yep, the web server ran out of disk space. We are working on clearing things out a bit. Seems test.winehq.org is taking much more disk than we expected. Seems a hardware upgrade needs to be pushed out pretty darn soon. -Newman Paul Chitescu wrote: > Hi! > > The CVS server cvs.winehq.org is out of disk space: > > $ cvs -z3 -q up -APd > can't create temporary directory /tmp/cvs-serv29410 > No space left on device > > Message is received from remote server. > > Anyone able to fix it? > > Regards, > > Paul Chitescu > >

Feb. 12, 2009

Re: itss: Replace malloc() with HeapAlloc()

by Francois Gouget

On Wed, 11 Feb 2009, Vitaliy Margolen wrote: [...] > Don't forget few places with strdup: Yes I've seen them too :-( Should we ban it too? What's the proper replacement? StrDupA() is only exported by slwapi.dll which means it's not a good choice... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Feb. 12, 2009

Re: itss: Replace malloc() with HeapAlloc()

by Vitaliy Margolen

Francois Gouget wrote: > On Tue, 10 Feb 2009, Andrew Talbot wrote: > [...] >> There are also many calls to realloc() - a function with complexities of its >> own - and other functions with "realloc" in their name. > > Good point. Here are the ones I noticed: > > dlls/rsaenh/mpi.c:3668: if ((tmp = realloc (a->dp, sizeof (mp_digit) * a->used)) == NULL) { > dlls/rsaenh/mpi.c:72: tmp = realloc (a->dp, sizeof (mp_digit) * size); > dlls/twain_32/dsm_ctrl.c:87: devices = realloc(devices, sizeof(devices[0])*(nrdevices+1)); > > dlls/advapi32/tests/registry.c:55: if ((ret = realloc( list[idx], size ))) list[idx] = ret; > dlls/ddraw/tests/ddrawmodes.c:97: modes = realloc(modes, (modes_size *= 2) * sizeof(DDSURFACEDESC)); > dlls/mstask/tests/task.c:41: if ((ret = realloc(list[idx], size))) > dlls/oleaut32/tests/tmarshal.c:59: if ((ret = realloc( list[idx], size ))) list[idx] = ret; > dlls/userenv/tests/userenv.c:54: if ((ret = realloc( list[idx], size ))) list[idx] = ret; > > And we even have two calls to calloc()! > dlls/winedos/int33.c:267: MCALLDATA *data = calloc(1,sizeof(MCALLDATA)); > dlls/winedos/devices.c:137: hdr_ptr = calloc(1,sizeof(void *)+extra); > > > Don't forget few places with strdup: dlls/gphoto2.ds/gphoto2_main.c:70: gpfile->folder = strdup(folder); dlls/gphoto2.ds/gphoto2_main.c:71: gpfile->filename = strdup(name); dlls/twain_32/dsm_ctrl.c:90: devices[nrdevices].modname = strdup(dsname); dlls/wineps.drv/mkagl.c:141: glyphs[num_glyphs].name = strdup(namebuf); dlls/wineps.drv/mkagl.c:142: glyphs[num_glyphs].comment = strdup(commbuf); dlls/wineps.drv/mkagl.c:280: glyphs[num_glyphs].name = strdup(namebuf); dlls/wineps.drv/mkagl.c:281: glyphs[num_glyphs].comment = strdup(linebuf); dlls/winex11.drv/opengl.c:320: WineGLInfo.glExtensions = strdup((const char *) pglGetString(GL_EXTENSIONS)); Vitaliy.

Feb. 12, 2009