December 2004 - Wine-Devel - list.winehq.org

Re: Jack Bug

by Christian Britz

Christian Britz schrieb: >No. Maybe my server has not replicated yet. > >I'll inform you tommorow about success. > > does work now

Dec. 10, 2004

Office2K and current Wine

by Igor Shmukler

Hello, We have problems running most programs including Office with latest wine (20041201) we built from sources on RH9. Following error message appears when running installer: $ fixme:msi:MsiEnableLogA 00000516 "c:\\windows\\temp\\Office 2000 SR-1 Premium Setup(0006)_MsiExec.txt" 00000000 fixme:msi:MsiInstallProductW L"Z:\\home\\ser\\.wine\\office\\data1.msi" L"" fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"AppSearch" fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"ResolveSource" fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting fixme:msi:HANDLE_CustomType1 DATABASE NOT THREADSAFE... not starting wine: Unhandled exception (thread 000b), starting debugger... Is this a known issue? Any pointers would be most welcome. Thank you in advance, Igor.

Dec. 9, 2004

Re: tools/wineinstall

by Christian Britz

Bon soir Vincent, dear all, Vincent Béron schrieb: >That's because it's unable to determine how it was installed in the >first place, and where the files are located. The "wine" program itself >is usually easy to find, but not necessarily so for the dlls and other >installed files. > >rpm -e, the equivalent under Debian, make uninstall (from original >source tree), etc. are all different ways to install Wine. > > Well, it shouldn't be too hard to detect that or at least offer manual choice. Wait a sec ... this would mean I probably could do it myself, OMG! ;-) Will changes to wineinstall be accepted at this point of time? Regards, Christian P.S.: apt-get [--purge] remove on debian.

Dec. 9, 2004

Re: Hang in usr1_handler (ptrace issue?)

by Jesse Allen

On Mon, Dec 06, 2004 at 01:19:37PM -0700, Jesse Allen wrote: > On Mon, 06 Dec 2004 18:23:28 +0000, Mike Hearn <mh(a)codeweavers.com> wrote: > > Hi, > > > > Lately I've been seeing hangs of this form: > > ... > > in other words, whilst waiting on some server object it was suspended. I > > am running the FC3 kernel "2.6.9-1.681_FC3". Is this what the > > previously discussed ptrace change would look like? If so I may need to > > ask Red Hat to do an errata or something. I saw that in 2.6.10-rc3 > > another ptrace change went in, so it may be that it's now fixed. > > > > thanks -mike > > > > > > > This may very well be the remaining problem for Warcraft 3. I'll > check my log again to see if there is a similarity. If anyone wants > this log, I can send it to you -- It's 500 KB. I can't tell if there is any similarity cause that function doesn't show up. If anyone wants the log it's here: http://www.chez.com/alors/loop.log.bz2 (copy and paste url into browser, don't click, it won't work) Anyone has any clue what is going on here? This is still related to the ptrace changes.

Dec. 9, 2004

Re: dlls/gdi/tests/metafile.c warning about test_mf_PatternBrush

by Walt Ogburn

Hi Gerald, It's commented out because the test currently crashes under Wine. I submitted one patch earlier, but the metafile records weren't the same as the correct Windows values and it didn't get committed. Now that there's a test I'll work on another patch. - Walter On Thu, 9 Dec 2004, Gerald Pfeifer wrote: > The following patch to dlls/gdi/tests/metafile.c > > revision 1.3 > date: 2004/12/09 11:37:59; author: julliard; state: Exp; lines: +236 -0 > Walt Ogburn <reuben(a)ugcs.caltech.edu> > Added some tests for win-format metafiles. > > introduces the following warning: > > metafile.c:381: warning: `test_mf_PatternBrush' defined but not used > > Should we put #ifdefs around the definition, or enable the following > code in the main test function? > > /* Crashes under wine: */ > /* test_mf_PatternBrush(); */ > > Another option would be not to make this function static. > > Gerald >

Dec. 9, 2004

Re: include file cleanup : another step

by Robert Shearman

Rémi Assailly wrote: > I moved some defines, ttydrv will not use gdi.h any longer. > I notice that some headers are declared twice, I removed useless > declarations. > > Changelog: > * moved some defines from gdi.h > >------------------------------------------------------------------------ > >--- dlls/gdi/palette.c~ 2004-10-18 23:18:58.000000000 +0200 >+++ dlls/gdi/palette.c 2004-12-09 14:14:52.000000000 +0100 >@@ -37,6 +37,11 @@ > #include "wine/debug.h" > #include "winerror.h" > >+/* palette object */ >+#define NB_RESERVED_COLORS 20 /* number of fixed colors in system palette */ >+ >+#define PC_SYS_USED 0x80 /* palentry is used (both system and logical) */ >+ > WINE_DEFAULT_DEBUG_CHANNEL(palette); > > static INT PALETTE_GetObject( HGDIOBJ handle, void *obj, INT count, LPVOID buffer ); > >--- include/gdi.h~ 2004-03-04 21:41:13.000000000 +0100 >+++ include/gdi.h 2004-12-09 19:01:20.154559672 +0100 >@@ -83,14 +83,6 @@ > SEGPTR segptr_bits; /* segptr to DIB bits */ > } BITMAPOBJ; > >-/* palette object */ >- >-#define NB_RESERVED_COLORS 20 /* number of fixed colors in system palette */ >- >-#define PC_SYS_USED 0x80 /* palentry is used (both system and logical) */ >-#define PC_SYS_RESERVED 0x40 /* system palentry is not to be mapped to */ >-#define PC_SYS_MAPPED 0x10 /* logical palentry is a direct alias for system palentry */ >- > typedef struct tagPALETTEOBJ > { > GDIOBJHDR header; > >--- dlls/ttydrv/palette.c~ 2004-12-09 18:57:42.835597176 +0100 >+++ dlls/ttydrv/palette.c 2004-12-09 14:27:48.000000000 +0100 >@@ -22,10 +22,14 @@ > > #include <stdlib.h> > >-#include "gdi.h" >-#include "winbase.h" > #include "ttydrv.h" > #include "wine/debug.h" >+#include "wine/wingdi16.h" >+ >+/* palette object */ >+#define NB_RESERVED_COLORS 20 /* number of fixed colors in system palette */ >+ >+#define PC_SYS_USED 0x80 /* palentry is used (both system and logical) */ > > WINE_DEFAULT_DEBUG_CHANNEL(ttydrv); > >--- dlls/x11drv/palette.c~ 2004-12-01 12:32:11.000000000 +0100 >+++ dlls/x11drv/palette.c 2004-12-09 19:03:03.933782832 +0100 >@@ -24,11 +24,16 @@ > #include <string.h> > > #include "gdi.h" >-#include "windef.h" > #include "winreg.h" > #include "x11drv.h" > #include "wine/debug.h" > >+/* palette object */ >+#define NB_RESERVED_COLORS 20 /* number of fixed colors in system palette */ >+ >+#define PC_SYS_USED 0x80 /* palentry is used (both system and logical) */ >+#define PC_SYS_RESERVED 0x40 /* system palentry is not to be mapped to */ >+ > WINE_DEFAULT_DEBUG_CHANNEL(palette); > > /* Palette indexed mode: > > Nice try, but I don't think we want three copies of the same defines. That's just asking for trouble with them getting out of sync. Rob

Dec. 9, 2004

Re: include file cleanup : another step

by Vincent Béron

