October 2005 - Wine-Devel - list.winehq.org

Re: wine/dlls/ntdll signal_i386.c exception.c

by Marcus Meissner

> >+" leal -12(%ebp), %eax\n" > >+" .byte 0x64\n" > >+" movl (0),%ecx\n" > > > > > > Is it not possible to use the proper %fs prefix instead of having to put > a bytecode in manually? It will likely not build with all assemblers. This is taken from the wine_push_frame() inline assemblercode directly. > >+" movl %ecx,(%eax)\n" > >+" .byte 0x64\n" > >+" movl %eax,(0)\n" > >+" movl 20(%ebp), %eax\n" > >+" pushl %eax\n" > > > > > > There is no need to move the variable into %eax before pushing, as > "pushl 20(%ebp)" will work as shortens the assembly. I used the assembler code that gcc generated directly. :/ > >+ * For i386 this function is implemented in assembler in signal_i386.c. > > > > > > It seems bad to split the function's implementation up like this? We > also now lose the TRACE's that were previously printed from within > EXC_CallHandler. If they are superfluous to requirements we might as > well delete them from the generic function too. I did not want to merge the TRACE()s into assembler, because this one might change and thenthe assembler would need to be ported. They could go from the generic one, yes. Ciao, Marcus

Oct. 31, 2005

KERNEL: force copying of DOS-style path into argv[0] of PE process (was: Re: Queries about some 'usability' points) - partially fixes #3542

by Alex Villacís Lasso

Lionel Ulmer wrote: >On Thu, Oct 27, 2005 at 04:17:17PM -0500, Alex Villacís Lasso wrote: > > >>The page says that you have a patch that fixes something. Is that the >>issue about the executable path name, or the one about the game refusing >>to go past the splash screen, or the one about the mouse cursor? >> >> > >It's only fixing the mouse cursor issue. > > Lionel > > > This is a patch to fix the primary bug on DungeonKeeper. I am surprised this bug was overlooked up to 0.9, since this is such a basic characteristic of Windows. The basic problem is that Wine is passing the argv[] array unmodified (except for the removal of the 'wine' reference itself) to the PE process. This means that, unless the user writes a DOS-style path at wine invocation, the PE process receives an UNIX-style relative path as its argv[0]. This differs from standard behavior in MS-DOS and Windows, where the argv[0] of the process contains a fully qualified DOS-style path (such as C:\WINDOWS\FOO.EXE) regardless of the method used to run the executable. DungeonKeeper relies on this characteristic of MS-DOS/Windows and crashes when it sees the UNIX-style path. This patch will also be sent to wine-patches, as a fix for one of the issues of bug 3542. Note that the patch, as it stands, only fixes PE executables. Winelib applications continue to receive an UNIX-style path. I don't really know whether this is the right thing to do, but winelib apps surely know that they are running in an Unix environment, so they know how to deal with an Unix-style argv[0]. However, this poses the question of how to write a test for this bug, since all tests are winelib applications. BTW, could you please post the mouse-cursor issue patch? I also have a Japanese RPG for which the mouse cursor gets stuck at the center of the window, and I think that problem and the one in DungeonKeeper might be one and the same. Changelog: * Force a copy of the fully-qualified DOS-style executable path into argv[0] of the current PE process.

Oct. 31, 2005

Re: wine/dlls/ntdll signal_i386.c exception.c

by Robert Shearman

