wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

wglMakeCurrent doesn't pick up HDC region
by Russ 24 Aug '05

24 Aug '05

Trying to get my commercial 3-D app to run under WINE using the same binary with the odd workaround or two. It uses OpenGL in various subwindows of the main window as needed. Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window. In Win32, when you call wglMakeCurrent, the opengl context is configured to match the size/position of the HWND for the HDC, so drawing openGL goes just into the desired subwindow. However, the WINE implementation of wglMakeCurrent just calls glXMakeCurrent (and glXCreateContext), which produces the entire size of the X11 window, resulting in the incorrect behavior observed. In my Mac OS X port, I have a similar issue, resolved by calling aglSetInteger(glContext, AGL_BUFFER_RECT,... I'm not sure what a glX equivalent would be to try, I don't see one offhand. As is, emulating the wglMakeCurrent accurately appears impossible, such that apps that use this Windows behavior can not be run. Suggestions welcome. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

x11drv: use of uninitialized rect
by James Hawkins 24 Aug '05

24 Aug '05

Hey, While compiling x11drv, gcc gives the following error: gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o text.o text.c text.c: In function 'X11DRV_ExtTextOut': text.c:85: warning: 'rect.bottom' is used uninitialized in this function text.c:85: warning: 'rect.top' is used uninitialized in this function text.c:85: warning: 'rect.right' is used uninitialized in this function text.c:85: warning: 'rect.left' is used uninitialized in this function Looking through the CVS log for text.c, I saw that before the latest patch, rect would be initialized if lprect == NULL; otherwise, rect = *lprect. My guess is that we want to use lprect instead of rect, but I'm not familiar enough with that code to make the change. Can you take a look at this Huw? Thanks, James Hawkins

1 0

WineHQ will be offline tomorrow
by Jeremy Newman 23 Aug '05

23 Aug '05

I will be taking the website offline tomorrow starting at 09:00 CDT (04:00 GMT). I will be moving it to a new ISP. Expect downtime to last for up to 8 hours as I will also be doing a complete reinstall of the OS. This will also affect the mailing lists and the CVS. -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

3 6

Re: winecfg: theming
by Kevin Koltzau 23 Aug '05

23 Aug '05

On Tuesday 23 August 2005 2:39 pm, Frank Richter wrote: > + static const WCHAR themesSubdir[] = > + { > '\\','R','e','s','o','u','r','c','e','s','\\','T','h','e','m','e','s',0 }; > + WCHAR themesPath[MAX_PATH]; > + > + free_theme_files(); > + themeFiles = DSA_Create (sizeof (ThemeFile), 1); > + > + GetWindowsDirectoryW (themesPath, MAX_PATH); This should be based on SHGetFolderPath(CSIDL_RESOURCES)

1 0

Re: shell32: Some tests for FolderShortcut class (3rd try)
by Michael Jung 23 Aug '05

23 Aug '05

Hi Alexandre, On Monday 22 August 2005 17:04, Michael Jung wrote: > Changelog: > Added some tests for CLSID_FolderShortcut objects Are there any further problems with this patch? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Automatic ANSI<>Unicode message translation
by Phil Krylov 23 Aug '05

23 Aug '05

Hi, I am having a problem with an app of mine. It posts WM_CHAR messages to a ANSI window with Unicode value in LOWORD(wParam). Wine automatically translates the character code to ANSI (producing a "?" when there is no such code in CP_ACP). Windows does not do it (contrary to documentation). Here is attached (source and binary) a quick and dirty sample application which shows the problem. I could remove map_wparam_AtoW() and map_wparam_WtoA() from dlls/user/message.c, but probably somebody needs that translation. Does anybody have an idea of a better fix for that bug? -- Ph.

5 29

Re: Remove unnecessary #pragma code_page(xxxx) statements from winefile .rc files
by Martin Fuchs 23 Aug '05

23 Aug '05

> This is because 'LANGUAGE LANG_xxxx' statements don't actually change > code page specified by a previous '#pragma code_page(xxxx)', therefore > russian resources get translated to unicode using wrong code page. > I don't know whether it's an rc bug or a feature. We either need > to remove '#pragma code_page' statements altogether, or add them > to all included .rc files. I took the 1st approach. > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Remove unnecessary #pragma code_page(xxxx) statements from > winefile .rc files, they confuse the resource compiler. Please be carefull to remove the code page pragmas. IMHO this is not the correct way. When there is no other code page given, the resource compiler uses the current code page of the operating system. And I don't think, all of those language specific resource scripts will compile correct on all possible OS code pages. The reliable way would be to include the correct code page at the begin of all resource scripts. Please take in mind: Wine is compiled on many different environments: LANG_C, de_DE.ISO-8859-1, en_EN.UTF-8, swedish, or whatever... Removing the code page pragmas would require to test the correctness of the compilation results of all different languages on all possible platforms. Regards, Martin

2 1

Safedisc1 CD checks work, it tries to start the game but fails to do so
by Ivan Leo Puoti 23 Aug '05

23 Aug '05

Hello list, here's a little update Safedisc1 now successfully passes all anti debugger check, and recognises the CD correctly. It then attempts to start the game, but this doesn't work yet because of the nested exception on signal stack bug. Hopefully we aren't too far from getting it to run. Ivan.

4 3

Re: [winedbg] Don't ever pass a NONCONTINUABLE exception
by Alexandre Julliard 22 Aug '05

22 Aug '05

Glenn Wurster <gwurster(a)scs.carleton.ca> writes: > Changelog: > Don't pass on non-continuable exceptions. Why do you want to do that? -- Alexandre Julliard julliard(a)winehq.org

3 6

Re: Throwing in an idea (probably it was discussed before though)
by Jacek Caban 22 Aug '05

22 Aug '05

John Smith wrote: >> You can also set it yourselves in in your app. As configuration >> is in registry, every app can modify it. > > > I like this idea, thanks. There are still 2 issues with such a soultion: > a) most likely, it won't work until 2nd start of the application (we > will modify it on the first run, and it most likely won't be applied > until the second run); If you have an installer, you may configure Wine during installation. If not - just detect Wine at the beginning of the app and, if you have to configure Wine, do so and restart the app. It's a bit (very) hackish but it should work and it's not visible for user. > b) current WINE guides are discouraging us from detecting WINE - and > messing up with Windows Registry, especially HKEY_LOCAL_MACHINE, on > all the millions of non-WINE machines is not a thing I would really > like to do (the last thing we want is to be caught by some antivirus, > which monitors activity it considers suspicious and changing > HKEY_LOCAL_MACHINE can easily qualify). > You don't have to touch HKEY_LOCAL_MACHINE, Wine's configuration is in HKEY_CURRENT_USER. And you may use modified WGA (and millions of other) way to detect Wine:-) Note: I still think fixing Wine is better way to go. Jacek

