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

Re: d3dx9_36: Equality between floats is too strict.
by Marvin May 12, 2012

May 12, 2012

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=18337 Your paranoid android. === WXPPROSP3 (32 bit math) === math.c:2343: Test failed: 0-0: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 1-1: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 2-4: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 3-9: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 4-16: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 5-25: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 6-36: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 7-49: D3DXSHAdd() failed, got 0.000000, expected 0.0 === W2K3R2SESP2 (32 bit math) === math.c:2343: Test failed: 0-0: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 1-1: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 2-4: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 3-9: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 4-16: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 5-25: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 6-36: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 7-49: D3DXSHAdd() failed, got 0.000000, expected 0.0 === WVISTAADM (32 bit math) === math.c:2343: Test failed: 0-0: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 1-1: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 2-4: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 3-9: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 4-16: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 5-25: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 6-36: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 7-49: D3DXSHAdd() failed, got 0.000000, expected 0.0 === W2K8SE (32 bit math) === math.c:2343: Test failed: 0-0: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 1-1: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 2-4: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 3-9: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 4-16: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 5-25: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 6-36: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 7-49: D3DXSHAdd() failed, got 0.000000, expected 0.0 === W7PRO (32 bit math) === math.c:2343: Test failed: 0-0: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 1-1: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 2-4: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 3-9: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 4-16: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 5-25: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 6-36: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 7-49: D3DXSHAdd() failed, got 0.000000, expected 0.0 === W7PROX64 (32 bit math) === math.c:2343: Test failed: 0-0: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 1-1: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 2-4: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 3-9: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 4-16: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 5-25: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 6-36: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 7-49: D3DXSHAdd() failed, got 0.000000, expected 0.0 === TEST64_W7SP1 (32 bit math) === math.c:2343: Test failed: 0-0: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 1-1: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 2-4: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 3-9: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 4-16: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 5-25: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 6-36: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 7-49: D3DXSHAdd() failed, got 0.000000, expected 0.0 === W7PROX64 (64 bit math) === math.c:2343: Test failed: 0-0: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 1-1: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 2-4: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 3-9: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 4-16: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 5-25: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 6-36: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 7-49: D3DXSHAdd() failed, got 0.000000, expected 0.0 === TEST64_W7SP1 (64 bit math) === math.c:2343: Test failed: 0-0: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 1-1: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 2-4: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 3-9: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 4-16: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 5-25: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 6-36: D3DXSHAdd() failed, got 0.000000, expected 0.0 math.c:2343: Test failed: 7-49: D3DXSHAdd() failed, got 0.000000, expected 0.0

1 0

Re: [2/8] d3dx9: Check the size of a DDS file in D3DXGetImageInfoFromFileInMemory.
by Stefan Dösinger May 12, 2012

May 12, 2012

Am Mittwoch, 9. Mai 2012, 23:32:05 schrieb Józef Kucia: > + *pitch = width * format_desc->bytes_per_pixel; > + *size = *pitch * height; Usually surface pitches are either 4 or 8 byte aligned(depending on the API and pool). I recommend to write some tests for this. The most likely problematic formats are D3DFMT_P8, any 16 bit format like R5G6B5 and 24 bit R8G8B8. Maybe you're supposed to honor the pitch_or_linear_size member of the DDSURFACEDESC.

3 5

Re: [PATCH 1/3] user32: Added GetMenuBarInfo implementation
by Alexandre Julliard May 12, 2012

May 12, 2012

Piotr Caban <piotr(a)codeweavers.com> writes: > + __TRY > + { > + mbi.cbSize = pmbi->cbSize; > + if (mbi.cbSize == sizeof(MENUBARINFO)) > + memcpy(pmbi, &mbi, sizeof(MENUBARINFO)); > + } > + __EXCEPT_PAGE_FAULT > + { > + SetLastError(ERROR_NOACCESS); > + return FALSE; > + } > + __ENDTRY Do you really have an app that requires an exception handler? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [2/5] d3dx9: Forward D3DXSaveSurfaceToFileA to D3DXSaveSurfaceToFileW.
by Józef Kucia May 11, 2012

May 11, 2012

