wine-devel February 2004

wine-devel@winehq.org

132 participants
261 discussions

NdrClientCall/format string interpreter/stubless proxies
by Mike Hearn 26 Feb '04

26 Feb '04

Hi Rob, A few weeks back you mentioned you had done some work on implementing the stubless proxy entry points - can you explain a bit more about this? In particular, how far away are you from having something submittable, have you got docs on the format string syntax and how much are you intending to implement? thanks -mike

1 0

Re: crosstest compile fix (another)
by Hans Leidekker 26 Feb '04

26 Feb '04

On Sunday 22 February 2004 15:17, Stefan Leichter wrote: > as pointed out from Hans Leidekker (http://www.winehq.org/hypermail/ > wine-devel/2004/02/0448.html) mingw misses some GUID in its header files Well, it was a patch to MinGW and I don't think we should work around this shortcoming of MinGW by patching Wine. On the other hand, MinGW is still not useful for us even if we're sending them patches to fix things every now and then. That, and the poor or outdated state of MinGW RPM packages, and the plans for a PE build of Wine lead me to ask myself the question 'Why don't we build our own MinGW cross compiler packages?' That way we could have a working MinGW on RPM based distros as well and we can throw in couple of patches of our own to make it useful for compiling Wine. Not to create a fork of course, but more like what Redhat does, i.e. still trying to get patches accepted upstream. I have been working on these RPMS already and plan on putting up a page somewhere shortly. Initial goal is to compile all Wine tests out of the box. -Hans

4 8

Re: LOCALE: Don't copy value if buffer is too small
by Alexandre Julliard 26 Feb '04

26 Feb '04

Fabian Cenedese <Cenedese(a)indel.ch> writes: > Ok, I saw that you fixed the WCHAR/byte mess. But there is still a possibility that > the function can copy a string longer than buffer if it already has an appended null. That shouldn't happen, NtQueryValue should have signaled an overflow in that case. Do you have a test case showing the problem? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Native NetBSD audio driver
by Yorick Hardy 26 Feb '04

26 Feb '04

I was thinking to look at the integration of the oss and NetBSD drivers this weekend (following Eric and Dimi's suggestion). Should I rather wait until some restructuring is done? The inclusion of the NetBSD audio driver is not urgent since oss already works quite well, and it stagnated on my hard disk for months before I submitted anyway. I am not going to volunteer for the restructuring since I have a long overdue thesis to finish ;-). >> I think it might be worthwhile considering restructuring the audio >> drivers into hardware independent wave, direct sound, midi >> and mixer sections and a hardware dependent low level >> implementation for oss, alsa, ... > >Yes we should definitely do something like that. This sound driver >business is becoming a huge mess. Kind regards, Yorick Hardy. -------------------------------------------------------- This message was sent using MetroWEB's AirMail service. http://www.metroweb.co.za/ - full access for only R59. Free WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails Phone Now! 086 11 11 440

1 0

Re: DCE: LockWindowUpdate
by Mike Hearn 25 Feb '04

25 Feb '04

Hi Ken, I'm really sorry about this but I already implemented LockWindowUpdate about a month or two ago. Unfortunately it is blocking on moving invalidation handling into the wineserver, and was not applied. So, I'm afraid that (a) the work has already been done and (b) the patch you sent, is wrong. I made the same mistake at first - unfortunately LockWindowUpdate is a global thing, ie the locked window is held in-kernel on Windows. Alexandre: I said at the time we should apply the patch I sent but disable it, so it doesn't get lost/forgotten about. Here's another reason we should do that - it'll stop people reimplementing what has already been done. thanks -mike On Wed, 25 Feb 2004 13:28:19 -0500, Ken Belleau wrote: > When there is a locked window, GetDCEx and related functions now returns > DCs with an empty visible region unless DCX_LOCKWINDOWUPDATE is > specified.

2 1

re: dialog:MSGBOX_OnInit
by Dan Kegel 25 Feb '04

25 Feb '04

vishal_wable(a)yahoo.com wrote: > I am trying to run a MFC application in Red Hat Linux 8 using WINE (latest > version). > > When i start the application with wine the application performs some intialization > but when the main window is about to be displayed, the application crashes giving > the following error. > > " fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet" > > The application contains splitter windows and a CGfxOutBar Control. > > There are a couple of modaless dialog boxes that are displayed on the main screen > when the application starts. > > I am compiling the exe in Visual Studio and then running it using wine in LINUX. That message isn't the root of your problem, I bet. http://www.winehq.com/site/documentation has info that might help you. The most common way to proceed is to figure out where the crash by turning on more verbose logging with --debugmsg options; see http://www.winehq.com/site/docs/wine-user/command-line-options#CONFIG-PARAM… Also, there's a way to use Visual Studio's debugger with Wine remotely, but I can't see where that's documented. (Hey, can anyone who knows how to do this point us to the doc?) - Dan -- US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/

2 1

Re: Switch kernel time functions to the new "time" debug channel
by Dimitrie O. Paun 25 Feb '04

25 Feb '04

On Wed, 25 Feb 2004, Mike Hearn wrote: > Another confusing debug channel allocation bites the dust... > > -WINE_DEFAULT_DEBUG_CHANNEL(win32); > +WINE_DEFAULT_DEBUG_CHANNEL(time); The win32 debug channel should just die, it's too generic to be useful. The entire friggin' API is Win32 :) Here is a patch that nukes it. ChangeLog Dimitrie O. Paun <dpaun(a)rogers.com> Remove the win32 debug channel, misc cleanup of debugging code. Index: ./dlls/kernel/sync.c =================================================================== RCS file: /var/cvs/wine/dlls/kernel/sync.c,v retrieving revision 1.48 diff -u -r1.48 sync.c --- ./dlls/kernel/sync.c 24 Feb 2004 01:06:30 -0000 1.48 +++ ./dlls/kernel/sync.c 25 Feb 2004 17:16:48 -0000 @@ -52,7 +52,7 @@ #include "wine/debug.h" -WINE_DEFAULT_DEBUG_CHANNEL(win32); +WINE_DEFAULT_DEBUG_CHANNEL(sync); /* check if current version is NT or Win95 */ inline static int is_version_nt(void) Index: ./dlls/kernel/syslevel.c =================================================================== RCS file: /var/cvs/wine/dlls/kernel/syslevel.c,v retrieving revision 1.3 diff -u -r1.3 syslevel.c --- ./dlls/kernel/syslevel.c 5 Nov 2003 00:52:30 -0000 1.3 +++ ./dlls/kernel/syslevel.c 25 Feb 2004 17:17:16 -0000 @@ -35,7 +35,7 @@ #include "wine/library.h" #include "wine/debug.h" -WINE_DEFAULT_DEBUG_CHANNEL(win32); +WINE_DEFAULT_DEBUG_CHANNEL(syslevel); static SYSLEVEL Win16Mutex; static CRITICAL_SECTION_DEBUG critsect_debug = Index: ./dlls/msnet32/msnet_main.c =================================================================== RCS file: /var/cvs/wine/dlls/msnet32/msnet_main.c,v retrieving revision 1.2 diff -u -r1.2 msnet_main.c --- ./dlls/msnet32/msnet_main.c 14 Mar 2003 23:00:53 -0000 1.2 +++ ./dlls/msnet32/msnet_main.c 25 Feb 2004 17:17:44 -0000 @@ -18,7 +18,7 @@ #include "wine/debug.h" -WINE_DEFAULT_DEBUG_CHANNEL(win32); +WINE_DEFAULT_DEBUG_CHANNEL(msnet); /*********************************************************************** * @ (MSNET32.57) Index: ./dlls/wintrust/wintrust_main.c =================================================================== RCS file: /var/cvs/wine/dlls/wintrust/wintrust_main.c,v retrieving revision 1.5 diff -u -r1.5 wintrust_main.c --- ./dlls/wintrust/wintrust_main.c 5 Sep 2003 23:08:26 -0000 1.5 +++ ./dlls/wintrust/wintrust_main.c 25 Feb 2004 17:18:19 -0000 @@ -27,7 +27,7 @@ #include "wine/debug.h" -WINE_DEFAULT_DEBUG_CHANNEL(win32); +WINE_DEFAULT_DEBUG_CHANNEL(wintrust); /*********************************************************************** * WinVerifyTrust (WINTRUST.@) Index: ./windows/user.c =================================================================== RCS file: /var/cvs/wine/windows/user.c,v retrieving revision 1.99 diff -u -r1.99 user.c --- ./windows/user.c 5 Feb 2004 01:24:48 -0000 1.99 +++ ./windows/user.c 25 Feb 2004 17:26:43 -0000 @@ -38,11 +38,7 @@ #include "local.h" #include "wine/debug.h" -WINE_DECLARE_DEBUG_CHANNEL(hook); -WINE_DECLARE_DEBUG_CHANNEL(local); -WINE_DECLARE_DEBUG_CHANNEL(system); -WINE_DECLARE_DEBUG_CHANNEL(win); -WINE_DECLARE_DEBUG_CHANNEL(win32); +WINE_DEFAULT_DEBUG_CHANNEL(system); static SYSLEVEL USER_SysLevel; static CRITICAL_SECTION_DEBUG critsect_debug = @@ -113,7 +109,7 @@ break; } FreeLibrary16( gdi_inst ); - TRACE_(local)("<- userPercent %d, gdiPercent %d\n", userPercent, gdiPercent); + TRACE("<- userPercent %d, gdiPercent %d\n", userPercent, gdiPercent); return (WORD)min( userPercent, gdiPercent ); } @@ -271,8 +267,8 @@ WORD WINAPI UserSignalProc( UINT uCode, DWORD dwThreadOrProcessID, DWORD dwFlags, HMODULE16 hModule ) { - FIXME_(win)("(%04x, %08lx, %04lx, %04x)\n", - uCode, dwThreadOrProcessID, dwFlags, hModule ); + FIXME("(%04x, %08lx, %04lx, %04x)\n", + uCode, dwThreadOrProcessID, dwFlags, hModule ); /* FIXME: Should chain to GdiSignalProc now. */ return 0; } @@ -291,8 +287,8 @@ */ BOOL16 WINAPI ExitWindowsExec16( LPCSTR lpszExe, LPCSTR lpszParams ) { - TRACE_(system)("Should run the following in DOS-mode: \"%s %s\"\n", - lpszExe, lpszParams); + TRACE("Should run the following in DOS-mode: \"%s %s\"\n", + lpszExe, lpszParams); return ExitWindowsEx( EWX_LOGOFF, 0xffffffff ); } @@ -481,7 +477,7 @@ ) { if (i) return FALSE; - FIXME_(system)("(%p,%ld,%p,0x%08lx), stub!\n",unused,i,lpDisplayDevice,dwFlags); + FIXME("(%p,%ld,%p,0x%08lx), stub!\n",unused,i,lpDisplayDevice,dwFlags); strcpy(lpDisplayDevice->DeviceName,"X11"); strcpy(lpDisplayDevice->DeviceString,"X 11 Windowing System"); lpDisplayDevice->StateFlags = @@ -499,7 +495,7 @@ ) { if (i) return FALSE; - FIXME_(system)("(%p,%ld,%p,0x%08lx), stub!\n",unused,i,lpDisplayDevice,dwFlags); + FIXME("(%p,%ld,%p,0x%08lx), stub!\n",unused,i,lpDisplayDevice,dwFlags); MultiByteToWideChar( CP_ACP, 0, "X11", -1, lpDisplayDevice->DeviceName, sizeof(lpDisplayDevice->DeviceName)/sizeof(WCHAR) ); MultiByteToWideChar( CP_ACP, 0, "X11 Windowing System", -1, lpDisplayDevice->DeviceString, @@ -518,7 +514,7 @@ */ FARPROC16 WINAPI SetEventHook16(FARPROC16 lpfnEventHook) { - FIXME_(hook)("(lpfnEventHook=%08x): stub\n", (UINT)lpfnEventHook); + FIXME("(lpfnEventHook=%08x): stub\n", (UINT)lpfnEventHook); return NULL; } @@ -538,10 +534,10 @@ case USUD_LOCALHEAP: return USER_HeapSel; case USUD_FIRSTCLASS: - FIXME_(local)("return a pointer to the first window class.\n"); + FIXME("return a pointer to the first window class.\n"); return (DWORD)-1; default: - WARN_(local)("wReqType %04x (unknown)\n", wReqType); + WARN("wReqType %04x (unknown)\n", wReqType); return (DWORD)-1; } } @@ -558,7 +554,7 @@ * RegisterLogonProcess (USER32.@) */ DWORD WINAPI RegisterLogonProcess(HANDLE hprocess,BOOL x) { - FIXME_(win32)("(%p,%d),stub!\n",hprocess,x); + FIXME("(%p,%d),stub!\n",hprocess,x); return 1; } @@ -569,7 +565,7 @@ LPWSTR winstation,DWORD res1,DWORD desiredaccess, LPSECURITY_ATTRIBUTES lpsa ) { - FIXME_(win32)("(%s,0x%08lx,0x%08lx,%p),stub!\n",debugstr_w(winstation), + FIXME("(%s,0x%08lx,0x%08lx,%p),stub!\n",debugstr_w(winstation), res1,desiredaccess,lpsa ); return (HWINSTA)0xdeadcafe; @@ -579,7 +575,7 @@ * SetProcessWindowStation (USER32.@) */ BOOL WINAPI SetProcessWindowStation(HWINSTA hWinSta) { - FIXME_(win32)("(%p),stub!\n",hWinSta); + FIXME("(%p),stub!\n",hWinSta); return TRUE; } @@ -591,7 +587,7 @@ PSECURITY_INFORMATION pSIRequested, PSECURITY_DESCRIPTOR pSID ) { - FIXME_(win32)("(%p,%p,%p),stub!\n",hObj,pSIRequested,pSID); + FIXME("(%p,%p,%p),stub!\n",hObj,pSIRequested,pSID); return TRUE; } @@ -602,7 +598,7 @@ LPSTR lpszDesktop,LPSTR lpszDevice,LPDEVMODEA pDevmode, DWORD dwFlags,DWORD dwDesiredAccess,LPSECURITY_ATTRIBUTES lpsa ) { - FIXME_(win32)("(%s,%s,%p,0x%08lx,0x%08lx,%p),stub!\n", + FIXME("(%s,%s,%p,0x%08lx,0x%08lx,%p),stub!\n", lpszDesktop,lpszDevice,pDevmode, dwFlags,dwDesiredAccess,lpsa ); @@ -616,7 +612,7 @@ LPWSTR lpszDesktop,LPWSTR lpszDevice,LPDEVMODEW pDevmode, DWORD dwFlags,DWORD dwDesiredAccess,LPSECURITY_ATTRIBUTES lpsa ) { - FIXME_(win32)("(%s,%s,%p,0x%08lx,0x%08lx,%p),stub!\n", + FIXME("(%s,%s,%p,0x%08lx,0x%08lx,%p),stub!\n", debugstr_w(lpszDesktop),debugstr_w(lpszDevice),pDevmode, dwFlags,dwDesiredAccess,lpsa ); @@ -627,7 +623,7 @@ * EnumDesktopWindows (USER32.@) */ BOOL WINAPI EnumDesktopWindows( HDESK hDesktop, WNDENUMPROC lpfn, LPARAM lParam ) { - FIXME_(win32)("(%p, %p, 0x%08lx), stub!\n", hDesktop, lpfn, lParam ); + FIXME("(%p, %p, 0x%08lx), stub!\n", hDesktop, lpfn, lParam ); return TRUE; } @@ -637,7 +633,7 @@ */ BOOL WINAPI CloseWindowStation(HWINSTA hWinSta) { - FIXME_(win32)("(%p)\n", hWinSta); + FIXME("(%p)\n", hWinSta); return TRUE; } @@ -646,7 +642,7 @@ */ BOOL WINAPI CloseDesktop(HDESK hDesk) { - FIXME_(win32)("(%p)\n", hDesk); + FIXME("(%p)\n", hDesk); return TRUE; } @@ -654,7 +650,7 @@ * SetWindowStationUser (USER32.@) */ DWORD WINAPI SetWindowStationUser(DWORD x1,DWORD x2) { - FIXME_(win32)("(0x%08lx,0x%08lx),stub!\n",x1,x2); + FIXME("(0x%08lx,0x%08lx),stub!\n",x1,x2); return 1; } @@ -662,7 +658,7 @@ * SetLogonNotifyWindow (USER32.@) */ DWORD WINAPI SetLogonNotifyWindow(HWINSTA hwinsta,HWND hwnd) { - FIXME_(win32)("(%p,%p),stub!\n",hwinsta,hwnd); + FIXME("(%p,%p),stub!\n",hwinsta,hwnd); return 1; } @@ -677,14 +673,14 @@ * GetUserObjectInformationA (USER32.@) */ BOOL WINAPI GetUserObjectInformationA( HANDLE hObj, INT nIndex, LPVOID pvInfo, DWORD nLength, LPDWORD lpnLen ) -{ FIXME_(win32)("(%p %i %p %ld %p),stub!\n", hObj, nIndex, pvInfo, nLength, lpnLen ); +{ FIXME("(%p %i %p %ld %p),stub!\n", hObj, nIndex, pvInfo, nLength, lpnLen ); return TRUE; } /*********************************************************************** * GetUserObjectInformationW (USER32.@) */ BOOL WINAPI GetUserObjectInformationW( HANDLE hObj, INT nIndex, LPVOID pvInfo, DWORD nLength, LPDWORD lpnLen ) -{ FIXME_(win32)("(%p %i %p %ld %p),stub!\n", hObj, nIndex, pvInfo, nLength, lpnLen ); +{ FIXME("(%p %i %p %ld %p),stub!\n", hObj, nIndex, pvInfo, nLength, lpnLen ); return TRUE; } /*********************************************************************** @@ -692,7 +688,7 @@ */ BOOL WINAPI GetUserObjectSecurity(HANDLE hObj, PSECURITY_INFORMATION pSIRequested, PSECURITY_DESCRIPTOR pSID, DWORD nLength, LPDWORD lpnLengthNeeded) -{ FIXME_(win32)("(%p %p %p len=%ld %p),stub!\n", hObj, pSIRequested, pSID, nLength, lpnLengthNeeded); +{ FIXME("(%p %p %p len=%ld %p),stub!\n", hObj, pSIRequested, pSID, nLength, lpnLengthNeeded); return TRUE; } @@ -700,7 +696,7 @@ * SetSystemCursor (USER32.@) */ BOOL WINAPI SetSystemCursor(HCURSOR hcur, DWORD id) -{ FIXME_(win32)("(%p,%08lx),stub!\n", hcur, id); +{ FIXME("(%p,%08lx),stub!\n", hcur, id); return TRUE; } @@ -709,15 +705,14 @@ */ void WINAPI RegisterSystemThread(DWORD flags, DWORD reserved) { - FIXME_(win32)("(%08lx, %08lx)\n", flags, reserved); + FIXME("(%08lx, %08lx)\n", flags, reserved); } /*********************************************************************** * RegisterDeviceNotificationA (USER32.@) */ -HDEVNOTIFY WINAPI RegisterDeviceNotificationA( - HANDLE hnd, LPVOID notifyfilter, DWORD flags -) { - FIXME_(win32)("(hwnd=%p, filter=%p,flags=0x%08lx), STUB!\n", hnd,notifyfilter,flags ); +HDEVNOTIFY WINAPI RegisterDeviceNotificationA(HANDLE hnd, LPVOID notifyfilter, DWORD flags) +{ + FIXME("(hwnd=%p, filter=%p,flags=0x%08lx), STUB!\n", hnd,notifyfilter,flags ); return 0; } -- Dimi.

1 0

VB-Error: Type mismatch
by Fabian Cenedese 25 Feb '04

25 Feb '04

Hi Who invented VB...? Ah yeah, right... I'm trying (again) to run a VB app on wine. But it never shows up. Instead I only see a dialog with this Type mismatch error and then it quits. I tried to find the place where it goes wrong. Apparently it tries to parse a number from a string in VB notation. 0009:trace:ole:VarParseNumFromStr (L"&H8000",1024,0x00000000,0x408bdee0,0x408bdae0) With my own debug messages I found that it bails out with this reason: ole:VarParseNumFromStr: Not all chars were consumed This leads to a nice exception which is caught from the VB dll: 0009:Call kernel32.RaiseException(c000008f,00000001,00000002,408be0c8) ret=6a87479d 0009:trace:seh:EXC_RtlRaiseException code=c000008f flags=1 addr=0x404b9b30 0009:trace:seh:EXC_RtlRaiseException info[0]=deadcafe 0009:trace:seh:EXC_RtlRaiseException info[1]=deadcafe 0009:trace:seh:EXC_RtlRaiseException eax=408bdf70 ebx=4057691c ecx=00000000 edx=00000004 esi=408be0d0 edi=408bdf8c 0009:trace:seh:EXC_RtlRaiseException ebp=408bdfcc esp=408bdf70 cs=0023 ds=002b es=002b fs=1007 gs=0000 flags=00000212 0009:trace:seh:EXC_CallHandler calling handler at 0x11004246 code=c000008f flags=1 0009:CALL MSVBVM60.__vbaExceptHandler(<unknown, check return>(0x40340000,00000002,00000040): returning 42b4c020 ) ret=401cac8b And this in return presents me the nice error dialog. 0009:trace:resource:LoadStringW L"Type mismatch" loaded ! Is this function VarParseNumFromStr supposed to understand VB notation as well? The docs from MS I found don't say anything about how the numbers have to be formed to be parsed well. In a small test program in C I only got the same result on Windows for these parameters. So the implementation seems ok so far. But then where did this string come from? Some property? 0009:Call oleaut32.SysAllocStringLen(42b4b70c L"FontColor",00000009) ret=6a939fac 0009:trace:heap:RtlAllocateHeap (0x40340000,00000002,00000018): returning 42b4b6a8 0009:Ret oleaut32.SysAllocStringLen() retval=42b4b6ac ret=6a939fac 0009:Call user32.CharUpperBuffW(42b4b6ac L"FontColor",0000000a) ret=6a934b66 0009:Ret user32.CharUpperBuffW() retval=0000000a ret=6a934b66 0009:RET MSVBVM60.rtcUpperCaseVar() retval=408be230 ret=1102ff69 0009:CALL MSVBVM60.__vbaVarTstEq(408be1e0,408be230) ret=1102ff8e 0009:Call oleaut32.VarCmp(408be230,408be1e0,00000000,00030001) ret=6a94f05b 0009:trace:ole:VarCmp (0x408be230->(VT_BSTR),0x408be1e0->(VT_BSTR|VT_HARDTYPE),0x00000000,0x00030001) 0009:trace:ole:VariantInit (0x408bdff8) 0009:trace:ole:VariantInit (0x408be008) 0009:Call kernel32.CompareStringW(00000000,00030001,42b4b6ac L"FONTCOLOR",ffffffff,1100b858 L"VALUE",ffffffff) ret=40c164be 0009:Ret kernel32.CompareStringW() retval=00000001 ret=40c164be 0009:Ret oleaut32.VarCmp() retval=00000000 ret=6a94f05b 0009:RET MSVBVM60.__vbaVarTstEq() retval=00000000 ret=1102ff8e 0009:CALL MSVBVM60.__vbaFreeVar() ret=1102ff96 0009:Call oleaut32.SysFreeString(42b4b6ac L"FONTCOLOR") ret=6a94f0df 0009:trace:heap:RtlFreeHeap (0x40340000,00000002,42b4b6a8): returning TRUE 0009:Ret oleaut32.SysFreeString() retval=00000001 ret=6a94f0df 0009:RET MSVBVM60.__vbaFreeVar() retval=00000001 ret=1102ff96 0009:CALL MSVBVM60.rtcMidCharVar(408be220,408be1f0,00000003,408be230) ret=1102ffff 0009:Call oleaut32.SysAllocStringByteLen(42b4bfb8,00000008) ret=6a8742d9 0009:trace:heap:RtlAllocateHeap (0x40340000,00000002,00000018): returning 42b4b6a8 0009:Ret oleaut32.SysAllocStringByteLen() retval=42b4b6ac ret=6a8742d9 0009:RET MSVBVM60.rtcMidCharVar() retval=408be220 ret=1102ffff 0009:CALL MSVBVM60.__vbaVarCat(408be210,408be220,408be1d0) ret=11030014 0009:Call oleaut32.VarCat(408be1d0,408be220,408be210) ret=6a938e10 0009:trace:ole:VarCat (0x408be1d0->(VT_BSTR),0x408be220->(VT_BSTR),0x408be210) 0009:trace:heap:RtlAllocateHeap (0x40340000,00000002,00000018): returning 42b4bfd0 VARIANT: VarCat: L"&H"+L"8000"=L"&H8000" and so on I know that color properties can have standard system values which start with &H8000... But is this the reason? And why does this get into VarParseNumFromStr? Thanks bye Fabi

2 4

Theming widgets
by Kevin Koltzau 25 Feb '04

25 Feb '04

I'm starting to work on theming some widgets, and I've come up with a few methods of doing this: 1) Add theming code to every widget itself, static link to uxtheme.dll 2) Add theming code to every widget itself, using LoadLibrary/GetProcAddress 3) Subclass widgets when uxtheme.dll is loaded and override default painting Windows takes a totally different approach, using a different version of common controls that implement theming, under windows in order to enable theming you first need a manifest to load the proper version of comctrl32 then you also must call InitCommonControls which registers the standard controls (BUTTON,EDIT,etc) Going with that, I think #3 might be the best option, and extend InitCommonControls to subclass the standard controls if theming is enabled Any comments/suggestions?