1 0

UpdateWindow doesn't call XFlush
by Michael Kaufmann 22 Aug '05

22 Aug '05

Hi all, I've noticed that after an application calls UpdateWindow, the window contents doesn't get updated until the application requests the next event (GetMessage/PeekMessage). That's because UpdateWindow doesn't flush the X output queue (XFlush). I think the best approach would be that UpdateWindow calls GdiFlush, but this function is currently not implemented. The problem is that GdiFlush doesn't get a DC handle, it must figure out itself which DCs it has to flush. Can anyone implement GdiFlush or propose another mechanism on how to call XFlush in UpdateWindow? Regards Michael

1 0

X11: Problems with ConfigureNotify events that are received/processed too late
by Michael Kaufmann 22 Aug '05

22 Aug '05

Hi all, I'm trying to get the dialog boxes of Word 95 working. They often appear with the minimal window size (about 70x50 pixels), so they're unusable. With KDE's window manager (KWin) this happens very often. With Enlightenment and GNOME's window manager (Metacity), it only happens from time to time. I've looked for the reason, and I think it's very closely related to WINE bug 1265 which Duane Clark has tried to fix here: http://www.winehq.com/hypermail/wine-patches/2003/02/0095.html That's what's going on (CVS version of WINE, managed window mode): 1. Word creates a dialog with an initial position of (0,0) and size 0x0 (using CreateWindowEx) 2. Word calls SetWindowPos to set the correct dialog position and size 3. Word calls SetWindowPos to show the dialog (SWP_SHOWWINDOW) 4. The dialog gets the focus, the main window is being deactivated 5. In the WM_NCACTIVATE procedure of the main window, Word calls GetQueueStatus. WINE will process X events. 6. WINE receives a ConfigureEvent for the initial dialog position and size (0x0) and saves this to data->whole_rect in X11DRV_sync_window_position (7. If you're lucky, WINE also receives a ConfigureEvent for the correct dialog position) 8. Wine shows the dialog and maps it. It calls X11DRV_set_wm_hints, which calls set_size_hints. This procedure uses data->whole_rect as the dialog's rectangle. But this stored rectangle is completely wrong because WINE has not yet received all ConfigureEvents. 9. The window manager has to resize the dialog to the wrong size. The best solution would be to process all X events before setting the window position in SetWindowPos, but I don't know if that's possible. I've tried another approach: WINE should not set the window size hints when mapping a window (step 8.). I've attached a patch, but it's not 100% correct, because the style of a window (e.g. the WS_THICKFRAME style) may be changed by an application using SetWindowLong and SetWindowPos (with the SWP_FRAMECHANGED flag). WINE doesn't look for the SWP_FRAMECHANGED flag and updates the X11 window every time if it's visible or gets visible. So if an application calls SetWindowPos with the SWP_SHOWWINDOW flag, WINE needs to set the size hints because the window has been hidden and its style may have been changed. What would be the correct fix for this problem? Any ideas? Thanks, Michael Index: window.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/window.c,v retrieving revision 1.115 diff -u -r1.115 window.c --- window.c 27 Jul 2005 15:22:58 -0000 1.115 +++ window.c 15 Aug 2005 21:32:54 -0000 @@ -353,9 +353,9 @@ /*********************************************************************** * X11DRV_set_wm_hints * - * Set the window manager hints for a newly-created window + * Set the window manager hints for a window */ -void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data ) +void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data, BOOL update_size_hints ) { Window group_leader; XClassHint *class_hints; @@ -400,7 +400,7 @@ } /* size hints */ - set_size_hints( display, data, style ); + if (update_size_hints) set_size_hints( display, data, style ); /* systray properties (KDE only for now) */ if (ex_style & WS_EX_TRAYWINDOW) @@ -692,7 +692,7 @@ xim = x11drv_thread_data()->xim; if (xim) data->xic = X11DRV_CreateIC( xim, display, data->whole_window ); - X11DRV_set_wm_hints( display, data ); + X11DRV_set_wm_hints( display, data, TRUE ); SetPropA( data->hwnd, whole_window_prop, (HANDLE)data->whole_window ); return data->whole_window; Index: winpos.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/winpos.c,v retrieving revision 1.136 diff -u -r1.136 winpos.c --- winpos.c 15 Aug 2005 09:33:39 -0000 1.136 +++ winpos.c 15 Aug 2005 21:32:56 -0000 @@ -489,7 +489,7 @@ { TRACE( "mapping win %p\n", hwnd ); X11DRV_sync_window_style( display, data ); - X11DRV_set_wm_hints( display, data ); + X11DRV_set_wm_hints( display, data, FALSE ); wine_tsx11_lock(); XMapWindow( display, data->whole_window ); wine_tsx11_unlock(); @@ -650,7 +650,7 @@ { TRACE( "mapping win %p\n", hwnd ); X11DRV_sync_window_style( display, data ); - X11DRV_set_wm_hints( display, data ); + X11DRV_set_wm_hints( display, data, FALSE ); wine_tsx11_lock(); XMapWindow( display, data->whole_window ); wine_tsx11_unlock(); Index: x11drv.h =================================================================== RCS file: /home/wine/wine/dlls/x11drv/x11drv.h,v retrieving revision 1.76 diff -u -r1.76 x11drv.h --- x11drv.h 29 Jun 2005 19:28:06 -0000 1.76 +++ x11drv.h 15 Aug 2005 21:32:58 -0000 @@ -686,7 +686,7 @@ const RECT *new_whole_rect ); extern BOOL X11DRV_set_window_pos( HWND hwnd, HWND insert_after, const RECT *rectWindow, const RECT *rectClient, UINT swp_flags, const RECT *validRects ); -extern void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data ); +extern void X11DRV_set_wm_hints( Display *display, struct x11drv_win_data *data, BOOL update_size_hints ); extern void X11DRV_handle_desktop_resize(unsigned int width, unsigned int height); extern void X11DRV_Settings_AddDepthModes(void);