Alexandre Julliard wrote: >Index: wine/dlls/ntdll/signal_i386.c >diff -u -p wine/dlls/ntdll/signal_i386.c:1.100 wine/dlls/ntdll/signal_i386.c:1.101 >--- wine/dlls/ntdll/signal_i386.c 31 Oct 2005 14: 8: 5 -0000 >+++ /dev/null 31 Oct 2005 14: 8: 5 -0000 >@@ -1384,4 +1384,36 @@ __ASM_GLOBAL_FUNC( DbgBreakPoint, "int $ > */ > __ASM_GLOBAL_FUNC( DbgUserBreakPoint, "int $3; ret"); > >+ >+/********************************************************************** >+ * EXC_CallHandler (internal) >+ */ >+__ASM_GLOBAL_FUNC( EXC_CallHandler, >+" pushl %ebp\n" >+" movl %esp, %ebp\n" >+" subl $12, %esp\n" >+" movl 28(%ebp), %eax\n" >+" movl 12(%ebp), %edx\n" >+" movl %eax, -8(%ebp)\n" >+" movl %edx, -4(%ebp)\n" >+" leal -12(%ebp), %eax\n" >+" .byte 0x64\n" >+" movl (0),%ecx\n" > > Is it not possible to use the proper %fs prefix instead of having to put a bytecode in manually? >+" movl %ecx,(%eax)\n" >+" .byte 0x64\n" >+" movl %eax,(0)\n" >+" movl 20(%ebp), %eax\n" >+" pushl %eax\n" > > There is no need to move the variable into %eax before pushing, as "pushl 20(%ebp)" will work as shortens the assembly. >+" movl 16(%ebp), %eax\n" >+" pushl %eax\n" >+" movl 8(%ebp), %eax\n" >+" pushl %edx\n" >+" pushl %eax\n" >+" call *24(%ebp)\n" >+" movl -12(%ebp), %edx\n" >+" .byte 0x64\n" >+" movl %edx,(0)\n" >+" leave\n" >+" ret\n" >+); > #endif /* __i386__ */ >Index: wine/dlls/ntdll/exception.c >diff -u -p wine/dlls/ntdll/exception.c:1.85 wine/dlls/ntdll/exception.c:1.86 >--- wine/dlls/ntdll/exception.c 31 Oct 2005 14: 8: 5 -0000 >+++ /dev/null 31 Oct 2005 14: 8: 5 -0000 >@@ -116,7 +116,10 @@ static DWORD EXC_UnwindHandler( EXCEPTIO > * happening during the handler execution. > * Please do not change the first 4 parameters order in any way - some exceptions handlers > * rely on Base Pointer (EBP) to have a fixed position related to the exception frame >+ * >+ * For i386 this function is implemented in assembler in signal_i386.c. > > It seems bad to split the function's implementation up like this? We also now lose the TRACE's that were previously printed from within EXC_CallHandler. If they are superfluous to requirements we might as well delete them from the generic function too. > */ >+#ifndef __i386__ > static DWORD EXC_CallHandler( EXCEPTION_RECORD *record, EXCEPTION_REGISTRATION_RECORD *frame, > CONTEXT *context, EXCEPTION_REGISTRATION_RECORD **dispatcher, > PEXCEPTION_HANDLER handler, PEXCEPTION_HANDLER nested_handler) > > -- Rob Shearman

Oct. 31, 2005

Theme issues

by Kevin DeKorte

Using the clearlooks theme I found the following inconsistencies using WINE 0.9 1. Scroll bars don't seem to apply the theme 2. winefile the MDI minimize/maximize/close buttons have a square on them rather than something useful 3. Some of the wine icons (the file open dialog as seen from notepad) don't to have transparency implemented. (not a show stopper) Otherwise, wine is looking really really good for the apps I use it for. Notes 6.51 is the main one. Kevin -- Get my public GnuPG key from http://keyserver.veridis.com:11371/export?id=7574690260641978351

Oct. 31, 2005

Fwd: Re: Half-Life 2 / Counter-Strike: Source under Wine

by Oliver Stieber

--- Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote: > Date: Mon, 31 Oct 2005 15:00:43 +0000 (GMT) > From: Oliver Stieber <oliver_stieber(a)yahoo.co.uk> > Subject: Re: Half-Life 2 / Counter-Strike: Source under Wine > To: James Liggett <jrliggett(a)cox.net> > > > --- James Liggett <jrliggett(a)cox.net> wrote: > > > On Sun, 2005-10-30 at 11:34 -0600, Evil wrote: > > > Thanks for the tip, James! Disabling all the debugging had a much > > > bigger impact than I would have expected. I've included my observations > > > and comments below, in hope that they might be of use to the devs > > > working on DX. > > Yeah, you wouldn't think turning off debugging messages would do much of > > anything but it does. Don't ask me why though... :) > > > > > > The Counter-Strike: Source Video Stress Test is now giving me 15.74fps > > > in 1024x768 windowed mode (vs. 24 in Cedega and 44 in Win98). It's a > > > definite step in the right direction, but still a little too low to > > > prevent you from getting shot by any newb. :) I get the same speed at > > > lower resolutions, which indicates that I'm CPU-limited. I can believe > > > that, since it's pegged-out the entire time I run the test. > > Hmmm... I can usually get double that. My card isn't all that different > > from yours (I have a Radeon 9800 pro) Personally I think it has more to > > do with the speed of the code and yet to be implemented features. I can > > imagine that since Oliver is still trying to stabilize things and > > implement stuff, speed isn't yet the priority. > > I've got quite a few optimizations to check-in, but I don't think it's a good idea putting in > optimizations that may break things until wined3d is stable enough that bugs in wined3d don't go > on to break the optimizations. > > You may be limited on your bus speed, d3d8/wined3d aren't using AGP and they upload the vertex > data for every frame. > > > > > > I get pretty much the same performance whether I am windowing the game > > > by setting wine to emulate a desktop, or just passing -window to the > > > hl2.exe (15.2fps). > > > > > > The odd thing to me is: I get the same speed when running in fullscreen > > > mode. This is even the case if I used XRandR to set my desktop to the > > > same resolution before starting Steam, so that I don't end up > > > accidentally scrolling across my virtual desktop when I move the mouse > > > down or to the right. Doing that is also a help because it stops my > > > newsticker from drawing over the top of the game screen, but it seems to > > > have no impact on performance. > > > > > > Do OpenGL applications typically perform the same in windowed mode as > > > fullscreen mode? My experience programming with DirectX made me expect > > > fullscreen to run faster since the video card only has to flip the > > > backbuffer pointer instead of blitting from one chunk of memory to > > > another. Of course, that all being handled by the video card, I suppose > > > this too is probably just a side-effect of my CPU-limited speed. > > I wouldn't think running a game in a window versus full-screen would > > change much of anything. Then again, I'm no 3D expert either. > > > > > > Here are the parameters I'm feeding to CS:S by the way, in case anyone's > > > interested: "-heapsize 512000 -fullscreen -width 1024 -height 768". > > > I've tried passing "-dxlevel 70" to the hl2.exe, but don't see much if > > > any performance difference. It is interesting to not that if you don't > > > pass this parameter, you will see little white boxes indicating each > > > light source. These boxes aren't clipped by any object. > > > > > > Passing "-dxlevel 80" causes the menu screen to come up completely > > > white, making it unuseable. Forcing DirectX 8.1 or 9.0 has the same > > > white-screen effect. > > Try disabling pixel shaders in winecfg to get around that. They never > > did work for me. I tried to use them yesterday with HL2 to get some > > screenshots, and they froze my computer. If you're lucky enough to even > > star a game using them, they mess things up anyway. > > I'm in the middle of fixing pixel shaders properly, so far I've checked in the code to parse and > cross compile the pixel shaders, I just have to intergrate them with the drawing pipeline. > > Oliver. > > > > > > ___________________________________________________________ > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail > http://uk.messenger.yahoo.com > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Oct. 31, 2005

