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

Re: wine/dlls/shell32 shellord.c shlexec.c

by Alexandre Julliard

Duane Clark <dclark(a)akamail.com> writes: > At least in my case, I am using native msvcrt (because I have problems > with CxxFrameHandler in Xilinx ISE). If you still have problems with CxxFrameHandler in latest CVS, please send me a +seh trace and I'll look into it. -- Alexandre Julliard julliard(a)winehq.com

July 25, 2002

Re: Threading on Solaris

by Alexandre Julliard

Gregg Mattinson <gm138242(a)scot.canada.sun.com> writes: > Why does the SYSLEVEL structure have a CRITICAL_SECTION inside it? Shouldn't a > mutex be used instead? No, a mutex is a lot slower, and there is no way for a SYSLEVEL to report that it was abandoned. If a thread gets killed while holding a critical section or syslevel, all bets are off anyway, since you don't know anything about the state of the resource that was protected by the critical section. There is simply no way to recover from that. -- Alexandre Julliard julliard(a)winehq.com

July 25, 2002

Re: shlwapi cleanup

by Alexandre Julliard

"Jürgen Schmied" <juergenschmied(a)lycos.de> writes: > --- wine/dlls/shlwapi/Makefile.in 22 Jul 2002 20:32:53 -0000 1.21 > +++ wine/dlls/shlwapi/Makefile.in 24 Jul 2002 19:21:55 -0000 > @@ -4,8 +4,8 @@ > SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = shlwapi.dll > -# fixme: avoid ole32.dll import > -IMPORTS = ole32 user32 gdi32 advapi32 kernel32 > +IMPORTS = advapi32 gdi32 kernel32 user32 > +DELAYIMPORTS = comctl32 comdlg32 mpr ole32 shell32 version winmm Some of these (like shell32) will create circular dependencies. This must be avoided, our build process doesn't handle that. -- Alexandre Julliard julliard(a)winehq.com

July 25, 2002

Re: wine/dlls/shell32 shellord.c shlexec.c

by Duane Clark

Uwe Bonnes wrote: > > This patch has to do with environment string handling when using builtin > msvcrt. Please verify that the problem is still there when you use native > msvcrt. An perhaps debug a little how environment strings handling > influences your problem. At least in my case, I am using native msvcrt (because I have problems with CxxFrameHandler in Xilinx ISE).

July 25, 2002

Re: wine/dlls/shell32 shellord.c shlexec.c

by Uwe Bonnes

>>>>> "Duane" == Duane Clark <dclark(a)akamail.com> writes: Duane> Tony Lambregts wrote: >> It seems that one of the patches to shlexec.c has broken WinZip. >> The following is a trace from WinZip from this morning. >> >> >> fixme:toolbar:TOOLBAR_CheckStyle [10026] TBSTYLE_ALTDRAG not >> implemented fixme:toolbar:TOOLBAR_CheckStyle [10026] TBSTYLE_ALTDRAG >> not implemented fixme:listview:LISTVIEW_UnsupportedStyles >> !LVS_SHAREIMAGELISTS err:shell:SHGetFileInfoA pidl is null! >> fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray >> 0x405b689c err:shell:SHGetFileInfoA pidl is null! >> >> I have been trying to debug this for a while and it did not have this >> problem yesterday. If you want to download WinZip here is the url >> http://www.winzip.com/ Duane> Well, I do see the same thing, but the patch that breaks it for Duane> me is this one: Duane> http://www.winehq.com/hypermail/wine-cvs/2002/07/0189.html This patch has to do with environment string handling when using builtin msvcrt. Please verify that the problem is still there when you use native msvcrt. An perhaps debug a little how environment strings handling influences your problem. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 25, 2002

Re: wine/dlls/shell32 shellord.c shlexec.c

by Sylvain Petreolle

Couldn't Winzip be designed without thinking about an unsupported listview control ? I know this should have appear before, but the facts are here : WinZip fails in a source file called listview.c and the log shows a line upper a fixme:listview:LISTVIEW_UnsupportedStyles !LVS_SHAREIMAGELISTS > > > > WinZip internal error in file listview.c line 1236 > > > > *WinZip will exit. Please restart WinZip and try again.* > > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

July 25, 2002