1 1

(no subject)
by John Smith 22 Aug '05

22 Aug '05

>You can also set it yourselves in in your app. As configuration >is in registry, every app can modify it. I like this idea, thanks. There are still 2 issues with such a soultion: a) most likely, it won't work until 2nd start of the application (we will modify it on the first run, and it most likely won't be applied until the second run); b) current WINE guides are discouraging us from detecting WINE - and messing up with Windows Registry, especially HKEY_LOCAL_MACHINE, on all the millions of non-WINE machines is not a thing I would really like to do (the last thing we want is to be caught by some antivirus, which monitors activity it considers suspicious and changing HKEY_LOCAL_MACHINE can easily qualify). _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

1 0

Re: X11DRV: more gcc 4.0 warning fixes
by Alexandre Julliard 22 Aug '05

22 Aug '05

Mike McCormack <mike(a)codeweavers.com> writes: > Index: dlls/x11drv/event.c > =================================================================== > RCS file: /home/mike/src/wine-cvs/wine/dlls/x11drv/event.c,v > retrieving revision 1.58 > diff -u -p -r1.58 event.c > --- dlls/x11drv/event.c 16 Aug 2005 16:02:45 -0000 1.58 > +++ dlls/x11drv/event.c 17 Aug 2005 01:09:41 -0000 > @@ -698,7 +698,7 @@ static void EVENT_DropFromOffiX( HWND hW > > if( !aux_long && p_data) /* don't bother if > 64K */ > { > - signed char *p = (signed char*) p_data; > + char *p = (char*) p_data; > char *p_drop; > > aux_long = 0; The code is storing -1 in there so it has to be a signed char (though that algorithm is really a nasty hack that should be fixed properly). > --- dlls/x11drv/text.c 23 Dec 2004 20:31:56 -0000 1.15 > +++ dlls/x11drv/text.c 16 Aug 2005 01:53:53 -0000 > @@ -390,7 +390,7 @@ X11DRV_ExtTextOut( X11DRV_PDEVICE *physD > wine_tsx11_lock(); > if (lfUnderline) > { > - long linePos, lineWidth; > + unsigned long linePos, lineWidth; > > if (!XGetFontProperty( font, XA_UNDERLINE_POSITION, &linePos )) > linePos = descent - 1; > @@ -405,7 +405,7 @@ X11DRV_ExtTextOut( X11DRV_PDEVICE *physD > } > if (lfStrikeOut) > { > - long lineAscent, lineDescent; > + unsigned long lineAscent, lineDescent; > if (!XGetFontProperty( font, XA_STRIKEOUT_ASCENT, &lineAscent )) > lineAscent = ascent / 2; > if (!XGetFontProperty( font, XA_STRIKEOUT_DESCENT, &lineDescent )) I think these should remain signed too, especially since lineDescent is set to -lineAscent. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: MSXML: add some node tests
by Alexandre Julliard 22 Aug '05

22 Aug '05

Mike McCormack <mike(a)codeweavers.com> writes: > diff -u -p -r1.1 domdoc.c > --- dlls/msxml3/tests/domdoc.c 12 Aug 2005 11:25:05 -0000 1.1 > +++ dlls/msxml3/tests/domdoc.c 20 Aug 2005 07:38:47 -0000 > @@ -27,59 +27,65 @@ > #include "xmldom.h" > #include <stdio.h> > > +#ifndef STANDALONE > #include "wine/test.h" > +#else > +#define ok(cond,str) do{ if(!(cond)) fprintf(stderr,"line %d: %s",__LINE__,str); }while (0) > +#endif Please don't add that sort of thing again, simply copy wine/test.h over to Windows and build with -DSTANDALONE. -- Alexandre Julliard julliard(a)winehq.org

1 0

DDRAW: don't leak visuals
by Saulius Krasuckas 21 Aug '05

21 Aug '05

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;

1 1

Re: secur32: Fix wrapper.c to honour functions that are run twice.
by Kai Blin 21 Aug '05

21 Aug '05

* 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.

1 0

Re: atl: fix warnings in 64bit
by Jacek Caban 21 Aug '05

21 Aug '05

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

1 0

Re: [WINEOSS] multiple sound card mixer patch
by Robert Reif 21 Aug '05

21 Aug '05

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); }

1 0

Should all builtin DLLs have version information?
by Paul Vriens 21 Aug '05

21 Aug '05

Hi, the subject says it all. If yes, I will start adding some for the ones visible in Process Explorer when running some of 'my' test-apps. Paul.

2 2

excluding kernel32.9[78] from a relay log
by Saulius Krasuckas 20 Aug '05

20 Aug '05

Using CVS version I get following calls in the output very frequently: 000b:Call kernel32.97(408b8880) ret=40891d49 000b:Ret kernel32.97() retval=40428f60 ret=40891d49 000b:Call kernel32.98(408b8880) ret=40891e27 000b:Ret kernel32.98() retval=00000000 ret=40891e27 I want to exclude this stuff. Adding "97;98" to "HKEY_CURRENT_USER/Software/Wine/debug/RelayExclude" string value doesn't help me. $ grep -Ir [^0-9]9[78][^0-9] dlls/kernel/*.spec | dlls/kernel/kernel32.spec: 97 stdcall -noname _EnterSysLevel(ptr) | dlls/kernel/kernel32.spec: 98 stdcall -noname _LeaveSysLevel(ptr) Adding "_EnterSysLevel;_LeaveSysLevel;97;98" does not help either. Suggestions?

2 2

IDA Pro regression
by James Liggett 20 Aug '05

20 Aug '05

Hi, Yesterday, after not upgrading my wine CVS copy for about a month, I upgraded to do some testing. I started IDA pro (version 4.8 demo) and got ready to debug a DLL that's been giving me trouble. Getting ready to start the debugger, I opened the General Registers window, and I noticed that the boxes that show the contents of the registers were about five times taller than they normally are. I set up the process options for the debugger and tried to get back to the General Registers window to start the debugger but IDA crashed with an "Abnormal Termination" error. It doesn't give any unusual errors in the console. Can someone recommend to me some tips for finding the problem? I have considered downgrading CVS until I find the problem, but that seems like a *lot* of compiling and recompiling. Is there a more efficient way to go about finding the cause of the problem? Thanks very much, James Liggett

3 2

Bugs in ole32 test (Or in windows)
by Ivan Leo Puoti 20 Aug '05

20 Aug '05

The tmp files generated by the testProps() and testCodepage() in dlls/ole32/tests/stg_prop.c don't get deleted in windows nt 4.0, even if apparently a DeleteFileW is done on them. Ivan.

1 0

Re: winefile: TRY2 Fix for encoding Ru.rc
by Dmitry Timoshkov 20 Aug '05

20 Aug '05

"Yuri Kozlov" <kozlov.y(a)gmail.com> wrote: > Changelog: > fix for encoding Ru.rc > --- wine/programs/winefile/Ru.rc 2005-06-20 15:45:39.000000000 +0400 > +++ bwine/programs/winefile/Ru.rc 2005-08-18 19:56:37.000000000 +0400 > @@ -20,6 +20,8 @@ > > LANGUAGE LANG_RUSSIAN, SUBLANG_DEFAULT > > +#pragma code_page(1251) Why do you need it? Specifying a language should be enough, at least it works for all other resource files, including russian ones. -- Dmitry.

2 1

Re: RICHED20: Avoid flicker
by Phil Krylov 19 Aug '05

19 Aug '05

On Sun, 14 Aug 2005 17:53:33 +0400 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > this patch needs to be applied after the "Re: RICHED20: Implement > EM_SETRECT, EM_SETRECTNP and WM_SETREDRAW messages (fixed)" patch. > > ChangeLog: > > Avoid flicker in RichEdit using proper update region invalidation and an > offscreen bitmap. Anything wrong with this patch? -- Ph.

2 1

Jump to page:

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