On Wed, May 2, 2012 at 2:55 PM, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > --- > dlls/d3dx9_36/surface.c | 24 ++++++++++++++++++++---- > 1 files changed, 20 insertions(+), 4 deletions(-) > > diff --git a/dlls/d3dx9_36/surface.c b/dlls/d3dx9_36/surface.c > index 44d4e06..70627fd 100644 > --- a/dlls/d3dx9_36/surface.c > +++ b/dlls/d3dx9_36/surface.c > @@ -1364,11 +1364,27 @@ HRESULT WINAPI D3DXLoadSurfaceFromSurface(LPDIRECT3DSURFACE9 pDestSurface, > } > > > -HRESULT WINAPI D3DXSaveSurfaceToFileA(LPCSTR pDestFile, D3DXIMAGE_FILEFORMAT DestFormat, > - LPDIRECT3DSURFACE9 pSrcSurface, const PALETTEENTRY* pSrcPalette, const RECT* pSrcRect) > +HRESULT WINAPI D3DXSaveSurfaceToFileA(LPCSTR dst_filename, D3DXIMAGE_FILEFORMAT file_format, > + IDirect3DSurface9 *src_surface, const PALETTEENTRY *src_palette, const RECT *src_rect) > { > - FIXME("(%p, %d, %p, %p, %p): stub\n", pDestFile, DestFormat, pSrcSurface, pSrcPalette, pSrcRect); > - return D3DERR_INVALIDCALL; > + int len; > + LPWSTR filename; > + HRESULT hr; > + > + TRACE("(%s, %d, %p, %p, %p): relay\n", > + wine_dbgstr_a(dst_filename), file_format, src_surface, src_palette, src_rect); > + > + if (!dst_filename) return D3DERR_INVALIDCALL; > + > + len = MultiByteToWideChar(CP_ACP, 0, dst_filename, -1, NULL, 0); > + filename = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len * sizeof(WCHAR)); > + if (!filename) return E_OUTOFMEMORY; > + MultiByteToWideChar(CP_ACP, 0, dst_filename, -1, filename, len); > + > + hr = D3DXSaveSurfaceToFileW(filename, file_format, src_surface, src_palette, src_rect); > + > + HeapFree(GetProcessHeap(), 0, filename); > + return hr; > } > > HRESULT WINAPI D3DXSaveSurfaceToFileW(LPCWSTR pDestFile, D3DXIMAGE_FILEFORMAT DestFormat, > -- > 1.7.8.6 > This mail is the lost mail from 2nd May. Please ignore it.

1 0

Re: [PATCH 1/2 resend] mshtml.idl: Added DispHTMLHistory declaration
by Jacek Caban May 11, 2012

May 11, 2012

There must have been some problem with mail servers. These mails were sent last week and should replace already committed patches. The fix from try 2 (fixing tests on old IEs) is also already committed. Cheers, Jacek

1 0

Re: [1/8] d3dx9: Add missing pixel formats.
by Matteo Bruni May 11, 2012

May 11, 2012

2012/5/9 Józef Kucia <joseph.kucia(a)gmail.com>: > diff --git a/dlls/d3dx9_36/util.c b/dlls/d3dx9_36/util.c > index 4dbf44c..ad8a6ea 100644 > --- a/dlls/d3dx9_36/util.c > +++ b/dlls/d3dx9_36/util.c > @@ -62,6 +62,7 @@ static const PixelFormatDesc formats[] = > {D3DFMT_G16R16, {0, 16, 16, 0}, { 0, 0, 16, 0}, 4, 1, 1, 4, FORMAT_ARGB, NULL, NULL }, > {D3DFMT_A8, {8, 0, 0, 0}, { 0, 0, 0, 0}, 1, 1, 1, 1, FORMAT_ARGB, NULL, NULL }, > {D3DFMT_A8L8, {8, 8, 0, 0}, { 8, 0, 0, 0}, 2, 1, 1, 2, FORMAT_ARGB, la_from_rgba, la_to_rgba}, > + {D3DFMT_A4L4, {4, 4, 0, 0}, { 4, 0, 0, 0}, 1, 1, 1, 1, FORMAT_ARGB, la_from_rgba, la_to_rgba}, > {D3DFMT_DXT1, {0, 0, 0, 0}, { 0, 0, 0, 0}, 1, 4, 4, 8, FORMAT_ARGB, NULL, NULL }, > {D3DFMT_DXT2, {0, 0, 0, 0}, { 0, 0, 0, 0}, 1, 4, 4, 16, FORMAT_ARGB, NULL, NULL }, > {D3DFMT_DXT3, {0, 0, 0, 0}, { 0, 0, 0, 0}, 1, 4, 4, 16, FORMAT_ARGB, NULL, NULL }, I guess it would make sense to add all the new pixel formats to the table, assuming it doesn't break the tests or other stuff.

3 2

Re: [PATCH 3/4] dmusic: COM cleanup of IReferenceClock.
by Nikolay Sivov May 11, 2012

May 11, 2012

On 5/11/2012 09:19, Christian Costa wrote: > > diff --git a/dlls/dmusic/dmusic_private.h b/dlls/dmusic/dmusic_private.h > index 73a05d4..96334c9 100644 > --- a/dlls/dmusic/dmusic_private.h > +++ b/dlls/dmusic/dmusic_private.h > @@ -167,13 +167,14 @@ extern HRESULT WINAPI DMUSIC_CreateDMSynthPort(REFIID riid, LPVOID *ppobj, LPUNK > * IReferenceClockImpl implementation structure > */ > struct IReferenceClockImpl { > - /* IUnknown fields */ > - const IReferenceClockVtbl *lpVtbl; > - LONG ref; > + /* IUnknown fields */ > + IReferenceClock IReferenceClock_iface; > + const IReferenceClockVtbl *lpVtbl; You forgot to remove that, right? > + LONG ref; > > >

2 1

Re: Vincent Povirk : windowscodecs: Add wrapper functions for IWICPalette methods.
by Charles Davis May 11, 2012

May 11, 2012

On May 10, 2012, at 1:17 PM, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 2fc7cdc93f6dc8ed67498b74193423c44e5bb770 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=2fc7cdc93f6dc8ed67498b741… > > Author: Vincent Povirk <vincent(a)codeweavers.com> > Date: Tue May 8 10:49:22 2012 -0500 > > windowscodecs: Add wrapper functions for IWICPalette methods. I have to say, these patches all seem really mechanical. Correct me if I'm wrong, but I think MIDL has an option to generate the proxy wrappers automatically. Even if it doesn't, I'm sure this would be a good feature to add to widl (if we don't already have it) so we don't have to laboriously write and maintain each and every one of the proxy wrappers. Chip

2 1

Re: [PATCH 2/2 try 2] mshtml: Added IHTMLWindow2::get_history implementation
by Marvin May 10, 2012

May 10, 2012

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=18319 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

GSoC Joystick Configuration Tools
by Lucas Zawacki May 10, 2012

May 10, 2012

Hello all, I'll use this thread to post information and ask questions regarding my GSoC project. First there's a wiki which aggregates some information and lists tasks I'm working on: http://lfzawacki.heroku.com/wine/published/HomePage Then there's a github repo: https://github.com/lfzawacki/wine-joysticks In the repository you'll find the different tools I'll be implementing. They can be easily built and tested, even before they make it into wine. At the moment there's an intial version of the command line joystick tester. This tool is useful for listing connected joysticks, testing if they work correctly in wine, testing axis remapping, watching for dinput trace messages, etc... It's also the basis for the joystick testing GUI. I'll start cleaning up, splitting this code and commiting it to wine next week. For now I'll make a similar tool to this one that tests force feedback. I'll try to make it in the style of the Linux fftest program, but using the dinput interfaces so that a user can test the differences. Cheers, Lucas

2 2

Re: [5/8] d3dx9: Add DDS support in D3DXCreateTextureFromFile functions.
by Józef Kucia May 10, 2012

May 10, 2012

On Wed, May 9, 2012 at 11:32 PM, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > diff --git a/dlls/d3dx9_36/tests/surface.c b/dlls/d3dx9_36/tests/surface.c > index ab56593..3d5a50f 100644 > --- a/dlls/d3dx9_36/tests/surface.c > +++ b/dlls/d3dx9_36/tests/surface.c > @@ -917,6 +917,20 @@ static void test_D3DXCreateVolumeTexture(IDirect3DDevice9 *device) > } > } > > +static void test_D3DXCreateTextureFromFileInMemory(IDirect3DDevice9 *device) > +{ > + HRESULT hr; > + IDirect3DTexture9 *texture; > + > + hr = D3DXCreateTextureFromFileInMemory(device, dds_16bit, sizeof(dds_16bit), &texture); > + ok(hr == D3D_OK, "D3DCreateTextureFromFileInMemory returned %#x, expected %#x\n", hr, D3D_OK); > + if (SUCCEEDED(hr)) IDirect3DTexture9_Release(texture); > + > + hr = D3DXCreateTextureFromFileInMemory(device, dds_24bit, sizeof(dds_24bit), &texture); > + ok(hr == D3D_OK, "D3DXCreateTextureFromFileInMemory returned %#x, expected %#x\n", hr, D3D_OK); > + if (SUCCEEDED(hr)) IDirect3DTexture9_Release(texture); > +} > + I noticed that I put more and more texture functions tests in tests/surface.c, because these tests needs the dds files which are in tests/surface.c. I wonder if it would be better to copy needed dds files to tests/texture.c and move texture function tests to their proper place. I think the dds files could be used to tests other texture functions, e.g. D3DXCreateTextureFromFileInMemoryEx doesn't seem to have any tests.

