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

Re: [1/3] comctl32: Do not call parent of tool window for tip text
by Ann & Jason Edmeades Oct. 29, 2007

Oct. 29, 2007

> Sending message to parent in tooltip code > probably simply works around toolbar's broken behavior. In this case I think > I've identified a line in toolbar.c that fails to properly detect empty string > causing not appearing tooltips in Radmin. I'll try to submit another patch with > this fix shortly. Thanks for checking this out - If your new patch makes tooltips work, I should probably be quiet... But.. I was looking through my notes of when I was working on this bug, looking at SPY++ logs from windows and comparing them with +spy,+message,+msg etc logs from wine. My notes indicated I was seeing the following sequence (I have hwnds or whatever spy logs written down): Tooltip sends toolbar needtextW Sends to base class tbn_GetInfoTipA which didn't return anything Sends tbn_GetInfoTipA to its parent which didn't return anything Tooltip sends baseclass ttn NeedTextA Which forwards to parent as ttn NeedTextA My notes and investigations could be wrong, does this tie up with what you were seing? Jason

2 1

Misplaced Property Sheet buttons
by Peter Åstrand Oct. 29, 2007

Oct. 29, 2007

I'm debugging a problem where the standard buttons on a property sheet are misplaced. The application is Magna Cura. The screenshot http://www.cendio.com/~astrand/wine/62-tab-size/unpatched.png demonstrates the problem: The buttons are only partially visible. It turns out that the parent window for the Buttons changes size several times. The height is: 228 95 466 436 450 The PROPSHEET_AdjustButtons function, however, is only called in WM_INITDIALOG, so the buttons are positioned based on the height 466, and never repositioned. What's the proper fix for this? I've tried this patch: --- propsheet.c (revision 13243) +++ propsheet.c (arbetskopia) @@ -3828,6 +3828,13 @@ return TRUE; } + case WM_WINDOWPOSCHANGED: + { + PropSheetInfo* psInfo = (PropSheetInfo*) lParam; + PROPSHEET_AdjustButtons(hwnd, psInfo); + return FALSE; + } + default: return FALSE; } This solves the position problem, but instead the Help button disappears. See screenshot http://www.cendio.com/~astrand/wine/62-tab-size/patched.png. Any ideas? Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00 ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping. Program och anmälan: http://www.thinlincusergroup.se/aktiviteter

2 2

Re: [1/3] comctl32: Do not call parent of tool window for tip text
by Ann & Jason Edmeades Oct. 29, 2007

Oct. 29, 2007

Hi Alexander, > In the process of debugging I > also determined that Windows doesn't seem to send this message to > parent at all (tested on win98-Qemu, winXP SP2-Qemu and winXP SP1 > normal installation). So I'm deleting this second call altogether and > a conformance test for this situation will be included in the next > patch. > Under some circumstances, it must - see bug 9233 (and my patch at url below) http://www.winehq.org/pipermail/wine-patches/2007-August/042660.html http://www.winehq.org/pipermail/wine-cvs/2007-August/035236.html I debugged this through to the point where the parent was definitely retrieving the information (I watched spy logs of the application in question) and I believe reversing this patch will break radmin again... It's a free download, can you please test you havent regressed that application with the patch Jason

2 1

re: RICHED20: fix test crash on WinXP-SP2
by Dan Kegel Oct. 29, 2007

Oct. 29, 2007

Alex Lasso wrote: > First of several patches to make riched20 tests actually pass on Windows. Without your patch, "make test" crashes for me on Wine. Your patch fixes the crash. So this isn't just a problem on Windows, thanks for fixing it! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: tools/widl/typegen.c pointer initialization
by Dan Hipschman Oct. 29, 2007

Oct. 29, 2007

