September 2009 - Wine-devel

RFC: Sharing a wineprefix
by Paul Chitescu 29 Sep '09

29 Sep '09

Hi people! I know this has been talked about again and again and no satisfactory solution (generic, safe, somehow simple) has been found for all. This proposal aims to solve a common scenario with minimum of changes in Wine, in particular remaining compatible with existing installations. It doesn't solve all problems but a quite pressing one: have a bunch of programs installed just once and used by several users. The idea is to have two categories of users: - The Administrator: - Is the owner of the WINEPREFIX, just like now - R/W access to the prefix - Can install and uninstall programs - Exclusive lock, no other user can run in the same prefix at the same time - All others are restricted users: - R/O access to the prefix (including the machine Registry) - They can only write to their profile (including the user Registry) - Can install programs only to their profile if the installer supports so - Cannot run wine in that prefix while the Administrator runs it - Multiple restricted users can run in the same prefix at once UNIX access rights and/or symlinks will be used to: - Make sure other users cannot write to the prefix - Each user has a Wine visible path to his profile directory - Each user can create a new profile directory - or, subject to policy, the Administrator may create (but no need to populate) them in advance Required changes I've identified so far: - The R/W lock to the prefix - wineserver -k as admin should terminate all users' instances - wineserver needs to be able to load Registry hives R/O - wineboot needs to be able to create just the user's profile and ignore pending renames for restricted users - Report to application the detected type of user: Administrator / Restricted - Some winecfg settings need to be migrated from HKCU to HKLM so the admin can enforce sane values or provide proper defaults or because they are logically per prefix - The user Registry hive and the temporary directory for the restricted users need to be stored in their profile directory Advantages: - Not much coding required, less chances to introduce bugs - Will not break existing installations - No trust is required between users, only to Administrator - Each user runs its own wineserver, there is no communication between them - Solves the most common requests from users - Required step to a more complete (but dangerous) extension Disadvantages: - Single admin user - The Administrator cannot run concurrently with other users - To install or remove programs all users need to shutdown their Wine - A restricted user cannot promote to Admin just to do one action (but of course he can su, wineserver -k others, run as Administrator) - Some programs (although not many, most need just to install) need to run as Administrator - After a Wine upgrade the Administrator needs to upgrade the prefix too - All users share the view of the dosdevices (can be moved to the profile dir if we really want to) - Users cannot install programs (except some) or fonts - Doesn't allow non-simultaneous usage of the prefix by different Admins Opinions? Comments? Votes? Although most changes are not complex there is much work and this needs some political decision to proceed to actual coding.

5 5

programs: add extrac32 tool
by Kirill K. Smirnov 29 Sep '09

29 Sep '09

