January 2005 - Wine-Devel - list.winehq.org

Re: ole:register_ifstub couldn't get IPSFactory buffer for interface

by Mike Hearn

On Sat, 2005-01-29 at 13:16 -0600, Rob Shearman wrote: > InstallShield uses MIDL-compiled proxies/stubs. The fixme's are from > functions being executed on the error path, triggered by the pipe > problem. Hmm, did we remove the 1 || hack while I wasn't watching? I thought we were going to wait a bit before letting it use its own compiled marshallers instead of the typelib marshaller. thanks -mike

Jan. 29, 2005

Re: MSVCRT: Re-implement *printf

by Aneurin Price

Jesse Allen wrote: >>Sorry for being late at responding. I took a look at it finally like >>a week ago. You can definately break up the patch. >> >> > >Erm, nevermind on breaking it up yet. I started to myself, but I >think it's more trouble than it's worth right now. We can have that >done later if that is what is wanted to have it accepted. > >I had another idea to help testing. I added a comparison test in >_vsnprintf to go ahead and see if there is any difference between libc >and wine by calling libc's version. If there is a difference, it will >print a warning. Here's an obvious example in action while running >War3: > > <snip> Cool, that's a good idea. I was holding off on responding to the other 2 posts until I'd come up with a meaningful response, but it's probably better to acknowledge them :). In response to Juan's comments then: 1. Already done :). I had several test cases (including one for the example you give) committed some time ago. 2. Well I can certainly give it some thought, though I'm not sure yet how I'd want to do it. This is the part that made me want to wait before responding, since I don't have anything actually useful to add yet. Anyway, I'm not ignoring you, and will respond decently when I've found the time to play with this a bit :). Thanks for the input.

Jan. 29, 2005

Q? system wide variables

by Oliver Stieber

Hi, I need to track the 'fake' amount of video memory in total, allocated and left for Directx 9 and would like to track it across wine so that DDraw, DirectX, DxDiag and X11 driver can all sing from the same song sheet. What's the best place to do this? is the registry code fast enough or should I add a new function to the X11 driver so that I can request and release 'fake' video memory and make all other AvailableVideoMemory requests ask X11 driver? I would expect the use to be able to override by the initial amount, even if there's code that detects it since wine,X and openGL manage video memory differently to windows, direct draw and D3D. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

Jan. 29, 2005

Re: ole:register_ifstub couldn't get IPSFactory buffer for interface

by Rob Shearman

Mike Hearn wrote: >On Sat, 29 Jan 2005 18:35:17 +0100, Uwe Bonnes wrote: > > >>Now I get: >>... >>fixme:ole:RegisterTypeLib Registering non-oleautomation interface! >>fixme:ole:PipeBuf_GetDestCtx (0x752a8f9c,0x752a8fa0), stub! >>fixme:ole:RPC_QueueRequestAndWait no pipe found. >>fixme:ole:NdrClearOutParameters (0x752a8f28,0x751a4212,0x752a905c): stub >>fixme:ole:NdrProxyErrorHandler (0x80004003): semi-stub >>fixme:ole:PipeBuf_GetDestCtx (0x752a8f98,0x752a8f9c), stub! >>fixme:ole:RPC_QueueRequestAndWait no pipe found. >>fixme:ole:NdrClearOutParameters (0x752a8f24,0x751a422e,0x75ba1ed0): stub >>fixme:ole:NdrProxyErrorHandler (0x80004003): semi-stub >>fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from >>0x4003 -> 0x8) 7627601c >>fixme:ole:RPC_QueueRequestAndWait no pipe found. >>err:ole:ifproxy_release_public_refs IRemUnknown_RemRelease failed with error >>0x80004003 >> >> > >Are you using any native DLLs? Those Ndr* calls aren't being produced by >Wine, that's for sure ... > > InstallShield uses MIDL-compiled proxies/stubs. The fixme's are from functions being executed on the error path, triggered by the pipe problem. Rob

Jan. 29, 2005

Xnews regression from update region handling

by Rein Klazes