2 2

dialog:MSGBOX_OnInit
by vishal wable 25 Feb '04

25 Feb '04

Hello Sir, I am trying to run a MFC application in Red Hat Linux 8 using WINE (latest version). When i start the application with wine the application performs some intialization but when the main window is about to be displayed, the application crashes giving the following error. " fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet" The application contains splitter windows and a CGfxOutBar Control. There are a couple of modaless dialog boxes that are displayed on the main screen when the application starts. I am compiling the exe in Visual Studio and then running it using wine in LINUX. Could you please help me to solve this problem. Regards, Vishal Wable --------------------------------- Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want.

1 0

Document Crosstest
by Uwe Bonnes 25 Feb '04

25 Feb '04

Hallo, http://www.winehq.com/site/docs/wine-devel/testing-windows 4.5.3. With MinGW should read: Have mingw installed. For an RPM package look e.g. at http://mirzam.it.vu.nl/mingw/ Run "make crosstest". Run test like "wine -- msvcrt_crosstest.exe scanf.c" on wine or "msvcrt_crosstest.exe scanf.c" on windows -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: More msvcrt scanf tests
by Alexandre Julliard 25 Feb '04

25 Feb '04

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > + todo_wine ok(strstr(buffer,"e+008") != 0,"Sprintf different \"%s\"\n",buffer); > + sprintf(buffer,I64x,(ULONGLONG)0xffffffffffffffff); Long long constants are not portable, you need to compute them from long constants. -- Alexandre Julliard julliard(a)winehq.org

