Owen Rudge wrote:
This layout is not officially published anywhere, however (nor is the
new one), so I presume it will be acceptable to modify it to fit the
vtable and reference count, etc, in?
Personally I don't see another way to do so.
It might conceivably cause problems for any pre-comctl32
--- On Wed, 12/8/09, Dan Kegel wrote:
> In http://www.winehq.org/pipermail/wine-devel/2009-August/077858.html
> Hin-Tak wrote
> >...
> >The last part (missing charset) seems to be some
> harmless thing winetrick does - instead of gtk it calls good
> old xlib message to pop up a message; I haven't
Hi
I am sorry I forgot to introduce myself.
I am a software engineer at AMD, working on OpenGL graphics driver, I am
working with wine issues now. Some uses complained that there are too
many issues to play games with wine with AMD graphics card, so we want
to improve the quality.
That's all, Th
Hi
You are using the hardcoded method to get the vidmem now (in function
IWineD3DImpl_FillGLCaps), first you call glGetString(GL_RENDERER) to get
the GPU renderer string, and then you use this string to set the vidmem
in your code. Unfortunately you don't get all of the ATI GPU's string
now, for o
This layout is not officially published anywhere, however (nor is the
new one), so I presume it will be acceptable to modify it to fit the
vtable and reference count, etc, in? It might conceivably cause problems
for any pre-comctl32-v6 app that tries to poke around the internals (not
that they
You can't do that. HIMAGELIST should be the same thing as IImageList.
Hmm. Looking at the HIMAGELIST/IImageList internals in a debugger on
Windows, the layout appears to be entirely different to the HIMAGELIST
layout defined in dlls/comctl32/imagelist.h (as you'd expect -the
vtable, etc, need
Well the main advantage I can see is that we are able to have mp3
support without adding a new library dependency. This will be
especially useful for platforms other than Linux where libmpg123 is not
present. Such as the Mac.
There is no technical or licensing reason we would have to link to
> If the code can be copied into wine itself, it seems to reason that we
> could statically link that same code ;-).
>
> http://www.mpg123.org/ - it's LGPL 2.1.
Oh yes, I assumed so. I was talking about statically linking vs.
dlopen in general, and why avoiding dlopen where practical is a good
th
Owen Rudge wrote:
---
dlls/comctl32/imagelist.c | 318
-
1 files changed, 317 insertions(+), 1 deletions(-)
Hi.
+/*
+ * IImageList implementation
+ */
+
+typedef struct {
+
On Wed, Aug 12, 2009 at 4:09 PM, Juan Lang wrote:
>> Right. Is there an particular reason we can't dlopen the native library?
>
> I don't think dlopen is preferable, quite the opposite in fact.
> dlopen leads to a situation in which Wine has features that work on
> the build system, but not at runt
> Right. Is there an particular reason we can't dlopen the native library?
I don't think dlopen is preferable, quite the opposite in fact.
dlopen leads to a situation in which Wine has features that work on
the build system, but not at runtime on another system that doesn't
have the library availa
On Wed, Aug 12, 2009 at 4:34 PM, Chris Robinson wrote:
> Personally, I'd think linking libmpg123 would be a better option, instead of
> duplicating it. It would allow Wine to be updated when the lib updates,
> instead of trying to keep up with changes, and avoid duplicating
> functionality.
Right.
On Wednesday 12 August 2009 1:10:15 pm Aric Stewart wrote:
> I have a few questions. Right now I have the smallest subset of files
> from libmpg123 that are needed to compile and work in the wine framework
> (mostly) unmodified. I have replaced all the malloc/free calls with
> HeapAlloc/HeapFr
Hi Aric,
> What I am wondering about is that there is still a lot of code in these
> files we have no interest in. The file reader and http reader and other
> things that we do not use (it is accessed just by the direct stream methods)
> and those things dependencies.
>
> Should I leave all this
Hello all,
I am working on updating our winemp3.acm implementation to a modern
libmpg123. We where at about 0.59r and I have 1.8.1 working very well.
I have a few questions. Right now I have the smallest subset of files
from libmpg123 that are needed to compile and work in the wine fram
2009/8/10 Stefan Dösinger :
> Hi,
> A few comments - mostly things I haven't spotted earlier.
Hi,
I fixed the code, almost completely following your reviews (thank you,
of course).
I'm reporting the differences with your suggestions:
>
>> --- /dev/null
>> +++ b/dlls/d3dx9_36/asmshader.h
>> --- /d
Yippee!!
A big step forward for usability.
I'll mark the bug fixed tonight.
> +/* get window bounds */
> +if(!GetClientRect(graphics->hwnd, &wnd_rect))
> +return GenericError;
What if the Graphics object doesn't have a window?
--
Vincent Povirk
Henri Verbeet wrote:
2009/8/12 Andrew Eikum :
+GpStatus stat = Ok;
The initialization is redundant, since you always initialize stat
before using it.
+if((stat = GdipCreateRegionRect(&wnd_rectf, &wnd_rgn) != Ok))
+return stat;
I don't think that does what you want it to do.
2009/8/12 Andrew Eikum :
> +GpStatus stat = Ok;
The initialization is redundant, since you always initialize stat
before using it.
> +if((stat = GdipCreateRegionRect(&wnd_rectf, &wnd_rgn) != Ok))
> +return stat;
I don't think that does what you want it to do.
Andrew Eikum wrote:
---
dlls/gdiplus/tests/graphics.c | 244
+
1 files changed, 244 insertions(+), 0 deletions(-)
I suggest to split this:
---
+ok(rectf.X == exp.X &&
+rectf.Y == exp.Y &&
+rectf.Width == exp.Width &&
+rectf
2009/8/12 xiaq :
> The patch has been reviewed by the original translator, Hongbo Ni. I
> have also included my name in the file.
>
You need to include your full name in patches sent to Wine.
Dmitry Timoshkov wrote:
"Aric Stewart" wrote:
It seems to be 'OK' for X11 to return that because everyone in the X11
universe seems to just accept that as how X works.
Could you please provide an example of this? How other projetcs cope with
that?
Having an appropriate X11 keyboard layout a
In http://www.winehq.org/pipermail/wine-devel/2009-August/077858.html
Hin-Tak wrote
>...
>The last part (missing charset) seems to be some harmless thing winetrick does
>- instead of gtk it calls good old xlib message to pop up a message; I haven't
>looked at why.
the code is
warn() {
echo "$
> These don't seem to match the PSDK headers or MSDN (which don't match
> each other either...) Which are the correct ones?
Oof. Your guess is as good as mine. I looked at MSDN and at MinGW's
headers for inspiration, but MSDN says multiple incompatible versions
of af_irda.h were released. I'll
I don't know, is it?
I can never remember how to use the GUID functions.
On Wed, Aug 12, 2009 at 3:36 AM, Henri Verbeet wrote:
> 2009/8/12 Vincent Povirk :
>> + if (memcmp(formats[i].guid, pPixelFormat, sizeof(GUID)) == 0)
> This works of course, but isn't IsEqualGUID() the preferred way t
Am Wednesday 12 August 2009 03:05:43 schrieb Stefan Dösinger:
> Am Tuesday 11 August 2009 23:43:33 schrieb Johan Gill:
> > There is IWineD3DDeviceImpl_SetupFullscreenWindow, but that one is not
> >
> > exported so it can't be called from ddraw as it is.
> >
> > Calling it from within IWineD3DDevice
"Aric Stewart" wrote:
It seems to be 'OK' for X11 to return that because everyone in the X11
universe seems to just accept that as how X works.
Could you please provide an example of this? How other projetcs cope with
that?
Having an appropriate X11 keyboard layout activated is exactly the s
It seems to be 'OK' for X11 to return that because everyone in the X11
universe seems to just accept that as how X works. Not fixing it wine
would mean require all wine users to use something like xmodmap to
modify their own xservers to get the correct behavior.
That doesn't seem like an accep
Juan Lang writes:
> +typedef struct _IAS_QUERY
> +{
> +UCHAR irdaDeviceID[4];
> +#ifdef USE_WS_PREFIX
> +char irdaClassName[WS_IAS_MAX_CLASSNAME];
> +char irdaAttribName[WS_IAS_MAX_ATTRIBNAME];
> +#else
> +char irdaClassName[IAS_MAX_CLASSNAME];
> +char irdaAttribName[
Alexandre Julliard wrote:
Nikolay Sivov writes:
diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c
index a65d832..9bca376 100644
--- a/dlls/comctl32/listview.c
+++ b/dlls/comctl32/listview.c
@@ -9740,6 +9740,8 @@ static LRESULT LISTVIEW_Paint(LISTVIEW_INFO *infoPtr, HDC
hdc)
Nikolay Sivov writes:
> diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c
> index a65d832..9bca376 100644
> --- a/dlls/comctl32/listview.c
> +++ b/dlls/comctl32/listview.c
> @@ -9740,6 +9740,8 @@ static LRESULT LISTVIEW_Paint(LISTVIEW_INFO *infoPtr,
> HDC hdc)
> {
> TRACE("(
Nikolay Sivov writes:
> Paul Vriens wrote:
>> Not sure for the reason. But one thing I don't like is that this
>> comctl32/msg.c (with no actual tests itself) is also shown on
>> test.winehq.org.
> Could we get rid of .c file here and move messaging test helpers to
> header only? It's the way win
Alistair Leslie-Hughes wrote:
Hi,
This is just to silence a noisy fixme.
Changelog:
msxml3: IXMLDOMElement doesnt support IObjectIdentity
It's an interface used by jscript engine, so it would be better to
silence it for all object that implements IDispatch. I'd suggest to move
it to d
Alistair Leslie-Hughes wrote:
Hi,
Changelog:
msxml3: Add IDispatchEx support to IXMLDOMElement
@@ -46,6 +47,9 @@ typedef struct _domelem
LONG ref;
IUnknown *node_unk;
IXMLDOMNode *node;
+
+/* IDispatchEx */
+DispatchEx dispex;
} domelem;
It would be probably be
Alistair Leslie-Hughes wrote:
Hi,
This fixes bug http://bugs.winehq.org/show_bug.cgi?id=18531
Changelog:
shdocvw: Implement OleInPlaceObject InPlaceDeactivate
It's not an implementation, but a bit better stub. Please leave the
FIXME message.
Jacek
Nikolay Sivov wrote:
Paul Vriens wrote:
Nikolay Sivov wrote:
Currently tests are dependent which makes it impossible to change
only one,
could be possible actually, but not always. Anyway separate tests are
better.
Changelog:
- Make test not depend from each other, replace some magics wi
Paul Vriens wrote:
Nikolay Sivov wrote:
Currently tests are dependent which makes it impossible to change
only one,
could be possible actually, but not always. Anyway separate tests are
better.
Changelog:
- Make test not depend from each other, replace some magics with
macros
Hi Niko
Nikolay Sivov wrote:
Currently tests are dependent which makes it impossible to change only one,
could be possible actually, but not always. Anyway separate tests are better.
Changelog:
- Make test not depend from each other, replace some magics with macros
Hi Nikolay,
Looks like this on
2009/8/12 Vincent Povirk :
> +if (memcmp(formats[i].guid, pPixelFormat, sizeof(GUID)) == 0)
This works of course, but isn't IsEqualGUID() the preferred way to do that?
40 matches
Mail list logo
