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

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

Overlapped I/O without an hEvent
by Ryan Reading Nov. 26, 2002

Nov. 26, 2002

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 Nov. 26, 2002

Nov. 26, 2002

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 Nov. 26, 2002

Nov. 26, 2002

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 Nov. 26, 2002

Nov. 26, 2002

> 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

Re: Screwed up textures in OpenGL apps
by David D. Hagood Nov. 26, 2002

Nov. 26, 2002

Lionel Ulmer wrote: > Out of curiosity after the DoubleBuffered thread.... Does this fix your > problem too ? > > No, I was running DesktopDoubleBuffered = Y already.

1 0

Winelib Apps v0.1
by Dimitrie O. Paun Nov. 26, 2002

Nov. 26, 2002

Folks, Version 0.1 of the Winelib Applications page is available here: http://www.dssd.ca/wine/Winelib-Apps-0.1.html The current version is always available at this address http://www.dssd.ca/wine/Winelib-Apps.html Your comments, and suggestions are highly appreciated. -- Dimi.

1 1

An opengl regression
by Duane Clark Nov. 25, 2002

Nov. 25, 2002

The patch for dynamic loading of opengl, http://www.winehq.com/hypermail/wine-cvs/2002/11/0151.html has caused a (apparently minor) regression in the program earthquake http://www.navagent.com/products/earthquake/ That is a small app (250K download) with a spinning globe that shows current earthquakes; actually a pretty cool little app. The regression is that now when the oceans are turned on (via the settings dialog), the land gets flooded.

3 5

Compiling Win32 targets on Linux
by mwood＠gosympatico.ca Nov. 25, 2002

Nov. 25, 2002

I'm not sure if this is directly related to Wine, but I would like to build win32 exectuables on a Linux machine, with gcc if this is possible. I use Slackware 7.x and 8.x and was wondering what I would need to install to accomplishh this. Mikko Woodroffe

2 1

Wintab.dll technical issues.
by Robert North Nov. 25, 2002

Nov. 25, 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. One question about stubs: What's the wine policy on stub return values? Should a stub always return an error? Should/Can it return success? 2: Testing wintab.dll in Win98. wintab.dll is quite complex for what it does. 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. 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???? 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. 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. 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? Hope you guys have the answers -Rob.

5 5

[RFC] pthread emulation on FreeBSD (and Linux)
by Patrik Stridvall Nov. 25, 2002

Nov. 25, 2002

With the attached patch FreeBSD compiles again even if OpenGL (which need pthreads) is used. Since it is only stubs at present OpenGL can't really work, but Wine and the normal test runs fine ("make test"). Anyway, to answer the first obvious question: Why didn't you just put it in scheduler/pthread.c? Well, the thing is it didn't work. It still generates the same link errors. However that is not very suprising since the pthread_ implementation is in ntdll.dll which is not linked with during the "-Bsymbolic -z defs" step. This begs the question: Does the Linux implementation of pthread really work anyway? The thing is Linux (or rather the GNU C library) always links in pthread suppport. However since some of the symbols are on purpose defined as weak they can be overriden. This is what scheduler/pthread.c does on Linux. Or rather tryies to do. I'm not really sure if works any longer. Note that if I apply the attach patch and compiles on Linux it seems to work with "make test" as well. Anyway be pthreads on Linux working properly as it may, the big question is how do we support pthreads on both Linux and FreeBSD. FreeBSD since it AFAICS have no default overridable implementation seems to require that we have some sort of wine_pthread library to implement pthreads from scratch like outlined in the attached patch. I'm not really very good on how runtime linking on Linux and FreeBSD. So, I would very much like comments from people more knowledgeable than I on that area. Comments? Suggestions? PS. Can somebody test if OpenGL:s pthread locking REALLY works properly on Linux?

3 2

Re: Screwed up textures in OpenGL apps
by David D. Hagood Nov. 25, 2002

Nov. 25, 2002

Dan Kegel wrote: > Please verify that booting with just one CPU active > doesn't fix the problem. e.g. at lilo prompt, do something like > linux nosmp > It could be that Wine doesn't support SMP yet. > > - Dan > > First thing I tried, and with no change, so I don't think it's a SMP issue. Furthermore, my other apps under Wine work fine, only the OpenGL ones die.

2 2

Visual Basic runtimes?
by Mike Hearn Nov. 25, 2002

Nov. 25, 2002

Hi, (btw, thanks to ove and alexandre for catching my patch booboo). Anyway, I'm trying to install Tipic IM (tipic.com) and once I figured out how to install .msi files in wine (hint: install ie6 then run msiexec /i foo.msi) I hit the lack of VB runtimes. It appears the MSI file assumes you already have msvbvm50 and msvbvm60 installed, but of course I don't. Tracking these down on the net wasn't too hard, but I'm wondering whether Wine could ship with them included or would it require a cleanroom implementation of these DLLs? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

1 0

RE: [RFC] pthread emulation on FreeBSD (and Linux)
by Patrik Stridvall Nov. 25, 2002

Nov. 25, 2002

> On Sun, 24 Nov 2002, Patrik Stridvall wrote: > > > Anyway, to answer the first obvious question: > > Why didn't you just put it in scheduler/pthread.c? > > > > Well, the thing is it didn't work. It still generates the > > same link errors. However that is not very suprising since > > the pthread_ implementation is in ntdll.dll which is > > not linked with during the "-Bsymbolic -z defs" step. > > scheduler/pthread.c should be linked into libwine, which is > linked into > everything, at least this is the idea and was the case last time I > checked. It is not so in the current CVS of Wine: scheduler/pthread.c is linked with ntdll not with libwine. However libwine is not an appropriate place for the pthread implementation since the pthread implementation needs to call Windows API functions. libwine is a strictly Unix API library AFAICS. That why I made a new libwine_pthread library. > > This begs the question: > > Does the Linux implementation of pthread really work anyway? > > Works in WineX (though we needed some more hacks in it to > make it interact > well with the nvidia opengl drivers), and it'd surprise me if > it doesn't > still work in Wine, as the OpenGL deployed by most linux > distros wouldn't > work *at all* under Wine if it didn't, and people currently seem to be > working on Wine as if it did work. True. However, while I can't say I really understand how runtime linking work, I still feel that something is wrong. > > The thing is Linux (or rather the GNU C library) always links > > in pthread suppport. However since some of the symbols are > > on purpose defined as weak they can be overriden. This is > > what scheduler/pthread.c does on Linux. Or rather tryies to > > do. I'm not really sure if works any longer. > > It's not the weak symbols that allow overrides, weak symbols > only allow > the pthreads library to *not* be linked in (so your statement > about always > linking it in is untrue). Weak symbols work such that until > the library is > linked in, they are just null pointers, and glibc only calls > them if they > aren't null. Overriding symbols can only be done by linking > things in the > right order (link the wine overrides before the real pthread lib), and > since libwine is loaded before > opengl-linked-against-pthreads, the libwine > pthread implementation is used instead of the pthreads linked > in later, > and this don't need a special kind of symbol to work. OK. Thanks for the explaination. As I said not my area or expertise. > > Note that if I apply the attach patch and compiles on > > Linux it seems to work with "make test" as well. > > > > Anyway be pthreads on Linux working properly as it may, the big > > question is how do we support pthreads on both Linux and FreeBSD. > > I'd say link -lwine in before -lc_r, but then I don't know much about > FreeBSD. It is already done that what eventhough: 1. We current link with -lc not -lc_r, but maybe we should. 2. scheduler/pthread.c is as I said earlier in ntdll not libwine, so I can't see how linking can work and futhermore is doesn't for empirical evidence. > > FreeBSD since it AFAICS have no default overridable implementation > > seems to require that we have some sort of wine_pthread library to > > implement pthreads from scratch like outlined in the attached patch. > > The scheduler/pthread.c is basically the same thing, since it needs to > override every single pthread symbol used by apps, otherwise > the override > fails (or if it would be successful, it would still be incomplete). > > Stupid question: the reason for the missing symbols on FreeBSD isn't > because of the #ifdef __GLIBC__ in scheduler/pthread.c, is it? No, I would have to be VERY tired to make that mistake. :-) But since your premise scheduler/pthread.c in libwine is wrong that might be the answer. However it still doesn't explain why OpenGL seems to work on Linux. Perhaps it is because Linux have weak symbols or whatever concerning pthreads in libc and everything is OK because of this...

