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

Re: winspool.drv: Conformance-Tests

by Detlef Riekenberg

Felix Nawothnig wrote: > > While rewriting the conformance-tests for winspool.drv, how should we > > handle this bugs / features ? > a) ... > b) ... > c) ... > Disclaimer: These are my personal guidelines, so treat them as such. :-) Thanks for your hints. I will change some Tests to trace, when i check for the undocumented results. In my case, SetLastError() is used, when the Function fails (documented) and also, when the Function returned SUCCESS (undocumented). > Just check this on NT then, but avoid using GetVersion() - I'd suggest > to do something like: That was my Test: /* Test for BUG in win9x and wine: Level is not checked */ if((result != FALSE) && (strlen(buffer) == (exact-1))) { todo("windows") { todo_wine { ok(0, "BUG in win9x and wine: Invalid Level '0' is" \ " not checked (valid Level is '1')\n"); } } }else { is_result_ok(FALSE); is_lasterror_ok(ERROR_INVALID_LEVEL); is_size_untouched((exact+1)); is_buffer_untouched(buffer, exactbytes); } > > I marked that as todo("windows"). > > Is this ok? > > No. Until there are other third-party win32 implementations using the > WRT (Reactos?) we use just todo_wine, nothing else. OK. I change that. > > Another Example for GetPrinterDriverDirectory and Enum*: > > On w2k, the the returned "number of bytes required" in the ANSI-Version > > is the same as in the Unicode-Version. > > For GetPrinterDriverDirectory, the rest from the unicode-version of the > > result is visible in the second part of the buffer. > > (I Think, w2k fill the buffer with the unicode-version and convert > > in-place to ANSI. Should we do the same ?) > > I'm not sure what you mean here... Documented is: Return the required number of Bytes for the Buffer. On W2K the default Driver-Directory is "C:\WINNT\system32\spool\DRIVERS\W32X86" (38 Characters + Zero). Optimal Buffersize is 78 Byte for "W" and 39 Byte for "A", but W2k required a Buffer of 78 Byte for GetPrinterDriverDirectoryA. A Trace for the Buffer-Contents is: .c:656:00236438: buffer "C:\WINNT\system32\spool\DRIVERS\W32X86" .c:661:00236460: buffer+40 L"ool\DRIVERS\W32X86" > If the function works as documented but fills the rest of the passed > buffer with undefined stuff (it NUL terminates the first part, right?) Yes, thats the behavior. On win9X, the "W"-Version is not implemented and the "A"-Version wants a Buffer with the optimal Size (18 Byte for "C:\WINDOWS\SYSTEM"+0). (Wine has a BUG and returned a 19 here. I know how to fix this, but I want to get the tests in the CVS first). > we shouldn't test for it unless we find an app which depends on it. I will change the relevant Tests to trace. -- By By ... ... Detlef

Aug. 18, 2005

Re: RICHED20: Avoid flicker

by Phil Krylov

On Sun, 14 Aug 2005 17:53:33 +0400 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > this patch needs to be applied after the "Re: RICHED20: Implement > EM_SETRECT, EM_SETRECTNP and WM_SETREDRAW messages (fixed)" patch. > > ChangeLog: > > Avoid flicker in RichEdit using proper update region invalidation and an > offscreen bitmap. Anything wrong with this patch? -- Ph.

Aug. 18, 2005

Re: [Bug 3165] Patch available

by Kevin DeKorte

On Thursday 18 August 2005 03:24 am, Dripple wrote: > Hi, > > I tested the patch submitted in > http://bugs.winehq.org/show_bug.cgi?id=3165 Bugzilla page with Notes. > Seems to fix the issue. > > Regards. > > Dripple. Well the patch does improve the cursor. I can now see it. Although it is only grey. It there any reason why the best cursor selection method always checks for bits == 1. What about color cursors? Kevin -- Get my public GnuPG key from http://keyserver.veridis.com:11371/export?id=7574690260641978351

Aug. 18, 2005

Re: Cursor disappears and reappears

by gslink

I suspect this may not be in Wine at all. There is currently a problem that shows up both in and out of Wine with the cursor vanishing permanently until reboot on some games that block or change the cursor. This appears to be a problem in FC but I have not had time to track it down.

Aug. 18, 2005

Re[2]: commctrl: dialog theming

by Vitaliy Margolen

Thursday, August 18, 2005, 12:10:39 AM, Mike McCormack wrote: > Evil wrote: >> I'm no longer able to run programs that require the native comctl32 and >> commctrl DLLs, since updating to today's CVS. Could it be related to >> these theme patches? > You shouldn't need to use the native comctl32 any longer. Please update > your dll overrides to "comctl32" = "builtin". > Wine's comctl32 implementation is almost complete. If there's bugs with > the builtin comctl32 then please help us by reporting them rather than > sweeping the problem under the carpet and using the native dll. To fuel this fire a little bit, I should mention that ATM all themed controls are broken with all Delphi and possible some other programs. So having an option to use native comctl32 is not such a bad idea. Vitaliy.

