August 2005 - Wine-Devel - list.winehq.org

Re: Throwing in an idea (probably it was discussed before though)

by John Smith

>This will just allow developers to hide bugs in wine and slow development >even further, I thing it's a bad idea. Ahem. To say it politely - I didn't get an impression that WINE developers are desperately looking for unknown bugs to fix. Situation is pretty simple. We have an application, which works Ok under WINE, provided that Managed=N specified (with CrossOver it works Ok out-of-the-box). We won't change our code to go around WINE shortcomings (we checked relevant portions of our code though for potential bugs and found nothing), but we would add some kind of hint to make life of our customers a little bit easier. On the other hand, if WINE team doesn't care about current WINE end-users (and there are lots of them, despite the fact that WINE is still Alpha; they just download binary RPM provided and expect their favorite applications to work out-of-the-box) and thinks that they should wait until bug-free WINE released - we don't care much either. >From: Ivan Leo Puoti <ivanleo(a)gmail.com> >Reply-To: ivanleo(a)gmail.com >To: wine-devel(a)winehq.com >Subject: Re: Throwing in an idea (probably it was discussed before though) >Date: Mon, 22 Aug 2005 00:31:07 +0100 > >John Smith wrote: >>As a Win developer, I want to make a suggestion (sorry if it was already >>discussed - or if similar mechanism already exists): >>What if some simple way will be provided for Win developers to say which >>options they prefer for WINE to use for their application? While it may >>seem to somewhat contradict to the 'big bright future' of the WINE (with >>all the apps running flawlessly under WINE), it would hopefully allow for >>immediate increase of out-of-the-box supported applications. >> >>For example, it could be a resource string of special format (for example, >>"__WINE_CONFIG_HINT: "Managed" = "N""), and multiple hints should be >>allowed. This hint should override system-wide settings but in turn should >>be overridden by per-app settings in wine config file/registry. > >This will just allow developers to hide bugs in wine and slow development >even further, I thing it's a bad idea. > >Ivan. > > _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Aug. 22, 2005

Re: Throwing in an idea (probably it was discussed before though)

by Ivan Leo Puoti

John Smith wrote: > As a Win developer, I want to make a suggestion (sorry if it was already > discussed - or if similar mechanism already exists): > What if some simple way will be provided for Win developers to say which > options they prefer for WINE to use for their application? While it may > seem to somewhat contradict to the 'big bright future' of the WINE (with > all the apps running flawlessly under WINE), it would hopefully allow > for immediate increase of out-of-the-box supported applications. > > For example, it could be a resource string of special format (for > example, "__WINE_CONFIG_HINT: "Managed" = "N""), and multiple hints > should be allowed. This hint should override system-wide settings but in > turn should be overridden by per-app settings in wine config file/registry. This will just allow developers to hide bugs in wine and slow development even further, I thing it's a bad idea. Ivan.

Aug. 21, 2005

Throwing in an idea (probably it was discussed before though)

by John Smith

As a Win developer, I want to make a suggestion (sorry if it was already discussed - or if similar mechanism already exists): What if some simple way will be provided for Win developers to say which options they prefer for WINE to use for their application? While it may seem to somewhat contradict to the 'big bright future' of the WINE (with all the apps running flawlessly under WINE), it would hopefully allow for immediate increase of out-of-the-box supported applications. For example, it could be a resource string of special format (for example, "__WINE_CONFIG_HINT: "Managed" = "N""), and multiple hints should be allowed. This hint should override system-wide settings but in turn should be overridden by per-app settings in wine config file/registry. _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Aug. 21, 2005

Re: DDRAW: don't leak visuals

by Saulius Krasuckas

