September 2010 - Wine-Devel

Re: shell32: Import ole32 directly
by Alexandre Julliard Sept. 3, 2010

Sept. 3, 2010

André Hentschel <nerv(a)dawncrow.de> writes: > ole32 function CoTaskMemAlloc is already used in DLL_PROCESS_ATTACH > (SIC_Initialize -> SIC_IconAppend -> SHAlloc -> CoTaskMemAlloc) A better fix would be to avoid initializing unneeded stuff in process attach. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: Add tests for SetHandleCount + make tests pass for winversions >WINNT
by Alexandre Julliard Sept. 3, 2010

Sept. 3, 2010

Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> writes: > @@ -1192,7 +1192,10 @@ BOOL WINAPI UnlockFileEx( HANDLE hFile, DWORD reserved, DWORD count_low, DWORD c > */ > UINT WINAPI SetHandleCount( UINT count ) > { > - return min( 256, count ); > + if (GetVersion() & 0x80000000) > + return min( 0x100, count ); > + else > + return min( 0xffffffff, count ); It's pretty unlikely that count would be larger than 0xffffffff. Also I don't think we need a version check. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: add a stub for GetThreadUILanguage
by Dmitry Timoshkov Sept. 3, 2010

Sept. 3, 2010

Austin English <austinenglish(a)gmail.com> wrote: > +LANGID WINAPI GetThreadUILanguage( void ) > +{ > + FIXME(": stub, returning LOCALE_USER_DEFAULT.\n"); > + return LOCALE_USER_DEFAULT; > +} The API is supposed to return a language id, not the locale id. Calling GetUserDefaultUILanguage() may be what you need. -- Dmitry.

1 0

banning spammer from the forum
by Rosanne DiMesio Sept. 3, 2010

Sept. 3, 2010

Can someone with forum admin rights please ban user Eden1023? I've had to delete multiple spam posts by this user every day for the past few days. -- Rosanne DiMesio <dimesio(a)earthlink.net>

4 5

Re: [2/3] dsound/tests: Add IEEE float buffer tests
by testbot＠testbot.winehq.org Sept. 2, 2010

Sept. 2, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4950 Your paranoid android. === W98SE (32 bit dsound) === dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D407F4 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D554 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D56C 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D624 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D614 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D614 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D5F4 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D630 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D60C 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D628 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D628 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D628 00000000

1 0

RFC: Compiling as 16 bit
by Morten Rønne Sept. 2, 2010

Sept. 2, 2010

This is related to the creation of the DOS test programs for which I have sent another mail. But this is a more generic question relating to the fact that openwatcom is a 16 bit compiler while gcc (of course) is a 32 bit compiler. Currently this have lead me to drop the inclusion of the files windef.h and winbase.h, because the definitions created aren't of the correct size (int is 16 bit, not 32 bit and so on). I am looking for a way to change windef.h so that it will create the correct base types for both 16 and 32 bit compile. Openwatcom defines the symbol __I86__ while compiling for 16 bit, is it acceptable that I use that to create 16 bit types? It seems that _MSC_VER will change a few cases of int to long, but far from enough. Is _MSC_VER intended to be a 16 bit compile flag? Or should I use something else more wine like (e.g. __WINE_16BIT_COMPILE). Also compiling 16 bit give some errors in other include files (after I have defined proper sizes for the 16 bit compile) ../../../include/winnt.h(3529): Error! E1040: Field width too large #ifdef BITFIELDS_BIGENDIAN unsigned NameIsString:1; unsigned NameOffset:31; #else unsigned NameOffset:31; unsigned NameIsString:1; #endif As it can be seen the include file uses unsigned directly and not a type like DWORD or ULONG that would be a "safe" 32 bit. Would it be acceptable to change this and others to a "proper" type which I know to be size safe? Best Regards Morten Rønne

2 4

Re: [1/3] dsound: Add support for 32-bit IEEE float buffers
by Chris Robinson Sept. 2, 2010

Sept. 2, 2010

On Thursday, September 02, 2010 1:38:29 pm Owen Rudge wrote: > These patches add support to DirectSound that allow the conversion of > 32-bit IEEE float audio buffers to PCM. Some games (e.g., Call of Duty > 5) output their audio in this format, and media players such as > foobar2000 have support for it too. You'll probably want to make sure the float values are clamped between -1 and +1 before converting, otherwise they'll wrap and cause bad static noise.

1 0

Re: RFC: test of 16 bit wine (DOS)
by Dan Kegel Sept. 2, 2010

Sept. 2, 2010

On Thu, Sep 2, 2010 at 7:50 PM, Morten Rønne <morten.roenne(a)tdcadsl.dk> wrote: >> Oh, right, win16test's Makefile and probably its test.h are kind of >> simpleminded. >> You probably want to have just one 16 bit test app per dll. >> Hopefully the test cases from win16test will be a useful starting point >> aside from their wimpy build system. > > I would like to avoid the dll part as DOS doesn't know about that and > "simply" run the program directly with tools/run_test. You might have misunderstood. By DLL I just meant the part of Wine that you're testing. In the case of DOS, the tests should probably go in krnl386.exe16/tests. > I will make some tests to see what I can fit into the test system, so it > works the same way other tests do, but as a "standalone" test. Good. That's exactly what I did with win16test. The missing part is integrating into the Wine build sytem. - Dan

1 0

re: RFC: test of 16 bit wine (DOS)
by Dan Kegel Sept. 2, 2010

Sept. 2, 2010

Morten Rønne wrote: > I have been working on creating tests for the 16 bit implementation of wine Great! Have you seen http://code.google.com/p/win16test/ ? That's for Win16 binaries, not DOS, but it might have some similarities. For instance, it also uses openwatcom. I had trouble back then getting the Linux version of openwatcom to produce win16 binaries, so I used 'winetricks openwatcom' to install the windows version. - Dan

2 5

Please report mcicda (CDROM audio) test results
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 2, 2010

Sept. 2, 2010

Hi, Wine's testbt job #4280 http://testbot.winehq.org/JobDetails.pl?Key=4280 contains both a patch and a binary for new MCICDA=MCI CD-audio tests. It already contains most of what I want in the initial release but would benefit from testing on a broad range of native MS systems. Please invoke it as: mcicda_test.exe mcicda (it generates many failures on Wine but I already wrote several patches to fix them.) Some failures are still possible as there are a few rough edges, e.g. mcicda.c:222: Test failed: info upc: 0=NOERROR mcicda.c:322: Test failed: PLAY data to 00291d10: MCIERR_OUTOFRANGE mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped. It skips tests if - there's no disk in drive; - there are no audio tracks; Untested: blank RW disk Questions: - Is this patch right in mcicda/tests/ or should it be part of winmm/tests/? - Which kind of tests should I restrict to WINETEST_INTERACTIVE mode only? People may start to complain in the near future that running the Wine testsuite starts spinning their CD-ROM and even play music. (like somebody observed that the MIDI testsuite plays a few notes). Thank you for your contributions, Jörg Höhle

5 12

Re: winmm/tests: Share common function dbg_mcierr.
by testbot＠testbot.winehq.org Sept. 2, 2010

Sept. 2, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4939 Your paranoid android. === W98SE (32 bit mci) === mci.c:613: Test failed: Expect message 0001 from play to 250 wait notify mci.c:620: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close

1 0

Our wiki disallows chinese text?
by Dan Kegel Sept. 2, 2010

Sept. 2, 2010

The chap I mentioned earlier is starting off by trying to translate wiki pages into Chinese. http://wiki.winehq.org/FrontPage now has a Chinese entry at the bottom, but there's a hitch: when I try putting a bit of chinese text into http://wiki.winehq.org/Chinese the wiki refuses to save it, saying Sorry, can not save page because "葡" is not allowed in this wiki Is that because we don't have anyone who can monitor the wiki for chinese spam? How can we allow creation of Chinese pages? - Dan

3 2

Re: [PATCH 5/6] winmm/tests: MCI_STATUS returns DWORD_PTR, unlike other commands.
by testbot＠testbot.winehq.org Sept. 2, 2010

Sept. 2, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4901 Your paranoid android. === W98SE (32 bit mci) === mci.c:714: Test failed: Expect message 0001 from play to 250 wait notify mci.c:721: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close mci.c:782: Test failed: not enough time elapsed 58ms mci.c:838: Test failed: mci status position: 58

2 1

Mono integration, and when do we ship Mono with Wine?
by Vincent Povirk Sept. 2, 2010

Sept. 2, 2010

Dan Kegel recently listed this as a possible 1.4 goal: > Mono integration similar to the current Gecko integration He may have meant one or both of the following things: 1. A more-or-less complete mscoree.dll that works based on the mono embedding api, as well as replacements for all the utilities that ship with .NET. 2. A wine-mono package similar to the current wine-gecko package to be installed automatically in new prefixes. I am making very slow progress with 1. I believe the current major shortcomings are functions that create COM wrappers for managed objects (ClrCreateManagedInstance and DllGetClassObject) and functions that search for and load different .NET versions (I believe these will be needed so that the managed objects we create will load and function properly). Mono already provides COM wrappers, so all we have to do is create the objects and pass COM wrappers to applications. I'm making this judgment based on the limited pool of mscoree bugs in the Wine bugzilla. I wish more people would file bugs when Mono doesn't work. I figure 2 can't be very technically difficult in and of itself, but when will we be ready to do that? What are the requirements? Do we want to go the "offer to download and install on first use" route first, and if so when will we be ready for that? Do those functions I mentioned earlier have to actually work first? The one hard requirement I have and have not met is that a working mono package can be built by me using only free software and that I can explain the build process to other people. I can do this for the core runtime and libraries, but I cannot do this for the gluezilla dependency. This gluezilla thing is sort of explained here: http://www.mono-project.com/WebBrowser Basically, .NET provides a web browser control, which Mono implements based on Gecko (or, optionally, WebKit). The official installer of Mono for Windows, which is what anyone who uses Mono in Wine uses, ships with Mozilla. It also ships with gluezilla, which is a C++ library that helps the managed code link Gecko. I don't think it'd be acceptable to leave out WebBrowser support. I am not currently able to create a Windows build of gluezilla or gecko using only free software. As I understand it, the official Windows build relies on Visual Studio. I do not know whether it's feasible for gluezilla to link to wine gecko, so that we don't have to install two versions of gecko. I also know that shipping gluezilla and gecko on Windows is wrong. Mono's wiki tells me that it's possible in .NET to access the underlying IE embedding objects through the winforms api, and those only exist if we're embedding IE. So the correct approach is to embed IE (in this case, Wine's IE replacement) by writing another WebBrowser backend. I don't know how hard that is. Maybe it'd make a good Summer of Code project? So, does anyone have other requirements, or thoughts on resolving the WebBrowser requirement?

5 4

Re: [5/5] msi/test: Add tests for 64-bit properties.
by testbot＠testbot.winehq.org Sept. 2, 2010

Sept. 2, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4928 Your paranoid android. === W7PROX64 (64 bit package) === package.c:8387: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8398: Test failed: Expected "C:\winetest\", got "" package.c:8409: Test failed: Expected "C:\winetest\", got "" package.c:8459: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8470: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8479: Test failed: Expected "C:\", got "" package.c:8485: Test failed: Expected "C:\winetest\", got "" package.c:8506: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8515: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

Re: [PATCH 3/3] include: Add MCI_INTEGER64 and MCI_INTEGER3264 mci types. (try 2)
by Jacek Caban Sept. 2, 2010

Sept. 2, 2010

Hi Octavian, On 9/1/10 7:45 PM, Octavian Voicu wrote: > MCI_INTEGER64 is only defined for _WIN64 in DDK. > > MCI_INTEGER3264 is wine specific and will be needed because MCI_STATUS > return type is MCI_INTEGER64 in 64-bit winmm.dll, and MCI_INTEGER > in 32-bit winmm.dll. That's not a reason to add Wine-specific defines in public header. Jacek

3 3

Re: msvcrt:string Fix codepage table 1361 (Korean Johab) [try2]
by Alexandre Julliard Sept. 2, 2010

Sept. 2, 2010

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -1563,8 +1564,11 @@ sub HANDLE_FILE(@) > } > printf OUTPUT "#include \"wine/unicode.h\"\n\n"; > > + if( $codepage == 1361 ) { @lb_ranges = ( 0x81, 0xd3, 0xd8, 0xde, 0xe0, 0xf9 ); } > + else { @lb_ranges = get_lb_ranges(); } There's no reason to hardcode the whole thing. If some lead bytes aren't detected properly you can add just those. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 6/6] winmm/tests: Add MCI parser tests.
by testbot＠testbot.winehq.org Sept. 1, 2010

Sept. 1, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4902 Your paranoid android. === W98SE (32 bit mci) === mci.c:926: Test failed: mci status position: 128

1 0

Re: [PATCH 2/3] winmm: Replace command ids with symbolic constants in mci command resources.
by Octavian Voicu Sept. 1, 2010

Sept. 1, 2010

In order to prevent copy-paste errors, the changes were generated using the following script, executed from git root (there are two very long lines, might not work if they're wrapped): for i in MCI_OPEN MCI_CLOSE MCI_ESCAPE MCI_PLAY MCI_SEEK MCI_STOP MCI_PAUSE MCI_INFO MCI_GETDEVCAPS MCI_SPIN MCI_SET MCI_STEP MCI_RECORD MCI_SYSINFO MCI_BREAK MCI_SOUND MCI_SAVE MCI_STATUS MCI_CUE MCI_REALIZE MCI_WINDOW MCI_PUT MCI_WHERE MCI_FREEZE MCI_UNFREEZE MCI_LOAD MCI_CUT MCI_COPY MCI_PASTE MCI_UPDATE MCI_RESUME MCI_DELETE; do j=`egrep "^#define $i\\W" include/mmsystem.h | awk '{print $3}' | sed 's/0x0/0x00000/g'`; k=`echo $i | sed 's/MCI_//g'`; sed -i "s/${j}L, MCI_COMMAND_HEAD,/$i, 0, MCI_COMMAND_HEAD,/ig" dlls/mciavi32/mciavi_res.rc dlls/mciqtz32/mciavi_res.rc dlls/winmm/winmm_res.rc; done for i in MCI_CAPTURE MCI_MONITOR MCI_RESERVE MCI_SETAUDIO MCI_SIGNAL MCI_SETVIDEO MCI_QUALITY MCI_LIST MCI_UNDO MCI_CONFIGURE MCI_RESTORE; do j=`egrep "^#define $i\\W" include/digitalv.h | awk '{print $3}' | sed 's/0x0/0x00000/g'`; k=`echo $i | sed 's/MCI_//g'`; sed -i "s/${j}L, MCI_COMMAND_HEAD,/$i, 0, MCI_COMMAND_HEAD,/ig" dlls/mciavi32/mciavi_res.rc dlls/mciqtz32/mciavi_res.rc dlls/winmm/winmm_res.rc; done

1 0

Re: d3dx9: Implement D3DXFVFFromDeclarator. (try 2)
by Henri Verbeet Sept. 1, 2010

Sept. 1, 2010

On 1 September 2010 02:40, Misha Koshelev <misha680(a)gmail.com> wrote: > + while (texture <= 8) What is the "texture == 8" case for? Also, it seems to me FVFs require texcoords to be assigned to consecutive texture units.

2 1

Re: [PATCH 4/6] winmm/tests: Add a few Open/Close MCI tests.
by testbot＠testbot.winehq.org Sept. 1, 2010

Sept. 1, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4900 Your paranoid android. === W98SE (32 bit mci) === mci.c:637: Test failed: Expect message 0001 from play to 250 wait notify mci.c:644: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close

1 0

Re: [PATCH 2/6] winmm: Close MCI device after immediate auto-open commands.
by testbot＠testbot.winehq.org Sept. 1, 2010

Sept. 1, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4899 Your paranoid android. === W98SE (32 bit mci) === mci.c:613: Test failed: Expect message 0001 from play to 250 wait notify mci.c:620: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close

1 0

Re: [PATCH 1/6] winmm: MCI open always creates an alias for subsequent commands.
by testbot＠testbot.winehq.org Sept. 1, 2010

Sept. 1, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4898 Your paranoid android. === W98SE (32 bit mci) === mci.c:681: Test failed: not enough time elapsed 58ms mci.c:737: Test failed: mci status position: 58

1 0

Re: [PATCH] wined3d: Add missing ckey, fx, and pal directdraw caps.
by Stefan Dösinger Sept. 1, 2010

Sept. 1, 2010

Looks OK to me. (unless there are whitespace issues which I can't see in my current mail client) Am 01.09.2010 um 06:44 schrieb Octavian Voicu: > Fixes regression described in bug 24226. > --- > dlls/wined3d/directx.c | 7 ++++++- > 1 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 01b4e46..9e50f78 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -4259,7 +4259,7 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > int ps_selected_mode; > struct shader_caps shader_caps; > struct fragment_caps fragment_caps; > - DWORD ckey_caps, blit_caps, fx_caps; > + DWORD ckey_caps, blit_caps, fx_caps, pal_caps; > > TRACE_(d3d_caps)("(%p)->(Adptr:%d, DevType: %x, pCaps: %p)\n", This, Adapter, DeviceType, pCaps); > > @@ -4786,6 +4786,8 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > WINEDDCAPS_COLORKEY | > WINEDDCAPS_COLORKEYHWASSIST | > WINEDDCAPS_ALIGNBOUNDARYSRC; > + pal_caps = WINEDDPCAPS_8BIT | > + WINEDDPCAPS_PRIMARYSURFACE; > > /* Fill the ddraw caps structure */ > pCaps->DirectDrawCaps.Caps = WINEDDCAPS_GDI | > @@ -4796,6 +4798,9 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > WINEDDCAPS2_PRIMARYGAMMA | > WINEDDCAPS2_WIDESURFACES | > WINEDDCAPS2_CANRENDERWINDOWED; > + pCaps->DirectDrawCaps.CKeyCaps = ckey_caps; > + pCaps->DirectDrawCaps.FXCaps = fx_caps; > + pCaps->DirectDrawCaps.PalCaps = pal_caps; > pCaps->DirectDrawCaps.SVBCaps = blit_caps; > pCaps->DirectDrawCaps.SVBCKeyCaps = ckey_caps; > pCaps->DirectDrawCaps.SVBFXCaps = fx_caps; > -- > 1.7.0.4 > > >

1 0

Re: shell32: add stubbed SHGetKnownFolderPath
by Alexandre Julliard Sept. 1, 2010

Sept. 1, 2010

Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> writes: > @@ -111,3 +111,8 @@ typedef [v1_enum] enum tagSHCOLSTATE > } SHCOLSTATE; > > typedef DWORD SHCOLSTATEF; > + > +typedef GUID KNOWNFOLDERID; > + > +typedef KNOWNFOLDERID *REFKNOWNFOLDERID; This doesn't match the PSDK definitions. -- Alexandre Julliard julliard(a)winehq.org

1 0