Chris Morgan wrote:
> On Sun, Apr 6, 2008 at 5:05 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>> On Sun, Apr 6, 2008 at 1:49 PM, Chris Morgan <[EMAIL PROTECTED]> wrote:
>> > > It seems reasonable to me to include the version bundled with gutsy,
>> > > even if it's getting old, because gutsy is s
" The following errors were found* Please enter what did not work."
I understand the mechanics of why it says that, but realistically, should it
for this field, be required to have data? For example, with me running WoW,
it's flawless for me. Absolutely no problems, and I'm rating it platinum. If
w
Am Dienstag, 8. April 2008 01:37:36 schrieb Milan Kostić:
> I wish to ask what is that GL_INVALID_VALUE (0x501) and
> GL_INVALID_OPERATION (0x502)??? This 0x501 i can see in many games.
GL_INVALID_OPERATION and _VALUE opengl errors. That they show up doesn't give
more information beyond "meh, thi
Am Dienstag, 8. April 2008 00:35:14 schrieb Alexander Dorofeyev:
> On the other hand, it is pretty tricky. Also Stefan believes adding
> isInDraw checks everywhere isn't especially nice, but ultimately to prevent
> all situations of ActivateContext inside ENTER_GL/LEAVE_GL with isInDraw
> approach
Maarten Lankhorst wrote:
>
> It probably asks for the specific keys in
> \ENUM\category\devicename\idname so if you copy these over it will
> probably work. WINEDEBUG=+setupapi is your friend.
>
> Cheers,
> Maarten.
>
>
>
Thanks for the suggestion. I tried that, and now that some page fault
On Mon, Apr 7, 2008 at 5:26 PM, Tom Wickline <[EMAIL PROTECTED]> wrote:
> http://web.mit.edu/kerberos/dist/index.html
That's a fine tip, thanks. (The .net installer doesn't count,
it's not free.)
- Dan
>
> Looks as if both of them come with Microsoft .NET Framework 1.0
>
> http://support.microsoft.com/dllhelp/?fid=96502&l=55&det=1
>
> http://support.microsoft.com/dllhelp/
>
> Tom
>
Info:
http://web.mit.edu/Kerberos/kfw-2.6/kfw-2.6.5/relnotes.html#requirements
Links:
http://web.mit.edu/kerbe
On Sun, Apr 6, 2008 at 2:43 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
> (This may sound like a repeat question, but last time I
> was asking about msvcr71, and thanks to the answers,
> that's now in winetricks.)
>
> Anybody have a good download link for an app that
> comes bundled with msvcr70 a
Ok i'm tested wine and his new GL_ATI_fragment_shader support with
9250 card nad Mesa/DRI driver. Now env bumpmaping and dot3 tests in
3DMark2001 seems to work good, but in car test high ground texture is
black. In DungeonSiege2 i disabled ps in winecfg, because it has same
problem (and more) flic
There's a little problem with consistency about these things. In various
related
routines and paths, there were (and still are) both places that check isInDraw
and places that don't check it. read_from_framebuffer and
IWineD3DSurfaceImpl_BindTexture that can be called from LoadLocation are
exa
On Mon, Apr 7, 2008 at 4:41 PM, Chris Morgan <[EMAIL PROTECTED]> wrote:
> Hey John.
>
> Looks like you've gotten the nice urls working, great job man. It will
> be great to have this before 1.0 is shipped since it will make our
> urls a lot nicer looking.
>
> I had a few comments about the code
On Apr 7, 2008, at 6:50 AM, Alexandre Julliard wrote:
> Module: wine
> Branch: master
> Commit: 3bfa90eedafc9bd2faf9bc421caa172547e8ddd6
> URL:http://source.winehq.org/git/wine.git/?
> a=commit;h=3bfa90eedafc9bd2faf9bc421caa172547e8ddd6
>
> Author: Alexandre Julliard <[EMAIL PROTECTED]>
> Date
On Mon, Apr 7, 2008 at 2:30 AM, Alexander Dorofeyev <[EMAIL PROTECTED]> wrote:
> Oh, you are right. Must be fixed some other way then, I guess, maybe moving
> assignment to isInDraw lower or moving ActivateContext higher. From what I
> understood from Bioshock bug (http://bugs.winehq.org/show_bug.c
Hey John.
Looks like you've gotten the nice urls working, great job man. It will
be great to have this before 1.0 is shipped since it will make our
urls a lot nicer looking.
I had a few comments about the code changes. You don't follow the
variable naming convention of the appdb. We have some pre
apologies - there was a typo in that patch - should be looking for "://"
rather than "::/" . Otherwise my questions are the same.
--- On Mon, 7/4/08, Hin-Tak Leung <[EMAIL PROTECTED]> wrote:
> From: Hin-Tak Leung <[EMAIL PROTECTED]>
> Subject: a proposed fix for bug 11690 concerning hhctrl.ocx
>
Give nice urls a whirl at:
http://appdb.klehm.net/app/"yoursearchtermhere";
Search Examples:
http://appdb.klehm.net/app/adobe
http://appdb.klehm.net/app/visual
Direct Link Examples:
http://appdb.klehm.net/app/photoshop
http://appdb.klehm.net/app/command-conquer-red-alert-2
See the nice urls bein
Updated with the hints from Dmitry:
On Mo, 2008-04-07 at 13:08 +0900, Dmitry Timoshkov wrote:
> Why not have a local variable of type LARGE_INTEGER and return
> li.QuadPart ?
Thanks.
Changelog:
ntoskrnl.exe: Implement KeQueryInterruptTime
--
By by ... Detlef
>From 27c33c2db0bcf5260555b5
apologies - there was a typo in that patch - should be looking for "://"
rather than "::/" . Otherwise my questions are the same.
--- On Mon, 7/4/08, Hin-Tak Leung <[EMAIL PROTECTED]> wrote:
> From: Hin-Tak Leung <[EMAIL PROTECTED]>
> Subject: a proposed fix for bug 11690 concerning hhctrl.ocx
>
Hi Jacek and James - according to git, you two are the ones last working on the
part
of code which I have a possible fix for bug 11690 (see the bug report for
somebody
tested okay something like this), so I'd like to see what you think of this
patch, specially (and others can chip in as well..
I agree that the good implementation is with array.
The bad thing is that we must bound the size of the array ourself. I think
that a size of 64 or 128 for the array is enough, right?
The advantage of a list is that we do not need to take care about the size.
David
> Well no, you keep track of the array size and grow it when it's too
> small when doing a push.
i.e. HeapReAlloc
http://msdn2.microsoft.com/en-us/library/aa366704(VS.85).aspx
You may optimize that if you allocate space for 2 or so matrices at once,
as it decreases the number of HeapReAlloc calls
On 07/04/2008, David Adam <[EMAIL PROTECTED]> wrote:
> I agree that the good implementation is with array.
>
> The bad thing is that we must bound the size of the array ourself. I think
> that a size of 64 or 128 for the array is enough, right?
>
Well no, you keep track of the array size and grow i
> The commit comment for this patch is rather non-descriptive... what is
> this supposed to fix?
> An array based stack seems more appropriate than a list based one for
> ID3DXMATRIXStack, why change that?
I think so, too (after taking a closer look at the interface documentation at
msdn).
Though
On 07/04/2008, David Adam <[EMAIL PROTECTED]> wrote:
>
The commit comment for this patch is rather non-descriptive... what is
this supposed to fix?
An array based stack seems more appropriate than a list based one for
ID3DXMATRIXStack, why change that?
Hi!
On Saturday 05 April 2008, Hin-Tak Leung wrote:
> 2) (to uli and Till) - do you mind if I put a mod/update of ddiwrapper
> out publicly, or uli can release a new one that works with current
> wine?
Hand it over, and I'll put it on the FTP server and update our package.
CU
Uli
--
SUSE LINU
I ran one of our X issues by Bryce Harrington. Here's his reply:
-- Forwarded message --
From: Bryce Harrington <[EMAIL PROTECTED]>
Date: Sun, Apr 6, 2008 at 9:46 PM
Subject: Re: [ubuntu-x] Future of digitizing tablet support in xorg?
To: Dan Kegel <[EMAIL PROTECTED]>
Cc: [EMAIL
On Mon, Apr 7, 2008 at 2:30 AM, Francois Gouget <[EMAIL PROTECTED]> wrote:
> If the cutoff is '0.9.48' (for instance), then maybe we could add a
> 'pre-0.9.48' version.
Sounds too confusing to me, offhand. I'd rather stick with the current
situation of having a too-early cutoff.
> That way us
Am Montag, 7. April 2008 11:34:33 schrieb H. Verbeet:
> On 07/04/2008, Chris Robinson <[EMAIL PROTECTED]> wrote:
> > +if(!This->stateBlock->vertexDecl) {
> > +WARN("(%p) : Called without a valid vertex buffer set\n", This);
>
> That WARN is misleading.
This problem also affects the othe
On 07/04/2008, Chris Robinson <[EMAIL PROTECTED]> wrote:
> +if(!This->stateBlock->vertexDecl) {
> +WARN("(%p) : Called without a valid vertex buffer set\n", This);
That WARN is misleading.
On Sun, 6 Apr 2008, Chris Morgan wrote:
[...]
> I'm all for adapting our behavior to better fit with the behavior of
> our users. I've spent hundreds of hours working on improving the
> appdb.
>
> If there was a good reason stated to accept results for obsoleted
> versions then I'd agree with you.
On Fri, 28 Mar 2008, Steven Edwards wrote:
> On Fri, Mar 28, 2008 at 3:01 PM, James Hawkins <[EMAIL PROTECTED]> wrote:
> > What is the process for making this switch? Do we need to contact
> > Paul Millar? The lack of a new winetest is putting a hamper on our
> > efforts to fix up the tests i
Am Montag, 7. April 2008 08:30:20 schrieb Alexander Dorofeyev:
> Oh, you are right. Must be fixed some other way then, I guess, maybe moving
> assignment to isInDraw lower or moving ActivateContext higher. From what I
> understood from Bioshock bug (http://bugs.winehq.org/show_bug.cgi?id=9973),
> m
On Tue, 1 Apr 2008, Steven Edwards wrote:
> On Mon, Mar 31, 2008 at 11:40 PM, TheBlunderbuss
> <[EMAIL PROTECTED]> wrote:
> > I like it, since I already do something like this!
> > How about a more surreptitious way of marking versions? Maybe a reg key
> > or other file.
> > This way, users mi
On Sun, 30 Mar 2008, Stefan Dösinger wrote:
> Am Sonntag, 30. März 2008 20:46:08 schrieb Austin English:
> > My comment from the bug:
> > "How about a little file in .wine or a registry key that is read upon
> > running wine, and should match the current wine version. If it doesn't,
> > call wine
On Monday 07 April 2008 04:14:59 Austin English wrote:
> Has anyone considering talking to Canonical about getting a more
> recent wine version included in wine? While they understandably don't
> want to introduce too new of versions, they also need to take into
> account that we release every two
35 matches
Mail list logo
