April 2011 - Wine-devel - list.winehq.org

Re: dbghelp: get rid of a couple unused variables
by Andrew Nguyen 11 Apr '11

11 Apr '11

On 04/11/2011 12:41 AM, Austin English wrote: > This ignores the side effects of the dwarf2_parse_u2 function.

2 1

Re: gdi32/dibdrv: The dib debug channel is unused so remove it.
by Huw Davies 11 Apr '11

11 Apr '11

On Sun, Apr 10, 2011 at 06:45:51PM +0200, Francois Gouget wrote: > It might get used soon but then it's easy to add back anyway. Very soon in fact - it gets used in the PatBlt patch I just sent ;-)

1 0

Re: d3dx9_36: Make get_parameter_{handle,struct}() static.
by luis.busquets＠ilidium.com 11 Apr '11

11 Apr '11

Shouldn't this be inline? > --- > dlls/d3dx9_36/effect.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c > index 1e3de0c..a03e8a3 100644 > --- a/dlls/d3dx9_36/effect.c > +++ b/dlls/d3dx9_36/effect.c > @@ -91,12 +91,12 @@ static void skip_dword_unknown(const char **ptr, > unsigned int count) > } > } > > -struct d3dx_parameter *get_parameter_struct(D3DXHANDLE handle) > +static struct d3dx_parameter *get_parameter_struct(D3DXHANDLE handle) > { > return (struct d3dx_parameter *) handle; > } > > -D3DXHANDLE get_parameter_handle(struct d3dx_parameter *parameter) > +static D3DXHANDLE get_parameter_handle(struct d3dx_parameter *parameter) > { > return (D3DXHANDLE) parameter; > } > -- > 1.7.4.1 > > > >

1 0

Ubuntu's new UI has glitches that affect Wine...
by Dan Kegel 11 Apr '11

11 Apr '11

Ubuntu 11.04 beta 1 is out, http://www.ubuntu.com/testing/natty/beta There are aleady about six bug reports about how its new UI interacts with Wine: https://launchpad.net/ubuntu/+bugs?field.searchtext=unity+wine If you're an ubuntu user, please try out Natty Beta, review those bugs, and vote for the ones that affect you. And file more if you find any! - Dan

1 1

Introducing "Deobjectivizer"
by Charles Davis 11 Apr '11

11 Apr '11

Hi, I've been working on a secret Clang-based project for a while, and now I'm ready to share it with the world. Introducing the "Deobjectivizer". This is a program that scans framework bundle headers for Objective-C constructs, and generates procedural C wrappers around them, so you can call them from C. It uses Clang's libraries to parse, analyze, and rewrite Objective-C headers into pure C headers, and then generate corresponding source files containing the wrapper implementations. The implementation of this tool is a little hackish at the moment, but it suffices to generate a wrapper around the entire Foundation framework (at least). With this, we don't have to use Objective-C just to use Cocoa anymore. The Mac OS X Quartz driver can go forward now! The QuickTime decoder can use QTKit now instead of the 32-bit only Carbon QuickTime interface, allowing it to work on 64-bit (if and when Wine supports it on Mac). It might even be possible to integrate Win32 screen-savers with Mac OS X using this (the ScreenSaver framework is Objective-C based). I've attached the source so you can play with my newest creation. At the moment, it can only be built on Mac OS X (only one of two platforms, the other being iOS, where a program like this makes sense anyway). Feel free to make changes; the sources are licensed under the same license as Clang itself. We can't incorporate it into Wine directly because it is written in C++ (and maybe because of the license), but we can detect its presence at compile time (in configure) and use it to generate pure C wrappers that Wine can use. Comments welcome. What do you think? Chip

1 0

Re: gdiplus: Make get_font_hfont() static.
by Vincent Povirk 10 Apr '11

10 Apr '11

I'm planning to use this from GdipAddPathString. On Sun, Apr 10, 2011 at 11:45 AM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > dlls/gdiplus/gdiplus_private.h | 2 -- > dlls/gdiplus/graphics.c | 2 +- > 2 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/dlls/gdiplus/gdiplus_private.h b/dlls/gdiplus/gdiplus_private.h > index 1629ae6..bfa33ef 100644 > --- a/dlls/gdiplus/gdiplus_private.h > +++ b/dlls/gdiplus/gdiplus_private.h > @@ -58,8 +58,6 @@ extern void calc_curve_bezier_endp(REAL xend, REAL yend, REAL xadj, REAL yadj, > > extern void free_installed_fonts(void); > > -extern void get_font_hfont(GpGraphics *graphics, GDIPCONST GpFont *font, HFONT *hfont); > - > extern BOOL lengthen_path(GpPath *path, INT len); > > extern GpStatus trace_path(GpGraphics *graphics, GpPath *path); > diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c > index 336929f..6a5ef7f 100644 > --- a/dlls/gdiplus/graphics.c > +++ b/dlls/gdiplus/graphics.c > @@ -1654,7 +1654,7 @@ end: > return stat; > } > > -void get_font_hfont(GpGraphics *graphics, GDIPCONST GpFont *font, HFONT *hfont) > +static void get_font_hfont(GpGraphics *graphics, GDIPCONST GpFont *font, HFONT *hfont) > { > HDC hdc = CreateCompatibleDC(0); > GpPointF pt[3]; > -- > 1.7.4.1 > > > >