Small visual issues with P-CAD2000 and wine 0.9

by Marcos Vicente Cruz

HI, I having small visual issues in P-CAD 2000's toolbar on Linux since I've upgraded to wine 0.9. The buttons aren't displayed properly. See the screenshot attached. Thank you, Marcos

Oct. 31, 2005

Re: Custom Windows Program Loader

by Informações

Thanks everyone for the insightful information. Actually, the solution provided looks quite simple. However, I was trying to make some naive tests one my Windows box and got stuck on something that looks quite simple as well... I just can't find the KERNEL32.DLL library that I expected to be inside the downloadable "wine-dlls-0.9-mingw.zip" package. ;.( Can anyone confirm me if this package has successfully being build on Windows using MingW ? If so, where should I look for it ? If not, which were the caveats ? Just another piece of information: I extracted the contents of this package in a temporary directory and placed the notepad.exe executable along with the dummy notepad.exe.local file inside the same directory. When I try to run notepad, I have an error message that reads something like: "It wasn't possible to find the entry-point for the procedure wine_get_unix_file_name in dynamic library kernel32.dll" The message is written in portuguese, and this is the best translation that I was able to do. It looks like any other Wine library tries to call a procedure from the Wine kernel32,dll but ends up calling this procedure on the native kernel32.dll. Is that right ? Any help is greatly appreciated. FLu-X ----- Original Message ----- From: "Anssi Hannula" <anssi.hannula(a)mbnet.fi> To: "Informações" <info(a)sparsi.com> Cc: <wine-devel(a)winehq.org> Sent: Friday, October 28, 2005 6:01 PM Subject: Re: Custom Windows Program Loader -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Informações wrote: > Hey All, Hi! > I've been trying to solve a problem that WINE seems to have tacked > quite properly: I need to run a Windows application under Windows OS > using custom DLLs in place of Windows-kernel DLLs. For instance, I wanna > be able to run the Notepad application loading all its required DLLs > from the Windwos/System path but, for instance, user32.dll, that I will > provide as a custom implementation. > > As I can seem, WINE program loader does the job, but not under > Windows. Does anybody have any clue on how to make this "magic" happens > on a Windows environment (possibly inside cygwin) ? Does anybody know > any other tool capable of providing this functionality ? http://www.winehq.com/?issue=271#Wine DLLs on Windows - -- Anssi Hannula -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFDYpGm62+GgqekZEoRAgVQAJ9tMbZY3/5sCwa5HZnvUDgcrHWbQACePnIM LPxVGUQk0YCBNH9O8NX4Ay0= =/up1 -----END PGP SIGNATURE-----