1 0

Off Topic: Off-list help needed with SGML Tools please
by Dustin Navea Nov. 25, 2002

Nov. 25, 2002

For some reason I cant get SGMLTools to compile properly, everything but jade compiles but when it goes to compile that, I get a bunch of errors. I could leave out jade but thats what Im needing to compile to build sgml docs... I have tested this with Slackware 8.1 default GCC and the prepackaged GCC 3.2.1 Source from Slackware-current and neither would compile it. I also tested that its not just Slackware's GCC... Redhat 8.0 would not compile it either with GCC 3.2.1... So if anyone can help me it would be most appreciated.. I still have a couple of other things to try (installing the latest slackware binutils, and trying out CVS sgmltools, if i can ever connect to the cvs server) :/ -Dustin

1 0

Exe, Com and PATH
by Sylvain Petreolle Nov. 25, 2002

Nov. 25, 2002

Wanting to run msdos debugger, I ran from c:\ : wine debug. the 2 debug that exists on my fake windows are c:\debug.com c:\windows\command\debug.exe My PATH variable is set as "Path" = "c:\\program\ files\\java\\j2re1.4.0_01\\bin;c:\\windows;c:\\windows\\command;c:\\windows\\system32;c:\\windows\\system;e:\\" Currently running wine debug from c:\ runs c:\windows\command\debug.exe,ignoring debug.com in the current directory. This is not the behaviour expected in real windows. These are 2 problems here : - Normally dos looks first in current directory => would load c:\debug.com. There is a problem with PATH here. - Putting 2 files with a .exe and .com with the same name in the same directory loads the .exe first, which shouldn't happen. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Fwd: Problem with network functions
by Sylvain Petreolle Nov. 24, 2002

Nov. 24, 2002

Does someone has a clue for this / has same issues ? I cant figure how to find what is causing the network errors I have. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Bug #416: Missing Exports in Winsocks
by Andrew John Hughes Nov. 24, 2002

Nov. 24, 2002

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This patch adds stubs for the functions listed in Bug #416, SetService{A,W} and GetTypeByName{A,W}. License: LGPL - - -- Andrew :-) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE94VftSE/kMce1ABARAipUAJ0ew9mD8eqn+2HrS1Yk72lvy+h4QACfaIeV uPloEX9A/xk4ptC6l0Xl5Z4= =K3YG - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE94VggSE/kMce1ABARAleXAJ40B6etNGsPhlZdm7GoqCrvYpGwpACgiU/o 2chi+d/NOUGg3WhHjj31UwQ= =Za8w -----END PGP SIGNATURE-----

1 0

Re: Some additions to D3D
by Alexandre Julliard Nov. 24, 2002

Nov. 24, 2002

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > Note (for Alexandre): how would you prefer for us to track dependencies > between patches ? Submit each time a patch agains fresh CVS with all > previous patches sent (with an ever growing changelog) or do you prefer > (like here) a lot of patches dependant one on the others ? > If it's the latter, do we need to do 'letter tracking' as Dimi did ? In general separate patches are better; the exception is if they are fixes to a previous patch then it's better to resend all so I don't have to try to understand the broken version before reading the fix. And yes, in either case please find a way to clearly mark the sequence, don't rely on the submission order because mail doesn't always arrive in the correct order. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: _ fstati64
by Stefan Leichter Nov. 24, 2002

Nov. 24, 2002

Am Sonntag 24 November 2002 11:11 schrieben Sie: > ChangeLog > ------------- > converted implementation of _fstat to _fstati64 > implemented _fstat by calling _fstati64 > Hello Alexandre, this patch is relative to my patch _stati64 please apply the _stati64 patch before this one. The _stati64 patch went to the worng list by accident. Thanks Stefan

1 0

Screwed up textures in OpenGL apps
by David D. Hagood Nov. 24, 2002

Nov. 24, 2002

I'd asked this before, but received no response, so I'll ask it again. Does anybody have any suggestions on where to start debugging textures being wrong under OpenGL apps under Wine? Specifically, I am trying to get HalfLife-Blue Shift to run, but all the "static" textures (walls, floors, etc.) are screwed up. The "dynamic" textures on things like people are fine. Now, I USED to have Halflife running great, but then I upgraded my system to a SMP P3 system (I had been running a UMP P3) (the old system died.) All my native apps (Q3A, RTCW, gears, etc.) are just fine. Only Windows apps running under Wine are screwed up. Does anybody have a simple Windows OpenGL app I can use for testing? Or a direction to begin looking in? I do know this - forcing OpenGL to go to indirect rendering does NOT fix the textures - they are still just as screwed up, just a lot slower.

2 1

Re: [Fwd: [Bug 688] - make documentation produces only files as 'x6772.html']
by Tony Lambregts Nov. 24, 2002

Nov. 24, 2002

Tony Lambregts wrote: > Vincent Béron wrote: > >> Hi guys, >> >> Alexandre just committed my patch concerning the documentation building >> process. Could you verify it works for you? >> >> >> > I am sure it is something on my end but I get the following when I > "make html", "make everything" > > docbook2html -d ./default.dsl -o wine-devel wine-devel.sgml > Using catalogs: /etc/sgml/sgml-docbook-3.1.cat > Using stylesheet: ./default.dsl > Working on: /usr/local/src/wine/documentation/wine-devel.sgml > jade:E: cannot find "./default.dsl"; tried "./default.dsl", > "/usr/share/sgml/./default.dsl" > jade:E: specification document does not have the DSSSL architecture as > a base architecture > ..... > spews out sgml > .... > > It must be something I've done but I have no idea what, since > db2html -d ./faq-plain.dsl wine-faq.sgml > jade:E: cannot find "./faq-plain.dsl"; tried "./faq-plain.dsl", > "/usr/share/sgml/./faq-plain.dsl" > jade:E: specification document does not have the DSSSL architecture as > a base architecture > > > same thing. WTF. > Ok heres what I have found. "db2html -d ../faq-plain.dsl wine-faq.sgml " works, However if I use "db2html -d ./faq-plain.dsl wine-faq.sgml " it blows chunks. as I reported. So the change to two dots works, which makes sense, therfore I changed the Makefile so that SRCDIR = .. and re-ran "make html" and produces the html beautifully. So all that tells me is "There is something wrong here" ./ should work (right?) -- Tony Lambregts

3 5

Re: dosconf move
by Alexandre Julliard Nov. 24, 2002

Nov. 24, 2002

"György 'Nog' Jeney" <nog(a)sdf.lonestar.org> writes: > Is there any reason why this patch has not been applied? This is essentially > the same as my dosconf try 3 patch but for your convinience I made a new diff > against the current cvs. It's really ugly to export the DOSCONF structure as part of the DOS module interface. I think it's better to wait until that stuff can be moved without having to export it. -- Alexandre Julliard julliard(a)winehq.com

2 2

RE: wintab.dll: Copyright & trademark issues.
by Patrik Stridvall Nov. 23, 2002

Nov. 23, 2002

> As I mentioned in an e-mail a couple of days back, > I'm about to start implemening a version of wintab.dll. > First I want to ask about legal issues: > > 1. trademark issues. > > wintab is a trademark. > Does this impact on the ability to implement wintab.dll No, I can't see how. Everything we will reasonable do with the name are either unrelated to trademarks or are used in reference to what is protected by the trademark. > 2. API header files. > Please look at the licence for the API files, avaialable at the > following URL: > http://www.pointing.com/Wintab/WTKIT126.ZIP > Does this allow our use of the headers, in Wine? > Does it allow the use of fragments of the headers in Wine? >From the headers: < The text and information contained in this file may be freely used, < copied, or distributed without compensation or licensing restrictions. So the headers are basicly public domain. Specifically it is compatible with the X11 license and the LGPL so no problem. We could include the files as they are without any modification at all as far as copyright is concerned. Presumably we might need some compiler related fixes though. > This is not too much of an issue, as I understand it's OK to re-write > compatible headers "In your own words". True. > 3. I am in the UK, how does this affect the copyright/trademark issues > above? It is not likely to matter very much almost regardless of there you are in the world, copyright and trademark laws are usually not that different. UK is pretty normal AFAIK. > Ok, some background about wintab: > wintab.dll is an "open industry standard" API > developed by a group of tablet manufacturers, and seems to > be currently maintained by the company LCS/Telegraphics. > Web page for wintab: http://www.pointing.com/WINTAB.HTM > LCS/Telegraphics home: http://www.pointing.com/LCS.HTM OK. Seem to contain documentation and other things nessary or useful for implementing. I can see two issues though. 1. It is not an offical Microsoft DLL so should it be part of Wine or not? IMHO yes, it seems to be widely used. However Alexandre decides. 2. How do you expect to implement this presumably very complicted DLL? Does Linux have some special libraries for supporting tablets?

