December 2009 - Wine-Devel - list.winehq.org

Re: [1/6]user32:SwitchDesktop API Implementation (try 2)
by Vitaliy Margolen Dec. 13, 2009

Dec. 13, 2009

shanmukha sainath addepalli wrote: > Hi, > > These are the series of patches for the Implementation of > SwitchDesktop and OpenInputDesktop API in user32.dll. SwitchDesktop > API is useful for switching between two desktops. Multi desktop > applications use this API functionality to switch between desktops. > Each patch have to be atomic - it should compile on it's own and work. This and other patches in your series won't compile / work. > + SERVER_START_REQ( switch_desktop ) Here you depend on a service call that's not yet defined. Wine will not compile this way. Vitaliy.

1 0

Interfacing with AppDB database
by Sean Hodges Dec. 13, 2009

Dec. 13, 2009

Hey all, I'm hoping to write an application that interfaces with the AppDB database. Can anyone point me in the direction of who I can contact over this? There appears to be no Web service or obvious way to query AppDB beyond navigating the site itself. Could you CC me in any replies as well, as I'm not subscribed to this list. Thanks, Sean

3 2

Re: mshtml: Implement IHTMLImgElement get_Name
by Paul Vriens Dec. 13, 2009

Dec. 13, 2009

On 12/13/2009 12:11 PM, Alistair Leslie-Hughes wrote: > + ok_(__FILE__,line) (!lstrcmpW(sNameImage, tmp), "expected '%s' got '%s'\n", wine_dbgstr_w(sNameImage), wine_dbgstr_w(tmp)); Hi Alistair, Could you use strcmp_wa instead of lstrcmpW as that function is not present on Win9x/WinMe? -- Cheers, Paul.

1 0

meaning of "Hardware" field in bugzilla?
by Dan Kegel Dec. 13, 2009

Dec. 13, 2009

Does "mac" mean "powerpc mac only"? I rather thought it meant "apple macintosh", regardless of cpu. I ask because Austin has just gone through and changed lots of "mac" bugs to "pc" even though the bugs were on Intel macs, which just seems wrong.

8 8

Sound concerns
by Maarten Lankhorst Dec. 12, 2009

Dec. 12, 2009

Hi all, I believe most oconcerns about OpenAL have been addressed. One of the open questions was whether midi and wave would be synced. And I think the most likely answer is that they aren't, even on windows. On windows winmm midi drivers use winmm timeGetTime or QueryPerformanceCounter for DirectMusic. Sample accurate wave is used to sync with midi, by using exclusive mode or the asio model. If there are any other open concerns, apart from packaging, let me know, since I really want to get dsound openal merged. :) If there are still concerns that are open I would like to know, especially if they affect wasapi which is defined in include/audioclient.idl and audiopolicy.idl Cheers, Maarten.

3 5

Re: [3/3] winex11.drv: Use the old method to delete the desktop window.
by Alexandre Julliard Dec. 11, 2009

Dec. 11, 2009

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > @@ -516,6 +516,14 @@ static void handle_wm_protocols( HWND hwnd, XClientMessageEvent *event ) > HMENU hSysMenu; > POINT pt; > > + if (hwnd == GetDesktopWindow()) > + { > + /* The desktop window does not have a close button that we can > + * pretend to click. Therefore, we simply send it a close command. */ > + PostMessageW( hwnd, WM_X11DRV_DELETE_WINDOW, 0, 0 ); > + return; > + } You could just as well send the WM_SYSCOMMAND directly. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: WineD3D: Frontbuffers are always onscreen
by Henri Verbeet Dec. 11, 2009

Dec. 11, 2009

2009/12/10 Stefan Dösinger <stefan(a)codeweavers.com>: > @@ -6304,7 +6304,7 @@ HRESULT create_primary_opengl_context(IWineD3DDevice *iface, IWineD3DSwapChain * ... > - swapchain->context[0]->render_offscreen = swapchain->render_to_fbo; > + swapchain->context[0]->render_offscreen = surface_is_offscreen(target); This will introduce a warning, surface_is_offscreen() takes an IWineD3DSurface pointer. > - > - swapchain->context[0]->render_offscreen = swapchain->render_to_fbo; ... > + if(swapchain->context[0]) > + { > + swapchain->context[0]->render_offscreen = swapchain->render_to_fbo; > + } That's pretty ugly, couple of points: - It doesn't make sense for "render_to_fbo" to be TRUE for a swapchain without back buffer. - Setting "render_offscreen" is really the responsibility of the context_create() call, similar to create_primary_opengl_context(). - The line is actually wrong, the relevant context has been setup to render to the front buffer, so "render_offscreen" should always be FALSE, even if there is a back buffer.

2 6

Valgrind errors: 893 leaks, 105 conditional depends on uninit, 63 invalid read, 12 invalid write, ...
by Dan Kegel Dec. 11, 2009

Dec. 11, 2009

Here's a more detailed breakdown of the current valgrind warnings when running the wine test suite as of yesterday, with the ntdll/heap warnings suppressed (as they will be from now on): 1 --25396-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting 1 vex x86->IR: unhandled instruction bytes: 0xFB 0xC3 0x0 0x0 2 Source and destination overlap 3 Use of uninitialised value of size 4 4 Invalid read of size 1 4 Invalid write of size 4 4 Unhandled exception: illegal instruction 5 Unhandled exception: page fault on write 7 Unhandled exception: page fault on read 7 Invalid free() / delete / delete[] 8 Invalid write of size 1 14 Syscall param writev(vector[...]) points to uninitialised byte(s) 19 Invalid read of size 4 40 Invalid read of size 2 105 Conditional jump or move depends on uninitialised value(s) 893 X bytes are definitely lost I think *all* the remaining invalid write errors are bogus, either they're in GetDIBits, in a video driver, or in the stack backtracing code. All of the remaining invalid free errors are in the oleaut32 vartype test: Invalid free() / delete / delete[] at notify_free (heap.c:255) by RtlFreeHeap (heap.c:1748) by SysFreeString (oleaut.c:194) by test_VarBstrFromDate (vartype.c:4910) by func_vartype (vartype.c:6276) by run_test (test.h:535) by main (test.h:585) Address 0x7f0a1560 is not stack'd, malloc'd or (recently) free'd for which I've filed http://bugs.winehq.org/show_bug.cgi?id=20992

1 0

UNC Pathname handling
by Alexandre Hardy Dec. 11, 2009

Dec. 11, 2009

Hi, I have written a patch to add basic UNC pathname support which tries to handle UNC pathnames according to the MSDN spec. The patch satisfies some of the UNC pathname tests for GetLongPathNameA, but is actually intended to fix GetLongPathNameW. I am not entirely satisfied with the patch, and would appreciate some comments. Some issues: 1) Paths prefixed by '\\?\' require GetLongPathName to handle strings of length 32767. I don't like the fact that the patch creates two such large strings on the local stack, should the memory be dynamically allocated only when needed? 2) The handling of shares \\hostname\C$ is implemented, but no other shares are handled. And even in this case, only the host on which wine is executed is handled, no other hosts are handled. I have read that Windows 7 disables this share by default. So should wine be handling this particular URL, or should more general sharing be implemented? The patch is included as an attachment to this message. Kind regards Alexandre -- -------------------------------------------------- Alexandre Hardy http://www.ahardy.za.net

