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
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 is?
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);
+
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)
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 that 3gb -
Hi all,
http://www.microsoft.com/downloads/details.aspx?familyid=428D5727-43AB-4F24-90B7-A94784AF71A4displaylang=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
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
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
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+
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... the global
$ 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
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?
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
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 if
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
CreateProcess is run:
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, but
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
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
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
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
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
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...
-
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
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.
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
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 seems to
+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,
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, but
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 a
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
30 matches
Mail list logo