wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

FF8 and DirectMusic
by Martin Lexa 06 Aug '02

06 Aug '02

Hi! I tried Final Fantasy 8 under Wine (no Windows), yesterday. Got it running, but FF8Config refused to start complaining something about MIDI error. Of course no music. Here is what I found after debugging almost 6 hours :( 1. There are some missing registry entries which are needed. [Software\\Classes\\CLSID\\{58C2B4D0-46E7-11D1-89AC-00A0C9054129}] 1028325524 @="DirectMusicSynth" [Software\\Classes\\CLSID\\{58C2B4D0-46E7-11D1-89AC-00A0C9054129}\\InprocServer32] 1028325524 @="dmsynth.dll" "ThreadingModel"="Both" [Software\\Classes\\CLSID\\{636B9F10-0C7D-11D1-95B2-0020AFDC7421}] 1028325524 @="DirectMusic Object" [Software\\Classes\\CLSID\\{636B9F10-0C7D-11D1-95B2-0020AFDC7421}\\InprocServer32] 1028325524 @="dmusic.dll" "ThreadingModel"="Both" [Software\\Microsoft\\DirectMusic] 1028325524 @="" "GMFilePath"="gm.dls" [Software\\Microsoft\\DirectMusic\\Defaults] 1028325524 @="" "DefaultOutputport"="{58C2B4D0-46E7-11D1-89AC-00A0C9054129}" [Software\\Microsoft\\DirectMusic\\SoftwareSynths] 1028325524 @="" [Software\\Microsoft\\DirectMusic\\SoftwareSynths\\{58C2B4D0-46E7-11D1-89AC-00A0C9054129}] 1028325524 @="" "Description"="Microsoft Software Synthesizer" 2. Original (native) DMUSIC.DLL, DMUSIC16.DLL, DMUSIC32.DLL, DMSYNTH.DLL are needed too. After above changes FF8Config wasn't complaining about MIDI problems., but simply hanging after displaying window. I think problem is that I'm using native DirectMusic DLLs or am I wrong? Maybe not, because there is X11DRV error... Here is wine output: $ wine --debugmsg +ole FF8Config.exe trace:ole:OLE32_DllEntryPoint 0x40bda000 0x1 0x1 trace:ole:CoRegisterMallocSpy trace:ole:IMallocSpy_fnQueryInterface ({0000001d-0000-0000-c000-000000000046},0x405c6dec) trace:ole:OLE32_DllEntryPoint 0x40bda000 0x2 (nil) trace:ole:OLE32_DllEntryPoint 0x40bda000 0x2 (nil) fixme:ddraw:MESA_IDirect3D2Impl_EnumDevices (0x403d8f58)->(0x401e45,0x403d8f58),stub! fixme:ddraw:MESA_IDirect3D2Impl_EnumDevices (0x403d8f58)->(0x401e45,0x403d8f58),stub! trace:ole:OLE32_DllEntryPoint 0x40bda000 0x2 (nil) fixme:ddraw:MESA_IDirect3D2Impl_EnumDevices (0x403d8f58)->(0x401e45,0x403d8f58),stub! fixme:ddraw:MESA_IDirect3D2Impl_EnumDevices (0x403d8f58)->(0x401e45,0x403d8f58),stub! trace:ole:CoInitializeEx ((nil), 2) trace:ole:CoInitializeEx () - Initializing the COM libraries trace:ole:RunningObjectTableImpl_Initialize () trace:ole:WINE_StringFromCLSID 0x4155a0->{636B9F10-0C7D-11D1-95B2-0020AFDC7421} trace:ole:CoGetClassObject CLSID: {636b9f10-0c7d-11d1-95b2-0020afdc7421}, IID: {00000001-0000-0000-c000-000000000046} trace:ole:COMPOBJ_DLLList_Add fixme:setupapi:SetupDiGetClassDevsA {6994ad04-93ef-11d0-a3cc-00a0c9223196} (null) 0000 00000012 trace:ole:__CLSIDFromStringA {58C2B4D0-46E7-11D1-89AC-00A0C9054129} -> 0x405c6d4c trace:ole:WINE_StringFromCLSID 0x405c6d4c->{58C2B4D0-46E7-11D1-89AC-00A0C9054129} trace:ole:CoGetClassObject CLSID: {58c2b4d0-46e7-11d1-89ac-00a0c9054129}, IID: {00000001-0000-0000-c000-000000000046} trace:ole:COMPOBJ_DLLList_Add trace:ole:CoUninitialize () err:ntdll:RtlpWaitForCriticalSection section 0x40cd0424 "x11drv_main.c: X11DRV_CritSection" wait timed out, retrying (60 sec) tid=080720a8 If running wine like this 'wine --debugmsg +all FF8Config.exe &>log' the FF8Config not hangs in displaying window and looks like it's running ok! This means wine is running very slowly, because of writing debug messages, so there is some kind of timing error... may be not. Don't know for sure. Could somebody point me where should I look? What above "err:ntdll:..." really means? How should I debug it? And I'd like to ask is somebody who works on DirectMusic implementation under Wine? If no, could somebody tell me how hard should be add this? Is really necessary to implement each DLL or just DMSYNTH.DLL(?) contains needed rutines? I'd like to get FF8 running at any price :) Thank you in advance. Regards, Martin.

2 2

Isn't 'make depend' optional?
by Bang Jun-Young 06 Aug '02

06 Aug '02