Hi, +int PASCAL wWinMain ( HINSTANCE hInstance, HINSTANCE prev, LPWSTR cmdline, int show ) +{ extrac32 is a console application, isn't it? Why not wmain() instead? And get rid of rather complex ParseCmdLine(). + if (!SetupIterateCabinetW( pszCabFile, 0, (PSP_FILE_CALLBACK) ExtCabCallback, 0 )) + WINE_FIXME( "Can not extract cab file:%s!!!\n", wine_dbgstr_w( pszCabFile ) ); This is an error, not a FIXME + if(!argv) + { + WINE_FIXME("Error!Can not get cmd line\n" ); + return 0; + } not a FIXME + if (argc < 2) + { + WINE_FIXME( "No options\n" ); + return 1; + } not a FIXME + if (fArgc != 1) + WINE_FIXME( "Invalid usage for /C flag - two filenames expected\n" ); not a FIXME -- Kirill

2 1

Re: [PATCH 06/12] d3d10: Implement ID3D10EffectType::GetMemberName().
by Henri Verbeet 28 Sep '09

28 Sep '09

> static LPCSTR STDMETHODCALLTYPE d3d10_effect_type_GetMemberName(ID3D10EffectType *iface, UINT index) > { > - FIXME("iface %p, index %u stub!\n", iface, index); > + struct d3d10_effect_type *This = (struct d3d10_effect_type *)iface; > > - return NULL; > + TRACE("iface %p, index %u\n", iface, index); > + > + if(index >= This->member_count) return NULL; > + > + return This->members[index].name; > } You can't do this yet, it needs to work for types created by parse_fx10_type() as well. The same goes for patches 7-11. Patches 1-5 look ok to me, and can stand on their own.

2 1

Review Request: Patch to selectively bind to interfaces while still allowing broadcast packets
by Erich Hoover 28 Sep '09

28 Sep '09

Attached is a patch I have been working to fix Bug #7929 (C&C 3 network does not work). This patch replaces interface-specific bind requests (on UDP datagrams only) with a global bind and stores the interface index. The patch then uses IP_PKTINFO to set the outgoing interface and filter incoming packets based on interface (checking against the stored interface index from the initial bind). Additionally, the patch peeks at packets in "select" and asynchronous I/O operations to ensure that spurious wakeups do not occur when a packet comes in from the wrong interface. I intend to split the patch into the following pieces: 1) UDP broadcast tests (used for making sure everything works) 2) The "bare essentials" (storing and retrieving the interface index, and setting/filtering the interface) 3) Ensure "select" does not wake up on packets with an interface mismatch 4) Ensure Async WSARecv does not wake up on packets with an interface mismatch 5) Ensure Async ReadFile does not wake up on packets with an interface mismatch I would greatly appreciate any comments people have on this patch. Thanks so much! Erich Hoover ehoover(a)mines.edu

1 0

Re: [PATCH 3/4] mshtml: Add helper function get_url_components
by Detlef Riekenberg 28 Sep '09

28 Sep '09

On Fr, 2009-09-25 at 15:30 -0500, Andrew Eikum wrote: > +static HRESULT get_url_components(HTMLLocation *This, URL_COMPONENTSW > *url) > +{ > + const WCHAR *doc_url; > + if(!InternetCrackUrlW(doc_url, 0, 0, url)) { > + FIXME("InternetCrackUrlW failed\n"); Such a FIXME does not help to find the reason. Dumping doc_url helps, but might add personal data to the log -- By by ... Detlef

2 1

Patch for [Bug 14222] RpcBindingSetAuthInfo(Ex) fails with RPC_C_AUTHN_GSS_NEGOTIATE
by Stefan Kuhr 28 Sep '09

28 Sep '09

Hello everyone, please find attached a patch for Bug 14222. IIRC I sent a similar patch a year ago or so and never received feedback why it was rejected. Austin encouraged me to send it again, so please if it is unacceptable, let me know why. The patch will make RPC clients work that are written for Windows 2000 (and later), where the negotiate provider performs an automatic fallback to NTLM, if Kerberos is not possible, both in workgroup and domain scenarios. Currently, Wine doesn't have a negotiate and a Kerberos provider. This patch allows clients requesting Negotiate to get the NTLM provider and will still work, even if one day negotiate and Kerberos providers will be added to Wine. Cheers, -- Stefan

1 0

Re: comctl32/tests: Fix monthcal test on NT4
by Greg Geldorp 28 Sep '09

28 Sep '09

Hi Nikolay, > Ge van Geldorp wrote: > > Changelog: > > comctl32/tests: Fix monthcal test on NT4 > Hi, Ge. > > This one interfere with a mine, sent yesterday: > > http://www.winehq.org/pipermail/wine-patches/2009-September/078955.html > > Could you wait a bit? I hope this could fix some failures. Sure. I'll resend after your patch is in (if my fix is still needed). Ge.

2 1

Re: d3d9: Don't release the parent device before destroying its children
by Henri Verbeet 28 Sep '09

28 Sep '09

2009/9/28 Allan Tong <actong88(a)gmail.com>: > I assume this was done to avoid referencing freed memory, but I'm not > sure if there was any other reason for this. > Not referencing potentially freed memory was the only reason. > Note that this patch only changes d3d9. > Could you write one for d3d8 as well? Otherwise I'll send one tomorrow.

2 1

Re: ole32/tests: fix clipboard tests on Windows
by Alexandre Julliard 28 Sep '09

28 Sep '09

"Ge van Geldorp" <ggeldorp(a)vmware.com> writes: > @@ -417,18 +417,23 @@ static HRESULT DataObjectImpl_CreateComplex(LPDATAOBJECT *lplpdataobj) > InitFormatEtc(obj->fmtetc[1], cf_stream, TYMED_ISTREAM); > InitFormatEtc(obj->fmtetc[2], cf_storage, TYMED_ISTORAGE); > InitFormatEtc(obj->fmtetc[3], cf_another, TYMED_ISTORAGE|TYMED_ISTREAM|TYMED_HGLOBAL); > - memset(&dm, 0, sizeof(dm)); > - dm.dmSize = sizeof(dm); > - dm.dmDriverExtra = 0; > - lstrcpyW(dm.dmDeviceName, device_name); > - obj->fmtetc[3].ptd = HeapAlloc(GetProcessHeap(), 0, FIELD_OFFSET(DVTARGETDEVICE, tdData) + sizeof(device_name) + dm.dmSize + dm.dmDriverExtra); > - obj->fmtetc[3].ptd->tdSize = FIELD_OFFSET(DVTARGETDEVICE, tdData) + sizeof(device_name) + dm.dmSize + dm.dmDriverExtra; > - obj->fmtetc[3].ptd->tdDriverNameOffset = FIELD_OFFSET(DVTARGETDEVICE, tdData); > - obj->fmtetc[3].ptd->tdDeviceNameOffset = 0; > - obj->fmtetc[3].ptd->tdPortNameOffset = 0; > - obj->fmtetc[3].ptd->tdExtDevmodeOffset = obj->fmtetc[3].ptd->tdDriverNameOffset + sizeof(device_name); > - lstrcpyW((WCHAR*)obj->fmtetc[3].ptd->tdData, device_name); > - memcpy(obj->fmtetc[3].ptd->tdData + sizeof(device_name), &dm, dm.dmSize + dm.dmDriverExtra); > + if (! broken(TRUE)) /* Windows messes up ptd when doing OleGetClipboard() */ > + { If that case is really unconditionally broken on Windows it doesn't make sense to test it at all. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 12/12] d3d10/tests: Add test_effect_constant_buffer_type test.
by Henri Verbeet 28 Sep '09

28 Sep '09

2009/9/28 Rico Schüller <kgbricola(a)web.de>: > + ID3D10Effect* effect; I'd prefer it if that was written as "ID3D10Effect *effect;" > + ok(SUCCEEDED(hr), "ID3D10EffectType::GetDesc failed!\n"); Please print the actual error code as well. > + ok(type_desc.Elements == 0, "Elements is %i, expected 0\n", type_desc.Elements); > + ok(type_desc.Members == 2, "Members is %i, expected 2\n", type_desc.Members); > + ok(type_desc.Rows == 0, "Rows is %i, expected 0\n", type_desc.Rows); > + ok(type_desc.Columns == 0, "Columns is %i, expected 0\n", type_desc.Columns); These are unsigned variables. > + string = type->lpVtbl->GetMemberName(type, 0); > + ok(strcmp(string, "f1") == 0, "GetMemberName(0) is \"%s\", expected \"f1\"\n", string); You should probably use wine_dbgstr_a() for this.

1 0