October 2012 - Wine-Devel - list.winehq.org

Re: [PATCH] user32: Fix error handling in MapWindowPoints, ClientToScreen and ScreenToClient and add tests for them. (try 6) (resend)

by Dmitry Timoshkov

Christian Costa <titan.costa(a)gmail.com> wrote: > Based ont a patch of Rico Schuller. I'd suggest to make sure that the test with appropriate todo_wine statements is accepted first, and only then start thinking about a proper fix, or even leave creating the fix to someone else. -- Dmitry.

Oct. 31, 2012

Re: [PATCH] user32: Fix error handling in MapWindowPoints, ClientToScreen and ScreenToClient and add tests for them. (try 6) (resend)

by Christian Costa

2012/10/31 Dmitry Timoshkov <dmitry(a)baikal.ru> > Christian Costa <titan.costa(a)gmail.com> wrote: > > > Based ont a patch of Rico Schuller. > > I'd suggest to make sure that the test with appropriate todo_wine > statements is accepted first, It it can help the process, I'll do that. > and only then start thinking about > a proper fix, or even leave creating the fix to someone else. > > > That doesn't prevent to give feedback and say what's wrong with this last fix version.

Oct. 31, 2012

Re: What parts of gettext does Wine need at runtime?

by Alexandre Julliard

Scott Ritchie <scott(a)open-vote.org> writes: > Is libgettextpo0 (in 32 and 64 bit) sufficient? Or do we need the > sort of utilities in the gettext-base package? The gettext tools are only needed at build time. libgettextpo is also only needed at build time, and then only if you are a developer who wants to rebuild po files. There's no runtime dependency on any part of gettext at all. -- Alexandre Julliard julliard(a)winehq.org

Oct. 31, 2012

What parts of gettext does Wine need at runtime?

by Scott Ritchie

Is libgettextpo0 (in 32 and 64 bit) sufficient? Or do we need the sort of utilities in the gettext-base package? I'm trying to fix https://bugs.launchpad.net/ubuntu/precise/+source/gettext/+bug/954029 which was largely caused by my overcautiousness here.

Oct. 30, 2012

Re: [PATCH 3/4] msvcp90: in istream<>::tellg don't use sentry

by Piotr Caban

On 10/30/12 10:16 PM, Daniel Lehman wrote: + tpos.pos = 0xdeadbeefdeadbeef; Long long constants are not supported in C89. You can use 0xdeadbeef here.

Oct. 30, 2012

Re: xapofx1_3.dll?

by Austin English

On Tue, Oct 30, 2012 at 6:11 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > > why does Wine include a stub xapofx1_1.dll but no xapofx1_3.dll? > > Installing Wallace & Gromit 102 "The Last Resort" / "Urlaub unter Tage" > adds xapofx1_3.dll XAudio2_4.dll and X3DAudio1_6.dll > to system32 (though IIRC I asked the installer not to care about DirectX). > > This app loads none of these libraries (well, I solely tested winecfg's > default xp mode, not w7. Presumably those dlls are only relevant > since Vista with mmdevapi and the app uses DSound on older systems). > > http://bugs.winehq.org/show_bug.cgi?id=27279 > is about apps linked against this dll such that they won't even start. > > Regards, > Jörg Höhle > It looks like no one ever sent a patch for it, at least according to my email archives and a quick google search. -- -Austin

Oct. 30, 2012

Re: scrrun: Add basic IDictionary getHasVal support

by Piotr Caban

Hi, On 10/30/12 09:51, Alistair Leslie-Hughes wrote: +static LONG create_hash_val(BSTR name) +{ + LONG hash = 0; + int len = SysStringLen(name); + int i; + + for(i =0; i < len; i++) + { + hash += name[i]; + } + + return hash; +} This hashing function will have lots of conflicts when used in hash-table. It's quite easy to guess how it's done in native dll: for(i=0; i<len; i++) hash = (hash<<4) + hash + name[i]; hash %= 1201; It would be nice to add some tests for strings containing '\0' characters and for other VARIANT types. I don't know how scrrun stores data internally, if it's using a hash-table, the function may change after adding some elements.

Oct. 30, 2012

Re: ntdll: Do not execute callbacks past DeleteTimer(INVALID_HANDLE_VALUE)

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > You know this patch from March this year. Initially, this patch was > the first of 2-3. I decided to release it on its own after finding > out yesterday that in July, Fran,cois Gouget added a todo_wine for a > bug that I fixed monthes earlier! Now I had to augment my patch > with a one-liner removing that todo_wine from kernel32/tests. > > Let me thank him for writing a test case that demonstrates the > effectiveness of my patch. Or lack thereof ;-) ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so sync.c && touch sync.ok sync.c:808: Test failed: Timer callback 0 expected 1 got 0 sync.c:1166: Tests skipped: one-time initialization API not supported make[1]: *** [sync.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Oct. 30, 2012

xapofx1_3.dll?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, why does Wine include a stub xapofx1_1.dll but no xapofx1_3.dll? Installing Wallace & Gromit 102 "The Last Resort" / "Urlaub unter Tage" adds xapofx1_3.dll XAudio2_4.dll and X3DAudio1_6.dll to system32 (though IIRC I asked the installer not to care about DirectX). This app loads none of these libraries (well, I solely tested winecfg's default xp mode, not w7. Presumably those dlls are only relevant since Vista with mmdevapi and the app uses DSound on older systems). http://bugs.winehq.org/show_bug.cgi?id=27279 is about apps linked against this dll such that they won't even start. Regards, Jörg Höhle

Oct. 30, 2012

Re: [PATCH 4/5] include: Don't add d3d8 LP* interface typedefs for __WINESRC__.

by Jacek Caban

On 10/30/12 12:01, Alexandre Julliard wrote: > Henri Verbeet <hverbeet(a)gmail.com> writes: > >> We can certainly generate some more d3d headers from idl, and we >> probably should anyway, but I'm not sure how that's going to make the >> mechanism any more generic. I suppose we could do something like >> "DECL_WINELIB_TYPE(struct IDirect3D8, *LPDIRECT3D8);", if that's much >> better. > That would be better for headers written by hand, yes. But I'm not sure > we want to add that at this point, since the goal should be to generate > all interfaces from idl. It's unrelated to original problem here, but please keep in mind that other work on widl should also be done before switching to IDL files. Currently IDL-generated files are not really compatible with MSVC non-IDL-generated COM headers because widl adds some stuff like default includes. We probably need some way (command like arg or some tricky argument in IDL file) to instruct widl to generate pure headers. This may not be a big deal for Wine (and we ignored it for dwrite.h), but that's more important for mingw-w64 and they use our d3dx* headers (among others). Jacek

Oct. 30, 2012