Hi, I got the following error with wine-20020804 when I skipped 'make depend' before doing 'make': gmake[2]: Entering directory `/u0/work/wine-20020804/tools/widl' gcc -c -I. -I. -I../../include -I../../include -O2 -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o header.o header.c header.c:36: y.tab.h: No such file or directory gmake[2]: *** [header.o] Error 1 gmake[2]: Leaving directory `/u0/work/wine-20020804/tools/widl' gmake[1]: *** [widl] Error 2 gmake[1]: Leaving directory `/u0/work/wine-20020804/tools' gmake: *** [tools] Error 2 This was due to dependency that widl/*.c require y.tab.h in common but y.tab.h is not generated before compilation is being done. I have worked around it as follows: --- Make.rules.in.orig Sat Aug 3 04:34:21 2002 +++ Make.rules.in Mon Aug 5 14:57:17 2002 @@ -112,7 +112,7 @@ CLEAN_FILES = *.o *.a *.so *.ln *.$(LIBEXT) \\\#*\\\# *~ *% .\\\#* *.bak *.orig *.rej \ *.flc *.spec.c *.spec.def *.glue.c *.dbg.c y.tab.c y.tab.h @LEX_OUTPUT_ROOT@.c core -OBJS = $(C_SRCS:.c=.o) $(GEN_C_SRCS:.c=.o) $(GEN_ASM_SRCS:.s=.o) $(ASM_SRCS:.S=.o) $(EXTRA_OBJS) +OBJS = $(EXTRA_OBJS) $(C_SRCS:.c=.o) $(GEN_C_SRCS:.c=.o) $(GEN_ASM_SRCS:.s=.o) $(ASM_SRCS:.S=.o) RCOBJS = $(RC_SRCS:.rc=.res.o) LINTS = $(C_SRCS:.c=.ln) Obviously the patch doesn't look good. Is there any better solution for this? What about introducing PREEXTRA_OBJS and POSTEXTRA_OBJS? Jun-Young -- Bang Jun-Young <junyoung(a)mogua.com>

7 15

ASM_FUNC isn't autodetect correctly
by Luc Saillard 05 Aug '02

05 Aug '02

Hi, On my computer, ASM_FUNC doesn't have the good value. configure choose this macro: >#define __ASM_FUNC(name) ".def " __ASM_NAME(name) "; .scl 2; .type 32; .endef" but when i use this macro, i've a lot assembler error that .scl and .endef isn't a valid command. The good value is (at least it compile cleanly): >#define __ASM_FUNC(name) ".type " __ASM_NAME(name) ",@function" I'm using a debian sid box with: ii gcc-2.95 2.95.4-10 ii gcc-3.1 3.1.1-2 ii binutils 2.12.90.0.15-1 (freshly installed) ii autoconf 2.53-4 I've test gcc 2.95 and gcc 3.1 with the same error. Perhaps it's my binutils package ? If i revert aclocal.m4 from 2002-07-25 with this command >cvs diff -c -D 2002-07-22 aclocal.m4 | patch -R It will detect the good macros. >checking how to define a function in assembly code... .type @function But, it will failed later when testing dlopen, because conftest_asm.s doesn't exist. So i need to set this macro at hand. Luc

1 0

RE: DInput patch - Bugzilla rights
by Patrik Stridvall 05 Aug '02

05 Aug '02

> Lionel Ulmer wrote: > > > > >This fixes bug 941. By the way, could I have more 'bugzilla' > power, I hate > >not being able to move bugs out of Unconfirmed state or to > not being able to > >close them (/me thinks that all Wine developpers should have > these rights). > > > > > Yes I aggree all Wine developers should have full rights in bugzilla. Yes, please. I remember once trying to reclassfied a wrongly classified bug and failed. I wasn't that important so I didn't bother asking for more rights... I haven't used Bugzilla that much but I certainly won't not use it less if I get more rights rather more... > Right now Andriy Palamarchuk and Jeremy Newman are the ones > that can do > this. The only catch is the developers need to set up a > bugzilla account > first. I have one already. Same as my email adress: ps(a)leissner.se

1 0

Re: DInput patch - Bugzilla rights
by Tony Lambregts 05 Aug '02

05 Aug '02

Lionel Ulmer wrote: > >This fixes bug 941. By the way, could I have more 'bugzilla' power, I hate >not being able to move bugs out of Unconfirmed state or to not being able to >close them (/me thinks that all Wine developpers should have these rights). > > Yes I aggree all Wine developers should have full rights in bugzilla. Right now Andriy Palamarchuk and Jeremy Newman are the ones that can do this. The only catch is the developers need to set up a bugzilla account first. Tony Lambregts

1 0

OpenGL 'hack' patch
by Lionel Ulmer 05 Aug '02

05 Aug '02

Hi all, To make NWN's model viewer work in Wine, I did the attached patch... Warning, it's not for the faint of heart so ugly it is :-) Basically, the plan is to have two drawable per DC in the X11 driver, one for 'normal' drawings, the other for OpenGL drawings, the latter being the one associated with the window when goind a CLIPSIBLINGS GetDCEx. Now to do this 'nicely', the 'use ExtEscape to store data' method is not the right one (but it works :-) ). So my current plan is to really separate all the X11 stuff into the X11DRV and to have a 'portable' opengl32.dll library. Now my question is 'how to do this properly' ? Is extending the 'dc' function pointer array with all the needed OpenGL functions a way (even if these functions are NOT GDI functions but pure OpenGL) ? The problem with this solution is that I would need to use the 'DC_GetDCPtr' function outside of GDI (and that may break DLL separation). Another solution could be to add all the OpenGL functions as GDI functions, do the DC function pointer thing and then put a forward from all the wgl functions to the GDI32.* functions. What do you all think of it ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

cvs [update aborted]: request `update_template' not supported by server
by Shachar Shemesh 05 Aug '02

05 Aug '02

When trying to perform CVS operations on the WINE build from Solaris, I get the above mentioned error: cvs [update aborted]: request `update_template' not supported by server I am using cvs version 1.10.1 Anyone here knows what the problem is? Shachar

1 0

Small 'quibble' about GetDCEx
by Lionel Ulmer 05 Aug '02

05 Aug '02

Hi, While hunting down a function to get the HWND associated to a DC (I found it 'WindowFromDC'), I looked at the GetDCEx code, and found this : dce->DCXflags |= DCX_DCEBUSY; (...) if (!USER_Driver.pGetDC( hwnd, hdc, hrgnClip, flags )) hdc = 0; In that case, shouldn't the DCEBUSY flag be 'unset' or something ? I did not submit a patch because I did not know if unsetting would have been enough or if DCE_ReleaseDC should have been called (and, yes, I know, the pGetDC cannot ever return FALSE in the X11 driver, but well, if the error code exists, we should write it properly :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Recent patches introduced a regression error
by Paul Millar 04 Aug '02

04 Aug '02

Hi, According to WRT [1], one of todays patches caused a regression error, picked up by one of the wininet DLL tests. Only, none of the patches seem to have touched wininet. The problem is with the tests at dlls/wininet/tests/http.c lines 117 and 157. The test freezes for up to 4 minutes, then returns the failures. As an act in desperation, I've tried reversing some of the patches (1-4, 6, and 7 from the WRT list) without success. I'm also a little suspicious that this might be something to do with Glasgow (or me :) I've been able to reproduce the problem on two other (local) machines, but I've not tried on any remote machines. I've also tried using earlier cvs versions (from a few days ago), but that build fails the wininet tests too. It would be good if someone could confirm the problem. Sorry if this turns out to be a red herring ... Paul. PS It's quite late here, so I might not be able to reply until tomorrow. [1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php ---- Paul Millar

3 8

PATCH: formatting fixes in files/smb.c
by Gerald Pfeifer 04 Aug '02

04 Aug '02

I am also Cc:ing this patch to wine-devel because I think it shows that there is an issue that deserves a bit of thought: Code formatting. We certainly should not get anal rentative on this, but something like int trn = 1234,i=0; from files/smb.c where even a single line is inconsistent really makes me wonder. Also I am not aware of any coding style that asks for blanks around the assignment but does not use a blank after the comma. The patch below fixes at least the worst problems, by consistently using a blank after a comma in variable declarations. Gerald ChangeLog: Fix formatting of variable declarations. Index: smb.c =================================================================== RCS file: /home/wine/wine/files/smb.c,v retrieving revision 1.8 diff -u -3 -p -r1.8 smb.c --- smb.c 19 Jul 2002 03:17:19 -0000 1.8 +++ smb.c 4 Aug 2002 17:35:54 -0000 @@ -123,7 +123,7 @@ struct NB_Buffer static int netbios_name(const char *p, unsigned char *buffer) { char ch; - int i,len=0; + int i, len=0; buffer[len++]=' '; for(i=0; i<=MAX_HOST_NAME; i++) @@ -146,7 +146,7 @@ static int netbios_name(const char *p, u static DWORD NB_NameReq(LPCSTR host, unsigned char *buffer, int len) { - int trn = 1234,i=0; + int trn = 1234, i=0; NBR_ADDWORD(&buffer[i],trn); i+=2; NBR_ADDWORD(&buffer[i],0x0110); i+=2; @@ -203,9 +203,9 @@ static BOOL UNC_SplitName(LPSTR unc, LPS static BOOL NB_Lookup(LPCSTR host, struct sockaddr_in *addr) { - int fd,on=1,r,len,i,fromsize; + int fd, on=1, r, len, i, fromsize; struct pollfd fds; - struct sockaddr_in sin,fromaddr; + struct sockaddr_in sin, fromaddr; unsigned char buffer[256]; fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP); @@ -288,7 +288,7 @@ err: static BOOL NB_SessionReq(int fd, char *called, char *calling) { unsigned char buffer[0x100]; - int len = 0,r; + int len = 0, r; struct pollfd fds; TRACE("called %s, calling %s\n",called,calling); @@ -571,7 +571,7 @@ static BOOL SMB_NegotiateProtocol(int fd static BOOL SMB_SessionSetup(int fd, USHORT *userid) { unsigned char buf[0x100]; - int pcount,bcount; + int pcount, bcount; struct NB_Buffer rx, tx; memset(buf,0,sizeof buf); @@ -667,7 +667,7 @@ static BOOL SMB_TreeConnect(int fd, USHO { unsigned char buf[0x100]; int slen; - struct NB_Buffer rx,tx; + struct NB_Buffer rx, tx; TRACE("%s\n",share_name); @@ -731,7 +731,7 @@ static BOOL SMB_NtCreateOpen(int fd, USH DWORD attributes, HANDLE template, USHORT *file_id ) { unsigned char buffer[0x100]; - int len = 0,slen; + int len = 0, slen; TRACE("%s\n",filename); @@ -886,9 +886,9 @@ static BOOL SMB_Open(int fd, USHORT tree DWORD creation, DWORD attributes, USHORT *file_id ) { unsigned char buf[0x100]; - int slen,pcount,i; + int slen, pcount, i; USHORT mode = SMB_GetMode(access,sharing); - struct NB_Buffer rx,tx; + struct NB_Buffer rx, tx; TRACE("%s\n",filename); @@ -944,8 +944,8 @@ static BOOL SMB_Open(int fd, USHORT tree static BOOL SMB_Read(int fd, USHORT tree_id, USHORT user_id, USHORT dialect, USHORT file_id, DWORD offset, LPVOID out, USHORT count, LPUSHORT read) { - int buf_size,n,i; - struct NB_Buffer rx,tx; + int buf_size, n, i; + struct NB_Buffer rx, tx; TRACE("user %04x tree %04x file %04x count %04x offset %08lx\n", user_id, tree_id, file_id, count, offset); @@ -1285,7 +1285,7 @@ done: static int SMB_GetSocket(LPCSTR host) { - int fd=-1,r; + int fd=-1, r; struct sockaddr_in sin; struct hostent *he; @@ -1390,7 +1390,7 @@ HANDLE WINAPI SMB_CreateFileA( LPCSTR un { int fd; USHORT tree_id=0, user_id=0, dialect=0, file_id=0; - LPSTR name,host,share,file; + LPSTR name, host, share, file; HANDLE handle = INVALID_HANDLE_VALUE; name = HeapAlloc(GetProcessHeap(),0,lstrlenA(uncname)); @@ -1540,7 +1540,7 @@ BOOL WINAPI SMB_ReadFile(HANDLE hFile, L SMB_DIR* WINAPI SMB_FindFirst(LPCSTR name) { int fd = -1; - LPSTR host,share,file; + LPSTR host, share, file; USHORT tree_id=0, user_id=0, dialect=0; SMB_DIR *ret = NULL; LPSTR filename;

1 0

Re: DDraw Clipper fix
by Ove Kaaven 03 Aug '02

03 Aug '02

On Sat, 3 Aug 2002, Lionel Ulmer wrote: > This should hopefully fix bug : > Bug 936 - Incorrect placement of DirectDraw output (offset outside the Windows 'window') > > Basically, the logic to compute the clipping window was wrong (or at least I > did not understand all the subtilities of the code :-) ). At least with this > fix, this particular application now runs fine. I'm 99% sure I fixed this in my last patch submission to winehq a while ago. Seems Alexandre applied it after 20020710, though. So I don't think your patch applies on top of CVS.

2 1

New CVS and Agent
by Oliver Sampson 03 Aug '02

03 Aug '02

Howdy, I just built a new CVS version--the first one in a while. I got caught by the -managed and the -winver options going away--a little searching through the list archives, and the problems were solved! Anyhow, I generally run with two instances of Forte Agent v1.9 open. Since I've built the new CVS, there's a change in behavior that I thought I'd the devel community know about. When pressing the shortcut buttons on the Agent instance that was first opened, nothing happened. When pressing on the buttons in the second instance, they worked normally. I closed the second instance, and the buttons in the first instance now work normally. Perhaps the messages are being captured and sent to the wrong place? (They're not being sent to the wrong instance of Agent.) Also there was no obvious output messages in the console window. That's the only change in behavior I've found so far. It still runs great. Thanks to the devel community! Oliver ==================================================== Oliver Sampson olsam(a)quickaudio.com http://www.oliversampson.com

1 1

Re: Bug in winetest's configure???
by Tony Lambregts 03 Aug '02

03 Aug '02

DJ Lucas wrote: >I dont' know if this has been brought up before or not, haven't searched >the archives or anything, but this seems to be dependant on how perl was >installed. > >For some reason, when perl, 5.6.1 or 5.8.0 is configured with >./configure.gnu, when you go to build wine, in the winetest Makefile, >the ccflags variable (leftover from perl install) is included in >LDFLAGS. Obviously this is in error, but attempting to figure out if >this should be brought to Wine or Perl Developers. :-$ See the >following URLs for archives of the LFS mailing lists where this has been >previously discussed. The second seems to be more relevant. > >http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2002/07/0547.h >tml > >http://archive.linuxfromscratch.org/mail-archives/blfs-support/2002/08/0 >024.html > >Thanks in advance > >DJ Lucas > >PS, if this has been previously identified, please CC me in the first >reply, no need to flood the mailing list. ;-) > > > > > This issue seems to be delt with in bug 787 and there is even a patch for it. http://bugs.winehq.com/show_bug.cgi?id=787 It seems this patch is not in CVS and I do not recall it being submitted to wine patches either. Any coment? This patch is from Mike Castle dalgoda(a)ix.netcom.com Index: winetest.c =================================================================== RCS file: /home/wine/wine/programs/winetest/winetest.c,v retrieving revision 1.5 diff -u -r1.5 winetest.c --- winetest.c 10 Mar 2002 00:21:20 -0000 1.5 +++ winetest.c 1 Aug 2002 20:38:29 -0000 @@ -152,7 +152,7 @@ /* perl extension initialisation */ -static void xs_init(void) +static void xs_init(pTHX) { extern void boot_wine(CV *cv); newXS("wine::bootstrap", boot_wine,__FILE__);

2 1

rpcrt / epmapper / scm
by juergen.schmied＠debitel.net 02 Aug '02

02 Aug '02

Hi! Some time ago I did send the rpcrt patches from ove ported to the cvs. It didn't got included. Are there any special reasons? The epmapper was implemented in the wineserver. Should it be a standalone server? 1) If it would be a win32 process we would need 2 context changes for every call. If it would be a server like the wine-server there would only be 1 context change per call. 2) What IPC should we use locally? We could implement LPC like reactos. 3) We need a process for managing services and COM out-of-process servers (the SCM). Any ideas how to do this? To many questions for one mail? ;-) juergen

2 1

problem with destroy window
by Juergen Schmied 02 Aug '02

02 Aug '02

Looks like a window what is in destruction gets the focus from WINPOS_ActivateOtherWindow and don't like it... juergen 08073ff8:Call user32.DestroyWindow(00010022) ret=5d34c141 trace:win:DestroyWindow (10022) 08073ff8:Call x11drv.ResetSelectionOwner(00010022,00000000) ret=4069f640 08073ff8:Ret x11drv.ResetSelectionOwner() retval=02800003 ret=4069f640 08073ff8:Call x11drv.ShowWindow(00010022,00000000) ret=406a4127 08073ff8:Ret x11drv.ShowWindow() retval=00000000 ret=406a4127 trace:win:DestroyWindow (10024) 08073ff8:Call x11drv.ResetSelectionOwner(00010024,00000000) ret=4069f640 08073ff8:Ret x11drv.ResetSelectionOwner() retval=02800007 ret=4069f640 08073ff8:Call x11drv.ShowWindow(00010024,00000000) ret=406a4127 08073ff8:Ret x11drv.ShowWindow() retval=00000000 ret=406a4127 trace:win:WINPOS_SetActiveWindow (10022, 0, 1) trace:win:WINPOS_SetActiveWindow no current active window. 08073ff8:Call window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_QUERYNEWPALETTE,wp=00000000,lp=00000000) 08073ff8:Call user32.GetWindow(00010025,00000005) ret=5d30c073 08073ff8:Ret user32.GetWindow() retval=00000000 ret=5d30c073 08073ff8:Call user32.SendMessageA(00010025,0000030f,00000000,00000000) ret=5d30c0be 08073ff8:Call window proc 0x5d34dfc9 (hwnd=00010025,msg=WM_QUERYNEWPALETTE,wp=00000000,lp=00000000) 08073ff8:Call user32.DefWindowProcW(00010025,0000030f,00000000,00000000) ret=5d34e274 08073ff8:Ret user32.DefWindowProcW() retval=00000000 ret=5d34e274 08073ff8:Ret window proc 0x5d34dfc9 (hwnd=00010025,msg=WM_QUERYNEWPALETTE,wp=00000000,lp=00000000) retval=00000000 08073ff8:Ret user32.SendMessageA() retval=00000000 ret=5d30c0be 08073ff8:Call user32.DefWindowProcA(00010022,0000030f,00000000,00000000) ret=5d34c99a 08073ff8:Ret user32.DefWindowProcA() retval=00000000 ret=5d34c99a 08073ff8:Ret window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_QUERYNEWPALETTE,wp=00000000,lp=00000000) retval=00000000 08073ff8:Call window proc 0x42f35c40 (hwnd=00010024,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) 08073ff8:Call user32.GetWindowLongA(00010024,00000000) ret=42f35c91 08073ff8:Ret user32.GetWindowLongA() retval=42ff0408 ret=42f35c91 08073ff8:Call user32.DefWindowProcA(00010024,0000001c,00000001,00000000) ret=42f36426 08073ff8:Ret user32.DefWindowProcA() retval=00000000 ret=42f36426 08073ff8:Ret window proc 0x42f35c40 (hwnd=00010024,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) retval=00000000 08073ff8:Call window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) 08073ff8:Call user32.DefWindowProcA(00010022,0000001c,00000001,00000000) ret=5d34c99a 08073ff8:Ret user32.DefWindowProcA() retval=00000000 ret=5d34c99a 08073ff8:Ret window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) retval=00000000 08073ff8:Call window proc 0x77a67048 (hwnd=00010021,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) 08073ff8:Call user32.DefWindowProcW(00010021,0000001c,00000001,00000000) ret=77a67087 08073ff8:Ret user32.DefWindowProcW() retval=00000000 ret=77a67087 08073ff8:Ret window proc 0x77a67048 (hwnd=00010021,msg=WM_ACTIVATEAPP,wp=00000001,lp=00000000) retval=00000000 08073ff8:Call window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_NCACTIVATE,wp=00000001,lp=00000000) 08073ff8:Call user32.DefWindowProcA(00010022,00000086,00000001,00000000) ret=5d34c99a 08073ff8:Ret user32.DefWindowProcA() retval=00000001 ret=5d34c99a 08073ff8:Ret window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_NCACTIVATE,wp=00000001,lp=00000000) retval=00000001 08073ff8:Call window proc 0x5d34c6f6 (hwnd=00010022,msg=WM_ACTIVATE,wp=00000001,lp=00000000) 08073ff8:Call kernel32.GetLastError() ret=00402238 08073ff8:Ret kernel32.GetLastError() retval=00000578 ret=00402238 08073ff8:Call kernel32.TlsGetValue(00000000) ret=00402246 08073ff8:Ret kernel32.TlsGetValue() retval=429e0100 ret=00402246 08073ff8:Call kernel32.SetLastError(00000578) ret=0040229a 08073ff8:Ret kernel32.SetLastError() retval=00000578 ret=0040229a 08073ff8:Call kernel32.UnhandledExceptionFilter(40464900) ret=0040172a =>0 0x5d30bf01 (HHCTRL.OCX..text+0xaf01 in C:\WINNT\SYSTEM32\HHCTRL.OCX) (ebp=40575064) 1 0x5d34c7b2 (HHCTRL.OCX.DllGetClassObject+0x22159 in C:\WINNT\SYSTEM32\HHCTRL.OCX) (ebp=405760fc) 2 0x406a54db (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=40576120) 3 0x406a557e (WINPROC_CallWndProc+0x8e(proc=0x5d34c6f6, hwnd=0x10022, msg=0x6, wParam=0x1, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=40576150) 4 0x406ab84b (CallWindowProcA+0x3b(func=0x5d34c6f6, hwnd=0x10022, msg=0x6, wParam=0x1, lParam=0x0) [winproc.c:2779] in user32.dll.so) (ebp=40576178) 5 0x406bb830 (call_window_proc+0x100(hwnd=0x10022, msg=0x6, wparam=0x1, lparam=0x0, unicode=0x0) [message.c:1372] in user32.dll.so) (ebp=405761c8) 6 0x406bc4f8 (SendMessageTimeoutA+0xe8(hwnd=0x10022, msg=0x6, wparam=0x1, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x40576250, hwnd=0x10022) [message.c:1784] in user32.dll.so) (ebp=40576220) 7 0x406bc679 (SendMessageA+0x39(hwnd=0x10022, msg=0x6, wparam=0x1, lparam=0x0) [message.c:1829] in user32.dll.so) (ebp=40576254) 8 0x406a4a96 (WINPOS_SetActiveWindow+0x476(hWnd=0x10022, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1359] in user32.dll.so) (ebp=405762a0) 9 0x406a39c1 (SetActiveWindow+0xd1(hwnd=0x10022) [winpos.c:723] in user32.dll.so) (ebp=405762d0) 10 0x406a4cfd (WINPOS_ActivateOtherWindow+0x13d(hwnd=0x10024) [winpos.c:1463] in user32.dll.so) (ebp=405762f0) 11 0x4069f6f6 (DestroyWindow+0x1f6(hwnd=0x10024) [win.c:1504] in user32.dll.so) (ebp=4057630c) 12 0x4069f6b6 (DestroyWindow+0x1b6(hwnd=0x10022) [win.c:1492] in user32.dll.so) (ebp=40576328) 13 0x5d34c141 (HHCTRL.OCX.DllGetClassObject+0x21ae8 in C:\WINNT\SYSTEM32\HHCTRL.OCX) (ebp=4057690c)

1 0

DTR/DSR vs RTS/CTS - followup
by lists＠vmn.com.br 02 Aug '02

02 Aug '02

Hello All, Last week I sent an email about a problem with a serial printer that used DTS/DTR hardware flow control. I later understood that DTS/DTR was not supported in linux , and therefore not in wine. Linux [and wine] support RTS/CTS hardware flow control. Since the protocols are similar, an ideia that I received was to construct a cable that made the computer think it was using RTS/CTS and the printer think it was using DTR/DTS. Today, I received the cable from the printer manufacturer and the initial tests with wine/linux worked. **************************** RTS - Ready To Send CTS - Clear To Send DTR - Data Terminal Ready DSR - Data Set Ready **************************** Here is a snippet of mytestapp --debugmsg +comm trace:comm:COMM_Init COM1 = /dev/ttyS0 trace:comm:COMM_Init LPT1 = /dev/lp0 trace:comm:COMM_Init COM2 = /dev/ttyS1 trace:comm:COMM_Init COM3 = /dev/ttyS2 trace:comm:COMM_Init COM4 = /dev/modem trace:comm:BuildCommDCBAndTimeoutsA (COM2:9600,N,8,1,0x4002af48,(nil)) trace:comm:COMM_BuildOldCommDCB (COM2:9600,N,8,1), ptr 0x4002af48 trace:comm:COMM_BuildOldCommDCB baudrate (9600) trace:comm:COMM_BuildOldCommDCB parity (N) trace:comm:COMM_BuildOldCommDCB charsize (8) trace:comm:COMM_BuildOldCommDCB stopbits (1) trace:comm:SetCommState handle 52, ptr 0x4002af48 trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState CRTSCTS trace:comm:SetCommMask handle 52, mask 10 Thanks every one from wine-devel for all the prompt answers I received. Miguel Feitosa ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

2 1

Compilation error with newer CVS on glibc -2.0
by Martin Cracauer 02 Aug '02

02 Aug '02

Hi, guys, since Jul 20 or so I get this compilation error on glibc-2.1.3/linux-2.4.18: gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o wrc.o wrc.c In file included from wrc.h:25, from wrc.c:61: wrctypes.h:447: redefinition of `struct user' make[2]: *** [wrc.o] Error 1 make[2]: Leaving directory `/disks/part9/home/cracauer/work/cvs-packages-work/stupids/wine/wine/tools/wrc' Wine's definition of struct user is clashing with the one from /usr/include/sys/user.h Now, it appears that /usr/include/sys/user.h (a glibc-2.1.3 file) is in error having this struct in first place, since newer kernels have this struct in asm/user.h. I fixed the problem in my /usr/include, but I guess it is better to use a different name for the struct in Wine to be compatible with this configuration (it's Debian-2.1 with an upgraded kernel). Unless somebody disagrees with that analysis, I'll submit a patch to rename the struct. Suggestions about a suitable name welcome. Martin

2 4

Translation wine documentation to other languages
by Andriy Palamarchuk 01 Aug '02

01 Aug '02

Sorry for crossposting initial message to both lists. I think the topic may be interesting for both - users and developers. Any volunteers to help to translate the documentation to languages other than English? This is very big job, so there can be more than one person, working on the same language. Among responses to my call for volunteers I got response from Pedro Restrepo suggesting his help in Wine localization. See his message below. Damian Wojslaw requested information on the same topic on wine-users. --- Pedro Restrepo <pedrores(a)tutopia.com> wrote: > Hi Andiry, > > First, thank you and thanks to all people working on > Wine. I am using > Wine to run Lotus Notes Client on Linux. At the > moment, we are testing > it. > > I want to help on Wine project. I propose you one > new work: Wine > translation to spanish (documentation, installer, > web site info, etc). I > think in this work because I think this project is > necessary for all > people who need transition tools from Windows to > Linux and there are > many people in this situation in SouthAmerica (I am > from Colombia and I > am tired of the big payments for software in our > poor nations). Currently Wine does not have official documentation in other languages. Some winelib applications are localized to other languages. Documents with highest priority for translation: * README file * Wine User Guide * user-oriented pages on Winehq Plus, we'll need to keep translations in sync with original documentation. Comments, ideas, suggestions? Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

2 1

Re: PATCH: Convert HMIDI to void*
by Eric Pouech 01 Aug '02

01 Aug '02

Michael Stefaniuc a écrit : > > Hello, > > am I right that HMIDI and HMIDIIN, HMIDIOUT shouldn't be > interchangeable? Would save some conversions. > > License: LGPL, X11 > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > Convert HMIDI to a void* I just modified a bit Michael's patch: - better fix for midimap file - changed all HMIDI???? Alexandre, use this version instead. A+ Name: mm_midih ChangeLog: HMIDI??? handles are no long OLD_HANDLE License: X11 GenDate: 2002/08/01 07:11:07 UTC ModifiedFiles: dlls/winmm/lolvldrv.c dlls/winmm/mmsystem.c dlls/winmm/mciseq/mcimidi.c dlls/winmm/midimap/midimap.c include/mmsystem.h AddedFiles: =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/lolvldrv.c,v retrieving revision 1.29 diff -u -u -r1.29 lolvldrv.c --- dlls/winmm/lolvldrv.c 3 Jul 2002 21:10:44 -0000 1.29 +++ dlls/winmm/lolvldrv.c 1 Aug 2002 06:51:25 -0000 @@ -693,7 +693,7 @@ *(LPDWORD)((char*)ptr + sizeof(LPMIDIOPENDESC)) = *lpdwUser; mod16 = (LPMIDIOPENDESC16)((LPSTR)ptr + sizeof(LPMIDIOPENDESC) + 2*sizeof(DWORD)); - mod16->hMidi = mod32->hMidi; + mod16->hMidi = LOWORD(mod32->hMidi); mod16->dwCallback = mod32->dwCallback; mod16->dwInstance = mod32->dwInstance; mod16->dnDevNode = mod32->dnDevNode; Index: dlls/winmm/mmsystem.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/mmsystem.c,v retrieving revision 1.63 diff -u -u -r1.63 mmsystem.c --- dlls/winmm/mmsystem.c 29 Jul 2002 23:29:23 -0000 1.63 +++ dlls/winmm/mmsystem.c 1 Aug 2002 06:51:25 -0000 @@ -2188,7 +2188,7 @@ *lphMidiOut = hMidiOut; if (lpwm) { - lpwm->mod.hMidi = hMidiOut; + lpwm->mod.hMidi = (HMIDI) hMidiOut; lpwm->mod.dwCallback = *lpdwCallback; lpwm->mod.dwInstance = *lpdwInstance; lpwm->mod.dnDevNode = 0; @@ -2739,7 +2739,7 @@ if (lpwm == NULL) return MMSYSERR_NOMEM; - lpwm->mod.hMidi = hMidiIn; + lpwm->mod.hMidi = (HMIDI) hMidiIn; lpwm->mod.dwCallback = dwCallback; lpwm->mod.dwInstance = dwInstance; Index: dlls/winmm/mciseq/mcimidi.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/mciseq/mcimidi.c,v retrieving revision 1.16 diff -u -u -r1.16 mcimidi.c --- dlls/winmm/mciseq/mcimidi.c 31 May 2002 23:40:57 -0000 1.16 +++ dlls/winmm/mciseq/mcimidi.c 1 Aug 2002 06:51:25 -0000 @@ -817,7 +817,7 @@ wmm->dwStatus = MCI_MODE_NOT_READY; if (oldstat == MCI_MODE_PAUSE) - dwRet = midiOutReset(wmm->hMidi); + dwRet = midiOutReset((HMIDIOUT)wmm->hMidi); while (wmm->dwStatus != MCI_MODE_STOP) Sleep(10); @@ -962,7 +962,7 @@ MIDI_mciReadNextEvent(wmm, mmt); /* FIXME == 0 */ } - dwRet = midiOutOpen(&wmm->hMidi, MIDIMAPPER, 0L, 0L, CALLBACK_NULL); + dwRet = midiOutOpen((LPHMIDIOUT)&wmm->hMidi, MIDIMAPPER, 0L, 0L, CALLBACK_NULL); /* dwRet = midiInOpen(&wmm->hMidi, MIDIMAPPER, 0L, 0L, CALLBACK_NULL);*/ if (dwRet != MMSYSERR_NOERROR) { return dwRet; @@ -1142,7 +1142,7 @@ break; default: if (doPlay) { - dwRet = midiOutShortMsg(wmm->hMidi, mmt->dwEventData); + dwRet = midiOutShortMsg((HMIDIOUT)wmm->hMidi, mmt->dwEventData); } else { switch (LOBYTE(LOWORD(mmt->dwEventData)) & 0xF0) { case MIDI_NOTEON: @@ -1150,7 +1150,7 @@ dwRet = 0; break; default: - dwRet = midiOutShortMsg(wmm->hMidi, mmt->dwEventData); + dwRet = midiOutShortMsg((HMIDIOUT)wmm->hMidi, mmt->dwEventData); } } } @@ -1163,9 +1163,9 @@ } } - midiOutReset(wmm->hMidi); + midiOutReset((HMIDIOUT)wmm->hMidi); - dwRet = midiOutClose(wmm->hMidi); + dwRet = midiOutClose((HMIDIOUT)wmm->hMidi); /* to restart playing at beginning when it's over */ wmm->dwPositionMS = 0; @@ -1212,7 +1212,7 @@ midiHdr.dwBufferLength = 1024; midiHdr.dwUser = 0L; midiHdr.dwFlags = 0L; - dwRet = midiInPrepareHeader(wmm->hMidi, &midiHdr, sizeof(MIDIHDR)); + dwRet = midiInPrepareHeader((HMIDIIN)wmm->hMidi, &midiHdr, sizeof(MIDIHDR)); TRACE("After MIDM_PREPARE \n"); wmm->dwStatus = MCI_MODE_RECORD; /* FIXME: there is no buffer added */ @@ -1220,12 +1220,12 @@ TRACE("wmm->dwStatus=%p %d\n", &wmm->dwStatus, wmm->dwStatus); midiHdr.dwBytesRecorded = 0; - dwRet = midiInStart(wmm->hMidi); + dwRet = midiInStart((HMIDIIN)wmm->hMidi); TRACE("midiInStart => dwBytesRecorded=%lu\n", midiHdr.dwBytesRecorded); if (midiHdr.dwBytesRecorded == 0) break; } TRACE("Before MIDM_UNPREPARE \n"); - dwRet = midiInUnprepareHeader(wmm->hMidi, &midiHdr, sizeof(MIDIHDR)); + dwRet = midiInUnprepareHeader((HMIDIIN)wmm->hMidi, &midiHdr, sizeof(MIDIHDR)); TRACE("After MIDM_UNPREPARE \n"); if (midiHdr.lpData != NULL) { HeapFree(GetProcessHeap(), 0, midiHdr.lpData); @@ -1255,7 +1255,7 @@ /* stop all notes */ unsigned chn; for (chn = 0; chn < 16; chn++) - midiOutShortMsg(wmm->hMidi, 0x78B0 | chn); + midiOutShortMsg((HMIDIOUT)(wmm->hMidi), 0x78B0 | chn); wmm->dwStatus = MCI_MODE_PAUSE; } if (lpParms && (dwFlags & MCI_NOTIFY)) { Index: dlls/winmm/midimap/midimap.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/midimap/midimap.c,v retrieving revision 1.13 diff -u -u -r1.13 midimap.c --- dlls/winmm/midimap/midimap.c 31 May 2002 23:40:57 -0000 1.13 +++ dlls/winmm/midimap/midimap.c 1 Aug 2002 06:46:12 -0000 @@ -81,7 +81,7 @@ { char name[MAXPNAMELEN]; int loaded; - HMIDI hMidi; + HMIDIOUT hMidi; unsigned short uDevID; LPBYTE lpbPatch; unsigned int aChn[16]; Index: include/mmsystem.h =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/include/mmsystem.h,v retrieving revision 1.51 diff -u -u -r1.51 mmsystem.h --- include/mmsystem.h 31 May 2002 23:06:48 -0000 1.51 +++ include/mmsystem.h 1 Aug 2002 06:52:49 -0000 @@ -34,10 +34,10 @@ DECLARE_OLD_HANDLE(HWAVE); DECLARE_OLD_HANDLE(HWAVEIN); DECLARE_OLD_HANDLE(HWAVEOUT); -DECLARE_OLD_HANDLE(HMIDI); -DECLARE_OLD_HANDLE(HMIDIIN); -DECLARE_OLD_HANDLE(HMIDIOUT); -DECLARE_OLD_HANDLE(HMIDISTRM); +DECLARE_HANDLE(HMIDI); +DECLARE_HANDLE(HMIDIIN); +DECLARE_HANDLE(HMIDIOUT); +DECLARE_HANDLE(HMIDISTRM); DECLARE_OLD_HANDLE(HMIXER); DECLARE_OLD_HANDLE(HMIXEROBJ); DECLARE_OLD_HANDLE(HMMIO);

3 2

Netbios and Wins support
by Claudiu Costin 01 Aug '02

01 Aug '02

Dear friends, Is there anybody working on Netbios/MS Windows Network support? I want to run Outlook with Exchange. I can help testing and hacking, but not writing real code. kind regards, -- Claudiu Costin, claudiuc(a)kde.org Linux-KDE Romania http://www.ro.kde.org

2 1

Re: PATCH: Convert HMIDI to void*
by Eric Pouech 31 Jul '02

31 Jul '02

Michael Stefaniuc a écrit : > > Hello, > > am I right that HMIDI and HMIDIIN, HMIDIOUT shouldn't be > interchangeable? Would save some conversions. yes & no HMIDIIN cannot be used for a HMIDIOUT (anyway, this will be checked internally by our mmsys implementation: all HMIDI???? handles are stored in the same table, and we never rely on the HMIDI??? handle type but on the actual object type) however, HMIDI can be used for a HMIDIIN (or HMIDIOUT or HMIDISTRM) handle (see midiConnect for example) it's true that midimap dll should use HMIDIOUT instead of HMIDI in its internal data structure A+

3 4

Toolbar redraw problem
by dusanv 31 Jul '02

31 Jul '02

Hi, I am seeing a bunch of apps have redrawing problems when a toolbar is dragged accross the window. Here's a screen shot: http://dusanv.net/files/wine-ss.png Does anyone have any info on this? I'd like to fix it but can't find anyhting relevant. TIA, Dusan

2 2

Re: PATCH: a bit further with a cygwin build (fixed patch)
by Francois Gouget 31 Jul '02

31 Jul '02

On Tue, 30 Jul 2002, Rafael Kitover wrote: > Sorry, due to brain-deadness on my part the previous version of this > patch didn't build properly. This version is much cleaner and builds > properly on linux. > +#ifndef HAVE__FSTAT > int _fstat(int fd, struct _stat* buf) > +#else > +int MSVCRT(_fstat)(int fd, struct _stat* buf) > +#endif /* HAVE__FSTAT */ ... > +#ifndef HAVE__STAT > int _stat(const char* path, struct _stat * buf) > +#else > +int MSVCRT(_stat)(const char* path, struct _stat * buf) > +#endif /* HAVE__STAT */ You should systematically use MSVCRT(_fstat) and MSVCRT(_stat). Your previous patch was better :-) Basically, we use MSVCRT(xxx) for all symbols for which we may get a conflict with the native C library headers. On Unix systyems, the _xxx functions are never defined (though there may be a couple of exceptions) so we don't use MSVCRT() for readability's sake. But if you find a system where there is a conflict, then it's best to just systematically use MSVCRT() than to use ifdefs that make it even harder to read. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

1 0

dos console apps question
by Chris Morgan 30 Jul '02

30 Jul '02

Lately I've been trying to get some dos console apps running under wine. These apps run great under wineconsole but not so much just under wine due to the lack of a server side console for the routines in dlls/msdos/vga.c to output too. So, after poking all around it seems that at some point during the normal loading of an app that we should be calling out to the server with alloc_console to create a default console, and binding this console to the current terminal. Does anyone have any suggestions about this? What function this should be done in? Thanks, Chris

4 3

Re: Toolbar redraw problem
by Dusan Vujosevic 30 Jul '02

30 Jul '02

I will add a bit later today it and put in the test app as well. Thanks, D. > > >---- Original Message ---- >From: galberte(a)neo.lrun.com >To: dusanv(a)cadlink.com, wine-devel(a)winehq.com >Subject: Re: Toolbar redraw problem >Date: Mon, 29 Jul 2002 21:09:06 -0400 > >> >>----- Original Message ----- >>From: "dusanv" <dusanv(a)cadlink.com> >>To: "wine-devel" <wine-devel(a)winehq.com> >>Sent: Monday, July 29, 2002 4:27 PM >>Subject: Toolbar redraw problem >> >> >>> Hi, >>> >>> I am seeing a bunch of apps have redrawing problems when a toolbar >is >>> dragged accross the window. Here's a screen shot: >>> >>> http://dusanv.net/files/wine-ss.png >>> >>> Does anyone have any info on this? I'd like to fix it but can't >find >>> anyhting relevant. >>> >> >>Could you please create a bug in Wine's Bugzilla >http://bugs.winehq.com/. >> >>And if that is a test program, that would be good to ad also. I >suspect that >>somewhere during the drag operation, the rectangle invalidated does >not >>contain the edges. It will be fun to find. >> >>Thanks, >>Guy >> >> >> >>

1 0

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