Le jeu 09/12/2004 à 15:47, Rémi Assailly a écrit : > I moved some defines, ttydrv will not use gdi.h any longer. > I notice that some headers are declared twice, I removed useless > declarations. > > Changelog: > * moved some defines from gdi.h > ---- > > --- dlls/gdi/palette.c~ 2004-10-18 23:18:58.000000000 +0200 > +++ dlls/gdi/palette.c 2004-12-09 14:14:52.000000000 +0100 > @@ -37,6 +37,11 @@ > #include "wine/debug.h" > #include "winerror.h" > > +/* palette object */ > +#define NB_RESERVED_COLORS 20 /* number of fixed colors in system palette */ > + > +#define PC_SYS_USED 0x80 /* palentry is used (both system and logical) */ > + > WINE_DEFAULT_DEBUG_CHANNEL(palette); > > static INT PALETTE_GetObject( HGDIOBJ handle, void *obj, INT count, LPVOID buffer ); > > --- include/gdi.h~ 2004-03-04 21:41:13.000000000 +0100 > +++ include/gdi.h 2004-12-09 19:01:20.154559672 +0100 > @@ -83,14 +83,6 @@ > SEGPTR segptr_bits; /* segptr to DIB bits */ > } BITMAPOBJ; > > -/* palette object */ > - > -#define NB_RESERVED_COLORS 20 /* number of fixed colors in system palette */ > - > -#define PC_SYS_USED 0x80 /* palentry is used (both system and logical) */ > -#define PC_SYS_RESERVED 0x40 /* system palentry is not to be mapped to */ > -#define PC_SYS_MAPPED 0x10 /* logical palentry is a direct alias for system palentry */ > - > typedef struct tagPALETTEOBJ > { > GDIOBJHDR header; > > --- dlls/ttydrv/palette.c~ 2004-12-09 18:57:42.835597176 +0100 > +++ dlls/ttydrv/palette.c 2004-12-09 14:27:48.000000000 +0100 > @@ -22,10 +22,14 @@ > > #include <stdlib.h> > > -#include "gdi.h" > -#include "winbase.h" > #include "ttydrv.h" > #include "wine/debug.h" > +#include "wine/wingdi16.h" > + > +/* palette object */ > +#define NB_RESERVED_COLORS 20 /* number of fixed colors in system palette */ > + > +#define PC_SYS_USED 0x80 /* palentry is used (both system and logical) */ > > WINE_DEFAULT_DEBUG_CHANNEL(ttydrv); > > --- dlls/x11drv/palette.c~ 2004-12-01 12:32:11.000000000 +0100 > +++ dlls/x11drv/palette.c 2004-12-09 19:03:03.933782832 +0100 > @@ -24,11 +24,16 @@ > #include <string.h> > > #include "gdi.h" > -#include "windef.h" > #include "winreg.h" > #include "x11drv.h" > #include "wine/debug.h" > > +/* palette object */ > +#define NB_RESERVED_COLORS 20 /* number of fixed colors in system palette */ > + > +#define PC_SYS_USED 0x80 /* palentry is used (both system and logical) */ > +#define PC_SYS_RESERVED 0x40 /* system palentry is not to be mapped to */ > + > WINE_DEFAULT_DEBUG_CHANNEL(palette); > > /* Palette indexed mode: Defining the same thing in multiple files is a clear indication an #include is needed. Vincent

Dec. 9, 2004

Re: dlls/gdi/tests/metafile.c warning about test_mf_PatternBrush

by Vincent Béron

Le jeu 09/12/2004 à 14:03, Gerald Pfeifer a écrit : > The following patch to dlls/gdi/tests/metafile.c > > revision 1.3 > date: 2004/12/09 11:37:59; author: julliard; state: Exp; lines: +236 -0 > Walt Ogburn <reuben(a)ugcs.caltech.edu> > Added some tests for win-format metafiles. > > introduces the following warning: > > metafile.c:381: warning: `test_mf_PatternBrush' defined but not used > > Should we put #ifdefs around the definition, or enable the following > code in the main test function? > > /* Crashes under wine: */ > /* test_mf_PatternBrush(); */ > > Another option would be not to make this function static. Making it not crash is even better. If we just silence it, it'll get forgotten and won't even be tested on Windows. Truning it into todo_wine() doesn't look practical because of the crash... IIRC, there are 3 other tests (can't recall in which dll exactly offhand) which are defined but never actually used. I think they are in user32 or gdi. Vincent

Dec. 9, 2004

dlls/gdi/tests/metafile.c warning about test_mf_PatternBrush

by Gerald Pfeifer

The following patch to dlls/gdi/tests/metafile.c revision 1.3 date: 2004/12/09 11:37:59; author: julliard; state: Exp; lines: +236 -0 Walt Ogburn <reuben(a)ugcs.caltech.edu> Added some tests for win-format metafiles. introduces the following warning: metafile.c:381: warning: `test_mf_PatternBrush' defined but not used Should we put #ifdefs around the definition, or enable the following code in the main test function? /* Crashes under wine: */ /* test_mf_PatternBrush(); */ Another option would be not to make this function static. Gerald

Dec. 9, 2004

Re: Visual studio 6 build fix.

by Juan Lang

> MS Visual C++ v6, when invoking the compiler and other build tools does > the following: > > create anonymous pipe; > duplicate the pipes write handle; > open's the file NUL > The attached patch makes this work properly. Ahh, cool, that might help with MinGW's windres.exe, too. It uses _popen, which I've implemented to do basically the same as above. _popen works for a silly little test program I wrote, but windres.exe isn't getting its output. I'll check it out. Thanks, --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250

Dec. 9, 2004

Re: visual studio 6 not happy?

by Rein Klazes