5 9

RFC: OlePicture patch
by Fabian Cenedese 25 Feb '04

25 Feb '04

Hi Can anybody comment on this? http://www.winehq.org/hypermail/wine-patches/2004/02/0121.html I know that it's not the best solution (or if it is it's without explanation). I tried to find anything about this magic number but I found nothing. Unless someone has a reason _not_ to apply it I vote in favour of it. It helps VB programs with the SSTab control without pictures assigned to the tabs to load properly. As there are no pictures it shouldn't read more data from the stream and try to create a picture with wrong data. Thanks bye Fabi

1 0

Fun quickfix
by Mike Hearn 25 Feb '04

25 Feb '04

Hi, Here's an easy to fix bug for somebody wanting to get into Wine hacking, or who has a spare few minutes. The basic problem is with the tab control and can be seen by running http://bylands.dur.ac.uk/~mh/Tab.exe ... that (from control spy). As you can see on the bottom row, the top of the tabs are overdrawn by the row above. Putting a Sleep call into the tab drawing code reveals that we're not drawing the tabs in any particular order (presumably it's the order they were added) and reading the code indicates that having TAB_DrawItem overdraw its bottom is the expected behaviour. The code can be seen in dlls/comctl32/tab.c, in TAB_Refresh and TAB_DrawItem One fix is to draw the tabs from top row to the bottom, instead of in a random order. In order to do that, you need to read the code in TAB_SetItemBounds and add a new field to TAB_ITEM to record which row it was placed in. Then, in TAB_Refresh, firstly sort the TAB_ITEMS topmost to bottommost before drawing them. This shouldn't be too hard, but would fix a nasty visual glitch in Wine. If anybody feels like doing it but gets stuck feel free to ask here for help. On the other hand if you're an old hand at Wine feel free to fix it too, there's little point keeping bugs around for training purposes :) thanks -mike

