- Wine-Devel - list.winehq.org

Fix for a warning in xrender.c
by Vincent Béron Nov. 26, 2002

Nov. 26, 2002

Changelog: Fix for deprecated use of label at the end of compound statement in xrender.c. Vincent

1 0

Working with GDI+
by François-Denis Gonthier Nov. 26, 2002

Nov. 26, 2002

Having to port System.Windows.Forms and System.Drawing to Linux, I would like to know how GDI+ works under Wine and WineLib? Anyone tried?

1 0

Winelib Applications
by Dimitrie O. Paun Nov. 26, 2002

Nov. 26, 2002

Folks, A new page has appeared in the Wine constellation <g>. It is still a work in progress, but I hope to release version 0.1 in the next few days, once I have a change to add what I've done on PuTTY, and Visual-MinGW. Check it out: http://www.dssd.ca/wine/Winelib-Apps.html Comments, suggestions, flames -- all welcome! -- Dimi.

3 6

self-registerable COM server dlls
by John K. Hohm Nov. 26, 2002

Nov. 26, 2002

I believe I have a workable method for defining the registration data needed to register and unregister self-registerable COM server dlls like ole32 et. al. that is easy enough to maintain and reasonably efficient. The only real objection I can anticipate is that I use char's instead of WCHAR's, and my reason is that the infrequency of use of these functions makes ease of maintenance more important than performance. I have attached (hopefully as text/plain) the header for the regsvr helper, and the comcat_main.c to give a feel for usage. Comments, please? /* * self-registerable dll helper functions * * Copyright (C) 2002 John K. Hohm * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ /* regsvr_register and regsvr_unregister take a pointer to registration data. The format of that data is as such (in RFC2234 ABNF): reg_data := LWSP "[" *"!" predef_key "\0" [ "=" value "\0" ] *sub_data "]" ; ! means delete (recursively) when unregistering sub_data := key_data / value_data key_data := LWSP "[" *"!" key "\0" [ "=" value "\0" ] *sub_data "]" ; ! means delete (recursively) when unregistering value_data := LWSP *"!" value_name "\0" "=" value "\0" ; ! means delete when unregistering predef_key := "HKCR" ; others could be added as necessary key := +CHAR value_name := +CHAR value := +CHAR */ HRESULT regsvr_register(char const *data); HRESULT regsvr_unregister(char const *data); /* * exported dll functions for comcat.dll * * Copyright (C) 2002 John K. Hohm * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include "comcat.h" #include "regsvr.h" #include "wine/debug.h" WINE_DEFAULT_DEBUG_CHANNEL(ole); DWORD dll_ref = 0; HINSTANCE COMCAT_hInstance = 0; /*********************************************************************** * Global string constant definitions */ const WCHAR clsid_keyname[6] = { 'C', 'L', 'S', 'I', 'D', 0 }; /*********************************************************************** * Registration data */ static char const regsvr_data[] = "[HKCR\0 [CLSID\0 [!{0002E005-0000-0000-C000-000000000046}\0=StdComponentCategoriesMgr\0 [InProcServer32\0=comcat.dll\0 ThreadingModel\0=Both\0 ] ] ] ]"; /*********************************************************************** * DllMain */ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID fImpLoad) { TRACE("%p 0x%lx %p\n", hinstDLL, fdwReason, fImpLoad); switch(fdwReason) { case DLL_PROCESS_ATTACH: COMCAT_hInstance = hinstDLL; break; case DLL_PROCESS_DETACH: COMCAT_hInstance = 0; break; } return TRUE; } /*********************************************************************** * DllGetClassObject (COMCAT.@) */ HRESULT WINAPI COMCAT_DllGetClassObject(REFCLSID rclsid, REFIID iid, LPVOID *ppv) { *ppv = NULL; if (IsEqualGUID(rclsid, &CLSID_StdComponentCategoriesMgr)) { return IClassFactory_QueryInterface((LPCLASSFACTORY)&COMCAT_ClassFactory, iid, ppv); } FIXME("\n\tCLSID:\t%s,\n\tIID:\t%s\n",debugstr_guid(rclsid),debugstr_guid(iid)); return CLASS_E_CLASSNOTAVAILABLE; } /*********************************************************************** * DllCanUnloadNow (COMCAT.@) */ HRESULT WINAPI COMCAT_DllCanUnloadNow() { return dll_ref != 0 ? S_FALSE : S_OK; } /*********************************************************************** * DllRegisterServer (COMCAT.@) */ HRESULT WINAPI COMCAT_DllRegisterServer() { TRACE("\n"); return regsvr_register(regsvr_data); } /*********************************************************************** * DllUnregisterServer (COMCAT.@) */ HRESULT WINAPI COMCAT_DllUnregisterServer() { TRACE("\n"); return regsvr_unregister(regsvr_data); }

