August 2008 - Wine-devel - list.winehq.org

Re: [2/2] mshtml: Implement IDispatch for IHTMLElement
by Jacek Caban 16 Aug '08

16 Aug '08

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Implement IDispatch for IHTMLElement You should forward these calls to IDispatchEx implementation. See htmlselect.c for example. Jacek

1 0

Re: [1/2] mshtml: Changed get_typeinfo to help support IDispatch
by Jacek Caban 16 Aug '08

16 Aug '08

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Changed get_typeinfo to help support IDispatch > Subject: [PATCH] Changed get_typeinfo to AddRef the COM pointer get_typeinfo is an internal function so it's fine to not AddRef as long as we guarantee that we hold the reference (and we do) so there is no point to add unneeded AddRef here. Jacek

1 0

re: Unwanted WM_CTLCOLORSTATIC notification
by Dan Kegel 15 Aug '08

15 Aug '08

Matt wrote: > I've been trying to debug a problem with Adobe Indesign CS where the > application crashes while creating the file open dialog box. Now I believe > (not 100% sure) I have tracked down the problem to a spurious > WM_CTLCOLORSTATIC notification. Thanks for looking into this. This is a key app needed by many schools and companies, but we haven't had enough time to give it the attention it deserves. Please file a bug report at http://bugs.winehq.org including all the info needed to reproduce the bug (ideally with a trial version; you can find download URLs at http://wiki.winehq.org/AdobeIndesign And attach your test case source there. If you want to go a little further, rewrite your test case in plain C instead of C++ (should be easy). And if you want to go even further, integrate it into our existing message tests, http://source.winehq.org/source/dlls/user32/tests/msg.c which already do have some tests for WM_CTLCOLORSTATIC. One note of caution: the user32/msg.c tests don't all pass on Wine, see http://wiki.winehq.org/MakeTestFailures and http://test.winehq.org/data/520ab5c261706f6118a85a82ba84213932ba76e7/#group… - Dan

2 1

Re: .NET program crashes involving stubbed functions
by James Mckenzie 15 Aug '08

15 Aug '08

Reece Dunn <msclrhd(a)googlemail.com> on Aug 13, 2008 11:32 AM wrote about .NET program crashes involving stubbed functions > >2008/8/13 Adam Petaccia <adam(a)tpetaccia.com>: >> Its customary to make a function return NotImplemented in Gdiplus, if >> its just a dummy function that does nothing and returns. But .NET seems >> to check for this and throw an exception, crashing the program anyway. >> >> See bug http://bugs.winehq.org/show_bug.cgi?id=12951 for details, but >> originally a program crashed because GdipNewPrivateFontCollection was >> just a stub. After the function was created, it still crashes because it >> returns "NotImplemented", rather than "Ok". IIRC, we return >> "NotImplemented" for some debugging reason, but if the goal of Wine is >> to run Windows applications, should we just go ahead and return "Ok" so >> that .NET apps don't freak out? >> >> Of course in a perfect world, we wouldn't have to fake a return code, >> but until that time comes do people have opinions one way or another? > >The problem with returning Ok is that it implies that the function >succeeded in what it is intended to do. As a result, the application >will continue and in this case expect to be able to use the private >font collection. To prevent the application crashing, it is likely >that several functions will need to be implemented. > >Also note that the reporter of the bug mentions that they installed >mono. This means that using MS.NET may lead to different behaviour. It >also means that it should be possible to see how the >GdipNewPrivateFontCollection call is being used by mono and the data >that it returns. Is there a method of resolving this using functions provided by Mono or will this require additional tools? > >So to summarise, I suspect this will require more than simply returning Ok. > I agree. There should be more responses than just OK. James McKenzie

1 0

Re: #1 winhttp: Add a handle management implementation.
by H. Verbeet 15 Aug '08

15 Aug '08

2008/8/15 Hans Leidekker <hans(a)meelstraat.net>: > > +HINTERNET alloc_handle( object_header_t *hdr ) > +{ > + object_header_t **p; > + ULONG_PTR handle = 0, num; > + > + list_init( &hdr->children ); > + > + EnterCriticalSection( &handle_cs ); > + if (!max_handles) > + { > + num = HANDLE_CHUNK_SIZE; > + if (!(p = heap_alloc_zero( sizeof(ULONG_PTR) * num ))) goto end; > + handles = p; > + max_handles = num; > + } > + if (max_handles == next_handle) > + { > + num = max_handles + HANDLE_CHUNK_SIZE; > + if (!(p = heap_realloc_zero( handles, sizeof(ULONG_PTR) * num ))) goto end; > + handles = p; > + max_handles = num; > + } > + handle = next_handle; > + if (handles[handle]) ERR("handle isn't free but should be\n"); > + > + handles[handle] = addref_object( hdr ); > + while (handles[next_handle] && (next_handle < max_handles)) next_handle++; > + > +end: > + LeaveCriticalSection( &handle_cs ); > + return hdr->handle = (HINTERNET)(handle + 1); > +} Not necessarily wrong, but the common way to implement tables like this is to grow the table by some percentage of the original size, and keep a list of free handles.