3 2

Re: Pipe tests coprrected
by Ferenc Wagner 25 Feb '04

25 Feb '04

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > dlls/kernel/tests/pipe.c > Added tests for redirected STDIN/STDOUT > Added todo_wine test for waiting on closed pipe > > The tests now succeed on NT40(vmware) They do on XP, too. The MinGW-compiled binary now won't run from a network drive. Also, test 3 of 7 loops, so I didn't run it. Apart from that, the report goes like below. -- Feri. pipe.c:823:test 1 of 7: pipe.c:645: Test failed: CreateNamedPipe failed pipe.c:647: Test failed: WriteFile to not-yet-connected pipe pipe.c:649: Test failed: ReadFile from not-yet-connected pipe pipe.c:653: Test failed: CreateFile failed pipe.c:673: Test failed: CloseHandle pipe.c:825:test 2 of 7: pipe.c:264: Test failed: CreateNamedPipe failed pipe.c:272: Test failed: CreateNamedPipe failed pipe.c:274: Test failed: CloseHandle pipe.c:275: Test failed: CloseHandle pipe.c:284: Test failed: CreateNamedPipe failed pipe.c:292: Test failed: nMaxInstances not obeyed pipe.c:295: Test failed: CloseHandle pipe.c:304: Test failed: CreateNamedPipe failed pipe.c:312: Test failed: PIPE_ACCESS_* mismatch allowed pipe.c:315: Test failed: CloseHandle pipe.c:827:test 3 of 7: should be fixed pipe.c:829:test 4 of 7: pipe.c:149:test_CreateNamedPipe starting pipe.c:174: Test failed: connecting to nonexistent named pipe should fail with ERROR_FILE_NOT_FOUND pipe.c:186: Test failed: CreateNamedPipe failed pipe.c:189: Test failed: CreateFile failed pipe.c:248: Test failed: CloseHandle pipe.c:250:test_CreateNamedPipe returning pipe.c:831:test 5 of 7: pipe.c:833:test 6 of 7: pipe.c:835:all tests done pipe: 44 tests executed, 0 marked as todo, 19 failures.

