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

Bugzilla is still annoying
by Scott Ritchie June 11, 2007

June 11, 2007

What was the status on the offer to upgrade bugzilla? Lately I've been annoyed by how it sends out emails whenever someone subscribes/unsubscribes from a bug. Is this a simple configuration setting, or do we need to upgrade? Thanks, Scott Ritchie

2 1

Re: [GDI+: 2/5] added Pens implementation, test
by Alexandre Julliard June 11, 2007

June 11, 2007

"Evan Stade" <estade(a)gmail.com> writes: > Hi, > > Changelog: > *added pen implementation > *added just enough memory and startup implementation to support pens > *defined some types > *added pen test You need to send that stuff in smaller chunks, for instance there's no reason to put startup implementation and pens in the same patch. Also things like the GpBrush definition should be part of the brush patch not the pen one. The tests can also be a separate patch. I'll commit the startup code part of the patch, have a look at this to see what a minimal patch should look like. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] setupapi/tests: Add rudimentary tests for InstallHinfSectionA/W.
by James Hawkins June 11, 2007

June 11, 2007

On 6/10/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > Tested on WinXP and Win98 (and of course wine). > --- > dlls/setupapi/tests/Makefile.in | 1 + > dlls/setupapi/tests/install.c | 152 +++++++++++++++++++++++++++++++++++++++ > 2 files changed, 153 insertions(+), 0 deletions(-) > +static void test_install(LPCSTR filename) +{ + char cmdline[MAX_PATH * 2]; + LONG ret; + + sprintf(cmdline, "DefaultInstall 128 %s\\%s", CURR_DIR, filename); + + if (useW == -1) + { + HKEY hkey; + useW = 1; + _InstallHinfSection(NULL, NULL, cmdline, 0); + if (RegOpenKey(HKEY_CURRENT_USER, "Software\\Wine\\setupapitest", &hkey) == ERROR_SUCCESS) + RegCloseKey(hkey); + else + { + skip("InstallHinfSectionW is broken, using InstallHinfSectionA\n"); + useW = 0; + _InstallHinfSection(NULL, NULL, cmdline, 0); + } + } + else _InstallHinfSection(NULL, NULL, cmdline, 0); + + ret = RegDeleteKey(HKEY_CURRENT_USER, "Software\\Wine\\setupapitest"); + ok(ret == ERROR_SUCCESS, "Expected registry key Software\\Wine\\setupapitest to exist, RegDeleteKeyA returned %d\n", ret); +} + +static void test_InstallHinfSection(void) +{ + create_inf_file(inffile); + test_install(inffile); + ok(DeleteFile(inffile), "Expected source inf to exist, last error was %d\n", GetLastError()); +} This would be much simpler if you didn't use the extra test_install function. What is the point of that? Unit test functions should be atomic. Each test function should create the files it needs, and make sure the files it created are cleaned up by the end of the function (replace files with registry keys, etc). You can also look at it like this: you should be able to remove test function x without affecting any other tests, which is not the case here. The check for DeleteFile would obviously fail. Unit tests should be clear and easy to understand what's being tested, and honestly, this code confused me on my first reading. + _InstallHinfSection(NULL, NULL, cmdline, 0); Why aren't you checking the return value, or GetLastError? + skip("InstallHinfSectionW is broken, using InstallHinfSectionA\n"); How is it broken? This needs to be clarified with a comment. You really should just test only the A function in the first place though. + if (pInstallHinfSectionW && !pInstallHinfSectionA) useW = 1; Is there ever a time when InstallHinfSectionA doesn't exist? If it doesn't exist, you're going to crash if InstallHinfSectionW is 'broken': + skip("InstallHinfSectionW is broken, using InstallHinfSectionA\n"); + useW = 0; + _InstallHinfSection(NULL, NULL, cmdline, 0); -- James Hawkins

2 2

Re: [GDI+: 3/5] added graphics implementation and tests
by Dmitry Timoshkov June 11, 2007

June 11, 2007

