wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Screenshot description
by Paul van Schayck 26 Feb '04

26 Feb '04

Hey, Wouldn't it be nice to have a description of every screen at the screenshot page of winehq.com? To know what you see, I don't know half the programs I see on those screens. I have made a patch for the site file. The patch needs a a description.txt file inside /images/shots/ in this form: [screen# out of the filename]|[screen dexcription] Example: "1|Wine doing default Windows programs" Next descriptions on a new line. I've not edited the template but the patch adds a $des_[#] to the available vars. This is my first attemp to do something for winehq. So, are you interested in descriptions for screenshots? Regards, Paul van Schayck

3 6

Proposal: new mailing list wine-gov@winehq.org
by Dan Kegel 26 Feb '04

26 Feb '04

City governments (especially in Germany and France) have recently begun seriously consider migrating to Linux, and feasibility studies are being done and to some extent are publically available. The study done for Munich, for instance, recognizes that cities need sometimes hundreds of specialized software packages that are not yet available for Linux, and so the cities will have to continue running the Windows versions of those apps for the time being. Yet it suggests using Terminal Services and/or VmWare to run those apps! Clearly, the Wine community needs to make an effort to address the needs of city governments and to get the word out that Wine is a viable option. One important part of this effort should be a mailing list akin to wine-users but dedicated to governmental users of Wine. (wine-users is full of all sorts of topics that might not mix well with staid government workers; some of the games discussed there might even be banned in Germany!) Dedicating a mailing list to this special category of user would greatly increase the signal-to-noise ratio, and should increase the likelihood that government users would feel comfortable about Wine. IMHO the list should allow posts in any language; if nobody can handle the language a post is in, we'll ask the poster to try again in English. The goal here is to avoid intimidating these possibly skittish users; asking them to *always* post in English might scare some of them away. Comments? Thanks, 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/

4 5

Re: NdrClientCall/format string interpreter/stubless proxies
by Robert Shearman 26 Feb '04

26 Feb '04

Hi Mike, I have implemented NdrClientCall/NdrClientCall2 and respective server functions and they are working fairly well (except for no exception handling and no pipe support). The thing that was blocking my submission of the patch was lack of testing. So far I have only tested on simple types and pointers to simple types. Full pointers have been implemented, but are not working correctly. I haven't had time to port my test program to the Wine test framework and test the rest of the types. I have been using references from MSDN on NDR format strings compared with my own tests based on code generated by MIDL. I have also used the OpenGroup DCE specification. (I have URLs for these, but not at hand and you can probably find them in my previous posts on the subject.) I will try to submit the patches tonight. Rob >>> Mike Hearn <mike(a)theoretic.com> 02/26/04 14:36 PM >>> 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

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

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