Well, I switched to Dapper Drake Flight 6, but the X
errors persist. I can reproduce them trivially tonight on
my laptop by hitting Find in wine's Notepad
(I was trying to reproduce http://bugs.winehq.org/show_bug.cgi?id=1614).
The errors look like
X Error of failed request: BadAtom (invalid Ato
HI all, Recently I have been trying to improve support for some MinGW based IDEs without native msvcrt. Now I am dealing with a problem with standard io handle redirection which prevents output from gcc tools from being piped to IDE message windows. I have been able to find that the problem is r
On 4/7/06, Dan Kegel <[EMAIL PROTECTED]> wrote:
> Seems like the recent font patches have
> caused trouble in both Firefox.
> In Firefox, I have to install corefonts for
> text to be legible at all lately.
> Is this expected?
I should mention that there's some chance a change
in my build environme
Seems like the recent font patches have
caused trouble in both Firefox.
In Firefox, I have to install corefonts for
text to be legible at all lately.
Is this expected?
--
Wine for Windows ISVs: http://kegel.com/wine/isv
I'm having a problem with staying connected while logged in to the PlayOnline
service of FFXI. The only debug message I keep finding is a warning that goes
"warn:winsock: WSAErrno errno 4 (Interrupted system call)." I already
submitted a bug for this but I'm wondering if there was anymore I coul
Tom Spear wrote:
On 4/7/06, *Michael Stefaniuc* <[EMAIL PROTECTED]
I couldn't agree more. Matter of fact I recall that this is the reason
that the KLEZ virus from a few years ago was able to infect a linux
system running outlook express on wine, as well as why certain games
crash (they wor
On 4/7/06, Michael Stefaniuc <[EMAIL PROTECTED]> wrote:
Tom Spear wrote:>> That is true, but we also need to make sure that since we are going for> conformity (including conforming to MS's bugs) we don't fix a bug in our> code that is reported by Coverity, but that is also a bug in MS code..
> So i
On Fri, Apr 07, 2006 at 11:47:08AM +0200, Stefan Dösinger wrote:
> I think we need to set the context before the first gl call in a thread. It
> should be enought to do a ckeck in ENTER_GL() if a context is set for the
> current thread, and if not create one and set it.
Yeah, check as soon as yo
Jesse Allen wrote:
> > These lines could explain why Starcraft is unable to switch to fullscreen:
> >
> > err:xrandr:X11DRV_XRandR_GetCurrentMode In unknown mode, returning default
> > fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16
> > to 8
> > fixme:xrandr:X11DRV_XRand
Stefan Dösinger <[EMAIL PROTECTED]> writes:
>> Alexandre, if you think
>> that it should be in the wined3d headers, you can add
>> #define MAKEFOURCC(a,b,c,d) ((a << 0) | (b << 8) | (c << 16) | (d << 24))
>> in line 169 in wined3d_interface.h, or ask me to send a patch for that.
> Forget about tha
Tom Spear wrote:
That is true, but we also need to make sure that since we are going for
conformity (including conforming to MS's bugs) we don't fix a bug in our
code that is reported by Coverity, but that is also a bug in MS code..
So if a game has to work around a bug in MS code, then our
Mike Hearn wrote:
>I'm not really convinced a static
>analysis can catch things that we "know" cannot happen (eg it'd be a
>violation of the X protocol or something) and so rely on them without
>explicit checks.
To be secure, I think we have to handle X protocol violations, too.
- Dan
--
Wine for
I am trying to build wine-0.9.11 on a solaris express system (nevada
b29).
But at the end of compilation, I got link errors in a couple
places. (messages are given below.)
I followed the guidance at
http://www.blastwave.org/wine/winemaking.html
I had not known the tips mentioned at
http:/
On 4/7/06, James Hawkins <[EMAIL PROTECTED]> wrote:
On 4/7/06, Tom Spear (Dustin Booker, Dustin Navea) <[EMAIL PROTECTED]> wrote:> >> > if (srclen < 0) srclen = strlenW(src) + 1;> >> > so we never access the string with a negative index.
> >>> Umm, all that does is increment it by 1... What if _so
Alexandre Julliard wrote:
Robert Reif <[EMAIL PROTECTED]> writes:
Programs that are written specifically for 2000 and xp don't
bother to set the primary buffer format because it's a noop. However
wine is patterned after win9x and DirectX 7 or
earlier which has a real primary buffer and expe
Hi,
At the moment I have problems with LockRect / UnlockRect, described here:
http://archives.free.net.ph/message/20060213.220622.51814d8e.en.html (The
sf.net archives broke the attachmet). This is needed for DDraw, and it's
also a showstopper for many D3D7 games.
Hmm, what application are you
Hi, I am trying to compile something that needs to be compiled defining
UNICODE and _UNICODE but I am getting this error:
In file included from plugins/yapp/../../include/m_database.h:67,
from plugins/yapp/stdafx.h:39,
from plugins/yapp/options.cpp:1:
/usr/include
I am trying to build wine-0.9.11 on a solaris express system (nevada
b29).
But the end of compilation, I got link errors in a couple
places. (messages are given below.)
I followed the guidance at
http://www.blastwave.org/wine/winemaking.html
I had not known the tips mentioned at
http://wik
On Fri, 07 Apr 2006 13:34:49 +0100, Robert Shearman wrote:
> Sorry, you are correct. It does indeed look like a flaw in the scanner:
I'm not sure whether this is a bug in the scanner or some other issue, but
cases where it flags things that cannot happen because of the
design of other parts of the
Petr Tesarik <[EMAIL PROTECTED]> writes:
> Hi everyone,
>
> has this patch been rejected? If so, could anyone tell me why?
The 1/3 patch is OK, but I'd appreciate if you could split the 3/3 one
so I can get a better idea of where you are going with all this.
--
Alexandre Julliard
[EMAIL PROTEC
Drat bitten by formatting again. And i thought i checked but i realized
i checked and then reedited the file and my setting returned to default.
Should i redo the formatting and resubmit?
-aric
Robert Shearman wrote:
Aric Stewart wrote:
if(fodInfos->unicode)
{
LPOPENFILENAMEW ofn =
If the function never checks that parameter for NULL, the checker won't
complain about it.
OK, I didn't realise that, thanks.
Please be careful before writing off a warning from the checker as "not
a bug".
I'll go back over the ones I marked as such and double check them for this.
Alexandre Julliard wrote:
Robert Shearman <[EMAIL PROTECTED]> writes:
/* check for an inherited winstation handle (don't ask...) */
if ((handle = find_inherited_handle( process, &winstation_ops )))
{
winstation = (struct winstation *)get_handle_obj( process,
handle, 0, &winstati
Robert Shearman <[EMAIL PROTECTED]> writes:
>/* check for an inherited winstation handle (don't ask...) */
>if ((handle = find_inherited_handle( process, &winstation_ops )))
>{
>winstation = (struct winstation *)get_handle_obj( process,
> handle, 0, &winstation_ops );
>}
>
On 4/7/06, Robert Shearman <[EMAIL PROTECTED]> wrote:
> >
> >strlen returns a value of type size_t, which is an unsigned value, so
> >this is always going to be positive.
> >
>
> But strlenW returns an int. I think this is the thing that Coverity is
> picking up on.
>
strlenW from include/wine/uni
James Hawkins wrote:
On 4/7/06, Tom Spear (Dustin Booker, Dustin Navea) <[EMAIL PROTECTED]> wrote:
if (srclen < 0) srclen = strlenW(src) + 1;
so we never access the string with a negative index.
Umm, all that does is increment it by 1... What if _somehow_ (dont ask
me how, just ve
Alexandre Julliard wrote:
Robert Shearman <[EMAIL PROTECTED]> writes:
Handle is non-NULL here.
*if* ((handle = find_inherited_handle( process, &desktop_ops )))
It's set to NULL here if we don't find an inherited handle.
/* check for an inherited winstation handle (
On 4/7/06, Tom Spear (Dustin Booker, Dustin Navea) <[EMAIL PROTECTED]> wrote:
> >
> > if (srclen < 0) srclen = strlenW(src) + 1;
> >
> > so we never access the string with a negative index.
> >
>
> Umm, all that does is increment it by 1... What if _somehow_ (dont ask
> me how, just venturing a gu
Hi everyone,
has this patch been rejected? If so, could anyone tell me why?
Yes, I know that neither the API, nor the include files are ideal yet,
but fixing it would produce a really huge patch, which is AFAIK
something you don't like at all.
Anyway, with this patch and my other patches applie
Hello,
Alexandre, if you think
> that it should be in the wined3d headers, you can add
> #define MAKEFOURCC(a,b,c,d) ((a << 0) | (b << 8) | (c << 16) | (d << 24))
> in line 169 in wined3d_interface.h, or ask me to send a patch for that.
Forget about that, I forgot that wined3d_types is included bef
> > At the moment I have problems with LockRect / UnlockRect, described here:
> > http://archives.free.net.ph/message/20060213.220622.51814d8e.en.html (The
> > sf.net archives broke the attachmet). This is needed for DDraw, and it's
> > also a showstopper for many D3D7 games.
>
> Hmm, what applicat
James Hawkins wrote:
On 4/6/06, Mike Hearn <[EMAIL PROTECTED]> wrote:
OK, that was a bit over-enthusiastic. A few of these are more tricky. EG:
Of the possible bugs I've seen so far, most of them are valid and
worth fixing, but the checker stumbles over WideCharToMultiByte. The
check
Robert Shearman <[EMAIL PROTECTED]> writes:
> Handle is non-NULL here.
>
>>*if* ((handle = find_inherited_handle( process, &desktop_ops )))
It's set to NULL here if we don't find an inherited handle.
>>{
>>desktop = get_desktop_obj( process, handle, 0 );
>>*if* (!desktop
Alexandre Julliard wrote:
Robert Shearman <[EMAIL PROTECTED]> writes:
ChangeLog:
The desktop variable could be NULL when set_process_default_desktop is
called, so check for this. (Found by Coverity).
I don't see how this could happen. Did I miss something?
See below.
void connec
> At the moment I have problems with LockRect / UnlockRect, described here:
> http://archives.free.net.ph/message/20060213.220622.51814d8e.en.html (The
> sf.net archives broke the attachmet). This is needed for DDraw, and it's
> also a showstopper for many D3D7 games.
Hmm, what application are yo
Robert Shearman <[EMAIL PROTECTED]> writes:
> ChangeLog:
> The desktop variable could be NULL when set_process_default_desktop is
> called, so check for this. (Found by Coverity).
I don't see how this could happen. Did I miss something?
--
Alexandre Julliard
[EMAIL PROTECTED]
On 4/7/06, James Hawkins <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Changelog:
> * Rewrite get_parameter to be able to handle an empty parameter.
>
blah Ignore this, because I sent too much in one patch.
--
James Hawkins
Robert Reif <[EMAIL PROTECTED]> writes:
> Programs that are written specifically for 2000 and xp don't
> bother to set the primary buffer format because it's a noop. However
> wine is patterned after win9x and DirectX 7 or
> earlier which has a real primary buffer and expects the
> program to chan
Detlef Riekenberg <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED]:~/wine.cvs/bin$ etags --version
> Exuberant Ctags 5.5.4, Copyright (C) 1996-2003 Darren Hiebert
> Compiled: Aug 13 2004, 05:14:24
> Addresses: <[EMAIL PROTECTED]>,
> http://ctags.sourceforge.net
> Optional compiled features: +
Hi,
> Note that the game is unplayable because it lags and lags and lags. I
> must wait 3 to 5 minutes before my character appears. And when i move, i
> see an image approximatively each second, it is jerky... I think it
> comes from the thing you said before : poor performance, but i prefer
> anno
Hi,
> If we add 'intelligent' (i.e. 'lazy' or 'just in time' :-) ) state change
> evaluation it could even be pretty efficient code-wise (maybe not so
> efficient in the GL driver though as it may lead to more 'pipeline flushes'
> than the 'hacky' solution).
I think we need to set the context befor
Mike McCormack <[EMAIL PROTECTED]> writes:
> --- a/dlls/msi/table.c
> +++ b/dlls/msi/table.c
> @@ -1604,13 +1604,12 @@ static MSIRECORD *msi_get_transform_reco
> USHORT mask = *rawdata++;
> MSICOLUMNINFO *columns = tv->columns;
> MSIRECORD *rec;
> -const int debug_transform = 0;
Am Freitag, den 07.04.2006, 10:38 +0200 schrieb Alexandre Julliard:
> > [EMAIL PROTECTED]:~/wine.cvs/bin$ make etags
> > find /home/detlef/wine.cvs/src -name '*.[ch]' -print | etags -
> > etags: Unknown option: -
> > make: *** [etags] Fehler 1
> > What's not broken about them?
>
> Well, it works f
Detlef Riekenberg <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED]:~/wine.cvs/bin$ make etags
> find /home/detlef/wine.cvs/src -name '*.[ch]' -print | etags -
> etags: Unknown option: -
> make: *** [etags] Fehler 1
> -
>
> What's not broken about them?
Well, it works fine here, so you'll have
Am Donnerstag, den 06.04.2006, 21:41 +0200 schrieb Alexandre Julliard:
> > "make etags" and "make ctags" are broken.
>
> What's broken about them?
-
[EMAIL PROTECTED]:~/wine.cvs/bin$ make ctags
find /home/detlef/wine.cvs/src -name '*.[ch]' -print | ctags --c-types=
+px -L -
-
The file "
>On Thu, Apr 06, 2006 at 10:18:16AM +0200, Stefan Dösinger wrote:
>> Because windows' ddraw.dll restores everything when the app exists. I've
>> added
>> some code to do that do my ddraw lib. I restore the screen mode when the
>> ddraw object is released, and on the last DllMain() unload call,
Mike McCormack wrote:
>
> Tomas Carnecky wrote:
>
>>> * Another (missing NULL ptr check in LoadTypeLibEx) is right, but, I
>>> don't
>>> think we want to add lots of missing NULL arg checks in the public
>>> API implementations. An application will never pass NULL to this
>>> function directly
Tomas Carnecky wrote:
* Another (missing NULL ptr check in LoadTypeLibEx) is right, but, I don't
think we want to add lots of missing NULL arg checks in the public API
implementations. An application will never pass NULL to this function
directly as otherwise it'd not work at all, so, a cr
48 matches
Mail list logo