"Evan Stade" <estade(a)gmail.com> wrote: > +GpStatus WINGDIPAPI GdipDrawLineI(GpGraphics *graphics, GpPen *pen, INT x1, > + INT y1, INT x2, INT y2) > +{ > + HGDIOBJ old_obj; > + > + if(!pen || !graphics) > + return InvalidParameter; > + > + old_obj = SelectObject(graphics->hdc, pen->gdipen); > + MoveToEx(graphics->hdc, x1, y1, NULL); > + LineTo(graphics->hdc, x2, y2); > + SelectObject(graphics->hdc, old_obj); > + > + return Ok; > +} > + > +GpStatus WINGDIPAPI GdipDrawRectangleI(GpGraphics *graphics, GpPen *pen, INT x, > + INT y, INT width, INT height) > +{ > + LOGBRUSH lb; > + HPEN hpen; > + HGDIOBJ old_obj; > + > + if(!pen || !graphics) > + return InvalidParameter; > + > + lb.lbStyle = BS_SOLID; > + lb.lbColor = pen->color; > + lb.lbHatch = 0; > + > + hpen = ExtCreatePen(PS_GEOMETRIC | PS_ENDCAP_SQUARE, (INT) pen->width, > + &lb, 0, NULL); Any reason why are you creating a new pen in GdipDrawRectangleI, and while using an existing one in GdipDrawLineI? -- Dmitry.

2 2

Re: [GDI+: 5/5] Added GdipFillPie
by Dmitry Timoshkov June 11, 2007

June 11, 2007

"Evan Stade" <estade(a)gmail.com> wrote: > +GpStatus WINGDIPAPI GdipFillPie(GpGraphics *graphics, GpBrush *brush, REAL x, > + REAL y, REAL width, REAL height, REAL startAngle, REAL sweepAngle) > +{ > + LOGBRUSH lb; > + HPEN hpen; > + HGDIOBJ old_pen, old_brush; > + REAL x_0, y_0, radStartAngle, radFinishAngle, hypotenuse, > + x_1, y_1, x_2, y_2; > + > + if(!brush || !graphics) > + return InvalidParameter; > + > + lb.lbStyle = BS_SOLID; > + lb.lbColor = brush->color; > + lb.lbHatch = 0; > + > + hpen = ExtCreatePen(PS_GEOMETRIC | PS_ENDCAP_SQUARE, 1, &lb, 0, NULL); > + > + old_pen = SelectObject(graphics->hdc, hpen); > + old_brush = SelectObject(graphics->hdc, brush->gdibrush); GdipFillPie takes only a brush in its parameters, not a pen. Shouldn't you simply select GetStockObject(NULL_PEN) instead of creating a 1 pixel pen with a color of brush? -- Dmitry.

2 1

RE: [PATCH] dinput: Use window subclassing to monitor focus looses away from monitored windows. [try 3]
by Vitaliy Margolen June 10, 2007

June 10, 2007

Please don't apply this and other dinput patches. It doesn't work for multiply acquired windows. This approach does not handle "nesting" - when same window is being acquired several times by different devices. I guess I will have to go back to WINDPROC hook after all. Vitaliy.

1 0

Re: [PATCH 3/3] winex11.drv: Use new mouse grabbing code for ddraw.
by Stefan Dösinger June 10, 2007

June 10, 2007

Am Sonntag, 10. Juni 2007 02:15 schrieb Vitaliy Margolen: > Remove old code that is not thread safe. > --- > dlls/winex11.drv/x11ddraw.c | 50 > +------------------------------------------ 1 files changed, 1 > insertions(+), 49 deletions(-) The ddraw code in winex11.drv isn't called from anywhere afaik, and alexandre doesn't really like it to I planned to remove it somewhen.

1 0

makedep problem on mingw
by Steven Edwards June 9, 2007

June 9, 2007

Hi, I won't have a chance to follow up on this until Wednesday but maybe someone can spot the problem before then. Doing a normal checkout and configure on mingw works fine but the generated makefile in wine/tools/ seems to have a problem with the dependency tracking. Maybe the recent makedep changes and windows don't agree. $ make ../tools/makedep -C. -S.. -T.. bin2res.c fnt2bdf.c fnt2fon.c make_ctests.c make dep.c relpath.c sfnt2fnt.c Makefile:423: *** unterminated variable reference. Stop. Attached is the buggy Makefile Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Re:user32:tests:msg Add test for switch mdi children.[try2] What is wrong with it?
by Anatoly Lyutin June 9, 2007

June 9, 2007

Subject. Thanks for attention. -- Best regards Anatoly Lyutin.

2 1

Re: [5/5] WineD3D: Some render target->texture blit context handling
by H. Verbeet June 9, 2007

June 9, 2007

On 08/06/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > + ActivateContext(This, src_surface, CTXUSAGE_RESOURCELOAD); > + if (GL_SUPPORT(ARB_MULTITEXTURE)) { > + GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB)); > + checkGLcall("glActiveTextureARB"); > + } > + IWineD3DDeviceImpl_MarkStateDirty(This, STATE_SAMPLER(0)); > + IWineD3DSurface_PreLoad(dst_surface); Why do you need this? The surface should be preloaded in attach_surface_fbo as soon as it's attached. Also, although stretch_rect_fbo() is currently only used for onscreen -> texture blits, it should not be limited to that, so I think the ActivateContext should be further down inside both the "if (src_swapchain)" and "if (dst_swapchain)" blocks.

