August 2013 - Wine-devel - list.winehq.org

Permissions bug with Acrobat X Standard
by Neil Hellfeldt 22 Aug '13

22 Aug '13

err:msi:cabinet_copy_file failed to create L"C:\\users\\Public\\Application Data\\Adobe\\Adobe PDF\\Settings\\Standard.joboptions" (error 3) err:msi:extract_cabinet FDICopy failed err:msi:ACTION_InstallFiles Failed to extract cabinet: L"Data1.cab" err:msi:ITERATE_Actions Execution halted, action L"InstallFiles" returned 1603 err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1603 Sysinfo: lubuntu 3.04 64bit WINEARCH=win32 When I go to the parent directory I find this location: ~/.local/share/wineprefixes/acrobatxstd/drive_c/users/Public/Application Data/Adobe drwxrwxr-x 3 hellfeldt hellfeldt 4.0K Aug 21 17:12 Acrobat/ dr-xr-xr-x 3 hellfeldt hellfeldt 4.0K Aug 21 17:12 Adobe PDF/ ~/.local/share/wineprefixes/acrobatxstd/drive_c/users/Public/Application Data/Adobe$ cd Adobe\ PDF/ ~/.local/share/wineprefixes/acrobatxstd/drive_c/users/Public/Application Data/Adobe/Adobe PDF$ mkdir Settings mkdir: cannot create directory ‘Settings’: Permission denied I tried changing the directory permissions and I tried creating the directory but acrobat delete the Adobe PDF directory and recreates it with the bad permissions again.

1 0

Re: [PATCH] winemac.drv: Support the public UTF-16 type for Unicode text.
by Ken Thomases 22 Aug '13

22 Aug '13

