Jeff L wrote:
Dmitry Timoshkov wrote:
Yes, 'attr' is used without a NULL check earlier, but that's an actual
bug, and that's where the code needs to be fixed.
So in this case my change is ok for the tidy up that it is, it just
that there is another problem. Is this in bugzilla?
Jeff
Lookin
Dmitry Timoshkov wrote:
"Jeff Latimer" <[EMAIL PROTECTED]> wrote:
Coverity Cid:344 highlighted a REVERSE-INULL. This patch removes the
redundant null tests as it is clear from the code above that the
pointer has already been used to dereference and can't be null.
Yes, 'attr' is used without
"Jeff Latimer" <[EMAIL PROTECTED]> wrote:
Coverity Cid:344 highlighted a REVERSE-INULL. This patch removes the
redundant null tests as it is clear from the code above that the pointer
has already been used to dereference and can't be null.
Yes, 'attr' is used without a NULL check earlier, bu
+if (stateblock->wineD3DDevice->vs_selected_mode != SHADER_NONE && stateblock->vertexShader &&
+ ((IWineD3DVertexShaderImpl *)stateblock->vertexShader)->baseShader.function != NULL)
+memcpy(&stateblock->wineD3DDevice->strided_streams,
stateblock->wineD3DDevice->up_strided,
s
On 1/1/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> So what's Wine to do? Can we somehow tell Wine
> to emulate 256 color mode for particular apps?
If it is a DirectDraw application then wine will emulate 256 color
mode(palettized colors).
The app in question is "I Spy Junior", which seem
This is the first time I've submitted a patch, so let me know if this
method of submission is incorrect. See description in the attachment.
It's best to put the description in the body of the mail, and write a
descriptive subject like "ole32: fix StgOpenStorage conformance test
failure" or s
Got ya, -- looking at the heapfree impl -- it does the check first (so it is
defined in Wine)
-- So please ignore this patch then --
However, this seems dangerous if you wanted to take any of that code and run
it under windows (but im guessing xp and 2k work this way -- and few people
use 95/
DO NOT top post bottom posted emails!!!
Nick Burns wrote:
>> From: Stefan Dösinger <[EMAIL PROTECTED]>
>> To: wine-devel@winehq.org
>> CC: Nick Burns <[EMAIL PROTECTED]>
>> Subject: Re: dlls/opengl32/wgl.c: minor dealloc fix
>> Date: Mon, 1 Jan 2007 22:33:49 +0100
>>
>>
>> Am 01.01.2007 um 11:03 sc
My son got a cd-rom game for xmas, so of course
I tried it in Wine. It installs fine, but the app just
hangs unless you started X with -depth 8.
(And even then the colors are all wrong, but that's
a different problem.)
X's randr extension was originally going to allow
switching screen resolution
Am 02.01.2007 um 00:54 schrieb Nick Burns:
According to...
http://msdn2.microsoft.com/en-us/library/aa366701.aspx
lpMem
[in] ...If this pointer is NULL, the behavior is undefined.
I personally dislike undefined behaviour -- If it is defined to NOP
in wine that is sufficent for me.
Bu
Thanks for the comments --
FIXME -> ERR done
dllmain ret TRUE -> FALSE done
LGPL thingy added
I will resubmit the patch soonish with these changes... (stupid cold might
have come back)
Relays can give you the params (and ret values) -- for now i have the traces
tell you what exts the app
According to...
http://msdn2.microsoft.com/en-us/library/aa366701.aspx
lpMem
[in] ...If this pointer is NULL, the behavior is undefined.
I personally dislike undefined behaviour -- If it is defined to NOP in wine
that is sufficent for me.
But I think/tought I had a crash there tho...
-
Am 01.01.2007 um 12:06 schrieb Nick Burns:
Here is my OpenAL32.dll thunk demacroized. Sorry this took so long
-- finally got some time with the break.
This is basically the same patch as before -- supports the same
functionality and all -- but no more cool macros (of doom)
(~500 lines ->
Am 01.01.2007 um 11:03 schrieb Nick Burns:
There can be a problem where the detach is hit before
internal_gl_extensions is allocated and it tries to free NULL and
dies...
This just checks for the allocation before freeing -- very minor
- Nick
HeapFree(GetProcessHeap(), 0, NULL) is suppose
Am 01.01.2007 um 19:08 schrieb Christoph Bumiller:
I'm not 100% sure of this but I think IWineD3DVertexBufferImpl-
>dirtyend can't be more than ->resourse.size and if so this is a
bug (please correct me if I'm wrong); and so if SizeToLock is zero
dirtyend should be set to resource.size in b
Hi, I've been trying to get a program that uses rpc to work on wine and I've
been having some problems (my understanding is that isn't surprising). The
goal is to be able to run a rpc server that sits and waits for connections
over tcp/ip (It's for doing distributed computing). My first problem
After looking at the behavior on xp and wine for EnumDisplaySettingsA and
EnumDisplaySettingsW before and after a window has been created (I wrote a
little program to dump the devmodes), I noticed that the devmode structs
that wine gives back are lacking some fields.
Attached is a patch that f
Andreas wrote:
[ppviewer 2003]
failed to install with some nice MSI failures when I tried it last week on a
current
Wine version (Ubuntu package 0.9.28, I think).
Does that mean that I'm entitled to assemble a capable lynch mob for the guys
who were supposed to fix any and all MSI installer iss
On Monday 01 January 2007 00:47, Vitaliy Margolen wrote:
> Please don't send compressed patches. It's not that huge to gzip it.
Sorry.
> > +WineGLFBConfigsListSize = 1;
> > +WineGLDisplayablePixelFormatListSize = 1;
>
> If you hard-coding the list size to 1 it's not a list anymore
Paul Vriens <[EMAIL PROTECTED]> writes:
> On Mon, 2007-01-01 at 16:25 +0100, Wagner Ferenc wrote:
>
>> Paul Vriens <[EMAIL PROTECTED]> writes:
>>
>>> The winetest gui shows that the working directory is (in this case)
>>> c:\temp\wct12. This value is however not passed to the tests when
>>> Creat
On Mon, 2007-01-01 at 16:25 +0100, Wagner Ferenc wrote:
> Paul Vriens <[EMAIL PROTECTED]> writes:
>
> > The winetest gui shows that the working directory is (in this case)
> > c:\temp\wct12. This value is however not passed to the tests when
> > CreateProcess is run:
> >
> > main.c:
> >
> > 291
Paul Vriens <[EMAIL PROTECTED]> writes:
> The winetest gui shows that the working directory is (in this case)
> c:\temp\wct12. This value is however not passed to the tests when
> CreateProcess is run:
>
> main.c:
>
> 291 if (!CreateProcessA (NULL, cmd, NULL, NULL, TRUE, 0,
> 292
There is a registry workaround I have used in the past for installers
that complain about BITS service but I can't remember what it is or find
it using searches.
Does anyone remember the workaround?
$ for y in {2002..2006}; do \
n=$( git log | grep ^Date: | grep $y | wc -l ); \
echo "Number of patches in $y: $n"; \
done
Number of patches in 2002: 3094
Number of patches in 2003: 3283
Number of patches in 2004: 3851
Number of patches in 2005: 6006
Number of patches in 2006: 8404
-Hans
On Mon, 2007-01-01 at 15:10 +0100, Eric Pouech wrote:
> Paul Vriens a écrit :
> > Hi,
> >
> > I've been trying to tackle some of the issues we have when trying to run
> > some process tests (through winetest.exe, see also
> > http://test.winehq.org/data):
> >
> everything is already computed...
Paul Vriens a écrit :
Hi,
I've been trying to tackle some of the issues we have when trying to run
some process tests (through winetest.exe, see also
http://test.winehq.org/data):
everything is already computed... the global variable base is what you
seem to be looking for
A+
Andrew Neil Ramage a écrit :
Is there any way to interface between the hardware and windows .SYS
and .VXD device drivers ? If it is possible, I would be interested in
writing the interface.
What are you looking for ?
1/ Reusing system drivers from Windows ?
2/ or providing (rewriting) those
Reinhard Karcher a écrit :
Hello wine developers,
the attached patch fixes some issues I had with the 16 bit configuration
program for our SOHO PBX.
Hi Reinhard,
thanks the work on the attached patch
items #1 and #4 look ok to me
I'm not sure about #2. Does it make a real difference for you
Hi all,
http://www.microsoft.com/downloads/details.aspx?familyid=428D5727-43AB-4F24-90B7-A94784AF71A4&displaylang=en
failed to install with some nice MSI failures when I tried it last week on a
current
Wine version (Ubuntu package 0.9.28, I think).
Does that mean that I'm entitled to assemble a
"Nick Burns" <[EMAIL PROTECTED]> writes:
> Ok that is understandable -- but if wine takes up the entire 4gb
> address space -- where are builtin libs supposed to live ((be
> mapped)/alloc to)?
There is free space between 0x6000 and 0x8000.
> Why not let builtin libs (like opengl) use tha
Ok that is understandable -- but if wine takes up the entire 4gb address
space -- where are builtin libs supposed to live ((be mapped)/alloc to)?
(im assuming that opengl is a builtin lib -- in this context)
In my case If I let wine take up my entire address space -- libraries (like
opengl) wi
Original-Nachricht
> > TRACE(" make current for dis %p, drawable %p, ctx %p\n",
> gdi_display, (void*) drawable, ctx->ctx);
> > +X11DRV_expect_error(gdi_display, error_catcher, NULL);
> > ret = pglXMakeCurrent(gdi_display, drawable, ctx->ctx);
> > +
"Nick Burns" <[EMAIL PROTECTED]> writes:
> The range 3GB (0xC000) - 4GB (0x) is considered system
> memory and apps should not write here (not sure why you would want to
> read from there either).
>
> But Wine tries to mmap this range (on Mac OSX at least)
>
> I was wondering why this
According to
http://msdn2.microsoft.com/en-gb/library/aa366912.aspx
The range 3GB (0xC000) - 4GB (0x) is considered system memory
and apps should not write here (not sure why you would want to read from
there either).
But Wine tries to mmap this range (on Mac OSX at least)
I w
Chris Robinson wrote:
> This greatly simplifies some of the wgl code by keeping around a single
> customized fbconfig array, instead of holding a static, custom-typedef array
> which left many functions to query glx for the fbconfig list anyway (which in
> turn caused many needless, potentially
35 matches
Mail list logo
