Hi,
I won't have a chance to follow up on this until Wednesday but maybe
someone can spot the problem before then. Doing a normal checkout and
configure on mingw works fine but the generated makefile in
wine/tools/ seems to have a problem with the dependency tracking.
Maybe the recent makedep chan
"Evan Stade" <[EMAIL PROTECTED]> wrote:
+GpStatus WINGDIPAPI GdipFillPie(GpGraphics *graphics, GpBrush *brush, REAL x,
+REAL y, REAL width, REAL height, REAL startAngle, REAL sweepAngle)
+{
+LOGBRUSH lb;
+HPEN hpen;
+HGDIOBJ old_pen, old_brush;
+REAL x_0, y_0, radStartAngle,
"Evan Stade" <[EMAIL PROTECTED]> wrote:
+GpStatus WINGDIPAPI GdipDrawLineI(GpGraphics *graphics, GpPen *pen, INT x1,
+INT y1, INT x2, INT y2)
+{
+HGDIOBJ old_obj;
+
+if(!pen || !graphics)
+return InvalidParameter;
+
+old_obj = SelectObject(graphics->hdc, pen->gdipen);
+
"Anatoly Lyutin" <[EMAIL PROTECTED]> wrote:
Subject.
Thanks for attention.
If it does matter, the patch looks good to me. It's probably
still in the Alexandre's queue.
--
Dmitry.
On 09/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Well yes, but inside stretch_rect_fbo() src_surface isn't guaranteed
> to be a render target (either onscreen or offscreen), so I'm not sure
> that calling ActivateContext on src_surface like that will always do
> what we want. In fact, ne
> Well yes, but inside stretch_rect_fbo() src_surface isn't guaranteed
> to be a render target (either onscreen or offscreen), so I'm not sure
> that calling ActivateContext on src_surface like that will always do
> what we want. In fact, neither src_surface nor dst_surface has to be a
> render tar
* On Fri, 8 Jun 2007, Alexandre Julliard wrote:
> * Saulius Krasuckas <[EMAIL PROTECTED]> writes:
> >
> > Ok, so what would you say about a benefit of renaming of
> > SetWindowLongPtr to SetWindowLongPtrA ?
>
> I wouldn't say anything at this point. It's up to you to explain what
> the benefits
Saulius Krasuckas <[EMAIL PROTECTED]> writes:
>> Things don't get decided by popularity, but by technical merit. If you
>> can make a good technical argument for a change it will go in; if you
>> can't, gathering votes for it won't help.
>
> Ok, so what would you say about a benefit of renaming
On 08/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
I added the preload because the old code also preloaded in case of fbo blits.
I didn't specifically look if the fbo code does that, though. If it does we
can remove it, but I'd prefer to do it in a seperate patch to keep the
changes seperate
> I would like to ask you about an interfaces of zip folder dynamic
> library - if they're known I would implement zip folders support.
> It was suggested to ask someone from wine development team to get more
> information about that.
> Please, take a look to the discussion in the wine group about
* On Fri, 8 Jun 2007, Alexandre Julliard wrote:
>
> Things don't get decided by popularity, but by technical merit. If you
> can make a good technical argument for a change it will go in; if you
> can't, gathering votes for it won't help.
Ok, so what would you say about a benefit of renaming of
Saulius Krasuckas <[EMAIL PROTECTED]> writes:
> I don't think so. "Accepted or rejected by the community" isn't numerical
> result of voting (which Dmitry wants to ensure me is present), while for
> example list from the page [1] is.
Things don't get decided by popularity, but by technical mer
Hi Alexander, as you say in the quoted thread,
> zip filder support is encapsulated within zipfldr.dll which is
> standard COM-component (i.e. exposes DllRegisterServer/
> DllCanUnloadNow).
> For example in WinXP zip folders support may be switched off by
> unregistering zipfldr.dll via regsvr32.
Good day,
First of all: big thank you for your great wine!
Several days ago I made a post on the wine groups:
Does anyone tried to use zip folders support on wine? Is is possible?
I tried to copy zipfldr.dll and register it, but it does not work.
Since I am a developer I would try to do it. Co
Subject.
Thanks for attention.
--
Best regards
Anatoly Lyutin.
On 6/8/07, Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
* On Fri, 8 Jun 2007, James Hawkins wrote:
> * On 6/8/07, Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
> > * On Fri, 8 Jun 2007, James Hawkins wrote:
> > > * On 6/8/07, Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
> > > > * On Sat, 9 Jun 200
* On Fri, 8 Jun 2007, James Hawkins wrote:
> * On 6/8/07, Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
> > * On Fri, 8 Jun 2007, James Hawkins wrote:
> > > * On 6/8/07, Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
> > > > * On Sat, 9 Jun 2007, Dmitry Timoshkov wrote:
> > > > > * "Saulius Krasuckas"
>>> Yep, you are right, it is actually "c:\wïñëtèst". I will fix it in
>>> the next try.
>>
>> That won't work. The actual unicode characters have different codes.
>> Personally
>> I don't see why you need non-acsii characters to test unicode APIs.
>>
In this case, the non-ascii characters are n
On 6/8/07, Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
* On Fri, 8 Jun 2007, James Hawkins wrote:
> * On 6/8/07, Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
> > * On Sat, 9 Jun 2007, Dmitry Timoshkov wrote:
> > > * "Saulius Krasuckas" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > The project needs
* On Fri, 8 Jun 2007, James Hawkins wrote:
> * On 6/8/07, Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
> > * On Sat, 9 Jun 2007, Dmitry Timoshkov wrote:
> > > * "Saulius Krasuckas" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > The project needs some voting mechanism, I'd say.
> > >
> > > It's already
On 6/8/07, Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
* On Sat, 9 Jun 2007, Dmitry Timoshkov wrote:
> * "Saulius Krasuckas" <[EMAIL PROTECTED]> wrote:
> >
> > The project needs some voting mechanism, I'd say.
>
> It's already in place.
Namely how can I enter a new voting for renaming "*" to "*
* On Sat, 9 Jun 2007, Dmitry Timoshkov wrote:
> * "Saulius Krasuckas" <[EMAIL PROTECTED]> wrote:
> >
> > The project needs some voting mechanism, I'd say.
>
> It's already in place.
Namely how can I enter a new voting for renaming "*" to "*A", then?
And I just can't resist...
"Saulius Krasuckas" <[EMAIL PROTECTED]> wrote:
The project needs some voting mechanism, I'd say.
It's already in place.
Well, Alexandre's vote would get an additional queue then, of course. ;)
The wine-patches queue works just fine IMHO.
--
Dmitry.
"Saulius Krasuckas" <[EMAIL PROTECTED]> wrote:
Since I have written a large part of that code, I can answer it:
some parts have been written under Windows, therefore no A/W suffix,
since that's how it's usually done in the Windows world, some code
has been copied from Wine parts, and they obviou
Am Freitag, 8. Juni 2007 17:12 schrieb H. Verbeet:
> On 08/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > +ActivateContext(This, src_surface, CTXUSAGE_RESOURCELOAD);
> > +if (GL_SUPPORT(ARB_MULTITEXTURE)) {
> > +GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB));
> > +ch
* On Sat, 9 Jun 2007, Dmitry Timoshkov wrote:
>
> Since I have written a large part of that code, I can answer it:
> some parts have been written under Windows, therefore no A/W suffix,
> since that's how it's usually done in the Windows world, some code
> has been copied from Wine parts, and they
"Saulius Krasuckas" <[EMAIL PROTECTED]> wrote:
Then could you answer me, please, why there is used both
SetWindowLongPtrA() and SetWindowLongPtr() in the same file
(dlls/user32/tests/win.c) ?
Since I have written a large part of that code, I can answer it:
some parts have been written under W
* On Sat, 9 Jun 2007, Dmitry Timoshkov wrote:
> * "Saulius Krasuckas" <[EMAIL PROTECTED]> wrote:
> >
> > API offers both A- an W- versions of this function, while at my first
> > glance I cannot firmly decide, what used name does refer to.
...
> The code is correct as it is now,
I talk abou
"Saulius Krasuckas" <[EMAIL PROTECTED]> wrote:
Hello. I see some tests call [GS]etWindowLongPtr(..., GWLP_WNDPROC, ...).
I think this is somewhat confusing. API offers both A- an W- versions of
this function, while at my first glance I cannot firmly decide, what used
name does refer to.
S
On 08/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
+ActivateContext(This, src_surface, CTXUSAGE_RESOURCELOAD);
+if (GL_SUPPORT(ARB_MULTITEXTURE)) {
+GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB));
+checkGLcall("glActiveTextureARB");
+}
+IWineD3DDeviceImpl_Ma
Hello. I see some tests call [GS]etWindowLongPtr(..., GWLP_WNDPROC, ...).
I think this is somewhat confusing. API offers both A- an W- versions of
this function, while at my first glance I cannot firmly decide, what used
name does refer to.
Shouldn't occurences be renamed to ...WindowLongPtr
Andrey Turkin <[EMAIL PROTECTED]> writes:
> Depends on previous NTDLL patch ('cause it uses previously stubbed out api)
>
> ---
> dlls/ntdll/tests/Makefile.in |1 +
> dlls/ntdll/tests/completion.c | 212
> +
> 2 files changed, 213 insertions(+), 0 del
> No, just filling the register maps. The actual generation of the GL
> shader still happens in CompileShader. It's nothing really
> spectacular, but it still saves us making a pass over the d3d shader
> in CompileShader, which is typically called from inside draw calls.
Sounds good :-)
As some op
On 08/06/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Am Donnerstag, 7. Juni 2007 23:52 schrieb H. Verbeet:
> For pre-2.0 pixel shaders the stateblock is used to determine the
> sampler types, so we need to wait until CompileShader to do this. For
> ps_2_0 and higher there is no such requiremen
Am Donnerstag, 7. Juni 2007 23:52 schrieb H. Verbeet:
> For pre-2.0 pixel shaders the stateblock is used to determine the
> sampler types, so we need to wait until CompileShader to do this. For
> ps_2_0 and higher there is no such requirement.
>
> Changelog:
> - For ps_2_0 and higher, call shader
James Hawkins wrote:
On 5/25/07, Andrey Turkin <[EMAIL PROTECTED]> wrote:
James Hawkins wrote:
> On 5/25/07, Mounir IDRASSI <[EMAIL PROTECTED]> wrote:
>> Hi,
>> You also have to modify other files in order to integrate your stub
>> implementation to the wine build chain: Makefile.in, configure a
Paul Vriens wrote:
Dmitry Timoshkov wrote:
"Nigel Liang" <[EMAIL PROTECTED]> wrote:
> > +static const WCHAR UNICODE_PATH[] =
{'c',':','\\','w',0x00ef,0x00f1,0x00eb,
> > +'t',0x00e8,'s','t','\0','\0'}; /* "c:\winetest" */
>
> The name above is definitely not "c:\winetest", also if you need
Dmitry Timoshkov wrote:
"Nigel Liang" <[EMAIL PROTECTED]> wrote:
> > +static const WCHAR UNICODE_PATH[] =
{'c',':','\\','w',0x00ef,0x00f1,0x00eb,
> > +'t',0x00e8,'s','t','\0','\0'}; /* "c:\winetest" */
>
> The name above is definitely not "c:\winetest", also if you need a
double
> termin
"Nigel Liang" <[EMAIL PROTECTED]> wrote:
> > +static const WCHAR UNICODE_PATH[] = {'c',':','\\','w',0x00ef,0x00f1,0x00eb,
> > +'t',0x00e8,'s','t','\0','\0'}; /* "c:\winetest" */
>
> The name above is definitely not "c:\winetest", also if you need a double
> termination '\0' state it specific
On 6/7/07, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
"Nigel Liang" <[EMAIL PROTECTED]> wrote:
> +static const WCHAR UNICODE_PATH[] = {'c',':','\\','w',0x00ef,0x00f1,0x00eb,
> +'t',0x00e8,'s','t','\0','\0'}; /* "c:\winetest" */
The name above is definitely not "c:\winetest", also if you ne
40 matches
Mail list logo
