wine-devel February 2007

wine-devel@winehq.org

130 participants
279 discussions

Re: version: Constify a formal parameter of VerQueryValue{A|W}()
by Felix Nawothnig 13 Feb '07

13 Feb '07

Andrew Talbot wrote: > -BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPSTR lpSubBlock, > +BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPCSTR lpSubBlock, This is wrong - in the PSDK headers it's LPSTR (the first parameter should be const though). Felix

2 2

Re: Bug 50
by Pedro Araújo Chaves Jr. 13 Feb '07

13 Feb '07

I've been trying to get the lpDx array to be properly calculated, but unfortunately to no avail. I did find, though, that GetTextExtentExPointW is never called with a maxExt value other than zero, and thus nfit is not calculated. Regarding that, would any of you know where I should look for the proper method of calculating the maximum width (maxExt) of a formatted string? I'm somewhat puzzled... neither lprect nor dc->BoundsRect seem to hold the proper values for getting that value [1], or (more likely, I guess) I'm just looking at it the wrong way. Btw, I'd add that I've been testing this in Lotus Notes R5, just in case it helps, and no, I haven't found a link to download a trial. [2] [3] Cheers, Pedro. [1] I'm investigating the SetTextJustification, ExtTextOutW, GetTextExtentPointW, GetTextExtentPoint32W, GetTextExtentExPointW, and WineEngGetTextExtentExPoint functions from gdi32 (the latter in freetype.c, the rest in font.c). I am yet to look into their *I counterparts, where applicable. [2] http://appdb.winehq.org/viewbugs.php?bug_id=50 [3] http://bugs.winehq.org/show_bug.cgi?id=7016

2 3

Re: opengl
by Bryan Haskins 13 Feb '07

13 Feb '07

Well you don't have Direct rendering... if you dont have support from the ATI OSS drivers ( if you use ATi) then you should download the ATI or nvidia proprietary drivers. Should be in your Distros Repos, or you can set them up yourself from their sties. On 2/13/07, gaosheng <gs(a)crosslight.com.cn> wrote: > > Hi: > I want to use opengl with wine. > > //----Here is my glxinfo. > > server glx vendor string:SGI > server glx version string:1.2 > > client glx vendor string:SGI > client glx version string:1.2 > > OpengGL vendor string:Mesa project:www.mesa3d.org > OpengGL renderer string:Mesa GLX Indirect > OpengGL version string:1.3 Mesa 4.0.4 > //------ > > I can't init opengl. when ChoosePixel(), it failed. > Can you tell me the reason. > > Best regards > gao sheng > > > > > -- Cheers, Bryan

1 0

Linuxtag 2007
by Stefan Munz 13 Feb '07

13 Feb '07

Hi, mentioned a few days ago I try to register "Wine" for participating at the Linuxtag 2007. They want some information that I can only guess. Maybe someone can provide me a better estimation for: Developers in 1. Germany 2. Europe (incl. Germany) 3. Worldwide (incl. Europe) How many developers work for Codeweavers (as they are for sure the biggest contributor)? -- Dipl.-Inform. Stefan Munz. . . . . . . . . . stefan.munz(a)itomig.de ITOMIG GbR . . . . . . . . . . . . . . . . . www.itomig.de Sand 14 . . . . . . . . . . . . . . . . . . mobil: +49 178 729 72 72 D-72076 Tübingen . . . . . . . . . . . . . .

6 8

Re: [PATCH] switch stat and fopen
by Mike McCormack 13 Feb '07

13 Feb '07

Marcus Meissner wrote: > - if (!(fin = fopen(input_file_name, "r"))) return 0; > if (stat(input_file_name, &st) < 0) return 0; > + if (!(fin = fopen(input_file_name, "r"))) return 0; Wouldn't it be better to use fstat here to avoid a race condition? Mike

2 1

Re: mshtml #10: Added SchemeIs implementation.
by Alexandre Julliard 13 Feb '07

13 Feb '07

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/nsio.c | 12 +++++++++++- > 1 files changed, 11 insertions(+), 1 deletions(-) This one causes make test to hang in the htmldoc.c test, somewhere in test_download(). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: avifil32: sign-compare fixes
by Alexandre Julliard 13 Feb '07

13 Feb '07