Aug. 18, 2005

Re: winspool.drv: Conformance-Tests

by Felix Nawothnig

Detlef Riekenberg wrote: > I wrote a Commandline-Program for testing the Printing-API and found > many misterious behaviour. > > While rewriting the conformance-tests for winspool.drv, how should we > handle this bugs / features ? There are several types of undocumented behaviour: a) The documentation is plain wrong and applications will most likely depend on the documented behaviour (often hard to tell - an example would be a function which is supposed to return the needed buffer size but misbehaves under some conditions): In this case test for the documented behaviour, comment it out using #if 0 and add a note that foobar32.dll Version 1.2.3.4 does not work as documented. b) The documentation is plain wrong and it's likely that applications using the API will rely on the undocumented behaviour (for example if MSDN got the argument order wrong): In this case test for the undocumented behaviour and add a comment telling that this is undocumented. c) The documentation is wrong, misleading or incomplete and although applications should not rely on the undocumented behaviour you found one which does (for example if a function reports failure instead of segfaulting when it retrieves a bad pointer): In this case test for the undocumented behaviour and add a comment telling which application depends on this undocumented behaviour. Any other undocumented behaviour should not be tested for at all. Disclaimer: These are my personal guidelines, so treat them as such. :-) > Example for GetPrinterDriverDirectory (W/A): > > Win98se and WinME do not check the requested level Just check this on NT then, but avoid using GetVersion() - I'd suggest to do something like: ret = GetPrinterDriverDirectoryW(foo); if(ret != ERROR_CALL_NOT_IMPLEMENTED) { /* Here you can test stuff which fails on 9x/ME */ } else trace("GetPrinterDriverDirectoryW not implemented, skipping tests\n"); /* ... and here the stuff which successeds on both 9x/ME and NT */ > I marked that as todo("windows"). > Is this ok? No. Until there are other third-party win32 implementations using the WRT (Reactos?) we use just todo_wine, nothing else. > Another Example for GetPrinterDriverDirectory and Enum*: > On w2k, the the returned "number of bytes required" in the ANSI-Version > is the same as in the Unicode-Version. I'd handle this like a). We probably want our implementation to work as documented (since this is most likely what apps will depend on) but we can't test it since it would fail on Windows - so we comment out the test. > For GetPrinterDriverDirectory, the rest from the unicode-version of the > result is visible in the second part of the buffer. > (I Think, w2k fill the buffer with the unicode-version and convert > in-place to ANSI. Should we do the same ?) I'm not sure what you mean here... If the function works as documented but fills the rest of the passed buffer with undefined stuff (it NUL terminates the first part, right?) we shouldn't test for it unless we find an app which depends on it. Felix

Aug. 18, 2005

Re: commctrl: dialog theming

by Evil

Andreas Mohr wrote: > Just to verify: are you sure that you're > >*either* running both commctrl.dll and comctl32.dll as native >*or* both commctrl.dll and comctl32.dll as builtin? >Otherwise it *will* fail, with a thunk error similar (or equal?) to above. > > Yes, using both native is when I get the aforementioned failure. Dreamweaver starts if you use both built-in, but there are broken dialogs that can't be used. -J

Aug. 18, 2005

Re: commctrl: dialog theming

by Evil

Mike McCormack wrote: > You shouldn't need to use the native comctl32 any longer. Please > update your dll overrides to "comctl32" = "builtin". > > Wine's comctl32 implementation is almost complete. If there's bugs > with the builtin comctl32 then please help us by reporting them rather > than sweeping the problem under the carpet and using the native dll. Dreamweaver's "Add Site" (and other) dialog are completely broken when using the built-in comctl32. This was known way before I ever started using WINE (because I learned of it by searching old mailing lists). I even added it to the app database months back. -Jesse

Aug. 18, 2005

[Bug 3165] Patch available

by Dripple

Hi, I tested the patch submitted in http://bugs.winehq.org/show_bug.cgi?id=3165 Bugzilla page with Notes. Seems to fix the issue. Regards. Dripple.

Aug. 18, 2005

Re: commctrl: dialog theming

by Mike McCormack

Evil wrote: > I'm no longer able to run programs that require the native comctl32 and > commctrl DLLs, since updating to today's CVS. Could it be related to > these theme patches? You shouldn't need to use the native comctl32 any longer. Please update your dll overrides to "comctl32" = "builtin". Wine's comctl32 implementation is almost complete. If there's bugs with the builtin comctl32 then please help us by reporting them rather than sweeping the problem under the carpet and using the native dll. Mike

Aug. 18, 2005