2 1

gcc 2.95.3 breakage
by Johan Gill Nov. 23, 2002

Nov. 23, 2002

It seems that latest CVS does not work well with gcc 2.95.3. collect2 segfaults when linking user, it seems. Gnarl -- /Johan Gill, johane(a)lysator.liu.se

1 1

[bug 718] Executing dos DPMI programs
by Sylvain Petreolle Nov. 23, 2002

Nov. 23, 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 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: [wine-users] Can't get Unreal to work in opengl mode
by Sylvain Petreolle Nov. 23, 2002

Nov. 23, 2002

Have exactly the same error when trying to run Max Pane. Tried with --debygmsg +seh, but didn't give any clue. Perhaps weshould file a bugreport on bugs.winehq.com or try wine-devel. Anyone who knows about seh at wine-devel, could you say what makes this happen ? > err:seh:EXC_DefaultHandling Exception frame is not in stack limits => > unable > to dispatch exception. > -------------------------------------------------------------------------- > > Here is how I got it: > > I started Wine from the command line; the resolution changed from > 1024x768 > to 64x480; then I got the Unreal menu; I then selected 'options' and > then > 'advanced options'; Unreal popped-up a window where I chose 'drivers' > then > 'opengl support'; after that I got back to the desktop ('err:seh...' > line). > > Hope it helps. > > N.B. I checked my config.log again; ./tools/wineinstall did > > $ ./configure -C --enable-opengl > > All the opengl items got a 'yes' answer, except this one: > > -------------------------------------------------------------------------- > configure:6918: checking for thread-safe OpenGL version > configure:6938: gcc -o conftest -g -O2 -I/usr/X11R6/include > conftest.c > -L/usr/X11R6/lib -lGL >&5 > /tmp/ccc9a5Qz.o: In function main': > /home/fab/test/wine/configure:6930: undefined reference to > pthread_getspecific' > collect2: ld returned 1 exit status > configure:6941: $? = 1 > configure: failed program was: > #line 6925 "configure" > #include "confdefs.h" > > int > main () > { > pthread_getspecific(); > ; > return 0; > } > configure:6959: result: no > -------------------------------------------------------------------------- > > See you. > > -- > Fabrice DELENTE > E-mail : fabrice.delente(a)free.fr > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-users ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Menu selection algorithm
by Jeff Smith Nov. 23, 2002

Nov. 23, 2002

Dmitry, I still have win95-osr2 loaded on a machine. Let me know what I need to run the test on that box and I would glad to do so if this would help out. -- Jeff S >From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> >"Shachar Shemesh" <wine-devel(a)sun.consumer.org.il> wrote: > > > So, what's the problem - you ask? While my view of what should happen is > > obviously consistant with that of Wine's - i.e. - the locale should > > select which menu to use, Windows displays the English locale ONLY. The > > only way I could make it display the Hebrew one was by changing the > > language on the English one to something else (French). > >I revived my old test for FindResource and now I see what are you talking >about. >LoadStringA/W and FindResourceA/W under Win2000 do search for language >resource >in the following order: >1. Neutral language with neutral sublanguage >2. LANG_ENGLISH, SUBLANG_DEFAULT >3. LANG_ENGLISH, SUBLANG_NEUTRAL >4. Current locale lang id >5. Current locale lang id with neutral sublanguage >6. Return first in the list > >But that means that the whole our internationalization will not work, if >we will go that way. But the question I have is: had I made an error when >I did the test under Win95OSR2 or MS has changed algorithm since then? > >-- >Dmitry. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

1 0

Menu selection algorithm
by Shachar Shemesh Nov. 23, 2002

Nov. 23, 2002

Hi list, Sorry if this is slightly off topic. I am having some trouble with a sample program I keep changing to death. This program is written in VC on Windows 2000, and being run on Wine as well. I added a Hebrew menu over an already existing English(US) one. My regional settings say that my global settings are Hebrew, as are my local settings. The two menus both have the same ID, and only the language is different between them. When VC's resource editor displays the menus, it displays one with (English U.S) appended, and the Hebrew one without any extension (implying it thinks this is the default one). So, what's the problem - you ask? While my view of what should happen is obviously consistant with that of Wine's - i.e. - the locale should select which menu to use, Windows displays the English locale ONLY. The only way I could make it display the Hebrew one was by changing the language on the English one to something else (French). Wine behaves as expected. running: wine TestApp Yields an english menu, while LANG=he_IL wine TestApp yields a Hebrew one. I wouldn't worry so much, except that since we define a bug in Wine as any inconsistancy with Windows, this is a bug. I'm mostly trying to understand why Windows won't do what it's supposed to do, however. I'm using "RegisterClass" to register a class with the menu identifier passed using "MAKEINTRESOURCE", and then just calling "CreateWindow" to create the window. Anyone has any ideas or suggestions, or just an opinion whether that should worry us at all? Shachar

2 2

Re: [Bug 688] - make documentation produces only files as 'x6772.html'
by Sylvain Petreolle Nov. 23, 2002

Nov. 23, 2002

I can answer that 'make html' works beautifully and perfectly. Good job ! > ------- Additional Comments From vberon(a)mecano.gme.usherb.ca > 2002-11-22 19:32 ------- > Sylvain, Tony, Dustin, could you confirm that it works correctly now? > Alexandre > just committed my patch. > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Page fault with isspace(*p)
by John K. Hohm Nov. 23, 2002

Nov. 23, 2002

I am rewriting the regsvr stuff in dlls/comcat to make it practical to extend to ole32 and all the other COM DLLs. I have a nice simple function to skip whitespace and return the next character: static int getc_skipws(char const **p) { while (isspace(*p)) ++*p; return **p; } This gets called with **p == '['. I get a page fault in the implementation of isspace(), where the macro is testing 0x20 against the value for '[' in the __ctype_b array. What gives?

1 1

Re: [Fwd: [Bug 688] - make documentation produces only files as 'x6772.html']
by Dustin Navea Nov. 23, 2002

Nov. 23, 2002

On Fri, 2002-11-22 at 19:37, Vincent Béron wrote: > Hi guys, > > Alexandre just committed my patch concerning the documentation building > process. Could you verify it works for you? > > Thank you, > Vincent > ---- > > From: wine-bugs(a)winehq.com > To: vberon(a)mecano.gme.usherb.ca > Subject: [Bug 688] - make documentation produces only files as 'x6772.html' > Date: 08 Nov 2002 20:23:34 -0600 > > http://bugs.winehq.com/show_bug.cgi?id=688 > > > > > > ------- Additional Comments From vberon(a)mecano.gme.usherb.ca 2002-11-08 20:23 ------- > Please advise on which of the 2 attachments is the best. > Personnaly, I'd rather go with the second, because with the first one it creates > a directory with images, but those are unused. > > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > <http://bugs.winehq.com/show_bug.cgi?id=688>. > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND > INSERTED IN THE BUG DATABASE. Well, I am still working on updating my status, turns out that since I upgraded to Slackware 8.1 the default gcc wont build the jade package of sgmltools properly and so I need to upgrade to the latest slack-prepared build of gcc... Then I will try making it again... and see what happens..

1 0

Wine & Boehm garbage collector
by François-Denis Gonthier Nov. 23, 2002

Nov. 23, 2002

