- wine-devel - winehq.org

Re: dpnet: Increase reported buffer size
by Marvin 01 Apr '13

01 Apr '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24918 Your paranoid android. === W2KPROSP4 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c0000005 at 004013BF

1 0

Problem about declarations of strcoll functions
by Jactry Zeng 01 Apr '13

01 Apr '13

Hi folks, I tried to implement a lot of strcoll function these days, and I meet some trouble when I added the declaration into include/msvcrt/*.h. With "grep coll *.spec" in dlls/msvcrt/ we can find there was a lot of strcoll function. Some of them was implemented and some of them not: @ cdecl ___lc_collate_cp_func() @ stub __lc_collate @ extern __lc_collate_cp MSVCRT___lc_collate_cp @ cdecl _mbscoll(str str) @ cdecl _mbscoll_l(str str ptr) @ cdecl _mbsicoll(str str) @ cdecl _mbsicoll_l(str str ptr) @ cdecl _mbsnbcoll(str str long) @ cdecl _mbsnbcoll_l(str str long ptr) @ cdecl _mbsnbicoll(str str long) @ cdecl _mbsnbicoll_l(str str long ptr) @ stub _mbsncoll(str str long) # stub _mbsncoll_l(str str long ptr) @ stub _mbsnicoll(str str long) # stub _mbsnicoll_l(str str long ptr) @ cdecl _strcoll_l(str str ptr) MSVCRT_strcoll_l @ cdecl _stricoll(str str) MSVCRT__stricoll @ cdecl _stricoll_l(str str ptr) MSVCRT__stricoll_l @ cdecl _strncoll(str str long) MSVCRT_strncoll_l @ cdecl _strncoll_l(str str long ptr) MSVCRT_strncoll @ cdecl _strnicoll(str str long) MSVCRT__strnicoll @ cdecl _strnicoll_l(str str long ptr) MSVCRT__strnicoll_l # stub _wcscoll_l(wstr wstr ptr) @ cdecl _wcsicoll(wstr wstr) MSVCRT__wcsicoll # stub _wcsicoll_l(wstr wstr ptr) @ cdecl _wcsncoll(wstr wstr long) MSVCRT__wcsncoll @ cdecl _wcsncoll_l(wstr wstr long ptr) MSVCRT__wcsncoll_l @ cdecl _wcsnicoll(wstr wstr long) MSVCRT__wcsnicoll # stub _wcsnicoll_l(wstr wstr long ptr) @ cdecl strcoll(str str) MSVCRT_strcoll @ cdecl wcscoll(wstr wstr) MSVCRT_wcscoll With "grep coll *.h" in include/msvcrt/ we can find some declarations of some strcoll function: crtdefs.h: unsigned int lc_collate_cp; mbstring.h:int __cdecl _mbscoll(const unsigned char*,const unsigned char*); mbstring.h:int __cdecl _mbsicoll(const unsigned char*,const unsigned char*); mbstring.h:int __cdecl _mbsnbcoll(const unsigned char*,const unsigned char*,size_t); mbstring.h:int __cdecl _mbsnbicoll(const unsigned char*,const unsigned char*,size_t); mbstring.h:int __cdecl _mbsncoll(const unsigned char*,const unsigned char*,size_t); mbstring.h:int __cdecl _mbsnicoll(const unsigned char*,const unsigned char*,size_t); string.h:int __cdecl _stricoll(const char*,const char*); string.h:int __cdecl strcoll(const char*,const char*); string.h:int __cdecl _wcsicoll(const wchar_t*,const wchar_t*); string.h:int __cdecl _wcsnicoll(const wchar_t*,const wchar_t*,size_t); string.h:int __cdecl wcscoll(const wchar_t*,const wchar_t*); string.h:static inline int stricoll(const char* s1, const char* s2) { return _stricoll(s1, s2); } string.h:static inline int wcsicoll(const wchar_t* str1, const wchar_t* str2) { return _wcsicoll(str1, str2); } wchar.h:int __cdecl _wcsicoll(const wchar_t*,const wchar_t*); wchar.h:int __cdecl _wcsnicoll(const wchar_t*,const wchar_t*,size_t); wchar.h:int __cdecl wcscoll(const wchar_t*,const wchar_t*); As we can see, _strcoll_l and _mbsnbcoll_l were implemented but they were not declared. Should we declare all of them? And whether the sequence was important? Thank you. -- Regards, Jactry Zeng

2 2

Re: mshtml: Fixed builtin getter call with arguments.
by Marvin 01 Apr '13

01 Apr '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24910 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH] wined3d: Add a registry key to configure buffer object placement
by Henri Verbeet 01 Apr '13

01 Apr '13

On 1 April 2013 10:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (wined3d_settings.placebo == PLACEBO_VIDMEM) > + { > + TRACE("Placing buffer %p in video memory\n", This); > + glHint(This->buffer_type_hint, GL_FASTEST); > + } > + I'm going to go out on a limb and call April fools on this. The state of GL drivers being what it is though, there's a slight chance such a thing actually exists, in which case please link to the documentation instead. Somewhat related, I do actually have a patch to change the usage hint for static vertex buffers to GL_STATIC_DRAW_ARB in my tree, which should actually make the driver more likely to initially place those in VRAM instead of GTT. (It mostly just helps with initial fps after a VB is just created, most drivers eventually figure out the optimal placement anyway and migrate the buffer to vram.)

1 0

Float printf precision
by Stefan Dösinger 31 Mar '13

31 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Henri, While overhauling the patch to hardcode local constants in the shader code I came across the TRACEs in wined3d_device_set_{vs,ps}_consts_f, which print the floats with %.8e. You changed this from %f in 979e3744f7721bef9e88fd671dfd7591c9f85392. I was curious how you ended up with 8 digits. My thinking was that 32 bit floats have a 23 bit mantissa, and one digit in the printout encodes lb(10) bits - so you need ~6,9 digits to encode the mantissa, which rounds up to 7. Thinking further, %.6e should do the job as well, as there's one additional digit leading the decimal. Is my thinking correct, or am I missing something? Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRWAiyAAoJEN0/YqbEcdMw+4AQAIW57gxqJJcPEKzS35K4R++Q aMy1rma7JV4/cUmRIqkmOROc6Y3T2bz7x3e12mNpLVvI9YUBdaZKsofuBJk9QCtL R6nWL266dLc3aRdIFazwjxK6GmohqjxoLidpCAPSXGkekjw48DqhA+5fdXO2YYm/ 2g1Fhyy/cpi6BN2AUh760YNy3ojk/x9eH25oTmifFxCUbWlhYNGsIVt8OTTW9YBE RnQyyoO2lPjNi5mlNIqoSkkYriG5m97nS8bSMXvu9BjKW8rSmmErLGPf2zDL7Big wdibKxbXaSSx74upJaOTLjoOx04sqoi4SuPnX/55ftFKj7s2SeoFJaOUwgdNJoN+ UxKcd0HzfaXBi/VikYvtfMd0+SLA8wFIVjrJsWeBwgNU9cEAA3OiRFPWyizZCPqu 4UQOSnxuK6LZ7Ke58ikcG6JqMVTye8iTeEmr6r3NhkRdmCKrFbVGmJ1POb8Q26Hu q2yQBHq2L5CZ0Vx7fruvqq9Ap8auI/l5B6tneDM/RUdvpWxQTJneVRpSqIE50ZmW U3XH2cx4eLaEGJnSnHBgxnqgSAmcVTJEkFHtd8tCiqsPcnkw2g3Ng3gQZhjkDJ45 ZxvXNxVUl3B899Y1CwFd3FVJhKQq2jFS0NQvNQYZXhx0djZ2ok8rvtmoJzTaNN1s SMfTtZDHxHFtluASd6zJ =7CAL -----END PGP SIGNATURE-----

2 1

Re: wined3d: Properly handle WS_VISIBLE and WS_EX_TOPMOST style flags on fullscreen windows.
by Henri Verbeet 31 Mar '13

31 Mar '13

On 29 March 2013 03:31, Sam Edwards <cfsworks(a)gmail.com> wrote: > Note that the tests are NOT (primarily) intended to make sure that > WS_VISIBLE and WS_EX_TOPMOST are still set. The main purpose of this patch > is to fix a slightly more serious bug: > > - Create a window without WS_VISIBLE. > - Create a fullscreen Direct3D device. > - wined3d applies its own flags (including WS_VISIBLE) to the window, to > make it fullscreen. > - Reset the device back to windowed mode. > - Because wined3d_device_setup_fullscreen_window didn't see the window had > WS_VISIBLE, wined3d_device_restore_fullscreen_window won't restore the > style. > > This patch corrects that behavior, and the window restores back to its > original style as on Windows. > I think the idea is basically ok, but I do have some comments: I think test_window_style() is a more appropriate place for the tests, and you should add them to the variants in ddraw as well. Ddraw applications in particular are very fragile in this regard. Note that the test_window_style() tests are fairly similar to what your tests do, except that they don't test restoring the window as such. That test also shows that we're actually not supposed to touch the styles at all, but that's hard to make work without calling into winex11. > - SetWindowPos(window, HWND_TOP, 0, 0, w, h, SWP_FRAMECHANGED | SWP_SHOWWINDOW | SWP_NOACTIVATE); > + SetWindowPos(window, HWND_TOPMOST, 0, 0, w, h, SWP_FRAMECHANGED | SWP_SHOWWINDOW | SWP_NOACTIVATE); This is really a separate change. > + device->style ^= (device->style^style) & WS_VISIBLE; Spaces around the (second) ^, please.

2 2

[website try2] Simplified Chinese translation for release 1.5.27
by Jactry Zeng 31 Mar '13

31 Mar '13

1 0

Windows API on Linux
by Abhinav Jangda 30 Mar '13

30 Mar '13

Hello everyone, I'm working on a project which aims to develop a port of Windows API on Linux, so that programs written using Windows API could directly be compiled and executed on Linux with its native look and feel. Anyone, interested in working on this project. I think some Wine developers will be as they would be having a good knowledge of Windows API. If anyone interested then please let me know. Thank You :)

4 3

Re: [website] Simplified Chinese translation for release 1.5.27
by Hin-Tak Leung 30 Mar '13

30 Mar '13

--- On Sat, 30/3/13, Jactry Zeng <jactry92(a)gmail.com> wrote: From: Jactry Zeng <jactry92(a)gmail.com> Subject: Re: [website] Simplified Chinese translation for release 1.5.27 To: htl10(a)users.sourceforge.net Cc: "Wine Devel" <wine-devel(a)winehq.org>, "Qian Hong" <fracting(a)gmail.com> Date: Saturday, 30 March, 2013, 10:41 2013/3/30 Hin-Tak Leung <htl10(a)users.sourceforge.net> > > > I think both are terrible translations but could not think of a better alternative off my head, so I went to consult google translate. It defaults to 運行時庫 for "runtime library" but allow me to choose a few other alternatives, among which is > > "執行階段程式庫" > > Don't you think that's much better!? Hi Hin-Tak, Thanks for your review. I also think both "运行时" or "运行时库" was not best translation. But I have seen a lot of documents in Simplified Chinese translated it in this way. Maybe it was not too accurate... And in my opinion, "运行时" meaning some function, "运行时库" meaning a runtime library. To be honest, I think a lot of Chinese translations of technical topics (or even not-technical topics) are quite poor, and little beyond a word-for-word substitution. run -> 运行 ("to convey/process", the more common use of "run", of 'using your legs faster than walking' is obviously wrong) time -> 时 ("hour", "during") library -> 库 ("storage container", the more common use of "library" to mean "collection of books" obviously wrong). Whereas "執行階段程式庫" meaning "the program/routine library of/in the execute stage" is quite a lot more fitting to what 'runtime library' actually means. As I was saying, one needs to be vigilant about automated translations being 'not quite correct'. I suspect it is a much abused practice in China, so you see the same (mis-)usage over and over. There are entire web sites devoted to poorly translated public signs in China and making fun of them. It is quite educational - one gets lazy and and accepts the occasional poor translation, but seeing similar but slightly different mistakes collected in a large quantity really makes one think. 2013/3/30 Jactry Zeng <jactry92(a)gmail.com> > > I translated it as "高质量" meaning a picture have hight resolution. Here has a typo, hight -> higher .... -- Regards, Jactry Zeng

1 0

Re: [website] Simplified Chinese translation for release 1.5.27
by Qian Hong 30 Mar '13

30 Mar '13

Hi Jactry, 2013/3/30 Jactry Zeng <jactry92(a)gmail.com>: > + <li>一些 C 运行时的改进。</li> I think it is better to translate "C runtime" to “C 运行时库“ rather than just ”C 运行时“。 + <li>为内建程序提供更高质量的图标。</li> Large icon means 大图标，not 高质量图标。You can verify this by the git commits。 Thanks for the work. -- Regards, Qian Hong - http://www.winehq.org

3 4

Re: [PATCH 1/3] jscript: Use helpers to access string buffers in jsregexp.c.
by Alexandre Julliard 29 Mar '13

29 Mar '13

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/jscript/jsregexp.c | 114 > +++++++++++++++++++++++++++++++----------------- > 1 file changed, 73 insertions(+), 41 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -M jscript.dll -T ../../.. -p jscript_test.exe.so run.c && touch run.ok run.c:1804: Test failed: expected global_success_d run.c:1805: Test failed: expected global_success_i run.c:1807: Test failed: parse_script failed: 80004005 run.c:1804: Test failed: expected global_success_d run.c:1805: Test failed: expected global_success_i run.c:1807: Test failed: parse_script failed: 80004005 run.c:1804: Test failed: expected global_success_d run.c:1805: Test failed: expected global_success_i run.c:1807: Test failed: parse_script failed: 80004005 run.c:1804: Test failed: expected global_success_d run.c:1805: Test failed: expected global_success_i run.c:1807: Test failed: parse_script failed: 80004005 run.c:1804: Test failed: expected global_success_d run.c:1805: Test failed: expected global_success_i run.c:1807: Test failed: parse_script failed: 80004005 run.c:1804: Test failed: expected global_success_d run.c:1805: Test failed: expected global_success_i run.c:1807: Test failed: parse_script failed: 80004005 make: *** [run.ok] Error 18 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3dx9 [patch 1/2, try 4]: Implement D3DXSHEvalSphericalLight
by Alexandre Julliard 29 Mar '13

29 Mar '13

Nozomi Kodama <nozomi.kodama(a)yahoo.com> writes: > From bb40ba80a24a954d21c44cbe55b4b9c79e2087c5 Mon Sep 17 00:00:00 2001 > From: "nozomi.kodama" <nozomi.kodama(a)yahoo.com> > Date: Wed, 27 Mar 2013 22:38:51 -1000 > Subject: d3dx9: Implement D3DXSHEvalSphericalLight It still fails the same way... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcp110: Add VS2012 C/C++ runtime
by Piotr Caban 29 Mar '13

29 Mar '13

On 03/28/13 23:22, Stefan Leichter wrote: > --- > configure.ac | 1 + > dlls/msvcp110/Makefile.in | 5 + > dlls/msvcp110/msvcp110.c | 37 + > dlls/msvcp110/msvcp110.spec | 3900 > +++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 3943 insertions(+), 0 deletions(-) > create mode 100644 dlls/msvcp110/Makefile.in > create mode 100644 dlls/msvcp110/msvcp110.c > create mode 100644 dlls/msvcp110/msvcp110.spec You can use tools/make_specfiles script to generate forwards to other msvcpXX dlls. The script will generate big parts of the spec file differently (because it prefers to forward to msvcp90, not to msvcp100).

1 0

Re: [PATCH 1/3] extrac32: Implement more strict command line processing.
by Sergey Guralnik 29 Mar '13

29 Mar '13

On 2013-03-26 10:17, Sergey Guralnik wrote: > Is some problem with this series? -- Sergey

1 0

Re: gdi32: Copy gamma ramp validation from winex11 to make it driver independent (try 2)
by Alexandre Julliard 28 Mar '13

28 Mar '13

André Hentschel <nerv(a)dawncrow.de> writes: > + /* the bias could be because the app wanted something like a "red shift" > + * like when you're hit in Quake, but XVidMode doesn't support it, > + * so we have to reject a significant bias */ Clearly gdi32 doesn't care about XVidMode. > @@ -1325,6 +1405,18 @@ BOOL WINAPI SetDeviceGammaRamp(HDC hDC, LPVOID ptr) > if (GetObjectType( hDC ) != OBJ_MEMDC) > { > PHYSDEV physdev = GET_DC_PHYSDEV( dc, pSetDeviceGammaRamp ); > + struct gamma_ramp > + { > + WORD red[256]; > + WORD green[256]; > + WORD blue[256]; > + } *ramp = ptr; > + > + if (!check_gamma_ramp(ramp->red) || > + !check_gamma_ramp(ramp->green) || > + !check_gamma_ramp(ramp->blue)) > + return FALSE; This can't work. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winemac: Track drawn surface rect to reduce black flicker for new or resized windows.
by Ken Thomases 28 Mar '13

