wine-devel April 2011

wine-devel@winehq.org

80 participants
185 discussions

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

Re: [PATCH 4/5] wined3d: Merge the IWineD3DSwapChain::Destroy() implementations.
by Alexandre Julliard 08 Apr '11

08 Apr '11

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > They're mostly the same, except for the GL version also destroying its > contexts, and being a bit more careful about the order in which backbuffers > are destroyed. > --- > dlls/wined3d/swapchain.c | 175 ++++++++++++++++----------------------------- > 1 files changed, 62 insertions(+), 113 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so ddrawmodes.c && touch ddrawmodes.ok wine: Unhandled page fault on read access to 0x00000f2c at address 0x687550fa (thread 0021), starting debugger... Unhandled exception: page fault on read access to 0x00000f2c in 32-bit code (0x687550fa). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:687550fa ESP:0032f910 EBP:0032f948 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000021 EBX:6884b244 ECX:00110064 EDX:00000000 ESI:00000000 EDI:00000001 Stack dump: 0x0032f910: 00001302 00131ef0 00000000 00000000 0x0032f920: 00000000 00000000 00000000 00110014 0x0032f930: 0000ff00 000000ff 687550db 6884b244 0x0032f940: 00131848 00000001 0032f9a8 6880052b 0x0032f950: 00134d58 00000000 00131ef0 7bc73cfc 0x0032f960: 00000002 00129f28 00000000 000004b0 Backtrace: =>0 0x687550fa context_destroy+0x2a(This=0x134d58, context=(nil)) [/home/julliard/wine/wine/dlls/wined3d/context.c:1615] in wined3d (0x0032f948) 1 0x6880052b IWineD3DBaseSwapChainImpl_Destroy+0x18a(iface=0x131848) [/home/julliard/wine/wine/dlls/wined3d/swapchain.c:65] in wined3d (0x0032f9a8) 2 0x688006a1 IWineD3DBaseSwapChainImpl_Release+0x40(iface=0x131848) [/home/julliard/wine/wine/dlls/wined3d/swapchain.c:125] in wined3d (0x0032f9e8) 3 0x686d25b9 D3D7CB_DestroySwapChain+0x58(swapchain=0x131848) [/home/julliard/wine/wine/dlls/ddraw/ddraw.c:2621] in ddraw (0x0032fa18) 4 0x6875d317 IWineD3DDeviceImpl_UninitGDI+0x66(iface=0x134d58, D3DCB_DestroySwapChain=0x686d2560) [/home/julliard/wine/wine/dlls/wined3d/device.c:2300] in wined3d (0x0032fa78) 5 0x686f8f6e ddraw_surface7_Release+0x1cd(iface=0x129f28) [/home/julliard/wine/wine/dlls/ddraw/surface.c:396] in ddraw (0x0032fad8) 6 0x68689c21 func_ddrawmodes+0x2720() [/home/julliard/wine/wine/dlls/ddraw/tests/ddrawmodes.c:583] in ddraw_test (0x0032fd38) 7 0x686adc9e run_test+0x14d(name="ddrawmodes.c") [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:556] in ddraw_test (0x0032fd88) 8 0x686ae767 main+0x156(argc=0xffffffff, argv=(nil)) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:624] in ddraw_test (0x0032fe48) 9 0x686ae93c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ddraw_test (0x0032fe90) 10 0x7b859a6c call_process_entry+0xb() in kernel32 (0x0032fea8) 11 0x7b85a69f start_process+0x5e(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1086] in kernel32 (0x0032fee8) 12 0x7bc74c78 call_thread_func+0xb() in ntdll (0x0032fef8) 13 0x7bc776b0 call_thread_entry_point+0x6f(entry=0x7b85a640, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffc8) 14 0x7bc4d27a start_process+0x29(kernel_start=0x7b85a640) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2606] in ntdll (0x0032ffe8) 15 0x6802996d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 0x687550fa context_destroy+0x2a [/home/julliard/wine/wine/dlls/wined3d/context.c:1615] in wined3d: cmpl %eax,0xf2c(%esi) 1615 if (context->tid == GetCurrentThreadId() || !context->current) -- Alexandre Julliard julliard(a)winehq.org

2 1

← Newer
1
...
11
12
13
14
15
16
17
18
19
Older →

Jump to page:

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 April 2011