Hello Wine-Devel I have not filled a bug with this a some of you may already know a solution to this problem. I've a contributor to the Mono project (http://www.go-mono.com) working on the System.Windows.Forms namespace. It has been decided to use Wine to implement this assembly since the S.W.F is rather tightly bound to the Win32 API. But we are facing a nasty problem. Current Mono implementation is using Hans Boehm conservative garbage collector and Wine cannot seems to work happily with that garbage collector. The temporary solution for development is to use Mono without garbage collection. This solution however, should not even be considered when Mono and it's System.Windows.Forms implementation will go mainstream. I've joined a small test case so one can try. Wine just crash at the first call to GC_malloc. Any help or advice is appreciated. François-Denis Gonthier

4 6

where is the code that converts VARIANTS?
by Medland, Bill Nov. 23, 2002

Nov. 23, 2002

Can anyone tell me where the code is that converts a VARIANT from VT_DECIMAL to VT_BSTR? Bill

2 1

closing handle fails
by steve.lustbader＠philips.com Nov. 22, 2002

Nov. 22, 2002

I open a handle to a com port with m_hPort = ::CreateFile(_T("COM1"),GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING,FILE_FLAG_OVERLAPPED, 0); Later, when I try to close the handle, the call to CloseHandle(m_hPort) gets stuck when CloseHandle calls NtClose. What trace can I provide here to help? -Steve

1 0

Re: wine/ windows/winproc.c windows/winpos.c windo ...
by Greg Turner Nov. 22, 2002

Nov. 22, 2002