2 16

Re: shdocvw: Fix test for non-english IE MUI (try 2)
by Nicolas Le Cam Dec. 11, 2009

Dec. 11, 2009

2009/12/11 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > > > Changelog: > shdocvw: Fix test for non-english IE MUI > > Best Regards > Alistair Leslie-Hughes > > > > Hi Alistair, - ok(!strcmp_wa(sName, "Microsoft Web Browser Control"), "got '%s', expected 'Microsoft Web Browser Control'\n", wine_dbgstr_w(sName)); + if (PRIMARYLANGID(LANGIDFROMLCID(GetThreadLocale())) == LANG_ENGLISH) + ok(!strcmp_wa(sName, "Microsoft Web Browser Control"), "got '%s', expected 'Microsoft Web Browser Control'\n", wine_dbgstr_w(sName)); + else /* Non-English cannot be blant. */ + ok(sName!=NULL, "get_Name return a NULL string.\n"); Did you mean blank ? -- Nicolas Le Cam

1 0

Re: [PATCH 2/2] server: Include user groups in file mode calculation when user is file owner
by Alexandre Julliard Dec. 11, 2009

Dec. 11, 2009

"Ben Peddell" <klightspeed(a)netspace.net.au> writes: > @@ -474,7 +475,9 @@ mode_t sd_to_mode( const struct security_descriptor *sd, const SID *owner ) > if (access & FILE_EXECUTE) > denied_mode |= S_IXUSR|S_IXGRP|S_IXOTH; > } > - else if (security_equal_sid( sid, owner )) > + else if (security_equal_sid( sid, owner ) || > + (security_equal_sid( user, owner ) && > + token_sid_present( current->process->token, sid, TRUE ))) > { > unsigned int access = generic_file_map_access( ad_ace->Mask ); > if (access & FILE_READ_DATA) > @@ -498,7 +501,9 @@ mode_t sd_to_mode( const struct security_descriptor *sd, const SID *owner ) > if (access & FILE_EXECUTE) > new_mode |= S_IXUSR|S_IXGRP|S_IXOTH; > } > - else if (security_equal_sid( sid, owner )) > + else if (security_equal_sid( sid, owner ) || > + (security_equal_sid( user, owner ) && > + token_sid_present( current->process->token, sid, FALSE ))) You should most likely set the group permissions too in that case. -- Alexandre Julliard julliard(a)winehq.org

2 3

Unable to cleanly install cups-devel.i686 on a Fedora 12 x86_64 machine
by Alex Villacís Lasso Dec. 11, 2009

Dec. 11, 2009

I have just updated my setup to Fedora 12 on 64 bits, and I want to compile Wine for this setup. I followed the instructions at: http://wiki.winehq.org/WineOn64bit on the section for Fedora 12. However, I have the following error when trying to install the packages as directed by the wiki: Error en la verificación de la transacción: file /usr/bin/cups-config from install of cups-devel-1:1.4.2-7.fc12.i686 conflicts with file from package cups-devel-1:1.4.2-7.fc12.x86_64 Resumen de errores ------------- What I understand from this is that /usr/bin/cups-config is provided by both packages, and cannot be marked as shared by both packages. I want to have both 32 and 64-bit support for compiling programs that use CUPS. Does this problem have a clean workaround? Or should I complain instead to the Fedora packagers?

5 4

Re: [2/3] wineboot: Terminate processes immediately after WM_ENDSESSION.
by Juan Lang Dec. 10, 2009

Dec. 10, 2009

Hi Vincent, - /* wait for app to quit on its own for a while */ - ret = WaitForSingleObject( process_handle, PROCQUIT_TIMEOUT ); + /* Check whether the app quit on its own */ + ret = WaitForSingleObject( process_handle, 0 ); CloseHandle( process_handle ); if (ret == WAIT_TIMEOUT) I'm confused why you removed the timeout. The documented behavior[1, 2] is to wait a short timeout, show a dialog if the app hasn't quit by then, then kill it. This change makes wineboot terminate a process immediately. Is this really necessary to fix the bug? I'd expect that you want to handle the WAIT_OBJECT_0 case in addition to the WAIT_TIMEOUT case, and leave the timeout alone. --Juan [1] http://blogs.msdn.com/michen/archive/2008/04/04/Application-termination-whe… [2] http://blogs.msdn.com/oldnewthing/archive/2008/04/21/8413175.aspx

2 2

Leaks galore!
by Dan Kegel Dec. 10, 2009

Dec. 10, 2009

http://kegel.com/wine/valgrind/logs/2009-12-05-01.15/ shows the same results as http://kegel.com/wine/valgrind/logs/2009-12-04-18.45/ but with a looser filter, i.e. I now even show files whose only sin is a memory leak (in the past, I had suppressed those because I cared more about non-leak errors). It also suppresses several more persistent sources of warnings, for which I've filed a couple bugs: http://bugs.winehq.org/show_bug.cgi?id=20917 http://bugs.winehq.org/show_bug.cgi?id=20919 With those changes, I now see 457 non-leak errors, (~134 of which are due to the fresh regression http://bugs.winehq.org/show_bug.cgi?id=20920 ) and 1560 leak errors (~300 of which are due to ntlm_auth, which I'm still trying to suppress), in the wine conformance test suite.

5 12

Re: [ddraw/tests] Fix some test failures on Vista+
by Stefan Dösinger Dec. 10, 2009

Dec. 10, 2009