1 0

buffer too small for currency
by Fabian Cenedese 24 Feb '04

24 Feb '04

Hi I get this warning when I try to start a basic program. This comes from the function VARIANT_GetLocalisedNumberChars. I added some printfs and found that my currency is apparently "SFr.", so 4 chars plus zero which is too much for the 4 char buffer. Strange though that on the command line it looks differently: locale -k LC_MONETARY int_curr_symbol="CHF " currency_symbol="Fr." mon_decimal_point="." mon_thousands_sep=" " mon_grouping=3;3 ... Anyway, I thought I increase this buffer. But then the string gets stored in two separate variables (each one char) in the VARIANT_NUMBER_CHARS struct. Is there a reason that this is not a string? Why only two chars? Thanks bye Fabi

3 4

WineGuru
by Dimitrie O. Paun 24 Feb '04

24 Feb '04

Hi Boaz, I've looked at the potato-factory, and to be honest I don't like the interface. The very fact that I have to logon before I can see anything makes it fairly useless for me. Now, before and put in too much infrastructure, I think we can start small as follows: -- have people submit material to wine-devel -- various folks (volunteers needed) will collect them and post them in a nice, orderly manner to a special area (TBD) on WineHQ This has the advantage of being a lot more controlled, and I'm sure the editorial review will pay off. If the volume becomes too big, we can consider in the future to automate the process. But until then, I think the manual approach is better. -- Dimi.