On Wed, 01 Dec 2004 22:13:27 -0800, you wrote: > Jerry Geis wrote: > > I am trying to use wine 12-01-04 release with Visual Studio. > > I am getting the vcspawn error. Have you ever found a solution to that? > > [http://www.winehq.com/hypermail/wine-devel/2003/02/0335.html] > > Nope. I didn't look very hard, though. One possibility for the vcspawn error is that the COMSPEC variable is not ( correctly) set. Try an "export COMSPEC=wcmd" to see if that makes the vcspawn error go away. If that is the case, not all the reg entries in tools/wine.inf are installed. Look in that file to see how to run it. That is not enough, I have just uploaded a patch that will fix the data exchange between compiler and gui. With it, just press <F7> and enjoy the view ;-) Rein. -- Rein Klazes rklazes(a)xs4all.nl

Dec. 9, 2004

Visual studio 6 build fix.

by Rein Klazes

Hi, MS Visual C++ v6, when invoking the compiler and other build tools does the following: create anonymous pipe; duplicate the pipes write handle; open's the file NUL calls CreateProcess starting vcspawn.exe with: startup info iohandles set to the 3 handles obtained above; the startup info flag STARTF_USESTDHANDLES set; create flag CREATE_NEW_CONSOLE set. the parent process reads from the pipe, and analyses the compiler and other messages that are obtained that way. Wine's console startup code is not really expecting this and insists on creating new stdio handles instead of inheriting them. The attached patch makes this work properly. Changelog: server : process.c dlls/kernel : console.c A starting process must obey the STARTF_USESTDHANDLES flag, even it is starting a new console. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Dec. 9, 2004

winelib problems

by Joris Huizer

Hello, I tried winemaker (just the notepad example explained at the page) but it doesn't work: - I had to comment out 'use strict' - otherwise winemaker would complain; - still no notepad2 executable is generated... Is it under active development, or is winemaker having bigger problems? regards, Joris

Dec. 9, 2004

Re: EnumCalendarInfo

by Robert Shearman

Vitaly Lipatov wrote: >Some months ago Ken Belleau done some implementation of EnumCalendarInfo. >http://www.winehq.org/hypermail/wine-patches/2004/04/0170.html >I can't find any discussion of this patch. >It is possible to review it and apply now? >I would like to write some tests for this functions later. > >P.S. >Sorry for patches I send this list. Have I to resend it in wine-patches or >not? > > Yes, resend it to wine-patches. Make sure you acknowledge Ken Belleau in the changelog though. Rob

Dec. 9, 2004

Re: Another systray patch

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > OK on the second point. For the first how should it be handled? The > protocol Windows uses doesn't seem to let you return a success/failure > value. Do we just drop the tray icon? Yeah, something like that. It's OK to not add an icon if we are out of memory, but it's not OK for the whole process to die. -- Alexandre Julliard julliard(a)winehq.org

Dec. 9, 2004

EnumCalendarInfo

by Vitaly Lipatov

Some months ago Ken Belleau done some implementation of EnumCalendarInfo. http://www.winehq.org/hypermail/wine-patches/2004/04/0170.html I can't find any discussion of this patch. It is possible to review it and apply now? I would like to write some tests for this functions later. P.S. Sorry for patches I send this list. Have I to resend it in wine-patches or not? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Dec. 9, 2004

some description for ExtTextOut

by Vitaly Lipatov

This patch adds description for ExtTextOut and missed constants. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Dec. 9, 2004

add GetGlobalFontLinkObject in mlang

by Vitaly Lipatov

Changes stub to FIXME for GetGlobalFontLinkObject in mlang DLL The patch is attached. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Dec. 9, 2004

Re: Another systray patch

by Mike Hearn

On Thu, 2004-12-09 at 15:35 +0100, Alexandre Julliard wrote: > It would be nice to do the XEMBED stuff as a separate patch. Also I > was hoping you would get rid of WS_EX_TRAYWINDOW instead of adding > even more uses of it... XEMBED in a separate patch is doable I guess but it wouldn't be used without the rest of the patch. It's only use at the moment is the systray code. > The screen will be 0 in 99.9% of the cases, you should preallocate > that one. OK, I'll fix that. > exit(1) is not acceptable here, you should handle allocation failures > properly. Also malloc doesn't clear the buffer so xmalloc shouldn't > either, otherwise it's very confusing. OK on the second point. For the first how should it be handled? The protocol Windows uses doesn't seem to let you return a success/failure value. Do we just drop the tray icon? > > +struct request { > > + NOTIFYICONDATAA ansi; > > + NOTIFYICONDATAW wide; > > + BOOL unicode; > > + BYTE *copydata; > > Inter-process data should always be sent in Unicode. OK. I'll convert on the client side, that should clean the code up somewhat too.

Dec. 9, 2004

Re: Another systray patch

by Mike Hearn

On Mon, 06 Dec 2004 21:41:16 +0000, Mike Hearn wrote: > That's very strange. That was the first time I have tried sending a > patch via the builtin emacs sendmail facility, it would be annoying if > that mangles it somehow. I checked the web archive and my own inbox, and > the patch *looked* fine. I wonder what is up with it. Hi Alexandre, This patch missed several rounds of commits. Does it not apply/build for you or something?

Dec. 9, 2004

Re: tools/wineinstall

by Vincent Béron

Le mar 07/12/2004 à 21:21, Christian Britz a écrit : > Dear all, > > the script tools/wineinstall suggest to uninstall wine first if you > update an existing installation. > > This makes senses but it is uncomfortable that the script doesn't offer > the option to do that for the user. You always have to su before > installing a new version That's because it's unable to determine how it was installed in the first place, and where the files are located. The "wine" program itself is usually easy to find, but not necessarily so for the dlls and other installed files. rpm -e, the equivalent under Debian, make uninstall (from original source tree), etc. are all different ways to install Wine. Vincent

Dec. 9, 2004

Re: Another systray patch

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > There was a crash in the previous patch, here is a fixed version. > > - Add a new wineshell process, and put system tray handling in there > - Rewrite the shell32 systray handling to be out of process > - Support the freedesktop.org XEMBED protocol It would be nice to do the XEMBED stuff as a separate patch. Also I was hoping you would get rid of WS_EX_TRAYWINDOW instead of adding even more uses of it... > + /* we can't intern this with the rest as it depends on the screen we are connecting to */ > + systray_buffer = HeapAlloc(GetProcessHeap(), 0, sizeof(char)*20); > + sprintf(systray_buffer, "_NET_SYSTEM_TRAY_S%d", DefaultScreen(display)); The screen will be 0 in 99.9% of the cases, you should preallocate that one. > +void *xmalloc(unsigned int size) > +{ > + void *p = HeapAlloc(GetProcessHeap(), 0, size); > + > + if (!p) > + { > + fprintf(stderr, "wineshell: virtual memory exhausted\n"); > + exit(1); > + } > + > + ZeroMemory(p, size); exit(1) is not acceptable here, you should handle allocation failures properly. Also malloc doesn't clear the buffer so xmalloc shouldn't either, otherwise it's very confusing. > +struct request { > + NOTIFYICONDATAA ansi; > + NOTIFYICONDATAW wide; > + BOOL unicode; > + BYTE *copydata; Inter-process data should always be sent in Unicode. -- Alexandre Julliard julliard(a)winehq.org

Dec. 9, 2004

problem reading dir's with fix

by Rein Klazes

hi, Since the change from readdir to getdents64 I cannot access certain files and dir's (including the one used for saving wine patches) with the common file dialog's. | 0009:Call ntdll.NtQueryDirectoryFile(00000010,00000000,00000000,00000000,77a6a070,77cc6b24,00002000,00000003,00000000,77cc6b10,00000000) ret=77b26174 | trace:file:NtQueryDirectoryFile (0x10 (nil) (nil) (nil) 0x77a6a070 0x77cc6b24 0x00002000 0x00000003 0x00000000 L"diffs" 0x00000000 | trace:file:append_entry long L"."... short L""... mask L"diffs" | trace:file:match_filename (L"."..., L"diffs") | trace:file:append_entry long L".."... short L""... mask L"diffs" | trace:file:match_filename (L".."..., L"diffs") [some 200 entries snipped] | trace:file:append_entry long L"freecell.ICO"... short L""... mask L"diffs" | trace:file:match_filename (L"freecell.ICO"..., L"diffs") | trace:file:NtQueryDirectoryFile => 80000006 (0) | 0009:Ret ntdll.NtQueryDirectoryFile() retval=80000006 ret=77b26174 | 0009:Call ntdll.RtlNtStatusToDosError(80000006) ret=77b261e1 | 0009:Ret ntdll.RtlNtStatusToDosError() retval=00000012 ret=77b261e1 | trace:file:FindFirstFileExW L"H:\\diffs" not found H:\ contains almost 400 entries, so it is clear not all are read. Looking through the code I notice that getdents64 is called only once, where readdir was called several times. Here is my solution that fixes the problem for me. Changelog: dlls/ntdll : directory.c If needed, keep calling getdents64() until no more entries are returned. Rein.

Dec. 9, 2004

Re: wine/ windows/winproc.c programs/uninstaller/m ...

by Dimitrie O. Paun

On Thu, Dec 09, 2004 at 08:08:00AM -0600, Alexandre Julliard wrote: > Log message: > Janitorial: C booleans must not be compared against TRUE. Thank you! -- Dimi.

Dec. 9, 2004

Wine test suite (or winrash, don't know which one) - possible way to improve for some persons (with some antivirus or firewall software running)

by Tero Tamminen

Hi! I don't know if this is proper list to send this (well, I didn't find any mailinglist for the Wine test suite app and mailinglist in sf project for winrash was empty). So I thought that information would possibly reach developers of Wine test suite or winrash through this mailinglist. And as I said in the subject, I don't know if this message concerns wine test suite or winrash program or both. Because of that, I use winrash from now on, because it is much shorter to write. I have this winrash running on one of my computers, in windows 2003 server. There is a firewall program (ZoneAlarm Pro) installed to this computer. Some time ago, I upgraded Zonealarm to new version (5.5.062.004). This version has a feature, that checks if some programs are trying to execute new programs or something. It is possible to allow execution of new programs permanently (it saves directory and name of executable), but not in case of winrash. Winrahs starts its tests every time in temporary directory with new name. So every time a test starts, Zonealarm asks me if the execution of test is allowed. This is a problem for me, because it is annoying to click through all the messages, but it is also a problem for winrash, because I am not sitting in front of this computer very often and some tests might timeout because of that (and I think it has happened a couple of times already). So would it be possible to start all the tests from same directory (I mean, every version of the tests would start in same directory). It would save me some time because I wouldn't have to click through all the messages. Thanks! Tero Tamminen

Dec. 9, 2004

Re: Build also 20 ppem font size for wine_sserifee.fon

by Huw D M Davies

On Thu, Dec 09, 2004 at 05:33:01PM +0800, Dmitry Timoshkov wrote: > Hello, > > it seems that 20 ppem size for wine_sserifee was simply overlooked. > No, it's a different face than the 20 ppem for cp1251 and cp1252 and is actually the same face as one of the 120dpi ones. I believe this is a mistake by MS, but we have to follow suit. The good news is that I've already drawn such a beast, it just requires a little hack to sfnttofnt to distinguish it from the existing 20 ppem face. I'll try to post a patch soon. Huw. -- Huw Davies huw(a)codeweavers.com

Dec. 9, 2004

winedbg problems

by Michael Lin

Hi all, I am having problem with winedbg and a winelib application I am trying to debug. In the debugger it produce the following output when exception occured: Wine-dbg>cont First chance exception: page fault on read access to 0x00000000 in 32-bit code ( 0x401d4316). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:401d4316 ESP:41e4f7d4 EBP:41e4f7d4 EFLAGS:00210212( - 00 - RIA1) EAX:0000000a EBX:4059aee4 ECX:00000000 EDX:41e4fa3a ESI:00000104 EDI:41e4fa24 Stack dump: 0x41e4f7d4: 41e4fc40 405067c5 00000000 00000104 0x41e4f7e4: 403b67c4 00000001 0000001d 0000004c 0x41e4f7f4: 00000001 00000048 00690057 0065006e 0x41e4f804: 00500020 0073006f 00000000 00000000 0x41e4f814: 00700069 00200074 00720044 00760069 0x41e4f824: 00720065 00000000 4194e425 0000007a Backtrace: =>1 0x401d4316 RtlDetermineDosPathNameType_U+0x6(path=0x0) [/home/mlin/wine/dlls/ntdll/path.c:193] in ntdll (0x41e4f7d4) 2 0x405067c5 PROFILE_Open+0xf5(filename=0x0) [/home/mlin/wine/dlls/kernel/profile.c:751] in kernel32 (0x41e4fc40) 3 0x405087c6 WritePrivateProfileStringW+0x46(section=0x403c2998, entry=0x0, string=0x0, filename=0x0) [/home/mlin/wine/dlls/kernel/profile.c:1415] in kernel32 (0x41e4fc80) 4 0x4050897d WritePrivateProfileStringA+0xbd(section=0x4194ead8, entry=0x0, string=0x0, filename=0x0) [/home/mlin/wine/dlls/kernel/profile.c:1455] in kernel32 (0x41e4fcd0) 5 0x40aaf21ferr:dbghelp_stabs:stabs_pts_read_type_def Forward declaration name mismatch PtrArrayWalker <> PtrArray_FIXME<Page> err:dbghelp_stabs:stabs_pts_read_type_def Forward declaration name mismatch Node <> ValList<String> err:dbghelp_stabs:stabs_pts_read_type_def Forward declaration name mismatch Node <> ValList<Forecasting err:dbghelp_stabs:stabs_pts_read_type_def Forward declaration name mismatch ConstIterator <> ValList<String> err:dbghelp_stabs:stabs_pts_read_type_def Forward declaration name mismatch Iterator <> ValList<String> ..................... err:dbghelp_stabs:stabs_pts_read_type_def Forward declaration name mismatch Iterator <> ValList<String> err:dbghelp_stabs:stabs_pts_read_type_def Forward declaration name mismatch ConstIterator <> ValList<Forecasting err:dbghelp_stabs:stabs_pts_read_type_def Forward declaration name mismatch Iterator <> ValList<Forecasting Exception c0000005 Wine-dbg> Jon Griffiths reported a similar problem on Jun 21 2004. Does anyone else seen this problem? It seems like winedbg have some problem parsing stabs debug information on C++ templates. Any help would be really appreciated. Thanks, Michael

Dec. 9, 2004

Re: Fwd: Foobar2000 audio player Regression

by Robert Shearman

Nick Hornback wrote: >I originally posted this to the -users list, but I was >contacted by Robbert Xerox, who had the exact same >issue, and thus far nobody has replyed in the users >list, so maybe it will get more attention here. > > > >>Foobar2000 worked virtually perfectly in the >> >> >20041019 > > >>release (aside from some comctrl32 repainting issues >>-- which native comctrl32.dll fixed), but in >> >> >20041201 > > >>it is completely unuseable. Two major problems: >> >> > > > >>1) The toolbars are completely gone. They are >> >> >sort-of > > >>displayed when they get activity via mouse-press or >>whatever, but they do not repaint correctly at all. >>See this screenshot for details: >> >> > > > >http://img20.exs.cx/my.php?loc=img20&image=w1ifoobar.gif > > > >>2) It takes 100% cpu. In the 20041021 release, it >>hovered around 5% cpu (on my athlon 64 3200+), which >>was excellent because that beat most native linux >>audio players. >> >> >I have since found out that if you use a the builtin >comctrl32.dll, none of the window repaints at all. In >previous wine releases, using the builtin >comctrl32.dll would just create minor glitches (ex. >the status bar wouldn't update). > > The drawing issues look like a regression in the toolbar code. I'll take a look. Rob

Dec. 8, 2004

Re: shlwapi - forward SHSetTimerQueueTimer to kernel32.CreateTimerQueueTimer

by Robert Shearman

Steven Edwards wrote: >Hi, > >Msdn documents quite a bit about shlwapi functions that are wrappers around other functions: >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl… > >But at the moment the application I am testing only depends on this function. > >Changelog: >Foward Shlwapi.SHSetTimerQueueTimer to kernel32.CreateTimerQueueTimer > > Then the application will crash and die in horrible ways with this patch. The function signature of SHSetTimerQueueTimer is not the same as CreateTimerQueueTimer. However, as the MSDN docs say, they are compatible. So, you just need to create an implementation of SHSetTimerQueueTimer that converts the parameters appropriately and calls CreateTimerQueueTimer. Note that this function is still a FIXME stub at the moment, although I plan on implementing this and the thread pooling functions because they will be useful for the COM work. Rob

Dec. 8, 2004

Re: Genrate stdole32.tlb file, and install generated files

by Robert Shearman

Huw D M Davies wrote: >On Wed, Dec 08, 2004 at 12:02:28PM +0100, Alexandre Julliard wrote: > > >>Mike Hearn <mh(a)codeweavers.com> writes: >> >> >> >>>Hmm, so the approach with a custom app generating stdole32.tlb is not OK? >>> >>> >>No, we can't run a Winelib app during the build process, and >>stdole32.tlb really has to be built like everything else at compile >>time. >> >> > >The reason I wrote a program was that I was unable to get midl to >generate the correct typelib from stdole32.idl - it really didn't >like producing IUnknown iirc. Of course, it may be that I was just >being dumb, and that it's perfectly possible to do this. If not I >guess we can always lift this restriction on widl. > > MIDL cannot generate correct stdole* typelibs because it forces the inclusion of objidl.idl. You have to use mktyplib. As you say, we can lift this restriction from widl. Here is a file that, when used with mktyplib, generates a pretty similar file to stdole32.tlb (similar as in generates the same output from typelib viewers, but isn't the same at the byte level): http://www.winehq.org/hypermail/wine-devel/2003/01/att-0858/01-stdole32.odl Rob

Dec. 8, 2004

Re: Includes [1] ntdll

by Robert Reif

Jon Griffiths wrote: >Hi Rob, > > > >>Do the patches take into account that a header might only be >>included to >>check that an exported function matches the declaration in the >>header file? >> >> > >No, I dont think that case can exist. > > > Look at dxerr8 and dxerr9.

Dec. 8, 2004

Re: fix crash in painting.c

by Steven Edwards

Hi, --- Rein Klazes <wijn(a)wanadoo.nl> wrote: > Several app's crash with the re-organized region code. > > Changelog: > dlls/user : painting.c > GetUpdateRect can be called with rect is NULL. Just tested here and this does fix the IE6 regressions I was seeing. Thanks Steven __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

Dec. 8, 2004

Re: Includes [4] shlwapi

by Alexandre Julliard

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > It might be better to clean up the headers first then. By clean up I > take it you mean removing any header that aren't part of the platform > SDK? If that is the long term plan then it could be handled in 2 > steps a) remove all #includes from non-sdk headers and add them to > the files that need them, then b) start removing the non-standard > headers (possibly much later). No, I don't think we want to do that in two steps, since we don't want to add headers that are only needed to build a private header. For instance many private headers still contain 16-bit stuff, and we definitely don't want to start including Win16 headers all over the place. -- Alexandre Julliard julliard(a)winehq.org

Dec. 8, 2004

tooltips problem with server side update region handling

by Rein Klazes

Hi, There are now 4 little tooltips windows sticking on top of all windows and following me to every desktop I go :-(((. The problem seems to be that the call: SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0, SWP_NOZORDER | SWP_HIDEWINDOW | SWP_NOACTIVATE); in TOOLTIPS_Hide() is ineffective (does not hide the tooltip). Here is a +tooltip,+win,+x11drv trace of the situation before: | trace:tooltips:TOOLTIPS_Hide Hide tooltip 5! (0x10042) | trace:win:SetWindowPos hwnd 0x10042, after (nil), 0,0 (0x0), flags 00000094 | trace:win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOACTIVATE SWP_HIDEWINDOW | trace:x11drv:X11DRV_SetWindowPos hwnd 0x10042, after (nil), swp 0,0 0x0 flags 00000094 | trace:tooltips:TOOLTIPS_WindowProc hwnd=0x10042 msg=46 wparam=0 lParam=77a6f514 | trace:x11drv:X11DRV_SetWindowPos current (187,92)-(324,112), style 94800000 | warn:x11drv:SWP_DoOwnedPopups (0x10042) hInsertAfter = (nil) | trace:tooltips:TOOLTIPS_WindowProc hwnd=0x10042 msg=83 wparam=1 lParam=77a6f478 | trace:x11drv:SWP_DoNCCalcSize (1,1)-(1,1) | trace:x11drv:X11DRV_set_window_rectangles win 0x10042 window (0,0)-(0,0) client (1,1)-(1,1) | trace:win:RedrawWindow 0x10042 ((nil)) NULL 0,0-0,0 (nil) flags=08b8 | trace:win:dump_rdw_flags flags: RDW_VALIDATE RDW_NOINTERNALPAINT RDW_NOERASE RDW_ALLCHILDREN RDW_NOFRAME | trace:win:RDW_UpdateRgns hwnd 0x10042 [(nil)] -> hrgn [0x1], flags [08b8] compared to the situation after, with added some of the +server trace. | race:tooltips:TOOLTIPS_Hide Hide tooltip 5! (0x10042) | trace:win:SetWindowPos hwnd 0x10042, after (nil), 0,0 (0x0), flags 00000094 | trace:win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOACTIVATE SWP_HIDEWINDOW | trace:x11drv:X11DRV_SetWindowPos hwnd 0x10042, after (nil), swp 0,0 0x0 flags 00000094 | trace:tooltips:TOOLTIPS_WindowProc hwnd=0x10042 msg=46 wparam=0 lParam=77a6f514 | trace:x11drv:SWP_DoWinPosChanging hwnd 0x10042, after (nil), swp 0,0 0x0 flags 00001894 | trace:x11drv:SWP_DoWinPosChanging current (178,78)-(315,98) style 94800000 new (0,0)-(0,0) | warn:x11drv:SWP_DoOwnedPopups (0x10042) hInsertAfter = (nil) | 0009: get_window_children( parent=0x10020, atom=0000, tid=0000 ) | 0009: get_window_children() = 0 { count=7, children={0x10042,0x1002c,0x10044,0x10034,0x10022,0x10028,0x10026} } | 0009: start_hook_chain( id=4 ) | 0009: start_hook_chain() = 0 { handle=(nil), pid=0000, tid=0000, proc=(nil), unicode=0, module=L"" } | trace:tooltips:TOOLTIPS_WindowProc hwnd=0x10042 msg=83 wparam=1 lParam=77a6f498 | 0009: start_hook_chain( id=12 ) | 0009: start_hook_chain() = 0 { handle=(nil), pid=0000, tid=0000, proc=(nil), unicode=0, module=L"" } | trace:x11drv:SWP_DoNCCalcSize (1,1)-(1,1) | 0009: set_window_pos( handle=0x10042, top_win=0x10042, previous=(nil), flags=00000094, redraw_flags=00000000, window={0,0;0,0}, client={1,1;1,1} ) | 0009: set_window_pos() = INVALID_PARAMETER { new_style=00000000 } where it all ends. The INVALID_PARAMETER is, I think, the result of a failure of server function validate_window_rectangles(), choking on a window with size 0,0-0,0 and client 1,1-1,1. I guess the validation is too strict, right? Rein.

Dec. 8, 2004

Re: Includes [4] shlwapi

by Jon Griffiths

Hi, > The problem with that approach is that you remove a lot of headers > that are included anyway so it doesn't make any difference in build > time, and many of them will have to be added again once we finish > the header cleanup. For instance you remove winuser.h everywhere > win.h is included because win.h brings it in already, but once we > get rid of win.h we'll have to go back and re-add winuser.h. It might be better to clean up the headers first then. By clean up I take it you mean removing any header that aren't part of the platform SDK? If that is the long term plan then it could be handled in 2 steps a) remove all #includes from non-sdk headers and add them to the files that need them, then b) start removing the non-standard headers (possibly much later). If so, thats probably a worthwhile project. > What you should do is limit the changes to the cases where it makes > an > actual difference in the dependency tree. You'll get the same > performance gain with a much smaller set of changes. I will update my script to do this and resend. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250

Dec. 8, 2004

Re: Includes [1] ntdll

by Jon Griffiths

Hi Rob, > Do the patches take into account that a header might only be > included to > check that an exported function matches the declaration in the > header file? No, I dont think that case can exist. Each .c file contains 5-20 or more functions that take flags/structs etc defined in the header. The same header defines the function too, so I don't think you'll see this case in practice. However I will knock up a script to check that every function does include the header that defines it, an submit a patch for any cases that turn up (although I don't think there will be any). Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

Dec. 8, 2004

Re: [RESEND] Unicodified fontdlg (next try)

by Alexandre Julliard

Jacek Caban <jack(a)itma.pwr.wroc.pl> writes: > -INT_PTR CALLBACK FormatCharDlgProcA(HWND hDlg, UINT uMsg, WPARAM wParam, > +INT_PTR CALLBACK FormatCharDlgProc(HWND hDlg, UINT uMsg, WPARAM wParam, > LPARAM lParam) > { > - LPCHOOSEFONTA lpcf; > + LPCHOOSEFONTW lpcf; > INT_PTR res = FALSE; > > if (uMsg!=WM_INITDIALOG) > { > - lpcf=(LPCHOOSEFONTA)GetPropA(hDlg, WINE_FONTDATA); > - if (!lpcf && uMsg != WM_MEASUREITEM) > + lpcf=(LPCHOOSEFONTW)GetPropW(hDlg, strWineFontData); > + if (!lpcf) > return FALSE; > if (CFn_HookCallChk32(lpcf)) > - res=CallWindowProcA((WNDPROC)lpcf->lpfnHook, hDlg, uMsg, wParam, lParam); > + res=CallWindowProcW((WNDPROC)lpcf->lpfnHook, hDlg, uMsg, wParam, lParam); You cannot use the same dialog procedure for A and W here, since it will cause the hook to always be called with a W message, even if the app originally called ChooseFontA. You really need to keep both dialog procedures. -- Alexandre Julliard julliard(a)winehq.org

Dec. 8, 2004

Re: IMM_Register and Flight Simulator 98

by Christian Costa

I have exactly the same problem here (with several apps). Removing the LoadCursorW call (ie setting wndClass.hCursor to NULL) in IMM_Register seems to prevent the crash. Robert Reif wrote: > Just tried to install Flight Simulator 98 with latest CVS and got this: > >------------------------------------------------------------------------ > >[wine(a)dell cdrom1]$ wine setup.exe >wine: Unhandled exception (thread 0009), starting debugger... >WineDbg starting on pid 0x8 >Unhandled exception: page fault on read access to 0x000004d0 in 32-bit code (0x40e42e67). >In 32 bit mode. >Register dump: > CS:0023 SS:002b DS:002b ES:002b FS:0033 GS:004f > EIP:40e42e67 ESP:4081f394 EBP:4081f3bc EFLAGS:00010212( - 00 - RIA1) > EAX:00000000 EBX:40f0b1e4 ECX:40502a9f EDX:00000000 > ESI:40e15a98 EDI:40322f50 >Stack dump: >0x4081f394: 4081f3bc 409816e0 000000be 00000000 >0x4081f3a4: 00000000 00000000 40e42e5b 40e11220 >0x4081f3b4: 40e15a98 40322f50 4081f3e0 40dd85e3 >0x4081f3c4: 00000000 000000b6 00000000 00000000 >0x4081f3d4: 40997614 40322c28 40322e10 4081f67c >0x4081f3e4: 4095a025 0000004c 40322e28 4081f410 >Backtrace: >=>1 0x40e42e67 ?? +0x17 in libx11.so.6 (0x4081f3bc) > 2 0x40dd85e3 X11DRV_CreateDC+0x87(hdc=0x4c, pdev=0x40322e28, driver=0x4081f410, device=0x0, output=0x0, initData=0x0) [/home/wine/wine/dlls/x11drv/init.c:153] in x11drv (0x4081f3e0) > 3 0x4095a025 CreateDCW+0xed(driver=0x408d2f50, device=0x0, output=0x0, initData=0x0) [/home/wine/wine/dlls/gdi/dc.c:609] in gdi32 (0x4081f67c) > 4 0x40861503 CURSORICON_CreateFromResource+0x65f(hModule=0x0, hObj=0x0, bits=0x408c5740, cbSize=0x134, bIcon=0x0, dwVersion=0x30000, width=0x20, height=0x20, loadflags=0x8040) [/home/wine/wine/dlls/user/../../windows/cursoricon.c:711] in user32 (0x4081f70c) > 5 0x408616eb CURSORICON_Load+0x12f(hInstance=0x0, name=0x7f00, width=0x0, height=0x0, colors=0x1, fCursor=0x1, loadflags=0x8040) [/home/wine/wine/dlls/user/../../windows/cursoricon.c:971] in user32 (0x4081f75c) > 6 0x4086390f LoadImageW+0x8b(hinst=0x0, name=0x7f00, type=0x2, desiredx=0x0, desiredy=0x0, loadflags=0x8040) [/home/wine/wine/dlls/user/../../windows/cursoricon.c:2272] in user32 (0x4081f790) > 7 0x40862a5e LoadCursorW+0x26(hInstance=0x0, name=0x7f00) [/home/wine/wine/dlls/user/../../windows/cursoricon.c:1715] in user32 (0x4081f7b4) > 8 0x41747762 IMM_Register+0x5a [/home/wine/wine/dlls/imm32/imm.c:107] in imm32 (0x4081f800) > 9 0x417478d8 DllMain+0x78(hInstDLL=0x41740000, fdwReason=0x1, lpReserved=0x0) [/home/wine/wine/dlls/imm32/imm.c:146] in imm32 (0x4081f814) > 10 0x41746f88 __wine_dll_main+0x60 in imm32 (0x4081f844) > 11 0x401a2cee call_dll_entry_point+0x12 in ntdll (0x4081f85c) > 12 0x401a3d07 MODULE_InitDLL+0xe3(wm=0x40322b80, reason=0x1, lpReserved=0x0) [/home/wine/wine/dlls/ntdll/loader.c:741] in ntdll (0x4081f8cc) > 13 0x401a3ee4 process_attach+0xf8(wm=0x40322b80, lpReserved=0x0) [/home/wine/wine/dlls/ntdll/loader.c:814] in ntdll (0x4081f8f0) > 14 0x401a56e0 LdrLoadDll+0x84(path_name=0x40322ab8, flags=0x0, libname=0x4081f954, hModule=0x4081f934) [/home/wine/wine/dlls/ntdll/loader.c:1565] in ntdll (0x4081f914) > 15 0x40466d73 load_library+0x4b(libname=0x4081f954, flags=0x0) [/home/wine/wine/dlls/kernel/module.c:671] in kernel32 (0x4081f944) > 16 0x40466e3a LoadLibraryExW+0x2e(libnameW=0x40014c00, hfile=0x0, flags=0x0) [/home/wine/wine/dlls/kernel/module.c:726] in kernel32 (0x4081f964) > 17 0x40466dfe LoadLibraryExA+0x2e(libname=0x40e0bfc4, hfile=0x0, flags=0x0) [/home/wine/wine/dlls/kernel/module.c:707] in kernel32 (0x4081f97c) > 18 0x40466e70 LoadLibraryA+0x1c(libname=0x40e0bfc4) [/home/wine/wine/dlls/kernel/module.c:746] in kernel32 (0x4081f994) > 19 0x40df2064 LoadImmDll+0x1c [xim.c:78] in x11drv (0x4081f9a4) > 20 0x40df29bb X11DRV_SetupXIM+0x127(display=0x7801c0b8, input_style=0x40e15978) [/home/wine/wine/dlls/x11drv/xim.c:440] in x11drv (0x4081f9d4) > 21 0x40deb656 x11drv_init_thread_data+0x11a [/home/wine/wine/dlls/x11drv/x11drv_main.c:502] in x11drv (0x4081f9f0) > 22 0x40dc41d1 X11DRV_create_desktop+0x289(desktop_vi=0x0, geometry=0x78020580) [/home/wine/wine/dlls/x11drv/desktop.c:251] in x11drv (0x4081fa78) > 23 0x40deb3ac process_attach+0x150 [/home/wine/wine/dlls/x11drv/x11drv_main.c:395] in x11drv (0x4081fa9c) > 24 0x40deb761 DllMain+0x39(hinst=0x40db0000, reason=0x1, reserved=0x0) [/home/wine/wine/dlls/x11drv/x11drv_main.c:524] in x11drv (0x4081faa8) > 25 0x40dbb6d4 __wine_dll_main+0x60 in x11drv (0x4081fad8) > 26 0x401a2cee call_dll_entry_point+0x12 in ntdll (0x4081faf0) > 27 0x401a3d07 MODULE_InitDLL+0xe3(wm=0x40322978, reason=0x1, lpReserved=0x0) [/home/wine/wine/dlls/ntdll/loader.c:741] in ntdll (0x4081fb60) > 28 0x401a3ee4 process_attach+0xf8(wm=0x40322978, lpReserved=0x0) [/home/wine/wine/dlls/ntdll/loader.c:814] in ntdll (0x4081fb84) > 29 0x401a56e0 LdrLoadDll+0x84(path_name=0x403228a8, flags=0x0, libname=0x4081fbe8, hModule=0x4081fbc8) [/home/wine/wine/dlls/ntdll/loader.c:1565] in ntdll (0x4081fba8) > 30 0x40466d73 load_library+0x4b(libname=0x4081fbe8, flags=0x0) [/home/wine/wine/dlls/kernel/module.c:671] in kernel32 (0x4081fbd8) > 31 0x40466e3a LoadLibraryExW+0x2e(libnameW=0x40014c00, hfile=0x0, flags=0x0) [/home/wine/wine/dlls/kernel/module.c:726] in kernel32 (0x4081fbf8) > 32 0x40466dfe LoadLibraryExA+0x2e(libname=0x4081fc44, hfile=0x0, flags=0x0) [/home/wine/wine/dlls/kernel/module.c:707] in kernel32 (0x4081fc10) > 33 0x40466e70 LoadLibraryA+0x1c(libname=0x4081fc44) [/home/wine/wine/dlls/kernel/module.c:746] in kernel32 (0x4081fc28) > 34 0x408c2c42 load_driver+0x7a [user_main.c:75] in user32 (0x4081fd60) > 35 0x408c321f process_attach+0x47 [/home/wine/wine/dlls/user/user_main.c:180] in user32 (0x4081fd70) > 36 0x408c33cc DllMain+0x50(inst=0x40840000, reason=0x1, reserved=0x1) [/home/wine/wine/dlls/user/user_main.c:260] in user32 (0x4081fd80) > 37 0x40851218 __wine_dll_main+0x60 in user32 (0x4081fdb0) > 38 0x401a2cee call_dll_entry_point+0x12 in ntdll (0x4081fdc8) > 39 0x401a3d07 MODULE_InitDLL+0xe3(wm=0x402f0908, reason=0x1, lpReserved=0x1) [/home/wine/wine/dlls/ntdll/loader.c:741] in ntdll (0x4081fe38) > 40 0x401a3ee4 process_attach+0xf8(wm=0x402f0908, lpReserved=0x1) [/home/wine/wine/dlls/ntdll/loader.c:814] in ntdll (0x4081fe5c) > 41 0x401a3f13 process_attach+0x127(wm=0x402f07c8, lpReserved=0x1) [/home/wine/wine/dlls/ntdll/loader.c:806] in ntdll (0x4081fe7c) > 42 0x401a5fe6 LdrInitializeThunk+0x1f2(main_file=0x0, unknown2=0x0, unknown3=0x0, unknown4=0x0) [/home/wine/wine/dlls/ntdll/loader.c:1902] >in ntdll (0x4081ff20) > 43 0x40471433 start_process+0x9b(arg=0x0) [/home/wine/wine/dlls/kernel/process.c:1036] in kernel32 (0x4081fff4) > 44 0x400298f5 wine_pthread_abort_thread+0x29(status=0x0) [port.c:85] in libwine.so.1 (0x00000000) >0x40e42e67 ?? +0x17 in libx11.so.6: movl 0x4d0(%edx),%eax >Wine-dbg> > > >

Dec. 8, 2004

Re: msvcrt: implement _pipe

by Alexandre Julliard

Juan Lang <juan_lang(a)yahoo.com> writes: > + fd = msvcrt_alloc_fd(readHandle, wxflags); > + if (fd != -1) > + { > + pfds[0] = fd; > + fd = msvcrt_alloc_fd(writeHandle, wxflags); > + if (fd != -1) > + pfds[1] = fd; > + } > + if (fd == -1) > + { > + CloseHandle(readHandle); > + CloseHandle(writeHandle); > + *MSVCRT__errno() = MSVCRT_EMFILE; > + ret = -1; > + } You need to free pfds[0] on failure if it was allocated. -- Alexandre Julliard julliard(a)winehq.org

Dec. 8, 2004

Re: Wine Bug Busters @ 7pm GMT

by Mike Hearn

On Mon, 06 Dec 2004 13:56:30 +0200, Shachar Shemesh wrote: > Damn, had to miss it. Any impressions from the event? IRC logs? It was pretty good, a lot of people showed up which was fantastic. I was a bit disappointed that those people were mostly already experienced Wine developers, I was hoping to recruit some new people :) Still it was only 3 days after the announcement in WWN so I suspect if one was organised a longer time in advance more newbies would appear.

Dec. 8, 2004

Problems with Managed Mode

by pvriens＠xs4all.nl

Hi, just compiled wine (CVS from yesterday 12/7/2004). Started with a clean wine environment. Running 'wine notepad.exe' works fine. Running the same command when the config-file shows: [AppDefaults\\notepad.exe\\x11drv] "Desktop" = "800x600" gives: wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 fixme:dbghelp:SymLoadModule should have successfully loaded some debug information for image C:\windows\notepad.exe Unhandled exception: page fault on read access to 0x000004d0 in 32-bit code (0x1028dc07). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:1028dc07 ESP:2d89f304 EBP:2d89f32c EFLAGS:00010202( - 00 - -RI1) EAX:00000000 EBX:1033d58c ECX:352ca5c3 EDX:00000000 ESI:6d98fdb4 EDI:77e13110 Stack dump: 0x2d89f304: 2d89f32c 3b843d0c 000000be 00000000 0x2d89f314: 00000000 00000000 6aa2d799 6d9895cc 0x2d89f324: 6d98fdb4 77e13110 2d89f350 6d958e1b 0x2d89f334: 00000000 00000060 00000000 00000000 0x2d89f344: 3b8522cc 0000004c 77e12fd0 2d89f5f0 0x2d89f354: 3b81ce89 0000004c 77e12fe8 2d89f384 Backtrace: =>1 0x1028dc07 (0x2d89f32c) 2 0x6d958e1b X11DRV_CreateDC+0x87(hdc=0x4c, pdev=0x77e12fe8, driver=0x2d89f384, device=0x0, output=0x0, initData=0x0) [/data/install/linux/wine-src/wine/dlls/x11drv/init.c:153] in x11drv (0x2d89f350) 3 0x3b81ce89 CreateDCW+0xed(driver=0x3b13e410, device=0x0, output=0x0, initData=0x0) [/data/install/linux/wine-src/wine/dlls/gdi/dc.c:609] in gdi32 (0x2d89f5f0) 4 0x3b0cf0aa CURSORICON_CreateFromResource+0x62e(hModule=0x0, hObj=0x0, bits=0x3b130e00, cbSize=0x134, bIcon=0x0, dwVersion=0x30000, width=0x20, height=0x20, loadflags=0x8040) [/data/install/linux/wine-src/wine/dlls/user/../../windows/cursoricon.c:711] in user32 (0x2d89f67c) 5 0x3b0cf290 CURSORICON_Load+0x134(hInstance=0x3b0b0000, name=0x7f00, width=0x0, height=0x0, colors=0x1, fCursor=0x1, loadflags=0x8040) [/data/install/linux/wine-src/wine/dlls/user/../../windows/cursoricon.c:971] in user32 (0x2d89f6c8) 6 0x3b0d1411 LoadImageW+0x91(hinst=0x0, name=0x7f00, type=0x2, desiredx=0x0, desiredy=0x0, loadflags=0x8040) [/data/install/linux/wine-src/wine/dlls/user/../../windows/cursoricon.c:2272] in user32 (0x2d89f6fc) 7 0x3b0d05b6 LoadCursorW+0x26(hInstance=0x0, name=0x7f00) [/data/install/linux/wine-src/wine/dlls/user/../../windows/cursoricon.c:1715] in user32 (0x2d89f720) 8 0x12a2175b IMM_Register+0x57 [/data/install/linux/wine-src/wine/dlls/imm32/imm.c:107] in imm32 (0x2d89f76c) 9 0x12a218cc DllMain+0x74(hInstDLL=0x12a10000, fdwReason=0x1, lpReserved=0x0) [/data/install/linux/wine-src/wine/dlls/imm32/imm.c:146] in imm32 (0x2d89f780) 10 0x12a20f88 __wine_dll_main+0x60 in imm32 (0x2d89f7b0) 11 0x6aa37676 call_dll_entry_point+0x12 in ntdll (0x2d89f7c8) 12 0x6aa38673 MODULE_InitDLL+0xdf(wm=0x77e12d40, reason=0x1, lpReserved=0x0) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:741] in ntdll (0x2d89f838) 13 0x6aa387cd process_attach+0x81(wm=0x77e12d40, lpReserved=0x0) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:814] in ntdll (0x2d89f85c) 14 0x6aa39fb8 LdrLoadDll+0x84(path_name=0x77e12c68, flags=0x0, libname=0x2d89f8c4, hModule=0x2d89f8a4) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:1565] in ntdll (0x2d89f884) 15 0x35230e5b load_library+0x4b(libname=0x2d89f8c4, flags=0x0) [/data/install/linux/wine-src/wine/dlls/kernel/module.c:671] in kernel32 (0x2d89f8b4) 16 0x35230f1a LoadLibraryExW+0x2e(libnameW=0x385ccc00, hfile=0x0, flags=0x0) [/data/install/linux/wine-src/wine/dlls/kernel/module.c:726] in kernel32 (0x2d89f8d4) 17 0x35230ede LoadLibraryExA+0x2e(libname=0x6d985ff4, hfile=0x0, flags=0x0) [/data/install/linux/wine-src/wine/dlls/kernel/module.c:707] in kernel32 (0x2d89f8ec) 18 0x35230f50 LoadLibraryA+0x1c(libname=0x6d985ff4) [/data/install/linux/wine-src/wine/dlls/kernel/module.c:746] in kernel32 (0x2d89f904) 19 0x6d972078 LoadImmDll+0x1c [xim.c:78] in x11drv (0x2d89f914) 20 0x6d972972 X11DRV_SetupXIM+0x102(display=0x7974c260, input_style=0x6d98fc50) [/data/install/linux/wine-src/wine/dlls/x11drv/xim.c:440] in x11drv (0x2d89f944) 21 0x6d96b806 x11drv_init_thread_data+0x11a [/data/install/linux/wine-src/wine/dlls/x11drv/x11drv_main.c:502] in x11drv (0x2d89f960) 22 0x6d944f11 X11DRV_create_desktop+0x291(desktop_vi=0x0, geometry=0x7973a9b8) [/data/install/linux/wine-src/wine/dlls/x11drv/desktop.c:251] in x11drv (0x2d89f9ec) 23 0x6d96b54c process_attach+0x148 [/data/install/linux/wine-src/wine/dlls/x11drv/x11drv_main.c:395] in x11drv (0x2d89fa14) 24 0x6d96b905 DllMain+0x35(hinst=0x6d930000, reason=0x1, reserved=0x0) [/data/install/linux/wine-src/wine/dlls/x11drv/x11drv_main.c:524] in x11drv (0x2d89fa20) 25 0x6d93c6d4 __wine_dll_main+0x60 in x11drv (0x2d89fa50) 26 0x6aa37676 call_dll_entry_point+0x12 in ntdll (0x2d89fa68) 27 0x6aa38673 MODULE_InitDLL+0xdf(wm=0x77e12ba0, reason=0x1, lpReserved=0x0) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:741] in ntdll (0x2d89fad8) 28 0x6aa387cd process_attach+0x81(wm=0x77e12ba0, lpReserved=0x0) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:814] in ntdll (0x2d89fafc) 29 0x6aa39fb8 LdrLoadDll+0x84(path_name=0x77e12ac0, flags=0x0, libname=0x2d89fb64, hModule=0x2d89fb44) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:1565] in ntdll (0x2d89fb24) 30 0x35230e5b load_library+0x4b(libname=0x2d89fb64, flags=0x0) [/data/install/linux/wine-src/wine/dlls/kernel/module.c:671] in kernel32 (0x2d89fb54) 31 0x35230f1a LoadLibraryExW+0x2e(libnameW=0x385ccc00, hfile=0x0, flags=0x0) [/data/install/linux/wine-src/wine/dlls/kernel/module.c:726] in kernel32 (0x2d89fb74) 32 0x35230ede LoadLibraryExA+0x2e(libname=0x2d89fbc0, hfile=0x0, flags=0x0) [/data/install/linux/wine-src/wine/dlls/kernel/module.c:707] in kernel32 (0x2d89fb8c) 33 0x35230f50 LoadLibraryA+0x1c(libname=0x2d89fbc0) [/data/install/linux/wine-src/wine/dlls/kernel/module.c:746] in kernel32 (0x2d89fba4) 34 0x3b12e326 load_driver+0x76 [user_main.c:75] in user32 (0x2d89fcdc) 35 0x3b12e8fb process_attach+0x47 [/data/install/linux/wine-src/wine/dlls/user/user_main.c:180] in user32 (0x2d89fcec) 36 0x3b12eaa0 DllMain+0x4c(inst=0x3b0b0000, reason=0x1, reserved=0x1) [/data/install/linux/wine-src/wine/dlls/user/user_main.c:260] in user32 (0x2d89fcfc) 37 0x3b0bf218 __wine_dll_main+0x60 in user32 (0x2d89fd2c) 38 0x6aa37676 call_dll_entry_point+0x12 in ntdll (0x2d89fd44) 39 0x6aa38673 MODULE_InitDLL+0xdf(wm=0x77de0b60, reason=0x1, lpReserved=0x1) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:741] in ntdll (0x2d89fdb4) 40 0x6aa387cd process_attach+0x81(wm=0x77de0b60, lpReserved=0x1) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:814] in ntdll (0x2d89fdd8) 41 0x6aa38867 process_attach+0x11b(wm=0x77de09e0, lpReserved=0x1) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:806] in ntdll (0x2d89fdf8) 42 0x6aa38867 process_attach+0x11b(wm=0x77de0940, lpReserved=0x1) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:806] in ntdll (0x2d89fe18) 43 0x6aa38867 process_attach+0x11b(wm=0x77de0858, lpReserved=0x1) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:806] in ntdll (0x2d89fe38) 44 0x6aa38867 process_attach+0x11b(wm=0x77de0770, lpReserved=0x1) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:806] in ntdll (0x2d89fe58) 45 0x6aa38867 process_attach+0x11b(wm=0x77de0678, lpReserved=0x1) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:806] in ntdll (0x2d89fe78) 46 0x6aa3a87a LdrInitializeThunk+0x1ea(main_file=0x0, unknown2=0x0, unknown3=0x0, unknown4=0x0) [/data/install/linux/wine-src/wine/dlls/ntdll/loader.c:1902] in ntdll (0x2d89ff20) 47 0x3523b109 start_process+0x99(arg=0x0) [/data/install/linux/wine-src/wine/dlls/kernel/process.c:1036] in kernel32 (0x2d89fff4) 48 0x100046a5 wine_pthread_abort_thread+0x29(status=0x0) [port.c:85] in libwine.so.1 (0x00000000) 0x1028dc07: movl 0x4d0(%edx),%eax Wine-dbg> Any idea what to do/try next ? Cheers, Paul Vriens.