Am 10.12.2009 um 13:21 schrieb Paul Vriens: > <0004-Fix-some-test-failures-on-Vista.patch> > const char *name; > DDPIXELFORMAT fmt; > BOOL getdc_capable; > + HRESULT alt_result; > } testdata[] = { You are setting the alt_result only for the 4 failing tests. I think C sets the others to 0 because the initializer is static data I think its better to explicitly set it in all other test formats to avoid confusion

2 4

Re: winedbg: Add spanish translation
by Paul Vriens Dec. 10, 2009

Dec. 10, 2009

On 12/09/2009 03:30 AM, Jaime Rave wrote: > +LANGUAGE LANG_SPANISH, SUBLANG_DEFAULT Hi, Shouldn't this one need a SUBLANG_NEUTRAL instead? Or is this translation specific to "Spanish (Traditional Sort)"? See also: http://wiki.winehq.org/SublangNeutral -- Cheers, Paul.

1 0

Re: [PATCH 2/2] mmdevapi: add some initial tests
by Alexandre Julliard Dec. 10, 2009

Dec. 10, 2009

1 0

Re: [PATCH 2/7] dsound: Clean up DSPROPERTY_DescriptionW, try 2
by Detlef Riekenberg Dec. 10, 2009

Dec. 10, 2009

On Mi, 2009-12-09 at 16:57 +0100, Maarten Lankhorst wrote: > + { > + /* FIXME: Still a memory leak.. */ This should be fixed before sending to wine-patches -- By by ... Detlef

2 1

Re: [3/5] WineD3D: Test and fix ddraw and d3d9 GetDC differences
by Paul Vriens Dec. 10, 2009

Dec. 10, 2009

On 09/05/2009 04:54 PM, Stefan Dösinger wrote: > This patch uses a d3d9-side filter in favor of adding a 2nd set of > getdc-capable format flags. > Hi Stefan, These tests have failures on Vista+ boxes: dsurface.c:3243: Test failed: GetDC on a D3DFMT_X8B8G8R8 surface failed(0x88760249), expected it to work dsurface.c:3243: Test failed: GetDC on a D3DFMT_X8B8G8R8 surface failed(0x88760249), expected it to work dsurface.c:3243: Test failed: GetDC on a D3DFMT_A4R4G4B4 surface failed(0x88760249), expected it to work dsurface.c:3243: Test failed: GetDC on a D3DFMT_X4R4G4B4 surface failed(0x88760249), expected it to work These are real ones with NVIDIA, ATI and Intel cards but also VMware boxes with the latest VMware driver "VMware SVGA 3D (Microsoft Corporation - WDDM)". Should I change the test to introduce an alternative result for these 4 formats? -- Cheers, Paul.

2 1

Re: [PATCH 3/4] jscript: Added Function constructor tests.
by Detlef Riekenberg Dec. 10, 2009

Dec. 10, 2009

On Do, 2009-12-10 at 01:15 +0100, Jacek Caban wrote: > +func = new Function(); > +tmp = func(); > +ok(tmp === undefined, "func(1,3,2) = " + tmp) Greetings from Copy & Paste -- By by ... Detlef

1 0

Re: Wine performance improvement
by 임은지 Dec. 9, 2009

Dec. 9, 2009

Dan Kegel wrote: > > > Interesting! Clearly a long ways off from production-ready, but > it's fun to see somebody trying this. > > A few notes: > > Please clean up the patch a bit to remove lines like this: > +//FIXME("handle : %ld \n", handle); > and extra files like > dlls/ws2_32/tests/test.sh > > Please avoid hand-editing > include/wine/server_protocol.h > The start of the file even says: > * This file is automatically generated; DO NO EDIT! > * Edit server/protocol.def instead and re-run tools/make_requests > > Please switch to plain text for future posts. It's very > hard to read in the archive; see > http://www.winehq.org/pipermail/wine-devel/2009-December/080394.html > > Please identify the author(s) of the new code for copyright purposes, > and ensure they agree to licensing their code under the LGPL (for Wine) > and GPL (for Linux kernel). > > I'm sure other people will have more to say. > Thank you for your comments. I will cleanup the patch as you suggested and send it.

3 2

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
by Ken Thomases Dec. 9, 2009

Dec. 9, 2009

The call to setenv() has 0 (false) as its third parameter, so that LANG is not overwritten. -Ken On Nov 23, 2009, at 9:12 AM, Charles Davis wrote: > --- > dlls/kernel32/locale.c | 53 > +++++++++++++++++++++++++---------------------- > 1 files changed, 28 insertions(+), 25 deletions(-) > > > > diff --git a/dlls/kernel32/locale.c b/dlls/kernel32/locale.c > index fb9b517..d9ea8eb 100644 > --- a/dlls/kernel32/locale.c > +++ b/dlls/kernel32/locale.c > @@ -2925,32 +2925,35 @@ void LOCALE_Init(void) > UINT ansi_cp = 1252, oem_cp = 437, mac_cp = 10000, unix_cp; > > #ifdef __APPLE__ > - /* MacOS doesn't set the locale environment variables so we have to do it ourselves */ > - CFArrayRef preferred_locales, all_locales; > CFStringRef user_language_string_ref = NULL; > - char user_locale[50]; > - char* p; > - > - CFLocaleRef user_locale_ref = CFLocaleCopyCurrent(); > - CFStringRef user_locale_string_ref = CFLocaleGetIdentifier( user_locale_ref ); > - > - CFStringGetCString( user_locale_string_ref, user_locale, sizeof(user_locale), kCFStringEncodingUTF8 ); > - CFRelease( user_locale_ref ); > - /* Strip modifiers because setlocale() can't parse them. */ > - if ((p = strchr( user_locale, '@' ))) *p = 0; > - if (!strchr( user_locale, '.' )) strcat( user_locale, ".UTF-8" ); > - unix_cp = CP_UTF8; /* default to utf-8 even if we don't get a valid locale */ > - setenv( "LANG", user_locale, 0 ); > - TRACE( "setting locale to '%s'\n", user_locale ); > - > - /* We still want to set the retrieve the preferred language as chosen in > - System Preferences.app, because it can differ from CFLocaleCopyCurrent(). > - */ > - all_locales = CFLocaleCopyAvailableLocaleIdentifiers(); > - preferred_locales = CFBundleCopyLocalizationsForPreferences( all_locales, NULL ); > - if (preferred_locales && CFArrayGetCount( preferred_locales )) > - user_language_string_ref = CFArrayGetValueAtIndex( preferred_locales, 0 ); > - CFRelease( all_locales ); > + if (!getenv( "LANG" )) > + { > + /* MacOS doesn't set the locale environment variables so we have to do it ourselves */ > + CFArrayRef preferred_locales, all_locales; > + char user_locale[50]; > + char* p; > + > + CFLocaleRef user_locale_ref = CFLocaleCopyCurrent(); > + CFStringRef user_locale_string_ref = CFLocaleGetIdentifier( user_locale_ref ); > + > + CFStringGetCString( user_locale_string_ref, user_locale, sizeof(user_locale), kCFStringEncodingUTF8 ); > + CFRelease( user_locale_ref ); > + /* Strip modifiers because setlocale() can't parse them. */ > + if ((p = strchr( user_locale, '@' ))) *p = 0; > + if (!strchr( user_locale, '.' )) strcat( user_locale, ".UTF-8" ); > + unix_cp = CP_UTF8; /* default to utf-8 even if we don't get a valid locale */ > + setenv( "LANG", user_locale, 0 ); > + TRACE( "setting locale to '%s'\n", user_locale ); > + > + /* We still want to set the retrieve the preferred language as chosen in > + System Preferences.app, because it can differ from CFLocaleCopyCurrent(). > + */ > + all_locales = CFLocaleCopyAvailableLocaleIdentifiers(); > + preferred_locales = CFBundleCopyLocalizationsForPreferences( all_locales, NULL ); > + if (preferred_locales && CFArrayGetCount( preferred_locales )) > + user_language_string_ref = CFArrayGetValueAtIndex( preferred_locales, 0 ); > + CFRelease( all_locales ); > + } > #endif /* __APPLE__ */ > > setlocale( LC_ALL, "" ); > > >

7 19

Regression on Tuesday Dec 8
by Susan Cragin Dec. 9, 2009

Dec. 9, 2009

I was installing Dragon NaturallySpeaking on Tuesday with git and noticed that it was very slow to load. In addition, the "automatic" registration doesn't work as well as it used to. The link to the Scansoft site, to generate the code, does not work. Regression test? Sigh.

1 0

Re: [1/5] ole32: Change the base IStorage filename to a pointer type.
by Paul Vriens Dec. 9, 2009

Dec. 9, 2009

On 12/07/2009 10:17 PM, Vincent Povirk wrote: > + /* Stat always returns the full path, even for files opened with a relative path. */ > + GetCurrentDirectoryW(MAX_PATH, prev_dir); > + > + GetTempPathW(MAX_PATH, temp); > + > + SetCurrentDirectoryW(temp); > + > + GetFullPathNameW(filename, MAX_PATH, full_path,&rel_path); > + > + r = StgCreateDocfile( rel_path, STGM_CREATE | STGM_SHARE_EXCLUSIVE | > + STGM_READWRITE |STGM_TRANSACTED, 0,&stg); Hi Vincent, These tests currently crash on Win9x/WinME due . I rewrote that test to just use A-functions but there are loads of lstrcmpW tests that of course always fail on Win9x (not implemented). Do you think it's worthwhile changing these tests to cope with Win9x/WinMe? -- Cheers, Paul.

2 2

Re: libs/wine: don't try to read() a directory
by Alexandre Julliard Dec. 9, 2009

Dec. 9, 2009

Dan Kegel <dank(a)kegel.com> writes: > Fixes http://bugs.winehq.org/show_bug.cgi?id=20942 Introducing an fd leak to fix a Valgrind warning is not much of an improvement ;-) -- Alexandre Julliard julliard(a)winehq.org

2 1

[PATCH] kernel32: Respect the LANG environment variable on Mac OS.
by Joerg-Cyril.Hoehle＠t-systems.com Dec. 9, 2009

Dec. 9, 2009

Hi, perhaps I should contribute to this thread given that I indirectly triggered it via bug #20377. IMHO Wine, due to its sandbox nature, needs a way to switch language/locale independently on the desktop settings. Much like gcompris allows to choose a language other than the desktop's. No discussion, the default should be the desktop setting. So here, and in bug #20377, the issue is not the default setting. The issue is how to depart from the default. Now use LANG or LC_xyz to switch? The MacOS Terminal.app (as of 10.5.8) sets/shows very few environment variables. LANG is among them, none of LC_xyz is. Therefore I argue that LANG= is the canonical and reasonable choice for a local override on MacOS. It has the additional benefit of being + what Linux users are typically told to use (quick Google survey); + what the Wine Wiki recommends in http://wiki.winehq.org/TestingLanguages What's the relationship between LC_xyz and LANG? The official answer for programs using glibc is: "the library will test the environment variables LC_ALL, LC_CTYPE, and LANG in that order" But is glibc actually used on MacOS?? The Unicode FAQ says http://www.cl.cam.ac.uk/~mgk25/unicode.html "The LANG environment variable is used to set the default locale for all categories, but the LC_* variables can be used to override individual categories." So I don't understand the isolated recommendation of using LC_MESSAGES in this thread. My use-case is how to mimick a French, or Dutch, or Turkish, or any Asian MS-Windows environment, without switching my desktop to any of these (the "sandbox" idea again). LC_MESSAGES is not enough AFAIK. Ken Thomases writes: >I see no upside at all to changing LANG into an override where that's >not how it functions in any other context. I see no override involved here. On my Mac OSX 10.5.8 which is pretty much a base install, no LC_xyz is set. Therefore LANG does not override any LC_xyz setting. All I ask about LANG is that it overrides the desktop settings. If any LC_xyz were set, I expect them to take priority over LANG, like is documented and quoted above for glib and has been done for years in Linux. >Terminal (at least, recent versions) has a setting in its preferences >to set the locale environment variables in shells it creates. However, >it really only sets LANG according to the Region selected on the Formats >tab. It does not set individual LC_* variables. It completely ignores >the user's preferred language. I fail to see the problem. Only LANG is set, no LC_xyz therefore all UNIX apps launched within Terminal.app (or at least the glibc-based ones) should give a consistent answer, dictated by the LC_xyz/LANG defaulting rules. Should the next Apple update have Terminal.app set LC_xyz instead of LANG, I'd expect wine to obey them, because they take precedence over LANG. So actually, my wish is that Wine follows the LC_ALL/LC_xyz/LANG defaulting rules. Currently it does not. (I still need to check back on the Mac whether Wine follows LC_xyz). >(e.g. Japanese language, U.S. formats) Ken, is the use-case that you have in mind a Japanese user traveling to the U.S. (Jap. language, U.S. region/format)? Terminal.app sets LANG to US which you believe is wrong? My issue is not whether Terminal.app is broken or not. My issue is that if LANG is set, it should be obeyed, so the user gets consistent results (from a UNIX environment point of view). Regards, Jörg Höhle

4 5

Re: [PATCH 1/7] dsound: Implement DSPROPERTY_WaveDeviceMappingA on top of *W
by Alexandre Julliard Dec. 9, 2009

Dec. 9, 2009

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > + data.DataFlow = ppd->DataFlow; > + len = strlen(ppd->DeviceName)+1; > + data.DeviceName = HeapAlloc(GetProcessHeap(), 0, len); > + if (!data.DeviceName) > + return E_OUTOFMEMORY; > + MultiByteToWideChar(CP_ACP, 0, ppd->DeviceName, -1, data.DeviceName, len ); The W length handling is broken. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 1/2] dsound: Only initialize 1 guid for capture and renderer
by Alexandre Julliard Dec. 9, 2009

Dec. 9, 2009

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > @@ -355,8 +357,8 @@ HRESULT WINAPI DirectSoundEnumerateW( > if (devs > 0) { > if (GetDeviceID(&DSDEVID_DefaultPlayback, &guid) == DS_OK) { > static const WCHAR empty[] = { 0 }; > - for (wod = 0; wod < devs; ++wod) { > - if (IsEqualGUID( &guid, &DSOUND_renderer_guids[wod] ) ) { > + wod = guid.Data4[7]; > + if (wod < devs) { { Now that's an interesting indentation style... -- Alexandre Julliard julliard(a)winehq.org

2 1

Cruft left behind by tests
by Greg Geldorp Dec. 9, 2009

Dec. 9, 2009

Hi Dmitry, During WineConf we briefly discussed files/registry keys left behind by running winetest.exe on Windows machines. I promised to look at that and then promptly forgot about it. Anyway, this is the list of files that get left behind when running the tests on a WinXP machine: C:\CustomMsi (hidden directory, empty) %Local AppData%\DCBC2A71-70D8-4DAN-EHR8-E0D61DEA3FDF.ini (new file, not really a .ini file, contains binary data) %SystemRoot%\Debug\UserMode\userenv.log (updated) %SystemRoot%\inf\test.PNF (new) %SystemRoot%\Installer\3a964.msi (plus 4 other .msi files) %SystemSystem%\d3d8caps.dat (new) %SystemSystem%\d3d9caps.dat (new) %SystemSystem%\test.PNF (new) %SystemSystem%\CatRoot\{C689AABA-8E78-11D0-8C47-00C04FC295EE}\TimeStamp (plus 2 other GUID-named directories below CatRoot) IE Cookies and History files get updated, some files get added to the IE cache And the registry keys: HKCU\Software\Microsoft\ActiveMovie\devenum\{083863F1-70DE-11D0-BD40-00A0C911CE86}\{8DE0E022-0111-43BA-9227-175BA62326EC} HKCU\Software\Microsoft\ActiveMovie\devenum\{4EFE2452-168A-11D1-BC76-00C04FB9453B}\Default MidiOut Device HKCU\Software\Microsoft\ActiveMovie\devenum\{E0F158E1-CB04-11D0-BD4E-00A0C911CE86}\Default DirectSound Device HKCU\Software\Microsoft\Direct3D\MostRecentApplication HKCU\Software\Microsoft\DirectInput\MostRecentApplication HKCU\Software\Microsoft\Installer\Products\D37A124635D9F784DAFD3ACC0AC92055 HKCU\Software\Microsoft\Multimedia\msacm.imaadpcm HKCU\Software\Microsoft\Multimedia\msacm.msgsm610 HKCU\Software\Microsoft\Multimedia\ActiveMovie HKCU\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Cached HKCU\Software\Microsoft\Windows Script\Settings HKCU\Software\Wine HKCR\Applications\shell32_test.exe HKCR\CLSID\{178fc163-f585-4e24-9c13-4bb7faf80646} HKCR\Installer\Products\D37A124635D9F784DAFD3ACC0AC92055 HKCR\Interface\{8CC497C0-A1DF-11CE-8098-00AA0047BE5D} HKCR\Interface\{8CC497C1-A1DF-11CE-8098-00AA0047BE5D} HKCR\Interface\{8CC497C2-A1DF-11CE-8098-00AA0047BE5D} HKCR\Interface\{8CC497C3-A1DF-11CE-8098-00AA0047BE5D} HKCR\Interface\{8CC497C4-A1DF-11CE-8098-00AA0047BE5D} HKCR\Interface\{8CC497C5-A1DF-11CE-8098-00AA0047BE5D} HKCR\TestScript HKCR\TypeLib\{00020430-0000-0000-C000-000000000046}\1.0\FLAGS HKCR\TypeLib\{8CC497C9-A1DF-11CE-8098-00AA0047BE5D} HKCR\Wine.Test HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllIsMyFileType HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 1\CertDllOpenStoreProv HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 1\CertDllOpenStoreProv\DEFAULT HKLM\SOFTWARE\Microsoft\Direct3D\MostRecentApplication HKLM\SOFTWARE\Microsoft\DirectDraw\MostRecentApplication HKLM\SOFTWARE\Microsoft\DownloadManager HKLM\SOFTWARE\Microsoft\ESENT\Process\iphlpapi_test HKLM\SOFTWARE\Microsoft\RFC1156Agent HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Managed\S-1-5-21-606747145-1604221776-839522115-1003\Installer\Products\D37A124635D9F784DAFD3ACC0AC92055 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\803D6B87EA8012A4EAA3ED9844C59F21 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21-606747145-1604221776-839522115-1003\Products\C589F146D32331C48B665A7F3C562E47 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MCD HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ICM\RegisteredProfiles HKLM\SYSTEM\LastKnownGoodRecovery\LastGood HKLM\SYSTEM\CurrentControlSet\Control\Session Manager HKLM\SYSTEM\CurrentControlSet\Control\StillImage\Debug\wiadss.dll HKLM\SYSTEM\CurrentControlSet\Enum\USB\BOGUS HKLM\SYSTEM\CurrentControlSet\Services\BITS HKLM\SYSTEM\CurrentControlSet\Services\TestService HKU\.DEFAULT\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Ge.

2 2

Re: wineserver: Use existing file permissions as base for applying ACLs, change mapping logic
by Alexandre Julliard Dec. 9, 2009

Dec. 9, 2009

Paul Chitescu <paulc(a)voip.null.ro> writes: > Changelog: > wineserver: Use existing file permissions as base for applying ACLs, change > mapping logic. > > ACLs are applied over existing permissions. An ACCESS_ALLOWED_ACE by itself > will never reduce permissions. This doesn't make sense to me. A security descriptor with ACCESS_ALLOWED entries can still result in permissions being reduced. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shdocvw: Implement refresh in webbbrowser.c
by Jacek Caban Dec. 9, 2009

Dec. 9, 2009

Hi David, David Anderson wrote: > > Implements WebBrowser_Refresh in shdocvw/webbrowser.c . > > Now a VB app with a 'refresh' button works, refreshing a web page > displayed by gecko with the current web page (it used to crash the app > because refresh returned an E_NOTIMPL). > > Tested with linux winetest.exe.so on Ubuntu 9.10 > with ATI graphics card. No new fails (retests are not 100% stable, but > close to stable), I tested several times before and after the change. > Fails are like other linux-wine results shown on test.winehq.org. This is obviously not the right implementation. It's just a hack. Also we don't have any test for this function, so testing with existing tests doesn't make much sense. WebBrowser *This = WEBBROWSER_THIS(iface); - FIXME("(%p)\n", This); - return E_NOTIMPL; + BSTR url; + HRESULT res; + + TRACE("(%p)\n", This); + res = WebBrowser_get_LocationURL(iface, &url); You don't need this call, you can access WebBrowser object here. + if( res != S_OK) { + FIXME("(%p)-> ERROR calling WebBrowser_get_LocationURL\n", This); + return res; + } + TRACE("(%p)->(%s )\n", This, debugstr_w(url)); + return navigate_url(&This->doc_host, url, NULL,NULL,NULL,NULL); You leak url here. Thanks, Jacek

1 0

Re: ntdll/tests: Fix a memory leak.
by Paul Vriens Dec. 9, 2009

Dec. 9, 2009

On 12/08/2009 11:44 AM, Hans Leidekker wrote: > CloseHandle( dir ); > + pRtlFreeUnicodeString(&nameW ); This one makes the tests crash on 64bit Windows 7. Any idea why? The NtQueryDirectoryFile() just before that fails with ERROR_NO_MORE_ITEMS btw, but that's also true on my 32bit Win7 box. -- Cheers, Paul.

1 0

re: Wine performance improvement
by Dan Kegel Dec. 9, 2009

Dec. 9, 2009

Interesting! Clearly a long ways off from production-ready, but it's fun to see somebody trying this. A few notes: Please clean up the patch a bit to remove lines like this: +//FIXME("handle : %ld \n", handle); and extra files like dlls/ws2_32/tests/test.sh Please avoid hand-editing include/wine/server_protocol.h The start of the file even says: * This file is automatically generated; DO NO EDIT! * Edit server/protocol.def instead and re-run tools/make_requests Please switch to plain text for future posts. It's very hard to read in the archive; see http://www.winehq.org/pipermail/wine-devel/2009-December/080394.html Please identify the author(s) of the new code for copyright purposes, and ensure they agree to licensing their code under the LGPL (for Wine) and GPL (for Linux kernel). I'm sure other people will have more to say.

1 0

Wine performance improvement
by Eun-Ji, Lim Dec. 9, 2009

Dec. 9, 2009

1 0

Re: winhttp/tests: Fix test error when run as non-administrator
by Paul Vriens Dec. 8, 2009

Dec. 8, 2009

On 12/08/2009 12:58 AM, Juan Lang wrote: > - ok(ret, "WinHttpSetDefaultProxyConfiguration failed: %d\n", GetLastError()); > + ok(ret || GetLastError() == ERROR_ACCESS_DENIED, > + "WinHttpSetDefaultProxyConfiguration failed: %d\n", GetLastError()); > > - set_default_proxy_reg_value( saved_proxy_settings, len, type ); > + if (ret) > + set_default_proxy_reg_value( saved_proxy_settings, len, type ); > } Hi Juan, I'm not a big fan of this. In theory we can now mess up our implementation and return ERROR_ACCESS_DENIED without knowing that something is wrong as the tests will still succeed. I agree that ERROR_ACCESS_DENIED is a valid return value but I'd rather have some win_skip() or at least a skip() in there. win_skip() will work fine right now but as soon as we implement access rights to the registry (and multi-user) it should probably be a skip(). -- Cheers, Paul.

2 1

The XFORM matrix in PlgBlt is calculated incorrectly
by Alexander Almaleh Dec. 8, 2009

Dec. 8, 2009

2 1

Re: Wine sound discussion summary
by Stefan Dösinger Dec. 8, 2009

Dec. 8, 2009

> Though, how would MIDI be handled. I think that OpenAL doesn't handle MIDI... Good question. As far as I can see PulseAudio doesn't support MIDI either, but it is certainly available in Alsa, CoreAudio and on Windows Vista, even though its more tricky to activate HW midi on Vista. Emulating MIDI through a software synthesizer won't fly, as this will make it impossible to use hardware instruments. A related topic: How do Joysticks connected to the gameport work(which is the same hardware connector as MIDI). I think that a joystick already takes an entirely different path in the Linux kernel and it doesn't get anywhere near a sound system, so we don't have to bother about it. Is that correct?

7 18

Re: Author: Maarten Lankhorst <mlankhorst@patser.(none)>
by Stefan Dösinger Dec. 8, 2009

Dec. 8, 2009

> Author: Maarten Lankhorst <mlankhorst(a)patser.(none) Did you forget to configure your email address in git?

1 0

Re: shdocvw: Fix test for non-english IE MUI
by Jacek Caban Dec. 8, 2009

Dec. 8, 2009

Hi Alistair, Alistair Leslie-Hughes wrote: > Hi, > Either use this patch or patch "Added support for non-enligh IE MUI". > > Changelog: > shdocvw: Fix test for non-english IE MUI - ok(!strcmp_wa(sName, "Microsoft Web Browser Control"), "got '%s', expected 'Microsoft Web Browser Control'\n", wine_dbgstr_w(sName)); + ok(sName, "get_Name return a NULL string.'\n"); You don't need to delete the whole test. You can check for the system language and do the compare only if it's English. Jacek

3 2

Re: 1/2 wined3d: print warning/error to winediag [try2]
by Alexandre Julliard Dec. 8, 2009

Dec. 8, 2009

Roderick Colenbrander <thunderbird2k(a)gmail.com> writes: > { > - ERR("Direct3D%d is not available without opengl\n", dxVersion); > + ERR_(winediag)("Unable to initialize Direct3D%d due to lack of OpenGL support.\nMake sure OpenGL drivers are installed on your system and that Wine was compiled with OpenGL support.\n", dxVersion); I don't think you want that. One of the ideas behind winediag is that it should be machine-parsable, and adding new lines in the middle of traces will make that harder. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shdocvw: Added support for non-english IE MUI
by Paul Vriens Dec. 8, 2009

Dec. 8, 2009

On 12/08/2009 11:10 AM, Alistair Leslie-Hughes wrote: > Hi, > When IE has support to display non-english menus, its returns a > translated string for the control name (get_Name) for the language being > used. > > > Changelog: > shdocvw: Added support for non-english IE MUI > > Best Regards > Alistair Leslie-Hughes > Hi Alistair, Although I can agree on adding this language support to the implementation, I'm not sure we want this in the tests. Someone has to keep the translations up-to-date in the tests. Next to that the new tests assume that our translation is exactly the same as Windows, not sure if we even want that. -- Cheers, Paul.

2 1

winetest + pbuffer + nvidia 190.18 drivers = X crash
by Austin English Dec. 8, 2009

Dec. 8, 2009

Been happening for a few days...not sure what triggered it, but when coming back from work I see my login screen, which explains the lack of 64-bit tests/appinstall results. I don't know if any of the D3D guys could take a look, but I'd appreciate it... -- -Austin

2 4

Re: [PATCH] user32: Make DefWindowProc handle SHIFT+F10.
by Dmitry Timoshkov Dec. 8, 2009

Dec. 8, 2009

"Kusanagi Kouichi" <slash(a)ac.auone-net.jp> wrote: > According to MSDN[1], DefWindowProc generates the WM_CONTEXTMENU > message when SHIFT+F10 is typed. > > [1] http://msdn.microsoft.com/en-us/library/ms647592.aspx Usually MSDN statements/descriptions shouldn't be taken as an action guide, a test case is required to see what happens in reality. At least a quick test shows that if a menu is activated pressing Shift+F10 does nothing. dlls/user32/tests/msg.c already has some tests for VK_APPS and VK_F10 press/release, please add a new test there. -- Dmitry.

1 0

Very long printernames and test failures
by Paul Vriens Dec. 8, 2009

Dec. 8, 2009

Hi Detlef, Some test failures are shown on boxes with long printernames, for example: http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/vista_… http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/win7_1… And indeed if I create a local printer with a very long name the cutoff is one bigger than what the test is currently doing. The attached patch fixes that. I don't think this is enough though. Our implementation cuts of at '-1' from the looks of it. The best test would probably to add a printer in the tests and check for the size of the name in the strcut but I don't know how easy/intrusive that is. Any thoughts? -- Cheers, Paul.

2 3

Free VMware Workstation licenses for Wine developers
by Greg Geldorp Dec. 8, 2009

Dec. 8, 2009

I already announced this at WineConf, but for people who were not there: VMware wants to support the Wine project by providing free of charge Workstation 7 licenses to Wine developers. We're not going to be too picky about the definition of "Wine developer". If you have been able to get a patch past Alexandre you've shown enough dedication to qualify ;-). There are a few restrictions on these licenses: - Not for resale - Not upgradable - No support entitlement If you want a license, just send me an email (off-list). Ge.

1 0

How does --with-wine64 work?
by Austin English Dec. 8, 2009

Dec. 8, 2009

Vincent asked me to get add a --with-wine64 option to my build script. I was testing around, and can't seem to get it to work: $ mkdir - p $HOME/wine{32,64} $ cd $HOME/wine64 $ ~/wine-git/configure --enable-win64 $ make -j4 $ cd $HOME/wine32 $ ~/wine-git/configure --with-wine64=~/wine64 ... > checking for the directory containing the Wine tools... configure: error: could not find Wine tools in ~/wine64/ ~/wine-git/configure --with-wine64=~/wine64/tools/ ... checking for the directory containing the Wine tools... configure: error: could not find Wine tools in ~/wine64/tools/ What am I missing? Perhaps it needs to be installed somewhere first? -- -Austin

3 4

wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)
by Peter Kovacs Dec. 8, 2009

Dec. 8, 2009

Hi there, I want to bring this Issue up in Development Mailinglist. This proplem is about a bug that cant be fixed within wine, and The Bugtracker doesnt help it. I think this Bug is at the moment an Epic Fail of Open Source Development. (And needs to be solved so we get a accepted Fix somewhere someday) The Bug is Deadlocked. The Problem is in this Bug roughly spoken that in some games the Mouse movement is captured and not the real position. Now X only returns the real position. This Bug is a dependance of X (If I got it right). Since this Bug appeared people worked around this Bug by improving dirty hacks (by calculating mouse movement using weird? code), and maintaining them. And when Possible to make them switchable. Now Vitaliy Margolen actively stopped the maintenance of this workarounds (in the bug called dirty hacks.), by marking the patches obsolete and changing title. The Bug exist since 2009 - 12 - 06. And has a long thread. I understand the move of Margolen here. For that you need to look at the Bug history (clicky: http://bugs.winehq.org/show_bug.cgi?id=6971) And I dont put blame on his move. But for this Bug wine needs another political solution. Just stopping people to write hacks, dirty or not will stop people reaching in more and more patches. This sole incident wont have an effect on hole development but most bugs I followed started with a dirty hack. And this is definitely giving the wrong impression on wine. What I want to say, Margolens move might be technical right, but is political pretty lame. Atm I don't see any ability that the bug will be proper fixed. 1) I Xorg may implement the Problem or may not. Maybe they are even not aware(? - Haven't took a look) The Bug-tracking in wine does not contain a Link to the Bug-tracking in Xorg. 2) I am betting wine - Dev has no one working on the Bug actively. So how can we get a proper Fix or point people towards proper fixes? Is it right to have no Dirty Hack solution which just works? Do you think by stopping Hacks you will encourage development in what (you) think is the right solution? Where is the Xorg Link for this Problem since it is a problem interesting wine but maybe not Xorg? Before anyone asks, I don't have the Time to solve this Bug. Nor I do believe does any one of the "dirty" hackers. Or they had done it Proper by now. Thanks Listening, hope you got the Problem I want to address. I am not on the list since I develop nothing for wine. I would it appreciate it a lot, if I could stay with the discussion by keeping my email address in CC Regards Peter

5 6

Wine sound discussion summary
by Stefan Dösinger Dec. 7, 2009

Dec. 7, 2009

Hi, For those who didn't follow the big dsound argument thread, here is a quick summary of the main points. I originally inteded this as a summary mail, but while collecting the arguments I have instead taken the discussion off-list accidentally. But here's the current state: Pretty much everyone agrees that the current sound infrastructure is broken. In terms of how to fix it, there are 3 points to be worked out. 1) Use OpenAL or a more sophisticated driver infrastructure 2) If no OpenAL, what do we use 3) How do we get there. I'll mostly focus on (1) here, as the others depend on the decision of (1). On Wineconf we decided to give killing our entire sound infrastructure a try and replace it with a winmm and dsound based on OpenAL. That wasn't a promise by Alexandre to commit it, more an investigative study. The advantages of that would be: * A compact Wine sound system, we don't have many different sound drivers. OpenAL is available on all operating systems * We can let Linux(dmix, pulseaudio) do some or all of the mixing(with openal.so improvements) * Outsource workarounds for Alsa/PulseAudio/Coreaudio bugs to openal * Supporting DirectSound 3D is easy - openal just has it available. No need to reinvent the wheel. There are still a lot of dsound 3d games from WinXP and earlier. * Hardware accelerated 3D sound is possible. Currently there are no Linux drivers for that though. * Winmm, dsound and Windows openal.dll interaction still works fine as long as all libs interact with openal in the same way Disadvantages: * We have less control over our sound infrastructure and might get into troubles if some apps depend on the underlying driver system * We depend on the system openal. Linux distros have to keep their 32 bit openal updated. Getting bugfixes shipped to users might take years. MacOS OpenAL seems pretty broken. * Outsourcing bug workarounds is a slippery slope. It will be hard or impossible to work around problems without openal and distro help(and we need help again to get them fixed properly). * OpenAL is essentially just an abstraction layer not any system's native way to do sound. * Dsound 3D is dead in Win7, maybe we shouldn't focus our design decision on it 2) If no OpenAL, what do we use The consensus is mostly that if we don't use OpenAL for abstraction then we would aim for the Windows 7 sound driver API, or something very close to it. The goodies include a) Its the way Windows does it. b) If Win7 has user space audio driver support we might be able to use those drivers c) Technically native dsound and winmm might work, which can be helpful for debugging d) No bad surprises when apps start screwing around with the internals(e.g. load an DRM decryption APO into the sound processing chain). Problems of this sound infrastructure include: * It is very complex and maybe a lot more than we need. * The Windows 7 sound model mandates software mixing. We'd have a audiodg.exe process running that mixes all streams from all processes. Add in pulseaudio or dmix, and maybe dsound has to do its own mixing and you have 3 software mixers in a chain. But maybe that's a place where we can deviate from the MS design, or use mixing plugins provided by our drivers. * It rules out hardware accelerated dsound3d. Although a user might install Creative's openal wrapper or similar software to get back HW dsound 3D in the windows 7 way, with all its pros and cons. Most new 3D sound games use openal natively. * For full compatibility to drivers and native libs we'd need the DDK, and nobody checked the license terms so far. 3) How do we get there. This obviously depends on what we do, and we probably won't do much before the 1.2 release. For the OpenAL way, we could just throw in the code Maarten wrote so far, or Chris' Dsound->OpenAL wrapper. For Win7, one idea was to implement one more Win 3.1 sound driver in Wine that is based on the Win7 infrastructure, then implement that infrastructure and move winmm and dsound over. Once this is done, throw out the old Win 3.1 stuff. Or implement the Win7 infrastructure and maintain a separate dsound and winmm off-tree(developed on Windows), and put them in place once the Win7 driver infrastructure in Wine is solid enough.