On Sun, Oct 28, 2007 at 01:51:34PM +0100, Gerald Pfeifer wrote: > In tools/widl/typegen.c we have the following snippet > > static void write_user_tfs(FILE *file, type_t *type, unsigned int *tafsoff) > { > unsigned int start, absoff, flags; > unsigned int align = 0, ualign = 0; > const char *name; > type_t *utype = get_user_type(type, &name); > > which passes name to get_user_type without initializing it. get_user_type > in return has the following piece of code: > > static type_t *get_user_type(const type_t *t, const char **pname) > { > for (;;) > { > type_t *ut = get_attrp(t->attrs, ATTR_WIREMARSHAL); > if (ut) > { > if (pname) > *pname = t->name; > return ut; > } > > It is unclear to this reader (and various versions of GCC I tested), > whether we don't really use *name (*pname) uninitialized here. Now > it is possible that through some of the, hmm, tricky logic in these > two functions combined with some environmental guarantees it happens > that we don't, but it seems better to be proactive here. The logic is as follows: We wouldn't be in write_user_tfs if the predicate is_user_type wasn't true for that type, which means *pname (name) will always be initialized since it gets set precisely when get_user_type returns non-NULL (which is the is_user_type test). I don't think initializing it to NULL is helpful since it would crash just the same as if it weren't initialized. name *must* have a valid (non-NULL) value. This may silence a warning, but it's making the logic of the code more confusing by setting the variable to a value that doesn't make any sense in that context. get_user_type is the initialization. Better than this would be to put "assert(is_user_type(type));" above the initializations to convince the programmer at least that name will get initialized correctly in get_user_type. If that doesn't convince the compiler then I don't think it's worth it to try to placate it since we're supposed to be wrting code for humans, not computers. Some projects use a macro like "name IF_LINT(= NULL);" to quiet warnings while informing the reader that the initialization is not necessary. I suppose that's slightly better as well. I think the real problem is that the code is just not clear enough. I've been meaning to add asserts. Where asserts are impractical: comments.

2 2

Re: [PATCH] Currently the serial code interprets
by Juan Lang Oct. 29, 2007

Oct. 29, 2007

Hi Tom, > Content-Type: text/x-patch; name=0001-XONXOFF-reversion.patch > Content-Transfer-Encoding: base64 Apparently gmail's encoding .patch files as base64. It should be text/plain. Please try renaming it to, e.g., 0001-XONXOFF-reversion.diff and try again. --Juan

1 0

Pegasus Mail: program closes when sub-program closes
by Joel Barnett Oct. 28, 2007

Oct. 28, 2007

Sent to bugzilla, and to this email addy, as per winehq instructions: http://www.pmail.com/downloads_maine_t.htm Version to look at is 4.41, a free download. This email app does a normal shutdown whenever the editor is closed, e.g., after a new email is sent. This is not normal behaviour. In Windows the app stays open, so that one can continue sending, receiving, reading, writing email, etc. In old versions of wine, this error doesn't happen, (ver. 20050830). The regression error occurs as early as 0.9.20. Based on posts to the wine appdb for this app, it is likely that the regression error ocurred >=0.9.14. The editor in Pmail was not written by the developer and maintainer, David Harris, but rather licensed by him. Recent wine code seems to interpret an ordinary call to close the editor as a call to close the program itself. When Pmail starts, a 0 byte file, mailbox.lck is created in the mail box of the user. When the user closes the program normally, this file is deleted. Since the shutdown regression error deletes the lock file, I conclude the call to close the editor is being misinterpreted by wine as a call to shutdown Pmail. Joel Barnett New super maintainer for Pegasus Mail p.s. - I'm new at this, please forgive me if my report is funky. I did check bugzilla and didn't find anything relevant.

1 0

Re: ddraw: allow explicit backbuffer
by Stefan Dösinger Oct. 28, 2007

Oct. 28, 2007

Am Sonntag, 28. Oktober 2007 01:18:53 schrieb EA Durbin: > based on patch by Jaroslav Reznik, this fixes bug 9008 and allows the game > combat pillows to launch There is a test in the ddraw tests that shows that this is not allowed. This test will break I guess. However, maybe it is a version differece. The test tests IDirectDraw7 I think, maybe the game uses an older version.

2 1

Re: ddraw: allow explicit backbuffer
by Marcus Meissner Oct. 28, 2007

Oct. 28, 2007

On Sat, Oct 27, 2007 at 06:18:53PM -0500, EA Durbin wrote: > > based on patch by Jaroslav Reznik, this fixes bug 9008 and allows the game combat pillows to launch > > _________________________________________________________________ > Climb to the top of the charts! Play Star Shuffle: the word scramble challenge with star power. > http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct > From d6c94c504f555f773c2c90d7fcbd4bf3500fe490 Mon Sep 17 00:00:00 2001 > From: EA Durbin <ead1234(a)hotmail.com> > Date: Sat, 27 Oct 2007 18:16:27 -0500 > Subject: ddraw: allow explicit backbuffer, based on a patch by Jaroslav Reznik > > --- > dlls/ddraw/ddraw.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c > index 7785624..a84fc36 100644 > --- a/dlls/ddraw/ddraw.c > +++ b/dlls/ddraw/ddraw.c > @@ -2283,7 +2283,7 @@ IDirectDrawImpl_CreateSurface(IDirectDraw7 *iface, > return DDERR_NOEXCLUSIVEMODE; > } > > - if(DDSD->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER | DDSCAPS_BACKBUFFER)) { > + if(DDSD->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER || DDSCAPS_BACKBUFFER)) { This is wrong. You changed a logical OR into a boolean OR and the bitmask will no longer work... Something else needs to be changed, like removing either the DDSCAPS_BACKBUFFER part or the FRONTBUFFER part of the |. Ciao, Marcus

1 0

Re: implement FatalExitHook()
by Maarten Lankhorst Oct. 28, 2007

Oct. 28, 2007

Hi EA, I can find absolutely no info on FatalExitHook, are you sure it's supposed to exit the process, rather then making the argument be called in case of exit? Cheers, Maarten.

2 2

SHChangeNotify()
by Francois Gouget Oct. 28, 2007

Oct. 28, 2007

shlwapi.spec exports SHChangeNotify. However I see no implementation of this function in shlwapi. There is an SHChangeNotifyWrap() function however. Weirder still, SHChangeNotifyWrap() does not seem to be called anywhere, is not exported by shlwapi.spec, and calls SHChangeNotify(). So I'm confused as to how this is supposed to work. Could you clarify things for me? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

1 0

ddraw:d3d tests failing consistently
by Reece Dunn Oct. 27, 2007

Oct. 27, 2007

Hi, Looking at the ddraw:d3d tests, they are failing consistently on many Windows platforms: d3d.c:1039: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1050: Test failed: Vertex 2 differs. Got 129.000000 127.000000 1.000000 1.000000, expexted 133.000000 123.000000 1.000000 1.000000 d3d.c:1050: Test failed: Vertex 3 differs. Got 127.000000 129.000000 -1.000000 1.000000, expexted 123.000000 133.000000 -1.000000 1.000000 d3d.c:1050: Test failed: Vertex 4 differs. Got 128.500000 127.500000 0.500000 1.000000, expexted 130.500000 125.500000 0.500000 1.000000 d3d.c:1050: Test failed: Vertex 5 differs. Got 127.500000 128.500000 -0.500000 1.000000, expexted 125.500000 130.500000 -0.500000 1.000000 d3d.c:1050: Test failed: Vertex 6 differs. Got 127.500000 128.500000 0.000000 1.000000, expexted 125.500000 130.500000 0.000000 1.000000 d3d.c:1060: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1071: Test failed: Vertex 1 differs. Got 128.000000 128.000000 0.000000 1.000000, expexted 138.000000 148.000000 0.000000 1.000000 d3d.c:1071: Test failed: Vertex 2 differs. Got 129.000000 127.000000 1.000000 1.000000, expexted 143.000000 143.000000 1.000000 1.000000 d3d.c:1071: Test failed: Vertex 3 differs. Got 127.000000 129.000000 -1.000000 1.000000, expexted 133.000000 153.000000 -1.000000 1.000000 d3d.c:1071: Test failed: Vertex 4 differs. Got 128.500000 127.500000 0.500000 1.000000, expexted 140.500000 145.500000 0.500000 1.000000 d3d.c:1071: Test failed: Vertex 5 differs. Got 127.500000 128.500000 -0.500000 1.000000, expexted 135.500000 150.500000 -0.500000 1.000000 d3d.c:1071: Test failed: Vertex 6 differs. Got 127.500000 128.500000 0.000000 1.000000, expexted 135.500000 150.500000 0.000000 1.000000 d3d.c:1134: Test failed: Cliptest 3 differs. Got 00000020 expexted 00000026 d3d.c:1134: Test failed: Cliptest 4 differs. Got 00000010 expexted 00000019 d3d.c:1143: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1157: Test failed: Cliptest 1 differs. Got 00000000 expexted 00000002 d3d.c:1157: Test failed: Cliptest 2 differs. Got 00000000 expexted 00000001 d3d.c:1157: Test failed: Cliptest 3 differs. Got 00000020 expexted 00000022 d3d.c:1157: Test failed: Cliptest 4 differs. Got 00000010 expexted 00000011 d3d.c:1166: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1195: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1206: Test failed: Offscreen is 0 d3d.c:1217: Test failed: Offscreen is 0 d3d.c:1231: Test failed: Offscreen is 2 Does anyone know if this is a change in ddraw:d3d behaviour on Windows between versions/graphics drivers or has this test always failed? - Reece

5 17

MENU_TrackMenu trouble
by nicholai＠t-online.de Oct. 27, 2007

Oct. 27, 2007

Hello, I'm struggling to make recent Chessbase applications such as Fritz 9 and 10 work with wine. A free download which shows the same symptoms described below is available here: http://fritzserver.org/download/CBLightEnglishSetup.exe I have tried to look into this and this is what I've found: The application uses TrackPopupMenuEx() (user32/menu.c) which in wine is just a call to TrackPopupMenu(). The latter function calls MENU_TrackMenu() and that's where things seem to go wrong. In the loop going through the message queue the application will crash (see output below) whenever the following message is sent: SendMessageW( mt.hOwnerWnd, WM_ENTERIDLE, MSGF_MENU, (LPARAM)win ); If I uncomment that line, the application will stay alive but I will obviously experience weird menu behaviour. I'm stuck trying to find out what the problem is and would really appreciate any help on how to proceed with this Thanks and best regards, Nicholai ------------------------------------------------------------------------------------------------------------------------------- wine: Unhandled page fault on read access to 0x00000020 at address 0x15a60c5 (thread 03da), starting debugger... Unhandled exception: page fault on read access to 0x00000020 in 32-bit code (0x015a60c5). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:015a60c5 ESP:0034ea64 EBP:0034eb10 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:0272e930 EDX:782ba9e0 ESI:015a60c0 EDI:0272e930 Stack dump: 0x0034ea64: 015a60c0 782021cb 00000002 00000000 0x0034ea74: 62a7f85f 00000121 0272e930 00138218 0x0034ea84: 00000000 00000000 015cfe20 782bafa4 0x0034ea94: 7fffffff 7bc3f3de 00000000 00000000 0x0034eaa4: 00000090 7bc326a1 00000000 00000010 0x0034eab4: 0034eb04 7bc40bff 00110014 7bc8443c Backtrace: =>1 0x015a60c5 in sviewnet (+0x760c5) (0x0034eb10) 2 0x78201ca1 in mfc80 (+0x31ca1) (0x0034eb30) 3 0x78200a43 in mfc80 (+0x30a43) (0x0034eb98) 4 0x78200c53 in mfc80 (+0x30c53) (0x0034ebbc) 5 0x781fedad in mfc80 (+0x2edad) (0x0034ec04) 6 0x7ed63b8a WINPROC_wrapper+0x1a() in user32 (0x0034ec34) 7 0x7ed6429e in user32 (+0xa429e) (0x0034ec74) 8 0x7ed685db in user32 (+0xa85db) (0x0034f144) 9 0x7ed69a0b WINPROC_call_window+0x15b() in user32 (0x0034f184) 10 0x7ed3036c in user32 (+0x7036c) (0x0034f1f4) 11 0x7ed340a2 in user32 (+0x740a2) (0x0034f254) 12 0x7ed3451a SendMessageW+0x4a() in user32 (0x0034f294) 13 0x7ed2d327 in user32 (+0x6d327) (0x0034f354) 14 0x7ed2e0af TrackPopupMenu+0x11f() in user32 (0x0034f394) 15 0x7ed2e14e TrackPopupMenuEx+0x5e() in user32 (0x0034f3c4) 16 0x015a757a in sviewnet (+0x7757a) (0x000005f0) 17 0x00000000 (0x00000000)

1 0

wine tests question?
by Vijay Kiran Kamuju Oct. 27, 2007

Oct. 27, 2007

Hi, I have been looking into http://test.winehq.org/data/. And I have got a question, when i saw the test data. Why do some tests do not return the data about tests they haven't run/skipped. They spew messages something like below: mapi32:prop start dlls/mapi32/tests/prop.c 1.20 mapi32:prop done (-1073741819) mapi32:util start dlls/mapi32/tests/util.c 1.9 mapi32:util done (-1073741819) I am trying to figure out a reason so that i can fix this. can you guys help me out? thanks, VJ

2 2

What if heap errors caused 'make test' to fail?
by Dan Kegel Oct. 27, 2007

Oct. 27, 2007

Let's just say, for grins, that we applied a patch that made heap corruption fatal under WINEDEBUG=warn+heap, e.g. --- a/dlls/ntdll/heap.c +++ b/dlls/ntdll/heap.c @@ -909,6 +909,7 @@ static BOOL HEAP_ValidateInUseArena( con WARN( "Heap %p: unaligned arena pointer %p\n", subheap->heap, pArena ); if ( TRACE_ON(heap) ) HEAP_Dump( subheap->heap ); + assert( FALSE ); } return FALSE; } @@ -924,6 +925,7 @@ static BOOL HEAP_ValidateInUseArena( con WARN("Heap %p: invalid in-use arena magic for %p\n", subheap->heap, pArena ); if (TRACE_ON(heap)) HEAP_Dump( subheap->heap ); + assert( FALSE ); } return FALSE; } How many tests would that break? Any guesses? Scroll down for the answer: 25! Here's the output of WINEDEBUG=warn+heap make -k test piped through grep make.*Error: make[2]: *** [alloc.ok] Error 134 make[2]: *** [pipe.ok] Error 1 make[2]: *** [systray.ok] Error 6 make[2]: *** [thread.ok] Error 9 make[2]: *** [security.ok] Error 1 make[1]: *** [advapi32/tests/__test__] Error 2 make[2]: *** [info.ok] Error 134 make[1]: *** [ntdll/tests/__test__] Error 2 make[2]: *** [heap.ok] Error 134 make[2]: *** [change.ok] Error 2 make[2]: *** [heap.ok] Error 5 make[2]: *** [util.ok] Error 134 make[1]: *** [msvcrt/tests/__test__] Error 2 make[1]: *** [snmpapi/tests/__test__] Error 2 make[2]: *** [apibuf.ok] Error 134 make[1]: *** [netapi32/tests/__test__] Error 2 make[2]: *** [device.ok] Error 4 make[1]: *** [d3d9/tests/__test__] Error 2 make[2]: *** [moniker.ok] Error 134 make[2]: *** [toolhelp.ok] Error 8 make[2]: *** [webbrowser.ok] Error 134 make[1]: *** [shdocvw/tests/__test__] Error 2 make[2]: *** [input.ok] Error 64 make[2]: *** [editor.ok] Error 5 make[1]: *** [riched20/tests/__test__] Error 2 make[2]: *** [mixer.ok] Error 10 make[2]: *** [msg.ok] Error 18 make[2]: *** [shellpath.ok] Error 3 make[2]: *** [class.ok] Error 2 make[2]: *** [comm.ok] Error 3 make[2]: *** [vartype.ok] Error 134 make[1]: *** [oleaut32/tests/__test__] Error 2 make[2]: *** [parser.ok] Error 134 make[1]: *** [setupapi/tests/__test__] Error 2 make[2]: *** [win.ok] Error 8 make[2]: *** [capture.ok] Error 134 make[1]: *** [dsound/tests/__test__] Error 2 make[2]: *** [htmldoc.ok] Error 134 make[2]: *** [timer.ok] Error 1 make[2]: *** [mci.ok] Error 134 make[1]: *** [mshtml/tests/__test__] Error 2 make[2]: *** [font.ok] Error 26 make[1]: *** [gdi32/tests/__test__] Error 2 make[1]: *** [kernel32/tests/__test__] Error 2 make[2]: *** [wave.ok] Error 8 make[1]: *** [winmm/tests/__test__] Error 2 make[2]: *** [server.ok] Error 4 make[1]: *** [rpcrt4/tests/__test__] Error 2 make[2]: *** [dde.ok] Error 5 make[1]: *** [user32/tests/__test__] Error 2 make[2]: *** [shlexec.ok] Error 35 make[1]: *** [shell32/tests/__test__] Error 2 make[1]: *** [ole32/tests/__test__] Error 2 I wonder if some of these tests are themselves buggy such that they pass on Wine by accident (without this patch) but fail on Windows? - Dan

4 5

wine needs a relatively new version of fontforge?
by Lei Zhang Oct. 27, 2007

Oct. 27, 2007

Hi, Dan K. and I both ran into bug 10103 [1] because the fontforge on our systems is too old. I noticed some of the font tests failed on my system for the same reason. So what is the minimum version of fontforge that will generate correct fonts? Should we add a check for it? - Lei [1] http://bugs.winehq.org/show_bug.cgi?id=10103

1 0

Re: makefiles: add a notest target
by Maarten Lankhorst Oct. 26, 2007

Oct. 26, 2007

Hi Lei, Lei Zhang schreef: > Hi, > > This patch adds a notest target to build everything but the dll unit > tests and winetest. This cuts down build time by 25%. > Julliard will never accept such patch. In the hacks.git tree there is a patch I did that has a configuration time option for it. It would be cleaner if you used something like 'make SKIPTESTS=1'. I doubt that alexandre would ever accept any patch that would disable building tests, though. Cheers, Maarten.

3 2

Re: user32: Fix a test that now passes in Windows
by Reece Dunn Oct. 26, 2007

Oct. 26, 2007

On 25/10/2007, James Hawkins wrote: > Hi, > > Changelog: > * Fix a test that now passes in Windows. Looking at the code, it looks as if they are now passing in Wine :). > dlls/user32/tests/dde.c | 13 ++++++++++--- > 1 files changed, 10 insertions(+), 3 deletions(-) > + str = (LPSTR)DdeAccessData(hdata, &size); > + ok(!lstrcmpA(str, "requested data\r\n"), "Expected 'requested data\\r\\n', got %s\n", str); Shouldn't there be quote marks around the %s (i.e. '%s', to match the expected value)? > + ok(size == 19, "Expected 19, got %d\n", size); > + > + ret = DdeUnaccessData(hdata); > + ok(ret == TRUE, "Expected TRUE, got %d\n", ret); These are new test cases. Since these are not fixes to existing test cases, they should really be in a separate patch. - Reece

3 3

my first patch
by viny Oct. 26, 2007

Oct. 26, 2007

Can someone tell me if this patch is correct for submitting to wine-patches. I have generated this patch with "git format-patch -o out origin" (related bug : http://bugs.winehq.org/show_bug.cgi?id=9805) >From c5eab13b67e6f24b3518dd77840f260dc101520e Mon Sep 17 00:00:00 2001 From: Vincent Hardy <vincent.hardy.be(a)gmail.com> Date: Fri, 26 Oct 2007 13:37:39 +0200 Subject: [PATCH] Add TypeLib version for W2K, WXP, and Vista --- dlls/oleaut32/typelib16.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/dlls/oleaut32/typelib16.c b/dlls/oleaut32/typelib16.c index a010f7d..31bbf93 100644 --- a/dlls/oleaut32/typelib16.c +++ b/dlls/oleaut32/typelib16.c @@ -153,6 +153,9 @@ HRESULT WINAPI LoadTypeLib16( *| OLE 2.1 NT 1993-95 ?? ??? *| OLE 2.3.1 W95 23 700 *| OLE2 4.0 NT4SP6 1993-98 40 4277 + *| OLE 2.1 W2K 2000 10 3029 + *| OLE 2.1 WXP 2002 10 3029 + *| OLE 2.1 Vista 2007 10 3029 */ DWORD WINAPI OaBuildVersion16(void) { @@ -171,6 +174,12 @@ DWORD WINAPI OaBuildVersion16(void) return MAKELONG(3024, 10); /* W98 SE */ case 0x00000004: /* NT4 */ return MAKELONG(4277, 40); /* NT4 SP6 */ + case 0x00000005: /* W2K */ + return MAKELONG(3029, 10); /* W2K SP4 */ + case 0x00000105: /* WXP */ + return MAKELONG(3029, 10); /* WXP SP2 */ + case 0x00000006: /* Vista */ + return MAKELONG(3029, 10); /* Vista */ default: FIXME("Version value not known yet. Please investigate it!\n"); return 0; -- 1.5.2.5

3 2

Improving http://tests.winehq.org/data/
by Francois Gouget Oct. 26, 2007

Oct. 26, 2007

Here are some things I noticed while using this site. Let me know if I it would help to make bug reports for these: * Some result entries are red with a dash in them and a blue border. See the Windows 98 results for http://test.winehq.org/data/200710241000/ I assume these means that the test did not load. However we should distinguish two cases there: - if it did not run because the tested dll did not exist at all, then it's not a test failure and thus the background should be green. A typical case would be the crypt32 tests on Windows 98. - if the dll was there but the test still did not run, typically because the dll is missing an export, then that's a bug in the test: it should dynamically load that function so the other checks it performs can be run. A typical case is the gdi32 tests on Windows 98. Ideally we'd even have a log showing the missing API but that's probably too tricky to do on Windows. * Downloading the log file for a given test run gives me a file that's called 'report'. It would be nice if it was called something like 'vmware-win98-report' instead so that saving a couple of them in a directory leads to fewer collisions. * It would be nice if the /data page looked more like a calendar with the most current date easily accessible, and a less like the directory listing it currently is. Then a / page would be nice too. I'm pretty unlikely to fix these, but at least here is a starting if someone is inclined to do so: you will find the source for the test.winehq.org website in the tools.git repository: http://source.winehq.org/git/tools.git/?a=tree;f=winetest To get hold of the sources, see the instructions there: http://www.winehq.org/site/git#modules -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

6 9

Anything wrong with my patch from 16.10. about w32x86 and win40 creation?
by Markus Gömmel Oct. 26, 2007

Oct. 26, 2007

I think it's not a big deal but would help making on of our EmTec products more compatible... Markus

5 13

Re: [1/5] (resend) WineD3D: Enable the draw buffers extension only when used
by Stefan Dösinger Oct. 26, 2007

Oct. 26, 2007

Please ignore this patch. I just saw that macos advertises 4 draw buffers, but only one was used inside wined3d because we weren't using fbo offscreen rendering. Now macos supports the extension, 4 draw buffers but still complains... oh well > Am Freitag, 26. Oktober 2007 12:45:57 schrieb Stefan Dösinger: > > In a last discussion with Henri on IRC I fixed a concern he had about the > > old patch(dropped extension check). As for the general concern about > > driver issue fixups, we didn't come to a final conclusion and decided to > > ask Alexandre for his opinion. Just to sum up the pros/cons: > > > > -) Makes the code more complex to work around another's issues > > -) Will most likely never be removed should the driver be fixed > > > > +) Compiling the shader without warnings makes real issues more visible > > and important > > +) Avoids confusing mac users and developers with the false warnings > > +) MacOS Tiger Driver will propably never get fixed > > Use the attached patch instead, it follows a suggestion by Chris and is > less intrusive.

1 0

Re: d3dx8 math implementation + tests: use more "," instead of ";".
by Alexandre Julliard Oct. 26, 2007

Oct. 26, 2007

Lionel Debroux <lionel_debroux(a)yahoo.fr> writes: > I noticed several "," in the implementation and tests of D3DX8 math > functions. I added more, since this may help the auto-vectorizer of > some compilers noticing that x86 SIMD could be used. I don't see any reason why that would make the slightest difference, what makes you think this is needed? -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Improving http://tests.winehq.org/data/
by Dan Kegel Oct. 26, 2007

Oct. 26, 2007

James wrote: >Looking at the test data, all of the msi:install tests timeout. I >just ran the install tests in XP running under vmware on a 3ghz >machine. The tests took 9m41s. That completely blows away the 2min >timeout. There's nothing wrong with the tests, they just take a long >time. I don't think we should extend the timeout, because it's very >subjective and more tests will be added, meaning we'll have to change >the timeout eventually. I do think we should have a flag or variable >that allows the timeout to be ignored for certain tests. Any >opinions? I'd like a way to specify the expected runtime, for use on tests that we observe take a long time. It would be used in two ways: 1) runtest could take an option --skip-long-tests which would skip all tests that had that option set, and 2) by default runtest would only abort those tests if they took one minute over their expected time (say). That would give us both a quick interactive make test and a more reliable slow-but-complete make test. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

4 4

Re: Word crash
by Kai Blin Oct. 26, 2007

Oct. 26, 2007

On Friday 26 October 2007 09:28:09 Marco Stornelli wrote: > Hi all, > > I'm using wine 0.9.44-15 for openSuse 10.3 and office 2000. Excel > works fine, powerpnt doesn't start and wine doesn't print nothing in > console about it, and about word, wine prints this: Please don't send emails to wine-bugs. Open a bugreport on http://bugs.winehq.org/ instead. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0