* On Sun, 21 Aug 2005, Saulius Krasuckas wrote: > > This is my first X-perience. Does this look OK, folks? Proabably I should post a diff with a larger context to get an answer. Sorry. Index: dlls/ddraw/device_opengl.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/device_opengl.c,v retrieving revision 1.7 diff -p -u -1 -0 -r1.7 device_opengl.c --- dlls/ddraw/device_opengl.c 11 Aug 2005 10:57:47 -0000 1.7 +++ dlls/ddraw/device_opengl.c 21 Aug 2005 20:34:03 -0000 @@ -4337,26 +4337,28 @@ d3ddevice_init_at_startup(void *gl_handl template.visualid = XVisualIDFromVisual(visual); vis = XGetVisualInfo(display, VisualIDMask, &template, &num); if (vis == NULL) { LEAVE_GL(); WARN("Error creating visual info for capabilities initialization - D3D support disabled !\n"); return FALSE; } gl_context = glXCreateContext(display, vis, NULL, GL_TRUE); if (gl_context == NULL) { + XFree(vis); LEAVE_GL(); WARN("Error creating default context for capabilities initialization - D3D support disabled !\n"); return FALSE; } if (glXMakeCurrent(display, drawable, gl_context) == False) { glXDestroyContext(display, gl_context); + XFree(vis); LEAVE_GL(); WARN("Error setting default context as current for capabilities initialization - D3D support disabled !\n"); return FALSE; } /* Then, query all extensions */ glXExtensions = glXQueryExtensionsString(display, DefaultScreen(display)); /* Note: not used right now but will for PBuffers */ glExtensions = (const char *) glGetString(GL_EXTENSIONS); glVersion = (const char *) glGetString(GL_VERSION); if (gl_handle != NULL) { @@ -4428,14 +4430,15 @@ d3ddevice_init_at_startup(void *gl_handl GL_extensions.glCompressedTexSubImage2D = pglXGetProcAddressARB( (const GLubyte *) "glCompressedTexSubImage2DARB"); } } /* Fill the D3D capabilities according to what GL tells us... */ fill_caps(); /* And frees this now-useless context */ glXMakeCurrent(display, None, NULL); glXDestroyContext(display, gl_context); + XFree(vis); LEAVE_GL(); return TRUE; }

Aug. 21, 2005

DDRAW: don't leak visuals

by Saulius Krasuckas

