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

Re: [PATCH 2/2] qedit/tests: Add COM aggregation test for MediaDet.

by Michael Stefaniuc

On 07/01/2012 12:12 AM, Marvin wrote: > 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=19677 > > Your paranoid android. > > > === WNT4WSSP6 (32 bit mediadet) === > mediadet.c:149: Test failed: CoCreateInstance failed: 80040154 > mediadet: unhandled exception c0000005 at 00401587 > > === W2KPROSP4 (32 bit mediadet) === > mediadet.c:149: Test failed: CoCreateInstance failed: 80040154 > mediadet: unhandled exception c0000005 at 00401587 Both hosts miss qedit.dll. bye michael

June 30, 2012

Re: [PATCH 2/2] qedit/tests: Add COM aggregation test for MediaDet.

by Marvin

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=19677 Your paranoid android. === WNT4WSSP6 (32 bit mediadet) === mediadet.c:149: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 00401587 === W2KPROSP4 (32 bit mediadet) === mediadet.c:149: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 00401587

June 30, 2012

Release schedule

by Alexandre Julliard

Folks, Because of various travels and vacations (and just to keep you on your toes ;-), during the month of July I'm planning to make releases on Tuesdays instead of Fridays. So 1.5.8 will be on July 3rd, and then I'll be out for the rest of that week. Subsequent releases should happen on July 17th and 31st, and I'll also be out the first 10 days of August. And if you find this confusing, just take some vacations too ;-) -- Alexandre Julliard julliard(a)winehq.org

June 30, 2012

Re: include/basetsd.h: Fix int64 to int truncation warnings when compiling with a 64-bit PSDK compiler.

by Stefan Dösinger

Am Donnerstag, 28. Juni 2012, 20:50:15 schrieb Dmitry Timoshkov: > Obviosuly I'm not planning to add the casts everywhere, but the inline > constructs which specifically targeting the pointer to integer conversions > that imply truncation should compile without warnings IMHO. Fwiw, I fixed a number of double-to-float conversion warnings in MSVC in wined3d, d3d8 and d3d9 a while ago, as well as some similar integer issues. I fixed most of those warnings by using the proper data types and explicitly using float literals. I added a handful of casts in places where the API differences forced me to(d3d vs GL clipplanes if I remember correctly). >From my experience with wined3d the majority warnings(~90 %) from msvc made sense and pointed out potential bugs in the code. The rest were cases like the one Dmitry wants to patch where the API definitions force a conversion with potential data loss.

June 30, 2012

Re: windowscodecs: test for TIFFSetWarningHandlerExt

by Alexandre Julliard

Daniel Lehman <dlehman(a)esri.com> writes: > Fails to build on RHEL4 with libtiff 3.6.1 > > Alternative to this is a configure test for libtiff 3.8.0, which is when the function first appears I don't think this needs a configure test. Just define the prototype explicitly instead of using typeof. -- Alexandre Julliard julliard(a)winehq.org

June 29, 2012

Re: msvcp90: Fix __cdecl functions definitions that returns structures

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > In code produced by gcc callee removes hidden return argument. In code > produced by MS Visual Studio caller is responsible for removing the > hidden argument. That's only for structures larger than 8 bytes, which isn't the case at least for _Getcoll. Some tests would probably be a good idea. -- Alexandre Julliard julliard(a)winehq.org

June 29, 2012

Re: [1/5] d3dx9: Implement D3DXLoadVolumeFromMemory.

by Józef Kucia

On Thu, Jun 28, 2012 at 2:27 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > I'm not quite sure of the right and bottom misalignment checks. If the > tests confirm that, of course that's okay. > Native accepts misaligned boxes, but in order to implement it S3TC decompressor and compressor is needed. I'll make it a FIXME.

June 29, 2012

user32: Add test for ComboBox repositioning behavior (try 2).

by Sergey Guralnik

Marvin wrote 29.06.2012 10:14: > 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=19658 > > Your paranoid android. > > > === W7PRO (32 bit msg) === > msg.c:8219: Test failed: did not get zero count as expected (1). This is unrelated to my patch. -- Sergey

June 29, 2012

Re: user32: Add test for ComboBox repositioning behavior (try 2).

by Marvin

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=19658 Your paranoid android. === W7PRO (32 bit msg) === msg.c:8219: Test failed: did not get zero count as expected (1).

June 29, 2012

Re: gdiplus: Add a test to show that GdipCloneImage is not supposed to increase refcount of the source image stream, but clone it instead.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > I think it's most likely not keeping the input stream in the new image at all. > > It's probably also worth testing SelectActiveFrame, GetPropertyItem, > and GetImageRawFormat with clones of images. Maybe they don't work. A quick test shows that SelectActiveFrame called on a clone of a multiframe gif image succeeds under nt4 and win2k, but fails under all later gdiplus implementations. Looks like a clone does not really clone anything. -- Dmitry.

June 29, 2012

Re: gdiplus: Add a test to show that GdipCloneImage is not supposed to increase refcount of the source image stream, but clone it instead.

by Vincent Povirk

I think it's most likely not keeping the input stream in the new image at all. It's probably also worth testing SelectActiveFrame, GetPropertyItem, and GetImageRawFormat with clones of images. Maybe they don't work.

June 29, 2012

Re: include: fix mingw64 build

by Nicolas Le Cam

2012/6/29 Austin English <austinenglish(a)gmail.com>: > On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam <niko.lecam(a)gmail.com> wrote: >> 2012/6/29 Austin English <austinenglish(a)gmail.com>: >>> Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 >>> >>> -- >>> -Austin >>> >>> >>> >> Hi Austin, >> >> I already tried to fix it on Wine side, see [1], >> but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, >> as it shouldn't include crtdefs.h by default. >> >> BTW, won't that break mingw32 build ? >> >> [1] http://source.winehq.org/patches/data/84070 >> >> -- >> Nicolas Le Cam > > Thanks for the info. Have you or anyone else discussed this with > mingw64? I did a quick search on their bugtracker, but don't see > anything.. > http://sourceforge.net/search/?group_artifact_id=983354&type_of_search=arti… > > -- > -Austin No I didn't take the time to report the issue. I cloned their repo and wanted to send a patch, unfortunately I didn't have the time to work on that actually. -- Nicolas Le Cam

June 29, 2012

Re: include: fix mingw64 build

by Austin English

On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam <niko.lecam(a)gmail.com> wrote: > 2012/6/29 Austin English <austinenglish(a)gmail.com>: >> Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 >> >> -- >> -Austin >> >> >> > Hi Austin, > > I already tried to fix it on Wine side, see [1], > but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, > as it shouldn't include crtdefs.h by default. > > BTW, won't that break mingw32 build ? > > [1] http://source.winehq.org/patches/data/84070 > > -- > Nicolas Le Cam Thanks for the info. Have you or anyone else discussed this with mingw64? I did a quick search on their bugtracker, but don't see anything.. http://sourceforge.net/search/?group_artifact_id=983354&type_of_search=arti… -- -Austin

June 29, 2012

Re: include: fix mingw64 build

by Nicolas Le Cam

2012/6/29 Austin English <austinenglish(a)gmail.com>: > Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 > > -- > -Austin > > > Hi Austin, I already tried to fix it on Wine side, see [1], but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, as it shouldn't include crtdefs.h by default. BTW, won't that break mingw32 build ? [1] http://source.winehq.org/patches/data/84070 -- Nicolas Le Cam

June 29, 2012

Re: wbemprox: Add a Win32_LogicalDisk class stub.

by John Yani

NFS requests "Size" and "FreeSpace" fields. Not sure if it require them to be set.

June 28, 2012

Re: wbemprox: Add a Win32_LogicalDisk class stub.

by John Yani

So, is this patch good?

June 28, 2012

Re: wbemprox: Add a Win32_LogicalDisk class stub.

by Hans Leidekker

On Thu, 2012-06-28 at 22:22 +0300, John Yani wrote: > On 28 June 2012 22:17, Hans Leidekker <hans(a)codeweavers.com> wrote: > > On Thu, 2012-06-28 at 21:53 +0300, John Yani wrote: > > That's better. Does NFS actually query the Caption and Description properties? > > > > > Well, no. I just thought the output should be similar to the one on > winetestbot: https://testbot.winehq.org/JobDetails.pl?Key=19642&log_201=1#k201 No, that's just a test I wrote to investigate this stuff.

June 28, 2012

Re: wbemprox: Add a Win32_LogicalDisk class stub.

by John Yani