Oct. 31, 2005

Re: [Bugzilla] and [AppDB] add ability to mark Wine versions as 'obsolete', 'supported' or 'current'

by Jeremy Newman

Curious. The more we diverge our Bugzilla from the mainline Bugzilla, the harder it will be for us to upgrade. I've had requests to get us up to the latest release. But I'm fearful of the amount of work it will be to clean it up once the merge is complete. That and the last time I upgraded Bugzilla the upgrade process deleted all the comments from the DB. (Note: not a problem anymore as we keep good DB backups.) Maybe someone with more time can look into keeping our Bugzilla current and maintain our patches. On Sat, 2005-10-29 at 16:24 -0600, Tony Lambregts wrote: > This patch is meant to stimulate a discussion about how to deal with the > fact we cannot reasonable support obsolete versions of wine ;^) > > For example we would like to be able to age Test Results and probably > do not want submittions of test results or bugs that are from older > versions of wine. On the other hand we should accept new bug reports > from CVS and at least our current release. Since we cannot simply delete > old versions in bugzilla I came up the following patch. > > To use this patch you need to run the following sql: > > use bugs; > alter table versions add column status > enum('obsolete','supported','current') NOT NULL default 'current'; > > change log: Add status ('obsolete','supported' or 'current') to versions > table

Oct. 31, 2005

Re: ermapper 7

by Paul Wise

On Sun, 2005-10-30 at 19:00 +0800, Paul Wise wrote: > Was trying to install ermapper 7 under wine (80 meg download): > http://www.ermapper.com/download_files/ERMapper7.01CompactRC1.exe > > In debian wine 0.9*, it installs fine with OS set to winxp, except for > one thing: since it seems to use OLE/COM extensively, the main > application object doesn't get registered during installation. I've posted a bug about this: http://bugs.winehq.org/show_bug.cgi?id=3714 -- bye, pabs http://pabs.zip.to

Oct. 31, 2005

25% success rate on wife's must-have apps!

by Dan Kegel

I asked my wife what apps she uses daily on Windows, and tested all eight with wine from cvs this weekend. Results: 2 of the eight actually installed and ran properly. She was duly impressed - she thought it was going to be zero. Apps that Work: Macromedia Fireworks (2002) Font Xplorer Lite Apps that install but don't run: Macromedia Dreamweaver (2002) Can't install: Microsoft Office '97 Adobe Photoshop Elements Ulead Photoimpact Musicmatch Jukebox FamilyTreeMaker 6 I filed bugzilla reports for all the problems I found. Links at http://kegel.com/wine/qa/#app.home - Dan

Oct. 31, 2005