2 4

Using [GS]etWindowLong{Ptr} in tests
by Saulius Krasuckas June 8, 2007

June 8, 2007

Hello. I see some tests call [GS]etWindowLongPtr(..., GWLP_WNDPROC, ...). I think this is somewhat confusing. API offers both A- an W- versions of this function, while at my first glance I cannot firmly decide, what used name does refer to. Shouldn't occurences be renamed to ...WindowLongPtrA() here (or even all occurrences {by not requiring second parameter == GWLP_WNDPROC}) ? Same question stands for [GS]etWindowLong().

4 16

zip folders support
by Alexander Shabanov June 8, 2007

June 8, 2007

Good day, First of all: big thank you for your great wine! Several days ago I made a post on the wine groups: > Does anyone tried to use zip folders support on wine? Is is possible? > I tried to copy zipfldr.dll and register it, but it does not work. > Since I am a developer I would try to do it. Could you please suggest > a point to start? As far as I know the interfaces of zipfldr.dll are > not documented, so it will not be simple task. I would like to ask you about an interfaces of zip folder dynamic library - if they're known I would implement zip folders support. It was suggested to ask someone from wine development team to get more information about that. Please, take a look to the discussion in the wine group about that: http://groups.google.com/group/comp.emulators.ms-windows.wine/browse_thread… If you have an information about zip folders please let me know. btw: maybe an implementation of the such support is prohibited on Linux due to some restrictions with LZW algorithm? Or maybe Microsoft did not care about documenting this library? Unfortunately I am not found any information about this library in MSDN in the topics for developers. Thanks in advance and kind regards, Alexander Shabanov

2 1

Re: zip folders support
by Juan Lang June 8, 2007

June 8, 2007

Hi Alexander, as you say in the quoted thread, > zip filder support is encapsulated within zipfldr.dll which is > standard COM-component (i.e. exposes DllRegisterServer/ > DllCanUnloadNow). > For example in WinXP zip folders support may be switched off by > unregistering zipfldr.dll via regsvr32. > Therefore I may suspect that this support is given on the user (shell > only) level, because CreateFile can't be applied to the files within > zip folder You're correct, zipfldr.dll only register shell extension. As such, it's probably of limited use in Wine, as we really only use the shell for file dialogs - we don't implement an "explorer" that browses the shell namespace. So, may I ask: what app requires such a thing? And you say: > I tried to copy zipfldr.dll and register it, but it does not work. What exactly doesn't work? This probably best captured as a bug, by the way. Enter a bug describing what you expect to happen, what doesn't happen, etc. --Juan ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/

1 0

Re: shell32: conformance tests for unicode filenames and fix a bug forfile deletion (try 2)
by Dmitry Timoshkov June 8, 2007

June 8, 2007

"Nigel Liang" <ncliang(a)gmail.com> wrote: > +static const WCHAR UNICODE_PATH[] = {'c',':','\\','w',0x00ef,0x00f1,0x00eb, > + 't',0x00e8,'s','t','\0','\0'}; /* "c:\winetest" */ The name above is definitely not "c:\winetest", also if you need a double termination '\0' state it specifically. > +static int IsWin9x(void) > +{ > + OSVERSIONINFO winver; > + GetVersionEx(&winver); > + return winver.dwPlatformId==VER_PLATFORM_WIN32_WINDOWS; > +} (GetVersion() & 0x80000000) is much shorter way to detect win9x, but if you need to test whether the platform supports unicode that's wrong, have a look at other tests how it's done there. -- Dmitry.

3 5

Re: [NTDLL] Simple test suite for IO completion APIs
by Alexandre Julliard June 8, 2007