Dec. 8, 2004

Re: Searching for an existing Windows installation

by Mike Hearn

On Wed, 08 Dec 2004 02:10:54 +0100, Christian Britz wrote: > because this step during the installation takes very long, I would > suggest to make it optional. We should disable it by default, especially as Windows XP is so common these days. It used to be that using a real 98 drive could improve things a lot, but these days I feel the opposite is true, and using XP/NT almost always made things worse.

Dec. 8, 2004

Re: Searching for an existing Windows installation

by Oliver Stieber

I would suggest: search for windows partitions. look on those partitions for boot.ini files or wine win95 equivilent. voila. ___________________________________________________________ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com

Dec. 8, 2004

Re: Genrate stdole32.tlb file, and install generated files

by Huw D M Davies

On Wed, Dec 08, 2004 at 12:02:28PM +0100, Alexandre Julliard wrote: > Mike Hearn <mh(a)codeweavers.com> writes: > > > Hmm, so the approach with a custom app generating stdole32.tlb is not OK? > > No, we can't run a Winelib app during the build process, and > stdole32.tlb really has to be built like everything else at compile > time. The reason I wrote a program was that I was unable to get midl to generate the correct typelib from stdole32.idl - it really didn't like producing IUnknown iirc. Of course, it may be that I was just being dumb, and that it's perfectly possible to do this. If not I guess we can always lift this restriction on widl. Huw.

