May 2005 - Wine-devel - list.winehq.org

Re: crypt32 [4/4]: (un)protectdata test suite
by Alexandre Julliard 20 May '05

20 May '05

Kees Cook <kees(a)outflux.net> writes: > ChangeLog: > Create basic test suite for CryptProtectData/CryptUnprotectData. The tests fail here: ../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p crypt32_test.exe.so protectdata.c && touch protectdata.ok err:crypt:CryptProtectData CryptAcquireContextW failed protectdata.c:89: Test failed: Encrypting without entropy. protectdata.c:91: Test failed: Wrong (2148073494) GetLastError seen err:crypt:CryptProtectData CryptAcquireContextW failed protectdata.c:99: Test failed: Encrypting with entropy. protectdata.c:101: Test failed: Wrong (2148073494) GetLastError seen err:crypt:CryptProtectData CryptAcquireContextW failed protectdata.c:111: Test failed: Encrypting with entropy and no description. protectdata.c:113: Test failed: Wrong (2148073494) GetLastError seen protectdata.c:127: Test failed: CryptProtectData failed to run, so I can't test its output make[3]: *** [protectdata.ok] Error 7 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [QCAP] Final patch
by Dimi Paun 20 May '05

20 May '05

On Fri, 2005-05-20 at 00:42 +0200, Maarten Lankhorst wrote: > m3h, v4l driver for vfwcapture.. please leave the ERR notice on > initialisation intact, thank you :) I think you've overusing ERR(). ERR() should be called to signal an internal error such as inconsistent state, not something that the function is designed to handle. > + capBox->grab_buf = CoTaskMemAlloc(sizeof(struct video_mmap) * capBox->buffers); > + if(!capBox->grab_buf) { > + ERR("Out of memory?\n"); > + munmap(capBox->pmap, capBox->gb_buffers.size); > + return E_OUTOFMEMORY; > + } The function knows how to deal with this condition gracefully, just get rid of the ERR(). > + if (!capBox->grab_data) > + { > + ERR("%p: Out of memory?\n", capBox); > + return E_OUTOFMEMORY; > + } Ditto. Also the code is more clear if you just do: if (!capBox->grab_data) return E_OUTOFMEMORY; > + if (!capBox) { > + ERR("Out of memory\n"); > + return E_OUTOFMEMORY; > + } Ditto. > + if (stat (device, &st) == -1) { > + ERR("%s: %s\n", device, strerror(errno)); > + CoTaskMemFree(capBox); > + return E_FAIL; > + } Why is this a ERR()? > + > + if (!S_ISCHR (st.st_mode)) { > + ERR("%s: Not a device\n", device); > + CoTaskMemFree(capBox); > + return E_FAIL; > + } And why this? > + > + capBox->fd = open(device, O_RDWR | O_NONBLOCK); > + if (capBox->fd == -1) { > + ERR("%s: Failed to open: %s\n", device, strerror(errno)); > + CoTaskMemFree(capBox); > + return E_FAIL; > + } This is a TRACE or WARN at most. > + ERR("Tinkerer detected? Thou shalt not define HAVE_V4L2\n"); > + CoTaskMemFree(capBox); > + close(capBox->fd); > + return E_FAIL; This is a FIXME. And so on... -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

4 6

Q for AJ? Re: UT2003 Windowing Regression - Yet Another nights effort...
by Ann and Jason Edmeades 20 May '05

20 May '05

Ok, I need advice on this one... I have been purely testing on windows, no wine involvement, to see what happens when I do various things. My test program doesn't do anything in the WM_PAINT handler at all. This results in the machine sitting at 100% CPU processing WM_PAINT messages. 1. Changing the WM_PAINT process to post another user message, results in alternating message posted and WM_PAINT messages, ie normal user message processing is occurring 2. Posting a user message inside the user message handler, results in WM_PAINT being driven, followed by looping processing the user messages - ie WM_PAINT messages are not on the message queue 3. RedrawWindow with update now jumps straight into the message routine with a WM_PAINT, but if we do nothing in that routine, it does indeed proceed to the line after the RedrawWindow call. Wine never leaves the updatenow processing because it loops until the whole region is validated. I believe staying in the updatenow code in wine is incorrect. I think what happens is that when the message dispatch loop gets an empty queue and the window has an invalid region, then a WM_PAINT is returned. So... Can we / I please remove the loop? :-)) What other tests can I do under windows to confirm the behaviour? Jason

2 4

