July 2012 - Wine-Devel - list.winehq.org

Re: winex11.drv: xrandr1.2 don't assume CRTC 0 is active

by Henri Verbeet

On 30 July 2012 20:13, Alexandre Julliard <julliard(a)winehq.org> wrote: > This clearly needs a helper function. > I'm not sure if this really makes sense to begin with. CRTC 0 is supposed to be the primary display. With proper multihead support we'd be able to enumerate the other display as well, and change modes on them etc., but I suspect disabling the primary display isn't going to give very good results on native Windows either, except perhaps for applications that have multihead support themselves.

July 30, 2012

Re: Incompatibilities between different versions of msvcp dlls

by Alexandre Julliard

Piotr Caban <piotr.caban(a)gmail.com> writes: > In current way of implementing such differences it will lead to > keeping a copy of ios.c and locale.c files in msvcp60, msvcp71, > msvcp90 and msvcp100. The changes in code are minimal in these cases > (e.g. in ctype class case it's enough to remove _s functions in vtable > and change offsets in call_* macros for msvcp71/msvcp100). > > Do you have any ideas about solving this problem? Is it acceptable to > add version specific defines to make the files identical between dlls? If the changes are small enough you should be able to keep the files updated by doing a simple 3-way merge when you change one of them. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2012

Re: [PATCH] ntdll: add mmap caching

by Alexandre Julliard

Michael Blumenkrantz <michael.blumenkrantz(a)gmail.com> writes: > Hi, > > Attached is a patch that I wrote a year ago with the help of Bernhard Loos > (jhgf). For various reasons, I didn't get around to submitting it until now. > > This patch adds caching to NtMapViewOfSection() to reduce the frequency of > blocking server requests which occur, instead replacing them with lookups to a > wine rbtree, which is populated during NtCreateSection() and cleared during > close_handle(). While I don't have any performance statistics to show, this > should yield some definite benefits in nearly every modern game given that they > all repeatedly read mmapped sections of files. > > Bernhard suggested to me, at the time of writing this, that there could be some > potential compatibility issues with regard to sharing, but I don't know nearly > enough about the internals here to speculate. There are worse issues, like the lack of locking, and the fact that you are slowing down the close handle path, which will impact every application for a debatable benefit in a few cases. You'll need to show very convincing benchmarks if you want to pursue this further. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2012

Re: winex11.drv: xrandr1.2 don't assume CRTC 0 is active

by Alexandre Julliard

Patrick Rudolph <siro(a)das-labor.org> writes: > @@ -279,15 +279,34 @@ static int xrandr12_get_current_mode(void) > return 0; > } > > - if (!resources->ncrtc || !(crtc_info = pXRRGetCrtcInfo( gdi_display, resources, resources->crtcs[0] ))) > + if (!resources->ncrtc) > { > pXRRFreeScreenResources( resources ); > wine_tsx11_unlock(); > - ERR("Failed to get CRTC info.\n"); > + ERR("No CRTCs found.\n"); > return 0; > } > + for(i=0;resources->ncrtc;i++) > + { > + > + if (!(crtc_info = pXRRGetCrtcInfo( gdi_display, resources, resources->crtcs[i] ))) > + { > + pXRRFreeScreenResources( resources ); > + wine_tsx11_unlock(); > + ERR("Failed to get CRTC info.\n"); > + return 0; > + } > + /* verify that crtc i is active */ > + if((!crtc_info->mode) && (!crtc_info->width) && (!crtc_info->height)) > + if(i+1 < resources->ncrtc) /* crtc i is disabled, test for more crtcs */ > + pXRRFreeCrtcInfo( crtc_info ); > + else > + break; > + else > + break; > + } This clearly needs a helper function. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2012

Error 123

by Zachary Shields

Hi, I just installed Wine on my comp and everything went well. However, when I installed my program and try to open it it gives me the error: Unable to open com port (win error code: 123) Anyone have any ideas on how to fix this? Thanks, Zachary -- Zachary Nischan Shields 317.627.3628 NischanPictures.com

