wine-devel December 2007

wine-devel@winehq.org

139 participants
264 discussions

re: ole32: fix wrong timeout check
by Dan Kegel 23 Dec '07

23 Dec '07

>- if ((dwTimeout != INFINITE) && (start_time + dwTimeout >= now)) >+ if ((dwTimeout != INFINITE) && (now >= start_time + dwTimeout)) >From time immemorial, it has been drummed into me that one should always handle wraparound when checking timers. So something like DWORD delta = now - start_time; if (dwTimeout != INFINITE) && (delta < 0x80000000UL) && (delta > dwTimeout)) might be more correct... I used to always use a signed variable for this, but C compilers now treat overflow of signed variables as a conceptual error, so the subtraction has to be unsigned, There's probably a cleaner way to code this, but doing the subtraction to get the delta time, and then comparing against the maximum desired delta time, is the way to avoid trouble at rollover. - Dan

3 2

Re: tools/wineshelllink: do not execute applications directly, use 'start' utility instead
by Vitaliy Margolen 23 Dec '07

23 Dec '07

Kirill K. Smirnov wrote: > This is needed by console applications. > Fixes bug #10867 > > -Exec=env WINEPREFIX="${WINEPREFIX:-$HOME/.wine}" wine "$path" $args > +Exec=env WINEPREFIX="${WINEPREFIX:-$HOME/.wine}" wine start "$path" $args This is not correct. If console needs to be created for those apps and there isn't one, then Wine should do it when starting an app. Vitaliy.

1 0

Re: bugfix for bug #6994
by Stefan Dösinger 23 Dec '07

23 Dec '07

Am Sonntag, 23. Dezember 2007 01:43:17 schrieb Alexei Slepov: > Subject: > > We can't use ordinary backbuffer to render textures, which size is more > than > size of the screen. To render bigger texture we must use pbuffer. You can't just set the setting to PBUFFER, you at least have to check if pbuffers are supported. The proper fix is IMHO to fix the problems fbos suffer from and default to fbo offscreen rendering

1 0

Looking for serious Photoshop 7/CS users to break wine
by Dan Kegel 23 Dec '07

23 Dec '07

Our support for Photoshop 7 and maybe CS is strong enough for industrial users -- and if it isn't, I'd like to know about it so we can do something about it. So I posted notes asking for serious Photoshop users to try it and let us know what's still broken: http://ubuntuforums.org/showthread.php?p=4001494 http://www.adobeforums.com/webx/.3c05a212 Hopefully that will bring in some good bug reports. - Dan p.s. The latter message reads -- snip -- Topic: Wine Project looking for Photoshop CS users who want Linux support If you're not a Linux user, or if you don't like the idea of running Photoshop for Windows on Linux, you can stop reading now, this message probably won't be interesting to you. The Wine project is looking for hardcore Photoshop CS or 7 users who use Photoshop professionally, all day, every day, and who are willing to tell us why they can't do that in Linux using Wine yet. We know everybody would like Photoshop CS3 or at least CS2 support, but support for CS2 and CS3 isn't quite ready, so we'd like to focus on our strengths, and support Photoshop 7 and CS excellently. Don't worry, we're also working on the CS2 and CS3 issues. Getting all the 7 and CS issues taken care of builds a stronger foundation for CS2 and CS3. If something doesn't work in Photoshop 7 or CS itself, or your favorite plugin works in Windows with 7 or CS but not in Wine, please let us know how to reproduce the problem. To do that, just reply to this post, or post in the wine-users mailing list, or leave a comment in the wine appdb for Photoshop 7 or CS, or file a bug in the Wine Bugzilla, whichever you're more comfortable with. We'll take it from there; if we can reproduce it, we'll file a bug and see if we can get a wine developer to fix it. Ideally you'd test with the latest release of Wine (currently 0.9.51), but if you're still on a slightly older version, don't sweat it, we'll retest on the latest for you. Thanks! Dan Kegel Wine 1.0 Release Manager -- snip --

1 0

re: New bugzilla components (round 3)
by Dan Kegel 23 Dec '07

23 Dec '07

vdm is a bit cryptic, could we call it win16 instead? That's a bit broader, but that's ok. The other products could use some attention, too. Wine HQ Apps Database website-bugs -> appdb-misc WineHQ Bugzilla bug list -> delete comments -> delete login -> delete misc-bugs -> bugzilla-misc WineHQ.com (rename WineHQ.org) misc-web -> www-misc

1 0

skype regression (kernel32 / winedos)
by Alexander Dorofeyev 23 Dec '07

23 Dec '07