Alexandre, After the update region handling moved to the server, Xnews gets in an endless loop when the windows with news groups is scrolled. The endless loop is in user/painting.c. Calling sequence is ScrollWindowEx(... SW_ERASE|SW_INVALIDATE)-> RedrawWindow(..., RDW_INVALIDATE|RDW_ERASE|RDW_ERASENOW)-> erase_now() In erase_now() the aptly coded endless loop is never broken out, and loops on the same window over and over. Before the change this was coded quite differently (traversing the window's child tree) and could not loop indefinitely. I am quite stuck what should be the reason why the loop is expected to end in the first place. Perhaps you want to have a look. Xnews can be downloaded from all over the net, for example: http://xnews.newsguy.com/release/xnews.zip Unzip it in a directory of your choice; run xnews.exe; enter the host name of a news server; confirm that you want to download the list of newsgroups; you get a window with newsgroups, try to scroll down the list. Rein.

Jan. 29, 2005

Re: MSVCRT: Re-implement *printf

by Jesse Allen

On Fri, 28 Jan 2005 18:18:40 -0700, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > On Fri, 28 Jan 2005 12:48:12 +0000, Aneurin Price > > > > Nobody has any comments about this? > > > > > > Sorry for being late at responding. I took a look at it finally like > a week ago. You can definately break up the patch. Erm, nevermind on breaking it up yet. I started to myself, but I think it's more trouble than it's worth right now. We can have that done later if that is what is wanted to have it accepted. I had another idea to help testing. I added a comparison test in _vsnprintf to go ahead and see if there is any difference between libc and wine by calling libc's version. If there is a difference, it will print a warning. Here's an obvious example in action while running War3: warn:msvcrt:_vsnprintf -- vsnprintf's differ -- warn:msvcrt:_vsnprintf Wine (20): "-4035225266123964415" warn:msvcrt:_vsnprintf libc (64): " 1" warn:msvcrt:_vsnprintf format string: "%I64d" If we took a look at this, we would find that there is no bug in the difference, and actually the improvement over libc's version that we are expecting. So this warning can be discarded. If we found another warning, the difference may definately be a bug, and then it can be fixed when analyzed. We could also add a conformance test to make sure it is fixed and doesn't happen again. Of course this method doesn't help with crashing bugs. And it makes vsnprintf *2 slower, but it doesn't matter when we are testing it. I have a diff below which is against wine CVS + your printf patch. Jesse --- wine/dlls/msvcrt/printf.c 2005-01-29 11:21:54.000000000 -0700 +++ wine-printf/dlls/msvcrt/printf.c 2005-01-29 11:07:23.000000000 -0700 @@ -1134,6 +1134,8 @@ */ int _vsnprintf(char *buffer, size_t count, const char *format, va_list argptr) { + char *compare; + va_list argptrcpy = argptr; /* Since the meaning of type specifiers %S and %s (and C/c) invert * depending on whether the function called is *wprintf or *printf, * this doesn't simply convert to wide, call _vsnwprintf, and @@ -1196,6 +1198,19 @@ WideCharToMultiByte(CP_ACP, 0, out, -1, buffer, count + 1, NULL, NULL); HeapFree(GetProcessHeap(), 0, out); HeapFree(GetProcessHeap(), 0, in); + + compare = HeapAlloc(GetProcessHeap(),0,count+1); + if (compare != NULL) { + int comparePrinted = vsnprintf(compare, count, format, argptrcpy); + if (strncmp(compare, buffer, count)!=0) { + WARN("-- vsnprintf's differ --\n"); + WARN("Wine (%d): \"%s\"\n", charsPrinted, buffer); + WARN("libc (%d): \"%s\"\n", comparePrinted, compare); + WARN("format string: \"%s\"\n", format); + } + HeapFree(GetProcessHeap(), 0, compare); + } + return charsPrinted; }

Jan. 29, 2005

Re: [shlwapi/tests/shreg] Tests question

by Juan Lang

Hi Paul, --- Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > I will give it a try. Is it OK to submit patches to the tests first > (with todo_wine maybe) before I get into the fixing of Wine? Yep, with todo_wine is fine. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

Jan. 29, 2005

Re: [shlwapi/tests/shreg] Tests question

by Paul Vriens

On Sat, 2005-01-29 at 18:29, Juan Lang wrote: > > What's the best approach in this? > > - fix Wine (but what should be the correct returned buffer?) > > Definitely fix Wine. Hopefully there isn't an app that depends on one > behavior under Windows 98, and a different one under Windows XP. It's > perhaps less likely because Wine's implementation isn't correct in either > case? Pick one of the versions to match, document the difference with > other versions. > > If needed later someone can change the function to check at runtime which > version of Windows is being emulated, and match the behavior accordingly. > See e.g. > http://source.winehq.org/source/dlls/kernel/process.c#L2800 > for where this is done. > > --Juan > I will give it a try. Is it OK to submit patches to the tests first (with todo_wine maybe) before I get into the fixing of Wine? The major reasoning behind this is to get more test output from different systems. I've tested it on 6 or so but there's a lot more out there. Paul.

Jan. 29, 2005

Re: Recruit regression testers?

by Carlos Lozano

El lun, 24 de ene de 2005, a las 10:39, Lionel Ulmer escribio: > > Lionel, meanwhile, needs to digup his fallout CDs to debug the app :) > > Oh well, it's not exactly my CD that I need to find (I actually have a log > showing the problem done with the Fallout installer on my CD), it's just > that I need to find the time to do it. It is the line what did the regression. Regards, Carlos. -- ___ _ \ | / Consulting | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.ePSXe.com

Jan. 29, 2005

Re: ole:register_ifstub couldn't get IPSFactory buffer for interface

by Mike Hearn

On Sat, 29 Jan 2005 18:35:17 +0100, Uwe Bonnes wrote: > Now I get: > ... > fixme:ole:RegisterTypeLib Registering non-oleautomation interface! > fixme:ole:PipeBuf_GetDestCtx (0x752a8f9c,0x752a8fa0), stub! > fixme:ole:RPC_QueueRequestAndWait no pipe found. > fixme:ole:NdrClearOutParameters (0x752a8f28,0x751a4212,0x752a905c): stub > fixme:ole:NdrProxyErrorHandler (0x80004003): semi-stub > fixme:ole:PipeBuf_GetDestCtx (0x752a8f98,0x752a8f9c), stub! > fixme:ole:RPC_QueueRequestAndWait no pipe found. > fixme:ole:NdrClearOutParameters (0x752a8f24,0x751a422e,0x75ba1ed0): stub > fixme:ole:NdrProxyErrorHandler (0x80004003): semi-stub > fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from > 0x4003 -> 0x8) 7627601c > fixme:ole:RPC_QueueRequestAndWait no pipe found. > err:ole:ifproxy_release_public_refs IRemUnknown_RemRelease failed with error > 0x80004003 Are you using any native DLLs? Those Ndr* calls aren't being produced by Wine, that's for sure ... Anyway, the "no pipe found" error is known, I will post a patch soon that fixes it (but breaks InstallShield in other ways). It'll be a few days, maybe a week before it's back up and running, sorry. thanks -mike

Jan. 29, 2005