28 Mar '13

On Mar 27, 2013, at 3:31 PM, Ken Thomases wrote: > dlls/winemac.drv/macdrv.h | 12 +++++++++++- > dlls/winemac.drv/surface.c | 16 ++++++++++++++-- > dlls/winemac.drv/window.c | 17 ++--------------- > 3 files changed, 27 insertions(+), 18 deletions(-) > > <0001-winemac-Track-drawn-surface-rect-to-reduce-black-fli.patch> Please don't commit this. I've thought of a different approach. -Ken

1 0

Re: user32: ImmProcessKey is only called on WM_KEYDOWN and if the message is being removed
by Dmitry Timoshkov 28 Mar '13

28 Mar '13

Aric Stewart <aric(a)codeweavers.com> wrote: > Worked out with testing on Japanese windows XP. Resolves issues with > keystrokes and accelerators in menus when the IME is active. You should really start adding the tests and base your patches on test results instead of some sort of speculation. -- Dmitry.

3 4

Re: winemac: Null-terminate an snprintf-ed key name buffer in case of short buffer.
by Per Johansson 28 Mar '13

28 Mar '13

On Wed, Mar 27, 2013 at 7:22 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > --- This has probably been discussed before, but shouldn't snprintfW be safe against this kind of thing, the way POSIX snprintf is? Regards, -- Per Johansson