July 30, 2012

Re: [PATCH 3/3] advapi32/tests: Simple tests for TokenIntegrityLevel [try2]

by Nikolay Sivov

On 7/30/2012 19:08, Detlef Riekenberg wrote: > try2: now using EqualSid. > > Thanks Nikolay for comments > > > - pConvertSidToStringSidA = (void *)GetProcAddress( hmod, "ConvertSidToStringSidA" ); > - if( !pConvertSidToStringSidA ) > - return; > - pConvertStringSidToSidA = (void *)GetProcAddress( hmod, "ConvertStringSidToSidA" ); > - if( !pConvertStringSidToSidA ) > + if( !pConvertSidToStringSidA || !pConvertStringSidToSidA ) > + { > + skip("ConvertSidToStringSidA or ConvertStringSidToSidA not available\n"); > return; > + } I probably missed that, you need to use win_skip here. > > r = pConvertStringSidToSidA( NULL, NULL ); > ok( !r, "expected failure with NULL parameters\n" ); > @@ -4274,6 +4275,73 @@ static void test_kernel_objects_security(void) > CloseHandle(token); > } > > +static void test_TokenIntegrityLevel(void) > +{ > + TOKEN_MANDATORY_LABEL *tml; > + HANDLE token; > + DWORD size; > + DWORD res; > + LPVOID buffer = NULL; > + char *sidname = NULL; > + static SID medium_level = {SID_REVISION, 1, {SECURITY_MANDATORY_LABEL_AUTHORITY}, > + {SECURITY_MANDATORY_HIGH_RID}}; > + static SID high_level = {SID_REVISION, 1, {SECURITY_MANDATORY_LABEL_AUTHORITY}, > + {SECURITY_MANDATORY_MEDIUM_RID}}; > + > + if(!pConvertSidToStringSidA) > + { > + skip("ConvertSidToStringSidA not available\n"); > + return; > + } and here. > + > + SetLastError(0xdeadbeef); > + res = OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &token); > + ok(res, "got %d with %d (expected TRUE)\n", res, GetLastError()); > + if (!res) > + return; Does it really fail on some test machine? > + > + SetLastError(0xdeadbeef); > + res = GetTokenInformation(token, TokenIntegrityLevel, NULL, 0, &size); > + > + /* not supported before Vista */ > + if (!res && (GetLastError() == ERROR_INVALID_PARAMETER)) > + { > + skip("TokenIntegrityLevel not supported\n"); > + CloseHandle(token); > + return; > + } > + > + if (!res && (GetLastError() == ERROR_INSUFFICIENT_BUFFER)) > + { > + buffer = HeapAlloc(GetProcessHeap(), 0, size); > + SetLastError(0xdeadbeef); > + res = GetTokenInformation(token, TokenIntegrityLevel, buffer, size, &size); > + } Again, you don't need to allocate anything here, so you don't need cleanup code.

July 30, 2012