1 0

Try to implement my first stub function - AbortPrinter() - (try 3)
by Loïc Maury 10 Apr '11

10 Apr '11

Hello, I try always to implement my first stub function - AbortPrinter. The last time, I send into Wine patch mailling list, but the patch was not correct. Now I think the format for the patch is correct (no whitespace, etc…). More over, I have modified the value if(!job->portname) by if(!portname), because after the test "if(!job->portname)", I print trace of portname, but before he was initialized into the "if condition" and can to not enter into this condition. What do you think ? Thank you Loïc

3 3

Fwd: d3dx9_36 [patch 1/3; try 9]: Remove useless includes
by David Adam 10 Apr '11

10 Apr '11

Any feedback for the reasons why this patch and the following ones were not commited? Thanks in advance A+ David ---------- Forwarded message ---------- From: David Adam <david.adam.cnrs(a)gmail.com> Date: 2011/4/6 Subject: d3dx9_36 [patch 1/3; try 9]: Remove useless includes To: wine-patches <wine-patches(a)winehq.org>

1 0

Must multimedia players check the message queue and invoke DispatchMessage?
by Joerg-Cyril.Hoehle＠t-systems.com 10 Apr '11

10 Apr '11

Hi, In Bug #3930 http://bugs.winehq.org/show_bug.cgi?id=3930#c41 I conjectured that: 1. Since w2k, winmm hijacks the application's thread to play multimedia content. Wine does this as well with MCI_WAIT, but it should as well affect winmm:playSound, winmm:midi* and winmm:wave*. 2. Consequently, the players must implement a message loop and dispatch regular window messages using DispatchMessageA/W Currently, Wine does not. This IMHO has potential for dead locks. Music and animations can play for a long time and messages ought to be serviced. I'm not familiar with windows messages at all. What do you think about the consequence? Point 1 explains why tests reveal the current thread as the one executing all callbacks but one since w2k. Point 2 should be testable by playing a long piece of video or music and prequeuing or injecting (how?) some windows events. How to test this in a convincing manner? Would the obligation to service messages disappear if the players ran in their own thread (like w9x seems to do)? Thanks for your help, Jörg Höhle

5 8

Project: x86 to ARM binary translator
by Yale Zhang 09 Apr '11

09 Apr '11

Fellow developers, I'm thinking of starting a VM project to allow running x86 Windows apps on ARM Android. This will obviously involve binary translation. I've read about QEMU's tiny code generator and think for a usable experience, the intermediate micro-op representation will have to be abandoned, and use a more efficient, though less portable x86 to ARM translator. I also saw some Google SOC project that tried to incorporate LLVM into QEMU, but with disastrous slow down if done naively. I still think it's worth to do so, but lots of care will need to be done to only optimize code that needs it like Sun's HotSpot Java compiler does. Questions: 1. How useful would this be and how much interest? Obviously, this will be a huge project, and I just want to gauge the interest before I jump in. Microsoft will be releasing Windows for ARM soon, so there will be no need to worry about running Office, Matlab, Visual C++, etc on ARM, leaving only legacy applications and games to benefit from binary translation. I'm mostly interested in seeing some 3D games run on my Xoom. 2. What's the best design: whole system VM (qemu) or process VM (qemu & wine)? Process VM: + easier to incorporate 3D acceleration at API level + uses less memory + better performance (e.g. no need for MMU translation when accessing memory) + much better integration with host OS - needs to maintain custom Windows API implementation (Wine) Whole system VM: + simpler, more unified to implement + much better support for apps that are dependent on new, proprietary, obscure Windows libraries, interfaces (moot because Office, Matlab, etc will soon be available for ARM) Given the aims of only running legacy applications and games, it seems a foregone conclusion that Wine's process VM approach is best. Comments? 3. Will Wine ever incorporate binary translation? My proposed design will obviously use Wine's implementation of the Windows API, which is huge. I'm not sure how disruptive of a change binary translation will be to Wine. If Wine does incorporate binary translation, maybe they can change the name to Wine Is Now an Emulator If your're interested in this project, please reply.

6 7