June 8, 2007

Andrey Turkin <andrey.turkin(a)gmail.com> writes: > Depends on previous NTDLL patch ('cause it uses previously stubbed out api) > > --- > dlls/ntdll/tests/Makefile.in | 1 + > dlls/ntdll/tests/completion.c | 212 > +++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 213 insertions(+), 0 deletions(-) Please merge that code with the other async I/O tests in file.c. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] wined3d: For ps_2_0 and higher, call shader_get_registers_used() in IWineD3DPixelShaderImpl_SetFunction
by Stefan Dösinger June 8, 2007

June 8, 2007

Am Donnerstag, 7. Juni 2007 23:52 schrieb H. Verbeet: > For pre-2.0 pixel shaders the stateblock is used to determine the > sampler types, so we need to wait until CompileShader to do this. For > ps_2_0 and higher there is no such requirement. > > Changelog: > - For ps_2_0 and higher, call shader_get_registers_used() in > IWineD3DPixelShaderImpl_SetFunction Are you going to compile >= 2.0 shaders in SetFunction? How would that work with other things that may need delayed compilation, like fog or (future) srgb write correction?

2 2

Re: gdiplus: added stub implementation of gdiplus.dll
by Mounir IDRASSI June 8, 2007

June 8, 2007

Hi, You also have to modify other files in order to integrate your stub implementation to the wine build chain: Makefile.in, configure and configure.ac in the wine root directory, Makefile.in in the "dlls" directory. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr Evan Stade wrote: > Changelog: > * added stub implementation of gdiplus.dll (3 files) > > dlls/gdiplus/Makefile.in | 16 + > dlls/gdiplus/gdiplus.c | 45 +++ > dlls/gdiplus/gdiplus.spec | 609 > +++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 670 insertions(+), 0 deletions(-)

6 7

FYI: SHELL_ArgifyW and unquoted %1, non-native behavior
by Misha Koshelev June 8, 2007

June 8, 2007

Sorry if I am just filling your inboxes, but I thought I'd at least throw this out there before I forget about it. When I was making my ShellExecute DDE conformance tests to get Vector NTI associated files to open correctly (using DDE and without the fake "%1" that wine was adding to all shell/?/command strings that don't have one at the time), I noticed another non-native behavior in wine. Specifically, when %1 is in a command or a ddeexec string on Windows (XP), the filename is passed as is. However, under wine quotes are added to this argument in SHELL_ArgifyW. Since this did not affect anything Vector NTI related, I decided to just not worry about this behavior at the time and just to change my conformance test so it wouldn't tickle this. However, I am just wondering what the general policy is about something like this? Should it just be left alone until an app is found that somehow depends on this (I am thinking this is the case)? Or do we want to try to correct this when we discover this, that way perhaps preventing this bug in this application from ever even occuring? Thanks Misha

1 0

Re: ole32: Remove stack-based string buffer inFileMonikerImpl_DecomposePath
by Dmitry Timoshkov June 7, 2007

June 7, 2007

"Ulrich Czekalla" <ulrich.czekalla(a)utoronto.ca> wrote: > - WCHAR word[MAX_PATH]; > - int i=0,j,tabIndex=0; > + LPOLESTR word; > + int i=0,j,tabIndex=0, ret=0; > LPOLESTR *strgtable ; > > int len=lstrlenW(str); > > TRACE("%s, %p\n", debugstr_w(str), *stringTable); > > - strgtable =CoTaskMemAlloc(len*sizeof(LPOLESTR)); > + strgtable = CoTaskMemAlloc(len*sizeof(LPOLESTR)); > > if (strgtable==NULL) > return E_OUTOFMEMORY; > > + word = CoTaskMemAlloc((len + 1)*sizeof(LPOLESTR)); Shouldn't it be *sizeof(WCHAR) or *sizeof(OLECHAR)? -- Dmitry.

2 1

Could somebody run the wininet/ftp tests on Wine?
by Paul Vriens June 7, 2007

June 7, 2007

