==6476== Valgrind detected that your program requires
==6476== the following unimplemented functionality:
==6476==modify_ldt(): I (JRS) haven't investigated this yet; sorry.
==6476== This may be because the functionality is hard to implement,
==6476== or because no reasonable program
So, the question is What is the difference between the WineX OpenGL
library and the Wine OpenGL library?
Well, for me, the only possible difference would be that :
' This begs the question:
Does the Linux implementation of pthread really work anyway?
Works in WineX (though we needed some
In some of the int21 routines it says that we should use
DOSDEV_Peek/Read/Write. Should we also use the functions in the devices.c to
implement all functions on devices like ioctls etc.?
nog.
I'm so happy, I just had to share it with everyone :-D
Changelog:
Fix for MIDI Mapper.
Notes:
Finally found it! This was the last thing keeping sound from working
in Auralia. With just this simple patch, it now works. Auralia still
has a few problems, but they are minor in comparison. It
Lionel Ulmer wrote:
Hi all,
This patch should not be dependant of any others... But to prevent line
number errors, better to commit it after the 5 - 9 series (yeah, the
attachements are numbered to ease tracking :-) ).
Changelog:
- start of support for device locking / unlocking via
This patch breaks the TWIST demo that was working fine.
I think the changes in d3ddevice_create are responsible of that.
Strange, it works fine here.. A bit slow when statistics are displayed (due
to the locking of the D3DEVICE surface and thus needing a slow GL call like
glReadPixels /
On November 29, 2002 06:10 pm, Rolf Kalbermatter wrote:
But what the heck do the errors about AW functions calling Unicode
mean? Isn't that the actual idea about the AW functions?
Good catch. I've updated the list, there were 52 AW functions,
which leaves us 142 cross calls to deal with... :)
I realy need help with this. Whenever I call a DOSDEV_ function then that
function eventually calls DOSDEV_DoReq. This function calls DPMI_CallRMProc.
Now that function call DOSMEM_GetBlock( 64, (UINT16 *)(context-SegSs) ) to
try and allocate a stack. This fails for some reason but I dont
Lionel Ulmer wrote:
This patch breaks the TWIST demo that was working fine.
I think the changes in d3ddevice_create are responsible of that.
Strange, it works fine here.. A bit slow when statistics are displayed (due
to the locking of the D3DEVICE surface and thus needing a slow GL call like
On November 29, 2002 03:06 pm, Francois Gouget wrote:
Here's a proposed addition to the Janitorial projects:
Added:
http://www.dssd.ca/wine/Wine-Fun.html#tests
Let me know if you want anything changed.
--
Dimi.
that I have tried and needed yes, only valves with acute accent like you
call it, excuse my english.. :)
And I dont understand what you mean by dead key... but anyway... in every
linux app I can type that right, only the new wine version breaks that, but
I know it was fixed on 20021031 cause
Francois Gouget [EMAIL PROTECTED] writes:
I don't like pieces of code that go:
strcpy(foo, bar1);
strcat(foo, bar2);
strcat(foo, bar3);
strcat(foo, bar4);
strcat(foo, bar5);
strcat(foo, bar6);
It's really inefficient: the cost increases quadratically with the size
of the
Sorry if this hits the list twice im not sure if i typed wine-devel into the
to line or not ;)
That is a good question, either that or i will need borrow a copy of msvc
from a friend..
-Dustin
- Original Message -
From: Tony Lambregts [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Wine
I have reopened bug #15 due to the fact that the bug still exists to a
certain extent and in a different form. When sending an IM in AIM with any
recent version of wine (including a couple of days before the latest cvs
snapshot), I can resize the window and when the buttons go to reposition
On Sat, Nov 30, 2002 at 10:49:34AM -0800, Alexandre Julliard wrote:
It's more efficient to do:
sprintf(foo, %s%s%s%s%s%s, bar1,bar2,bar3,bar4,bar5,bar6);
In case you cannot be 100% sure of the lengths, it might still be worth it
with snprintf, but otherwise, it's a matter of taste.
It's really inefficient: the cost increases quadratically with the size
of the resulting string.
Well, no, the cost is linear. It would only be quadratic if the number
of strcat calls depended on the length of the string.
It's more efficient to do:
sprintf(foo, %s%s%s%s%s%s,
Hello,
I just want to say Thank you to all the people who put work into
the Compilation with -DSTRICT
Tom
17 matches
Mail list logo