1 0

COM and threads
by Fabian Cenedese Nov. 26, 2002

Nov. 26, 2002

Hi There were some postings recently about CoInitialize and theads: http://www.winehq.com/hypermail/wine-devel/2002/11/0974.html "Sort of, the problem is that Wine doesn't support apartments yet, so it doesn't try to keep track of the threads that has called CoInitialize." I now have a problem that goes maybe in the same direction. I have an ocx which is again embedded in another ocx. In the wrapper are two threads (Msg and worker). I now get an error if the second thread tries to call a function from the embedded ocx. In the wine log I can find only one call to CoInitialize. This is right before the call of the second ocx: 0811c6d0:Call ole32.CoGetMalloc(00000001,4211275c) ret=65352782 0811c6d0:Ret ole32.CoGetMalloc() retval=00000000 ret=65352782 trace:ole:IMalloc_fnAlloc (292) trace:ole:IMallocSpy_fnPreAlloc (0x40a00944)->(292) trace:heap:RtlAllocateHeap (0x40380000,00000002,00000128): returning 403d5308 trace:ole:IMallocSpy_fnPostAlloc (0x40a00944)->(0x403d5308) trace:ole:IMalloc_fnAlloc --(0x403d5308) 0811c6d0:Call kernel32.InterlockedIncrement(403c9ad4) ret=65352c07 0811c6d0:Ret kernel32.InterlockedIncrement() retval=00000002 ret=65352c07 0811c6d0:Call ole32.CoCreateInstanceEx(65343308,00000000,00000000,00000000,00000000,00000000) ret=65352c8d 0811c6d0:Ret ole32.CoCreateInstanceEx() retval=80070057 ret=65352c8d 0811c6d0:Call ole32.CoSetState(653c3f80) ret=653527ec fixme:ole:CoSetState (0x653c3f80),stub! trace:ole:CoSetState -- release 0x653c3f80 now 0811c6d0:Call kernel32.InterlockedDecrement(403c9ad4) ret=65356c7e 0811c6d0:Ret kernel32.InterlockedDecrement() retval=00000001 ret=65356c7e some window, gdi32 and heap functions 08119650:Call gdi32.CreateRectRgnIndirect(406e26bc) ret=4083c19e trace:heap:RtlAllocateHeap (0x40380000,00000002,00000020): returning 403d50c8 trace:heap:RtlAllocateHeap (0x40380000,00000002,00000020): returning 403d5050 08119650:Ret gdi32.CreateRectRgnIndirect() retval=00001842 ret=4083c19e 08119650:Call gdi32.CombineRgn(0000184e,0000184e,00001842,00000001) ret=4083c1b3 trace:heap:RtlAllocateHeap (0x40380000,00000002,00000020): returning 403d4ea0 trace:ole:IMalloc_fnFree (0x403d5308) trace:ole:IMallocSpy_fnPreFree (0x40a00944)->(0x403d5308 1) trace:heap:RtlFreeHeap (0x40380000,00000002,403d5308): returning TRUE trace:ole:IMallocSpy_fnPostFree (0x40a00944)->(1) 0811c6d0:Ret ole32.CoSetState() retval=00000000 ret=653527ec trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x65341543 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=00000010 The exception is right after CoSetState even if it says above that this is only a stub. It's that bad that I don't even have a call stack anymore. The function in the embedded ocx is never reached. But I can use the ocx in a simple VB proggy so I'd say registration is ok. I'm quite sure the problem lies in the two threads because it works better when I use only one thread in the wrapper ocx. Can somebody confirm this? Is there a workaround for this until wine supports COM with several threads? Thanks bye Fabi

2 1

RE: Wintab.dll technical issues.
by Patrik Stridvall Nov. 26, 2002

Nov. 26, 2002

