Hi Paul,
> yes, the patch fixes the problem.
>
> Wasn't this as your original patch intended? AJ must have changed this for
> a reason, if so.
It was a part of one of my revisions; I got rid of it in the final
version I sent just to make sure I wasn't taking any chances, as AJ has
been aversive to
> Does this patch work for you?
>
> http://www.winehq.org/pipermail/wine-patches/2006-August/030049.html
>
>
>
>
Hi James,
yes, the patch fixes the problem.
Wasn't this as your original patch intended? AJ must have changed this for
a reason, if so.
Cheers,
Paul.
The attached program demonstrates a bug in the default background-erase code
in send_erase (dlls/user/painting.c). The code includes a top level window
with WS_CLIPCHILDREN | WS_CLIPSIBLINGS, and two overlapping child windows -
one that draws nothing and has a white background (first child), and
well check this link out http://wiki.winehq.org/GitWine, in it Section 6
raise a bug in Bugzilla, http://bugzilla.winehq.org
and also discuss any usage issues in [EMAIL PROTECTED]
Thanks,
VJ
On 8/23/06, Doug Laidlaw <[EMAIL PROTECTED]> wrote:
I may be on the wrong list.
A program I use has sho
I may be on the wrong list.
A program I use has shown a backward step in graphics between Wine 0.9.15 and
0.9.16, and I am trying to find the change responsible. I currently have
Wine set as at 2006-06-21 16:21:20 CDT, it is identifying as 0.9.16, and the
fault is present. The Web site says t
On 8/23/06, Mike McCormack <[EMAIL PROTECTED]> wrote:
James Hawkins wrote:
> @@ -65,6 +65,7 @@ struct msi_control_tag
> float progress_current;
> float progress_max;
> WCHAR name[1];
> +DWORD attributes;
You shouldn't add members after name[1], as the string in name[] will
o
I've found an informative blog on these .dlls. This guy wrote a mini
installer for them, I don't know about the legality of it...
http://inky.50megs.com/blogs/2005/10/directx-updates-dll-hell-revisited.htm
these aren't included in the standard direct3d package. These .dlls
d3dx9_x.dll's come
James Hawkins wrote:
@@ -65,6 +65,7 @@ struct msi_control_tag
float progress_current;
float progress_max;
WCHAR name[1];
+DWORD attributes;
You shouldn't add members after name[1], as the string in name[] will
overwrite them.
+sz = 0x20;
+buf = msi_alloc( sz*siz
Jeremy Newman wrote:
> http://bugs.winehq.org/show_bug.cgi?id=5712
>
> We have a bug on this I see. Still no fix as of yet. Consider this a
> bump.
>
> On Wed, 2006-08-23 at 13:50 -0500, Jeremy Newman wrote:
>> Just going through my list of issues I'd like resolved, and discovered
>> this bug/reg
Not sure about the exact terms, but there are people distributing
them, eg
http://www.threelights.de/index.php?page=projects/d3dx9_xx_dll_files.php
I think they can't be distributed. Game developers ship some directx installer
which installs them. Distribution of these dlls is a bit tricky.
Perhaps if we really need them it might be an option to work together with
Transgaming. It are basicly utility libraries which don't touch any of the
r
Does this patch work for you?
http://www.winehq.org/pipermail/wine-patches/2006-August/030049.html
On 8/23/06, Jeremy Newman <[EMAIL PROTECTED]> wrote:
Unfortunately, FEAR Combat does not seem to include them.
What's the redistribution license on that part of the SDK? Could
those DLL's be included with binary packages of Wine and just turn
this into a packaging issue?
-Brian
On Wed, 2006-08-23 at 20:39 +0200, Paul Vriens wrote:
> Hi,
>
> normally when I start Process Explorer it automatically launches the
> 'explorer' process.
>
> With the latest git 'explorer' crashes. Regression testing showed that
> this is most likely due to the XEmbed patch:
>
> http://source.w
http://bugs.winehq.org/show_bug.cgi?id=5712
We have a bug on this I see. Still no fix as of yet. Consider this a
bump.
On Wed, 2006-08-23 at 13:50 -0500, Jeremy Newman wrote:
> Just going through my list of issues I'd like resolved, and discovered
> this bug/regression.
>
> In Max Payne 1 / Max
Unfortunately, FEAR Combat does not seem to include them.
On Wed, 2006-08-23 at 21:27 +0200, H. Verbeet wrote:
> On 23/08/06, Jeremy Newman <[EMAIL PROTECTED]> wrote:
> > Our goals are to never need native dlls. Why would we not implement
> > them, even as stub dlls?
> >
> Well, for one, they're n
On Wed, 2006-08-23 at 20:39 +0200, Paul Vriens wrote:
> Hi,
>
> normally when I start Process Explorer it automatically launches the
> 'explorer' process.
>
> With the latest git 'explorer' crashes. Regression testing showed that
> this is most likely due to the XEmbed patch:
>
> http://source.w
On 23/08/06, Jeremy Newman <[EMAIL PROTECTED]> wrote:
Our goals are to never need native dlls. Why would we not implement
them, even as stub dlls?
Well, for one, they're not really part of d3d as such. Applications
that use them should really come with them and install them. Also,
there are qui
Just going through my list of issues I'd like resolved, and discovered
this bug/regression.
In Max Payne 1 / Max Payne 2 it seems the game freezes up for a few
seconds when you hold down any key in the game. For example using 'W' to
move forward, hold it down you take like 1 step and it freezes up
Our goals are to never need native dlls. Why would we not implement
them, even as stub dlls?
On Wed, 2006-08-23 at 12:56 -0400, Vijay Kiran Kamuju wrote:
> I think d3dx9_*.*.dll are all shader related dlls for DirectX 9.
> They should be downloaded/copied from the DX installation.
> We may not be
Hi,
normally when I start Process Explorer it automatically launches the
'explorer' process.
With the latest git 'explorer' crashes. Regression testing showed that
this is most likely due to the XEmbed patch:
http://source.winehq.org/git/?p=wine.git;a=commit;h=60a97505a63e5102f239d0d4c2a2ea7fd77
On 23/08/06, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote:
I think d3dx9_*.*.dll are all shader related dlls for DirectX 9.
They contain mostly utility stuff, eg for loading textures from files,
matrix functions, loading models, creating geometry, etc. It also
includes both a shader assembler an
I think d3dx9_*.*.dll are all shader related dlls for DirectX 9.
They should be downloaded/copied from the DX installation.
We may not be implementing those dlls in future.
--
VJ
On 8/23/06, Tom Wickline <[EMAIL PROTECTED]> wrote:
On 8/23/06, Jeremy Newman <[EMAIL PROTECTED]> wrote:
> Tried FEA
On 23/08/06, Tom Wickline <[EMAIL PROTECTED]> wrote:
Native d3dx9_*.*.dll should work, I have to use d3dx9_28.dll to get
3DMark06 to run.
Yes, and generally the apps using them should install them. Otherwise
the DX SDK has cabs that contain those dlls in the Redist dir.
On 8/23/06, Jeremy Newman <[EMAIL PROTECTED]> wrote:
Tried FEAR Combat on Wine. Looks like it needs a d3dx9_27.dll which we
don't provide.
Anyone else have any luck with this one? I'm not sure what the status is
of all the required dx 9.0c dlls are.
Native d3dx9_*.*.dll should work, I have to
On 8/23/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
"James Hawkins" <[EMAIL PROTECTED]> writes:
> @@ -2087,33 +2087,44 @@ static void test_getproperty(void)
> ok( hPackage != 0, " Failed to create package\n");
>
> /* set the property */
> +SetLastError(0xdeadbeef);
> r =
"Renu Rajput" <[EMAIL PROTECTED]> writes:
> diff -urN OldDir/dlls/comdlg32/filedlg.c NewDir/dlls/comdlg32/filedlg.c
> --- OldDir/dlls/comdlg32/filedlg.c 2006-08-10 18:45:12.0 +0530
> +++ NewDir/dlls/comdlg32/filedlg.c 2006-08-11 16:09:32.0 +0530
> @@ -2011,7 +2011,10 @@
> IPersistF
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> On 8/23/06, Michael Stefaniuc <[EMAIL PROTECTED]> wrote:
>> > + /* start table off small to avoid hiding resize bugs */
>> > +msihandletable_size = 1;
>> Isn't this very small start value something to be used only for
>> debugging while one wri
Tried FEAR Combat on Wine. Looks like it needs a d3dx9_27.dll which we
don't provide.
Anyone else have any luck with this one? I'm not sure what the status is
of all the required dx 9.0c dlls are.
On 8/23/06, Michael Stefaniuc <[EMAIL PROTECTED]> wrote:
> + /* start table off small to avoid hiding resize bugs */
> +msihandletable_size = 1;
Isn't this very small start value something to be used only for
debugging while one writes the resizing code? For "production" I would
use a
Dan Kegel wrote:
> Changelog:
> msi: remove limit on number of handles
>
> handle.c | 30 +++---
> msipriv.h |1 -
> 2 files changed, 23 insertions(+), 8 deletions(-)
>
>
>
>
> diff --git a/dl
On 8/23/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
Dynamic allocation would be better, it's really not hard to do in this
case.
Oh, ok. Patch sent.
"Tom Wickline" <[EMAIL PROTECTED]> writes:
> Done..
>
> I also put a link in http://wiki.winehq.org/HackingTips under Tips & Tricks.
>
> Here's what I have : http://wiki.winehq.org/Developers-Hints
Thanks! I'll remove it from the source tree then.
--
Alexandre Julliard
[EMAIL PROTECTED]
Dmitry Timoshkov wrote:
As an additional optimization, probably it would be better to call
WineEngGetTextMetrics instead of GetTextMetricsW to avoid introducing
hdc as another parameter of WineEngGetGlyphIndices.
Sounds good and simpler, will give it a try.
Jeff
"Jeff L" <[EMAIL PROTECTED]> wrote:
if(dc->gdiFont)
- ret = WineEngGetGlyphIndices(dc->gdiFont, lpstr, count, pgi, flags);
+ ret = WineEngGetGlyphIndices(hdc, dc->gdiFont, lpstr, count, pgi, flags);
...
+GetTextMetricsW(hdc, &textm);
As an additional optimization, pro
> Hello
>
> > Both of you try to remove the following code from
> src/winex11.drv/opengl.c:
> > /* Aux buffers */
> > pglXGetFBConfigAttrib(gdi_display, cfgs[fmt_index],
> GLX_AUX_BUFFERS,
> > &value); if (ppfd->cAuxBuffers && !value) {
> > goto choose_exit;
> > }
>
> Is this co
On 8/22/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
"Tom Wickline" <[EMAIL PROTECTED]> writes:
> Changelog: add newly implemented dlls and update http links
I think the DEVELOPERS-HINTS contents should really be moved to the
Wiki, it would be a lot easier to keep up to date there. Does an
Mikołaj Zalewski <[EMAIL PROTECTED]> writes:
> --- framewnd_orig.c 2006-08-10 15:15:12.0 +0200
> +++ framewnd.c2006-08-22 22:10:05.0 +0200
Please generate diffs from the top-level directory.
--
Alexandre Julliard
[EMAIL PROTECTED]
Alexandre Julliard wrote:
Jeff L <[EMAIL PROTECTED]> writes:
+/* Note that the call to GetTextMetricsW is made in the loop *
+ * because it is less likely to have non existant glyphs *
+ * and hence we should have few calls to Ge
Jeff L <[EMAIL PROTECTED]> writes:
> for(i = 0; i < count; i++)
> +{
> pgi[i] = get_glyph_index(font, lpstr[i]);
> -
> +if (pgi[i] == 0)
> +{
> +if (flags & GGI_MARK_NONEXISTING_GLYPHS)
> +pgi[i] = 0x001f; /* Indicate
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> This lets http://bugs.winehq.org/show_bug.cgi?id=4227
> get to the next problem.(1024 handles wasn't enough, I checked.
> 2048 might not be enough for a truly huge app, but this should
> hold us for a while.)
Dynamic allocation would be better, it's r
"James Hawkins" <[EMAIL PROTECTED]> writes:
> @@ -2087,33 +2087,44 @@ static void test_getproperty(void)
> ok( hPackage != 0, " Failed to create package\n");
>
> /* set the property */
> +SetLastError(0xdeadbeef);
> r = MsiSetProperty(hPackage, "Name", "Value");
> ok( r =
42 matches
Mail list logo