On Aug 21, 2013, at 9:42 PM, Charles Davis wrote: > @@ -90,6 +93,9 @@ static CFDataRef export_hdrop_to_filenames(HANDLE data); > static CFDataRef export_oemtext_to_utf8(HANDLE data); > static CFDataRef export_text_to_utf8(HANDLE data); > static CFDataRef export_unicodetext_to_utf8(HANDLE data); > +static CFDataRef export_oemtext_to_utf16(HANDLE data); > +static CFDataRef export_text_to_utf16(HANDLE data); > +static CFDataRef export_unicodetext_to_utf16(HANDLE data); Please keep the export_* functions sorted (although I'm fine with utf8 coming before utf16). This applies to the function definitions, too. (Yes, this is an exceedingly minor issue. Sorry.) > +static HANDLE import_utf16_to_unicodetext(CFDataRef data) > +{ > + const WCHAR *src; > + unsigned long data_len; > + unsigned long new_lines = 0; > + LPWSTR dst; > + unsigned long i, j; > + HANDLE unicode_handle = NULL; This is an unnecessary initialization / dead store, which is frowned upon. Thanks! -Ken

2 2

Re: [PATCH 6/6] wined3d: Implement basic volume location management (try 2)
by Henri Verbeet 22 Aug '13

22 Aug '13

On 22 August 2013 14:57, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (volume->locations & WINED3D_LOCATION_DISCARDED) > + { > + TRACE("Volume previously discarded, nothing to do.\n"); > + wined3d_volume_invalidate_location(volume, WINED3D_LOCATION_DISCARDED); > + } I don't think the location invalidation here is strictly required, although it probably doesn't hurt much in practice. (I.e., consider the sequence DISCARD, load SYSMEM, load TEXTURE_RGB. There's no real reason the RGB load needs to do an upload from SYSMEM in that case, although it's perhaps not something that's going to happen much in practice either way.) > + wined3d_volume_validate_location(volume, WINED3D_LOCATION_SYSMEM); You could probably just have a wined3d_volume_validate_location(volume, location); at the end of the function and return from the default case instead. That's not something I feel strongly about though.

2 1

Re: oleaut32/tests: Some tests for LoadRegTypeLib() with activated context
by Alexandre Julliard 22 Aug '13

22 Aug '13

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Some tests for LoadRegTypeLib() with activated context > > From 1ea3d8c82dd77ac14f2cdec748c0284032958b2f Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <nsivov(a)codeweavers.com> > Date: Wed, 21 Aug 2013 12:34:47 +0400 > Subject: [PATCH 5/6] Some tests for LoadRegTypeLib() with activated context It doesn't work here: ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so tmarshal.c && touch tmarshal.ok tmarshal.c:999: Test failed: LoadRegTypeLib failed with error 0x8002801d tmarshal.c:1232: Test failed: IKindaEnumWidget_Next failed with error 0x8007000e wine: Unhandled page fault on read access to 0x00000000 at address 0x68640714 (thread 003a), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 5/5] wined3d: Implement basic volume location management
by Henri Verbeet 22 Aug '13

22 Aug '13

On 22 August 2013 00:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +const char *wined3d_debug_location(DWORD location) > +{ > + char buf[238]; That number looks a bit arbitrary, although I suppose it's at least large enough. > + if (volume->resource.pool == WINED3D_POOL_SYSTEM_MEM > + || volume->resource.pool == WINED3D_POOL_SCRATCH) > + { > + if (location & ~WINED3D_LOCATION_SYSMEM) > + { > + ERR("Trying to load a sysmem or scratch volume into %s.\n", > + wined3d_debug_location(location)); > + return; > + } > + } In principle we have resource_access_from_location() and the access_flags field in struct wined3d_resource for this. It's only a warning in surface_load_location() because we load e.g. default pool surfaces into sysmem for CPU fallbacks, but that doesn't apply to volumes. The right way for surfaces would probably be to use a staging resource for CPU fallbacks instead, or something along those lines. > + if (count_bits(location) > 1) > + FIXME("Implement loading two locations with one call\n"); > + I don't think we really want that. > +static void wined3d_volume_update_location(struct wined3d_volume *volume, DWORD location, BOOL keep) > +{ > + if (keep) > + { > + TRACE("Volume %p, invalidating %s.\n", volume, > + wined3d_debug_location(volume->locations & ~location)); > + volume->locations = location; > + } > + else > + { > + TRACE("Volume %p, invalidating %s.\n", volume, wined3d_debug_location(location)); > + volume->locations &= ~location; > + } > +} I'm a bit unhappy with the "persistent" flag to surface_modify_location(), and this is essentially the same thing. I think it would be better to just have two separate functions, wined3d_volume_invalidate_location() and wined3d_volume_validate_location(). Perhaps wined3d_volume_update_location() can work too, but in that case I think it should take two location masks, one to set and one to clear.

2 8

Re: [4/4] oledb32: A basic test for IRowPosition_Initialize()
by Marvin 22 Aug '13

22 Aug '13

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=26813 Your paranoid android. === WINEBUILD (build) === Make failed

2 1

Re: gdi32: some fix of errors writing Arabic on entry boxs
by Yaron Shahrabani 22 Aug '13

22 Aug '13

Ahlan Ya Mas3ab! How can I test it with Hebrew? Yaron Shahrabani <Hebrew translator> On Wed, Aug 21, 2013 at 11:19 PM, مصعب الزعبي <moceap(a)hotmail.com> wrote: > Written By Aric Stewart , fix about 50 percent of Bug 33794 > > --- > dlls/gdi32/font.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > > >

1 0

Re: msvcrt: _[w]access_s returns an error code.
by Marvin 21 Aug '13

21 Aug '13

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=26809 Your paranoid android. === WXPX64 (32 bit msvcr90) === No test summary line found

1 0

RFC: winedev guide multimedia chapter patch
by Frédéric Delanoy 21 Aug '13

21 Aug '13

Hi guys, I've been updating the wine multimedia paths of the wine dev guide, but I'm not really familiar with that area of Wine, so could you please have a look at the attached patch to check if it seems correct? I checked the code a bit but I'm not sure how outdated the guide is. For easier "testing", just clone http://source.winehq.org/git/docs.git, apply the patch and run ./configure, then 'make winedev-guide.html' in the "en/" subdirectory. Thanks, Frédéric Delanoy

2 1

Re: [PATCH] winemac.drv: Use the public UTF-16 type for Unicode text.
by Ken Thomases 21 Aug '13

21 Aug '13

On Aug 20, 2013, at 10:49 PM, Charles Davis wrote: > In the Windows world, "Unicode" almost universally means "UTF-16". So, > use the well-known UTF-16 type instead of making up our own. > > I have to wonder if there was a good reason Ken didn't use this > initially. Please hold this patch while I review it. I think there is a good reason why I didn't use it, but I have to figure it out again. :-/ It has to do with a promised pasteboard type (what Microsoft calls delayed rendering) and the conversions to the other text types. I think we need to use a custom type to distinguish between being asked for promised data vs. being asked for a conversion. -Ken

2 2