> Firstly a quick note: > I have opened a bug for implementation of wintab.dll (Bug No. 1160) > > Now the questions: > > 1: Writing stubs. > I'll be taking up Patrik Stridvall's offer to write stubs for > anyone new > to wine development. Yes, I'm working on it right now. Will probably not finish tonight though. > One question about stubs: > What's the wine policy on stub return values? No general policy. It depends. > Should a stub always return an error? Normally stubs should indicate error (return NULL, FALSE or similar) and do SetLastError(ERROR_NOT_IMPLEMENTED). > Should/Can it return success? In some cases indicating success (return TRUE or similar), even though it not strictly correct, might be a good idea. It depends. Lying to the application should be avoided of course but sometimes it is nessary. > 2: Testing wintab.dll in Win98. > wintab.dll is quite complex for what it does. I guess you mean wintab32.dll. wintab.dll is the 16 bit variant AFAICS. > Therefore the only practical way to implement it is > to work on the functions and communication models that are > used by the apps I want it to support. Probably. > To do this, I need some tool that can log the function calls and > parameters to the DLL, while wunning Win98.The logging must > be able to > let the > programmer choose elements from data stuctures in > parameters/retvals to log. > Any ideas???? There are no good tools to do this AFAIK. But if you find any I'm very intrested. > I've attempted to use apis32 and built a wintab.fnl file for > wintab.dll. > Unfortunately apis32 doen't allow the logging of the contents of data > structs. Yes. APIS32 is the best AFAIK and it sucks pretty bad IMHO. > I would also like to know experinces with Spy++. > Wintab can send it's own custom messages, so I'm wondering how good > Spy++ is at detecting custom messages? > > I've used it many times before, but only to examine standard windows > messages. No idea, haven't used it for years. > 3: Coding standards. > I haven't found any coding standards associated with wine. > This is particularly important, as I'll be writing new source files. > Can someone point me to the standards? We have none. Decide for yourself. However please do not choose anything to unlik anything else in Wine.

2 1

Doubleclick in systray (was Pegasus Mail 4.02)
by Duane Clark Nov. 26, 2002

Nov. 26, 2002

Rick wrote: > The second issue, I've noticed that double-clicking the system tray > icon does not restore Pegasus Mail. I can minimize it so it appears > both on the taskbar and the system tray, but I can't restore the > application from the system tray icon (though I can from the > taskbar). > The problem here appears to be that under WinNT, when double clicking on the systray icon under WinNT, messages are sent for mouse down (message 201), mouse up (message 202), double click (message 203) (the message 200 is extraneous): <00171> 0007011E S message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000201 <00172> 0007011E R message:0x19C9 [User-defined:WM_USER+5577] lResult:00000000 <00173> 0007011E S message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000202 <00174> 0007011E R message:0x19C9 [User-defined:WM_USER+5577] lResult:00000000 <00175> 0007011E S message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000200 <00176> 0007011E R message:0x19C9 [User-defined:WM_USER+5577] lResult:00000000 <00177> 0007011E S message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000203 While under Wine, what is sent are two pairs of mouse down, mouse up messages: <00062> 00010024 P message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000201 <00063> 00010024 P message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000202 <00064> 00010024 P message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000201 <00065> 00010024 P message:0x19C9 [User-defined:WM_USER+5577] wParam:00001F47 lParam:00000202 So while I am poking around trying to figure out where that translation should be occuring, if anyone has some hints on where to look, it would be most appreciated...

3 6

RE: Overlapped I/O without an hEvent
by Martin Wilck Nov. 26, 2002

Nov. 26, 2002

