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

Re: QUARTZ: Patch 2 - Move blitting operation to message thread and handle WM_PAINT
by Chris Robinson June 17, 2007

June 17, 2007

I have no direct comment on the patch (it's not really my area), but there's something I'd like to bring up. On Sunday 17 June 2007 01:51:56 pm a_villacis(a)palosanto.com wrote: > This patch moves the blitting code into the message thread. This is a setup > patch for the DirectDraw rewrite, but can be applied on its own after the > first patch. I'm all for changing the video renderer away from GDI, however I think it'd be better to move it to Direct3D or WGL instead of DDraw. I'm quite sure native quartz uses Direct3D when available, given that DDraw has been deprecated ever since DX7. Also, using native quartz's video renderer causes wined3d debug output for me, and as Stefan says, DDraw currently defaults to GDI so it wouldn't have come from that.

1 0

Re: dinput: Handle multiple keyboard and mouse devices. Get rid of the message window. [resend]
by Vitaliy Margolen June 17, 2007

June 17, 2007

Please don't apply this patch. I will need to change few more things that will affect parts of this patch. Vitaliy. Vitaliy Margolen wrote: > Please use this one instead. The other patch had accidentally escaped debug > statements. > > Fixes bug 7129. > > The whole idea here is to set/release hook only once for keyboard/mouse. > Then if we have more then one device, just call their hook handlers from > the single > top level handler. > > Also, since we don't really check the return status from setting the > hook itself > get rid of the message window. Just notify the thread it needs to > recheck device > lists and set/remove hooks. > > --- > dlls/dinput/dinput_main.c | 234 > +++++++++++++++++++++++++----------------- > dlls/dinput/dinput_private.h | 3 +- > dlls/dinput/keyboard.c | 54 ++-------- > dlls/dinput/mouse.c | 28 +----- > 4 files changed, 156 insertions(+), 163 deletions(-) > > > ------------------------------------------------------------------------ > >

1 0

re: vxd loading is broken last months
by Dan Kegel June 17, 2007

June 17, 2007

Vitaly Lipatov wrote: > INT21_CreateMagicDeviceHandle in winedos/int21.c uses the same dummy file > magic with open file with unix path from wine_get_server_dir(). > I guess we could use NtCreateFile on unix path before. > Now we need select correct place for such dummy files inside wine disk tree... Yeah. Evan has been sitting on a patch to fix this for a week now. Evan, I'd say it's time to post your minimal test and the fix, even if things are broken. - Dan

4 3

GDI+ programs
by Evan Stade June 16, 2007

June 16, 2007

Hi, I want to make some real applications work with the built-in wine GDI+. Does anyone know of some programs that use GDI+ that would be good for guiding my development? thanks, Evan Stade

5 4

vxd loading is broken last months
by Vitaly Lipatov June 16, 2007

June 16, 2007

CreateFile is not success with somename.vxd (somename.vxd.so exists in /usr/lib/wine) As known open_vxd_handle( LPCWSTR name ) in kernel32/vxd.c have to open dummy file in the wineserver directory. It try use NtCreateFile for open Unix path /tmp/.wine/... and get failure. What part have to be fixed? NtCreateFile or open_vxd_handle? -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

2 2

cmd.exe console question
by Ann & Jason Edmeades June 15, 2007

June 15, 2007

Out of interest, is there any way to get (read here 'write code for') the wine's cmd.exe better integrated in the window you launch it from when it is not in wineconsole mode. For example, I would love to see cls clear the screen (I suppose I could just launch 'clear'!), or command retrieval work (and, but by far the lowest priority, colo(u)rs). I *know* you can do it with wineconsole with user and curses backend, but in a 'normal' shell window the shell itself manages it, and is there any programming interface to that? One problem I can perceive is I cant tell between output being redirected to a file, or output being redirected to the shell window (neither query the console attributes) Jason

1 0

Re: [PATCH 2/2] dinput: Handle multiple keyboard and mouse devices.
by Detlef Riekenberg June 15, 2007

June 15, 2007

On So, 2007-06-10 at 19:20 -0600, Vitaliy Margolen wrote: > Should fix bug 7129. > > The whole idea here is to set/release hook only once for keyboard/mouse. > Then if we have more then one device, just call their hook handlers from the single > top level handler. > --- > dlls/dinput/dinput_main.c | 82 ++++++++++++++++++++++++++++++++++++++--- > dlls/dinput/dinput_private.h | 4 ++- > dlls/dinput/keyboard.c | 54 ++++++--------------------- > dlls/dinput/mouse.c | 28 ++------------ > 4 files changed, 95 insertions(+), 73 deletions(-) Works the same as native dinput. Thanks a lot. The sensitive high-speed Mouse-Accellerator for the RMB is also present with native dinput. I will add a new bug for that regression. Any Ideas, where to search? ("dlls/" or "dlls/winex11.drv/") As additional hint, the moving direction is most times fixed: When i start moving up/right (45*) while the RMB id pressed, then the app still see 45* when I move the mouse in a different direction (down or left as examples). Looks like a value is not reset. -- By by ... Detlef

1 0

Re: gdiplus: graphics tests [try2]
by Alexandre Julliard June 15, 2007

June 15, 2007

"Evan Stade" <estade(a)gmail.com> writes: > +static const INT drawline_bmp1[192] = > +{0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff, > + 0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff, > + 0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff, > + 0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff, > + 0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff,0xffffffff, I don't think we want to do that sort of thing. We can't guarantee that the results will be exact pixel for pixel, and we don't really care. And even if we did, hardcoding the image in the source this way is unmaintainable. If you want to check the results, you should write an app that draws various things and check it visually against Windows, but I don't think that's something that can be part of the regression test suite. -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: [3/5] widl: Add tests for encapsulated unions
by Dan Hipschman June 15, 2007

June 15, 2007

On Thu, Jun 14, 2007 at 06:28:41PM -0700, Dan Hipschman wrote: > + if (strcmp(winetest_platform, "wine") != 0) /* crashes wine */ > + { > + eu.t = ENCU_I; > + eu.tagged_union.i = 7; > + ok(square_encu(&eu) == 49.0, "RPC square_encu\n"); > + > + eu.t = ENCU_F; > + eu.tagged_union.f = 3.0; > + ok(square_encu(&eu) == 9.0, "RPC square_encu\n"); > + } Hi. So, I realize the usual way to handle tests that crash wine (besides fixing the bug that causes the crash), is to "if (0)" or comment the test out, as in ntdll/tests/reg.c, or rpcrt4/tests/ndr_marshall.c, but this patch tests more than wine, it also tests widl, and it's therefore not just documentation. If I "if (0)" the test out (or worse, it doesn't get accepted), I'm going to have to edit the test each time I run it on windows to re-add the encapsulated union test so I can verify that the widl output stubs still work on windows. One solution is to do something like this: #ifndef TESTS_THAT_CRASH_WINE # define TESTS_THAT_CRASH_WINE 0 #endif ... if (TESTS_THAT_CRASH_WINE) { eu.t = ENCU_I; eu.tagged_union.i = 7; ok(square_encu(&eu) == 49.0, "RPC square_encu\n"); eu.t = ENCU_F; eu.tagged_union.f = 3.0; ok(square_encu(&eu) == 9.0, "RPC square_encu\n"); } So at least I can just compile with -DTESTS_THAT_CRASH_WINE=1 on windows, which is easy to stick in a batch file or something. Otherwise, I'm stuck maintaining a patch that has to be applied before each compile. Plus, it means I'm the only one who's probably testing encapsulated unions on windows, so it's only getting tested on one platform. Any chance something like the original patch can get into wine?

2 1

Liberation
by Louis. Lenders June 15, 2007

June 15, 2007

Hi, this is mainly a follow up to the thread here http://www.winehq.org/pipermail/wine-devel/2007-May/057092.html , to give it a new boost.... Question is, are there any plans to include Liberation fonts in wine? I gave it a good testing last two weeks, that is, i converted the fonts with Hans' Leidekkers script , from link above, and tested the "Arial-compatible" font quite a bit, with several applications. It all seems to work great, no issues / problems found. Several applications would be very happy , if this were to be included in wine. Any comments? Some of the tested apps: xchat --> just aborts silently without arial font Book worms adventures --> pops up a crash window without arial font d3d9-samples from DirectX 9.0 SDK --> Don't show any text without arial font + a lot more that just look prettier with arial font. --------------------------------- Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your freeaccount today.

7 10

gdiplus no longer available in Vista?
by Paul Vriens June 15, 2007

June 15, 2007

Hi, I had a look but wasn't able to find gdiplus.dll on my Vista box. This most likely means our test has to be re-written. I'll wait with that till the cross-compiling of the gdiplus tests is fixed. Cheers, Paul.

2 1

Problem with the Ubuntu 7.04 (Feisty) package (again)
by Ben Hodgetts (Enverex) June 15, 2007

June 15, 2007

We've had a few people report issues with the Ubuntu Feisty .38 package in the WineHQ repo lately (http://wine.budgetdedicated.com/archive/ubuntu/feisty/wine_0.9.38~winehq0~u…) the specific issue being that the fonts are all missing on most things, in other places only the first few letters may be shown. Originally I thought this was something to do with them lacking fonts but in each case telling them to install the .37 package instead fixed the issue meaning it's more likely to be a problem with the .38 package. Any ideas Scott? Ben H.

1 0

Re: [3/5] widl: Add tests for encapsulated unions
by Dan Hipschman June 15, 2007

June 15, 2007

On Thu, Jun 14, 2007 at 06:28:41PM -0700, Dan Hipschman wrote: > > This adds a test for encapsulated unions, but it crashes wine. The exact Hmm, now that I reread this, I think I said this wrong. The test does crash wine, but I wrote my patch so that it doesn't run on wine. So, doing "make check" in dlls/rpcrt4/tests will *not* crash wine, it just won't run the encapsulated union tests. The encapsulated union tests *will* run, and succeed, on windows, however. I felt this was best because that way all of widl's output can still continue to be tested on windows, and everything that can be tested in wine without crashing still will be.

1 0

Re: Uninstaller
by Misha Koshelev June 14, 2007

June 14, 2007

First of all, of course I am not Alexandre. But I have to say I think I agree with James on this, with regards to submitting just one patch with the correct spacing. I can see how seeing one patch without any spacing changes keeps the diff very simple (I am assuming this is why you submitted your patches in this way), but at the same time I would assume that if Alexandre really wants to see what changed in this way after applying the one patch you will send with correct spacing, he can just type: git-diff -b and see something very similar to your patch #1 (ignores whitespace, same effect). Other than that, I did not see anything obviously wrong with the patch upon a quick look. If you don't hear from anyone else on wine-devel, I would suggest resubmitting as one patch with correct indentation as James suggested. If you don't see it committed after a while (maybe a week or so, maybe longer) I would either get in touch with the list again or try to get in touch with Alexandre to see if he has any specific comments. Hope that helps. Misha

3 4

Re: include/uxtheme.h : enum THEMESIZE
by Michael Stefaniuc June 14, 2007

June 14, 2007

Nicolas (dyalog.com) wrote: > according to MSDN, include/uxtheme.h should define an "enum THEMESIZE", > which is typedefed to "THEME_SIZE", > rather than typedef the enum {} to "THEMESIZE" as it is currently. > http://msdn2.microsoft.com/en-us/library/ms649970.aspx > > note that dlls/uxtheme/draw.c uses this definition so must also be patched. Please merge those 2 changes into one patch as one without the other make the Wine source to not compile anymore. And please use unified diff format; the draw.c.patch isn't a unified diff. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: user32: improve cut/copy/paste behavior of password edit boxes
by Vitaly Lipatov June 14, 2007

June 14, 2007

В сообщении от 14 июня 2007 Lei Zhang написал(a): > Hi, > > This patch prevents cutting/copying text from edit boxes with the > ES_PASSWORD style. It also corrects the paste behavior of password Why we need prevent it? > edit boxes when the clipboard is empty. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

Re: Juan Lang : comdlg32: Initialize file dialog controls before creating dialog.
by Lei Zhang June 14, 2007

June 14, 2007

Hi Juan, With this patch, the bottom of file dialogs are cut off such that the file type dropdown and the cancel button can barely be seen. - Lei On 6/7/07, Alexandre Julliard <julliard(a)wine.codeweavers.com> wrote: > Module: wine > Branch: master > Commit: 13f18ee7593364a2a685fed2bdfa814431906f0c > URL: http://source.winehq.org/git/wine.git/?a=commit;h=13f18ee7593364a2a685fed2b… > > Author: Juan Lang <juan_lang(a)yahoo.com> > Date: Thu Jun 7 12:27:11 2007 -0700 > > comdlg32: Initialize file dialog controls before creating dialog. > > --- > > dlls/comdlg32/filedlg.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/comdlg32/filedlg.c b/dlls/comdlg32/filedlg.c > index f63e64f..5409b91 100644 > --- a/dlls/comdlg32/filedlg.c > +++ b/dlls/comdlg32/filedlg.c > @@ -1037,11 +1037,11 @@ INT_PTR CALLBACK FileOpenDlgProc95(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM l > so it will be easily accessible through a GetPropA(...) */ > SetPropA(hwnd, FileOpenDlgInfosStr, (HANDLE) fodInfos); > > + FILEDLG95_InitControls(hwnd); > + > fodInfos->DlgInfos.hwndCustomDlg = > CreateTemplateDialog((FileOpenDlgInfos *)lParam, hwnd); > > - FILEDLG95_InitControls(hwnd); > - > if (fodInfos->DlgInfos.hwndCustomDlg) > { > RECT rc; > > > >

2 2

Re: [3/5] WineD3D: Present does not clear the depth stencil
by H. Verbeet June 14, 2007

June 14, 2007

On 14/06/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > The patch removes the clearing from Present, except for the DISCARD swap effect if the d3d trace channel is on. It sounds a bit questionable to have different behaviour depending on the debug channel.

2 2

Re: [crypt32/tests 2/2] Vista uses a different error code (RESEND)
by Dmitry Timoshkov June 14, 2007

June 14, 2007

"Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: > ret = CryptSIPRetrieveSubjectGuid(tempfileW, NULL, &subject); > ok ( !ret, "Expected CryptSIPRetrieveSubjectGuid to fail\n"); > ok ( GetLastError() == ERROR_FILE_INVALID || > + GetLastError() == ERROR_INVALID_PARAMETER /* Vista */ || > GetLastError() == S_OK /* Win98 */, > - "Expected ERROR_FILE_INVALID or S_OK, got 0x%08x\n", GetLastError()); > + "Expected ERROR_FILE_INVALID, ERROR_INVALID_PARAMETER or S_OK, got 0x%08x\n", GetLastError()); S_OK is an OLE error, ERROR_SUCCESS is correct name in this case. It's not your fault at all, but since you are fixing this code it would be nice to fix it as well. -- Dmitry.

2 1

Re: Fixed the WriteEnvironmentStrings action [try2]
by Dmitry Timoshkov June 14, 2007

June 14, 2007

"James Hawkins" <truiken(a)gmail.com> wrote: > + while (*cptr && (*cptr == '=' || *cptr == '+' || > + *cptr == '-' || *cptr == '!' || *cptr == '*')) > + { > + switch (*cptr) > + { > + case '=': > + *flags |= ENV_ACT_SETALWAYS; > + break; > + case '+': > + *flags |= ENV_ACT_SETABSENT; > + break; > + case '-': > + *flags |= ENV_ACT_REMOVE; > + break; > + case '!': > + *flags |= ENV_ACT_REMOVEMATCH; > + break; > + case '*': > + *flags |= ENV_MOD_MACHINE; > + break; > + default: > + ERR("Unknown Environment flag: %c\n", *cptr); > + return ERROR_FUNCTION_FAILED; > + } > + > + cptr++; > + (*name)++; > + } A simple 'goto' in the 'default:' case, or using while (*cptr) { if (*cptr == '=') else if (*cptr == '+') { } else if (...) { } else break; } would help to avoid double comparisons and simplify the code. -- Dmitry.

1 0

Re: patch for winefile.
by Dmitry Timoshkov June 14, 2007

June 14, 2007

"Ivan Sinitsin" <ivan(a)etersoft.ru> wrote: > + static const WCHAR sFont[] = {'M','i','c','r','o','s','o','f','t',' ','S','a','n','s',' ','S','e','r','i','f','\0'}; > + HDC hdc = GetDC(0); ... > + if( RegQueryValueEx( hKey, reg_font_facename, NULL, &type, > + (LPBYTE) &logfont.lfFaceName, &sizeW) != ERROR_SUCCESS ) > + strcpyW(logfont.lfFaceName,sFont); It's not very useful to use by default the font that is not available on any Linux installation by default. I'd suggest to use GetStockObject(DEFAULT_GUI_FONT) instead. And you are leaking an hdc. > + LOGFONT logfont; > > wi.cbSize = sizeof( WINDOWINFO ); > GetWindowInfo(Globals.hMainWnd, &wi); > width = wi.rcWindow.right - wi.rcWindow.left; > height = wi.rcWindow.bottom - wi.rcWindow.top; > + GetObject((HGDIOBJ)Globals.hfont, sizeof(logfont), (LPVOID)&logfont); This cast is not needed. -- Dmitry.

1 0

Uninstaller
by Tom Spear June 14, 2007

June 14, 2007

It's been a while since I brought anything up on this, so I figured I'd ask what was wrong with the last set of patches I sent.. The patches are at [1] and [2], the discussion generated by them are at [3], [4], [5], and [6]... Summary, I did everything I was told in private by a developer (who isn't alexandre, i know), and I got told by another developer, who also isn't alexandre, to fix some things that the first developer said didn't need fixing.. So should I fix those things, or is there some other reason it wasn't committed? [1] http://www.winehq.org/pipermail/wine-patches/2007-June/039911.html [2] http://www.winehq.org/pipermail/wine-patches/2007-June/039912.html [3] http://www.winehq.org/pipermail/wine-devel/2007-June/057253.html [4] http://www.winehq.org/pipermail/wine-devel/2007-June/057254.html [5] http://www.winehq.org/pipermail/wine-devel/2007-June/057255.html [6] http://www.winehq.org/pipermail/wine-devel/2007-June/057258.html Someone please let me know what is wrong (I'd love to hear from The Man, if he has time to take a look), but anyone's responses are welcome (hopefully I get more than 2 reponses this time lol).... -- Thanks Tom

1 0

Re: [GDI+: 7/7] implemented GdipDrawImage
by Evan Stade June 14, 2007

June 14, 2007

On 6/13/07, Evan Stade <estade(a)gmail.com> wrote: > Hi, > > changelog: > *implemented GdipDrawImage > > dlls/gdiplus/gdiplus.spec | 2 +- > dlls/gdiplus/graphics.c | 28 ++++++++++++++++++++++++++++ > include/gdiplusflat.h | 1 + > 3 files changed, 30 insertions(+), 1 deletions(-) > > -Evan Stade > > ignore this patch

1 0

msi: Fixed the WriteEnvironmentStrings action
by Misha Koshelev June 14, 2007

June 14, 2007

> + res = RegQueryValueExW(env, name, NULL, &type, NULL, &size); > + if (res != ERROR_FILE_NOT_FOUND || (res == ERROR_SUCCESS && type != REG_SZ)) > + goto done; Hate to point this out but isn't this the exact same error I made in my first (and second) patch from last night? I think it should be: if ((res != ERROR_FILE_NOT_FOUND && res != ERROR_SUCCESS) || (res == ERROR_SUCCESS && type != REG_SZ)) goto done; In your statement, if res is ERROR_SUCCESS it will always goto done no matter what the value of type, because ERROR_SUCCESS != ERROR_FILE_NOT_FOUND. Guess logic errors in if statements are contagious :) Misha

1 0

Re: msi: Do not use type value if call to RegQueryValueEx failed.
by James Hawkins June 13, 2007

June 13, 2007

On 6/12/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > This is necessary (bug not sufficient, see my comment in the bug report that I am about > to post) to fix bug 8678. > > It is also clearly correct, as checking the type "returned" by RegQueryValueEx when it fails > makes no sense. > size = 0; res = RegQueryValueExW(env, var, NULL, &type, NULL, &size); - if ((res != ERROR_MORE_DATA && res != ERROR_FILE_NOT_FOUND) || type != REG_SZ) + if ((res != ERROR_MORE_DATA && res != ERROR_FILE_NOT_FOUND) || + (res == ERROR_SUCCESS && type != REG_SZ)) { RegCloseKey(env); return res; This is wrong. If res == ERROR_SUCCESS, then the first condition evaluates to TRUE and we fall through to exit, but then again, res will never be ERROR_SUCCESS after that particular call. Either way, I have a patch ready to send in that fixes the entire action. -- James Hawkins

3 2