3 2

Mixing native and bulitin DLL (MSVCRT)
by Uwe Bonnes 24 Feb '04

24 Feb '04

Hallo, I am trying to debug a problem with builtin MSVCRT. Is there any easy way to deviate calls from builtin msvcrt to native msvcrt. At present I have renamed native msvcrt in the wine system directory. Then in the builtin msvcrt I call a function and for that function I do a LoadLibrary(<renamed native msvcrt>) and a GetProcAddress(hinstofrenamendmsvcrt,<original function) to finally call that procedure. I experimented with the forwards in the spec file, but didn't succeed. Is there any easier way? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Winedbg that catches exception raised in IsBadReadPtr
by Christian Costa 24 Feb '04

24 Feb '04

Hi, Winedbg catches the exception raised and handled in a __TRY/__EXCEPT/__ENTRY statement in the IsBadReadPtr function. Is it a normal behaviour? And if yes how can I disable it? Without Winedbg everything is fine. Thanks in advance, Bye, Christian

3 2

rebar issues
by Matt Chapman 24 Feb '04

24 Feb '04

Hi, I'm having some rebar issues with a particular application (Canon File Viewer Utility). The rebar is meant to look something like: |0--------------- |1------|2---| |3------|4------|5------|6------ | (and there are some extra hidden bands) Instead in wine the result is: |0--------------- ||| |3------ |||| with the remaining bands having 0-size child windows (and there's important functionality in those bands). The minimum sizes provided by the application seem to be right. The application then requests maximisation of 0,3,4,5,6 in that order, which isn't implemented in WINE so that should not do anything, but I'd still expect the minimum sizes to be honoured. The output of wine --debugmsg +rebar is at: http://www.cse.unsw.edu.au/~matthewc/rebar.gz (62K) I'm currently trying to understand the source, but if anyone is familiar with the rebar and has any suggestions that would be much appreciated. Thanks, Matt

