wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: RPC Update Patch
by Dan Kegel 28 Feb '04

28 Feb '04

> On Thu, 26 Feb 2004 23:16:23 -0600, Gregory M. Turner wrote: >> They are actually pretty well-documented on MSDN: >> >> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/rp… >> >> Looks like a lot of work, Robert; thanks for your efforts. > > Hmm, interesting. I wonder why this doesn't show up when I google for "ndr > format strings". It does if you include the quotes... - 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/

1 0

Re: implement fixme in CreateAcceleratorTable
by Dmitry Timoshkov 28 Feb '04

28 Feb '04

"Pabs" <pabs3(a)bonedaddy.net> wrote: > ChangeLog > > Added some checks to CreateAcceleratorTableA/W (removes fixmes) IMO it's better to use if (!MapVirtualKeyW(lpaccel[i].key, 0)) { WARN("Invalid VK\n"); SetLastError(ERROR_INVALID_PARAMETER); return NULL; } for a check whether VK is a valid one. -- Dmitry.

2 1

catching first chance exception question
by Robert Reif 27 Feb '04

27 Feb '04

I'm looking at how windows deals with invalid parameters in some of the winmm functions and it raises some questions. Sometimes they will check the parameters and return an error code and sometimes they will let a bad parameter cause a first-chance exception and catch it and return an error code. Is it ok to do a simple NULL pointer check and return an error rather than letting it cause an exception and catching it? If not, what's the best way to catch the exception and return the proper error code?

2 1

Re: build: avoid Unix file on MinGW
by Lionel Ulmer 27 Feb '04

27 Feb '04

On Fri, Feb 27, 2004 at 09:19:08AM -0500, Dimitrie O. Paun wrote: > BTW, why do we need the {GLU32,GLUT32,OPENGL}FILES cases? > Should those just be listed under X files? And shouldn't > we just build those, and dload() the Unix libs at run time? We need these special cases as an user can have X installed but not GLU / GLUT or OpenGL. And as to why we cannot dload the Unix lib at run time, it would be a bit like 'why do we not build the X11DRV library all the time and dlsym all the X11 symbols'. Basically, if you do not have OpenGL installed, there is no way you will be able to get Wine's OpenGL library to run. So there is no point to offer some special 'dlopen' magic to be able to load it on these boxes. Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: winemaker: use winegcc
by Francois Gouget 27 Feb '04

27 Feb '04

On Fri, 27 Feb 2004, Dimitrie O. Paun wrote: [...] > @@ -801,7 +753,7 @@ > $basename=~ s/\.(dll|exe)$//i; > # This is the default link list of Visual Studio, except odbccp32 > # which we don't have in Wine. > - my @std_imports=qw(advapi32 comdlg32 gdi32 kernel32 odbc32 ole32 oleaut32 shell32 user32 winspool); > + my @std_imports=qw(odbc32 ole32 oleaut32 winspool); > my @std_libraries=qw(uuid); Does winegcc systematically link applications and dlls to advapi32, comdlg32, etc? How does one do if one does not want to link with gdi32 for instance? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

2 1

Re: Help needed to get the application work for native linux editors
by Robert Shearman 27 Feb '04

27 Feb '04

Hi, I can't really give you any advice on using the X API, but I can tell you that the Win32 and X API are completely different. If you want to support native X apps then you will have to either completely rewrite your Windows program in Linux or you will have to compile the Linux editor as a Winelib app and run it under Wine. I suggest you find a good book on the X API and/or contact the appropriate mailing lists to find out which functions you should use. Rob >>> "saravanan" <saravananv(a)erdcitvm.org> 02/26/04 11:17 AM >>> Hai friends, I successfully ran a script manager(keyboard Manager/driver) developed for windows (using VC++) in Linux using wine. Its working in the wordpad application called using wine.I want to make it work in Linux editors. The technical details about the working of the keyboard driver is as follows. 1) The keyboard driver is a keyboard hooker program. The keyboard driver will trap all the keystrokes from the keyboard and convert the Ascii value to the appropriate native language Character code. 2) First we have to get the handle of the window/control where the cursor is currently located, for that the GetFocus API is used. 3) Virtual-key code of the key that generated the keystroke message is converted to appropriate another code for making the keyboard Inscript or phonetic and send using Postmessage API. I have some doubts. Do these APIs written for windows work in linux. In linux , How could i get the handle of the window where the cursor is currently located. What are the changes that i should make in the source code to make it work for linux editors. Looking for your suggessions. Thanks in advance . Saravanan ______________________________________ Scanned and protected by Email scanner

4 3

RPC Update Patch
by Robert Shearman 27 Feb '04

27 Feb '04

Hi, I have uploaded the big stubless RPC patch to a website as it is rather large (~120k). You can get it here: http://www.dcs.warwick.ac.uk/~csvmc/rpcrt4_3.diff As you can probably see, a lot of the stuff in this patch is a bit rough around the edges (lack of copyright notice in some files), but it does seem to work for a lot of cases. Rob P.S. It doesn't work for native OLE32 yet because we need some undocumented interfaces in RPCSS.

3 4

Re: Reset Resolution on Crash (resend)
by Alexandre Julliard 27 Feb '04

27 Feb '04

Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > No comment to this patch last time it was sent. Is it better implemented > some other way? I don't think user32 should be messing with the exception filter. Maybe we could make winedbg do this? -- Alexandre Julliard julliard(a)winehq.org

1 0

Authors.c Won't Compile
by Robert Shearman 27 Feb '04

27 Feb '04

Hi, I can't compile authors.c due to some encoding issue with sed. I can generate the authors.c file fine on the command line, but the same command in the Makefile won't generate compilable code due to it terminating the string constant before a UTF-8 character. Rob Example of errors: authors.c:19: error: stray '\366' in program authors.c:20: error: `m' undeclared here (not in a function) authors.c:20: error: initializer element is not constant authors.c:20: error: (near initialization for `SHELL_Authors[18]') authors.c:20: error: syntax error before string constant

1 0

Re: time: rework of GetLocalTime speedup
by Steven Edwards 26 Feb '04

26 Feb '04

--- Huw D M Davies <h.davies1(a)physics.ox.ac.uk> wrote: > Huw Davies <huw(a)codeweavers.com> > Cache the result of TIME_GetBias for upto 1 second. Hello Huw, I know you may not have a lot of time =P but while you are working on the Wine time implementation could you look at rpcrt4 and its use of gettimeofday? Most of the WINE rpcrt4 implementation should be portable to Windows/ReactOS but currently I have to use a hacked implementation of this function and would rather it use the Win32 or NT api. Thanks Steven __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools

1 0

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

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