Dec. 8, 2004

Re: wine/ windows/win.c windows/painting.c server/ ...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > 2. Bad news: it is *very* slow now. The repaint on > wine List\ View.exe > from the MS Control Spy is painful. > Similarly, menus are slow, dialog boxes, etc. > I have a fast machine (3GHz, 1GB RAM), and it takes > 2-3 seconds to open the File Open dialog. > Is this expected? Part of it is probably because the window moves are not optimized at all, there is currently no attempt to take into account valid bits so any window show/move/resize operation forces a repaint of the whole window. This will be fixed in a subsequent patch. -- Alexandre Julliard julliard(a)winehq.org

Dec. 8, 2004

Re: Includes [4] shlwapi

by Alexandre Julliard

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > winnls.h is included already by wine/unicode.h in url.c, so its not > needed again there. The script I wrote basically comments out the > includes one at a time, and restores any that caused a compile > failure when missing. The worst that could happen is that a new > warning could be generated, but I rebuilt all the files, check the > build logs and believe I got them all. The problem with that approach is that you remove a lot of headers that are included anyway so it doesn't make any difference in build time, and many of them will have to be added again once we finish the header cleanup. For instance you remove winuser.h everywhere win.h is included because win.h brings it in already, but once we get rid of win.h we'll have to go back and re-add winuser.h. What you should do is limit the changes to the cases where it makes an actual difference in the dependency tree. You'll get the same performance gain with a much smaller set of changes. -- Alexandre Julliard julliard(a)winehq.org