2 3

Re: Fix compile of programs/winedbg/elf.c on NetBSD 1.6
by Eric Pouech 24 Feb '04

24 Feb '04

Yorick Hardy a écrit : > Changelog: Use SHN_UNDEF instead of STN_UNDEF when it is defined > and STN_UNDEF is not. Fixes compiling on NetBSD 1.6. > > > Kind regards, > both STN_UNDEF and SHN_UNDEF exist in ELF definition and are meant to be used in different cases, which your patch mixes. Hence the fix is wrong (even if by change STN_UNDEF and SHN_UNDEF both are defined as 0) So, I'd rather suggest something (at the top of the file) as #ifndef STN_UNDEF # define STN_UNDEF 0 #endif A+

2 4

Big hex numbers negative?
by Fabian Cenedese 24 Feb '04

24 Feb '04

Hi While testing more variant functions I tried this on Windows: double dVal; OLECHAR test1[]={'&', 'H', '8', '0', '0', '0', '0', '0', '0', '0', '\0'}; ok=VarR8FromStr(test1, LANG_NEUTRAL, NUMPRS_STD, &dVal); The result for dVal was -2147483648. But as a real value it shouldn't have any problems holding the "real" value 2147483648. So why has it become negative? Is it because the source form was a hex number? Are all hex numbers automatically signed if converted to int/real? Or just because of the 32nd bit? The documentation wasn't that informative. (The funny thing though was this remark in my VC6 help, it's not in the online version of MSDN anymore: Passing into this function any invalid and, under some circumstances, NULL pointers will result in unexpected termination of the application. For more information about handling exceptions, see Programming Considerations. ...now I understand many things :) Thanks bye Fabi

3 3

how to connect to com object "outside" from wine?
by maman yonatan 23 Feb '04

23 Feb '04

Hi (I'm new in that group and don't know much about wine, so I'm sorry in advance if my question is in-proper) Here is my problem: I wrote in windows com object, and registered it in wine using regsv32 utility. I also wrote a com client application. When I executed the client code using Wine, all was just OK, and the client successfully make a reference to the server and activated It. :-) my question is there any way to write a client on the native (Linux) using g++ and activation the com object? does it make a difference if the com object id a dll, exe, or ocx ? 10x Yonatan __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools

6 12

Re: crosstest compile fix (another)
by Brian Vincent 23 Feb '04

23 Feb '04

> Yep, should have the first version of this service this week sometime. > > Thanks, > Chris > > >> Amen. Not everyone need to "make crosstest". We would come a long way >> if testers instead could install the Windows service (not yet written) >> that downloads >> the latest crosstest EXE from winehq and runs it. Speaking of which, SourceForge seems like the ideal way to build nightly Winetests by using their compile farm. I've been trying to get access to it for a few days in order to figure that out. All of the pieces seem to fit together and the only unknown is whether or not they have mingw on their servers. Does anyone else have any suggestions how we could create nightly builds? -brian

1 0

"oleaut32"="builtin" crash on OCX hosting with ATL
by Boaz Harrosh 23 Feb '04

23 Feb '04

Hi Marcus Do you need a little(est) test with full source code that hosts an OCX (The OCX is IE but I can change it if you need). It is written with ATL/WTL. It will work fine with: "oleaut32"="native" but will crash with "oleaut32"="builtin". I also have a winelib that crashes the same (same code), but contact me personally if you need the source for that. (I could post the .exe.so with full debug info) I would give it a shut, but it will only be months from now. It didn't look very simple, but maybe I am wrong about that. Free Life Boaz

2 1

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 February 2004