- Wine-Devel - list.winehq.org

mmsystem should be loaded at startup
by Joshua Thielen Nov. 24, 2001

Nov. 24, 2001

Hello everybody, Finale expects mmsystem to be present without having to call LoadLibrary on it. It does a GetModuleHandle on mmsystem.dll to find out if the mm extensions are available. I checked out windows 95, and it has mmsystem and winmm loaded when no apps are runing besides the desktop / explorer. This patch links wine with winmm andmakes winmm load mmsystem on init. Finale gets by this ok now. I don't know if this the correct approach, though. Could someone (Eric or Alexandre?) please take a look at it before I send it to wine-patches? TIA, Josh Thielen Index: wine/miscemu/wine.spec =================================================================== RCS file: /home/wine/wine/miscemu/wine.spec,v retrieving revision 1.3 diff -u -r1.3 wine.spec --- wine/miscemu/wine.spec 2000/12/15 03:38:11 1.3 +++ wine/miscemu/wine.spec 2001/11/23 19:11:47 @@ -4,3 +4,4 @@ init wine_initial_task import ntdll.dll +import winmm.dll Index: wine/dlls/winmm/mmsystem.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/mmsystem.c,v retrieving revision 1.46 diff -u -r1.46 mmsystem.c --- wine/dlls/winmm/mmsystem.c 2001/11/13 21:58:32 1.46 +++ wine/dlls/winmm/mmsystem.c 2001/11/23 19:11:59 @@ -114,6 +114,7 @@ */ BOOL WINAPI WINMM_LibMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID fImpLoad) { + HINSTANCE16 mmsys16; TRACE("0x%x 0x%lx %p\n", hInstDLL, fdwReason, fImpLoad); switch (fdwReason) { @@ -124,9 +125,15 @@ MULTIMEDIA_DeleteIData(); return FALSE; } + mmsys16 = LoadLibrary16("mmsystem.dll"); + if (!mmsys16) { + ERR("Could not load sibling mmsystem.dll\n"); + return FALSE; + } break; case DLL_PROCESS_DETACH: MULTIMEDIA_DeleteIData(); + if(mmsys16) FreeLibrary16(mmsys16); break; case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: @@ -2549,7 +2556,7 @@ TRACE("(%d, %p, %d);\n", uDeviceID, lpCaps, uSize); if ((wmld = MMDRV_Get(uDeviceID, MMDRV_MIDIIN, TRUE)) == NULL) - return MMSYSERR_INVALHANDLE; + return MMSYSERR_BADDEVICEID; return MMDRV_Message(wmld, MIDM_GETDEVCAPS, (DWORD)lpCaps, uSize, TRUE); }

3 3

Re: mmsystem should be loaded at startup
by Alexandre Julliard Nov. 24, 2001

Nov. 24, 2001

Joshua Thielen <thielen(a)netprince.net> writes: > Finale expects mmsystem to be present without having to call LoadLibrary > on it. It does a GetModuleHandle on mmsystem.dll to find out if the mm > extensions are available. I checked out windows 95, and it has mmsystem > and winmm loaded when no apps are runing besides the desktop / > explorer. This patch links wine with winmm andmakes winmm load mmsystem > on init. Finale gets by this ok now. I don't know if this the correct > approach, though. Could someone (Eric or Alexandre?) please take a look > at it before I send it to wine-patches? It would be better to do the LoadLibrary16("mmsystem") in wine_initial_task, this way it only impacts 16-bit applications. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wineconsole compile error
by Alexandre Julliard Nov. 24, 2001

Nov. 24, 2001

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > dialog.o dialog.c > dialog.c: In function `WCUSER_GetProperties': > dialog.c:492: structure has no member named `u' > dialog.c:496: structure has no member named `u' > dialog.c:500: structure has no member named `u' > dialog.c:509: structure has no member named `u3' > > This is happening on gcc 3.0.2 (nameless union support, I suppose). It should be fixed now. -- Alexandre Julliard julliard(a)winehq.com

1 0

wineconsole compile error
by Andreas Mohr Nov. 24, 2001

Nov. 24, 2001

Hi all, people get make[1]: Entre dans le répertoire `/home/wine/programs/wineconsole' gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DUNICODE -D_REENTRANT -I/usr/X11R6/include -o dialog.o dialog.c dialog.c: In function `WCUSER_GetProperties': dialog.c:492: structure has no member named `u' dialog.c:496: structure has no member named `u' dialog.c:500: structure has no member named `u' dialog.c:509: structure has no member named `u3' This is happening on gcc 3.0.2 (nameless union support, I suppose). On my system, this file compiles painlessly: root(a)andi:/root# gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20010902 (Debian prerelease) (no nameless union support, I suppose) I told this guy to replace .u. and .u3. in dialog.c with DUMMYUNIONNAME and DUMMYUNIONNAME3, respectively. This caused: dialog.c:492: parse error before `.' dialog.c:496: parse error before `.' dialog.c:500: parse error before `.' dialog.c:509: parse error before `.' I thought that this particular error was caused by a missing #include "winnt.h", but adding this didn't help either. Please fix this "mess" ASAP (in an appropriate way, one that I seem to not be able to find out :-\). Thank you ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany "Point is, nothing here is unfamiliar or unexpected. How long does it take before there's general recognition that Microsoft software has no business on the Internet? - Dennis E. Powell re: Code Red