Hi, Some time ago I added some ftp-tests. After I've seen a lot of wininet patches I just tried (current GIT) to run the ftp tests again on Wine. This time I get some failure (or actually successes): [paul(a)LatitudeC600 tests]$ make ftp.ok ../../../tools/runtest -v -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so ftp.c && touch ftp.ok ftp.c:303: Test succeeded inside todo block: Expected ERROR_SUCCESS, got 0 ftp.c:363: Test succeeded inside todo block: Expected ERROR_SUCCESS, got 0 ftp.c:375: Test succeeded inside todo block: Expected ERROR_SUCCESS, got 0 ftp.c:485: Test failed: Expected FtpOpenFileA to succeed ftp.c:858: Test succeeded inside todo block: Expected ERROR_SUCCESS or ERROR_FILE_NOT_FOUND (win98), got 0 ftp: 128 tests executed (14 marked as todo, 5 failures), 0 skipped. make: *** [ftp.ok] Error 5 The strange thing is that the calls fail yet the last error is set to ERROR_SUCCESS. Can somebody confirm? Cheers, Paul.

2 2

Re: cmd:Ru:Update Russian translation.[try2][fixed]
by Kirill K. Smirnov June 7, 2007

June 7, 2007

> >> + WCMD_YES, "Д" > >> + WCMD_NO, "Н" > > > > Answers to "Yes/No" question should not be translated, should they? "All" > > too. > > I think that should translate this answers because in some languages > such as Norwegian,German and Korean it was translated. > I really doesn`t understand why in Russian language this answers should > not to be translated. In windows they are not translated. Moreover, it is inconvenient to switch to Russian, press 'Д' ('Н'), then switch to English. It may be better if we allow to use translated and untranslated answers simultaneously. AFAIK it is allowed to use translated only. -- Kirill

1 0

Re: cmd:Ru:Update Russian translation.[try2][fixed]
by Kirill K. Smirnov June 7, 2007

June 7, 2007

Hi, Anatoly! The translation is still very raw. Please, verify it. >+ WCMD_YES, "Д" >+ WCMD_NO, "Н" Answers to "Yes/No" question should not be translated, should they? "All" too. >+ WCMD_NOASSOC, "Файл, ассоциированный с расширением %s,отсутствует\n" This phrase does not sound Russian. "Отсутствует сопоставление для расширения %s" will be better. and so on... -- Kirill

3 2

Re: wininet: Make the passive mode response check case insensitive.
by Francois Gouget June 7, 2007

June 7, 2007

On Wed, 6 Jun 2007, Hans Leidekker wrote: [...] > Changelog > Make the passive mode response check case insensitive. --- a/dlls/wininet/ftp.c +++ b/dlls/wininet/ftp.c [...] - if (strncmp(p, "Entering Passive Mode", 21)) + if (strncasecmp(p, "Entering Passive Mode", 21)) You should not be using str*casecmp() in Wine (because it's a Unix function, and because it uses the wrong locale). Try CompareString() instead. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

3 2

Re: avifil32: remove 'recursive registry key delete' function
by Detlef Riekenberg June 7, 2007

June 7, 2007

On Do, 2007-06-07 at 00:00 +0200, Stefan Leichter wrote: Replacing recursive_delete_key with RegDeleteTree is not the same. As Example: > - res = recursive_delete_keyA(HKEY_CLASSES_ROOT, > list->progid); > + res = RegDeleteTreeA(HKEY_CLASSES_ROOT, list->progid); > if (res != ERROR_SUCCESS) goto error_close_coclass_key; When the Initial RegOpenKey failed, RegDeleteTree is returning ERROR_FILE_NOT_FOUND and the codepath went to the error-label, but the old recursive_delete_keyA returned ERROR_SUCCESS. See this removed Line from recursive_delete_keyA/W: - if (res == ERROR_FILE_NOT_FOUND) return ERROR_SUCCESS; This additional change should work: if ((res != ERROR_SUCCESS) && (res != ERROR_FILE_NOT_FOUND)) { goto error_close_coclass_key; } Thanks -- By by ... Detlef

1 0

Re: wined3d [1/5]: Add GL_EXT_texture_sRGB constants and corresponding CheckDeviceFormat query
by Phil Costin June 7, 2007

June 7, 2007

Stefan Dösinger wrote: > Am Donnerstag, 7. Juni 2007 01:03 schrieb Phil Costin: >> Adds necessary GL constants and allows the application to query whether a >> particular texture format is compatible with sample-time texture >> linearization. > Ideally you shouldn't enable the srgb formats in this patch already, but > rather in 4/5, but since the current code returns WINED3D_OK this is an > unimportant detail. Well, originally I did but you advised me to move it to patch 1 so I did :) Regards, Phil

2 1