2 1

Re: [1/5] gdiplus: Retrive LOGFONT from a GpFont using GdipGetLogFontW instead of accessing it directly.
by Alexandre Julliard May 10, 2012

May 10, 2012

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -4926,12 +4925,15 @@ GpStatus WINGDIPAPI GdipMeasureCharacterRanges(GpGraphics* graphics, > TRACE("(%p %s %d %p %s %p %d %p)\n", graphics, debugstr_w(string), > length, font, debugstr_rectf(layoutRect), stringFormat, regionCount, regions); > > - if (!(graphics && string && font && layoutRect && stringFormat && regions)) > + if (!graphics || !string || !font || !layoutRect || !stringFormat || !regions) > return InvalidParameter; Please avoid mixing that sort of gratuitous change with the real changes. > + stat = GdipGetLogFontW((GpFont *)font, graphics, &lfw); > + if (stat != Ok) return stat; I'm not sure it's an improvement, since you need to add these ugly casts. You should find a way that doesn't require that. -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: kernel32: Correct WideCharToMultiByte and MultiByteToWideChar error codes and conditions (try 4)
by Juan Lang May 10, 2012

May 10, 2012

Hi Alex, first, thanks for taking the time to respond to feedback. Showing responsiveness helps a great deal. Next, on your patch: I'm trying to help you get this committed, so this is meant to be constructive feedback. +static void test_WideCharToMultiByte_error(UINT page, DWORD flags, LPCWSTR src, + INT srclen, LPSTR dst, INT dstlen, + LPCSTR defchar, BOOL* used, + const char* test_description, + DWORD expected_error) +{ + SetLastError(ERROR_SUCCESS); + WideCharToMultiByte(page, flags, src, srclen, dst, dstlen, defchar, used); + ok(GetLastError() == expected_error, + "codepage %i, %s, expected error %i got error %i\n", page, + test_description, expected_error, GetLastError()); +} + +static void test_MultiByteToWideChar_error(UINT page, DWORD flags, LPCSTR src, + INT srclen, LPWSTR dst, INT dstlen, + const char* test_description, + DWORD expected_error) +{ + SetLastError(ERROR_SUCCESS); + MultiByteToWideChar(page, flags, src, srclen, dst, dstlen); + ok(GetLastError() == expected_error, + "codepage %i, %s, expected error %i got error %i\n", page, + test_description, expected_error, GetLastError()); +} These helpers don't really gain you anything here, there's really not enough code to be worth using helpers. Please just copy/paste the changes everyplace you're currently using them. Also, a common convention we use is to set last error to 0xdeadbeef prior to a test we expect to set last error on failure. Thanks, --Juan

2 1

Re: [PATCH] winmm: Don't call MMDevAPI during process exit
by Alexandre Julliard May 10, 2012

May 10, 2012

Andrew Eikum <aeikum(a)codeweavers.com> writes: > --- > This fixes bug 30631, introduced by > 31291cdc6ccc4c172ccf86f383c6a90f31a50ba1. > > In addition to safely exiting on process exit, we do much more > thorough cleanup on process detach. There shouldn't be any reason to do cleanup on process exit (and you can't really do anything reliably at that point anyway). -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [5/8] d3dx9: Add DDS support in D3DXCreateTextureFromFile functions.
by Matteo Bruni May 10, 2012

May 10, 2012

2012/5/9 Józef Kucia <joseph.kucia(a)gmail.com>: > --- > +HRESULT load_texture_from_dds(IDirect3DTexture9 *texture, const void *src_data, UINT srd_data_size, > + const PALETTEENTRY *palette, DWORD filter, D3DCOLOR color_key, const D3DXIMAGE_INFO *src_info) DECLSPEC_HIDDEN; ... > +HRESULT load_texture_from_dds(IDirect3DTexture9 *texture, const void *src_data, UINT srd_data_size, > + const PALETTEENTRY *palette, DWORD filter, D3DCOLOR color_key, const D3DXIMAGE_INFO *src_info) I guess that was meant to be called "src_data_size". More to the point, anyway, you're not using that value right now, you should probably add a check against it or remove the parameter altogether.

2 1

Re: [4/8] d3dx9: Implement D3DXCreateCubeTextureFromFileInMemoryEx.
by Matteo Bruni May 10, 2012

May 10, 2012

2012/5/9 Józef Kucia <joseph.kucia(a)gmail.com>: > + mip_levels = min(src_info->MipLevels, IDirect3DCubeTexture9_GetLevelCount(cube_texture)); > + for (face = D3DCUBEMAP_FACE_POSITIVE_X; face <= D3DCUBEMAP_FACE_NEGATIVE_Z; face++) > + { > + size = src_info->Width; > + for (mip_level = 0; mip_level < mip_levels; mip_level++) > + { > + hr = calculate_dds_surface_size(src_info, size, size, &src_pitch, &mip_level_size); > + if (FAILED(hr)) return hr; > + > + SetRect(&src_rect, 0, 0, size, size); > + > + IDirect3DCubeTexture9_GetCubeMapSurface(cube_texture, face, mip_level, &surface); > + hr = D3DXLoadSurfaceFromMemory(surface, palette, NULL, pixels, src_info->Format, src_pitch, > + NULL, &src_rect, filter, color_key); > + IDirect3DSurface9_Release(surface); > + if (FAILED(hr)) return hr; > + > + pixels += mip_level_size; > + size = max(1, size / 2); > + } > + > + /* if texture has fewer mip levels than DDS file, skip excessive mip levels */ > + while (mip_level < src_info->MipLevels) > + { > + calculate_dds_surface_size(src_info, size, size, &src_pitch, &mip_level_size); > + pixels += mip_level_size; > + size = max(1, size / 2); > + mip_level++; > + } > + } Really a nitpick, you could merge the "while" into the "for" loop above. > + if ((caps.Caps2 & D3DCAPS2_DYNAMICTEXTURES) && (pool != D3DPOOL_DEFAULT) && (usage != D3DUSAGE_DYNAMIC)) > + { > + hr = D3DXCreateCubeTexture(device, size, mip_levels, usage, format, pool, &tex); > + buftex = NULL; > + } > + else > + { > + hr = D3DXCreateCubeTexture(device, size, mip_levels, usage, format, D3DPOOL_SYSTEMMEM, &buftex); > + tex = buftex; > + } The "if" condition doesn't look correct to me, since e.g. you don't need a temporary texture if pool == D3DPOOL_DEFAULT and usage == D3DUSAGE_DYNAMIC.