Am Die, 2002-11-26 um 00.33 schrieb Ryan Reading: > I finally got it working, but not by ignoring the hEvent member in the > case that it is NULL. I tried that first (before I understood the > problem better), but it didn't work. The GetOverlappedResult() > implementation was not going to work with hEvent == NULL. Please try this patch, where GetOverlappedResult is modified, too: Index: files/file.c =================================================================== RCS file: /home/wine/wine/files/file.c,v retrieving revision 1.170 diff -u -r1.170 file.c --- files/file.c 21 Nov 2002 03:45:03 -0000 1.170 +++ files/file.c 26 Nov 2002 10:34:21 -0000 @@ -1593,32 +1593,40 @@ ERR("lpOverlapped was null\n"); return FALSE; } - if(!lpOverlapped->hEvent) + if( lpOverlapped->hEvent ) { - ERR("lpOverlapped->hEvent was null\n"); - return FALSE; + if ( bWait ) + { + do { + TRACE("waiting on %p\n",lpOverlapped); + r = WaitForSingleObjectEx(lpOverlapped->hEvent, INFINITE, TRUE); + TRACE("wait on %p returned %ld\n",lpOverlapped,r); + } while (r==STATUS_USER_APC); + } + else if ( lpOverlapped->Internal == STATUS_PENDING ) + { + /* Wait in order to give APCs a chance to run. */ + /* This is cheating, so we must set the event again in case of success - + it may be a non-manual reset event. */ + do { + TRACE("waiting on %p\n",lpOverlapped); + r = WaitForSingleObjectEx(lpOverlapped->hEvent, 0, TRUE); + TRACE("wait on %p returned %ld\n",lpOverlapped,r); + } while (r==STATUS_USER_APC); + if ( r == WAIT_OBJECT_0 ) + NtSetEvent ( lpOverlapped->hEvent, NULL ); + } } - - if ( bWait ) + else { - do { - TRACE("waiting on %p\n",lpOverlapped); - r = WaitForSingleObjectEx(lpOverlapped->hEvent, INFINITE, TRUE); - TRACE("wait on %p returned %ld\n",lpOverlapped,r); - } while (r==STATUS_USER_APC); - } - else if ( lpOverlapped->Internal == STATUS_PENDING ) - { - /* Wait in order to give APCs a chance to run. */ - /* This is cheating, so we must set the event again in case of success - - it may be a non-manual reset event. */ - do { - TRACE("waiting on %p\n",lpOverlapped); - r = WaitForSingleObjectEx(lpOverlapped->hEvent, 0, TRUE); - TRACE("wait on %p returned %ld\n",lpOverlapped,r); - } while (r==STATUS_USER_APC); - if ( r == WAIT_OBJECT_0 ) - NtSetEvent ( lpOverlapped->hEvent, NULL ); + /* hEvent == NULL: we cannot wait. + * FIXME: According to MSDN, NT, Win2k, and XP use the hFile handle for notification + * in this case. */ + if ( bWait ) + { + SetLastError ( ERROR_INVALID_HANDLE ); + return FALSE; + } } if(lpTransferred) @@ -1818,7 +1831,7 @@ if (flags & FD_FLAG_OVERLAPPED) { if (unix_handle == -1) return FALSE; - if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) + if ( (overlapped==NULL) || ( overlapped->hEvent && NtResetEvent( overlapped->hEvent, NULL ) ) ) { TRACE("Overlapped not specified or invalid event flag\n"); close(unix_handle); @@ -2042,7 +2055,7 @@ if (flags & FD_FLAG_OVERLAPPED) { if (unix_handle == -1) return FALSE; - if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) ) + if ( (overlapped==NULL) || ( overlapped->hEvent && NtResetEvent( overlapped->hEvent, NULL ) ) ) { TRACE("Overlapped not specified or invalid event flag\n"); close(unix_handle); Index: include/async.h =================================================================== RCS file: /home/wine/wine/include/async.h,v retrieving revision 1.5 diff -u -r1.5 async.h --- include/async.h 4 May 2002 18:37:08 -0000 1.5 +++ include/async.h 26 Nov 2002 10:53:28 -0000 @@ -73,7 +73,7 @@ ovp->next = ovp->prev = NULL; close( ovp->fd ); - if( ovp->event != INVALID_HANDLE_VALUE ) + if( ovp->event && ovp->event != INVALID_HANDLE_VALUE ) NtSetEvent( ovp->event, NULL ); if ( ovp->ops->call_completion ) -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: _stati64 (before _fstati64)
by Andreas Mohr Nov. 26, 2002

Nov. 26, 2002

On Sun, Nov 24, 2002 at 09:35:53PM +0100, Stefan Leichter wrote: > Hello, > > by accident i have send this patch to wine-develop list instead of wine-patches. > This patch needs to be applied before my _fstati64 patch Err... and what had happened to *my* patch from Nov 09 ?? Duplicate work... urks ! :-\ -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview

1 0

Re: [bug 718] Executing dos DPMI programs
by Jukka Heinonen Nov. 26, 2002

Nov. 26, 2002

> Does someone has success when executing DPMI programs ? > Every program I try to execute at this time fails, > going to the debugger, saying : > > Unhandled exception: privileged instruction in 32-bit code > (0x00000000). > In 32-bit mode. > 0x00000000: int $0x31 DPMI16 programs should work as should simple DPMI32 programs. However, most DPMI32 programs are not even supposed to work because there is no real implementation of 32-bit interrupt handling. It is on my TODO list but I'm currently working on moving interrupt handlers to winedos dll and I shall return to DPMI32 support after this. The problem is that Wine has no support for calling Wine functions from application context whose stack and code pointers use 32-bit segmented model. Wine interrupt emulation currently uses a simple scheme which works with any code pointer but which fails miserably if stack pointer is over 0xffff. The simplest fix would probably be to swap to 16-bit stack on entry to Wine interrupt handler. This would mean that only winedos dll needs to deal with 32-bit segmented stuff. I have a rather good idea on how this can be implemented. Anyway, your error message looks quite interesting because current Wine version emulates *all* interrupt opcodes in real mode, 16-bit protected mode and 32-bit protected mode and thus it should be impossible to get this error message. Are you sure you tried executing using the latest CVS version or at least the latest release? -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 3