1 0

Re: Where are we going on multiuser?
by Alexandre Julliard Nov. 23, 2001

Nov. 23, 2001

"Bill Medland" <medbi01_1(a)accpac.com> writes: > What is our vision on support for multiple users on a single computer? > > I know that WINEPREFIX allows us to use something other than $HOME/.wine for > the base of everything but as far as I can see the whole design still > requires a different WINEPREFIX for each user. (e.g. the socket is in > wine-server-<hostname> and there is no apparent support for the system.reg, > user.reg and userdef.reg being in different places). You need one WINEPREFIX per user yes. You can use global registry files by creating symlinks to global files in the user WINEPREFIX. The usual way is to wrap your app in a shell script that will populate the user's WINEPREFIX if it doesn't exist yet. There are plans for splitting registry files into separate sections with some kind of include mechanism, but nothing implemented yet. -- Alexandre Julliard julliard(a)winehq.com

1 0

Where are we going on multiuser?
by Bill Medland Nov. 23, 2001

Nov. 23, 2001

What is our vision on support for multiple users on a single computer? I know that WINEPREFIX allows us to use something other than $HOME/.wine for the base of everything but as far as I can see the whole design still requires a different WINEPREFIX for each user. (e.g. the socket is in wine-server-<hostname> and there is no apparent support for the system.reg, user.reg and userdef.reg being in different places). Bill

1 0

Re: fix documentation compilation error
by Andreas Mohr Nov. 23, 2001

Nov. 23, 2001

On Fri, Nov 23, 2001 at 01:35:14AM +0100, Michael Stefaniuc wrote: > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > Add missing </para> in documentation/packaging.sgml Ouch ! Hmm, better make an actual compile next time :-\ Sorry !! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

A window painting problem.
by Duane Clark Nov. 22, 2001

Nov. 22, 2001

Howdy, Perhaps this is one of those things that is in work. But this patch causes one of the (sub)windows in the app Xilinx fpga_editor (commercial) to never get painted. The app has several windows within a window, including a scrolled window, which after the patch I can zoom in and out and move the scrollbars just fine. But the contents never get painted, no matter what I do, including hiding and reshowing, etc. All the other pieces and windows are painted fine. http://cvs.winehq.com/patch.py?id=1005773317852080273907632 Log message: Moved WIN_FindWinToRepaint functionality to the server. Duane

1 0

Re: Which is correct? listview or treeview?
by Gerard Patel Nov. 22, 2001

Nov. 22, 2001

At 01:58 PM 21/11/2001 -0800, you wrote: >With regard to my problem that I was getting infinite redraws in my listview >following Alexandre's change to server/user/message.c: > >I eventually tracked it down to the fact our code used >SetRedraw(FALSE)/SetRedraw(TRUE) on a list control. (So the bug can now be >demonstrated easily on e.g. the MFC RowList sample with a two-line change). >Now I see that in the case of LISTVIEW_SetRedraw DefWindowProc is called and >then RedrawWindow. >In the TREEVIEW_SetRedraw case it simply sets a flag within the treeview's >data. > >Which is (more) correct? I have seen the same problem with the plain listbox I have an app (Eudora) that is using WM_SETREDRAW on a listbox and found that it was not possible to reproduce the app's behaviour without doing directly a RedrawWindow. Andi commented it was ugly and unefficient (IIRC) and Alexandre Julliard ignored the patch anyway. So I intended at some point to look at Listview and Treeview (with the nasty intent to prove that I am right and they are wrong of course :-)) If you find that doing an explicit RedrawWindow is the right way (TM) I am all for it. OTOH, I have myself - at least ;-( - one regression pending for this patch. The attached hack (on dlls/x11drv/winpos.c) fixes it, maybe with a lot of luck it could fix your problem too ? I'm not too hopeful as it does not seem related but you never know. Gerard --- winpos.c.orig Tue Nov 13 23:02:20 2001 +++ winpos.c Thu Nov 22 00:24:35 2001 @@ -1464,6 +1464,14 @@ /*********************************************************************** * X11DRV_ConfigureNotify */ + +Bool predicate(Display *display, XEvent *event, char *arg) +{ + Window w = *((Window *) arg); + return ((event->type == ConfigureNotify) && + (event->xany.window == w)); +} + void X11DRV_ConfigureNotify( HWND hwnd, XConfigureEvent *event ) { HWND oldInsertAfter; @@ -1472,8 +1480,20 @@ RECT rect; WINDOWPOS winpos; int x = event->x, y = event->y; + XConfigureEvent ev; if (!(win = WIN_GetPtr( hwnd ))) return; + + while (XCheckIfEvent(event->display, (XEvent *)&ev, + predicate, (XPointer)&event->window)) + { + event->x = ev.x; + event->y = ev.y; + event->width = ev.width; + event->height = ev.height; + event->above = ev.above; + event->send_event = ev.send_event; + } data = win->pDriverData; /* Get geometry */

2 1

thanksgiving prayer
by lee Nov. 22, 2001

Nov. 22, 2001

...wishing everyone a special thanksgiving filled with great joy, special friends and loved ones as we move forward to a brighter tomorrow, carrying with us the best of yesterday and the promise of today- lee

1 0