2 1

Re: [2/8] d3dx9: Check the size of a DDS file in D3DXGetImageInfoFromFileInMemory.
by Matteo Bruni May 10, 2012

May 10, 2012

2012/5/9 Józef Kucia <joseph.kucia(a)gmail.com>: > +static HRESULT get_image_info_from_dds(const void *buffer, UINT length, D3DXIMAGE_INFO *info) > { > + UINT i; > + UINT faces = 0; ... > + /* calculate the expected length */ > + width = info->Width; > + height = info->Height; > + for (i = 0; i < info->MipLevels; i++) > + { > + UINT pitch, size = 0; > + calculate_dds_surface_size(info, width, height, &pitch, &size); > + expected_length += size; > + width = max(1, width / 2); > + height = max(1, width / 2); > + } > + > + if (length < expected_length) > + return D3DXERR_INVALIDDATA; It looks like you're not actually using the faces variable.

2 1

Re: [PATCH] dmusic: Variable spelling fix.
by Andrew Eikum May 10, 2012

May 10, 2012

On Thu, May 10, 2012 at 07:52:58AM +0200, Christian Costa wrote: > static HRESULT read_from_stream(IStream *stream, void *data, ULONG size) > { > - ULONG readed; > + ULONG read; > HRESULT hr; > > - hr = IStream_Read(stream, data, size, &readed); > + hr = IStream_Read(stream, data, size, &read); > if(FAILED(hr)){ I called it that to prevent shadowing read(3). It probably doesn't matter since we almost never use that call in Wine, but that was the rationale. Andrew

2 1

Re: [PATCH 1/2] comctl32: LVM_SETITEMTEXT is not supported on LVS_OWNERDATA
by Nikolay Sivov May 10, 2012

May 10, 2012

On 5/10/2012 12:01, Piotr Caban wrote: > > Thanks to this patch we no longer ask about the item text inside this > notification before returning error. > --- > dlls/comctl32/listview.c | 1 + > dlls/comctl32/tests/listview.c | 8 +++++++- > 2 files changed, 8 insertions(+), 1 deletions(-) > > case LVM_SETITEMTEXTA: > case LVM_SETITEMTEXTW: > + if (infoPtr->dwStyle& LVS_OWNERDATA) return FALSE; > return LISTVIEW_SetItemTextT(infoPtr, (INT)wParam, (LPLVITEMW)lParam, > uMsg == LVM_SETITEMTEXTW); Please place this inside LISTVIEW_SetItemTextT().

1 0

[PATCH 0/6] Extended file stat system call
by David Howells May 10, 2012

May 10, 2012

Implement a pair of new system calls to provide extended and further extensible stat functions. The second of the associated patches is the main patch that provides these new system calls: ssize_t ret = xstat(int dfd, const char *filename, unsigned atflag, unsigned mask, struct xstat *buffer); ssize_t ret = fxstat(int fd, unsigned atflag, unsigned mask, struct xstat *buffer); which are more fully documented in the first patch's description. These new stat functions provide a number of useful features, in summary: (1) More information: creation time, inode generation number, data version number, flags/attributes. A subset of these is available through a number of filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS). (2) Lightweight stat: Ask for just those details of interest, and allow a netfs (such as NFS) to approximate anything not of interest, possibly without going to the server. (3) Heavyweight stat: Force a netfs to go to the server, even if it thinks its cached attributes are up to date. (4) Allow the filesystem to indicate what it can/cannot provide: A filesystem can now say it doesn't support a standard stat feature if that isn't available. (5) Make the fields a consistent size on all arches, and make them large. (6) Can be extended by using more request flags and appending further data after the end of the standard return data. Note that no lstat() equivalent is required as that can be implemented through xstat() with atflag == 0. ======= PATCHES ======= Patch 1 defines the xstat() and fxstat() system calls. Patches 2-6 implement extended stat facilities for Ext4, AFS, NFS and CIFS, and make eCryptFS go to the lower filesystem for such details. ============== CONSIDERATIONS ============== Should fxstat() be implemented as xstat() with a NULL filename, using dfd as fd? Should the default for a network fs be to do an unconditional (heavyweight) stat with a flag to suppress going to the server to update the locally held attributes and flushing pending writebacks? Should things like the Windows Archive, Hidden and System bits be handled through IOC flags, perhaps expanded to 64-bits? Are these things useful to userspace other than Samba and userspace NFS servers? Is it useful to pass the volume ID out? Or is statfs() sufficient for this? Should I add a sixth argument to xstat(), mark it reserved and require that must be supplied as 0 to hedge against future use? Is there anything else I can usefully add at the moment? ========== TO BE DONE ========== Autofs, ntfs, btrfs, ... I should perhaps use u8/u32/u64 rather than uint8/32/64_t. Handle remote filesystems being offline and indicate this with XSTAT_INFO_OFFLINE. ======= TESTING ======= There's a test program attached to the description for the main patch. It can be run as follows: [root(a)andromeda tmp]# ./xstat -R /mnt/foo xstat(/mnt/foo) = 0 0000: 000081a40000ffef 0000000000000001 0000020000000000 0000100000080000 0020: 0000000000000000 0000000600000008 000000004f88499a 0000000136fd9208 0040: 000000004f88499a 0000000136fd9208 000000004f8849b9 0000000106daf187 0060: 000000004f8849b9 0000000106daf187 000000000000000c 000000000000000f 0080: 0000000000000008 00000000484ebbef 0000000000000025 5949ebd4711efd82 00a0: d3250b5c15d5e380 0000000000000000 0000000000000000 0000000000000000 00c0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 00e0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 results=ffef Size: 15 Blocks: 8 IO Block: 4096 regular file Device: 08:06 Inode: 12 Links: 1 Access: (0644/-rw-r--r--) Uid: 0 Gid: 0 Access: 2012-04-13 16:43:22.922587656+0100 Modify: 2012-04-13 16:43:53.115011975+0100 Change: 2012-04-13 16:43:53.115011975+0100 Create: 2012-04-13 16:43:22.922587656+0100 Inode version: 484ebbefh Data version: 25h Inode flags: 00080000 (-------- ----e--- -------- --------) Information: 00000200 (-------- -------- ------a- --------) Volume ID: 82fd1e71d4eb4959-80e3d5155c0b25d3 David --- David Howells (6): xstat: eCryptFS: Return extended attributes xstat: CIFS: Return extended attributes xstat: NFS: Return extended attributes xstat: AFS: Return extended attributes xstat: Ext4: Return extended attributes xstat: Add a pair of system calls to make extended file stats available arch/x86/syscalls/syscall_32.tbl | 2 arch/x86/syscalls/syscall_64.tbl | 2 fs/afs/inode.c | 29 ++- fs/afs/super.c | 7 + fs/cifs/cifsfs.h | 4 fs/cifs/cifsglob.h | 16 +- fs/cifs/dir.c | 2 fs/cifs/inode.c | 120 +++++++++++-- fs/ecryptfs/inode.c | 14 +- fs/ext4/ext4.h | 2 fs/ext4/file.c | 2 fs/ext4/inode.c | 32 +++ fs/ext4/namei.c | 2 fs/ext4/super.c | 1 fs/ext4/symlink.c | 2 fs/nfs/inode.c | 49 ++++- fs/nfs/super.c | 1 fs/stat.c | 350 +++++++++++++++++++++++++++++++++++--- include/linux/fcntl.h | 1 include/linux/fs.h | 4 include/linux/stat.h | 126 +++++++++++++- include/linux/syscalls.h | 7 + 22 files changed, 694 insertions(+), 81 deletions(-)

10 65

Re: [7/8] d3dx9/tests: Add tests for compressed pixel formats support in D3DXLoadSurface functions.
by Stefan Dösinger May 10, 2012

May 10, 2012

Am Mittwoch, 9. Mai 2012, 23:32:10 schrieb Józef Kucia: > +#define check_pixel_3bpp(lockrect, x, y, color) \ > +ok(((BYTE*)(lockrect).pBits)[3 * (x) + (y) * (lockrect).Pitch + 0] == > ... Inline functions are generally prefered over macros where possible. I think it is possible to pass a different line number to ok() to make the messages more useful when they are called from a helper function, but I don't know how off the top of my head. If you have to use a macro, please use capital letters.

2 1

Re: kernel32: Correct WideCharToMultiByte and MultiByteToWideChar error codes and conditions
by Nikolay Sivov May 10, 2012

May 10, 2012

On 5/10/2012 00:52, Alex Henrie wrote: > This patch was a lot harder to figure out than I thought it was going to be. > > The MSDN documentation of most of these behaviors can be found at > http://msdn.microsoft.com/en-us/library/windows/desktop/dd319072(v=vs.85).a… Does any application depend on that? > > --- > dlls/kernel32/locale.c | 38 ++++++++++++++--- > dlls/kernel32/tests/locale.c | 94 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 126 insertions(+), 6 deletions(-) This is a wrong file to place tests into. > > diff --git a/dlls/kernel32/tests/locale.c b/dlls/kernel32/tests/locale.c > index 3216ef9..9cbb124 100644 > --- a/dlls/kernel32/tests/locale.c > +++ b/dlls/kernel32/tests/locale.c > @@ -3137,6 +3137,99 @@ static void test_IdnToUnicode(void) > } > } > > +static void test_WideCharToMultiByte_error(UINT page, DWORD flags, LPCWSTR src, > + INT srclen, LPSTR dst, INT dstlen, > + LPCSTR defchar, BOOL* used, > + const char* test_description, > + DWORD expected_error) > +{ > + SetLastError(ERROR_SUCCESS); > + WideCharToMultiByte(page, flags, src, srclen, dst, dstlen, defchar, used); > + ok(GetLastError() == expected_error, > + "codepage %i, %s, expected error %i got error %i\n", page, > + test_description, expected_error, GetLastError()); > +} > + > +static void test_MultiByteToWideChar_error(UINT page, DWORD flags, LPCSTR src, > + INT srclen, LPWSTR dst, INT dstlen, > + const char* test_description, > + DWORD expected_error) > +{ > + SetLastError(ERROR_SUCCESS); > + MultiByteToWideChar(page, flags, src, srclen, dst, dstlen); > + ok(GetLastError() == expected_error, > + "codepage %i, %s, expected error %i got error %i\n", page, > + test_description, expected_error, GetLastError()); > +} > + Looks ugly enough, it's better to place some test data in table and loop through it, if you really want to test that.

2 3

Re: [PATCH 2/3] dmsynth: Add some clock tests.
by Marvin May 10, 2012

May 10, 2012

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=18298 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

kernel32: Add UTF-7 support
by Alex Henrie May 9, 2012

May 9, 2012

Hi all, Could I get some feedback on http://source.winehq.org/patches/data/85898 ? It was marked "Rejected" a week ago without explanation. Most of the code was authored by Katayama Hirofumi, whose patches have been accepted into Wine before. He gave permission to use his code under the LGPL at http://bugs.winehq.org/show_bug.cgi?id=27388 What more needs to be done before this patch can be accepted? -Alex

3 4

Re: d3drm/tests: Port IDirect3DRMFrame tests to IDirect3DRMFrame3
by Alexandre Julliard May 9, 2012

May 9, 2012

André Hentschel <nerv(a)dawncrow.de> writes: > --- > dlls/d3drm/tests/d3drm.c | 323 +++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 320 insertions(+), 3 deletions(-) It doesn't seem necessary to duplicate the whole thing, try to find a better way. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] d3drm: Retreive mesh name at loading time. Implement GetName and SetName. (try 5) (resend)
by Alexandre Julliard May 9, 2012

May 9, 2012

Christian Costa <titan.costa(a)gmail.com> writes: > Try 5: Use a growing buffer to store name. I don't think a growing buffer makes sense for this. > + if (name) > + { > + *size = min(*size, This->name_size); > + memcpy(name, This->name, *size); > + /* Make sure we have the terminating 0 in case of truncation */ > + name[*size] = 0; Buffer overflow. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Ubuntu 12.04 (version#2, drop previous mail)
by Eric Pouech May 9, 2012

May 9, 2012

> This is because you _cannot_ install the 32-bit -dev packages onto > 12.04. It's not just symlinks that are missing, many of the header > files are different between the arches. I'm not sure this is a generic rule, and if it were, then exclusion between i386 and x86_64 should be defined on most dev packages, and it's not the case also note, that in some cases, arch specific headers are moved to arch dependent directories (e.g. jpeg, glib...), which should also parallel install of multi-arch libs in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least > Just do the chroot. You will save yourself so much grief and it will > actually work. if the ubuntu folks keep this state of mind, then they'll continue to sink the best solution is then to pick up another distro A+ -- -- Eric Pouech

3 4

Re: [2/5] gdi32: Set tmDigitizedAspectX/Y to 96 instead of 300 for consistency.
by Dmitry Timoshkov May 8, 2012

May 8, 2012

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > --- a/dlls/gdi32/freetype.c > +++ b/dlls/gdi32/freetype.c > @@ -6677,8 +6677,8 @@ static BOOL get_outline_text_metrics(GdiFont *font) > TM.tmWeight = pOS2->usWeightClass; > } > TM.tmOverhang = 0; > - TM.tmDigitizedAspectX = 300; > - TM.tmDigitizedAspectY = 300; > + TM.tmDigitizedAspectX = 96; /* FIXME */ > + TM.tmDigitizedAspectY = 96; /* FIXME */ A couple of comments to the patch: 1. the values should be set to the resolution of the target device, and 96 looks more natural since most of the time the device is a display. 2. the change is for consystency with get_bitmap_text_metrics() which sets these values to 96. 3. even if this pacth is rejected, other patches in the sequence should not be affected by it. -- Dmitry.

1 0

running 16bit code
by David Laight May 8, 2012

May 8, 2012

Does wine support running of 16bit windows apps? If so does it rely on the underlying OS having support for 'virtual 8086 emulation'? I'm thinking of removing the VM86 support from NetBSD, and wine is about the only likley user. David -- David Laight: david(a)l8s.co.uk

5 5

Re: [PATCH 4/4] dmsynth: Add stubbed IKsControl interface to DirectMusicSynthSink object.
by Alexandre Julliard May 8, 2012

May 8, 2012

Christian Costa <titan.costa(a)gmail.com> writes: > --- > dlls/dmsynth/dmsynth_private.h | 1 + > dlls/dmsynth/synthsink.c | 67 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 68 insertions(+), 0 deletions(-) It fails here: ../../../tools/runtest -q -P wine -M dmsynth.dll -T ../../.. -p dmsynth_test.exe.so dmsynth.c && touch dmsynth.ok dmsynth.c:56: Test succeeded inside todo block: IDirectMusicSynthSink_QueryInterface returned: 0 make: *** [dmsynth.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] d3dcompiler: Partially implement D3DCompile function.
by Henri Verbeet May 8, 2012

May 8, 2012

I realize compile_shader() is mostly a copy of assemble_shader(), but nevertheless: On 8 May 2012 16:17, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > +struct bwriter_shader *parse_hlsl_shader(const char *text, enum shader_type type, DWORD version, If this isn't called outside of compiler.c it should be static. > + LPD3DBLOB buffer; "ID3DBlob *" > + CopyMemory(pos, preproc_messages, strlen(preproc_messages) + 1); memcpy() should do fine. > + hr = SlWriteBytecode(shader, 9, &res); ... > + size = HeapSize(GetProcessHeap(), 0, res); > + hr = D3DCreateBlob(size, &buffer); That's not very pretty, SlWriteBytecode() should probably just return the size as well.

2 1

Re: mscoree: Implement vtable fixups.
by Alexandre Julliard May 8, 2012

May 8, 2012

Vincent Povirk <madewokherd(a)gmail.com> writes: > + if (fixup->fixup->type & COR_VTABLE_32BIT) > + { > + DWORD *vtable = fixup->vtable; > + DWORD *tokens = fixup->tokens; > + for (i=0; i<fixup->fixup->count; i++) > + { > + TRACE("%x\n", tokens[i]); > + vtable[i] = (DWORD)host->mono->mono_marshal_get_vtfixup_ftnptr( > + image, tokens[i], fixup->fixup->type); This will cause warnings on 64-bit. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: kernel32: Add UTF-7 support
by Alex Henrie May 8, 2012

May 8, 2012

2012/5/7 Ben Klein <shacklein(a)gmail.com>: > Without being a regular contributor, here are a few tips from a cursory glance: > 1) Whitespace change on at least one line The only change to whitespace I made was: - if( flags) + if (flags) I don't think this is a big deal. > 2) Why the change from ERROR_INVALID_PARAMETER to ERROR_INVALID_FLAGS? To match the behavior of Windows. I verified this with both MSDN and empirical tests. If the flags parameter is not null, all versions of Windows tested report ERROR_INVALID_FLAGS with the possible exception of Windows NT4. See http://testbot.winehq.org/JobDetails.pl?Key=18148 > 3) New function defs do not match format of surrounding defs in unicode.h This was a hard one. I didn't know if I should keep Katayama's use of INT or change the functions to use int like the UTF-8 functions do. So you're saying it should all be int? Do LPCSTR and LPCWSTR need to be changed to something else as well? > 4) No new tests to confirm the behaviour is correct (or mention of > current tests succeeding) dlls/kernel32/tests/locale.c already has just as many UTF-7 tests as it has UTF-8 tests. What tests do we need for UTF-7 which are not needed for UTF-8? Thanks for your quick response, -Alex

2 1

Re: msi: Tweak msiexec's usage message.
by Julian Rüger May 7, 2012

May 7, 2012

Hi Francois and wine-devel, while we're at it, shouldn't these >"Advertise a product:\n" >"\t/j[u|m] package [/t transform] [/g languageid]\n" >"Apply a patch:\n" >"\t/p patch_package [property]\n" >"\t/p patch_package /a package [property]\n" also be put in curly brackets? Like this: \t/j[u|m] {package} [/t transform] ... \t/p {patch_package} [property]\n ... Best, Julian

3 3

Re: [Programs] Notepad: sync with ReactOS notepad (2)
by carlo.bramix＠libero.it May 7, 2012

May 7, 2012

Hello friends, >> Because you do seriously believe that ReactOS developers reversed the >> Windows notepad?! Along with Solitaire & calculator, I suppose? >> Common sense is a powerful tool, let's make use of it :-). > >It's a matter of trust. If a person is known to use illegal practices >to write ReactOS code then even adding one line of code to notepad >makes her/his contribution dangerous for the entity accepting that code. > >> For the record, ReactOS as well disallows any person who has seen the >> Microsoft Windows code to comment, contribute, commit to the project. > >That's just a blanket statement, nothing more. It's hard to believe >to it if the person(s) publicly accused in using leaked code still >commit to ReactOS without any limitation. as I already wrote, I totally agree. Please reject the patches. Sincerely, Carlo Bramini.

1 0

Re: [Programs] Notepad: sync with ReactOS notepad (2)
by carlo.bramix＠libero.it May 7, 2012

May 7, 2012

Hello friends, >The issue is whether the appropriate guidelines were followed >(http://wiki.winehq.org/CleanRoomGuidelines) One issue is that Wine >does not allow people that have ever viewed Microsoft source code to >contribute to Wine, but there are other issues. You'll have to talk >to Alexandre and see how he feels about this specific issue, but if >you've followed all of the guidelines and contribute only your own >changes then he might be ok with your contribution. I see. Perhaps it would be better to reject all these patches since I'm not the only author of all the changes. I understand that this is done to protect yourself and the project, because you do not know the people who touched the sources of the notepad, who they are and how they collected their information, so I agree with you. Sincerely, Carlo Bramini.

3 2

Re: [Programs] Notepad: sync with ReactOS notepad (2)
by carlo.bramix＠libero.it May 6, 2012

May 6, 2012

Hello friends, >thank you for working on this. I think you will improve the chances for >your patches to be accepted if you give them individually meaningful >names, like > >"notepad: Don't use reserved MSVC keyword." > >for patch #2. Actually, I followed the tip I read into the wiki of WINE in "Patch submission guidelines", so I tried to imitate the style of other patches for WINE and for this reason I used an identical title with a progressive number as subject. If something different is prefered, no problem, I will follow your suggestion and I will use a more focused title. >Also, like Jerome said, we may have a problem if different people >commited these changes to ReactOS. I'm no expert on this, but as I >understand, Wine needs the patch to be credited to the author who >actually wrote the code. Well, ReactOS notepad had been imported from WINE long time ago and various people did some changes on it and I'm included in them since, in this specific case, the status bar implementation had been almost rewritten by me. I'm not an expert too, but since it is distribuited under the same license of WINE, with same coding restrictions and all people who sent patches have agreed to the same GPL as well, my intuition would say that there is no problem on this... because the owner who can providing this code to you is the ReactOS project itself. That's just my opinion of course... I will wait for your suggestions/orders... ;-) Sincerely, Carlo Bramini.

4 3

Re: [Programs] Notepad: sync with ReactOS notepad (2)
by Julian Rüger May 6, 2012

May 6, 2012

Hi Carlo, thank you for working on this. I think you will improve the chances for your patches to be accepted if you give them individually meaningful names, like "notepad: Don't use reserved MSVC keyword." for patch #2. Also, like Jerome said, we may have a problem if different people commited these changes to ReactOS. I'm no expert on this, but as I understand, Wine needs the patch to be credited to the author who actually wrote the code. (Can someone else please comment on this, if I am mistaken?) Best regards, Julian

1 0

Re: rpcrt4/tests: Fix build with PSDK headers.
by Marvin May 5, 2012

May 5, 2012

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=18238 Your paranoid android. === WNT4WSSP6 (32 bit ndr_marshall) === ndr_marshall: unhandled exception c0000005 at 004081C6

1 0

Re: [Programs] Notepad: sync with ReactOS notepad
by Jerome Leclanche May 5, 2012

May 5, 2012

On Sat, May 5, 2012 at 2:15 PM, carlo.bramix(a)libero.it < carlo.bramix(a)libero.it> wrote: > Attached patch synces the WINE's notepad with the improvements added into > ReactOS' Notepad. > > - Imported status bar implementation, it fixes Bug #18715. New menu voice > has > been introduced into the resource file. > This is the biggest part of the patch, that it caused to touch all files > modified by the patch. > Other minor fixes included here are: > > - Implemented GOTO function. Since its menu voice has been added into the > resource file when adding support the statusbar, the related dialog box > and the > source code have been introduced too. > > - Find/Replace functions have an extremely similar behavior, so the job > can be > implemented with a single function. > > - Find and Find next commands must be grayed if there is not a text to > search > into. > > - The "class" word is a reserved keyword in MSVC, so I also imported the > fix > into the creation of the class of the window: "class" has been replaced > with > "wndclass", no code change. > > Sincerely, > > Carlo Bramini > > It's not going to be accepted as one big patch. It needs to be split. Also, are you the author of all the patches or are these other contributors for this? J. Leclanche

1 0

Re: kernel32: add more tracing to GetDiskFreeSpaceW
by Dmitry Timoshkov May 5, 2012

May 5, 2012

Austin English <austinenglish(a)gmail.com> wrote: > @@ -1687,6 +1689,8 @@ BOOL WINAPI GetDiskFreeSpaceW( LPCWSTR root, LPDWORD cluster_sectors, > if (sector_bytes) *sector_bytes = info.BytesPerSector; > if (free_clusters) *free_clusters = info.AvailableAllocationUnits.u.LowPart; > if (total_clusters) *total_clusters = info.TotalAllocationUnits.u.LowPart; > + TRACE("%u, %u, %u, %u, capped=%d\n", cluster_sectors ? *cluster_sectors : 0, sector_bytes ? *sector_bytes : 0, > + free_clusters ? *free_clusters : 0, total_clusters ? *total_clusters : 0, capped); Why not print in the values directly from info structure? That way all the data are in the trace regardless of what info appication requested. I'd guess that printing valus in hex would be more readable, and once the data is printed in hex it should be obvious when the values were capped, making 'capped' flag redundant. -- Dmitry.

1 0

Re: [2/5] msvcm80: Add stub dll.
by Charles Davis May 4, 2012

May 4, 2012

On May 4, 2012, at 10:07 AM, Vincent Povirk wrote: > > <0002-msvcm80-Add-stub-dll.txt> msvcmrt? The Managed C++ Runtime DLL? I imagine you won't get far on that without a C++/CLI compiler that understands the Microsoft Visual C++ ABI--unless you're willing to write all the marshaling glue code by hand. There's only one such compiler right now, and it only runs on Windows. VC++ ABI support is on my Clang to-do list--heck, it's my GSoC project--but C++/CLI is something I won't get to for a while. Given all that, how do you intend to implement this? Chip

2 2

Re: [2/5] msvcm80: Add stub dll.
by Stefan Dösinger May 4, 2012

May 4, 2012

3 2

Re: [5/5] msvcm80: Add __setusermatherr_m stub.
by Charles Davis May 4, 2012

May 4, 2012

On May 4, 2012, at 10:10 AM, Vincent Povirk wrote: > diff --git a/dlls/msvcm80/msvcm80_main.c b/dlls/msvcm80/msvcm80_main.c > index cd38f5b..eb09898 100644 > --- a/dlls/msvcm80/msvcm80_main.c > +++ b/dlls/msvcm80/msvcm80_main.c > @@ -50,3 +50,10 @@ void __cdecl CrtImplementationDetails_RegisterModuleUninitializer(void* handler) > FIXME("%p: stub\n", handler); > } > > +/* handler is a "method" with signature int32 (*handler)(_exception*), but I'm > + * not sure what that means */ I am. Actually, it's: int (__clrcall *handler)(struct _exception *) i.e. a "pointer to a function intended to be called from managed code that takes a pointer to a struct _exception and returns an int." The definition of struct _exception is in <math.h> under Visual Studio. To write such a function, you'd need a C++/CLI compiler. Chip

1 0

Wine Gecko 1.6-beta1
by Jacek Caban May 4, 2012

May 4, 2012

Hi all, I've uploaded a beta version of another Gecko update. Other than usual Gecko changes coming from Mozilla (for upcoming Firefox 13), it contains fixes for Wine bugs 30465 and 25243. To try it, as usually, the attached patch is required as well as the build that may be found on SourceForge [1], installed in usual way [2] (or your own build, it's easy those days! See wine-gecko-1.6 branch on [3]). All help with testing is appreciated! Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.6-beta1/ [2] http://wiki.winehq.org/Gecko [3] http://wine.git.sourceforge.net/git/gitweb.cgi?p=wine/wine-gecko;a=summary

1 0

Re: [PATCH 1/2] jscript: Skip failing tests on old jscript versions
by Marvin May 4, 2012

May 4, 2012

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=18229 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: po: English (neutral / Great Britain) spelling fixes.
by Nicolas Le Cam May 3, 2012

May 3, 2012

Le 3 mai 2012 02:45, "Francois Gouget" <fgouget(a)free.fr> a écrit : > @@ -9429,9 +9429,9 @@ msgstr "" > "start [options] document_filename\n" > "\n" > "Options:\n" > -"/M[inimized] Start the program minimized.\n" > -"/MAX[imized] Start the program maximized.\n" > -"/R[estored] Start the program normally (neither minimized nor maximized).\n" > +"/M[inimized] Start the program minimised.\n" > +"/MAX[imized] Start the program maximised.\n" > +"/R[estored] Start the program normally (neither minimised nor maximised).\n" > "/W[ait] Wait for started program to finish, then exit with its exit " > "code.\n" > "/Unix Use a Unix filename and start the file like windows explorer.\n" Hi Francois, Shouldn't the end of words between brackets be translated too ? -- Nicolas Le Cam

3 3

Re: [3/5] d3dx9: Implement D3DXSaveSurfaceToFileW.
by Henri Verbeet May 3, 2012

May 3, 2012

On 2 May 2012 23:32, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > + if(wic_pixel_formats[i].d3dformat == format) Missing whitespace. > +HRESULT WINAPI D3DXSaveSurfaceToFileW(LPCWSTR dst_filename, D3DXIMAGE_FILEFORMAT file_format, "LPCWSTR" -> "const WCHAR *" > + TRACE("(%s, %d, %p, %p, %p)\n", > + wine_dbgstr_w(dst_filename), file_format, src_surface, src_palette, src_rect); wine_dbgstr_rect(). > + memcpy(&wic_pixel_format, pixel_format_guid, sizeof(GUID)); > + hr = IWICBitmapFrameEncode_SetPixelFormat(frame, &wic_pixel_format); > + d3d_pixel_format = wic_guid_to_d3dformat(&wic_pixel_format); What is all this for? Also, how do you intend to implement D3DXSaveSurfaceToFileInMemory()?

2 2

Re: [2/5] d3dx9: Forward D3DXSaveSurfaceToFileA to D3DXSaveSurfaceToFileW.
by Henri Verbeet May 3, 2012

May 3, 2012

On 2 May 2012 23:32, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > +HRESULT WINAPI D3DXSaveSurfaceToFileA(LPCSTR dst_filename, D3DXIMAGE_FILEFORMAT file_format, > + IDirect3DSurface9 *src_surface, const PALETTEENTRY *src_palette, const RECT *src_rect) If you're changing these anyway, LPCSTR is a broken way of saying "const char *". > + TRACE("(%s, %d, %p, %p, %p): relay\n", > + wine_dbgstr_a(dst_filename), file_format, src_surface, src_palette, src_rect); I generally prefer %#x for things like file_format, but don't care particularly strongly. For src_rect you should use %s and wine_dbgstr_rect(). I don't care much for the "relay" suffix, but I suppose half the existing code has it as well. > + len = MultiByteToWideChar(CP_ACP, 0, dst_filename, -1, NULL, 0); > + filename = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len * sizeof(WCHAR)); The HEAP_ZERO_MEMORY flag is useless, you're immediately going to overwrite all the memory afterwards. Sadly the existing d3dx9 code isn't a very good example here either.

1 0

Request for help/advice in investigation of one interesting "huge FPS regression" bug
by Alexey Loukianov May 3, 2012

May 3, 2012

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good day to all. Henri, Stefan, I address this message to you at the first place as to a main developers of wined3d/opengl stuff. Nevertheless, hints and help are welcome from anyone, cause ATM I'm totally confused and don't know what else to try to investigate a case. What I've got here is an app (localized version of "Perfect World" MMORPG game client from "Mail.Ru Games Corp") that seems to suffer huge FPS regression which I believe to be a bug in nVIDIA drivers rather than a regression in Wine. Details are following. When I configure an app to run in a windowed mode I've got around 40 FPS on game login screen with nVIDIA drivers 275.09.07, but switching into using more recent versions causes FPS to drop to around ~10. Configuring the game to use fullscreen more fixes the issue - I've got ~30-40 FPS at game login screen no matter the driver version I use. I've been suspecting that this issue might be related to vsync control (and a recent change in nVIDIA linux drivers for vsync to be on by default) that causes the issue, so I had exported __GL_SYNC_TO_VBLANK="0" into the environment and used nvidia-settings to set vsync to be off by default. Using a small native opengl demo program I had specifically written to test for vsync state I can prove that vsync defaults to be off on my system. Also I had modified Wine's winex11.drv opengl.c in a way that a call to wglSwapIntervalEXT always sets swap_interval to be zero, no matter what was originally requested. Nevertheless, I still got this strange FPS drop when I run the game in a windowed more with a recent nVIDIA drivers. What could be a cause for it? What I want is to track down the problem to it's roots and check if it's really a bug in nVIDIA drivers. In the end I would like to implement a small opengl demo that would trigger the bug so nVIDIA wouldn't be able to reject my bug report on a matter that "it's a Wine bug, prove us that it's not". - -- Best regards, Alexey Loukianov mailto:mooroon2(a)mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPij76AAoJEPB9BOdTkBULjz4H/1B/Nw6qOQUlEmDb64SmabvQ LQmzIHcnH38Ftz3KyWQxlYZ5EtLDYAIOQeP4pAHfzxKhGUJ1mCumv4ByaSs4YDhI juWJ/u/88vKwZYXJ9nZLQVqJY+dkr9MbxP3q0eGNaAFLNRDIqodzJJWB5EPucMrX Yid/zMjl5uGd9QDCO3Db4gwJKYpvHCbAfzADddqBwPoak9jXdlq53H9a2mImTbCB JR1MXQq6gFakOgtxXPxzFSU2Ge0n8RBGGN7UeZEubsLiktnmvTbKAJmmgWgPG80Y mlud7LrM4wLRPtpwTwS+M1n8TuVtUZzzCTagRyj3XSRL8Pqf2d5S3H+MpxBT1JQ= =TkMD -----END PGP SIGNATURE-----

5 8