On Friday 22 November 2002 03:22 pm, Alexandre Julliard wrote: > ChangeSet ID: 6371 > 1.154 1.155 +76 -93 wine/controls/menu.c gcc 3.2 isn't happy with this: make[2]: Entering directory `/var/src/wine/dlls/user' gcc -c -I. -I. -I../../include -I../../include -march=athlon -O1 -pipe -mmmx -m3dnow -gstabs -g3 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_USER32_ -D_WINABLE_ -D_REENTRANT -o ../../controls/menu.o ../../controls/menu.c ../../controls/menu.c: In function `MENU_GetBitmapItemSize': ../../controls/menu.c:722: pointers are not permitted as case values ../../controls/menu.c:729: pointers are not permitted as case values ../../controls/menu.c:730: pointers are not permitted as case values ../../controls/menu.c:731: pointers are not permitted as case values ../../controls/menu.c:732: pointers are not permitted as case values ../../controls/menu.c:733: pointers are not permitted as case values ../../controls/menu.c:737: pointers are not permitted as case values ../../controls/menu.c:738: pointers are not permitted as case values ../../controls/menu.c:739: pointers are not permitted as case values ../../controls/menu.c:740: pointers are not permitted as case values ../../controls/menu.c:741: pointers are not permitted as case values ../../controls/menu.c: In function `MENU_DrawBitmapItem': ../../controls/menu.c:778: pointers are not permitted as case values ../../controls/menu.c:793: pointers are not permitted as case values ../../controls/menu.c:796: pointers are not permitted as case values ../../controls/menu.c:799: pointers are not permitted as case values ../../controls/menu.c:802: pointers are not permitted as case values ../../controls/menu.c:805: pointers are not permitted as case values ../../controls/menu.c:808: pointers are not permitted as case values ../../controls/menu.c:809: pointers are not permitted as case values ../../controls/menu.c:810: pointers are not permitted as case values ../../controls/menu.c:811: pointers are not permitted as case values ../../controls/menu.c:812: pointers are not permitted as case values make[2]: *** [../../controls/menu.o] Error 1 make[2]: Leaving directory `/var/src/wine/dlls/user' make[1]: *** [user] Error 2 make[1]: Leaving directory `/var/src/wine/dlls' make: *** [dlls] Error 2 These are DECLARE_HANDLE'ed values. This seems to fix it: Index: controls/menu.c =================================================================== RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.155 diff -u -r1.155 menu.c --- controls/menu.c 22 Nov 2002 21:22:16 -0000 1.155 +++ controls/menu.c 22 Nov 2002 22:13:40 -0000 @@ -719,26 +719,26 @@ { switch(LOWORD(id)) { - case HBMMENU_SYSTEM: + case (WORD)HBMMENU_SYSTEM: if (data) { bmp = (HBITMAP)data; break; } /* fall through */ - case HBMMENU_MBAR_RESTORE: - case HBMMENU_MBAR_MINIMIZE: - case HBMMENU_MBAR_MINIMIZE_D: - case HBMMENU_MBAR_CLOSE: - case HBMMENU_MBAR_CLOSE_D: + case (WORD)HBMMENU_MBAR_RESTORE: + case (WORD)HBMMENU_MBAR_MINIMIZE: + case (WORD)HBMMENU_MBAR_MINIMIZE_D: + case (WORD)HBMMENU_MBAR_CLOSE: + case (WORD)HBMMENU_MBAR_CLOSE_D: size->cx = GetSystemMetrics( SM_CXSIZE ); size->cy = GetSystemMetrics( SM_CYSIZE ); return; - case HBMMENU_CALLBACK: - case HBMMENU_POPUP_CLOSE: - case HBMMENU_POPUP_RESTORE: - case HBMMENU_POPUP_MAXIMIZE: - case HBMMENU_POPUP_MINIMIZE: + case (WORD)HBMMENU_CALLBACK: + case (WORD)HBMMENU_POPUP_CLOSE: + case (WORD)HBMMENU_POPUP_RESTORE: + case (WORD)HBMMENU_POPUP_MAXIMIZE: + case (WORD)HBMMENU_POPUP_MINIMIZE: default: FIXME("Magic 0x%08x not implemented\n", id); return; @@ -775,7 +775,7 @@ switch(LOWORD(lpitem->text)) { - case HBMMENU_SYSTEM: + case (WORD)HBMMENU_SYSTEM: if (lpitem->dwItemData) { bmp = (HBITMAP)lpitem->dwItemData; @@ -790,26 +790,26 @@ bm.bmWidth -= bmp_xoffset; } goto got_bitmap; - case HBMMENU_MBAR_RESTORE: + case (WORD)HBMMENU_MBAR_RESTORE: flags = DFCS_CAPTIONRESTORE; break; - case HBMMENU_MBAR_MINIMIZE: + case (WORD)HBMMENU_MBAR_MINIMIZE: flags = DFCS_CAPTIONMIN; break; - case HBMMENU_MBAR_MINIMIZE_D: + case (WORD)HBMMENU_MBAR_MINIMIZE_D: flags = DFCS_CAPTIONMIN | DFCS_INACTIVE; break; - case HBMMENU_MBAR_CLOSE: + case (WORD)HBMMENU_MBAR_CLOSE: flags = DFCS_CAPTIONCLOSE; break; - case HBMMENU_MBAR_CLOSE_D: + case (WORD)HBMMENU_MBAR_CLOSE_D: flags = DFCS_CAPTIONCLOSE | DFCS_INACTIVE; break; - case HBMMENU_CALLBACK: - case HBMMENU_POPUP_CLOSE: - case HBMMENU_POPUP_RESTORE: - case HBMMENU_POPUP_MAXIMIZE: - case HBMMENU_POPUP_MINIMIZE: + case (WORD)HBMMENU_CALLBACK: + case (WORD)HBMMENU_POPUP_CLOSE: + case (WORD)HBMMENU_POPUP_RESTORE: + case (WORD)HBMMENU_POPUP_MAXIMIZE: + case (WORD)HBMMENU_POPUP_MINIMIZE: default: FIXME("Magic 0x%08x not implemented\n", LOWORD(lpitem->text)); return; -- gmt "War is an ugly thing, but not the ugliest of things; the decayed and degraded state of moral and patriotic feeling which thinks that nothing is worth war is much worse. A man who has nothing for which he is willing to fight; nothing he cares about more than his own personal safety; is a miserable creature who has no chance of being free, unless made and kept so by the exertions of better persons than himself." -- John Stuart Mill

1 0

wintab.dll: Copyright & trademark issues.
by Robert North Nov. 22, 2002

Nov. 22, 2002

As I mentioned in an e-mail a couple of days back, I'm about to start implemening a version of wintab.dll. First I want to ask about legal issues: 1. trademark issues. wintab is a trademark. Does this impact on the ability to implement wintab.dll 2. API header files. Please look at the licence for the API files, avaialable at the following URL: http://www.pointing.com/Wintab/WTKIT126.ZIP Does this allow our use of the headers, in Wine? Does it allow the use of fragments of the headers in Wine? This is not too much of an issue, as I understand it's OK to re-write compatible headers "In your own words". 3. I am in the UK, how does this affect the copyright/trademark issues above? Ok, some background about wintab: wintab.dll is an "open industry standard" API developed by a group of tablet manufacturers, and seems to be currently maintained by the company LCS/Telegraphics. Web page for wintab: http://www.pointing.com/WINTAB.HTM LCS/Telegraphics home: http://www.pointing.com/LCS.HTM I also found this organiation that LCS belongs to interesting: http://www.interop.org/ Many thanks -Rob.

1 0

Re: wine and asyncronous file i/o
by Martin Fuchs Nov. 22, 2002

Nov. 22, 2002

Thanks, Martin! > EOF conditions are nasty. Seems we got it wrong... Please try the > following patch (it should solve your problem). However I guess it needs > regression testing because it changes overlapped ReadFile() semantics > drastically. If this condition turns out to be right, we may actually be > able to get rid of the special treatment of sockets in > FILE_AsyncReadService(). Yes, the file read routine seems to work now. However the application doesn't run completely yet. But that's another problem, I think... -- Martin Fuchs martin-fuchs(a)gmx.net

1 0

wm_mousehover bug fix.....
by Mike Hearn Nov. 22, 2002

Nov. 22, 2002

Sorry to kind of spam, it was much easier to fix it than I thought it would be. Hacking wine isn't so hard after all...... input.c line 970 should be: PostMessageA(TrackingList[i].tme.hwndTrack, WM_MOUSEHOVER, get_key_state() , (pos.y << 8) + (pos.x)); I didn't think it was worth sending to wine-patches as it's just a 1 line fix and I didn't do it against wine cvs, but the last tarball release. That solves all my mouse handling issues with the ASV, so I'm a happy person once more. If somebody could apply that patch that'd be fab. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

4 3

RFC: console & curses
by Eric Pouech Nov. 22, 2002

Nov. 22, 2002

I did send a couple of days ago a first patch about the (n)curses backend to wineconsole Alexandre commented a few implementation issues in it, which may change a bit what I started with and how the wineconsole should behave: console creation can be invoked from different contexts: 1/ the program calls AllocConsole 2/ the user starts wine thru wineconsole for his/her (favorite) CUI app (using from command line something like 'wineconsole foo') 3/ (N1) the program forks a child with CREATE_NEW_CONSOLE flags set in CreateProcess 4/ the program doesn't request anything on the other hand, wineconsole is now able to handle two types of backend for the user interface: A/ USER: the one already in place B/ Curses: the new one using (n)curses and a regular term for display (N2) C/ no wineconsole support => by default, the windows input & output streams are hooked to stdin and stdout, but we don't provide full console support - cursor motion, screen reading... now the final question, how to choose between A, B and C. the proposal is to fix the choice with: 1 => A 2 => B 3 => A 4 => C why such a directive proposal ? 4 => C is rather natural and doesn't need further explanation (one day, we could envisage to support it no longer, but that's another story) 1 => A greatly facilitates the console creation (ncurses requires both terminal control and moreover to keep the process group leader running as long as all the children - hooked to the same terminal - are running). Very few programs use AllocConsole (and even use it). The only issue may be with winedbg which may allocate its own console on startup (N3) 2 => B we could easily add 2 => A too (with some wineconsole parameters). Moreover, if the user wants to have the console in a specific xterm, it's doable with xterm -e 'wineconsole blablabla' 3 => A here again it's easier to deal with. if trying to run a curses backend, we should ensure that two different wineconsoles are not currently hooked to the same terminal If you have any comments, speak up now !! A+ N1: 3/ can be seen from various aspects as a specific case of 1/, but implementation could implement it as 2/) N2: one could try running wineconsole USER backend with ttydrv instead of x11drv, but that's out of the scope of this (maybe for Dimi's fun projects list N3: IMO what's missing is that winedbg should check if has inheried a real console. If so, it should detach from it and recreate a new one.

3 16

Re: Rosetta, wine, sound bug?
by Jeff Smith Nov. 22, 2002

Nov. 22, 2002

>From: Sylvain Petreolle <spetreolle(a)yahoo.fr> > > > bash-2.05a$ wine -debugmsg +winmm,+wave,+dsound Rosetta.exe > > trace:winmm:WINMM_LibMain 0x41630000 0x1 (nil) > > trace:winmm:WINMM_CreateIData Created IData (0x403f0ef8) > > trace:winmm:MMDRV_Install ('wineoss.drv', 'wineoss.drv', mapper=N); > > trace:winmm:MMDRV_Install Got 32 bit func 'auxMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'mixMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'midMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'modMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'widMessage' > > trace:winmm:MMDRV_Install Got 32 bit func 'wodMessage' > > trace:winmm:MMDRV_GetDescription32 Can't find file wineoss.drv > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Shouldn't happen. > > trace:winmm:MMDRV_Install wineoss.drv => No description I get similar errors with MMDRV_GetDescription32. I assumed they were happening because the actual file wineoss.drv does not exist. Further, I assumed that MMDRV_GetDescription32 tries to get the description from locating the relevant record in the actual file. Please note that I have not had a chance to verify any of this. I have just recently taken an interest in wine's sound libraries, and would be glad to help out where I can. -- Jeff S _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

Rosetta, wine, winex bug?
by ladies_man＠earthlink.net Nov. 22, 2002

Nov. 22, 2002

I have a problem with wine, and everyone says that it is a bug, so I suppose that it would have some relevance here. Any help or solutions would be helpful. I have three programs, wine, winex, and Rosetta. When I combine winex with Rosetta sound works fine, but then the display is royally messed up. When I use wine with Rosetta, the sound fails but everything else works beautifully. Computer Information: Make: Dell Inspiron 3800 Laptop Processor: 700mhz Celeron Ram: 128mb Distribution: Gentoo Linux, stage 1, highly optimized and custom compiled. Video Card: ATI Rage Mobility Sound Card: ESS Maestro3 Devices: /dev/mixer /dev/dsp /dev/cdroms/cdrom0 Here is my Wine config file: [Drive C] "Path" = "${HOME}/.wine/fake_windows" "Type" = "hd" "Label" = "MS-DOS" "Filesystem" = "win95" ;;[Drive D] ;;"Path" = "/path/to/drive_d" ;;"Type" = "hd" ;;"Label" = "LABEL" ;;"Filesystem" = "win95" [Drive E] "Path" = "/mnt/cdrom" "Type" = "cdrom" "Label" = "CD-Rom" "Filesystem" = "win95" "Device" = "/dev/cdroms/cdrom0" [Drive F] "Path" = "/tmp" "Type" = "hd" "Label" = "Tmp Drive" "Filesystem" = "win95" [Drive H] "Path" = "${HOME}" "Type" = "network" "Label" = "Home" "Filesystem" = "win95" [Drive Z] "Path" = "/" "Type" = "network" "Label" = "Root" "Filesystem" = "win95" [wine] "Windows" = "c:\\Windows" "System" = "c:\\Windows\\System" "Temp" = "f:\\" "Path" = "c:\\Windows;c:\\Windows\\System;f:\\;h:\\;z:\\" "Profile" = "c:\\Windows\\Profiles\\Administrator" "GraphicsDriver" = "x11drv" ; Wine doesn't pass directory symlinks to Windows programs by default. ; Enabling this may crash some programs that do recursive lookups of a whole ; subdir tree in case of a symlink pointing back to itself. ;"ShowDirSymlinks" = "1" "ShellLinker" = "wineshelllink" # <wineconf> [Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win20,win30,win31)" }, ;"Windows" = "win98" ; DOS version to imitate ;"DOS" = "6.22" ; Be careful here, wrong DllOverrides settings have the potential ; to pretty much kill your setup. [DllOverrides] "rpcrt4" = "builtin, native" "oleaut32" = "builtin, native" "ole32" = "builtin, native" "commdlg" = "builtin, native" "comdlg32" = "builtin, native" "ver" = "builtin, native" "version" = "builtin, native" "shell" = "builtin, native" "shell32" = "builtin, native" "shfolder" = "builtin, native" "shlwapi" = "builtin, native" "shdocvw" = "builtin, native" "lzexpand" = "builtin, native" "lz32" = "builtin, native" "comctl32" = "builtin, native" "commctrl" = "builtin, native" "advapi32" = "builtin, native" "crtdll" = "builtin, native" "mpr" = "builtin, native" "winspool.drv" = "builtin, native" "ddraw" = "builtin, native" "dinput" = "builtin, native" "dsound" = "builtin, native" "opengl32" = "builtin, native" "msvcrt" = "native, builtin" "msvideo" = "builtin, native" "msvfw32" = "builtin, native" "mcicda.drv" = "builtin, native" "mciseq.drv" = "builtin, native" "mciwave.drv" = "builtin, native" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" "msacm.drv" = "builtin, native" "msacm" = "builtin, native" "msacm32" = "builtin, native" "midimap.drv" = "builtin, native" ; you can specify applications too "notepad.exe" = "native, builtin" ; default for all other dlls "*" = "native, builtin" [x11drv] ; Number of colors to allocate from the system palette "AllocSystemColors" = "100" ; Use a private color map "PrivateColorMap" = "N" ; Favor correctness over speed in some graphics operations "PerfectGraphics" = "N" ; Color depth to use on multi-depth screens ;;"ScreenDepth" = "16" ; Name of X11 display to use ;;"Display" = ":0.0" ; Allow the window manager to manage created windows "Managed" = "N" ; Use a desktop window of 640x480 for Wine "Desktop" = "640x480" ; Use XFree86 DGA extension if present ; (make sure /dev/mem is accessible by you !) "UseDGA" = "Y" ; Use XShm extension if present "UseXShm" = "Y" ; Use XVidMode extension if present "UseXVidMode" = "Y" ; Enable DirectX mouse grab "DXGrab" = "N" ; Create the desktop window with a double-buffered visual ; (useful to play OpenGL games) "DesktopDoubleBuffered" = "N" ; Code page used for captions in managed mode ; 0 means default ANSI code page (CP_ACP == 0) "TextCP" = "0" ; Use this if you have more than one port for video on your setup ; (Wine uses for now the first 'input image' it finds). ;; "XVideoPort" = "43" ; Run in synchronous mode (useful for debugging X11 problems) ;;"Synchronous" = "Y" [fonts] ;Read the Fonts topic in the Wine User Guide before adding aliases ;See a couple of examples for russian users below "Resolution" = "96" "Default" = "-adobe-helvetica-" "DefaultFixed" = "fixed" "DefaultSerif" = "-adobe-times-" "DefaultSansSerif" = "-adobe-helvetica-" ;; default TrueType fonts with russian koi8-r encoding ;"Default" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultFixed" = "-monotype-courier new-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultSerif" = "-monotype-times new roman-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultSansSerif" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" ;; default cyrillic bitmap X fonts ;"Default" = "-cronyx-helvetica-" ;"DefaultFixed" = "fixed" ;"DefaultSerif" = "-cronyx-times-" ;"DefaultSansSerif" = "-cronyx-helvetica-" ; the TrueType font dirs you want to make accessible to wine [FontDirs] ;"dir1" = "/usr/X11R6/lib/X11/fonts/TrueType" ;"dir2" = "/usr/share/fonts/truetype" ;"dir3" = "/usr/X11R6/lib/X11/fonts/TT" ;"dir4" = "/usr/share/fonts/TT" [serialports] "Com1" = "/dev/ttyS0" "Com2" = "/dev/ttyS1" "Com3" = "/dev/ttyS2" "Com4" = "/dev/modem" [parallelports] "Lpt1" = "/dev/lp0" [ppdev] ;; key: io-base of the emulated port ;; value : parport-device{,timeout} ;; timeout for auto closing an open device ( not yet implemented) ;"378" = "/dev/parport0" ;"278" = "/dev/parport1" ;"3bc" = "/dev/parport2" [spooler] "FILE:" = "tmp.ps" "LPT1:" = "|lpr" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" [ports] ;"read" = "0x779,0x379,0x280-0x2a0" ;"write" = "0x779,0x379,0x280-0x2a0" [Debug] ;"RelayExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection" ;"RelayInclude" = "user32.CreateWindowA" ;"SnoopExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection" ;"SpyExclude" = "WM_SIZE;WM_TIMER;" [registry] ;These are all booleans. Y/y/T/t/1 are true, N/n/F/f/0 are false. ;Defaults are read all, write to Home ; Global registries (stored in /etc) "LoadGlobalRegistryFiles" = "Y" ; Home registries (stored in ~user/.wine/) "LoadHomeRegistryFiles" = "Y" ; Load Windows registries from the Windows directory "LoadWindowsRegistryFiles" = "Y" ; TRY to write all changes to home registries "WritetoHomeRegistryFiles" = "Y" ; Registry periodic save timeout in seconds ; "PeriodicSave" = "600" ; Save only modified keys "SaveOnlyUpdatedKeys" = "Y" [Tweak.Layout] ;; supported styles are 'Win31'(default), 'Win95', 'Win98' ;; this has *nothing* to do with the windows version Wine returns: ;; set the "Windows" value in the [Version] section if you want that. "WineLook" = "Win95" [Console] ;"Drivers" = "tty" ;"XtermProg" = "nxterm" ;"InitialRows" = "25" ;"InitialColumns" = "80" ;"TerminalType" = "nxterm" [Clipboard] "ClearAllSelections" = "0" "PersistentSelection" = "1" ; List of all directories directly contain .AFM files [afmdirs] "1" = "/usr/share/ghostscript/fonts" "2" = "/usr/share/a2ps/afm" "3" = "/usr/share/enscript" "4" = "/usr/X11R6/lib/X11/fonts/Type1" [WinMM] "Drivers" = "wineoss.drv" #"Drivers" = "winearts.drv" "WaveMapper" = "msacm.drv" "MidiMapper" = "midimap.drv" [dsound] ;; HEL only: Number of waveOut fragments ahead to mix in new buffers. ;"HELmargin" = "5" ;; HEL only: Number of waveOut fragments ahead to queue to driver. ;"HELqueue" = "5" ;; Max number of fragments to prebuffer ;"SndQueueMax" = "28" ;; Min number of fragments to prebuffer ;"SndQueueMin" = "12" ;; Kazaa Lite [AppDefaults\\Kazaa.exe\\DllOverrides] "shdocvw" = "native" "shlwapi" = "native" "urlmon" = "native" # </wineconf> Here is the output from the wine command: bash-2.05a$ wine -debugmsg +warn,+winmm,+winoss,+err,+fixme .wine/fake_windows/Program\ Files/The\ Rosetta\ Stone/The\ Rosetta\ Stone/Rosetta.exe trace:winmm:WINMM_LibMain 0x41630000 0x1 (nil) trace:winmm:WINMM_CreateIData Created IData (0x403f10a8) trace:winmm:MMDRV_Install ('wineoss.drv', 'wineoss.drv', mapper=N); trace:winmm:MMDRV_Install Got 32 bit func 'auxMessage' trace:winmm:MMDRV_Install Got 32 bit func 'mixMessage' trace:winmm:MMDRV_Install Got 32 bit func 'midMessage' trace:winmm:MMDRV_Install Got 32 bit func 'modMessage' trace:winmm:MMDRV_Install Got 32 bit func 'widMessage' trace:winmm:MMDRV_Install Got 32 bit func 'wodMessage' trace:winmm:MMDRV_GetDescription32 Can't find file wineoss.drv trace:winmm:MMDRV_Install wineoss.drv => No description trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 6 dev for (wineoss.drv:Aux) trace:winmm:MMDRV_InitPerType Setting min=0 max=6 (ttop=6) for (wineoss.drv:Aux)trace:winmm:MMDRV_InitPerType Aux:Trans[0] -> w ineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[1] -> wineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[2] -> wineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[3] -> wineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[4] -> wineoss.drv trace:winmm:MMDRV_InitPerType Aux:Trans[5] -> wineoss.drv trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wineoss.drv:Mixer) trace:winmm:MMDRV_InitPerType Setting min=0 max=1 (ttop=1) for (wineoss.drv:Mixer) trace:winmm:MMDRV_InitPerType Mixer:Trans[0] -> wineoss.drv trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 0 dev for (wineoss.drv:MidiIn) trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 0 dev for (wineoss.drv:MidiOut) trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wineoss.drv:WaveIn) trace:winmm:MMDRV_InitPerType Setting min=0 max=1 (ttop=1) for (wineoss.drv:WaveIn) trace:winmm:MMDRV_InitPerType WaveIn:Trans[0] -> wineoss.drv trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wineoss.drv:WaveOut) trace:winmm:MMDRV_InitPerType Setting min=0 max=1 (ttop=1) for (wineoss.drv:WaveOut) trace:winmm:MMDRV_InitPerType WaveOut:Trans[0] -> wineoss.drv trace:winmm:MMDRV_Install ('wavemapper', 'msacm.drv', mapper=Y); trace:winmm:MMDRV_Install Got 32 bit func 'widMessage' trace:winmm:MMDRV_Install Got 32 bit func 'wodMessage' trace:winmm:MMDRV_GetDescription32 Can't find file msacm.drv trace:winmm:MMDRV_Install msacm.drv => No description trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wavemapper:WaveIn) trace:winmm:MMDRV_InitPerType Setting min=0 max=0 (ttop=1) for (wavemapper:WaveIn) trace:winmm:MMDRV_InitPerType WaveIn:Trans[-1] -> wavemapper trace:winmm:MMDRV_InitPerType WaveIn:Trans[0] -> wineoss.drv trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (wavemapper:WaveOut) trace:winmm:MMDRV_InitPerType Setting min=0 max=0 (ttop=1) for (wavemapper:WaveOut) trace:winmm:MMDRV_InitPerType WaveOut:Trans[-1] -> wavemapper trace:winmm:MMDRV_InitPerType WaveOut:Trans[0] -> wineoss.drv trace:winmm:MMDRV_Install ('midimapper', 'midimap.drv', mapper=Y); trace:winmm:MMDRV_Install Got 32 bit func 'modMessage' trace:winmm:MMDRV_GetDescription32 Can't find file midimap.drv trace:winmm:MMDRV_Install midimap.drv => No description trace:winmm:MMDRV_InitPerType DRVM_INIT => 00000000 trace:winmm:MMDRV_InitPerType Got 1 dev for (midimapper:MidiOut) trace:winmm:MMDRV_InitPerType Setting min=0 max=0 (ttop=0) for (midimapper:MidiOut) trace:winmm:MMDRV_InitPerType MidiOut:Trans[-1] -> midimapper trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:waveOutGetDevCapsA (0 0x406b22c4 52)! trace:winmm:MMDRV_Message (WaveOut 0 4 0x00000000 0x406b22c4 0x00000034 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=4 usr=0x00000000 p1=0x406b22c4 p2=0x00000034 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutMessage ((nil), 2058, 1080763140, 0) trace:winmm:MMDRV_PhysicalFeatures (0x403f2594, 080a, 406b2304, 00000000) trace:winmm:MMDRV_Message (WaveOut 0 2058 0x00000000 0x406b2304 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=2058 usr=0x00000000 p1=0x406b2304 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open (0x4043334c, 0, Out, 0x40433338, 43630D38, 404330B0, 00030080, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=22050, nAvgBytesPerSec=44100, nBlockAlign=2, wBitsPerSample=8, cbSize=0 trace:winmm:WAVE_Open cb=43630d38 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b21a0 0x406b2220 0x00030080 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b21a0 p1=0x406b2220 p2=0x00030080 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutSetVolume (0000, ffffffff); trace:winmm:MMDRV_Message (WaveOut 0 17 0x00000000 0xffffffff 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=17 usr=0x00000000 p1=0xffffffff p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b21c8 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b21c8 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutGetDevCapsA (4294967294 0x406b1f2c 52)! trace:winmm:waveOutGetDevCapsA (0 0x406b2068 52)! trace:winmm:MMDRV_Message (WaveOut 0 4 0x00000000 0x406b2068 0x00000034 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=4 usr=0x00000000 p1=0x406b2068 p2=0x00000034 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open ((nil), 0, Out, 0x40430808, 00000000, 00000000, 00000001, 32); trace:winmm:WAVE_Open WAVE_FORMAT_QUERY requested ! trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b1fb4 0x406b2034 0x00000001 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b1fb4 p1=0x406b2034 p2=0x00000001 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=(nil) trace:winmm:WAVE_Open (0x40430804, 0, Out, 0x40430808, 00000000, 00000000, 00000002, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b1fac 0x406b202c 0x00000002 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b1fac p1=0x406b202c p2=0x00000002 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutGetVolume (8000, 404307f8); trace:winmm:MMDRV_Message (WaveOut 0 16 0x406b1fd4 0x404307f8 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=16 usr=0x406b1fd4 p1=0x404307f8 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b1fd4 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b1fd4 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open (0x40430804, 0, Out, 0x40430808, 00000000, 00000000, 00000002, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b2210 0x406b2290 0x00000002 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b2210 p1=0x406b2290 p2=0x00000002 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutGetVolume (8000, 406b233c); trace:winmm:MMDRV_Message (WaveOut 0 16 0x406b2238 0x406b233c 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=16 usr=0x406b2238 p1=0x406b233c p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b2238 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b2238 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:WAVE_Open (0x40430804, 0, Out, 0x40430808, 00000000, 00000000, 00000002, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b1ec0 0x406b1f40 0x00000002 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b1ec0 p1=0x406b1f40 p2=0x00000002 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutPrepareHeader (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b1ee8 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b1ee8 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b1ee8 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b1ee8 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b1ee8 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b1ee8 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b1ee8 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b1ee8 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:waveOutWrite (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b1ee8 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b1ee8 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b1ee8 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b1ee8 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b1ee8 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b1ee8 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b1ee8 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b1ee8 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutReset (0x8000); trace:winmm:MMDRV_Message (WaveOut 0 12 0x406b1ee8 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=12 usr=0x406b1ee8 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b1ee8 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b1ee8 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b1ee8 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b1ee8 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b1ee8 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b1ee8 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b1ee8 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b1ee8 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b1ee8 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b1ee8 p1=0x00000000 p2=0x00000000 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:WAVE_Open (0x40430804, 0, Out, 0x40430808, 00000000, 00000000, 00000002, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=44100, nAvgBytesPerSec=176400, nBlockAlign=4, wBitsPerSample=16 , cbSize=0 trace:winmm:WAVE_Open cb=00000000 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406b22b8 0x406b2338 0x00000002 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406b22b8 p1=0x406b2338 p2=0x00000002 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutPrepareHeader (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b22e0 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b22e0 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b22e0 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b22e0 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b22e0 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b22e0 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutPrepareHeader (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 7 0x406b22e0 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=7 usr=0x406b22e0 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x2 (nil) trace:winmm:waveOutWrite (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b22e0 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b22e0 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b22e0 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b22e0 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b22e0 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b22e0 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutWrite (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 9 0x406b22e0 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406b22e0 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutReset (0x8000); trace:winmm:MMDRV_Message (WaveOut 0 12 0x406b22e0 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=12 usr=0x406b22e0 p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x40430824, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b22e0 0x40430824 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b22e0 p1=0x40430824 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x404308b8, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b22e0 0x404308b8 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b22e0 p1=0x404308b8 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x4043094c, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b22e0 0x4043094c 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b22e0 p1=0x4043094c p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutUnprepareHeader (0x8000, 0x404309e0, 32); trace:winmm:MMDRV_Message (WaveOut 0 8 0x406b22e0 0x404309e0 0x00000020 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=8 usr=0x406b22e0 p1=0x404309e0 p2=0x00000020 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x406b22e0 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x406b22e0 p1=0x00000000 p2=0x00000000 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x3 (nil) trace:winmm:waveOutSetVolume (0000, ffffffff); trace:winmm:MMDRV_Message (WaveOut 0 17 0x00000000 0xffffffff 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=17 usr=0x00000000 p1=0xffffffff p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutSetVolume (0000, ffffffff); trace:winmm:MMDRV_Message (WaveOut 0 17 0x00000000 0xffffffff 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=17 usr=0x00000000 p1=0xffffffff p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WINMM_LibMain 0x41630000 0x0 0x1 bash-2.05a$ Now I have no clue what the problem is, many people have been working on this and none of them can figure it out. Both winex 20020807 and the 2.2.1 version have used the oss.drv's and they work. If anyone can help solve this problem I would greatly appreciate it, and if it is a bug, I hope you can fix it quickly. -- ---------------------------------- E-Mail: ladies_man(a)earthlink.net Date: 20-Nov-2002 Time: 15:54:44 This message was sent by XFMail ---------------------------------- -- ---------------------------------- E-Mail: ladies_man(a)earthlink.net Date: 20-Nov-2002 Time: 15:59:39 This message was sent by XFMail ----------------------------------

4 7

winspool.drv again
by Dimitrie O. Paun Nov. 22, 2002

Nov. 22, 2002

Alexandre, The winspool.drv issue is a lot more serious than the in-tree execution. This one screws things up badly for the PuTTY build system. Should we modify winebuild to try to link with winspool.drv, and if that fails with winspool.dll when -lwinspool is given? (or the other way around, I don't know) I'd really appreciate help on this one, so I can send the patch out. -- Dimi.

4 4

Wine and IrDA via Virtual Com Port
by Ryan Reading Nov. 22, 2002

Nov. 22, 2002

Hi all, This is my first time on this list. I've been playing around with Wine with quite a bit of success, but I've ran into a problem when trying to get an old program that uses IR to work correctly. I've already post on comp.emulators.ms-windows.wine and they referred my problem here. Here is the info that I have... For the record, I am running Wine 20021031. The program is based on the commercial Greenleaf Comm++ libraries. It is designed to be utilized in Windows on top of a *virtual* Com port running IrDA. The software itself knows nothing of IrDA, it's the *virtual* Com port's responsibility to provide that. Apparently it uses IrCOMM and TinyTP, but I'm just learning exactly what that means. I setup Linux to run IrDA through /dev/ttyS0 (the physical IR serial device) on /dev/ircomm0 (the IrDA device). I set "Com4" = "/dev/ircomm0". in the wine config file. I run the software with "--debugmsg +comm,+file" and look at the output. The software gets to a point where it performs some basic Serial port setup (SetupComm(), GetCommState(), SetCommState(), etc) and then I get the following... <snip> trace:file:Writefile 192 0x420b1190 14 0x4230a200 0x430a1530 trace:file:Writefile Overlapped not specified or invalid event flag <-- this is the interesting line trace:ClearCommError handle 0xc0 cbInQue = 0 cbOutQue = 0 ... last line repeated until timeout </snip> ( big apologies for not having a larger dump ) The pointer to the OVERLAPPED structure in this function is not set to NULL, but the hEvent member of that struct is set to ZERO (0), which seems to be the problem. I don't know why that member variable is set to ZERO (0), but that obviously keeps me from actually writing anything to the IR port. So my question involves how to approach this problem. I actually modified the Wine code to "overlook" the bad hEvent variable in WriteFile(), ReadFile(), and GetOverlappedResult() just for kicks to see what would happen. When I do that, it actually sends stuff over the IR connection and processes more ( additional ReadFile[Ex](), WriteFile[Ex](), GetOverlappedResult() calls ), but obviously the handshaking doesn't complete correctly since I'm ignoring the error checking. Could my problem be in the way IrDA is setup ( i.e. what is the correct way to emulate a Windows *virtual* COM port running IrDA in Wine )?? Any advice or information on this problem would be really appreciated. Thanks. -- Ryan

2 1

Debugging mouse messages
by Mike Hearn Nov. 22, 2002

Nov. 22, 2002

Hi, After setting up my dual crossover/winehq (last tarball release) installation, I tried doing some traces on IE with the adobe svg plugin. I can't figure out why I am getting this: trace:msg:MSG_peek_message got type 5 msg 113 hwnd 0 wp 8 lp 41380d58 trace:cursor:X11DRV_GetCursorPos pointer at (661,442) trace:msg:MSG_peek_message got type 5 msg 2a1 hwnd 10042 wp 0 lp 0 trace:msg:GetKeyState key (0x12) -> 0 trace:msg:WINPROC_CallProc32ATo32W func 0x413e9024 (hwnd=00010039,msg=WM_USER+000b,wp=00000000,lp=00000000) over and over again when the mouse is not moving. It appears that IE (the constant polling for the cursor position occurs when showing a 404 screen too) has different mouse behaviour to other apps, for instance in WebFerret the X11DRIV_GetCursorPos function is only called when the mouse actually moves. In IE, it's called seemingly on a timer (i'd guess every .25 or .5 seconds) even when the cursor is over a toolbar (though not the address bar oddly). I'm also confused by the reference to WINPROC_CallProc32ATo32W, is this normal? Google says it's used as part of 32bit<->16bit thunking, but there is no 16bit code here as far as I'm aware. Any ideas? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ

2 3

Re: Screenshots
by Brian Vincent Nov. 22, 2002

Nov. 22, 2002

I've been meaning to put something together for a few days here.. > shots to Brian isn't the best way to go about it as nobody knows who has > sent what. Have you actually got any yet Brian? First, take a look at: http://www.theshell.com/~vinn/ss Quite a few folks have sent stuff in. Now, after looking at so many screenshots and trying to evaluate them for content I've realized a few things.. 1) We're absolutely going to have to insist on 800x600 resolution. Thanks for all the ones so far, but really the only usable ones are the 800x600. (There are exceptions, such as Mike's Quicktime one that can be resized nicely.) 2) Screenshots of an application doing something are the way to go. For instance, the one Mike just sent me showing Adobe's SVG plug-in in IE is WAY cool. Unfortunately it's not usable because of the resolution. Even a pull-down menu being pulled down is enough. 3) Cluttered desktops suck. You don't need to have 3 terminal windows, Mozilla, and everything else in the background. For the most part I think the screenshots have followed that rule closely. Okay, here's the deal.. Thomas Wickline volunteered to do screenshots of these apps: Office 2000 and everything in it lotus notes Quicken Quick Books visio Carlos Lozano did shots for the "gold" list apps. I'm going to ask him for some more here in the future.. (unbeknowst to him) The following would be nice to see: any game the exact same screenshot Mike Hearn sent of IE/SVG except at 800x600 Adobe Photoshop Anything else is fair game. I'll put screenshots on that URL above, so check there before doing any. -brian

6 5

Interesting control samples
by Mehmet YASAR Nov. 22, 2002

Nov. 22, 2002

Hi, I just found http://www.codejock.com/, they seems to provide a Toolkit to enhance any app (giving Microsoft's new UI look), the most interesting for Wine is that you can download 40 basic samples of different controls. Few notes : - A quick test shows that Wine can't launch any exe. - No source code is included I thought it may be a good test case ... Here is the list of samples included in XTSetupSamples_1931.exe : AccelDemo.exe BrowseDialog.exe BrowseEdit.exe Button.exe CaptionBar.exe CheckListBox.exe ColorPicker.exe CommonControls.exe CoolMenu.exe DockingDemo.exe EditListBox.exe FlatCombo.exe FlatHeader.exe FlatTabCtrl.exe FlatTabView.exe GUI_Explorer.exe GUI_Outlook.exe GUI_VisualStudio.exe GUI_WinZip.exe HexEdit.exe HyperLink.exe ListCtrl.exe MaskEdit.exe MDITabWindows.exe MultiFrameDocking.exe OutlookBar.exe Pager.exe PrintPreview.exe SearchOptions.exe SplitterWindow.exe StatusBar.exe TabbedView.exe TabCtrlBar.exe TabCtrl.exe TipOfTheDay.exe TipWindow.exe TrayIconDemo.exe TrayIconDlg.exe TreeCtrl.exe WindowPos.exe Mehmet

1 0