2 1

Linker error when improving GetLargestConsoleWindowSize
by Hugh McMaster 28 Mar '13

28 Mar '13

Hi, I've written a function to determine the largest possible screen buffer that wineconsole is able to display. This function replaces the hard-coded constants listed in both instances of GetLargestConsoleWindowSize in dlls/kernel32/console.c. [snip] #include <windows.h> #include <winuser.h> [snip] COORD GetLargestConsoleWindowSize_helper(HANDLE hConsoleOutput) { RECT workarea; COORD console_fontsize; COORD max_console; SystemParametersInfoA(SPI_GETWORKAREA, 0, &workarea, 0); console_fontsize = GetConsoleFontSize(hConsoleOutput, 0); max_console.X = (workarea.right / console_fontsize.X) - 6; max_console.Y = (workarea.bottom / console_fontsize.Y) - 6; return max_console; } While dlls/kernel32/console.c compiles, I'm having trouble with the final compile-time linking. It seems that SystemParametersInfoA is an undefined reference, but windows.h and winuser.h are included in console.c. This is the terminal output: make[1]: Entering directory `/home/hugh/wine-1.5.26/dlls/kernel32' [snip] ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. -fasynchronous-unwind-tables -shared ./kernel32.spec actctx.o atom.o change.o comm.o computername.o console.o cpu.o debugger.o editline.o environ.o except.o fiber.o file.o format_msg.o heap.o kernel_main.o lcformat.o locale.o lzexpand.o module.o nameprep.o oldconfig.o path.o powermgnt.o process.o profile.o resource.o string.o sync.o tape.o term.o thread.o time.o toolhelp.o version.o virtual.o volume.o wer.o locale_rc.res version.res winerror.res -nodefaultlibs -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b800000 -o kernel32.dll.so -lwinecrt0 -lntdll ../../libs/port/libwine_port.a console.o: In function `GetLargestConsoleWindowSize_helper': /home/hugh/wine-1.5.26/dlls/kernel32/console.c:1377: undefined reference to `SystemParametersInfoA' /usr/bin/ld: kernel32.dll.so: hidden symbol `SystemParametersInfoA' isn't defined /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status winegcc: gcc failed make[1]: *** [kernel32.dll.so] Error 2 Unfortunately, my knowledge of C is terrible, so I'm not sure what to do from here. If someone could help me solve this, I'd appreciate it. If it helps, I'm able to use winegcc to build a simple Windows executable using SystemParametersInfo without any problems. Thank you in advance, Hugh

3 4

Re: [1/3] kernel32: Set GetLargestConsoleWindowSize based on screen resolution
by Ken Thomases 27 Mar '13

27 Mar '13

On Mar 27, 2013, at 6:41 AM, Hugh McMaster wrote: > This patch modifies the dlls/kernel32 Makefile.in to (1) compile a new source file (screensize.c) (patch 3/3) and (2) add -lX11 to the ExtraDllFlags line. This approach is untenable. Kernel32 can't be made to depend on X11. It has to still work when X11 isn't available. Also, X11 is just one possible graphics/windowing system that Wine can use, so it's not always the right authority to consult about screen size. Eric Pouech suggested in the other thread to calculate the console window size in wineconsole, at which point you can use user32 and SystemParametersInfo(). Finally, your patch series is broken in the sense that each patch in the series must still be able to compile. You introduce a dependency on screensize.c in the first patch but don't actually provide that source file until the third. -Ken

2 2

Re: d3dx9 [patch 1/2, try 3]: Implement D3DXSHEvalSphericalLight
by Alexandre Julliard 27 Mar '13

27 Mar '13

Nozomi Kodama <nozomi.kodama(a)yahoo.com> writes: > From 3d331ffa908f69ca58686b4601effbb16d89d1da Mon Sep 17 00:00:00 2001 > From: "nozomi.kodama" <nozomi.kodama(a)yahoo.com> > Date: Thu, 14 Mar 2013 18:34:48 -1000 > Subject: d3dx9: Implement D3DXSHEvalSphericalLight It fails on 64-bit: ../../../../wine/tools/runtest -q -P wine -M d3dx9_36.dll -T ../../.. -p d3dx9_36_test.exe.so ../../../../wine/dlls/d3dx9_36/tests/math.c && touch math.ok math.c:2930: Test failed: Red: case 1, order 5: expected[20] = 0.000529, received 0.000529 math.c:2939: Test failed: Green: case 1, order 5: expected[20] = 0.000809, received 0.000809 math.c:2949: Test failed: Blue: case 1, order 5: expected[20] = 0.001089, received 0.001089 math.c:2930: Test failed: Red: case 1, order 6: expected[20] = 0.000529, received 0.000529 math.c:2939: Test failed: Green: case 1, order 6: expected[20] = 0.000809, received 0.000809 math.c:2949: Test failed: Blue: case 1, order 6: expected[20] = 0.001089, received 0.001089 math.c:2930: Test failed: Red: case 2, order 5: expected[20] = -0.000715, received -0.000714 math.c:2939: Test failed: Green: case 2, order 5: expected[20] = -0.001093, received -0.001093 math.c:2949: Test failed: Blue: case 2, order 5: expected[20] = -0.001471, received -0.001471 math.c:2930: Test failed: Red: case 2, order 6: expected[20] = -0.000715, received -0.000714 math.c:2939: Test failed: Green: case 2, order 6: expected[20] = -0.001093, received -0.001093 math.c:2949: Test failed: Blue: case 2, order 6: expected[20] = -0.001471, received -0.001471 make: *** [math.ok] Error 12 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: tools/wine.inf: add HKLM\\System\\CurrentControlSet\\Services\\Eventlog\\Application registry key
by Alexandre Julliard 27 Mar '13

27 Mar '13

Austin English <austinenglish(a)gmail.com> writes: > Fixes http://bugs.winehq.org/show_bug.cgi?id=22026 It breaks the tests: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so eventlog.c && touch eventlog.ok eventlog.c:524: Tests skipped: We don't have a backup eventlog to work with eventlog.c:457: Tests skipped: No records in the 'Application' log eventlog.c:835: Test failed: Expected 1 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 2 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 3 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 4 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 5 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 6 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 7 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 8 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 9 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:835: Test failed: Expected 10 records, got 0 eventlog.c:840: Test failed: Expected oldest to be 1 or higher, got 0 eventlog.c:858: Test failed: Expected 10 records, got 0 eventlog.c:863: Tests skipped: No events were written to the eventlog eventlog.c:1086: Test failed: Expected an eventlog file eventlog.c:1113: Test succeeded inside todo block: Could not delete the registry tree : 0 eventlog.c:1120: Test succeeded inside todo block: Expected MoveFileEx to succeed: 1 make: *** [eventlog.ok] Error 24 -- Alexandre Julliard julliard(a)winehq.org

1 0

Wiki is down
by Rosanne DiMesio 27 Mar '13

27 Mar '13

I'm getting an "Internal Server Error" message when I try to access the wiki. -- Rosanne DiMesio <dimesio(a)earthlink.net>

3 5

Re: [PATCH 1/3] msvcr90: Forward some functions directly to ntdll
by Alexandre Julliard 27 Mar '13

27 Mar '13

Piotr Caban <piotr(a)codeweavers.com> writes: > These functions are currently forwarded from msvcr90 to msvcrt which > forwards to ntdll. Naver LINE is crashing while trying to call them. Does it work if you remove the forward in msvcrt instead? That would be a better fix. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: advapi32: Do not terminate a regular program if it calls StartServiceCtrlDispatcher.
by Alexandre Julliard 27 Mar '13

27 Mar '13

Alexander Morozov <amorozov(a)etersoft.ru> writes: > @@ -592,7 +586,26 @@ BOOL WINAPI StartServiceCtrlDispatcherA( const SERVICE_TABLE_ENTRYA *servent ) > services[i] = info; > } > > - service_run_main_thread(); > + disp = HeapAlloc( GetProcessHeap(), 0, sizeof(*disp) ); > + > + if (!(disp->manager = OpenSCManagerW( NULL, NULL, SC_MANAGER_CONNECT ))) > + { > + ERR("failed to open service manager error %u\n", GetLastError()); > + HeapFree( GetProcessHeap(), 0, disp ); > + return FALSE; > + } > + > + disp->pipe = service_open_pipe(); > + if (disp->pipe == INVALID_HANDLE_VALUE) > + { > + WARN("failed to create control pipe error %u\n", GetLastError()); > + CloseServiceHandle( disp->manager ); > + HeapFree( GetProcessHeap(), 0, disp ); > + SetLastError( ERROR_FAILED_SERVICE_CONTROLLER_CONNECT ); > + return FALSE; > + } > + > + service_run_main_thread( disp ); There's no reason to duplicate that code, just do it in service_run_main_thread instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: urlmon: Fix handling of mailto URIs in CoInternetCombineUrlEx.
by Jacek Caban 27 Mar '13

27 Mar '13

Hi Hans, On 03/27/13 10:43, Hans Leidekker wrote: > --- > dlls/urlmon/tests/uri.c | 63 +++++++++++++++++++++++++++++++++++++++++++---- > dlls/urlmon/uri.c | 15 ++++++++--- > 2 files changed, 69 insertions(+), 9 deletions(-) > > diff --git a/dlls/urlmon/tests/uri.c b/dlls/urlmon/tests/uri.c > index e5faa81..29bd859 100644 > --- a/dlls/urlmon/tests/uri.c > +++ b/dlls/urlmon/tests/uri.c > @@ -7005,8 +7005,61 @@ static const uri_combine_test uri_combine_tests[] = { > {URL_SCHEME_FILE,S_OK}, > {URLZONE_INVALID,E_NOTIMPL} > } > + }, > + { "http://winehq.org",0, > + "mailto://",0, > + 0,S_OK,FALSE, You are changing parts that are not combining-specific. Since the relative URI is absolute in this case, there is not much happening other than parsing the URI during combining. Those tests are fine, but please add also tests for CreateUri, see uri_tests array. This should be straightforward based on tests you already wrote. > diff --git a/dlls/urlmon/uri.c b/dlls/urlmon/uri.c > index 0f6ee31..c6b5166 100644 > --- a/dlls/urlmon/uri.c > +++ b/dlls/urlmon/uri.c > @@ -422,7 +422,7 @@ static inline BOOL is_hierarchical_uri(const WCHAR **ptr, const parse_data *data > else if(is_hierarchical_scheme(data->scheme_type) && (*ptr)[0] == '\\' && (*ptr)[1] == '\\') { > *ptr += 2; > return TRUE; > - } else if(check_hierarchical(ptr)) > + } else if(data->scheme_type != URL_SCHEME_MAILTO && check_hierarchical(ptr)) > return TRUE; > > *ptr = start; > @@ -2980,6 +2980,9 @@ static BOOL canonicalize_path_opaque(const parse_data *data, Uri *uri, DWORD fla > const BOOL known_scheme = data->scheme_type != URL_SCHEME_UNKNOWN; > const BOOL is_file = data->scheme_type == URL_SCHEME_FILE; > const BOOL is_mk = data->scheme_type == URL_SCHEME_MK; > + const BOOL is_javascript = data->scheme_type == URL_SCHEME_JAVASCRIPT; > + const BOOL is_mailto = data->scheme_type == URL_SCHEME_MAILTO; > + DWORD offset = 0; > > if(!data->path) { > uri->path_start = -1; > @@ -2996,7 +2999,7 @@ static BOOL canonicalize_path_opaque(const parse_data *data, Uri *uri, DWORD fla > } > > /* For javascript: URIs, simply copy path part without any canonicalization */ > - if(data->scheme_type == URL_SCHEME_JAVASCRIPT) { > + if(is_javascript) { > if(!computeOnly) > memcpy(uri->canon_uri+uri->canon_len, data->path, data->path_len*sizeof(WCHAR)); > uri->path_len = data->path_len; > @@ -3007,7 +3010,11 @@ static BOOL canonicalize_path_opaque(const parse_data *data, Uri *uri, DWORD fla > /* Windows doesn't allow a "//" to appear after the scheme > * of a URI, if it's an opaque URI. > */ > - if(data->scheme && *(data->path) == '/' && *(data->path+1) == '/') { > + if (is_mailto && *(data->path) == '/' && *(data->path+1) == '/') { > + if (!*(data->path+2)) uri->path_start = -1; > + offset += 2; I think this should be done in parsing phrase, not during canonicalization. Jacek

1 0

Re: comctl32: Make an attempt to update notification handle
by Dmitry Timoshkov 27 Mar '13

27 Mar '13

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + case WM_WINDOWPOSCHANGING: > + { > + HWND parent = GetParent(hwnd); > + if (parent) infoPtr->hwndNotify = parent; > + return DefWindowProcW(hwnd, uMsg, wParam, lParam); > + } What if an application subclasses tab and doesn't pass WM_WINDOWPOSCHANGING to the original proc? Why not just call GetParent() every time when a notification is being sent? -- Dmitry.

3 7

Re: iads.idl: Add missing interfaces
by Nikolay Sivov 27 Mar '13

27 Mar '13

On 3/27/2013 09:05, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > iads.idl: Add missing interfaces > > > Best Regards > Alistair Leslie-Hughes > +typedef enum > +{ > + ADS_SEARCHPREF_ASYNCHRONOUS = 0, > + ADS_SEARCHPREF_DEREF_ALIASES = 1, You don't need to do it manually, widl will generate values for each entry.

1 0

Re: d3dx9 [patch 1/2, try 3]: Implement D3DXSHEvalSphericalLight
by Matteo Bruni 27 Mar '13

27 Mar '13

2013/3/15 Nozomi Kodama <nozomi.kodama(a)yahoo.com>: > Patch series is fine to me.

4 3

Re: msvcr110: forward __crtSetUnhandledExceptionFilter to kernel32.SetUnhandledExceptionFilter
by Alexandre Julliard 26 Mar '13

26 Mar '13

Austin English <austinenglish(a)gmail.com> writes: > diff --git a/dlls/msvcr110/msvcr110.spec b/dlls/msvcr110/msvcr110.spec > index 4a94dbe..babfc67 100644 > --- a/dlls/msvcr110/msvcr110.spec > +++ b/dlls/msvcr110/msvcr110.spec > @@ -928,7 +928,7 @@ > @ stub -arch=i386,win64 __crtLCMapStringEx > @ cdecl __crtLCMapStringW(long long wstr long ptr long long long) msvcrt.__crtLCMapStringW > @ stub -arch=i386,win64 __crtSetThreadStackGuarantee > -@ stub __crtSetUnhandledExceptionFilter > +@ stdcall __crtSetUnhandledExceptionFilter(ptr) kernel32.SetUnhandledExceptionFilter A quick test shows that the crt functions are cdecl. -- Alexandre Julliard julliard(a)winehq.org

1 0

Mac driver status: ready for contributions
by Ken Thomases 26 Mar '13

26 Mar '13

Hi, With my latest set of patches, the Mac driver in Wine is up to speed with what's in CrossOver 12 (plus some extra goodies). Of course, that's not to say that the Mac driver is done, but if you were holding off getting involved because you figured big chunks of already-done work were pending, that's no longer the case. From here on out, all work on the Mac driver will be new coding, so it's ready for anybody to contribute. Testing is one excellent way of contributing. I encourage any Mac Wine users to enable the Mac driver, test your favorite programs, and file bugs for any new problems (and there _will_ be bugs to find). Please try to distinguish between general Wine bugs which also happen with the X11 driver vs. bugs which only happen with the Mac driver. Currently, you have to set a registry key to enable the Mac driver: [HKEY_CURRENT_USER\Software\Wine\Drivers] "Graphics"="mac,x11" Swap the order to "x11,mac" – or just remove the "Graphics" value altogether – to revert to using the X11 driver. Aside from bugs, the Mac driver is pretty close to complete. Here's a list of stuff that I know is incomplete. Not all of these things are hard. In fact, I expect some will be quite easy and the only reason I didn't get to them was to get broader coverage of general areas of functionality by CrossOver 12's release. * The Quit menu item should do a graceful shutdown of the Windows process rather than abruptly terminating it. Same for requests to quit from the system such as during logout, restart, or shutdown. * A registry setting to govern whether full-screen at full-resolution should capture the display (which will disable active screen corners but also application switching and UI overlays). Full-screen at other resolutions already captures the displays. * A registry setting to govern whether the Option/Alt key sends an Alt keystroke instead of accessing additional characters from the Mac keyboard layout. * Support for maximizing windows. * Reduce or eliminate flashes of black before windows (re)draw. * Support for Mac input methods (Asian languages, press-and-hold, keyboard and character viewers). * Rework the Graphics tab of winecfg. Most of it doesn't apply to the Mac driver. As Mac-driver-specific registry settings are implemented, they may need to be revealed in winecfg. * Maybe implement a Cocoa Preferences dialog for the Mac driver's settings as an alternative to putting them in winecfg. * Activating a Wine GUI process all of whose windows are minimized should maybe unminimize one. * Add some additional standard items to the Mac menus, such as Hide Wine, Hide Others, and Show All. * Support for metafile clipboard formats. * Support for mouse capture. * Improved system tray functionality like detecting mouse moves and right-clicks and presenting notification balloons. * Support localization of the few UI strings in the Mac driver (basically the menu item titles). (Charles Betts has already submitted work to support disabling and reenabling the screen saver. As I understand it, Alexandre has some unspecified ideas about how he wants to change the driver interface for the SystemParametersInfo entry point.) Cheers, Ken

3 3

Re: gdi32: Printer drivers don't use the character extra spacing if lpdx is supplied.
by Alexandre Julliard 26 Mar '13

26 Mar '13

Huw Davies <huw(a)codeweavers.com> writes: > Ideally this would be done in wineps.drv, but by that point the conversion to device units would cause rounding errors. What about GetTextExtent functions? Do they need this too? Some test cases would be nice. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: explorer: Create desktop window hidden and only show it if it wins the race.
by Dmitry Timoshkov 26 Mar '13

26 Mar '13

Ken Thomases <ken(a)codeweavers.com> wrote: > + ShowWindow( hwnd, SW_SHOW ); > SetWindowLongPtrW( hwnd, GWLP_WNDPROC, (LONG_PTR)desktop_wnd_proc ); > SendMessageW( hwnd, WM_SETICON, ICON_BIG, (LPARAM)LoadIconW( 0, MAKEINTRESOURCEW(OIC_WINLOGO))); > if (name) set_desktop_window_title( hwnd, name ); You can postpone calling ShowWindow() after setting window text and icon, since they are drawn as part of a non-client area, and changing them forces another set of redraws. -- Dmitry.

2 1

[1/3] Make mac driver the default on OS X
by Joerg-Cyril.Hoehle＠t-systems.com 26 Mar '13

26 Mar '13

Hi, Ken Thomases wrote: >I think that the Mac driver should not be made the default >until OpenGL and clipboard support are in. Exactly :-( Following Josh DuBois explanation about HKCU/Software/Wine/Drivers "Graphics"="mac,x11" I decided to give it a try over the week-end and was very disappointed to see that seemingly *not any* app would run. It took me some time to understand that they all want graphics. Please don't waste the user's time when such "basics" don't work. What you can do is post to wine-devel and the user forum, asking for people to test your work. That would be polite. Josh DuBois wrote: >I propose an environment variable, WINEDRIVERLOADORDER Too generic. Include "DISPLAY" into the name, if at all, e.g. WINEDISPLAYDRIVER, or "GRAPHICS" as in the registry. The winepulse driver might face similar issues. I have not looked how Maarten thinks that it may coexist nicely with winealsa. Bug report: Toying around with built-in notepad, clock, winhlp32, I noticed that notepad and winhlp32 are not resizable, whereas the system preferences "control" is. By comparison, with the x11 driver, notepad's window is resizable even though it has no triangle widget at the bottom left. Also, the virtual desktop seems gone or not yet implemented. This is a key requirement for enough apps that do not handle today's huge resolutions. Another annoyance was that there's no HIDE function or short cut and some dialogues do not provide the orange button (middle one) to iconify the window. As a result, those pesky windows clutter your screen. That alone is enough reason to me a reason not to use that driver. It is not acceptable that one cannot get rid of a set of windows! Example: wine control, then navigate to the root CA certificates. The menu bar sometimes was refreshed badly, causing some texts therein to be displayed twice, shifted by a few pixels, or with varying fonts. Regards, Jörg Höhle

4 10

Re: [4/5] hlink: Implement IHlinkBrowseContext_GetHlink()
by Marvin 25 Mar '13

25 Mar '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24822 Your paranoid android. === W2KPROSP4 (32 bit browse_ctx) === browse_ctx.c:61: Test failed: got 0x80004005 browse_ctx.c:64: Test failed: got 0x80004005 === W2K3R2SESP2 (32 bit browse_ctx) === browse_ctx.c:61: Test failed: got 0x80004005 browse_ctx.c:64: Test failed: got 0x80004005 === W2K8SE (32 bit browse_ctx) === browse_ctx.c:61: Test failed: got 0x80004005 browse_ctx.c:64: Test failed: got 0x80004005 === W7PROX64 (32 bit browse_ctx) === browse_ctx.c:61: Test failed: got 0x80004005 browse_ctx.c:64: Test failed: got 0x80004005 === TEST64_W7SP1 (32 bit browse_ctx) === browse_ctx.c:61: Test failed: got 0x80004005 browse_ctx.c:64: Test failed: got 0x80004005 === W7PROX64 (64 bit browse_ctx) === browse_ctx.c:61: Test failed: got 0x80004005 browse_ctx.c:64: Test failed: got 0x80004005 === TEST64_W7SP1 (64 bit browse_ctx) === browse_ctx.c:61: Test failed: got 0x80004005 browse_ctx.c:64: Test failed: got 0x80004005

1 0

Re: ntdll: Improve stub for FileFsAttributeInformation in NtQueryVolumeInformationFile
by Marvin 24 Mar '13

24 Mar '13

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24819 Your paranoid android. === W2KPROSP4 (32 bit file) === file.c:1675: Test failed: got 8 === W2K3R2SESP2 (32 bit file) === file.c:1675: Test failed: got 8 === W2K8SE (32 bit file) === file.c:1675: Test failed: got 8 === W7PROX64 (32 bit file) === file.c:1675: Test failed: got 8 === TEST64_W7SP1 (32 bit file) === file.c:1675: Test failed: got 8 === W7PROX64 (64 bit file) === file.c:1675: Test failed: got 8 === TEST64_W7SP1 (64 bit file) === file.c:1675: Test failed: got 8

1 0

Re: winemac: Calculate surface rect correctly in macdrv_UpdateLayeredWindow().
by Ken Thomases 22 Mar '13

22 Mar '13

On Mar 22, 2013, at 1:21 AM, Ken Thomases wrote: > --- > dlls/winemac.drv/window.c | 33 ++++++++++++++++----------------- > 1 files changed, 16 insertions(+), 17 deletions(-) > > <0001-winemac-Calculate-surface-rect-correctly-in-macdrv_U.patch> Hmm. On further consideration, I'm not sure this is right. I think the intent was for the window surface of a ULW window to have a full surface even if it's partially off-screen. So, perhaps macdrv_WindowPosChanging() needs to use the same calculation as macdrv_UpdateLayeredWindow() for that kind of window so the surface rect doesn't keep ping-ponging. Also, the same issue exists in the X11 driver. I'll have to discuss with Alexandre when he gets back. -Ken

1 0

Re: [PATCH 4/5] winemac: Implement rudimentary support for system tray icons as Mac status items.
by C.W. Betts 22 Mar '13

22 Mar '13

On Mar 17, 2013, at 9:40 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > > Doesn't support right-clicks, mouse moves, or notification balloons. Notification balloons can probably be done using either Notification Center or Growl, but either due to an out-of-date version of Growl in Twitter or a bug in Growl itself, clicking on the Growl notification doesn't bring Twitter to the front for me. > --- > dlls/winemac.drv/Makefile.in | 2 + > dlls/winemac.drv/cocoa_status_item.m | 175 +++++++++++++++++ > dlls/winemac.drv/event.c | 5 + > dlls/winemac.drv/image.c | 2 +- > dlls/winemac.drv/macdrv.h | 3 + > dlls/winemac.drv/macdrv_cocoa.h | 13 ++ > dlls/winemac.drv/systray.c | 358 ++++++++++++++++++++++++++++++++++ > dlls/winemac.drv/winemac.drv.spec | 3 + > 8 files changed, 560 insertions(+), 1 deletions(-) > create mode 100644 dlls/winemac.drv/cocoa_status_item.m > create mode 100644 dlls/winemac.drv/systray.c > > <0004-winemac-Implement-rudimentary-support-for-system-tra.patch>

4 8

Parameterizing the places Wine suggests people report bugs
by Josh DuBois 22 Mar '13

22 Mar '13

Hi all, There are a couple of places wine suggests that people report bugs to wine-devel. The crash reporting dialog in winedbg suggests this, and a couple of places in code refer to wine-devel(a)winehq.org in error messages. The configure script has a PACKAGE_BUGREPORT macro which could be used to allow someone building wine to redirect those errors somewhere else. At least for wine's crash dialog, an alternate approach for a repackager to redirect bug reports would be to read the url / email address for where to send bugs from the registry. Would Wine accept a patch for making winedbg read the 'destination' for bug reports from the registry or some other runtime variable? Or would the project prefer to have all the bug reports routed directly to winehq, so that a repackager who wants to re-route bugs would have to build that facility on its own?

2 1

Re: gdi32: Copy gamma ramp validation from winex11 to make it driver independent
by Dmitry Timoshkov 22 Mar '13

22 Mar '13

André Hentschel <nerv(a)dawncrow.de> wrote: > - this was done for the mac driver > - i tried to follow the file-style, except of the original variable naming The ERRs should be downgraded to WARNs or even TRACEs, there is no point to loudly complain on application input. -- Dmitry.

1 0

[GSoC] My proposal for GSoC 2013
by Gediminas Jakutis 21 Mar '13

21 Mar '13

Hello! My name is Gediminas Jakutis. I study Informatics Engineering [bachelor / undergraduate] at Kaunas University of Technology, second year. I wish to try out GSoC for the first time by helping to improve Wine. My primary programming language is C. I am self-taught in C, but I believe my knowledge is good enough. I am quite familiar with Wine - I use it and experiment with it for many years now. I am subscribed to and read wine-devel for more than a year. I browse through Wine's source code once in a while out of curiosity. Thus, I have some knowledge of its structure. Sadly, I have not written any patches for Wine yet. Mostly due to lack of confidence. For GSoC, I am suggesting my own idea. In case this idea is not good, I am open to changing it, thinking of a new one, or adopting one. My idea: I have noticed that Wine's virtual desktop feature is very limited - if the first program on a prefix starts without a virtual desktop, all programs launched during the same session also start without a VD, disregarding any VD settings and/or requests with environment variables. And vice versa - if the first program starts inside a VD, all other programs in that sessions start in the VD. Often, this can be worked around by using separate Wine prefixes. Yet sometimes, this workaround is not possible. A good example: steam and games that only run properly in a VD. This forces the user to start steam in a VD and makes steam itself unusable while a game is running, especially if the game does not support the steam overlay. I would like to fix this limitation and make it possible to properly choose to run different programs on one prefix with or without a VD regardless what was chosen to programs already running in that prefix. I can already see this requiring changes in the winecfg utility, by the way. In case this turns out to be too easy of a project, I could implement some way to perform "alt-tabbing" between programs in a VD and/or an optional (enable-able in winecfg) rudimentary taskbar for changing/checking focus. I am very excited about participating in GSoC. And even more excited about starting to contribute to Wine by writing patches! Regardless if I get accepted or not, I wish to make Wine better. Thus, expect me to start submitting patches in the future even if I do not get accepted. ;] Sincerely, Gediminas Jakutis ---- LDK Varčiai www.varciai.lt

3 3

Re: winemac: Implement GetDeviceGammaRamp() and SetDeviceGammaRamp().
by André Hentschel 20 Mar '13

20 Mar '13

Am 18.03.2013 04:41, schrieb Ken Thomases: > --- > dlls/winemac.drv/display.c | 131 ++++++++++++++++++++++++++++++++++++++++++++ > dlls/winemac.drv/gdi.c | 4 +- > dlls/winemac.drv/macdrv.h | 2 + > 3 files changed, 135 insertions(+), 2 deletions(-) Hi, wrt macdrv_SetDeviceGammaRamp, the X11 driver has some validation in xvidmode.c->ComputeGammaFromRamp() because windows doesn't allow every ramp. It might happen that apps try bad ramps and the screen simply gets dark without validation. I'll see if i can copy/move the validation to gdi32 where the driver function normally get's called so that the validation is driver independent. -- Best Regards, André Hentschel

2 1

Re: [PATCH 2/2] msvcrt: Fixed fgetwc behavior on multibyte characters and unicode files
by Akihiro Sagawa 20 Mar '13

20 Mar '13

On Mon, 18 Mar 2013 17:11:04 +0100, Piotr Caban wrote: > + char mbs[2]; This should be a constant, like MSVCRT_MB_LEN_MAX. > + int len = 0; > + ch = MSVCRT_fgetc(file); > + if(ch != MSVCRT_EOF) { > + mbs[0] = (char)ch; > + if(MSVCRT_isleadbyte(mbs[0])) { This doesn't work correctly if char is signed. Because _isleadbyte() expects the value of unsigned char or EOF as well as other is- functions. I wrote some fgetwc() tests. Please refer following page: https://testbot.winehq.org/JobDetails.pl?Key=24806 Akihiro Sagawa

2 1

Re: [7/10] winemenubuilder: Create a basic Info.plist.
by Ken Thomases 20 Mar '13

20 Mar '13

On Mar 17, 2013, at 12:18 PM, Per Johansson wrote: > + namestr = CFStringCreateWithCString(NULL, link_name, CFStringGetSystemEncoding()); You should use CFStringCreateWithFileSystemRepresentation() to create CFStrings from POSIX path strings. > + pathstr = CFStringCreateWithCString(NULL, path, CFStringGetSystemEncoding()); Same thing here. > + data = CFPropertyListCreateData(NULL, propertyList, format, 0, &err); Since you don't use "err", just pass NULL. -Ken

2 1

Re: [10/10] winemenubuilder: Put appbundle icon inside the bundle.
by Ken Thomases 19 Mar '13

19 Mar '13

On Mar 17, 2013, at 12:18 PM, Per Johansson wrote: > + CFStringRef iconstr = CFStringCreateWithCString(NULL, icon, CFStringGetSystemEncoding()); Another place to use CFStringCreateWithFileSystemRepresentation(). -Ken

1 0

Re: msvcr110: add a stub for __crtGetShowWindowMode
by Dmitry Timoshkov 18 Mar '13

18 Mar '13

Austin English <austinenglish(a)gmail.com> wrote: > +int CDECL __crtGetShowWindowMode(void) > +{ > + FIXME(": stub!\n"); > + return 0; > +} Isn't it supposed to return SW_SHOW and other SW_xxx commands, specified at process creation time (SW_SHOWDEFAULT)? In that case returning 0 (SW_HIDE) is not a very good choice. -- Dmitry.

1 0

Re: [0/10] Launcher app bundles on OS X
by C.W. Betts 18 Mar '13

18 Mar '13

A quick glance at the source revealed that you removed static from some functions. Why? If a function isn't being called outside a source file, it's better to have it be static. This includes functions referenced in structs (but not the structs themselves). A more seasoned developer is welcome to correct me if I'm wrong. On Mar 17, 2013, at 11:18 AM, Per Johansson <per(a)morth.org> wrote: > I'm resending this now after testing it with the Mac driver. > They work well together, the launcher bundle will first briefly > appear in the dock, then exit, and the mac driver icon appears. > > It's split it up into parts for easier review. I've also tried > to make sure that even if e.g. part 6 fails review, part 1 - 5 > can still be applied. > > File type associations are not included because I plan to move > that code into the mac driver but haven't gotten around to it yet. > > Regards, > -- > Per Johansson > > >

2 1

Re: [website] Portuguese translation for release 1.5.25
by Bruno Jesus 18 Mar '13

18 Mar '13

2013/3/18 Lucas Zawacki <lfzawacki(a)gmail.com>: > From: Lucas Zawacki <lfzawacki(a)gmail.com> > > --- > news/pt/2013030101.xml | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > create mode 100644 news/pt/2013030101.xml > > diff --git a/news/pt/2013030101.xml b/news/pt/2013030101.xml > new file mode 100644 > index 0000000..ae13cfd > --- /dev/null > +++ b/news/pt/2013030101.xml > @@ -0,0 +1,14 @@ > +<news> > +<date>1 de Março de 2013</date> > +<title>Wine 1.5.25 lançado</title> > +<body> > + A versão de desenvolvimento 1.5.25 já está disponível agora. > + <a href="{$root}/announce/1.5.25">Novidades</a> desta versão: > +<ul> > + <li>Suporte adequado ao cursor no driver de Mac.</li> > + <li>Correções no suporte a escrita direita-para-esquerda no RichEdit.</li> > + <li>Versão inicial da uma fonte Wingdings.</li> Should be: Versão inicial de uma fonte Wingdings. Or: Versão inicial da fonte Wingdings. > + <li>Várias correções de bugs.</li> > +O código fonte está <a href="http://prdownloads.sourceforge.net/wine/wine-1.5.25.tar.bz2">disponível agora</a>. > +Pacotes binários estão em processo de construção e irão aparecer em breve em suas respectivas <a href="{$root}/download">sessões da área de downloads</a>. > +</body></news> > -- > 1.7.9.5 > > > Best wishes, Bruno

2 1

Re: usp10: Support GPOS extension lookup subtables
by Aric Stewart 18 Mar '13

18 Mar '13

Hi Phil, Thank you for being patient I am back from vacation and reviewing your patch. The logic looks great and just fine. Do you happen to have a font that uses lookup type 9 that I can run my usp test suite on to make sure it functions as expected? thanks! -aric On 3/8/13 10:47 AM, Phil Krylov wrote: > > > >

1 0

WineD3D performance
by Graham Knap 18 Mar '13

18 Mar '13

Hi everyone I would like to try to help with improving the performance of StarCraft II on Wine. I'm working with a friend. Over the past couple of weeks, we have tried to read whatever documentation we could find. We have tried a couple of different approaches to profiling, without much success. My friend got WineD3D running on Windows. We built Wine from current source code, tested this on two different configurations, and got similar results. - my Core 2 E8500 + GeForce 9600GT + Windows XP x86 - his i5-2500 + GeForce 660 + Windows 7 x64 It looks like WineD3D is the cause of most of the performance difference. Windows with its own D3D gave us at least twice the frame rate of Windows + WineD3D. There is some difference between the numbers for Windows + WineD3D and Linux + Wine, but it's much smaller, i.e. something like 25%. Can anyone offer some hints on how to find the most significant causes of the performance difference? Any tips for effective profiling or tracing? Thanks. -- graham

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel