March 2012 - Wine-devel - list.winehq.org

wineapploader in wine64
by Michael Ost 11 Mar '12

11 Mar '12

Hi, Any explanation for why the wineapploader script doesn't use 'wine64' instead of 'wine' in a 64bit Linux with 64bit wine? That's the script that is used to build /usr/bin/wineboot and /usr/bin/regedit, for instance. In Fedora 15 with wine 1.3.24, the upshot is that the 'wineboot' command doesn't work. /usr/lib/wine/wineboot.exe.so is not installed; only /usr/lib64/wineboot.exe.so is. Since the /usr/bin/wineboot is running 'wine' instead of 'wine64' it is looking for the 32bit /usr/lib/wine/wineboot.exe.so. It can't be found since it isn't installed so the loader gives up. > $ wineboot > wine: cannot find L"C:\\windows\\system32\\wineboot.exe" If it used wine64 instead, it would work. There must be a reason that wine64 is starting 32bit apps, but I haven't been able to glean anything from the web. Thanks for any info, -- Michael Ost

4 6

Build failure after interrupted first build
by Vincent Pelletier 11 Mar '12

11 Mar '12

Hi. I got a failure building wine, where wrc would fail on utils.c:xmalloc's "assert(size > 0)". This came from a po/*.mo file being present but empty because a first build got interrupted (^C). Just in case either someone here can figure out a one-liner fix for this, or if it helps the next person encountering that behaviour. Regards, -- Vincent Pelletier

1 0

Web based translation tool
by Miroslav Suchý 11 Mar '12

11 Mar '12

Hi, I just read: http://www.winehq.org/news/2012022001 and then http://wiki.winehq.org/Translating especially: > The Wine project would be very interested in making its PO files available on web-based community translations systems such as Pootle or Launchpad. Our hope is that this would make translating Wine even easier and engage new translators. > > The reason why it has not happened yet is that all Wine contributions, including for translations, must be attributable to a specific author and that these tools don't make that possible yet. For more details see the wine-devel discussion here and here. Any contributions that would solve this issue would be very welcome. which refer: http://www.winehq.org/pipermail/wine-devel/2012-January/093908.html I would like to point you to: https://www.transifex.net/ which can do the tracking. Latest version is probably not what you want, because it just add at the top of the file: # Translators: # Martin Minar <skulliq(a)gmail.com>, 2011. # Milan Kerslager <kerslage(a)linux.cz>, 2002, 2007. # Miloslav Trmac <mitr(a)volny.cz>, 2002. # Miroslav Suchý <msuchy(a)redhat.com>, 2011. msgid "" msgstr "" "Project-Id-Version: Spacewalk\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2011-12-21 13:07+0100\n" "PO-Revision-Date: 2011-12-14 09:21+0000\n" "Last-Translator: Miroslav Suchý <msuchy(a)redhat.com>\n" "Language-Team: Czech (http://www.transifex.net/projects/p/fedora/team/cs/)\n So you had overview of contributors, but you could not tell which one contributor done which string. But version 0.7 (IIRC) sent each contribution immediately to git. Under login (and email) of that contributor. That contributor was "Author" and commiter was some transifex user. So this way you allow git commit access to those contributors directly to git, but since it goes via that web interface, they could commit only to /po/ directory and even only to language, for which they had been granted. You can download it here: http://trac.transifex.org/files/ and setup your own instance. If is sufficient for you only tracking name of contributors, you can use that hosted solution at: https://www.transifex.net/ -- Miroslav Suchy Red Hat Satellite Engineering

4 5

Are we the reason Apple isn't helping us?
by Charles Davis 11 Mar '12

11 Mar '12

Hi, An Apple developer recently contacted me directly about the Wine64 radar (number 9269783). What's interesting about his response, however, is that he put in an aside to berate us for our etiquette. I am convinced that at least this developer sees us as rude, hateful creatures now, and he cited a particular bug (29922) that he filed and even offered to fix as an example. Gee, I wonder why that might be? (Hint: Look at the "To:" field.) In your defense, I realize that Vitaliy's behavior is not representative of Wine developers as a whole, and that Jeremy's behavior wasn't exactly golden, either. I also realize that there really is no build breakage resulting from the bug, because we don't include any Objective-C headers. He was convinced that there could have been breakage, however. You--AJ, I'm talking to you in particular--did not adequately explain to him why this didn't break the build. Instead, you--Vitaliy in particular--practically yelled at him--for trying to help! By this point, he's likely told his colleagues at Apple about his experience. With guys like Vitaliy developing Wine, is it any wonder Apple doesn't want to help? Are we, the developers, the real reason Apple isn't contributing? For that matter, are we the real reason more people *in general* aren't contributing? At the very least, we should be more welcoming of help, even from Apple. We need it. Maybe not to fix trivial non-bugs like 29922, but to make Wine a better alternative to Windows--on Mac, Linux, or anywhere. But as long as people like Vitaliy are yelling at potential contributors, we won't get much help beyond what we've got at CodeWeavers. Just my two bits. Chip

4 3

Re: mscoree: Better support RUNTIME_INFO_UPGRADE_VERSION in, GetRequestedRuntimeInfo
by Vincent Povirk 11 Mar '12

11 Mar '12

Can you add a test to make sure the 2.x runtime doesn't get returned when 1.x is requested with RUNTIME_INFO_UPGRADE_VERSION ? On Sun, Mar 11, 2012 at 5:49 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > > > Changelog: > mscoree: Better support RUNTIME_INFO_UPGRADE_VERSION in > GetRequestedRuntimeInfo > > > Best Regards > Alistair Leslie-Hughes > > >

1 0

Re: winedbg: Respect Thumb mode when adjusting PC on ARM
by Eric Pouech 11 Mar '12

11 Mar '12

Le 10/03/2012 18:26, André Hentschel a écrit : > --- > programs/winedbg/be_arm.c | 10 ++++++---- > 1 files changed, 6 insertions(+), 4 deletions(-) > > diff --git a/programs/winedbg/be_arm.c b/programs/winedbg/be_arm.c > index c39043c..6c1cc05 100644 > --- a/programs/winedbg/be_arm.c > +++ b/programs/winedbg/be_arm.c > @@ -205,13 +205,15 @@ static void be_arm_clear_watchpoint(CONTEXT* ctx, unsigned idx) > > static int be_arm_adjust_pc_for_break(CONTEXT* ctx, BOOL way) > { > + INT step = (ctx->Cpsr& 0x20) ? 2 : 4; hmm the way winedbg works might put us in trouble here... when winedbg is entered with a break exception: 1/ winedbg calls adjust_pc_for_break(..., TRUE) to get the PC to the real location of the break insn (and not after, as most CPU report in break exception handler) 2/ user interacts with winedbg 3/ user resumes execution, and winedbg calls again adjust_pc_for_break(..., FALSE) but, the ctx passed here is the context used to resume execution... and in ARM case Cpsr could have been changed by user in step 2/ leading to wrong PC computation in 3/ therefore, if we want to plug that hole, I'd suggest having two context used in winedbg (the incoming one (never being changed), and the current/outgoing one), and that we pass the two contexts in winedbg to do the right thing here A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 2

Re: gdiplus: Create GDI bitmap only when needed.
by Vincent Povirk 11 Mar '12

11 Mar '12

Looks good, thanks.

1 0

Re: [PATCH 6/6] d3dxof: Do not allow separator to terminate the string. Only the double quote can do that.
by Alexandre Julliard 10 Mar '12

10 Mar '12

Christian Costa <titan.costa(a)gmail.com> writes: > This should fix the d3dxof problem of bug 12694. It's broken on 64-bit: ../../../../wine/tools/runtest -q -P wine -M d3dxof.dll -T ../../.. -p d3dxof_test.exe.so ../../../../wine/dlls/d3dxof/tests/d3dxof.c && touch d3dxof.ok d3dxof.c:578: Test failed: Got size 8, expected 4 d3dxof.c:597: Test failed: Got size 8, expected 4 make[1]: *** [d3dxof.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

3 7

Re: windowscodecs: Implement DllCanUnloadNow
by Vincent Povirk 10 Mar '12

10 Mar '12

Um, you missed almost much every implementation of a COM interface in the entire dll? 2012/3/10 André Hentschel <nerv(a)dawncrow.de>: > Needed for dotNet 4.5 preview > --- > dlls/windowscodecs/clsfactory.c | 15 +++++++++++++-- > dlls/windowscodecs/main.c | 9 +++++++++ > dlls/windowscodecs/wincodecs_private.h | 12 ++++++++++++ > dlls/windowscodecs/windowscodecs.spec | 1 + > 4 files changed, 35 insertions(+), 2 deletions(-) > > diff --git a/dlls/windowscodecs/clsfactory.c b/dlls/windowscodecs/clsfactory.c > index 0f30115..bd22ce5 100644 > --- a/dlls/windowscodecs/clsfactory.c > +++ b/dlls/windowscodecs/clsfactory.c > @@ -112,7 +112,10 @@ static ULONG WINAPI ClassFactoryImpl_Release(IClassFactory *iface) > TRACE("(%p) refcount=%u\n", iface, ref); > > if (ref == 0) > + { > HeapFree(GetProcessHeap(), 0, This); > + unlock_module(); > + } > > return ref; > } > @@ -127,8 +130,14 @@ static HRESULT WINAPI ClassFactoryImpl_CreateInstance(IClassFactory *iface, > > static HRESULT WINAPI ClassFactoryImpl_LockServer(IClassFactory *iface, BOOL lock) > { > - TRACE("(%p, %i): stub\n", iface, lock); > - return E_NOTIMPL; > + TRACE("(%p,%x)\n", iface, lock); > + > + if(lock) > + lock_module(); > + else > + unlock_module(); > + > + return S_OK; > } > > static const IClassFactoryVtbl ClassFactoryImpl_Vtbl = { > @@ -146,6 +155,8 @@ static HRESULT ClassFactoryImpl_Constructor(classinfo *info, REFIID riid, LPVOID > > *ppv = NULL; > > + lock_module(); > + > This = HeapAlloc(GetProcessHeap(), 0, sizeof(ClassFactoryImpl)); > if (!This) return E_OUTOFMEMORY; > > diff --git a/dlls/windowscodecs/main.c b/dlls/windowscodecs/main.c > index a6588fd..69e50f5 100644 > --- a/dlls/windowscodecs/main.c > +++ b/dlls/windowscodecs/main.c > @@ -32,6 +32,8 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(wincodecs); > > +LONG module_ref = 0; > + > extern BOOL WINAPI WIC_DllMain(HINSTANCE, DWORD, LPVOID) DECLSPEC_HIDDEN; > > BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) > @@ -49,6 +51,13 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) > return WIC_DllMain(hinstDLL, fdwReason, lpvReserved); > } > > +HRESULT WINAPI DllCanUnloadNow(void) > +{ > + TRACE("() ref=%d\n", module_ref); > + > + return module_ref ? S_FALSE : S_OK; > +} > + > HRESULT copy_pixels(UINT bpp, const BYTE *srcbuffer, > UINT srcwidth, UINT srcheight, INT srcstride, > const WICRect *rc, UINT dststride, UINT dstbuffersize, BYTE *dstbuffer) > diff --git a/dlls/windowscodecs/wincodecs_private.h b/dlls/windowscodecs/wincodecs_private.h > index 691b1ec..8845e22 100644 > --- a/dlls/windowscodecs/wincodecs_private.h > +++ b/dlls/windowscodecs/wincodecs_private.h > @@ -87,4 +87,16 @@ extern HRESULT MetadataReader_Create(const MetadataHandlerVtbl *vtable, IUnknown > > extern HRESULT UnknownMetadataReader_CreateInstance(IUnknown *pUnkOuter, REFIID iid, void** ppv) DECLSPEC_HIDDEN; > > +extern LONG module_ref DECLSPEC_HIDDEN; > + > +static inline void lock_module(void) > +{ > + InterlockedIncrement(&module_ref); > +} > + > +static inline void unlock_module(void) > +{ > + InterlockedDecrement(&module_ref); > +} > + > #endif /* WINCODECS_PRIVATE_H */ > diff --git a/dlls/windowscodecs/windowscodecs.spec b/dlls/windowscodecs/windowscodecs.spec > index d0b6a7e..71022cb 100644 > --- a/dlls/windowscodecs/windowscodecs.spec > +++ b/dlls/windowscodecs/windowscodecs.spec > @@ -1,3 +1,4 @@ > +@ stdcall -private DllCanUnloadNow() > @ stdcall -private DllGetClassObject(ptr ptr ptr) > @ stdcall -private DllRegisterServer() > @ stdcall -private DllUnregisterServer() > -- > > Best Regards, André Hentschel > > >

2 2

Re: [1/2] kernel32: Forward RtlPcToFileHeader to ntdll also on ARM
by André Hentschel 10 Mar '12

10 Mar '12

Am 08.03.2012 22:10, schrieb André Hentschel: > needed by native msvcrt110.dll and msvcrt110d.dll > --- > dlls/kernel32/kernel32.spec | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec > index fb3f9c2..1c794c9 100644 > --- a/dlls/kernel32/kernel32.spec > +++ b/dlls/kernel32/kernel32.spec > @@ -1023,7 +1023,7 @@ > @ stdcall RtlFillMemory(ptr long long) ntdll.RtlFillMemory > @ stdcall -arch=x86_64 RtlLookupFunctionEntry(long ptr ptr) ntdll.RtlLookupFunctionEntry > @ stdcall RtlMoveMemory(ptr ptr long) ntdll.RtlMoveMemory > -@ stdcall -arch=x86_64 RtlPcToFileHeader(ptr ptr) ntdll.RtlPcToFileHeader > +@ stdcall -arch=x86_64,arm RtlPcToFileHeader(ptr ptr) ntdll.RtlPcToFileHeader I forgot to mention that i checked that it's really not exported on all architectures. And yes, it's really only on x64 and arm, not on x86. -- Best Regards, André Hentschel

1 0