November 2002 - Wine-devel - list.winehq.org

COM and threads
by Fabian Cenedese 26 Nov '02

26 Nov '02

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 26 Nov '02

26 Nov '02

> 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 26 Nov '02

26 Nov '02

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 26 Nov '02

26 Nov '02

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 26 Nov '02

26 Nov '02

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 26 Nov '02

26 Nov '02

> 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

Overlapped I/O without an hEvent
by Ryan Reading 26 Nov '02

26 Nov '02

Hi all, This is a follow-up to the message I wrote a message yesterday with the subject "Wine and IrDA via Virtual Com Port", although that wasn't a good subject for the problem. The software that I have is using Overlapped (asynchronous) I/O for communication of an IR port. The software makes WriteFile(), ReadFile(), and GetOverlappedResult() calls. However, before making any of the calls, the software does NOT initialize the hEvent member of the OVERLAPPED structure that is passed to the functions (it just zeroes the entire structure). Apparently the Win32 implementation of this is OK, but it is pretty obvious that the Wine implementation will not work with hEvent == 0. Now, I'm not saying that the Wine implementation is wrong, because based on the MSDN documentation, that value should be set to a valid event handle; however, the behavior is fundamentally different from the native Win32 environment, which in my case, leads to undesirable results. Is this something that I could feasibly fix in Wine, or would it be better to try to change the implementation of the software? Does anyone have any experience with this part of Wine? Thanks. -- Ryan 01010011 01100101 01110010 01100101 01101110 01100100 01101001 01110000 01101001 01110100 01111001 If only all life was just this simple. :)

4 5

Orlando, anyone?
by Fredrick P. Lackey 26 Nov '02

26 Nov '02

Hey, everyone! It's the annoying Microsoft guy again. ;-) Well, I've started to make the move. Now, 1/2 of my laptop is Red Hat. Whoo hoo! Man, I love Linux! =) I am having some problems, and was wondering if anyone in your list knew anyone in or near Orlando. heck, in Florida would be close enough. I'd like to see about hooking up on the phone or in person and trying to get the few issues I'm having worked out. I know that may seem a bit odd, but I'm really pumped to get M$ outta the picture. Thanx, Fred Lackey Orlando, Florida

2 1

Found Something Really Weird here!!
by Rômulo 26 Nov '02

26 Nov '02

I found something reeeally weird here, installing wine, on mandrake, gcc v3.2. ( [lamorack(a)WNET wine-20021031]$ gcc -v Reading specs from /usr//bin/../lib/gcc-lib/i586-mandrake-linux-gnu/3.2/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk)) See this: (...) make[1]: Nada a ser feito para `all'. make[1]: Saindo do diretório `/home/lamorack/wine-20021031/miscemu' make[1]: Entrando no diretório `/home/lamorack/wine-20021031/programs' make[2]: Entrando no diretório `/home/lamorack/wine-20021031/programs/avitools' LD_LIBRARY_PATH="../../library:../../unicode:$LD_LIBRARY_PATH" ../../tools/winebuild/winebuild -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -o aviplay.exe.spec.c -exe aviplay.exe -mgui aviplay.o -L../../dlls -lddraw -lkernel32 could not open .so file for ddraw.dll make[2]: ** [aviplay.exe.spec.c] Erro 1 make[2]: Saindo do diretório `/home/lamorack/wine-20021031/programs/avitools' make[1]: ** [avitools] Erro 2 make[1]: Saindo do diretório `/home/lamorack/wine-20021031/programs' make: ** [programs] Erro 2 And that's it! I really hope u have an idea... 'cause i did not. Send me any E-mail answering, please

2 1

Re: Re: About picture format.
by yf 26 Nov '02

26 Nov '02

> On Mon, Nov 25, 2002 at 01:03:00PM +0800, yf wrote: > > > > It is a Windows application. > > you can download it on http://www.myhexin.com/tw2002/rjxz/download.asp?rjxz=exe1 > > Which program do you start? when running, it complains: fixme:ole:OLEPictureImpl_Load Unknown magic 0010 fixme:ole:OLEPictureImpl_Render type -1 not implemented fixme:ole:OLEPictureImpl_Destroy Unsupported type -1 - unable to delete fixme:ole:OLEPictureImpl_Load Could only read 136 of 1073465 bytes? > > I have a bit of a hard time following the menus, since they appear to be > in an asian language and the characters do not even display ;) I have sended the patch of how to make the Chinese character properly showed before. --- wine-20021031/graphics/x11drv/codepage.c.original 2002-11-16 13:50:31.000000000 +0800 +++ wine-20021031/graphics/x11drv/codepage.c 2002-11-04 17:44:14.000000000 +0800 @@ -279,8 +279,8 @@ { if ( IsLegalDBCSChar_cp936( *str_src, *(str_src+1) ) ) { - str2b_dst->byte1 = *str_src; - str2b_dst->byte2 = *(str_src+1); + str2b_dst->byte1 = *str_src&0x7f; + str2b_dst->byte2 = *(str_src+1)&0x7f; str_src++; } else > > Ciao, Marcus >

3 4