December 2006 - Wine-devel - list.winehq.org

Reason for some process failures in kernel32 tests
by Paul Vriens 01 Jan '07

01 Jan '07

Hi, I've been trying to tackle some of the issues we have when trying to run some process tests (through winetest.exe, see also http://test.winehq.org/data) process.c:775: Test failed: CreateProcess (./kernel32_test.exe tests/process.c C:\TEMP\wt44.tmp "a\"b\\" c\" d) failed : 2 process.c:777: Test failed: Child process termination process.c:781: Test failed: Arguments:argvA0 expected './kernel32_test.exe', got '(null)' process.c:790: Test failed: CreateProcess (.\kernel32_test.exe tests/process.c C:\TEMP\wt45.tmp "a\"b\\" c\" d) failed : 2 process.c:792: Test failed: Child process termination process.c:796: Test failed: Arguments:argvA0 expected '.\kernel32_test.exe', got '(null)' process.c:810: Test failed: CreateProcess (..\wct12/kernel32_test.exe tests/process.c C:\TEMP\wt46.tmp "a\"b\\" c\" d) failed : 2 process.c:812: Test failed: Child process termination process.c:816: Test failed: Arguments:argvA0 expected '..\wct12/kernel32_test.exe', got '(null)' The reason for this particular one is that I'm running winetest.exe started from a command-file on my desktop. This means that the current directory is the desktop directory. The winetest gui shows that the working directory is (in this case) c:\temp\wct12. This value is however not passed to the tests when CreateProcess is run: main.c: 291 if (!CreateProcessA (NULL, cmd, NULL, NULL, TRUE, 0, 292 NULL, NULL, &si, &pi)) { The above means that the kernel32_test.exe has a working directory that is not c:\temp\wct12 (in this case again) and thus cannot find the executable when referenced relatively. All the test-results that are shown on http://test.winehq.org show more-or-less the same behavior. How can I retrieve the correct working directory (as shown in the winetest gui) and pass that to the single tests? (I think that would solve these particular issues). Cheers and thanks for any pointers, Paul.

3 5

OpenGL as child windows
by Chris Robinson 31 Dec '06

31 Dec '06

The topic of getting OpenGL to show and use more visuals/pixel formats than just the one the main window uses came up on IRC, and I was told to make a post here. One of the ideas was to create a child window of the main X window (which can be given a different visual) and have OpenGL use that for drawing. A simple test program I wrote (using X) seems to behave well. The child window stays relative to the parent, it remains fully connected (even with the wobbly effects of compositors like Beryl), and it can use a different visual. Since wgl is now a part of x11drv, it should be possible to make an X11 child window. Are there any problems with using this approach in Wine?

7 9

Re: Resend: user32: fix return value in DialogBoxParamA if no resourcecan be found + simple test (try 2)
by Dmitry Timoshkov 31 Dec '06

31 Dec '06

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote: > As Dmitry Timoshkov (thanks for that) the SetLastError was not necessary. > Here's updated patch. Probably the problem is that you need also handle both FindResourceW and LoadResource failures the same way by returning -1, and change 'return -1;' later to 'return 0;' (for invalid parent) as MSDN suggests. All that needs to be tested as well. Also DialogBoxParamW needs to be fixed as well. Probably other dialaog APIs (like DialogBoxIndirectParamAorW) need a review regarding that. -- Dmitry.

1 0

Re: ntdll: Map ESPIPE to STATUS_ILLEGAL_FUNCTION
by Andreas Mohr 31 Dec '06

31 Dec '06

Hi, On Sun, Dec 31, 2006 at 05:28:23PM +0800, Dmitry Timoshkov wrote: > Hello, > > Running RedAlert demo spits a lot of FIXMEs about converting errno 29 > (ESPIPE) to STATUS_UNSUCCESSFUL. In Linux /usr/include/asm/errno.h has > a comment /* Illegal seek */ for ESPIPE, so STATUS_ILLEGAL_FUNCTION seems > to be the best choice. > > Changelog: > ntdll: Map ESPIPE to STATUS_ILLEGAL_FUNCTION. The STATUS_ILLEGAL_FUNCTION name was rather misleading to me since it doesn't indicate at all that it's supposed to be pipe-related (however it's within the numeric range of many other pipe status codes!). So, given that this is mainly a pipe status code after all I'd say that's the best we can achieve right now. Of course, what really matters is what the receiving Win32 side *usually* expects after we encountered ESPIPE, and this might turn out to differ from your conversion ;). (is there any indication that RedAlert checks for a specific status code??) Andreas Mohr

2 1

Re: X11DRV: remove DesktopDoubleBuffered option
by Dmitry Timoshkov 31 Dec '06

31 Dec '06

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> wrote: > This patch removes the DesktopDoubleBuffered option. Support for this option should be removed from winecfg simultaneously with this change. -- Dmitry.

1 0

problems with installed wine
by Corey McClymonds 31 Dec '06

31 Dec '06

for almost a week now, wine has been acting weird. I compile wine and using it from the wine source tree, everything works perfectly. But if I make install it, then try to use it, all I get is a black screen that I have to alt-tab to get out of. On a note, it works fine if I run as root. I have blown away my .wine directory, it doesn't help. I compile from git. Corey McClymonds

2 1

Re: Resend: msxml.dll: nextNode and reset functions
by James Hawkins 30 Dec '06

30 Dec '06

On 12/28/06, Colin Pitrat <colin.pitrat(a)bull.net> wrote: > Hi, > > here is a patch I sent a few weeks ago implementing two functions in > msxml.dll, and the corresponding test. > I suggest sending the tests in one patch first, then send each function in a separate patch afterwards. -- James Hawkins

1 0

Re: Vijay Kiran Kamuju : comctl32: MonthCalendar - Fix highlighting of current date.
by Duane Clark 30 Dec '06

30 Dec '06

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: c5b8df481f2bb0362b57188a8c7df423030ba8b0 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=c5b8df481f2bb0362b57188a8… > > Author: Vijay Kiran Kamuju <infyquest(a)gmail.com> > Date: Sun Dec 24 13:31:56 2006 +0530 > > comctl32: MonthCalendar - Fix highlighting of current date. That does highlight the current date on startup. But I notice that when I click another date, the current date doesn't get unhighlighted.

5 6

Re: riched20: block recursive notification
by Matt Finnicum 30 Dec '06

30 Dec '06

On 12/30/06, Clinton Stimpson <cjstimpson(a)utwire.net> wrote: > > This patch blocks riched20 from recursivly sending an EN_CHANGE > notification. > Fixes bug 6985. > > Thanks, > Clinton Stimpson > > ChangeLog > Block recursive EN_CHANGE notifications. If you're adding a new variable to the ME_TextEditor structure then you should probably also initialize it in ME_MakeEditor. Naming the variable "notify" is somewhat ambiguous, and there seems to be an established convention of naming int's with the 'n' prefix, like nNotifiy. You should probably comment to explain what the variable is for or attempt to name it something more self evident. Maybe a BOOL would be more appropriate, unless you're intending to extend this to other notify calls as well. Lastly, I don't see why this patch is needed - it only prevents the ME_SendOldNotify (which just calls SendMessageA) from triggering another call of that same EN_CHANGE notification. I don't see why calling SendMessageA would cause ME_UpdateRepaint to be called. Maybe the application you're working with, in processing the EN_CHANGE message, is sending another message to which we wrongly are sending an EN_CHANGE notification - so thus we should fix our message handling of that. A quick look at MSDN shows that "The EN_CHANGE notification message is sent when the user has taken an action that may have altered text in an edit control." - it seems that we may be sending them whenever any action (user or not) has altered text in the control. We really could use some tests to see what should generate EN_CHANGE messages. Another possibility is that we don't handle the case where (again, from MSDN) "The EN_CHANGE notification is not sent when the ES_MULTILINE style is used and the text is sent through WM_SETTEXT." - perhaps your application has ES_MULTILINE set and uses a WM_SETTEXT in response to the EN_CHANGE notification? Thanks for your help with richedit, --Matt Finnicum

1 0

Re: wine-patch OleIconToCursor function
by Marcus Meissner 30 Dec '06

30 Dec '06

On Sat, Dec 30, 2006 at 04:49:27AM +0100, Bernard Ladenthin wrote: > Hello, > in the attachment is a small patch for the OleIconToCursor function. > The function works with this. I hope i can help with this and get a > response mail that this mail have received. I haven't any experiences > with git so it's a simply patch. > > I have tested it with the "Lexware Buchhalter 2005". > You can download it from http://server.ladenthin.net/bh2005.zip to see > that it works. Start with wine the "LxStart.exe" and turn over the > Text and Icon with the mouse, the icon is now the cursor. > > Best regards from Germany, > Bernard Ramon Ladenthin In general you do no need to edit Changelog yourself. Just add a note above the patch. Otherwise it looks fine to my eyes (and perhaps Alexandres too), thanks! Ciao, Marcus > diff --git a/ChangeLog b/ChangeLog > index 3b536b5..9723401 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,8 @@ > +2006-12-30 Bernard Ramon Ladenthin <bernard(a)ladenthin.net> > + > + * dlls/oleaut32/oleaut.c, dlls/oleaut32/stubs.c: > + oleaut32: Implement the function OleIconToCursor and remove the stub. > + > 2006-12-22 Dmitry Timoshkov <dmitry(a)codeweavers.com> > > * dlls/user32/tests/msg.c, dlls/winex11.drv/winpos.c: > diff --git a/dlls/oleaut32/oleaut.c b/dlls/oleaut32/oleaut.c > index d6a08a9..65a4174 100644 > --- a/dlls/oleaut32/oleaut.c > +++ b/dlls/oleaut32/oleaut.c > @@ -837,3 +837,19 @@ BOOL WINAPI DllMain(HINSTANCE hInstDll, > > return TRUE; > } > + > +/*********************************************************************** > + * OleIconToCursor (OLEAUT32.415) > + */ > +HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hIcon) > +{ > + FIXME("(%p,%p), (olepro32.dll), partially implemented.\n",hinstExe,hIcon); > + if (hIcon) > + return CopyCursor(hIcon); > + else > + return NULL; > + > + /* FIXME > + make a extended conversation from HICON to HCURSOR > + */ > +} > diff --git a/dlls/oleaut32/stubs.c b/dlls/oleaut32/stubs.c > index ac2d494..d87e76e 100644 > --- a/dlls/oleaut32/stubs.c > +++ b/dlls/oleaut32/stubs.c > @@ -33,15 +33,6 @@ > WINE_DEFAULT_DEBUG_CHANNEL(ole); > > /*********************************************************************** > - * OleIconToCursor (OLEAUT32.415) > - */ > -HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hicon) > -{ > - FIXME("(%p,%p), not implemented (olepro32.dll)\n",hinstExe,hicon); > - return S_OK; > -} > - > -/*********************************************************************** > * OleCreatePropertyFrameIndirect (OLEAUT32.416) > */ > HRESULT WINAPI OleCreatePropertyFrameIndirect( LPOCPFIPARAMS lpParams) >

2 1