2 1

Re: #1 winhttp: Add a handle management implementation.
by Hans Leidekker 15 Aug '08

15 Aug '08

On Friday 15 August 2008 14:41:36 Hans Leidekker wrote: Sorry for the From address confusion. The CodeWeavers mail server accused me of relaying but I found out now that it's because I forgot to enable authenticated SMTP. -Hans

1 0

Unwanted WM_CTLCOLORSTATIC notification
by Matt J 15 Aug '08

15 Aug '08

Hi, I've been trying to debug a problem with Adobe Indesign CS where the application crashes while creating the file open dialog box. Now I believe (not 100% sure) I have tracked down the problem to a spurious WM_CTLCOLORSTATIC notification. This notification is generated when the application invokes WM_SETTEXT to change the caption of a 'group box' control control in the dialog box. To verify this I coded up a small test case, which I have attached to the email. This basically creates a new dialog box and when it receives it WM_INITDIALOG notification it calls SendDlgItemMessage to send a WM_SETTEXT message to set the text of a 'group box' control on the dialog. As it runs it logs the notifications that it receives. On windows we see the following: Message: 0x00000030 (48) Message: 0x00000110 (272) WM INITDIALOG Message: 0x00000127 (295) Message: 0x00000128 (296) Message: 0x00000018 (24) Message: 0x00000046 (70) ... Under wine we see: Message: 0x00000030 (48) Message: 0x00000110 (272) WM INITDIALOG Message: 0x00000138 (312) Message: 0x00000018 (24) Message: 0x00000046 (70) ... Of primary interest to me here is the WM_CTLCOLORSTATIC notification (0x00000138) that is generated only under wine. Also of interest is that WM_CHANGEUISTATE (0x00000127) and WM_UPDATEUISTATE (0x00000128) notifications are received under windows but not wine. This is my first foray into debugging wine, so I may be totally off track here, but I do believe that the WM_CTLCOLORSTATIC notification is what is causing InDesign to crash. So, I am wondering if someone with more experience here can give some advice about rectifying this problem. If I can provide any more info about the problem, please let me know. Regards, Matt

1 0

Re: wininet: default to keep-alive when the server is HTTP/1.1, not when it isn't
by Huw Davies 15 Aug '08

15 Aug '08

Vincent Povirk wrote: > This is a fix to a problem I introduced in > fd5b97bc4d12adc69085b739061c56e9107f8d1f. The expression that checked > the HTTP version was true for HTTP/1.0 servers, and I treated it as if > it were true for HTTP/1.1 servers. That means we defaulted to keep-alive > for HTTP/1.0 servers only, the exact opposite of what we want. This was a problem with the old code too, but what happens when we get HTTP > 1.1 ? Huw.

2 1

Flaky tests are starting to get real annoying...
by Dan Kegel 14 Aug '08

14 Aug '08

So, one of the things one learns when writing a patch robot is that flaky tests are very annoying. Each time it gets a new git tree, the robot does five baseline "make -k test" runs, remembers the tests that fail, and doesn't penalize patches for failing any of those tests. See http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/patchwat… Annoyingly, that's not enough. Some tests stubbornly refuse to fail during the baseline test runs. So I added a second, manual blacklist for those tests; see http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/patchwat… The list is currently user32:msg.c user32:input.c d3d9:visual.c ddraw:visual.c urlmon:protocol.c kernel32:thread.c and will continue growing as I keep plugging away at getting the patch robot happy. Is anybody else seeing this kind of flakiness? (If you're not, try running patchwatcher for a while :-) FWIW, I'm running the tests on hardy with a fresh metacity (as described in http://wiki.winehq.org/MakeTestFailures ).

4 6

Re: user32: test what FindWindow when window isn't found
by Dmitry Timoshkov 14 Aug '08

14 Aug '08

"Austin English" <austinenglish(a)gmail.com> wrote: > - /* test FindWindow behavior */ > + SetLastError(0xdeadbeef); > + HWND hWnd = FindWindow("SomeWindowThatDoesNotExist", NULL); > + if(hWnd) { > + printf("hWnd not NULL"); > + } > + else { > + > + todo_wine > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "ERROR_FILE_NOT_FOUND, got %d\n", GetLastError()); > + } Why did you remove the comment? Introducing 'hWnd' variable is not needed, there is one already called 'found', besides declaring variables in the code is not allowed in Wine. It would be much simpler to add the last error test to 2 existing FindWindowExA calls instead of introducing something looking as foreign code (in indentation, braces usage and spaces). -- Dmitry.

3 3