On 28 June 2012 22:17, Hans Leidekker <hans(a)codeweavers.com> wrote: > On Thu, 2012-06-28 at 21:53 +0300, John Yani wrote: >> +static void fill_logicaldisk( struct table *table ) >> +{ >> + static const WCHAR caption[] = >> + {'C',':',0}; >> + static const WCHAR description[] = >> + {'L','o','c','a','l',' ','F','i','x','e','d',' ','D','i','s','k',0}; >> + static const WCHAR device_id[] = >> + {'C',':',0}; >> + struct record_logicaldisk *rec; >> + FIXME("returns a fake logical disks table\n"); >> + if (!(table->data = heap_alloc( sizeof(*rec) ))) >> + { >> + return; >> + } >> + rec = (struct record_logicaldisk *)(table->data); >> + rec->caption = caption; >> + rec->description = description; >> + rec->device_id = device_id; >> + table->num_rows = 1; >> + TRACE("created %u row(s)\n", table->num_rows); > > That's better. Does NFS actually query the Caption and Description properties? > > Well, no. I just thought the output should be similar to the one on winetestbot: https://testbot.winehq.org/JobDetails.pl?Key=19642&log_201=1#k201

June 28, 2012

Re: wbemprox: Add a Win32_LogicalDisk class stub.

by Hans Leidekker

On Thu, 2012-06-28 at 21:53 +0300, John Yani wrote: > +static void fill_logicaldisk( struct table *table ) > +{ > + static const WCHAR caption[] = > + {'C',':',0}; > + static const WCHAR description[] = > + {'L','o','c','a','l',' ','F','i','x','e','d',' ','D','i','s','k',0}; > + static const WCHAR device_id[] = > + {'C',':',0}; > + struct record_logicaldisk *rec; > + FIXME("returns a fake logical disks table\n"); > + if (!(table->data = heap_alloc( sizeof(*rec) ))) > + { > + return; > + } > + rec = (struct record_logicaldisk *)(table->data); > + rec->caption = caption; > + rec->description = description; > + rec->device_id = device_id; > + table->num_rows = 1; > + TRACE("created %u row(s)\n", table->num_rows); That's better. Does NFS actually query the Caption and Description properties?

June 28, 2012

Re: user32: Add a test for ComboBox WM_WINDOWPOSCHANGED handling.

by Alexandre Julliard

Sergey Guralnik <serhio(a)etersoft.ru> writes: > @@ -5807,6 +5830,25 @@ static void test_combobox_messages(void) > log_all_parent_messages--; > ok_sequence(WmKeyDownComboSeq, "WM_KEYDOWN/VK_DOWN on a ComboBox", FALSE); > > + wp.hwnd = combo; > + wp.hwndInsertAfter = HWND_TOP; > + wp.cx = wp.cy = wp.x = wp.y = 50; > + wp.flags = 0; > + flush_sequence(); > + SendMessage(combo, WM_WINDOWPOSCHANGED, 0, (LPARAM)&wp); It doesn't make much sense to send this message directly. What are you trying to test? -- Alexandre Julliard julliard(a)winehq.org

June 28, 2012

Re: [2/2] gdiplus: Increase refcount of the source stream when loading a bitmap instead of cloning it.

by Vincent Povirk

This looks good to me. (I didn't think it was necessary to comment, but this is an important fix and I was surprised it was still New.)

June 28, 2012

Re: Unused msvcp60 functions

by Piotr Caban

On 06/28/12 16:33, Francois Gouget wrote: > Actually there are some implementation differences between msvcp60's and > msvcp90's misc.c code. In particular for the init_lockit(), > free_lockit() and various _Lockit_ctor_*() functions. Are the two > implementations supposed to be identical? I forgot that functions in this file were changed. This implementations are not supposed to be identical. > There's no indication that the > two misc.c files are supposed to remain synchronized but if that's the > goal, one option would be to move the msvcp90-specific functions to > another file so that it remains easy to copy and/or diff these two > misc.c files. All files in msvcp60 and msvcp90 will be quite similar. So it's useful if diff is minimal/readable. But I don't think that splitting most of the files (so some files may be copied) is useful. > Also a lot of functions actually rely on forwarding to msvcp90. Should > this be used for the misc.c functions too? Only if functions are operating on identical object in msvcp60 and msvcp90. I was trying to forward functions when it was possible.

June 28, 2012

Re: Unused msvcp60 functions

by Francois Gouget

On Thu, 28 Jun 2012, Piotr Caban wrote: [...] > The function were not removed to make msvcp60 and msvcp90 more similar > (and probably because I didn't use -Wunused-function option). Thanks to > it one can copy misc.c file between the dlls when it's modified. Actually there are some implementation differences between msvcp60's and msvcp90's misc.c code. In particular for the init_lockit(), free_lockit() and various _Lockit_ctor_*() functions. Are the two implementations supposed to be identical? There's no indication that the two misc.c files are supposed to remain synchronized but if that's the goal, one option would be to move the msvcp90-specific functions to another file so that it remains easy to copy and/or diff these two misc.c files. Also a lot of functions actually rely on forwarding to msvcp90. Should this be used for the misc.c functions too? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.

June 28, 2012

Re: windowscodecs: Make sure that stream is not reused once the decoder is initialized.

by Vincent Povirk

Looks good to me.

June 28, 2012

mshtml: Always set the URL policy in the error cases?

by Francois Gouget

gcc 4.7 is complaining that policy may be used uninitialized in InternetHostSecurityManager_QueryCustomPolicy() and indeed there are many error cases in confirm_safety_load() and confirm_safety() where the policy is not set. The patch belowe seems to plug all these holes but I don't know if it really makes sense. diff --git a/dlls/mshtml/secmgr.c b/dlls/mshtml/secmgr.c index ff349ac..3f64a42 100644 --- a/dlls/mshtml/secmgr.c +++ b/dlls/mshtml/secmgr.c @@ -104,10 +104,9 @@ static HRESULT confirm_safety_load(HTMLDocumentNode *This, struct CONFIRMSAFETY CATID init_catid = CATID_SafeForInitializing; hres = ICatInformation_IsClassOfCategories(This->catmgr, &cs->clsid, 1, &init_catid, 0, NULL); + *ret = hres == S_OK ? URLPOLICY_ALLOW : URLPOLICY_DISALLOW; if(FAILED(hres)) return hres; - - *ret = hres == S_OK ? URLPOLICY_ALLOW : URLPOLICY_DISALLOW; } return S_OK; @@ -157,13 +156,17 @@ static HRESULT confirm_safety(HTMLDocumentNode *This, const WCHAR *url, struct C if(!This->catmgr) { hres = CoCreateInstance(&CLSID_StdComponentCategoriesMgr, NULL, CLSCTX_INPROC_SERVER, &IID_ICatInformation, (void**)&This->catmgr); - if(FAILED(hres)) + if(FAILED(hres)) { + *ret = URLPOLICY_DISALLOW; return hres; + } } hres = ICatInformation_IsClassOfCategories(This->catmgr, &cs->clsid, 1, &scripting_catid, 0, NULL); - if(FAILED(hres)) + if(FAILED(hres)) { + *ret = URLPOLICY_DISALLOW; return hres; + } if(hres != S_OK) { *ret = URLPOLICY_DISALLOW; -- 1.7.10

June 28, 2012

Re: kernel32/tests: Remove an unused variable in the sync tests.

by Marvin

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

June 28, 2012

Re: include/basetsd.h: Fix int64 to int truncation warnings when compiling with a 64-bit PSDK compiler.

by Michael Stefaniuc

On 06/28/2012 01:50 PM, Dmitry Timoshkov wrote: > Michael Stefaniuc <mstefani(a)redhat.com> wrote: > >>> truncating from double to float while gcc keeps silence for instance. >> I never looked at that but I assume the same holds true as above. > > The following thread has some interesting details: > http://www.daniweb.com/software-development/c/threads/114052/warning-c4305-… WOW, that's pretty stupid. "0.1" has no type, it is a numeric literal. Type is inferred from the context and only if that isn't possible it will fall back to the intrinsic type. You can even say "int i = 0.1;" and that is correct C. gcc -Wall -Wextra does not complain about the examples in the thread you quoted as that is the correct C behavior. MSVC is a C++ compiler beaten into submission to do C. And C++ perverted C. bye michael

June 28, 2012

Re: [4/5] d3dx9: Implement D3DXCreateVolumeTextureFromFileInMemoryEx.

by Matteo Bruni

2012/6/27 Józef Kucia <joseph.kucia(a)gmail.com>: > --- > + for (mip_level = 0; mip_level < mip_levels; mip_level++) > + { > + hr = calculate_dds_surface_size(src_info, width, height, &src_pitch, &mip_level_size); > + if (FAILED(hr)) return hr; ... > + hr = D3DXLoadVolumeFromMemory(volume, palette, NULL, pixels, src_info->Format, > + src_pitch, mip_level_size, NULL, &box, filter, color_key); mip_level_size would be the source slice pitch, right? I'd just call it like that.

June 28, 2012

Re: [1/5] d3dx9: Implement D3DXLoadVolumeFromMemory.

by Matteo Bruni

2012/6/27 Józef Kucia <joseph.kucia(a)gmail.com>: > --- Hi Józef, > +void copy_simple_data(const BYTE *src, UINT srcpitch, SIZE src_size, const PixelFormatDesc *srcformat, > + BYTE *dest, UINT destpitch, SIZE dst_size, const PixelFormatDesc *destformat, D3DCOLOR colorkey) DECLSPEC_HIDDEN; > + You are not actually using this function in the patch. > + if (dst_box->Left > dst_box->Right || dst_box->Right > desc.Width) > + return D3DERR_INVALIDCALL; > + if (dst_box->Top > dst_box->Bottom || dst_box->Bottom > desc.Height) > + return D3DERR_INVALIDCALL; > + if (dst_box->Front > dst_box->Back || dst_box->Back > desc.Depth) > + return D3DERR_INVALIDCALL; > + > + dst_width = dst_box->Right - dst_box->Left; > + dst_height = dst_box->Bottom - dst_box->Top; > + dst_depth = dst_box->Back - dst_box->Front; > + if (!dst_width || !dst_height || !dst_depth) > + return D3DERR_INVALIDCALL; You can avoid the last check by comparing e.g. (dst_box->Left >= dst_box->Right) above, instead of using ">". > + if (src_box->Left & (src_format_desc->block_width - 1) > + || src_box->Top & (src_format_desc->block_height - 1) > + || (src_box->Right & (src_format_desc->block_width - 1) > + && src_width != desc.Width) > + || (src_box->Bottom & (src_format_desc->block_height - 1) > + && src_height != desc.Height)) > + { > + WARN("Source box (%u, %u, %u, %u) is misaligned\n", > + src_box->Left, src_box->Top, src_box->Right, src_box->Bottom); > + return D3DXERR_INVALIDDATA; > + } I'm not quite sure of the right and bottom misalignment checks. If the tests confirm that, of course that's okay. > + for (slice = 0; slice < src_depth; slice++) > + { > + src_addr = src_memory; > + src_addr += slice * src_slice_pitch; Shouldn't you take into account src_box->Front?

June 28, 2012

Re: include/basetsd.h: Fix int64 to int truncation warnings when compiling with a 64-bit PSDK compiler.

by Dmitry Timoshkov

Michael Stefaniuc <mstefani(a)redhat.com> wrote: > > truncating from double to float while gcc keeps silence for instance. > I never looked at that but I assume the same holds true as above. The following thread has some interesting details: http://www.daniweb.com/software-development/c/threads/114052/warning-c4305-… > > Anyway, the patch shouldn't hurt, PSDK headers have similar casts. This > In this specific case it doesn't. Start littering the code with casts to > get rid of all those warnings and it will majorly hurt. Unneeded casts > are *BAD*; worse then ignoring bogus warnings from a compiler. Obviosuly I'm not planning to add the casts everywhere, but the inline constructs which specifically targeting the pointer to integer conversions that imply truncation should compile without warnings IMHO. -- Dmitry.

June 28, 2012

Re: include/basetsd.h: Fix int64 to int truncation warnings when compiling with a 64-bit PSDK compiler.

by Michael Stefaniuc

On 06/28/2012 01:00 PM, Dmitry Timoshkov wrote: > Michael Stefaniuc <mstefani(a)redhat.com> wrote: > >> afair the fix is to disable the int truncation warnings in MSVC. For >> whatever reason they seem to enable those bogus warnings. > > The warnings are not bogus, the PSDK compiler also emits a warning when They are bogus as the C standard explicitly allows conversion between integer types. > truncating from double to float while gcc keeps silence for instance. I never looked at that but I assume the same holds true as above. > Anyway, the patch shouldn't hurt, PSDK headers have similar casts. This In this specific case it doesn't. Start littering the code with casts to get rid of all those warnings and it will majorly hurt. Unneeded casts are *BAD*; worse then ignoring bogus warnings from a compiler. > patch also helps to pay more attention to warnings: when there are lots > of existing ones, it's hard to recognize new and possibly real problems > in the code. bye michael

June 28, 2012

Re: include/basetsd.h: Fix int64 to int truncation warnings when compiling with a 64-bit PSDK compiler.

by Dmitry Timoshkov

Michael Stefaniuc <mstefani(a)redhat.com> wrote: > afair the fix is to disable the int truncation warnings in MSVC. For > whatever reason they seem to enable those bogus warnings. The warnings are not bogus, the PSDK compiler also emits a warning when truncating from double to float while gcc keeps silence for instance. Anyway, the patch shouldn't hurt, PSDK headers have similar casts. This patch also helps to pay more attention to warnings: when there are lots of existing ones, it's hard to recognize new and possibly real problems in the code. -- Dmitry.

June 28, 2012

Re: include/basetsd.h: Fix int64 to int truncation warnings when compiling with a 64-bit PSDK compiler.

by Michael Stefaniuc

Dmitry, afair the fix is to disable the int truncation warnings in MSVC. For whatever reason they seem to enable those bogus warnings. bye michael On 06/28/2012 12:12 PM, Dmitry Timoshkov wrote: > --- > include/basetsd.h | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/include/basetsd.h b/include/basetsd.h > index 698dd5c..4a59897 100644 > --- a/include/basetsd.h > +++ b/include/basetsd.h > @@ -153,12 +153,12 @@ typedef unsigned int UHALF_PTR, *PUHALF_PTR; > > static inline ULONG32 HandleToULong(const void *h) > { > - return (ULONG_PTR)h; > + return (ULONG32)(ULONG_PTR)h; > } > > static inline LONG32 HandleToLong(const void *h) > { > - return (LONG_PTR)h; > + return (LONG32)(LONG_PTR)h; > } > > static inline void *ULongToHandle(ULONG32 ul) > @@ -173,32 +173,32 @@ static inline void *LongToHandle(LONG32 l) > > static inline ULONG32 PtrToUlong(const void *p) > { > - return (ULONG_PTR)p; > + return (ULONG32)(ULONG_PTR)p; > } > > static inline LONG32 PtrToLong(const void *p) > { > - return (LONG_PTR)p; > + return (LONG32)(LONG_PTR)p; > } > > static inline UINT32 PtrToUint(const void *p) > { > - return (UINT_PTR)p; > + return (UINT32)(UINT_PTR)p; > } > > static inline INT32 PtrToInt(const void *p) > { > - return (INT_PTR)p; > + return (INT32)(INT_PTR)p; > } > > static inline UINT16 PtrToUshort(const void *p) > { > - return (ULONG_PTR)p; > + return (UINT16)(ULONG_PTR)p; > } > > static inline INT16 PtrToShort(const void *p) > { > - return (LONG_PTR)p; > + return (INT16)(LONG_PTR)p; > } > > static inline void *IntToPtr(INT32 i)

June 28, 2012

Re: [2/2] msvcp90: Sync spec files

by Owen Rudge

On 28/06/2012 11:33, Owen Rudge wrote: > --- > dlls/msvcp60/msvcp60.spec | 638 > ++++++++++++++++++++++---------------------- Sorry, I ran the make_specfiles script without realising that msvcp60.spec shouldn't have been updated. I've resent the patch without these changes. -- Owen Rudge http://www.owenrudge.net/

June 28, 2012

Re: [2/2] msvcp90: Sync spec files

by Piotr Caban

First patch looks correct. On 06/28/12 12:33, Owen Rudge wrote: > dlls/msvcp60/msvcp60.spec | 638 > ++++++++++++++++++++++---------------------- You can't update msvcp60.spec file this way (most of functions there should not be forwarded to msvcp90).

June 28, 2012

Re: Unused msvcp60 functions

by Piotr Caban

On 06/28/12 09:30, Francois Gouget wrote: > I get the following warnings when compiling msvcp60: > > main.c:108:51: warning: ‘std_BADOFF_func’ defined but not used [-Wunused-function] > misc.c:66:40: warning: ‘mutex_mutex_lock’ defined but not used [-Wunused-function] > misc.c:73:40: warning: ‘mutex_mutex_unlock’ defined but not used [-Wunused-function] > misc.c:80:40: warning: ‘mutex_mutex_ctor’ defined but not used [-Wunused-function] > misc.c:87:40: warning: ‘mutex_mutex_dtor’ defined but not used [-Wunused-function] > misc.c:175:58: warning: ‘set_new_handler_reset’ defined but not used [-Wunused-function] > > misc.c:127:50: warning: ‘wctype’ defined but not used [-Wunused-function] The function were not removed to make msvcp60 and msvcp90 more similar (and probably because I didn't use -Wunused-function option). Thanks to it one can copy misc.c file between the dlls when it's modified. All of these functions can be removed.

June 28, 2012

Unused msvcp60 functions

by Francois Gouget

I get the following warnings when compiling msvcp60: main.c:108:51: warning: ‘std_BADOFF_func’ defined but not used [-Wunused-function] misc.c:66:40: warning: ‘mutex_mutex_lock’ defined but not used [-Wunused-function] misc.c:73:40: warning: ‘mutex_mutex_unlock’ defined but not used [-Wunused-function] misc.c:80:40: warning: ‘mutex_mutex_ctor’ defined but not used [-Wunused-function] misc.c:87:40: warning: ‘mutex_mutex_dtor’ defined but not used [-Wunused-function] misc.c:175:58: warning: ‘set_new_handler_reset’ defined but not used [-Wunused-function] Indeed msvcp60.spec contains no _BADOFF, _Mutex or set_new_handler function. I don't see them in my 'database' of exported Windows APIs for msvcp60 but maybe the Windows dlls I built it from where not entirely up to date. Still it looks like these were added in later revisions and thus can be removed from the above files. misc.c:127:50: warning: ‘wctype’ defined but not used [-Wunused-function] This one is actually forwarded to msvcp90 according to msvcp60.spec, thus making this implementation redundant. So it should either be removed or msvcp60.spec should be modified. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

June 28, 2012

Re: po: add missing url tag to nl.po

by Francois Gouget

On Wed, 27 Jun 2012, Austin English wrote: > http://bugs.winehq.org/show_bug.cgi?id=31038 "Noot: Het wordt aanbevolen om distributiepakketten te gebruiken. Zie <a " -"href=http://wiki.winehq.org/Gecko voor details." +"href=http://wiki.winehq.org/Gecko</a> voor details." Note that this is missing a lot more than just </a>. This should be: "Noot: Het wordt aanbevolen om distributiepakketten te gebruiken. Zie <a " "href=\"http://wiki.winehq.org/Gecko\">http://wiki.winehq.org/Gecko</a> voor details." Fortunately it looks like nl is the only such case. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A polar bear is a cartesian bear after a coordinate transform.

June 28, 2012

Re: [1/5] windowscodecs: Implement MetadataHandler_GetValue. Take 2. Resend.

by Marvin

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=19631 Your paranoid android. === WVISTAADM (32 bit metadata) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

June 28, 2012

Re: [4/5] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem. Take 2.

by Dmitry Timoshkov

Marvin <testbot(a)testbot.winehq.org> wrote: > === W7PROX64 (64 bit image) === > image.c:2817: Test failed: 0: expected property size 17 or 36, got 44 > image.c:2817: Test failed: 2: expected property size 144 or 0, got 152 > image.c:2817: Test failed: 3: expected property size 20 or 0, got 28 > > === TEST64_W7SP1 (64 bit image) === > image.c:2817: Test failed: 0: expected property size 17 or 36, got 44 > image.c:2817: Test failed: 2: expected property size 144 or 0, got 152 > image.c:2817: Test failed: 3: expected property size 20 or 0, got 28 That's a propblem with 32 and 64-bit PropertyItem structure size difference, I sent another version of the patch. -- Dmitry.

June 28, 2012

Re: [5/5] gdiplus: Add a bunch of tests for TIFF image properties. Resend.

by Marvin

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=19626 Your paranoid android. === W7PROX64 (64 bit image) === image.c:2818: Test failed: 0: expected property size 17 or 36, got 44 image.c:2818: Test failed: 2: expected property size 144 or 0, got 152 image.c:2818: Test failed: 3: expected property size 20 or 0, got 28 === TEST64_W7SP1 (64 bit image) === image.c:2818: Test failed: 0: expected property size 17 or 36, got 44 image.c:2818: Test failed: 2: expected property size 144 or 0, got 152 image.c:2818: Test failed: 3: expected property size 20 or 0, got 28

June 28, 2012

Re: [4/5] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem. Take 2.

by Marvin

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=19625 Your paranoid android. === W7PROX64 (64 bit image) === image.c:2817: Test failed: 0: expected property size 17 or 36, got 44 image.c:2817: Test failed: 2: expected property size 144 or 0, got 152 image.c:2817: Test failed: 3: expected property size 20 or 0, got 28 === TEST64_W7SP1 (64 bit image) === image.c:2817: Test failed: 0: expected property size 17 or 36, got 44 image.c:2817: Test failed: 2: expected property size 144 or 0, got 152 image.c:2817: Test failed: 3: expected property size 20 or 0, got 28

June 28, 2012

Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem.

by Dmitry Timoshkov

Ben Peddell <klightspeed(a)netspace.net.au> wrote: > > Looks like testbot picked up wrong e-mail sequence. It looks like an e-mail > > delivery problem in the mailing list software, and it is getting pretty > > annoying. > > > > The winehq.org mailserver only allows one SMTP connection per relaying > IP, so emails sent at the same time are likely to be received out of > order unless the relaying mailserver only transfers emails sequentially. It doesn't explain the lost of some e-mails. For instance patch tracker may see 2 of 5 patches while http://www.winehq.org/pipermail/wine-patches lists 3 of 5. -- Dmitry.

June 28, 2012

Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem.

by Ben Peddell

On 27/06/2012 7:35 PM, Dmitry Timoshkov wrote: > Marvin <testbot(a)testbot.winehq.org> wrote: > >> === W7PROX64 (64 bit image) === >> image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 >> image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 >> image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 >> >> === TEST64_W7SP1 (64 bit image) === >> image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 >> image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 >> image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 > > Looks like testbot picked up wrong e-mail sequence. It looks like an e-mail > delivery problem in the mailing list software, and it is getting pretty > annoying. > The winehq.org mailserver only allows one SMTP connection per relaying IP, so emails sent at the same time are likely to be received out of order unless the relaying mailserver only transfers emails sequentially. -- Ben Peddell IT Support Bowen, Collinsville and Proserpine Catholic schools http://klightspeed.killerwolves.net/

June 28, 2012

Re: wbemprox: Add a Win32_LogicalDisk class stub.

by Hans Leidekker

On Wed, 2012-06-27 at 14:41 +0300, John Yani wrote: > +static void fill_logicaldisk( struct table *table ) > +{ > + static const WCHAR device_id[] = {'0',0}; > + struct record_logicaldisk *rec; > + FIXME("returns a fake logical disks table\n"); > + if (!(table->data = heap_alloc( sizeof(*rec) ))) > + { > + return; > + } > + rec = (struct record_logicaldisk *)(table->data); > + rec->device_id = heap_strdupW( device_id ); > + table->num_rows = 1; > + TRACE("created %u rows\n", table->num_rows); > +} There's no need to create a copy of device_id. Just assign it to rec->device_id and remove COL_FLAG_DYNAMIC from the column definition.

June 27, 2012

ODBC on 64bit system

by Daniel Jelinski

Hello all, Is it possible to run a 32bit application using 64bit ODBC drivers? I already checked that standard 32bit wine compilation does not work - but will it work with WoW64? I am trying to get an application to connect to SQL Server via tdsodbc, but unfortunately tdsodbc:i386 in ubuntu 11.10 is broken... Regards, Daniel

June 27, 2012

Re: [1/5] windowscodecs: Implement IWICBitmapScaler::GetSize.

by Vincent Povirk

Good point. I'll resend with parameter checking. On Wed, Jun 27, 2012 at 11:25 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> static HRESULT WINAPI BitmapScaler_GetSize(IWICBitmapScaler *iface, >> UINT *puiWidth, UINT *puiHeight) >> { >> - FIXME("(%p,%p,%p): stub\n", iface, puiWidth, puiHeight); >> + BitmapScaler *This = impl_from_IWICBitmapScaler(iface); >> + TRACE("(%p,%p,%p)\n", iface, puiWidth, puiHeight); >> >> - return E_NOTIMPL; >> + if (!This->source) >> + return WINCODEC_ERR_WRONGSTATE; >> + >> + *puiWidth = This->width; >> + *puiHeight = This->height; >> + >> + return S_OK; > > This patch and remaning patches in the sequence completely miss any > parameter checking. > > -- > Dmitry.

June 27, 2012

Re: [1/5] windowscodecs: Implement IWICBitmapScaler::GetSize.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > static HRESULT WINAPI BitmapScaler_GetSize(IWICBitmapScaler *iface, > UINT *puiWidth, UINT *puiHeight) > { > - FIXME("(%p,%p,%p): stub\n", iface, puiWidth, puiHeight); > + BitmapScaler *This = impl_from_IWICBitmapScaler(iface); > + TRACE("(%p,%p,%p)\n", iface, puiWidth, puiHeight); > > - return E_NOTIMPL; > + if (!This->source) > + return WINCODEC_ERR_WRONGSTATE; > + > + *puiWidth = This->width; > + *puiHeight = This->height; > + > + return S_OK; This patch and remaning patches in the sequence completely miss any parameter checking. -- Dmitry.

June 27, 2012

Re: d3dx9_36 [patch 2 of 3]: Implementation of D3DXSHScale

by Matteo Bruni

2012/6/27 Nozomi Kodama <nozomi.kodama(a)yahoo.com>: > -@ stub D3DXSHScale(ptr long ptr ptr) +@ stdcall D3DXSHScale(ptr long ptr ptr) ... +FLOAT* WINAPI D3DXSHScale(FLOAT *out, UINT order, CONST FLOAT *a, CONST FLOAT scale) The last parameter doesn't match between the function prototype and the spec entry. Also, apparently MSDN agrees with your prototype, while the docs in the last DirectX SDK have a pointer there. I guess the tests demonstrate that the parameter is actually a plain float... + for (i = 0; i < 100; i++) + { + a[i] = (FLOAT)i; + b[i] = (FLOAT)i; + } No need to cast. + D3DXSHScale(b, order, a, 5.0f); Not important, but you could also verify that the returned pointer is == b. +/* D3DXSHScale does not modify the elements of the array after the order * order-th element */ Can you please indent those comments? + return; +} That's not needed at all. Also, while you're at it, you should probably merge the two for loops in the test, like Francois did in http://www.winehq.org/pipermail/wine-patches/2012-June/115464.html

June 27, 2012

Re: wbemprox: Add a Win32_LogicalDisk class stub.

by Hans Leidekker

On Wed, 2012-06-27 at 11:34 +0300, John Yani wrote: > +static void fill_logicaldisk( struct table *table ) > +{ > + static const WCHAR fmtW[] = {'%','u',0}; > + WCHAR device_id[11]; > + struct record_logicaldisk *rec; > + UINT num_rows = 1; > + FIXME("returns a fake logical disks table\n"); > + if (!(table->data = heap_alloc( sizeof(*rec) * num_rows ))) > + { > + return; > + } > + rec = (struct record_networkadapter *)(table->data); This should be (struct record_logicaldisk *)(table->data); > + sprintfW( device_id, fmtW, 0 ); > + rec->device_id = heap_strdupW( device_id ); > + > + TRACE("created %u rows\n", num_rows); > + table->num_rows = num_rows; > +} You don't need the num_rows variable since it's a fixed value. You also don't need to build the device id, it can just be a static string.

June 27, 2012

Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Marvin <testbot(a)testbot.winehq.org> wrote: > > > === W7PROX64 (64 bit image) === > > image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 > > image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 > > image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 > > > > === TEST64_W7SP1 (64 bit image) === > > image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 > > image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 > > image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 > > Looks like testbot picked up wrong e-mail sequence. It looks like an e-mail > delivery problem in the mailing list software, and it is getting pretty > annoying. Just in case sent precompiled version of the tests to testbot once again, and they passed: https://testbot.winehq.org/JobDetails.pl?Key=19596 -- Dmitry.

June 27, 2012

Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem.

by Dmitry Timoshkov

Marvin <testbot(a)testbot.winehq.org> wrote: > === W7PROX64 (64 bit image) === > image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 > image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 > image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 > > === TEST64_W7SP1 (64 bit image) === > image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 > image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 > image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 Looks like testbot picked up wrong e-mail sequence. It looks like an e-mail delivery problem in the mailing list software, and it is getting pretty annoying. -- Dmitry.

June 27, 2012

Re: [4/4] gdiplus: Add a bunch of tests for TIFF image properties.

by Marvin

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=19595 Your paranoid android. === W7PROX64 (64 bit image) === image.c:2812: Test failed: 0: expected property size 17 or 36, got 44 image.c:2812: Test failed: 2: expected property size 144 or 0, got 152 image.c:2812: Test failed: 3: expected property size 20 or 0, got 28 === TEST64_W7SP1 (64 bit image) === image.c:2812: Test failed: 0: expected property size 17 or 36, got 44 image.c:2812: Test failed: 2: expected property size 144 or 0, got 152 image.c:2812: Test failed: 3: expected property size 20 or 0, got 28

June 27, 2012

Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem.

by Marvin

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=19594 Your paranoid android. === W7PROX64 (64 bit image) === image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 image.c:2811: Test failed: 3: expected property size 20 or 0, got 28 === TEST64_W7SP1 (64 bit image) === image.c:2811: Test failed: 0: expected property size 17 or 36, got 44 image.c:2811: Test failed: 2: expected property size 144 or 0, got 152 image.c:2811: Test failed: 3: expected property size 20 or 0, got 28

June 27, 2012

Re: d3dx9_36 [patch 3 of 3]: Implementation of D3DXSHMultiply2

by Marvin

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

June 27, 2012

Re: d3dx9_36 [patch 2 of 3]: Implementation of D3DXSHScale

by Marvin

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

June 27, 2012

Re: [PATCH 4/4] qedit: Support COM aggregation for SampleGrabber.

by Michael Stefaniuc

On 06/27/2012 12:02 AM, Marvin wrote: > 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? No qedit.dll on those two boxes. > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=19578 > > Your paranoid android. > > > === WNT4WSSP6 (32 bit mediadet) === > mediadet.c:148: Test failed: CoCreateInstance failed: 80040154 > mediadet.c:356: Test failed: CoCreateInstance failed: 80040154 > mediadet: unhandled exception c0000005 at 00401639 > > === W2KPROSP4 (32 bit mediadet) === > mediadet.c:148: Test failed: CoCreateInstance failed: 80040154 > mediadet.c:356: Test failed: CoCreateInstance failed: 80040154 > mediadet: unhandled exception c0000005 at 00401639 > bye michael

June 26, 2012

Re: [PATCH 4/4] qedit: Support COM aggregation for SampleGrabber.

by Marvin

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=19578 Your paranoid android. === WNT4WSSP6 (32 bit mediadet) === mediadet.c:148: Test failed: CoCreateInstance failed: 80040154 mediadet.c:356: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 00401639 === W2KPROSP4 (32 bit mediadet) === mediadet.c:148: Test failed: CoCreateInstance failed: 80040154 mediadet.c:356: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 00401639

June 26, 2012

Re: [PATCH 3/4] qedit/tests: Add COM aggregation test for MediaDet.

by Michael Stefaniuc

Argh! Please skip this patch, it is incomplete and just skips the rest of the tests on Wine. I'll resubmit it when I implement COM aggregation for MediaDet. Patch 4/4 can be still applied as it doesn't depends on this. bye michael On 06/26/2012 11:53 PM, Michael Stefaniuc wrote: > --- > dlls/qedit/tests/mediadet.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/dlls/qedit/tests/mediadet.c b/dlls/qedit/tests/mediadet.c > index 1d9a2f1..1d75680 100644 > --- a/dlls/qedit/tests/mediadet.c > +++ b/dlls/qedit/tests/mediadet.c > @@ -132,6 +132,7 @@ static BOOL init_tests(void) > static void test_mediadet(void) > { > HRESULT hr; > + struct unk_impl unk_obj = {{&unk_vtbl}, 19, NULL}; > IMediaDet *pM = NULL; > BSTR filename = NULL; > LONG nstrms = 0; > @@ -141,6 +142,12 @@ static void test_mediadet(void) > int flags; > int i; > > + /* COM aggregation */ > + hr = CoCreateInstance(&CLSID_MediaDet, &unk_obj.IUnknown_iface, CLSCTX_INPROC_SERVER, > + &IID_IUnknown, (void**)&unk_obj.inner_unk); > + todo_wine ok(hr == S_OK, "CoCreateInstance failed: %08x\n", hr); > + if (hr != S_OK) return; > + > /* test.avi has one video stream. */ > hr = CoCreateInstance(&CLSID_MediaDet, NULL, CLSCTX_INPROC_SERVER, > &IID_IMediaDet, (LPVOID*)&pM);

June 26, 2012

Re: [PATCH 3/4] qedit/tests: Add COM aggregation test for MediaDet.

by Marvin

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=19577 Your paranoid android. === WNT4WSSP6 (32 bit mediadet) === mediadet.c:148: Test failed: CoCreateInstance failed: 80040154 mediadet.c:356: Test failed: CoCreateInstance failed: 80040154 === W2KPROSP4 (32 bit mediadet) === mediadet.c:148: Test failed: CoCreateInstance failed: 80040154 mediadet.c:356: Test failed: CoCreateInstance failed: 80040154

June 26, 2012

Re: kernel32: Change LCMapStringW to LCMapStringEx and call it from LCMapStringW (try 2)

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -2625,6 +2641,28 @@ INT WINAPI LCMapStringW(LCID lcid, DWORD flags, LPCWSTR src, INT srclen, > } > > /************************************************************************* > + * LCMapStringW (KERNEL32.@) > + * > + * See LCMapStringA. > + */ > +INT WINAPI LCMapStringW(LCID lcid, DWORD flags, LPCWSTR src, INT srclen, > + LPWSTR dst, INT dstlen) > +{ > + WCHAR locale[LOCALE_NAME_MAX_LENGTH]; > + > + TRACE("(0x%04x,0x%08x,%s,%d,%p,%d)\n", > + lcid, flags, debugstr_wn(src, srclen), srclen, dst, dstlen); > + > + if (!LCIDToLocaleName(lcid, locale, LOCALE_NAME_MAX_LENGTH, 0)) > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + return 0; > + } I don't think it makes sense to do name conversion for a parameter that isn't used. If we use it someday it will most likely be to look up a conversion table directly from the lcid. -- Alexandre Julliard julliard(a)winehq.org

June 26, 2012

Re: configure: Add -linotify when present, for non-Linux platforms.

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > A FreeBSD user ran into this when sys/inotify.h was present via an > extra package and Wine went ahead using that, only to fail at link- > time. We'd want to use kqueue instead on FreeBSD. -- Alexandre Julliard julliard(a)winehq.org

June 26, 2012

Re: windowscodecs: Implement MetadataHandler_GetValue.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > + case VT_I8: > > + case VT_UI8: > > + case VT_R8: > > + return v1->u.uhVal.QuadPart - v2->u.uhVal.QuadPart; > > Won't this only compare the low part on x86? In reality the only possible variant type supposed to be seen by this helper is VT_UI2, everything else is just for the sake of completeness. -- Dmitry.

June 26, 2012

Re: windowscodecs: Implement MetadataHandler_GetValue.

by Vincent Povirk

> + case VT_I8: > + case VT_UI8: > + case VT_R8: > + return v1->u.uhVal.QuadPart - v2->u.uhVal.QuadPart; Won't this only compare the low part on x86?

June 26, 2012

Re: [PATCH 3/5] secur32: Handle incomplete messages in schan_InitializeSecurityContextW().

by Marvin

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=19560 Your paranoid android. === WNT4WSSP6 (32 bit schannel) === schannel.c:702: Test failed: Got unexpected status 0x80090308.

June 26, 2012

[PATCH] winepulse.drv: Add PulseAudio driver

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

Hi, >If you don't paste all the mmdevapi tests with the fix in my git tree, it's a >regression. I don't want to see held_Frames because it's a shadow buffer. >If winmm and dsound don't work without it, they're wrong, fix those. I won't comment on the two individual pulseaudio drivers. Unfortunately, none of the two authors bothered to point me to a verbose log of the mmdevapi tests for my scrutiny. The tests should pass like they do on native. Regarding latency, I'm not aware of a flaw in Wine's winmm. HOWEVER, Wine's DSound needs a patch. Here the reason. To recap, latency is somehow related to the "distance" between what one hears and the PCM frames sent to the device. GetPosition is the only API call in that area in both winmm and mmdevapi. Buffer size is a completely different thing. I find it useful to have in mind a cascade of audio filters performing some buffering each. Then it's obvious that an app only sees the frontmost buffer size and knows nothing about the others. High latencies imply that there must be some large buffer space(s), somewhere. Period is an artificial entity related to how often the frontmost buffer is drained to feed the next buffer in the chain, in case that happens regularly. This is not guaranteed nor necessarily documented. You get the idea: regardless of arbitrary (front) buffer sizes and periods not worth this name, try and send a stable flow of data to play music without glitches and let explosions be heard ASAP. So far the situation, now the issue. It appears easier to write code that provides (frontmost) buffer space behaviour similar to native than one that provides similar latency. Alas, behaviour observable on MS-Windows differs from what we get with PulseAudio and some ALSA devices. Tests seem to indicate a latency of around 30-70ms from mmdevapi with MS-Windows. That good enough for games. OTOH if ALSA or PA gives us 2 seconds on Linux, that's a big cause of trouble. The authors of MS apps could never test them in an environment with such high latency. What happens with software not tested? It happens not to work. Two solutions: - Reduce actual latency or - lie about latency. Lying about latency causes apps to loose the ability to sync audio and video. However, given a choice between loss of lip sync and possible crashes or other weird behaviour because an app is executed in a environment that its developers never experienced, I consider the loss of lip sync to be less worrying. We designed the winealsa driver to accomodate an arbitrary latency and accept a large variation of periods. (Some bug report from Jack users seem to imply that it should accept even larger periods, e.g. 150ms, yet still pretend to use 10ms on the mmdevapi side). We choose to have the winealsa driver not lie about latency. That should be left to high level APIs. DirectSound is built around the "Direct" HW (lack of) abstraction: a circular buffer of samples is played by a DAC. The converted signal is immediately sent to the speaker. Hence: 1. GetPosition information in the DSound abstraction translates to a "playpos" -- well known. 2. No provision is made for additional buffering. The playpos must lie within the circular buffer. The reported free (writable) space shall never cross the playpos -- with subtle consequences. Wine's DSound needs a patch to ensure this second property. Given a 80ms primary buffer, Wine's DSound must not pretend its playpos is 2 seconds late! I think Wine should try and reduce latency but lie if that does not suffice. What's needed? 1. Have DSound always use a buffer large enough for typical situations (I believe 100-200ms). 2. Clamp the reported position such that it won't leave the (virtual) primary buffer. As a result, DSound must pretend to play even when Wine is solely pumping the huge 2s of cascading SW audio buffers. 3. Work on reducing the latency of the cascading audio filters. That device-level work is independent on the DSound one. Native's 30-70ms has the benefit that it nicely fits within typical DSound primary buffer sizes. PulseAudio's 2s does not (yet). I believe a total 80ms latency would be acceptable with games. Further areas of investigation and effort: - Maybe clamp latency in the mmdevapi drivers after all? After all, huge latencies are known to cause dead-locks in apps and we don't know what all apps or libraries built atop mmdevapi or winmm expect. (If yes, to what value? 150% buffer size?) - Try and find MS setups with huge latencies. USB headphones are said to be candidates, but I've yet to see an excellent and trustworthy report about what happens in that case. - Work on reducing the cascades of audio buffers - Work on further decoupling mmdevapi periods from UNIX audio API ones - Research the trade-off between glitch free playback and buffering in UNIX. The current settings in Wine's audio are IMHO not good enough yet. Regards, Jörg Höhle

June 26, 2012

Re: urlmon: Do not stop binding when OnDataAvailable() returns E_PENDING

by Jacek Caban

On 06/26/12 00:02, Andrew Talbot wrote: > Changelog: > urlmon: Do not stop binding when OnDataAvailable() returns E_PENDING. > > diff --git a/dlls/urlmon/binding.c b/dlls/urlmon/binding.c > index 58aed20..42eca4b 100644 > --- a/dlls/urlmon/binding.c > +++ b/dlls/urlmon/binding.c > @@ -1097,7 +1097,7 @@ static void report_data(Binding *This, DWORD bscf, ULONG progress, ULONG progres > > hres = IBindStatusCallback_OnDataAvailable(This->callback, bscf, progress, > &formatetc, &stgmed); > - if(hres != S_OK) { > + if(FAILED(hres) && hres != E_PENDING) { > if(This->download_state != END_DOWNLOAD) { > This->download_state = END_DOWNLOAD; > IBindStatusCallback_OnProgress(This->callback, progress, progress_max, Please add a test case. You may modify one of existing binding tests to use E_PENDING. Jacek

June 26, 2012

Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?

by Daniel Jelinski

I don't know about compiling, but there are several other reasons to keep waiting, listed here: http://forum.winehq.org/viewtopic.php?t=15802 Regards, Daniel 2012/6/25, Erich E. Hoover <ehoover(a)mymail.mines.edu>: > I know that for a while there were some packaging problems that meant that > upgrading to 12.04 made compiling 32-bit Wine on a 64-bit PC extremely > difficult. Is this still the case? I'd like to upgrade to the new OS > version, but I'm not willing to sacrifice the ability to build Wine in > order to do so. Thanks in advance! > > Erich Hoover > ehoover(a)mines.edu >

June 26, 2012

Re: [PATCH] opengl32: Disable wglGetProcAddress for core GL 1.0/1.1 functions

by Roderick Colenbrander

On Mon, Jun 25, 2012 at 10:40 PM, Marvin <testbot(a)testbot.winehq.org> wrote: > 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=19550 > > Your paranoid android. > > > === WINEBUILD (build) === > Patch failed to apply I don't think the test-bot didn't picked up the patch since the file it links to on the page is empty. Roderick

June 26, 2012

Re: [PATCH] opengl32: Disable wglGetProcAddress for core GL 1.0/1.1 functions

by Marvin

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

June 26, 2012

Re: change wording of ok()-messages in winspool-tests?

by Julian Rüger

Francois Gouget wrote: > > > > Do you think it's worth changing these? > > Not necessarily. The only thing I'd feel like changing would be to [...] Alexandre Julliard wrote: > Test failure messages are not supposed to be seen, if they are seen it's > a bug. So it's not worth spending effort making them look nice or > consistent. OK, I won't bother then ;) Thanks a lot for your comments!

June 26, 2012

Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?

by Alex Henrie

2012/6/25 Erich E. Hoover <ehoover(a)mymail.mines.edu>: > I know that for a while there were some packaging problems that meant that > upgrading to 12.04 made compiling 32-bit Wine on a 64-bit PC extremely > difficult. Is this still the case? I've spent several hours on this over the past few days and rewrote the wiki page with instructions for using chroot: http://wiki.winehq.org/WineOn64bit It seems to work fine now. Good luck! -Alex

June 26, 2012

Re: change wording of ok()-messages in winspool-tests?

by Francois Gouget

On Sun, 24 Jun 2012, Julian Rüger wrote: [...] > ok( !retval, "function result wrong! False expected\n"); > or > ok( size == exact, "Parameter size wrong! %d expected got %d\n", > exact, size); > > > Do you think it's worth changing these? Not necessarily. The only thing I'd feel like changing would be to include the function name in the message. That said if the test fails you get the line number and thus can inspect the code to figure it out (and most likely you'll have to inspect the code anyway). I just feel like it's nice to know what function was tested just by looking at the message. [...] > Do we have guidelines for strings like these? > For example: start with a captial letter, no punctuation at the end... > > What tests have "good" style I can use as reference? We don't have guidelines for this. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

June 25, 2012

Re: Building WoW64 packages

by Marcus Meissner

On Mon, Jun 25, 2012 at 11:21:33PM +0200, Hilko Bengen wrote: > Hi, > > after the effort on the Debian wine packages has progressed to a point > where it's likely that we'll release wheezy with a stable wine version > that is not completely out of date, I'd like to take things a step > further. > > I recently spent some time looking at ways how we could build Debian > packages for a shared WoW64 setup similar to what is described in > http://wiki.winehq.org/Wine64. We will have to use separate build > environments because having 32-bit and 64-bit -dev packages installed at > the same time is not possible. Installing a 64-bit package that contains > the build tools into a 32-bit environment should be possible, though. This is not necessary. > From looking at the build system, things happen in a different way when > I run configure for the 32-bit components with --wine64=...: > > 1. Manpages are not installed (WOW64_DISABLE) > 2. --disable-fonts is implied > 3. --disable-server is implied, so wineserver is not built. (The 64-bit > wineserver is used instead, right?) Correct. > 4. --disable-tools is implied because the existing build tools are being > used. > Did I miss anything? > > Leaving parts out is easy to understand, but how do the build tools that > have been built for the x86_64 architecture affect the 32-bit components > that are being built with them? Are different paths encoded into > libwine? Not really ... you can create 32bit and 64bit built Wine packages without having cross dependencies. You just need to pack less files for the 32bit one if you use it with a 64 prefix. So for 32bit, do not use --with-wine64, just package the relevant things for the -32bit build. What is needed from the 32bit build in a WoW context is: /usr/bin/wine /usr/bin/wine-preloader /usr/lib/wine/fakedlls/* /usr/lib/libwine*.so* /usr/lib/wine/*.so* and for development additionally: /usr/lib/wine/*.def Ciao, Marcus

June 25, 2012

Building WoW64 packages

by Hilko Bengen

Hi, after the effort on the Debian wine packages has progressed to a point where it's likely that we'll release wheezy with a stable wine version that is not completely out of date, I'd like to take things a step further. I recently spent some time looking at ways how we could build Debian packages for a shared WoW64 setup similar to what is described in http://wiki.winehq.org/Wine64. We will have to use separate build environments because having 32-bit and 64-bit -dev packages installed at the same time is not possible. Installing a 64-bit package that contains the build tools into a 32-bit environment should be possible, though. >From looking at the build system, things happen in a different way when I run configure for the 32-bit components with --wine64=...: 1. Manpages are not installed (WOW64_DISABLE) 2. --disable-fonts is implied 3. --disable-server is implied, so wineserver is not built. (The 64-bit wineserver is used instead, right?) 4. --disable-tools is implied because the existing build tools are being used. Did I miss anything? Leaving parts out is easy to understand, but how do the build tools that have been built for the x86_64 architecture affect the 32-bit components that are being built with them? Are different paths encoded into libwine? Cheers, -Hilko

June 25, 2012

Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?

by Julius Schwartzenberg

André Hentschel wrote: > Am 25.06.2012 19:29, schrieb Erich E. Hoover: > You should wait until Scott Ritchie gives green light here. I blindly upgraded and it was a mess, so don't hurt yourself. I'm now back at 11.04 and that's pretty comfort, i also really dislike every non-gnome2 desktop, most likely i'll switch to cinnamon desktop at some point. Ubuntu 12.04 is still buggy in general (but not crashy!). Most of the reported bugs have not been fixed yet. I would also recommend waiting at least for 12.04.1 before considering it again.

June 25, 2012

Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?

by Joey Yandle

> I know that for a while there were some packaging problems that meant > that upgrading to 12.04 made compiling 32-bit Wine on a 64-bit PC > extremely difficult. I was able to patch and build 32-bit wine on 64-bit 12.04, using a debootstrap chroot: https://help.ubuntu.com/community/DebootstrapChroot/ Setting up the chroot took a couple of minutes, and was trivial to do. However, there appears to be a bug in wine or ubuntu which prevents SW:TOR from forking the display process, so I can't actually use wine on 12.04 to play the game I want. But building custom wine works fine. cheers, Joey

June 25, 2012

Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?

by André Hentschel

Am 25.06.2012 19:29, schrieb Erich E. Hoover: > I know that for a while there were some packaging problems that meant that upgrading to 12.04 made compiling 32-bit Wine on a 64-bit PC extremely difficult. Is this still the case? I'd like to upgrade to the new OS version, but I'm not willing to sacrifice the ability to build Wine in order to do so. Thanks in advance! > You should wait until Scott Ritchie gives green light here. I blindly upgraded and it was a mess, so don't hurt yourself. I'm now back at 11.04 and that's pretty comfort, i also really dislike every non-gnome2 desktop, most likely i'll switch to cinnamon desktop at some point. -- Best Regards, André Hentschel

June 25, 2012

Is it safe yet for developers to upgrade to Ubuntu 12.04?

by Erich E. Hoover

I know that for a while there were some packaging problems that meant that upgrading to 12.04 made compiling 32-bit Wine on a 64-bit PC extremely difficult. Is this still the case? I'd like to upgrade to the new OS version, but I'm not willing to sacrifice the ability to build Wine in order to do so. Thanks in advance! Erich Hoover ehoover(a)mines.edu

June 25, 2012

Re: [PATCH 2/2] opengl32: Check for valid context in wglGetProcAddress

by Roderick Colenbrander

On Mon, Jun 25, 2012 at 1:22 AM, Chris Robinson <chris.kcat(a)gmail.com> wrote: > On Sunday, June 24, 2012 10:42:11 PM Roderick Colenbrander wrote: >> @@ -797,7 +797,7 @@ static void test_getprocaddress(HDC hdc) >> /* Temporarily disable the context, so we can see that we can't >> retrieve functions now. */ wglMakeCurrent(hdc, NULL); >> func = wglGetProcAddress("glActiveTextureARB"); >> - todo_wine ok(func == NULL, "Function lookup without a context passed, >> expected a failure; last error %#x\n", GetLastError()); >> + ok(func == NULL, "Function lookup without a context passed, expected a >> failure; last error %#x\n", GetLastError()); >> wglMakeCurrent(hdc, ctx); >> } > > Does this apply to all functions, or just the ones MS's DLL doesn't implement? > I could imagine wlgGetProcAddress still returning functions that are in > opengl32.dll without worrying about the driver. > > >From what I remember wglGetProcAddress doesn't return <GL1.1 functions which are in opengl32.dll. I can easily add a test for this. Roderick

June 25, 2012

Re: [3/5] gdiplus: Implement GdipGetPropertyIdList.

by Nikolay Sivov

On 6/25/2012 14:30, Dmitry Timoshkov wrote: > + > + return hr == S_OK ? Ok : hresult_to_status(hr); > } > No need for special case for S_OK here.

June 25, 2012

Re: [PATCH 2/2] opengl32: Check for valid context in wglGetProcAddress

by Chris Robinson

On Sunday, June 24, 2012 10:42:11 PM Roderick Colenbrander wrote: > @@ -797,7 +797,7 @@ static void test_getprocaddress(HDC hdc) > /* Temporarily disable the context, so we can see that we can't > retrieve functions now. */ wglMakeCurrent(hdc, NULL); > func = wglGetProcAddress("glActiveTextureARB"); > - todo_wine ok(func == NULL, "Function lookup without a context passed, > expected a failure; last error %#x\n", GetLastError()); > + ok(func == NULL, "Function lookup without a context passed, expected a > failure; last error %#x\n", GetLastError()); > wglMakeCurrent(hdc, ctx); > } Does this apply to all functions, or just the ones MS's DLL doesn't implement? I could imagine wlgGetProcAddress still returning functions that are in opengl32.dll without worrying about the driver.

June 25, 2012

Re: change wording of ok()-messages in winspool-tests?

by Alexandre Julliard

Julian Rüger <jr98(a)gmx.net> writes: > Hi Francois and list, > > [/nitpick-mode on] > I'm preparing a patch to fix typos/spelling/grammar in > dlls/winspool.drv/tests/info.c, where I stumbled across repeated > messages like > > ok( !retval, "function result wrong! False expected\n"); > or > ok( size == exact, "Parameter size wrong! %d expected got %d\n", > exact, size); > > > Do you think it's worth changing these? > (I think "Wrong function result: 'false' expected\n", and "Wrong > parameter size: expected %d, got %d\n" would be better) > > Do we have guidelines for strings like these? > For example: start with a captial letter, no punctuation at the end... > > What tests have "good" style I can use as reference? > > Best regards, > Julian > > PS: Am I bike shedding here? Does anyone care about stuff like this? Test failure messages are not supposed to be seen, if they are seen it's a bug. So it's not worth spending effort making them look nice or consistent. -- Alexandre Julliard julliard(a)winehq.org

June 25, 2012

Re: [3/3] d3drm: Implement IDirect3DRMMeshBuilderX_GetClassName

by Marvin

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

June 24, 2012

Re: [2/3] d3drm: Implement IDirect3DRMLight_GetClassName

by Marvin

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

June 24, 2012

Re: [2/2] msxml3: Support xmlns[:*] attribute nodes intelligently.

by Ulrik Dickow

Hello again Nikolay and others, I'm back online. The first attachment is try 2 of the second patch, i.e. the one discussed in this thread. I hope it meets all of your concerns. I adjusted my plan slightly at this point: Den 12-06-2012 13:55, Ulrik Dickow skrev: > Den 12-06-2012 13:21, Nikolay Sivov skrev: >> On 6/12/2012 11:55, Ulrik Dickow wrote: >>> Patch 2 of 2 from http://bugs.winehq.org/show_bug.cgi?id=26226 . >>> [...] >>> + /* Emit appropriate fixme or warning in case of unsupported or invalid namespace. >>> [...] >> The question is more like what libxml2 thinks about that. If it follows >> w3c here which is likely the question will be - won't it break somewhere >> internally in libxml2 code if we hack it that way? > [...] > But maybe you are right that it is safer to return E_INVALIDARG, as I > did in an earlier version, to guard against future increased > intelligence in libxml2. Both of the applications in bug 26226 use the > correct W3C namespace, so they don't care. I'll change it back. The new patch returns E_NOTIMPL instead. That seems more appropriate to me, knowing that native msxml3 returns S_OK (like the first version of my patch) and that we will have to change it back if it turns out to break a real-life application. Evil apps that try to break us intentionally don't count :). The new patch gives exactly the same output for the tst-msxml_make_soap.c program as the old one. Consistent with this test, it also still succesfully fixes bug 26226 for BridgeCentral: BridgeCentral's SOAP requests again succeed perfectly. The new patch changes the output of the tst-msxml_xmlns_simple.c program. The new E_NOTIMPL behaviour actually made the original program crash because I failed to do proper error checking (see second attachment if you like, patch relative to the C attached to bugzilla). The new output of the fixed tst-msxml_xmlns_simple.c is in the third attachment. The differences to the old wine patch are in test 03 (only the FIXME text changed) and in test 04 (FAILures instead of ok, and now quite detailed FIXME texts instead of more general, invisible warnings). Of course, only the first attachment will be sent to wine-patches, and only if no objections appear here to prevent it. - Ulrik

June 24, 2012

change wording of ok()-messages in winspool-tests?

by Julian Rüger

Hi Francois and list, [/nitpick-mode on] I'm preparing a patch to fix typos/spelling/grammar in dlls/winspool.drv/tests/info.c, where I stumbled across repeated messages like ok( !retval, "function result wrong! False expected\n"); or ok( size == exact, "Parameter size wrong! %d expected got %d\n", exact, size); Do you think it's worth changing these? (I think "Wrong function result: 'false' expected\n", and "Wrong parameter size: expected %d, got %d\n" would be better) Do we have guidelines for strings like these? For example: start with a captial letter, no punctuation at the end... What tests have "good" style I can use as reference? Best regards, Julian PS: Am I bike shedding here? Does anyone care about stuff like this? Sorry for wasting your time ;)

June 24, 2012

Re: Incompatibility in Kernel32

by Ben Peddell

On 22/06/2012 7:23 PM, robert.van.herk(a)serioustoys.com wrote: >>> Is there any reason that you call DeleteFile() on a still being opened file? >> >> That's the whole point of this test. The observed behavior is that you can pass a >> filename to MsiRecordSetStream, successfully delete the file, and keep on using the >> stream. > > I think DeleteFile on a opened file is officially allowed in Windows. Although the MS documentation is vague: > > <QUOTE> > The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file. > > The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. > </QUOTE> The first statement is true under the DOS-based Windows systems - DeleteFile fails with ERROR_ACCESS_DENIED when that file has one or more open file handles. The second statement is true under the NT Windows systems - DeleteFile will fail with ERROR_SHARING_VIOLATION if at least one handle to it isn't opened with FILE_SHARE_DELETE, and ERROR_ACCESS_DENIED if it has a memory mapping. Results from the attached test under Windows 7 x64: Testing with no sharing, same process and no file mapping DeleteFile: Failed : 00000020 Done Testing with FILE_SHARE_DELETE, same process and no file mapping DeleteFile: OK Done Testing with no sharing, separate process and no file mapping DeleteFile: Failed : 00000020 Done Testing with FILE_SHARE_DELETE, separate process and no file mapping DeleteFile: OK Done Testing with no sharing, same process and file mapping DeleteFile: Failed : 00000020 Done Testing with FILE_SHARE_DELETE, same process and file mapping DeleteFile: Failed : 00000005 Done Testing with no sharing, separate process and file mapping DeleteFile: Failed : 00000020 Done Testing with FILE_SHARE_DELETE, separate process and file mapping DeleteFile: Failed : 00000005 Done Results from the attached test under Windows 98 SE: Testing with no sharing, same process and no file mapping DeleteFile: Failed : 00000005 Done Testing with FILE_SHARE_DELETE, same process and no file mapping CreateFile failed : 00000057 DeleteFile: OK Done Testing with no sharing, separate process and no file mapping DeleteFile: Failed : 00000005 Done Testing with FILE_SHARE_DELETE, separate process and no file mapping CreateFile failed : 00000057 DeleteFile: OK Done Testing with no sharing, same process and file mapping DeleteFile: Failed : 00000005 Done Testing with FILE_SHARE_DELETE, same process and file mapping CreateFile failed : 00000057 DeleteFile: OK Done Testing with no sharing, separate process and file mapping DeleteFile: Failed : 00000005 Done Testing with FILE_SHARE_DELETE, separate process and file mapping CreateFile failed : 00000057 DeleteFile: OK Done -- Ben Peddell IT Support Bowen, Collinsville and Proserpine Catholic schools http://klightspeed.killerwolves.net/

June 23, 2012

Re: MSVCP60.dll

by Bruno Jesus

On Fri, Jun 22, 2012 at 5:27 PM, John Emmas <johne53(a)tiscali.co.uk> wrote: > On 22 Jun 2012, at 20:17, Bruno Jesus wrote: >>> ... >>> BACKTRACE FOLLOWS:- >>> Unhandled exception: unimplemented function msvcp60.dll.??0Init(a)ios_base@std@@QAE(a)XZ called in 32-bit code (0x7b83aed2). >> >> This problem is already reported in http://bugs.winehq.org/show_bug.cgi?id=27109 >> > > Thanks Bruno, > > The problem seems to have been around for a very long time. Is it proving difficult to track down or something? I don't know, maybe someone else can answer that. What I know is that Piotr Caban is the one behind most of msvcp* bug resolutions. Bruno

June 22, 2012

Re: MSVCP60.dll

by John Emmas

On 22 Jun 2012, at 20:17, Bruno Jesus wrote: > On Fri, Jun 22, 2012 at 3:38 PM, John Emmas <johne53(a)tiscali.co.uk> wrote: >> ... >> BACKTRACE FOLLOWS:- >> Unhandled exception: unimplemented function msvcp60.dll.??0Init(a)ios_base@std@@QAE(a)XZ called in 32-bit code (0x7b83aed2). > > This problem is already reported in http://bugs.winehq.org/show_bug.cgi?id=27109 > Thanks Bruno, The problem seems to have been around for a very long time. Is it proving difficult to track down or something? John

June 22, 2012

Re: MSVCP60.dll

by Bruno Jesus

On Fri, Jun 22, 2012 at 3:38 PM, John Emmas <johne53(a)tiscali.co.uk> wrote: > If anyone thinks of any useful information I'll add it to the bug report. > ... > BACKTRACE FOLLOWS:- > Unhandled exception: unimplemented function msvcp60.dll.??0Init(a)ios_base@std@@QAE(a)XZ called in 32-bit code (0x7b83aed2). This problem is already reported in http://bugs.winehq.org/show_bug.cgi?id=27109 You could add a comment there instead of opening a new bug that could end up as being duplicate. I suggest you to get a new backtrace with wine debug symbols installed (if possible in wine 1.5.7). Best wishes, Bruno

June 22, 2012

Re: MSVCP60.dll

by John Emmas

On 15 Jun 2012, at 10:41, Michael Stefaniuc wrote: > > On 06/15/2012 06:22 AM, John Emmas wrote: >> >> Recently however, two customers tried to use it with Wine v1.5.35. In >> both cases the program crashed - apparently because some particular >> function wasn't found in MSVCP60.dll (at the moment, we don't know which >> function). > That is fairly trivial to figure out. Start your app with Wine on the > command line and it will crash with an exception: > Call from <address> to unimplemented function MSVCP60.<function> > > Once you have those please open a bug on http://bugs.winehq.org/ for > them. > Thanks Michael, That version number should have been 1.3.35 BTW, not 1.5.35. I'll file a bug report tomorrow but in the meantime it looks like the missing function is std::ios_base::Init() (it's probably the constructor for the Init class). I'm going from a backtrace that I got when I tried Crossover Linux (which exhibited the same problem). If anyone thinks of any useful information I'll add it to the bug report. John BACKTRACE FOLLOWS:- Unhandled exception: unimplemented function msvcp60.dll.??0Init(a)ios_base@std@@QAE(a)XZ called in 32-bit code (0x7b83aed2). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7b83aed2 ESP:0033fcc8 EBP:0033fd2c EFLAGS:00000212( - -- I -A- - ) EAX:7b827985 EBX:7b8961e8 ECX:00000000 EDX:80000100 ESI:80000100 EDI:004e120c Stack dump: 0x0033fcc8: 0033fd4c 00000008 7bca774c 80000100 0x0033fcd8: 00000001 00000000 7b83aed2 00000002 0x0033fce8: 7e50f460 7e51415b 00110000 00000000 0x0033fcf8: 00000000 7ee6863c 7ee6863c 00431870 0x0033fd08: 0033fd58 7ee186e9 0000000d 004ef298 0x0033fd18: 7ee6863c 7e090000 7b83ae8a 7ee6863c Backtrace: =>0 0x7b83aed2 in kernel32 (+0x2aed2) (0x0033fd2c) 1 0x7e50f3f8 in msvcp60 (+0x2f3f7) (0x0033fd5c) 2 0x7e4f4065 in msvcp60 (+0x14064) (0x0033fdc0) 3 0x00433f55 in ardourxchange (+0x33f54) (0x0033fdc0) 4 0x004a9fde in ardourxchange (+0xa9fdd) (0x0033fe70) 5 0x7b85b23c call_process_entry+0xb() in kernel32 (0x0033fe88) 6 0x7b85c40f in kernel32 (+0x4c40e) (0x0033fec8) 7 0x7bc72a70 call_thread_func_wrapper+0xb() in ntdll (0x0033fed8) 8 0x7bc7547d call_thread_func+0x7c() in ntdll (0x0033ffa8) 9 0x7bc72a4e RtlRaiseException+0x21() in ntdll (0x0033ffc8) 10 0x7bc4b8fe call_dll_entry_point+0x61d() in ntdll (0x0033ffe8) 0x7b83aed2: subl $4,%esp Modules: Module Address Debug info Name (73 modules) PE 340000- 352000 Deferred zlib1 PE 400000- 5e1000 Export ardourxchange PE 5f0000- 6c9000 Deferred iconv PE 10000000-100ee000 Deferred libxml2 PE 5f400000-5f4f2000 Deferred mfc42 PE 6f140000-6f198000 Deferred libsndfile-1 ELF 7b800000-7ba16000 Dwarf kernel32<elf> \-PE 7b810000-7ba16000 \ kernel32 ELF 7bc00000-7bcc4000 Dwarf ntdll<elf> \-PE 7bc10000-7bcc4000 \ ntdll ELF 7bf00000-7bf03000 Deferred <wine-loader> ELF 7e086000-7e0b9000 Deferred uxtheme<elf> \-PE 7e090000-7e0b9000 \ uxtheme ELF 7e0fc000-7e102000 Deferred libxfixes.so.3 ELF 7e1d8000-7e1f9000 Deferred libexpat.so.1 ELF 7e1f9000-7e224000 Deferred libfontconfig.so.1 ELF 7e224000-7e22d000 Deferred libxi.so.6 ELF 7e22d000-7e232000 Deferred libxrandr.so.2 ELF 7e232000-7e23b000 Deferred libxrender.so.1 ELF 7e23b000-7e241000 Deferred libxxf86vm.so.1 ELF 7e241000-7e262000 Deferred imm32<elf> \-PE 7e250000-7e262000 \ imm32 ELF 7e262000-7e37f000 Deferred libx11.so.6 ELF 7e37f000-7e38e000 Deferred libxext.so.6 ELF 7e38e000-7e3a7000 Deferred libice.so.6 ELF 7e3a7000-7e3b1000 Deferred libsm.so.6 ELF 7e3b1000-7e446000 Deferred winex11<elf> \-PE 7e3c0000-7e446000 \ winex11 ELF 7e446000-7e4b2000 Deferred libfreetype.so.6 ELF 7e4b5000-7e4bf000 Deferred libxcursor.so.1 ELF 7e4d2000-7e569000 Dwarf msvcp60<elf> \-PE 7e4e0000-7e569000 \ msvcp60 ELF 7e569000-7e5df000 Deferred rpcrt4<elf> \-PE 7e570000-7e5df000 \ rpcrt4 ELF 7e5df000-7e6e6000 Deferred ole32<elf> \-PE 7e600000-7e6e6000 \ ole32 ELF 7e6e6000-7e7dd000 Deferred comctl32<elf> \-PE 7e6f0000-7e7dd000 \ comctl32 ELF 7e7dd000-7e9ee000 Deferred shell32<elf> \-PE 7e7f0000-7e9ee000 \ shell32 ELF 7e9ee000-7ea58000 Deferred shlwapi<elf> \-PE 7ea00000-7ea58000 \ shlwapi ELF 7ea58000-7eb17000 Deferred gdi32<elf> \-PE 7ea60000-7eb17000 \ gdi32 ELF 7eb17000-7ec57000 Deferred user32<elf> \-PE 7eb30000-7ec57000 \ user32 ELF 7ec57000-7ec7c000 Deferred mpr<elf> \-PE 7ec60000-7ec7c000 \ mpr ELF 7ec7c000-7ec8f000 Deferred libz.so.1 ELF 7ec8f000-7ecfe000 Deferred wininet<elf> \-PE 7eca0000-7ecfe000 \ wininet ELF 7ecfe000-7ed5f000 Deferred advapi32<elf> \-PE 7ed10000-7ed5f000 \ advapi32 ELF 7ed5f000-7ed72000 Deferred libresolv.so.2 ELF 7ed76000-7ed7a000 Deferred libxinerama.so.1 ELF 7ed7a000-7ed92000 Deferred version<elf> \-PE 7ed80000-7ed92000 \ version ELF 7ed92000-7edb3000 Deferred iphlpapi<elf> \-PE 7eda0000-7edb3000 \ iphlpapi ELF 7edb3000-7ede4000 Deferred ws2_32<elf> \-PE 7edc0000-7ede4000 \ ws2_32 ELF 7ede4000-7ee72000 Deferred msvcrt<elf> \-PE 7ee00000-7ee72000 \ msvcrt ELF 7efba000-7efe0000 Deferred libm.so.6 ELF 7efe2000-7efe6000 Deferred libxau.so.6 ELF 7efe6000-7f000000 Deferred wsock32<elf> \-PE 7eff0000-7f000000 \ wsock32 ELF b7c31000-b7c37000 Deferred libxdmcp.so.6 ELF b7c39000-b7c3d000 Deferred libdl.so.2 ELF b7c3d000-b7d6b000 Deferred libc.so.6 ELF b7d6b000-b7d83000 Deferred libpthread.so.0 ELF b7da3000-b7ee5000 Dwarf libwine.so.1 ELF b7ee6000-b7f03000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 winewrapper.exe 00000009 0 0000000c services.exe 0000001d 0 0000001c 0 00000016 0 00000015 0 00000013 0 0000000e 0 0000000d 0 00000010 winedevice.exe 0000001a 0 00000017 0 00000012 0 00000011 0 00000018 plugplay.exe 0000001e 0 0000001b 0 00000019 0 0000001f explorer.exe 00000020 0 00000021 (D) C:\Program Files\ArdourXchange\ArdourXchange.exe 00000022 0 <== System information: Wine build: wine-1.4-6831-gf832abc Platform: i386 Host system: Linux Host version: 2.6.19-4-rt

June 22, 2012

Re: [1/2] windowscodecs: Implement GetPreview and GetThumbnail in the TIFF decoder.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > According to MSDN, GetPreview isn't supported on any decoder except > WMPhoto, and if that's true it should probably be returning > WINCODEC_ERR_UNSUPPORTEDOPERATION. > > And why bother with GetThumbnail if you're not going to do it > properly? At least check whether a thumbnail exists in the image > before returning something. That was to make WICExplorer happy. After looking at its source I've found that it doesn't always check return values of GetThumbnail and GetPreview, but checks for returned interface pointer instead. I'll send a proper patch. Thanks. -- Dmitry.

June 22, 2012

Re: [1/2] windowscodecs: Implement GetPreview and GetThumbnail in the TIFF decoder.

by Vincent Povirk

According to MSDN, GetPreview isn't supported on any decoder except WMPhoto, and if that's true it should probably be returning WINCODEC_ERR_UNSUPPORTEDOPERATION. And why bother with GetThumbnail if you're not going to do it properly? At least check whether a thumbnail exists in the image before returning something.

June 22, 2012

RE: Incompatibility in Kernel32

by robert.van.herk＠serioustoys.com

> > Is there any reason that you call DeleteFile() on a still being opened file? > > That's the whole point of this test. The observed behavior is that you can pass a > filename to MsiRecordSetStream, successfully delete the file, and keep on using the > stream. I think DeleteFile on a opened file is officially allowed in Windows. Although the MS documentation is vague: <QUOTE> The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file. The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. </QUOTE> These statements seem to be a bit contradictive to me, so that's why I though I'd write a test to see how Windows actually behaves, and then I found this incompatibility. Regards, Robert

June 22, 2012

Re: d3dx9_36: Implentation of D3DXSHDot

by Alexandre Julliard

Nozomi Kodama <nozomi.kodama(a)yahoo.com> writes: > +static void test_D3DXSHDot(void) > +{ > + unsigned int i; > + FLOAT a[64], b[64], got; > + CONST FLOAT expected[] = > + { 0.0f, 0.0f, 17.0f, 222.0f, 1300.0f, 5050.0f, 15225.0f, 38612.0f, 86352.0f, }; > + > + for (i = 0; i < 64; i++) > + { > + a[i] = (FLOAT)i; > + b[i] = (FLOAT)i + 0.5f; > + } You should start with a non-zero value to tests orders 0 and 1 properly. -- Alexandre Julliard julliard(a)winehq.org

June 22, 2012

Re: d3dx9_36 [patch 4 of 4, try 2]: Save multiplications

by Alexandre Julliard

Nozomi Kodama <nozomi.kodama(a)yahoo.com> writes: > @@ -1971,11 +1971,13 @@ FLOAT *WINAPI D3DXFloat16To32Array(FLOAT *pout, CONST D3DXFLOAT16 *pin, UINT n) > > FLOAT* WINAPI D3DXSHAdd(FLOAT *out, UINT order, const FLOAT *a, const FLOAT *b) > { > - UINT i; > + UINT i, sq_order; > > TRACE("out %p, order %u, a %p, b %p\n", out, order, a, b); > > - for (i = 0; i < order * order; i++) > + sq_order = order * order; > + > + for (i = 0; i < sq_order; i++) > out[i] = a[i] + b[i]; There's no reason to do that. -- Alexandre Julliard julliard(a)winehq.org

June 22, 2012

Re: wintrust/tests: Fix build with MSVC.

by Thomas Faber

On 2012-06-21 23:47, David Laight wrote: > On Thu, Jun 21, 2012 at 12:56:43PM +0200, Thomas Faber wrote: >> On 2012-06-21 12:34, Dmitry Timoshkov wrote: >>> Thomas Faber <thfabba(a)gmx.de> wrote: >>>> FIELD_OFFSET isn't constant "enough". >>> >>> The problem is not with FIELD_OFFSET, but with applying shift and mask >>> operations to a constant. >> >> You're right, it's actually a combination of multiple factors. I'm not sure >> what exactly its problem is - the gist is, FIELD_OFFSET cannot reliably be >> assumed constant. >> >> E.g. the following code only complains about c4: >> >> struct a { >> char a; >> int b[5]; >> int c; >> }; >> int c1 = (int)&(((struct a *)0)->a) << 8; >> int c2 = (int)&(((struct a *)0)->b[0]); >> int c3 = (int)&(((struct a *)0)->b[0]) + 1; >> int c4 = (int)&(((struct a *)0)->b[0]) << 8; > > This is a bug in the microsoft C compiler. > It won't let you do multiply or divide offsetof(struct, array_member[index]) > by anything and still get a compile-time constant. > The C language requires offsetof() be a compile-time constant, so this > ought to be allowed. > I couldn't find anything that looked like 'offsetof' that would generate > a real compile-time constant. > > I can't remember whether it is 'constant enough' to let you do: > static char fubar[offsetof(struct a, b[3])]; Yeah, after some reading it seems clear that it's only with array[index] as a member designator. >From reading, it also seems that offsetof should indeed be constant enough for all of these purposes - but I won't consider myself qualified to nitpick on the contents of the standard in this regard. In conclusion, assuming working around MSVC bugs like this is worth the effort (which I do think it is), FIELD_OFFSET(struct, array) + index * sizeof(type) can be used as a compatible replacement. Seems a workable alternative to me. I've submitted a new patch accordingly. -Tom

June 22, 2012

Re: d3dx9_36 [patch 1 of 4, try 2]: Implemetation of D3DXSHDot

by Dmitry Timoshkov

Hello, Please follow http://wiki.winehq.org/SubmittingPatches instructions for naming patches when sending a patch series. Usually 'git format-patch -n' will do it for you. Otherwise testbot won't recognize the series. -- Dmitry.

June 22, 2012

Re: d3dx9_36 [patch 3 of 4, try 2]: Implemetation of D3DXSHMultiply2

by Marvin

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

June 22, 2012