Dec. 8, 2004

Re: Genrate stdole32.tlb file, and install generated files

by Alexandre Julliard

Mike Hearn <mh(a)codeweavers.com> writes: > Hmm, so the approach with a custom app generating stdole32.tlb is not OK? No, we can't run a Winelib app during the build process, and stdole32.tlb really has to be built like everything else at compile time. -- Alexandre Julliard julliard(a)winehq.org

Dec. 8, 2004

Re: Wine CVS still broken

by Francois Gouget

On Tue, 7 Dec 2004, Florian Goth wrote: > I deleted my wine - folder and did a full cvs checkout today(23:00 CET ) > But there's still a problem in winejack: Use one of the three patches that have been posted on wine-patches. Just to show I'm really impartial I attached mine<g>. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?

Dec. 8, 2004

Fwd: Foobar2000 audio player Regression

by Nick Hornback

I originally posted this to the -users list, but I was contacted by Robbert Xerox, who had the exact same issue, and thus far nobody has replyed in the users list, so maybe it will get more attention here. > Foobar2000 worked virtually perfectly in the 20041019 > release (aside from some comctrl32 repainting issues > -- which native comctrl32.dll fixed), but in 20041201 > it is completely unuseable. Two major problems: > 1) The toolbars are completely gone. They are sort-of > displayed when they get activity via mouse-press or > whatever, but they do not repaint correctly at all. > See this screenshot for details: > http://img20.exs.cx/my.php?loc=img20&image=w1ifoobar.gif > 2) It takes 100% cpu. In the 20041021 release, it > hovered around 5% cpu (on my athlon 64 3200+), which > was excellent because that beat most native linux > audio players. > The console log is as follows (no errors or warnings): > fixme:hook:NotifyWinEvent (32780,0x10026,-4,1)-stub! > fixme:hook:NotifyWinEvent (32780,0x10026,-4,1)-stub! > fixme:hook:NotifyWinEvent (32780,0x10026,-4,2)-stub! > fixme:hook:NotifyWinEvent (32772,0x1002a,-4,0)-stub! > fixme:hook:NotifyWinEvent (32772,0x1002c,-4,0)-stub! > fixme:win:SetWindowTextA cannot set text "" of other > process window (nil) > Does anyone know what is going on here? I have since found out that if you use a the builtin comctrl32.dll, none of the window repaints at all. In previous wine releases, using the builtin comctrl32.dll would just create minor glitches (ex. the status bar wouldn't update). __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

