Hi,
the latest run (with report) on the Coverity site seems to be from July
21st. It appears that the main page is updated though (not for the lines
of code but for the errors fixed).
Does anybody know more about the why? I've tried to contact Coverity for
the last month and my last email (where
I've been experiencing an error in several installers and it just appeared
lately in installers that used to succeed, such as the battlefield 2 demo
installer, this error is causing them to fail. Was this caused by a recent
patch?
err:storage:Storage32Impl_SmallBlocksToBigBlocks conversion fai
On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Am Montag 11 September 2006 19:56 schrieb H. Verbeet:
> On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > That's what I'd use the state.changed field for. Set it to TRUE when the
> > state is first modified and to FALSE when it it
On Monday 11 September 2006 12:12, Frank Richter wrote:
> On 11.09.2006 15:24, Kuba Ober wrote:
> >> Correct me if I'm wrong, I could be looking at the wrong files :S.
> >
> > Are you looking at assembly files? Those have .S extension. Methinks you
> > should focus on the C sources first, which hav
Saulius Krasuckas wrote:
* On Sun, 10 Sep 2006, Aaron Slunt wrote:
I was interested in starting to play with wine and maybe even build a
few functions for it...but then I realized that it's low-level coding,
something I'm not familiar with (higher level is more of my expertise).
Correct me
Am Montag 11 September 2006 19:56 schrieb H. Verbeet:
> On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > That's what I'd use the state.changed field for. Set it to TRUE when the
> > state is first modified and to FALSE when it it applied to gl. Do not add
> > the state to the list of cha
On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
That's what I'd use the state.changed field for. Set it to TRUE when the state
is first modified and to FALSE when it it applied to gl. Do not add the state
to the list of changes whn state.changed == TRUE
Well, sure, that's what the consta
Am Montag 11 September 2006 18:41 schrieb H. Verbeet:
> On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > * Keep a list of dirty states for each gl context in use: We don't need
> > something as fancy as trees for that, a little array can do the job, like
> > this(example for render state
On 11/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
* Keep a list of dirty states for each gl context in use: We don't need
something as fancy as trees for that, a little array can do the job, like
this(example for render states, but can be used for all other stuff too):
You would at least n
Alexandre Julliard <[EMAIL PROTECTED]> writes:
> Francois Gouget <[EMAIL PROTECTED]> writes:
>> > @@ -1707,6 +1732,7 @@ typedef struct tagTOOLINFOA {
>> > LPSTR lpszText;
>> > LPARAM lParam;
>> > void *lpReserved;
>> > +HBITMAP hbmp;
>> > } TTTOOLINFOA, *LPTOOLINFOA, *PTOOLINFOA
On 11.09.2006 15:24, Kuba Ober wrote:
>> Correct me if I'm wrong, I could be looking at the wrong files :S.
>
> Are you looking at assembly files? Those have .S extension. Methinks you
> should focus on the C sources first, which have .c extension.
":S" might've been an emoticon here.
-f.r.
Hi,
> Ok, so the main idea is to separate the applying of GL state from the
> tracking of D3D state. Looks like a good idea.
Fully agreed
> What I would like to
> add to that is something BBrox mentioned on IRC a while back...
> grouping related states together and marking that group dirty / clea
On Mon, 2006-09-11 at 10:43 +0200, Alexandre Julliard wrote:
> Joel Parker <[EMAIL PROTECTED]> writes:
>
> > This patch fixes bug #4510. It allows the use of -ansi when
> > running ./configure.
>
> I'm not sure I see the point, you'd need to fix all the places that
> use the file too, otherwise i
Hi Folks,
So this weekend is Wineconf, which is the mostly annual
gathering of Wine developers and afficianodos. Everyone is welcome,
although we do intend to run a very technical and developer focused
agenda.
It will be held in Reading, a bit west of London, in the UK.
The formal program starts
Vitaliy Margolen <[EMAIL PROTECTED]> writes:
> +static void release_hook_thread(void)
> +{
> +LONG ref;
> +
> +EnterCriticalSection(&dinput_hook_crit);
> +ref = --hook_thread_refcount;
> +TRACE("Releasing to %ld\n", ref);
> +if (ref == 0) SendMessageW(hook_thread_hwnd, WM_DESTR
> I was interested in starting to play with wine and maybe even build a few
> functions for it...but then I realized that it's low-level coding,
What do you mean by low-level?
> Correct me if I'm wrong, I could be looking at the wrong files :S.
Are you looking at assembly files? Those have .S ex
Joel Parker <[EMAIL PROTECTED]> writes:
> Well, this was intended as an incremental step in that direction.
>
> As for defining _BSD_SOURCE, if I read the glibc documentation
> correctly, this is exactly what is intended:
>
> "If you compile your programs using gcc -ansi, you get only the ISO C
>
On Mon, 2006-09-11 at 13:36 +0300, Saulius Krasuckas wrote:
> Any chances this patch gets into the webserver? :)
> http://marc.theaimsgroup.com/?l=wine-patches&m=115673906004873&w=2
This usually happens at release time...
--
Dimi Paun <[EMAIL PROTECTED]>
Lattica, Inc.
"Roderick Colenbrander" <[EMAIL PROTECTED]> writes:
> The patch adds new WGL extension loading code based on code written
> by an old opengl32 -> x11drv patch written by Tomas Carnacky. The
> code properly advertises WGL extensions and only returns function
> pointers when the extension is really
* On Mon, 28 Aug 2006, Mike McCormack wrote:
> Update regression testing procedure to use Git
Any chances this patch gets into the webserver? :)
http://marc.theaimsgroup.com/?l=wine-patches&m=115673906004873&w=2
Francois Gouget <[EMAIL PROTECTED]> writes:
> @@ -1707,6 +1732,7 @@ typedef struct tagTOOLINFOA {
> LPSTR lpszText;
> LPARAM lParam;
> void *lpReserved;
> +HBITMAP hbmp;
> } TTTOOLINFOA, *LPTOOLINFOA, *PTOOLINFOA, *LPTTTOOLINFOA;
I don't think our code is going to handle this
Joel Parker <[EMAIL PROTECTED]> writes:
> This patch fixes bug #4510. It allows the use of -ansi when
> running ./configure.
I'm not sure I see the point, you'd need to fix all the places that
use the file too, otherwise it won't compile, and it's not clear that
defining BSD_SOURCE all over the p
--- Aaron Slunt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I was interested in starting to play with wine and
> maybe even build a few
> functions for it...but then I realized that it's
> low-level coding, something
> I'm not familiar with (higher level is more of my
> expertise). Correct me if
> I'm
* On Sun, 10 Sep 2006, Aaron Slunt wrote:
> I was interested in starting to play with wine and maybe even build a
> few functions for it...but then I realized that it's low-level coding,
> something I'm not familiar with (higher level is more of my expertise).
> Correct me if I'm wrong, I could
On 11/09/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
I guess that seems like a large undertaking, and those are all doomed to
failure.. but it doesn't have to be.
The key idea that I care about seems to be to move GL code from device.c
into the data structure object, and figure out a way to app
25 matches
Mail list logo