Joris Huizer <joris_huizer(a)yahoo.com> writes: > diff --git a/dlls/avifil32/avifile.c b/dlls/avifil32/avifile.c > index f989c79..e7b22b1 100644 > --- a/dlls/avifil32/avifile.c > +++ b/dlls/avifil32/avifile.c > @@ -835,7 +835,7 @@ static LONG WINAPI IAVIStream_fnFindSamp > ULONG n; > > for (n = 0; n < This->sInfo.dwFormatChangeCount; n++) > - if (This->idxFmtChanges[n].ckid >= pos) { > + if (This->idxFmtChanges[n].ckid >= (ULONG)pos) { Please don't add typecasts all over the place. If things can be fixed by changing variable types then that's fine, but otherwise we can just as well live with the warnings. -- Alexandre Julliard julliard(a)winehq.org

1 0

opengl
by gaosheng 13 Feb '07

13 Feb '07

Hi: I want to use opengl with wine. //----Here is my glxinfo. server glx vendor string:SGI server glx version string:1.2 client glx vendor string:SGI client glx version string:1.2 OpengGL vendor string:Mesa project:www.mesa3d.org OpengGL renderer string:Mesa GLX Indirect OpengGL version string:1.3 Mesa 4.0.4 //------ I can't init opengl. when ChoosePixel(), it failed. Can you tell me the reason. Best regards gao sheng

1 0

Re: DIB Engine, some summarization
by Rolf Kalbermatter 13 Feb '07

13 Feb '07

Damjan Jovanovic [mailto:damjan.jov@gmail.com] well: >What about the case where you draw with GDI, then render with OpenGL on >top of that, then draw on top of that with GDI, then swap buffers? >If you draw only client-side, you have to copy to the server, then copy >back, then copy to the server *again*. You have to upload or download >the image *every time* you go between OpenGL and GDI drawing, whereas >when you draw with X11, there is no uploads/downloads unless you use >DIB sections and draw directly. Well, I have to admit I don't understand the whole complexity with DirectX, OpenGL and GDI. But the DIB engine is mostly for DIB sections I would think. It could be used for most device dependant bitmap surfaces too as long as the driver puts them in the surface structure of course, since that are just bitmaps too, but if that would be wise is another question. I would think that to start with the handling of DIBs would be most important. Or is it the idea to use the DIB engine for device dependant bitmaps attached to the device context too? Because that would make at least this case probably indeed more complicated. As far as X11 is concerend device dependant bitmaps should not pose a problem other than possibly performance if an application also wants to draw directly in the bitmap. But this works now and could be left in. And the bit depth will be alright since the ddb should be in the same bit depth as what the X11 server uses. DIBs however have the additional problem of using any possible bit depth with X11 only really supporting the currently used bit depth. So here you want to get X11 out of the loop if possible. >X11 drawing has some more advantages, like being able to use forms of >hardware acceleration (XAA/EXA) that client-side drawing can't. That might be but arbitrary bit depth support for hardware related acceleration is probably not very common among chip sets. >A pure client-side drawing strategy is IMO inferior to a strategy where >you can draw client-side or server-side, as the need arises. I think DIB drawing should be if possible kept on the client side. That solves the problems with X11 not supporting arbitrary bit depths and also synchronisation of the bitmaps if the application uses direct bitmap access too. And it wouldn't be pure client side at all. A driver can hook functions even for DIBs if he wants. If he does he would of course have to make sure all bit depths are supported and synchronisation is taken care off. Support of all bit depts would be quite easy as it could decide to do whatever modes it can do and otherwise pass it on to the GDI engine anyhow. If the driver doesn't hook or fails that function somehow then the GDI engine is used to do the operation for the DIB. And at least for drivers having their device bitmap in the device context too (under Windows a driver doesn't need to do that, for instance always drawing directly to the shared video memory), it might be possible to use the DIB engine too, but that would be the drivers decision and as said I'm not yet sure that is how it's done under Windows nor if it should be done this way. Rolf Kalbermatter

1 0

ntdll: test that shows RtlRaiseException with EXCEPTION_BREAKPOINT mangles Eip of context
by Peter Oberndorfer 12 Feb '07

12 Feb '07

This test is supposed to show that the Eip field in the context is fixed up somewhere inside RtlRaiseException or NtRaiseException (test for NtRaiseException not included) for (only) EXCEPTION_BREAKPOINT exception For others context.Eip is not changed. Since real exceptions on wine also take that path i guess it is best to implement context modifing in there. The next patches will show what is the value of context.Eip in a Vectored exception handler (I still have some problems with this patch) After that i plan to wrap a debugger around the test to show that the debugger gets a unmodified context The ultimate goal is to fix the "Handling of EXCEPTION_BREAKPOINT" problem Vitaliy Margolen reported ( http://bugs.winehq.org/show_bug.cgi?id=7063 ) Patch tested on XP/2k Comments, suggestions? Greetings Peter --- dlls/ntdll/tests/exception.c | 85 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 85 insertions(+), 0 deletions(-)

1 0

← Newer
1
...
16
17
18
19
20
21
22
...
28
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel February 2007