Re: (resend)[1/2]usp10: cache OUTLINETEXTMETRICW instead of just TEXTMETRICW

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > --- > dlls/usp10/usp10.c | 28 +++++++++++++++++----------- > dlls/usp10/usp10_internal.h | 2 +- > 2 files changed, 18 insertions(+), 12 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so ipaddress.c && touch ipaddress.ok wine: Unhandled page fault on read access to 0x0000005c at address 0x555aef2c (thread 002c), starting debugger... Unhandled exception: page fault on read access to 0x0000005c in 32-bit code (0x555aef2c). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:555aef2c ESP:0032efa0 EBP:0032efe8 EFLAGS:00010206( R- -- I - -P- ) EAX:00131190 EBX:555c0bb4 ECX:00131190 EDX:00000000 ESI:00131140 EDI:00000000 Stack dump: 0x0032efa0: 00110000 00000000 00000008 686def04 0x0032efb0: 6872a969 687735a8 0032f078 00000001 0x0032efc0: 00000000 0000007c 027f0c7f 687735a8 0x0032efd0: 00130ed8 00000000 555aee8b 687735a8 0x0032efe0: 00130ed8 00000000 0032f008 686d2fd9 0x0032eff0: 00131140 00000000 00000000 687735a8 Backtrace: =>0 0x555aef2c ScriptString_pSize+0xac(ssa=0x131140) [/home/julliard/wine/wine/dlls/usp10/usp10.c:3496] in usp10 (0x0032efe8) 1 0x686d2fd9 EDIT_CalcLineWidth_SL+0x38(es=0x130ed8) [/home/julliard/wine/wine/dlls/user32/edit.c:821] in user32 (0x0032f008) 2 0x686d787f EDIT_EM_ReplaceSel+0x79e(es=<internal error>, can_undo=0, lpsz_replace="1", send_update=0, honor_limit=0) [/home/julliard/wine/wine/dlls/user32/edit.c:2655] in user32 (0x0032f098) 3 0x686db93c EditWndProc_common+0x256b(hwnd=0x50026, msg=0xc, wParam=0, lParam=0x32f5c4, unicode=0x1) [/home/julliard/wine/wine/dlls/user32/edit.c:3876] in user32 (0x0032f128) 4 0x6873b60b EditWndProcW+0x3a(hwnd=0x50026, msg=0xc, wParam=0, lParam=0x32f5c4) [/home/julliard/wine/wine/dlls/user32/winproc.c:1081] in user32 (0x0032f158) 5 0x6873b42a WINPROC_wrapper+0x19() in user32 (0x0032f188) 6 0x6873bb7c call_window_proc+0x5b(hwnd=0x50026, msg=0xc, wp=0, lp=0x32f5c4, result=0x32f20c, arg=0x6873b5d0) [/home/julliard/wine/wine/dlls/user32/winproc.c:242] in user32 (0x0032f1d8) 7 0x6873e5ad CallWindowProcW+0x5c(func=0x6873b5d0, hwnd=0x50026, msg=0xc, wParam=0, lParam=0x32f5c4) [/home/julliard/wine/wine/dlls/user32/winproc.c:980] in user32 (0x0032f228) fixme:dbghelp_dwarf:compute_location Only supporting one breg (edi/24 -> esi/23) 8 0x685c1cf5 IPADDRESS_SubclassProc+0xc4(hwnd=0x50026, uMsg=0xc, wParam=0, lParam=0x32f5c4) [/home/julliard/wine/wine/dlls/comctl32/ipaddress.c:555] in comctl32 (0x0032f2a8) 9 0x6873b42a WINPROC_wrapper+0x19() in user32 (0x0032f2d8) 10 0x6873bb7c call_window_proc+0x5b(hwnd=0x50026, msg=0xc, wp=0, lp=0x32f5c4, result=0x32f3a8, arg=0x685c1c30) [/home/julliard/wine/wine/dlls/user32/winproc.c:242] in user32 (0x0032f328) 11 0x6873e328 WINPROC_call_window+0x107(hwnd=0x50026, msg=0xc, wParam=0, lParam=0x32f5c4, result=0x32f3a8, unicode=0x1, mapping=1750868266) [/home/julliard/wine/wine/dlls/user32/winproc.c:908] in user32 (0x0032f378) 12 0x686fe88d call_window_proc+0x8c(hwnd=0x50026, msg=0xc, wparam=0, lparam=0x32f5c4, unicode=0x1, same_thread=0x1, mapping=1750868266) [/home/julliard/wine/wine/dlls/user32/message.c:2211] in user32 (0x0032f3d8) 13 0x6870557e send_message+0x20d(info=0x32f464, res_ptr=0x32f460, unicode=0x1) [/home/julliard/wine/wine/dlls/user32/message.c:3084] in user32 (0x0032f448) 14 0x687059ec SendMessageW+0x4b(hwnd=0x50026, msg=0xc, wparam=0, lparam=0x32f5c4) [/home/julliard/wine/wine/dlls/user32/message.c:3278] in user32 (0x0032f498) 15 0x6872d43b SetWindowTextW+0x6a(hwnd=0x50026, lpString="1") [/home/julliard/wine/wine/dlls/user32/win.c:2592] in user32 (0x0032f4c8) 16 0x685c2b7a IPADDRESS_WindowProc+0xaf9(hwnd=0xc0060, uMsg=0x465, wParam=0, lParam=0x7f000001) [/home/julliard/wine/wine/dlls/comctl32/ipaddress.c:365] in comctl32 (0x0032f638) 17 0x6873b42a WINPROC_wrapper+0x19() in user32 (0x0032f668) 18 0x6873bb7c call_window_proc+0x5b(hwnd=0xc0060, msg=0x465, wp=0, lp=0x7f000001, result=0x32fbf8, arg=0x685c2080) [/home/julliard/wine/wine/dlls/user32/winproc.c:242] in user32 (0x0032f6b8) 19 0x6873d210 WINPROC_CallProcAtoW+0xaf(callback=0x6873bb20, hwnd=0xc0060, msg=0x465, wParam=0, lParam=0x7f000001, result=0x32fbf8, arg=0x685c2080, mapping=WMCHAR_MAP_SENDMESSAGE) [/home/julliard/wine/wine/dlls/user32/winproc.c:502] in user32 (0x0032fb78) 20 0x6873e39b WINPROC_call_window+0x17a(hwnd=0xc0060, msg=0x465, wParam=0, lParam=0x7f000001, result=0x32fbf8, unicode=0, mapping=WMCHAR_MAP_SENDMESSAGE) [/home/julliard/wine/wine/dlls/user32/winproc.c:910] in user32 (0x0032fbc8) 21 0x686fe88d call_window_proc+0x8c(hwnd=0xc0060, msg=0x465, wparam=0, lparam=0x7f000001, unicode=0, same_thread=0x1, mapping=WMCHAR_MAP_SENDMESSAGE) [/home/julliard/wine/wine/dlls/user32/message.c:2211] in user32 (0x0032fc28) 22 0x6870557e send_message+0x20d(info=0x32fcb4, res_ptr=0x32fcb0, unicode=0) [/home/julliard/wine/wine/dlls/user32/message.c:3084] in user32 (0x0032fc98) 23 0x68705993 SendMessageA+0x52(hwnd=0xc0060, msg=0x465, wparam=0, lparam=0x7f000001) [/home/julliard/wine/wine/dlls/user32/message.c:3300] in user32 (0x0032fce8) 24 0x684f4ca3 func_ipaddress+0x1a2() [/home/julliard/wine/wine/dlls/comctl32/tests/ipaddress.c:56] in comctl32_test (0x0032fd58) 25 0x684d8807 main+0x386(argc=<couldn't compute location>, argv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/comctl32/tests/../../../include/wine/test.h:557] in comctl32_test (0x0032fe28) 26 0x6856ae35 __wine_spec_exe_entry+0x74(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in comctl32_test (0x0032fe70) 27 0x7b85c9fc call_process_entry+0xb() in kernel32 (0x0032fe88) 28 0x7b85dbcf start_process+0x5e(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1083] in kernel32 (0x0032fec8) 29 0x7bc76ed0 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 30 0x7bc79c0d call_thread_func+0x7c(entry=0x7b85db70, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2522] in ntdll (0x0032ffa8) 31 0x7bc76eae call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 32 0x7bc4ee5e start_process+0x1d(kernel_start=0x7b85db70) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2653] in ntdll (0x0032ffe8) 33 0x6802947d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 34 0x6802953b wine_switch_to_stack+0x2a(func=0x7bc4ee40, arg=0x7b85db70, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xffb4dc78) 35 0x7bc547e8 LdrInitializeThunk+0x3b7(kernel_start=0x7b85db70, unknown2=0, unknown3=0, unknown4=0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2709] in ntdll (0xffb4dce8) 36 0x7b863cd8 __wine_kernel_init+0xbb7() [/home/julliard/wine/wine/dlls/kernel32/process.c:1255] in kernel32 (0xffb4ebe8) 37 0x7bc54e63 __wine_process_init+0x182() [/home/julliard/wine/wine/dlls/ntdll/loader.c:2918] in ntdll (0xffb4ec68) 38 0x680270c2 wine_init+0x2a1(argc=0x3, argv=0xffb4f1b4, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:831] in libwine.so.1 (0xffb4ecc8) 39 0x7bf00ebb main+0x7a(argc=0x3, argv=0xffb4f1b4) [/home/julliard/wine/wine/loader/main.c:230] in <wine-loader> (0xffb4f108) 40 0x681c0e46 __libc_start_main+0xe5() in libc.so.6 (0xffb4f188) 0x555aef2c ScriptString_pSize+0xac [/home/julliard/wine/wine/dlls/usp10/usp10.c:3496] in usp10: movl 0x5c(%edx),%edx 3496 analysis->sz->cy = analysis->glyphs[0].sc->tm->otmTextMetrics.tmHeight; -- Alexandre Julliard julliard(a)winehq.org

July 30, 2012

Re: include: fix mingw64 build

by Francois Gouget

On Sat, 28 Jul 2012, Jacek Caban wrote: > Hi Francois, > > On 7/28/12 9:22 AM, Francois Gouget wrote: > > Note that I had to add a couple of patches to get Wine to compile: > > * crtdefs.h uses wchar_t but does not define it which was causing > > trouble depending on the order of the includes in the source. > > * One of the _mingw.h includes was causing trouble. Replacing it with a > > crtdefs.h include like the others fixed the issue. There is still a > > ton of these so I'm not sure these packages are a full fix. But Wine > > compiles at least. > > What's the error you get? I could successfully build Wine with current > mingw-w64 2.0 branch without errors. I think we should make sure to upstream > such fixes either to Wine or mingw-w64, depending where appropriate. I cannot reproduce the problem anymore (even when reverting my extra patch). It may be that something went wrong the first time I rebuilt the MinGW64 package so that it was missing some of your patch. -- Francois Gouget <fgouget(a)codeweavers.com>,

July 30, 2012

Re: GSoC mentor summit 2012

by Aric Stewart

I could be interested. I have never been and am a first time mentor. October is still a bit far off for me to be able to plan. So if someone else can completely commit that is cool. But I will try to get info about my availability that weekend asap. -aric On 7/26/12 10:07 AM, Owen Rudge wrote: > It looks like the GSoC mentor summit for 2012 has been announced. Are > any of the mentors this year interested in attending? It's happening on > the 20th/21st October in Mountain View. > > Details are on the GSoC mentor wiki: > > http://gsoc-wiki.osuosl.org/index.php/2012 > > Cheers, >

July 30, 2012

Re: __wine_uuidof causing a wall of "warning: returning reference to temporary" on g++

by Ilya Konstantinov

On Sun, Jul 29, 2012 at 9:47 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > Upon first attempts to compile, I've received a wall of "warning: >> returning reference to temporary" on Wine's headers from g++. >> All of those seem to stem from guidgen.h definition of __wine_uuidof / >> __CRT_UUID_DECL for C++. >> > > I don't see these warnings here. Also Wine has the same code for __uuidof > as mingw-w64, which is much more widely used with g++ (Wine is mostly > tested on C), and I never heard about such problem. Do you have any idea > about what could be different in your setup? What's your g++ version? I'm using gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) to build my Winelib app. As to the difference from mingw-w64, I see different code in there: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=revision&revisio… The idea is that if matches closer to the meaning of __uuidof, which should > return a reference to constant IID structure. Understood. > I'd expect compiler to be smart enough to produce same code without the > reference anyway (after all it's an inline function), but still being more > explicit would be nice. Could you please test if the attached patch fixes > the problem for you? Yep, it does.

July 30, 2012