Dec. 8, 2004

Re: windows/win.c : add missing styles

by Dmitry Timoshkov

"Rémi Assailly" <remi.assailly(a)free.fr> wrote: > --- windows/win.c~ 2004-11-29 18:35:46.000000000 +0100 > +++ windows/win.c 2004-12-07 18:04:02.135332008 +0100 > @@ -872,7 +872,6 @@ > if(style & WS_MINIMIZEBOX) TRACE(" WS_MINIMIZEBOX"); > if(style & WS_MAXIMIZEBOX) TRACE(" WS_MAXIMIZEBOX"); > > - /* FIXME: Add dumping of BS_/ES_/SBS_/LBS_/CBS_/DS_/etc. styles */ Don't remove this line, your patch doesn't add dumping of those styles. > #define DUMPED_STYLES \ > (WS_POPUP | \ > WS_CHILD | \ > @@ -882,6 +881,7 @@ > WS_CLIPSIBLINGS | \ > WS_CLIPCHILDREN | \ > WS_MAXIMIZE | \ > + WS_CAPTION | \ This isn't a style you want to add here. > WS_BORDER | \ > WS_DLGFRAME | \ > WS_VSCROLL | \ > @@ -891,7 +891,94 @@ > WS_GROUP | \ > WS_TABSTOP | \ > WS_MINIMIZEBOX | \ > - WS_MAXIMIZEBOX) > + WS_MAXIMIZEBOX | \ > + BS_DEFPUSHBUTTON | \ > + BS_CHECKBOX | \ > + BS_AUTOCHECKBOX | \ > + BS_AUTOCHECKBOX | \ > + BS_3STATE | \ > + BS_AUTO3STATE | \ > + BS_GROUPBOX | \ > + BS_USERBUTTON | \ > + BS_AUTORADIOBUTTON | \ > + BS_OWNERDRAW | \ > + BS_LEFTTEXT | \ > + BS_ICON | \ > + BS_BITMAP | \ > + BS_LEFT | \ > + BS_RIGHT | \ > + BS_CENTER | \ > + BS_TOP | \ > + BS_BOTTOM | \ > + BS_VCENTER | \ > + BS_PUSHLIKE | \ > + BS_MULTILINE | \ > + BS_NOTIFY | \ > + BS_FLAT | \ > + ES_CENTER | \ > + ES_RIGHT | \ > + ES_MULTILINE | \ > + ES_UPPERCASE | \ > + ES_LOWERCASE | \ > + ES_PASSWORD | \ > + ES_AUTOVSCROLL | \ > + ES_AUTOHSCROLL | \ > + ES_NOHIDESEL | \ > + ES_COMBO | \ > + ES_OEMCONVERT | \ > + ES_READONLY | \ > + ES_WANTRETURN | \ > + ES_NUMBER | \ > + SBS_VERT | \ > + SBS_TOPALIGN | \ > + SBS_LEFTALIGN | \ > + SBS_BOTTOMALIGN | \ > + SBS_RIGHTALIGN | \ > + SBS_SIZEBOXTOPLEFTALIGN | \ > + SBS_SIZEBOXBOTTOMRIGHTALIGN | \ > + SBS_SIZEBOX | \ > + SBS_SIZEGRIP | \ > + LBS_NOSEL | \ > + LBS_COMBOBOX | \ > + LBS_STANDARD | \ > + CBS_SIMPLE | \ > + CBS_DROPDOWN | \ > + CBS_DROPDOWNLIST | \ > + CBS_OWNERDRAWFIXED | \ > + CBS_OWNERDRAWVARIABLE | \ > + CBS_AUTOHSCROLL | \ > + CBS_OEMCONVERT | \ > + CBS_SORT | \ > + CBS_HASSTRINGS | \ > + CBS_NOINTEGRALHEIGHT | \ > + CBS_DISABLENOSCROLL | \ > + CBS_UPPERCASE | \ > + CBS_LOWERCASE | \ > + DS_ABSALIGN | \ > + DS_SYSMODAL | \ > + DS_3DLOOK | \ > + DS_FIXEDSYS | \ > + DS_NOFAILCREATE | \ > + DS_LOCALEDIT | \ > + DS_SETFONT | \ > + DS_MODALFRAME | \ > + DS_NOIDLEMSG | \ > + DS_SETFOREGROUND | \ > + DS_CONTROL | \ > + DS_CENTER | \ > + DS_CENTERMOUSE | \ > + DS_CONTEXTHELP | \ > + SS_USERITEM | \ > + SS_LEFTNOWORDWRAP | \ > + SS_OWNERDRAW | \ > + SS_BITMAP | \ > + SS_ENHMETAFILE | \ > + SS_ETCHEDHORZ | \ > + SS_ETCHEDVERT | \ > + SS_ETCHEDFRAME | \ > + SS_TYPEMASK | \ > + SS_WORDELLIPSIS | \ > + SS_ELLIPSISMASK) And where do you dump all the above listed styles? (Just a hint: you can't dump them without looking at the class name, and it won't work for superclassed windows). -- Dmitry.

Dec. 8, 2004