Re: wine/dlls/shell32 shellord.c shlexec.c

by Duane Clark

Tony Lambregts wrote: > > It seems that one of the patches to shlexec.c has broken WinZip. The > following is a trace from WinZip from this morning. > > > fixme:toolbar:TOOLBAR_CheckStyle [10026] TBSTYLE_ALTDRAG not implemented > fixme:toolbar:TOOLBAR_CheckStyle [10026] TBSTYLE_ALTDRAG not implemented > fixme:listview:LISTVIEW_UnsupportedStyles !LVS_SHAREIMAGELISTS > err:shell:SHGetFileInfoA pidl is null! > fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray 0x405b689c > err:shell:SHGetFileInfoA pidl is null! > > I have been trying to debug this for a while and it did not have this > problem yesterday. If you want to download WinZip here is the url > http://www.winzip.com/ Well, I do see the same thing, but the patch that breaks it for me is this one: http://www.winehq.com/hypermail/wine-cvs/2002/07/0189.html

July 25, 2002

Re: dos console apps question

by dank＠kegel.com

Jukka wrote: > Yes, many DOS console apps don't work under plain Wine > because DOS emulation does not create console for the > applications. Some applications actually make Wine crash > because the application gets illegal coordinates when > GetConsoleScreenBufferInfo fails. > > The correct place for console allocation would likely > be VGA_SetAlphaMode; call to normal Windows AllocConsole() > function should be enough, no server calls are needed. > Additionally, if DOS console application tries to call a > routine that requires console, VGA_SetAlphaMode should be called > in order to initialize console (see VGA_SetCursorPos). > > I have been thinking doing this myself, but I have always > ended up being uncertain about how this change is going to affect > piping input and output of DOS programs that use only > stream IO and not console IO. Sounds like we need some regression tests that run DOS progams like 'find' and 'more', and make sure they work properly. I myself use the sourcesafe commandline tools, which are of the sort that just pipe characters to stdout and from stdin, and was horrified to discover that sometime after 9/2001, wine stopped running them correctly -- it started putting stdout in raw mode (!), which caused all line-oriented reads from stdin to fail. It also did curses initialization (!!), which made things look very messy indeed. I'm still running my snapshot from around 9/2001, but if I ever get up the energy, maybe I'll write a regression test to make sure e.g. DOS "more" works correctly. - Dan

July 25, 2002

Re: wine/dlls/shell32 shellord.c shlexec.c

by Tony Lambregts

Duane Clark wrote: > Duane Clark wrote: > >> >> Ahh, that was one of the parts I mentioned that I didn't test because >> I did not know how to. Please tell me what you do to generate this >> error. > > > Oh, and please mention exactly which version of Winzip. > > Thanks > > The version of winzip is 8.1. This bug is reproduced as follows: 1. start WinZip --> wine "F:\program files\winzip\winzip32.exe" 2. When the startup screen appears click on the "I agree" button. 3. A message box pops up with the Title "WinZip","Out of resources error, unable to continue. " for the text, and an "OK" button. - click on "OK" button. 4. Another message box pops up with the Title "WinZip", two buttons and the following text: > > WinZip internal error in file listview.c line 1236 > > *WinZip will exit. Please restart WinZip and try again.* > > If this is a recurring problem and you would like WinZip to create a log > file with details about the error so that you can report this problem to the > developers, you can do so now. > The two buttons are "Close WinZip" and "Close WinZip after creating error log file" Clicking on either button will close the wine session. As I said before you can download the program at http://www.winzip.com/ddchomea.htm . This is the version that I am using. Tony Lambregts

July 25, 2002

Re: PATCH: [Bug 19] - font enumeration problems for aliased gdi fonts

by Rafael Kitover

Huw D M Davies wrote: > What's exactly the problem here? Is it lack of support of 16bit EnumFonts ? > > Huw. The problem is this line in X11DRV_EnumDeviceFonts: if (physDev->dc->gdiFont) return FALSE; so if the font is "MS Sans Serif", it will return 0, and old VB apps at least won't like that. But knowing the actual X11 font name given in the wine config, from the alias table it's possible to enumerate it, so those apps will start, that's what that patch does. That's all I really managed to understand here, if there is a better way to do this I will.

July 25, 2002