> You already have this case:
>
> } else if(GL_SUPPORT(NV_REGISTER_COMBINERS) &&
> GL_SUPPORT(NV_TEXTURE_SHADER2)) {
> return &nvts_fragment_pipeline;
Well, that is selecting the fragment pipeline implementation, which does
more than just picking a single state. It's mainly for the fra
"Piotr Caban" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
+/*** LibXML callbacks ***/
+static void libxmlStartDocument(void *ctx)
+{
+ saxlocator *This = ctx;
+ HRESULT hr;
+
+ if(This->saxreader->contentHandler)
+ {
+ hr = ISAXContentHandler_startDocument(This->saxreader->conten
> -lopengl32 -lglu32 -o OpenGLBase.exe OpenGLBase.cpp
> /tmp/cclajgrA.o:OpenGLBase.cpp:(.text+0x10e): undefined reference to
> [EMAIL PROTECTED]'
I think this is in gdi32.dll
On Wednesday 16 July 2008 03:38:37 pm Markus Hitter wrote:
> maybe I'm just missing the obvious, but I can't get my small one-file
> app to link. As I've just built Wine from scratch on this box,
> everything should be installed, including libGL... in /usr/lib32:
Try linking with MinGW's libs, not
Hello all,
maybe I'm just missing the obvious, but I can't get my small one-file
app to link. As I've just built Wine from scratch on this box,
everything should be installed, including libGL... in /usr/lib32:
[EMAIL PROTECTED]:~/Wine Apps/GPWiki Framework$ make
i586-mingw32msvc-g++ -pipe -mw
After upgrade to Wine 1.1.0 from 0.9.56 I found out that my WinEdt can't launch
Unix binaries (xdvi, xterm etc) anymore. A dialog box saying "Cannot execute
command ..." appears, but binaries are started anyway. AFAICS it is caused by
patch by Dmitry Timoshkov that introduces "winoldap.mod". Now
On Wed, Jul 16, 2008 at 3:02 PM, Mikołaj Zalewski <[EMAIL PROTECTED]> wrote:
> I haven't noticed such a thing on Windows and it seems strange to run the
> WM_PAINT handler before WM_CREATE finishes - it may e.g. break some apps
> that subclass this control.
>
There's only one way to find out for s
Jon Griffiths <[EMAIL PROTECTED]> writes:
> In the socket tests, avoid a race by waiting for the read threads to
> finish before closing the sockets (found during TransmitFile testing).
CloseHandle doesn't wait for the thread to finish, so this has no
effect. In any case there doesn't seem to be
On Mon, Jul 7, 2008 at 5:39 PM, Maarten Lankhorst <[EMAIL PROTECTED]>
wrote:
> Hi students,
>
> As you might know it's time for midterm evaluations. Unfortunately for
> some students I haven't seen the progress they made, and I highly
> encourage all students to send their patches early and often,
Dan Kegel wrote:
> On Sun, Jun 1, 2008 at 1:16 AM, Dan Kegel <[EMAIL PROTECTED]> wrote:
http://kegel.com/new-computer-2008.html ).
Result: ... it takes me a bit longer today on this machine (11 minutes)
to build as it did then on a dual cpu hot rod (8 minutes).
I guess Moor
Am Mittwoch, den 16.07.2008, 16:10 +0200 schrieb Tomas Carnecky:
> > This looks like fixing an under-allocation, not over-allocation. The
> > patched code allocates at least 5 bytes more, and never less than 312.
> Never _more_ than 312, because MIN(300, x) <= 300.
Oops, got me. I like to read: mi
On Sun, Jun 1, 2008 at 1:16 AM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>>> http://kegel.com/new-computer-2008.html ).
>>>
>>> Result: ... it takes me a bit longer today on this machine (11 minutes)
>>> to build as it did then on a dual cpu hot rod (8 minutes).
>>> I guess Moore's Law isn't quite keep
Michael Karcher wrote:
> Am Dienstag, den 15.07.2008, 15:55 -0700 schrieb Dan Hipschman:
>> if (n < 0) n = 0;
>> size = 12 + min( 300, n * 5 );
>> -dst = res = funcs.get_temp_buffer( n * 5 + 7 );
>> +dst = res = funcs.get_temp_buffer( size );
> This looks like fixing an under-allo
Thanks for the feedback. I haven't gotten to that level of analysis
yet, because I was more focused on a nice working solution up front, but
will start digging deeper. Really however, the call to Sleep() is just
an added bonus. The fix works fine without it, you just get some frame
rate drop
2008/7/16 Daniel Santos <[EMAIL PROTECTED]>:
> +if(_lotro_hack_enabled
> +&& to->sa_family == AF_INET
> +&& dwBufferCount == 1
> +&& _lotro_hack(&get_per_thread_data()->lotro_msgs,
> +s, lpBuffers, (struct WS_sockaddr_in*)to)) {
> +
Hi,
Wine main page is not updated - there are no link to WWN 349. Partial patch?
--
Kirill
2008/7/16 Ivan Gyurdiev <[EMAIL PROTECTED]>:
> I don't know about that - a pointer called "is__supported"
> seems just as readable to me.
>
There's certainly the option to use that instead in the future, but
for the moment I think the single extension check should work well
enough for the majority
2008/7/15 Reece Dunn <[EMAIL PROTECTED]>:
> This adds basic support for drawing themed push buttons.
Please ignore this patch, as it breaks the drawing of some dialogs
(e.g. Cepstral SwiftTalker options).
- Reece
Stefan Dösinger wrote:
> A function pointer is a nice idea actually. I don't think we'll ever need
> more than one extension per state line though,
You already have this case:
} else if(GL_SUPPORT(NV_REGISTER_COMBINERS) &&
GL_SUPPORT(NV_TEXTURE_SHADER2)) {
return &nvts_fragment_pipel
The last patch was diff'ed against an old version of dlls/d3dx9_36/Makefile.in.
Applies fine now.
Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl.
http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/index.html
>From 66f62937ccb3a562e0c6cc489a50
Am Dienstag, den 15.07.2008, 15:55 -0700 schrieb Dan Hipschman:
> if (n < 0) n = 0;
> size = 12 + min( 300, n * 5 );
> -dst = res = funcs.get_temp_buffer( n * 5 + 7 );
> +dst = res = funcs.get_temp_buffer( size );
This looks like fixing an under-allocation, not over-allocation. Th
21 matches
Mail list logo