I was walking through a Lionel code (written in 2003) and stumbled at the call to XGetVisualInfo(). The list of visuals it returns is never released. Hence, three lines were added. This is my first X-perience. Does this look OK, folks? Index: dlls/ddraw/device_opengl.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/device_opengl.c,v retrieving revision 1.7 diff -p -u -r1.7 device_opengl.c --- dlls/ddraw/device_opengl.c 11 Aug 2005 10:57:47 -0000 1.7 +++ dlls/ddraw/device_opengl.c 21 Aug 2005 19:58:09 -0000 @@ -4344,12 +4344,14 @@ d3ddevice_init_at_startup(void *gl_handl gl_context = glXCreateContext(display, vis, NULL, GL_TRUE); if (gl_context == NULL) { + XFree(vis); LEAVE_GL(); WARN("Error creating default context for capabilities initialization - D3D support disabled !\n"); return FALSE; } if (glXMakeCurrent(display, drawable, gl_context) == False) { glXDestroyContext(display, gl_context); + XFree(vis); LEAVE_GL(); WARN("Error setting default context as current for capabilities initialization - D3D support disabled !\n"); return FALSE; @@ -4435,6 +4437,7 @@ d3ddevice_init_at_startup(void *gl_handl /* And frees this now-useless context */ glXMakeCurrent(display, None, NULL); glXDestroyContext(display, gl_context); + XFree(vis); LEAVE_GL(); return TRUE;

Aug. 21, 2005

Re: secur32: Fix wrapper.c to honour functions that are run twice.

by Kai Blin

* Kai Blin <blin(a)gmx.net> [21/08/05, 20:15:55]: > - ret = SECUR32_makeSecHandle(phContext, package, &myCtxt); > + ret = SECUR32_makeSecHandle(phNewContext, package, &myCtxt); > if (ret != SEC_E_OK) > package->provider->fnTableW.DeleteSecurityContext( > &myCtxt); Of course this needs to be changed, or SECUR32_makeSecHandle will overwrite the return value of InitializeSecurityContext resp. AcceptSecurityContext. Fixed in my new patch. Sorry, Kai -- Kai Blin, (blin at gmx dot net) How sharper than a hound's tooth it is to have a thankless serpent.

Aug. 21, 2005

Re: Automatic ANSI<>Unicode message translation

by Phil Krylov

On Tue, 26 Jul 2005 21:26:29 +0900 "Dmitry Timoshkov" <dmitry(a)baikal.ru> wrote: > "Phil Krylov" <phil(a)newstar.rinet.ru> wrote: > > > Oh sorry. For some reason I thought that HIWORD(wParam) is used for some > > other data. Here is a new patch, is it ok? > > Looks good to me, let's see if Alexandre likes it as well. Still it is not the best. Now, WM_CHARs posted by PostMessageA and dispatched using GetMessageA work well (are converted back and forth). But when the message loop uses GetMessageW, these WM_CHARs come to the window procedure as 4-byte "garbage" (WCHAR which is converted from CP_ACP to 2 WCHARs). In Windows, the window procedure receives unchanged code... (See attached test). -- Ph.

Aug. 21, 2005

Re: atl: fix warnings in 64bit

by Jacek Caban

Hello. Kevin Koltzau wrote: >Changelog > Remove 'cast to pointer from integer of different size' warnings in 64bit > > >------------------------------------------------------------------------ > >Index: dlls/atl/registrar.c >=================================================================== >RCS file: /home/wine/wine/dlls/atl/registrar.c,v >retrieving revision 1.11 >diff -u -d -r1.11 registrar.c >--- dlls/atl/registrar.c 10 Aug 2005 09:53:47 -0000 1.11 >+++ dlls/atl/registrar.c 21 Aug 2005 02:42:53 -0000 >@@ -634,7 +634,7 @@ > { > Registrar *This = (Registrar*)iface; > TRACE("(%p)->(%s %d %s)\n", iface, debugstr_w(resFileName), nID, debugstr_w(szType)); >- return resource_register(This, resFileName, (LPOLESTR)nID, szType, TRUE); >+ return resource_register(This, resFileName, (LPOLESTR)(UINT_PTR)nID, szType, TRUE); > } > > static HRESULT WINAPI Registrar_ResourceUnregister(IRegistrar* iface, LPCOLESTR resFileName, >@@ -642,7 +642,7 @@ > { > Registrar *This = (Registrar*)iface; > TRACE("(%p)->(%s %d %s)\n", This, debugstr_w(resFileName), nID, debugstr_w(szType)); >- return resource_register(This, resFileName, (LPOLESTR)nID, szType, FALSE); >+ return resource_register(This, resFileName, (LPOLESTR)(UINT_PTR)nID, szType, FALSE); > } > > static const IRegistrarVtbl RegistrarVtbl = { > > It doesn't make a big difference, but it would be better to use MAKEINTRESOURCEW macro here. Jacek

Aug. 21, 2005

Re: [WINEOSS] multiple sound card mixer patch

by Robert Reif

Robert Reif wrote: > Fix mixer detection for multiple sound cards. > > > This fixes a bug with the previous patch and adds some more debugging info. Index: dlls/winmm/wineoss/mixer.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/wineoss/mixer.c,v retrieving revision 1.35 diff -p -u -r1.35 mixer.c --- dlls/winmm/wineoss/mixer.c 3 Aug 2005 21:25:10 -0000 1.35 +++ dlls/winmm/wineoss/mixer.c 21 Aug 2005 11:29:12 -0000 @@ -366,8 +366,8 @@ static DWORD MIX_Open(WORD wDevID, LPMIX * the equivalent of mixer identification * (with a reference to a wave, midi.. handle */ - if (!(mix = MIX_Get(wDevID))) { - WARN("bad device ID\n"); + if ((mix = MIX_Get(wDevID)) == NULL) { + WARN("bad device ID: %04X\n", wDevID); return MMSYSERR_BADDEVICEID; } @@ -610,8 +610,8 @@ static DWORD MIX_GetDevCaps(WORD wDevID, return MMSYSERR_INVALPARAM; } - if (!(mix = MIX_Get(wDevID))) { - WARN("bad device ID\n"); + if ((mix = MIX_Get(wDevID)) == NULL) { + WARN("bad device ID: %04X\n", wDevID); return MMSYSERR_BADDEVICEID; } @@ -787,7 +787,7 @@ static DWORD MIX_GetLineInfo(WORD wDevID } if ((mix = MIX_Get(wDevID)) == NULL) { - WARN("bad device ID\n"); + WARN("bad device ID: %04X\n", wDevID); return MMSYSERR_BADDEVICEID; } @@ -969,7 +969,7 @@ static DWORD MIX_GetLineControls(WORD wD } if ((mix = MIX_Get(wDevID)) == NULL) { - WARN("bad device id\n"); + WARN("bad device ID: %04X\n", wDevID); return MMSYSERR_BADDEVICEID; } @@ -1068,7 +1068,7 @@ static DWORD MIX_GetControlDetails(WORD } if ((mix = MIX_Get(wDevID)) == NULL) { - WARN("bad device ID\n"); + WARN("bad device ID: %04X\n", wDevID); return MMSYSERR_BADDEVICEID; } @@ -1266,7 +1266,7 @@ static DWORD MIX_SetControlDetails(WORD } if ((mix = MIX_Get(wDevID)) == NULL) { - WARN("bad device ID\n"); + WARN("bad device ID: %04X\n", wDevID); return MMSYSERR_BADDEVICEID; } @@ -1457,8 +1457,8 @@ static DWORD MIX_Init(void) #ifdef SOUND_MIXER_INFO mixer_info info; if (ioctl(mixer, SOUND_MIXER_INFO, &info) >= 0) { - MIX_Mixers[i].name = HeapAlloc(GetProcessHeap(),0,strlen(info.name) + 1); - strcpy(MIX_Mixers[i].name, info.name); + MIX_Mixers[MIX_NumMixers].name = HeapAlloc(GetProcessHeap(),0,strlen(info.name) + 1); + strcpy(MIX_Mixers[MIX_NumMixers].name, info.name); } else { /* FreeBSD up to at least 5.2 provides this ioctl, but does not * implement it properly, and there are probably similar issues @@ -1469,10 +1469,10 @@ static DWORD MIX_Init(void) #endif close(mixer); + MIX_Mixers[MIX_NumMixers].dev_name = HeapAlloc(GetProcessHeap(),0,strlen(name) + 1); + strcpy(MIX_Mixers[MIX_NumMixers].dev_name, name); MIX_NumMixers++; - MIX_Mixers[i].dev_name = HeapAlloc(GetProcessHeap(),0,strlen(name) + 1); - strcpy(MIX_Mixers[i].dev_name, name); - MIX_Open(i, NULL, 0); /* FIXME */ + MIX_Open(MIX_NumMixers - 1, NULL, 0); /* FIXME */ } else { WARN("couldn't open %s\n", name); }

Aug. 21, 2005

Re: Should all builtin DLLs have version information?

by Paul Vriens

On Thu, 2005-08-18 at 19:22, Detlef Riekenberg wrote: > Paul Vriens wrote: > > > the subject says it all. If yes, I will start adding some for the ones > > IMHO that's a good idea. I have added this one as a TODO on my list. What version-number should we give our DLLs. Some of them have already version 10.xxx, probably to get rid of any problem in the nearby future, for programs that check the version. Should we give our DLLs the highest version currently available on all of the windows-versions (95 .... W2K3)? This will mean that someone (me ?) has to go over them from time to time to check whether this has changed. I do think (apart from the extra work) that it look better than 10.xxx. Maybe we should add some comments in the version resource files like: /* Windows-version Date Checked Version * * 95 * 98 * WinXP 08/21/05 5.1.2600.2180 * Win2K * Win2K3 /* Any ideas, suggestions ? Paul.

Aug. 21, 2005