Hi. Unfortunately, Skype stopped working in git wine, it crashes shortly after start. Commit found via bisect: http://source.winehq.org/git/wine.git/?a=commit;h=e2a366ce338d5b6b0f3c8962d… kernel32: Forward interrupts in 32-bit code to winedos too last messages with +io,+int: warn:int:DOSVM_GetBuiltinHandler int1 not implemented, returning dummy handler warn:int:DOSVM_GetBuiltinHandler int1 not implemented, returning dummy handler warn:int:DOSVM_GetBuiltinHandler int1 not implemented, returning dummy handler err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception. fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for 8000000a Skype ver 3.5.0.239, wine mode - WinME

1 0

Re: loader: Add --compile-info option to Wine.
by Peter Beutner 23 Dec '07

23 Dec '07

Andrew Riedi schrieb: > Sometimes Wine has optional features that users want to enable, but that > require specific headers to compile. For bug reports, and the user IRC > channel, it seemed a good idea to add an option to Wine to figure out > what optional features have been compiled into Wine. Also, specific > versions of GCC may cause problems for specific programs that involve > copy protection software. To help out users, testers, people who tend > to our bugzilla, and other people involved with Wine, I decided to add > an option to Wine to output this valuable information. > + /* Compiler */ + printf( "\nCompiler:\n" ); +#ifdef __GNUC__ + printf( "\tGCC %d.%d.%d\n", __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__ ); +# if (__GNUC__ == 4 && (__GNUC_MINOR__ == 0 || __GNUC_MINOR__ == 1)) + printf( "\t**This GCC may cause problems with copy protection.**\n" ); +# endif +#endif As I recall this is not the only version that causes problems. Plus certain compiler flags have an influence as well. And as most distros ship gcc with a bunch of patches you probably can't even rely on the gcc version alone. Imo it would be better to collect the info on a wiki page.

9 12

Re: wined3d: fix check for P8 render target
by Roderick Colenbrander 23 Dec '07

23 Dec '07

> Hi. > > I think this part of d3dfmt_p8_init_palette has a bug, because it appears > to be > checking that render target is a render target. Incorrectly going into > index_in_alpha codepath here causes this bug: > > http://bugs.winehq.org/show_bug.cgi?id=10797 > > in Aliens vs Predator 1 game - it prefers P8 textures and sets color key > on some > textures for transparency and alpha channel is wrong on such textures in > game. > > --- > dlls/wined3d/surface.c | 7 ++----- > 1 files changed, 2 insertions(+), 5 deletions(-) > > Hi, Unfortunately this patch is not correct and I haven't looked exactly what the real issue is. In short most hardware (except if it has GL_EXT_paletted_texture) doesn't support 8bit textures and most of the time we do 8bit->32bit conversion in software. On hardware that supports fragment shaders we perform the conversion using a shader and this is a lot faster (it is 'free'). The palette is uploaded in d3dfmt_p8_init_palette. So the p8 conversion is done in hardware but in some cases we need to read back the data from the card. The p8 -> 32bit conversion was done behind the back of the game, so the game expects 8bit data back. A palette contains upto 256 entries and each color can appear multiple times in the palette. So the inverse palette lookup doesn't have a 1:1 mapping and this is problematic. The trick we do is to store the 8bit color index in the alpha component of the palette and use this to read back the correct index during the 32bit->8bit conversion. The problem is that most games need alpha and for that reason we only use this 'hack' when the primary render target is using 8bit. In this case you can't be using 3D and only old apps like StarCraft use this. Your game is likely using some p8 textures and is likely suffering from the 32 -> 8bit problem. I haven't check AVP but if this is the real issue there it can't be fixed. It would break other games like GTA4 and others. Regards, Roderick Colenbrander -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10

2 3

Re: bugfix for bug #6994
by Chris Robinson 23 Dec '07

23 Dec '07

On Saturday 22 December 2007 04:43:17 pm Alexei Slepov wrote: > We can't use ordinary backbuffer to render textures, which size is more > than > size of the screen. For example, if the screen size is 800x600, we can't > render background texture, which size is 1024x1024. So, if we are using > backbuffer, we see only part of texture, which size is exactly 800x600. > The only way to make the application working properly is to use pbuffer. This is what the OffscreenRenderMethod option is for. If it's set to backbuffer, wined3d needs to use the backbuffer as well as it can. If you need to use pbuffers, set it to pbuffer (which I believe is the default?). Or if the card supports it, use fbo, which is more flexible (and needed for some of D3D9's capabilities, IIRC).

1 0

Fix build when valgrind header is present but does not define VALGRIND_MAKE_WRITABLE
by Vincent Pelletier 22 Dec '07

22 Dec '07

Fixes gcc error: signal_i386.o: In function `setup_exception': /home/vincent/git/wine/dlls/ntdll/signal_i386.c:940: undefined reference to `VALGRIND_MAKE_WRITABLE' collect2: ld returned 1 exit status Others uses of this constant are already checked this way.

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
27
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2007