7 15

Re: 2/2 WGL: move some traces to winediag
by Henri Verbeet Dec. 7, 2009

Dec. 7, 2009

2009/12/7 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > Use this version instead. The last version contained some updates to > the wined3d winediag patch. > Sending this to winediag does mean it won't show up in +wgl traces anymore. Do we want that?

2 1

Please Review - Revised OS X Application Bundle patch
by Joerg-Cyril.Hoehle＠t-systems.com Dec. 7, 2009

Dec. 7, 2009

Hi, + * NOTES: An Application Bundle generally has the following layout + * + * foo.app/Contents + * foo.app/Contents/Info.plist + * foo.app/Contents/MacOS/foo (can be script or real binary) + * foo.app/Contents/Resources/appIcon.icns (Apple Icon format) + * foo.app/Contents/Resources/English.lproj/infoPlist.strings + * foo.app/Contents/Resources/English.lproj/MainMenu.nib (Menu Layout) Could you please comment on why you think that using a .app is the right approach? (please explain the goal: provide desktop icons?) What do you plan to put into that bundle? What would the menu be? (Is there one at all?) As an alternative, I've been creating .command files, as explained in the FAQ http://wiki.winehq.org/MacOSX/FAQs They seem conceptually simpler yet provide what you'll find in the xyz.desktop file that Wine produces on Linux: - Icon - Terminal window that shows Wine's log and I/O from application. Where does such output go in the .app case? - file name - Change Directory to app's directory (or any other) It does not depend on wine start /unix Isn't that missing from your patch: + fprintf(file, "#!/bin/sh\n"); + fprintf(file, "WINEPREFIX=\"%s\" wine \"%s\" %s\n\n", + wine_get_config_dir(), path, args); This information is present in the .desktop files - Move the icon anywhere you like and click to start it. There's no dependency on Applications/ or any other setting. - Easily modified by the user to change WINEPREFIX, add WINEDEBUG or whatever -- if needed at all. You'll remember that I presented my approach on 2009-09-14 in this list. I was wondering whether Wine should create such xyz.command files on MacOS instead of the xyz.desktop ones. They are so close to each other. Perhaps it is precisely that additional Terminal.app window that you or other Mac users might dislike? (I've not investigated whether there are "hide" or "auto-close on exit" properties that could be set.) Regards, Jörg Höhle

3 9