Re: [OLE #90] Marshal Objects & Monikers into the ROT
by Mike Hearn 20 May '05

20 May '05

On Fri, 20 May 2005 14:57:49 +0100, Robert Shearman wrote: > +static inline HRESULT WINAPI > +IrotRegister(DWORD *cookie) > +{ > + static DWORD last_cookie = 1; > + *cookie = InterlockedIncrement(&last_cookie); > + return S_OK; > +} I'm sure there's a good reason for this, but why isn't the last cookie an object member of the ROT? And what are all the Irot* methods given that this is a static inline? Could the need for these functions be documented? thanks -mike

1 0

[Fwd: [Bug 2969] New: CVS Regression - "Pure Virtual Function Call"]
by Dustin Navea 20 May '05

20 May '05

This one has been pre-diagnosed and the patch has been found. All relevant info is in the message from wine-bugs, attached below, any additional info needed? Let me know and I will request it from the author.. Dustin -------- Original Message -------- Subject: [Bug 2969] New: CVS Regression - "Pure Virtual Function Call" Date: Thu, 19 May 2005 15:03:13 -0500 From: Wine Bugs <wine-bugs(a)winehq.org> Reply-To: wine-devel(a)winehq.org To: wine-bugs(a)winehq.org http://bugs.winehq.org/show_bug.cgi?id=2969 Summary: CVS Regression - "Pure Virtual Function Call" Product: Wine Version: CVS Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-binary AssignedTo: wine-bugs(a)winehq.org ReportedBy: Andrew.Talbot(a)talbotville.com Patch http://cvs.winehq.org/patch.py?id=17288 causes Personal StockMonitor Gold to crash with error dialog: 'Microsoft Visual C++ Runtime Error':'Runtime Error! R6025 - pure virtual function call.' -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

2 1

Re: Another debugging tutorial
by gslink 20 May '05

20 May '05

There is only one problem with these documents. There aren't nearly enough of them!

1 0

shell32 icon indices and the "intialization hack"
by Michael Jung 20 May '05

20 May '05

Hello, Since the application of this patch http://www.winehq.org/hypermail/wine-cvs/2005/05/0232.html the "open folder" icon isn't displayed correctly any more in the file dialogs. There's a note in shell32/iconcache.c which states > hack to load the resources from the shell32.dll under a different dll name > will be removed when the resource-compiler is ready Furthermore shell32's shellfolders do some fancy stuff with the icon indices in their IShellFolder::GetIconLocation methods (they invert the indices). Is this the way windows does it? Could someone point me to information on this and the hack mentioned above? Thanks, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 1

Re: GDI: move 16-bit handles to the large heap
by Andreas Mohr 20 May '05

20 May '05

Hi, On Fri, May 20, 2005 at 12:18:07AM -0400, Dimi Paun wrote: > So we have to export a Wine specific function from GDI. > Big deal... :) What can we do, we have to cut the > Gordian Knot [http://www.gordiansolutions.com/TheKnot.htm] Well, umm, anyone an idea how Windows does this? ;-) (I assume that Windows has to do the same thing somehow) When I worked on the GDI system object mechanisms, I investigated that, but didn't find anything which could have done that. OTOH I'd bet that the Windows way of achieving this is equally messy... Andreas Mohr

2 1

Re: comctl32: Update LVGROUP struct to match msdn
by Dmitry Timoshkov 20 May '05

20 May '05

"James Hawkins" <truiken(a)gmail.com> wrote: > Changelog > * Update LVGROUP struct to match msdn. > --- include/commctrl.h 18 May 2005 09:43:23 -0000 1.144 > +++ include/commctrl.h 20 May 2005 05:14:22 -0000 > @@ -3439,6 +3439,8 @@ typedef struct LVGROUPA > UINT mask; > LPSTR pszHeader; > int cchHeader; > + LPSTR pszFooter; > + int cchFooter; > int iGroupId; > UINT stateMask; > UINT state; > @@ -3451,6 +3453,8 @@ typedef struct LVGROUPW > UINT mask; > LPWSTR pszHeader; > int cchHeader; > + LPWSTR pszFooter; > + int cchFooter; It appears that PSDK headers don't have LVGROUPA/W structures at all, but a unicode only LVGROUP instead. -- Dmitry.

1 0

Wiki tips
by Mike Hearn 20 May '05

20 May '05

A few tips on how to use the Wiki: - Embedding a block of code is best done like this: {{{ #!cplusplus if (foo) { bar; } }}} This will give it nice syntax highlighting, a monospace font and line numbers. - Unfortunately StudlyCaps as the Win32 API uses them is the same style that triggers WikiWording. To fix this surround Win32 API names like CreateWindow or IShellLink with backticks: eg `IShellLink`. This will disable WikiWording in that section and also format them with a monospace font. - If you have a word that it wants to WikiWord, prefix it with a ! mark. Don't do this just because there's no page for it yet, somebody may create one in future. Also don't do it for Win32 API names, use backticks instead. But it can be useful for some things. Those Wine developers who haven't yet made a todo list, go do it! It's really informative to be able to see what people are working on (not to mention interesting) and this way we can help cut down on duplication of effort. thanks -mike

5 4