February 2007 - Wine-Devel - list.winehq.org

Re: wine and msys rxvt.exe

by Dmitry Timoshkov

"Wesley Parish" <wes.parish(a)paradise.net.nz> wrote: > failed to load libX11.dll Looks like rxvt.exe is linked to an MSys provided X11 libraries that require a Windows X11 sever to be present and running. That's a sort of layer on layer and I don't think that there is someone who wants to make this configuration work. -- Dmitry.

Feb. 26, 2007

Re: wine and msys rxvt.exe

by John Smith

If I recall correctly, MSYS is the mingw linux environment emulated on windows. rxvt would be the terminal used in the msys environment. Hopefully this will be of some use, John Klehm On 2/25/07, Robert Shearman <rob(a)codeweavers.com> wrote: > > Wesley Parish wrote: > > I installed msys a couple of years back, and decided to test rxvt.exe: > > > > bash-3.1$ wine .wine/drive_c/msys/1.0/bin/rxvt.exe > > libGL warning: 3D driver claims to not support visual 0x4b > > fixme:netapi32:NetWkstaUserGetInfo Level 1 processing is partially > implemented > > fixme:advapi:LsaOpenPolicy ((null),0x68f478,0x00000001,0x68f494) stub > > fixme:advapi:LsaClose (0xcafe) stub > > fixme:advapi:LsaOpenPolicy ((null),0x68f488,0x000f0fff,0x68f484) stub > > fixme:netbios:NetServerEnum Stub ((null) 101 0x68ef04 -1 0x68ef08 > 0x68ef0c 8 > > L"DOMAIN" (nil)) > > fixme:advapi:LsaClose (0xcafe) stub > > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > > fixme:netapi32:NetUserGetInfo Level 3 is not implemented > > failed to load libX11.dllbash-3.1$ > > > > bash-3.1$ wine --version > > wine-0.9.29 > > > > Those are the error messages. > > > > My version of wine is a little old. Have the fixme's been fixed in the > latest > > wine? > > > > What is the program supposed to do? > > -- > Rob Shearman > > > >

Feb. 26, 2007

Re: We should have a .desktop file for the Uninstaller application

by Vitaliy Margolen

James Liggett wrote: > On Sun, 2007-02-25 at 20:29 -0800, Scott Ritchie wrote: >> As it is, most people don't even know this handy uninstaller applet >> exists. So let's fix that. > Good idea. And while we're at it, why not one for winecfg too? > > James > I was actually thinking about automatically creating those and other entries from wineshelllink whenever it creates Wine menu entry for the first time. However it would have to be aware of the WINEPREFIX and create separate entries for at least winecfg and uninstaller. So it's kind of defeats the propose of making it easy. Vitaliy.

Feb. 26, 2007

Re: We should have a .desktop file for the Uninstaller application

by James Liggett

On Sun, 2007-02-25 at 20:29 -0800, Scott Ritchie wrote: > As it is, most people don't even know this handy uninstaller applet > exists. So let's fix that. Good idea. And while we're at it, why not one for winecfg too? James

Feb. 26, 2007

Re: [3/4 revised] msi: Add partial, expandable OLE automation support.

by James Hawkins

On 2/25/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > This patch adds OLE automation support to MSI. It does this by creating > a wrapper class, which implements any of the OLE automation classes as > long as a function is given which is called from within the wrapper > classes invoke method after appropriate error checking. Basic > functionality is implemented, and it is fairly straightforward to add > the rest as the methods are all already implemented as functions in the > DLL. > +/* + * If you would like to implement a new automation function/object, look towards the bottom of this + * file for the "meat and potatoes" section. + */ + +/* FIXME: I don't know how big this should be */ +#define MAX_MSI_STRING 1000 + +/* + * AutomationObject - "base" class for all automation objects so we don't have to repeat functions. Just + * need to implement Invoke function for each dispinterface that is called from within + * the AutomationObject Invoke function which performs error checking, and pass the new + * function to create_automation_object. + */ + +typedef interface AutomationObject AutomationObject; + +interface AutomationObject { + /* + * VTables - We provide IDispatch, IProvideClassInfo, IProvideClassInfo2, IProvideMultipleClassInfo + */ + const IDispatchVtbl *lpVtbl; + const IProvideClassInfoVtbl *lpvtblIProvideClassInfo; + const IProvideClassInfo2Vtbl *lpvtblIProvideClassInfo2; + const IProvideMultipleClassInfoVtbl *lpvtblIProvideMultipleClassInfo; + + /* Object reference count */ + LONG ref; + + /* Clsid for this class and it's appropriate ITypeInfo object */ + LPCLSID clsid; + ITypeInfo *iTypeInfo; + + /* The MSI handle of the current object */ + MSIHANDLE msiHandle; + + /* A function that is called from IDispatch::Invoke, specific to this type of object. By the + * time this function is called, basic error checking has been done in the AutomationObject + * Invoke function */ + HRESULT (STDMETHODCALLTYPE *funcInvoke)( + AutomationObject* This, + DISPID dispIdMember, + REFIID riid, + LCID lcid, + WORD wFlags, + DISPPARAMS* pDispParams, + VARIANT* pVarResult, + EXCEPINFO* pExcepInfo, + UINT* puArgErr); +}; You went a little comment crazy here (and elsewhere). You should tone it down a bit. Good code explains itself and requires little or no commenting. + /* + * Perform a sanity check on the parameters. + */ + if ( (This==0) || (ppvObject==0) ) + return E_INVALIDARG; + + /* + * Initialize the return parameter. + */ + *ppvObject = 0; + + /* + * Compare the riid with the interface IDs implemented by this object. + */ + if (IsEqualGUID(riid, &IID_IUnknown) || IsEqualGUID(riid, &IID_IDispatch) || IsEqualGUID(riid, This->clsid)) + *ppvObject = This; + else if (IsEqualGUID(riid, &IID_IProvideClassInfo)) + *ppvObject = (IProvideClassInfo*)&(This->lpvtblIProvideClassInfo); + else if (IsEqualGUID(riid, &IID_IProvideClassInfo2)) + *ppvObject = (IProvideClassInfo2*)&(This->lpvtblIProvideClassInfo2); + else if (IsEqualGUID(riid, &IID_IProvideMultipleClassInfo)) + *ppvObject = (IProvideMultipleClassInfo*)&(This->lpvtblIProvideMultipleClassInfo); + + /* + * Check that we obtained an interface. + */ + if ((*ppvObject)==0) + { + TRACE("() : asking for unsupported interface %s\n",debugstr_guid(riid)); + return E_NOINTERFACE; + } + + /* + * Query Interface always increases the reference count by one when it is + * successful + */ + IClassFactory_AddRef(iface); + + return S_OK; +} Way too many comments. It may seem like nitpicking, but the comments clutter up the code and don't provide any useful information. -- James Hawkins

Feb. 26, 2007

Re: [2/4 revised] msi: Expand IDL file to contain all OLE automation interfaces.

by James Hawkins

On 2/25/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > This patch expands the IDL to contain all OLE automation interfaces that > the freely downloadable MS Windows Installer contains, and adds a > msiserver_dispids.h file that has define statements for all the dispids. > > Changelog: > > * msi: Expand IDL file to contain all OLE automation interfaces. > * Copyright (C) 2007 Mike McCormack + * Misha Koshelev You have to repeat the Copyright (C) 2007 part for your name. + [id(DISPID_INSTALLER_OPENDATABASE)] + Database* OpenDatabase( + [in] BSTR DatabasePath, + [in] VARIANT OpenMode); + [id(DISPID_INSTALLER_SUMMARYINFORMATION), propget] + SummaryInfo* SummaryInformation( + [in] BSTR PackagePath, + [in, optional, defaultvalue(0)] long UpdateCount); + [id(DISPID_INSTALLER_ENABLELOG)] + void EnableLog( + [in] BSTR LogMode, + [in] BSTR LogFile); Did you copy and paste this from OleView? This formatting is ridiculous. -- James Hawkins

Feb. 26, 2007

Re: msi: Add full JScript/VBScript support and partial expandable OLE automation support. [PATCH 3/3]

by Misha Koshelev

On Sun, 2007-02-25 at 13:00 +0000, Robert Shearman wrote: > Misha Koshelev wrote: > > +/* Macros to get pointer to AutomationObject) from the other VTables. */ > > > > Typo with extra ")" here. > > > +HRESULT WINAPI SessionImpl_Invoke( > > + AutomationObject* This, > > + DISPID dispIdMember, > > + REFIID riid, > > + LCID lcid, > > + WORD wFlags, > > + DISPPARAMS* pDispParams, > > + VARIANT* pVarResult, > > + EXCEPINFO* pExcepInfo, > > + UINT* puArgErr) > > +{ > > + WCHAR szString[MAX_MSI_STRING]; > > + DWORD dwLen = MAX_MSI_STRING; > > + IDispatch *iDispatch = NULL; > > + MSIHANDLE msiHandle; > > + LANGID langId; > > + UINT ret; > > + INSTALLSTATE iInstalled, iAction; > > > > Some error checking here would be good, like you do in > AutomationObject_Invoke. > > > + > > + switch (dispIdMember) > > + { > > > ... > > +/* > > + * AutomationObject - "base" class for all automation objects so we don't have to repeat functions. Just > > + * need to implement Invoke function for each dispinterface and pass the new function > > + * to create_automation_object. > > + */ > > + > > +typedef struct { > > + /* > > + * VTables - We provide IDispatch, IProvideClassInfo, IProvideClassInfo2, IProvideMultipleClassInfo > > + */ > > + const IDispatchVtbl *lpVtbl; > > + const IProvideClassInfoVtbl *lpvtblIProvideClassInfo; > > + const IProvideClassInfo2Vtbl *lpvtblIProvideClassInfo2; > > + const IProvideMultipleClassInfoVtbl *lpvtblIProvideMultipleClassInfo; > > + > > + /* Object reference count */ > > + LONG ref; > > + > > + /* Clsid for this class and it's appropriate ITypeInfo object */ > > + LPCLSID clsid; > > + ITypeInfo *iTypeInfo; > > + > > + /* The MSI handle of the current object */ > > + MSIHANDLE msiHandle;; > > + > > + /* A function that is called from IDispatch::Invoke, specific to this type of object */ > > + LPVOID funcInvoke; > > +} AutomationObject; > > > > You shouldn't need to expose the implementation details of > AutomationObject outside of automation.c. > > > + > > +/* This is the function that one needs to call to create an automation object. */ > > +extern HRESULT create_automation_object(MSIHANDLE msiHandle, IUnknown *pUnkOuter, LPVOID *ppObj, REFIID clsid, LPVOID funcInvoke); > > > > It is dangerous to use LPVOID as the type to pass a function in. > > > + > > +/* We need to expose these functions because our IActiveScriptSite calls it */ > > +extern HRESULT WINAPI LoadTypeInfo(IDispatch *iface, ITypeInfo **pptinfo, REFIID clsid, LCID lcid); > > +extern HRESULT WINAPI SessionImpl_Invoke(AutomationObject*,DISPID,REFIID,LCID,WORD,DISPPARAMS*,VARIANT*,EXCEPINFO*,UINT*); > > + > > +/* Disp Ids > > + * (not complete, look in msiserver.idl to add more) */ > > +typedef enum { > > + RecordDispId_StringData=1, > > + RecordDispId_IntegerData, > > + RecordDispId_SetStream, > > + RecordDispId_ReadStream, > > + RecordDispId_FieldCount, > > + RecordDispId_IsNull, > > + RecordDispId_DataSize, > > + RecordDispId_ClearData, > > + RecordDispId_FormatText > > +} RecordDispId; > > + > > +typedef enum { > > + ViewDispId_Execute=1, > > + ViewDispId_Fetch, > > + ViewDispId_Modify, > > + ViewDispId_Close, > > + ViewDispId_ColumnInfo, > > + ViewDispId_GetError > > +} ViewDispId; > > + > > +typedef enum { > > + DatabaseDispId_DatabaseState=1, > > + DatabaseDispId_SummaryInformation, > > + DatabaseDispId_OpenView, > > + DatabaseDispId_Commit, > > + DatabaseDispId_PrimaryKeys, > > + DatabaseDispId_Import, > > + DatabaseDispId_Export, > > + DatabaseDispId_Merge, > > + DatabaseDispId_GenerateTransform, > > + DatabaseDispId_ApplyTransform, > > + DatabaseDispId_EnableUIPreview, > > + DatabaseDispId_TablePersistent, > > + DatabaseDispId_CreateTransformSummaryInfo > > +} DatabaseDispId; > > + > > +typedef enum { > > + SessionDispId_Installer=1, > > + SessionDispId_Property, > > + SessionDispId_Language, > > + SessionDispId_Mode, > > + SessionDispId_Database, > > + SessionDispId_SourcePath, > > + SessionDispId_TargetPath, > > + SessionDispId_DoAction, > > + SessionDispId_Sequence, > > + SessionDispId_EvaluateCondition, > > + SessionDispId_FormatRecord, > > + SessionDispId_Message, > > + SessionDispId_FeatureCurrentState, > > + SessionDispId_FeatureRequestState, > > + SessionDispId_FeatureValidStates, > > + SessionDispId_FeatureCost, > > + SessionDispId_ComponentCurrentState, > > + SessionDispId_ComponentRequestState, > > + SessionDispId_SetInstallLevel, > > + SessionDispId_VerifyDiskSpace, > > + SessionDispId_ProductProperty, > > + SessionDispId_FeatureInfo, > > + SessionDispId_ComponentCost > > +} SessionDispId; > > > > See dlls/oleaut32/tests/tmarshal_dispids.h and > dlls/oleaut32/tests/tmarshal.idl for how to use DISPIDs properly. > > > +typedef struct { > > + IActiveScriptSite lpVtbl; > > + AutomationObject *session; > > > > You don't actually access this as anything other than an IDispatch > object, so you might as well change to "IDispatch *session". > > > +LPCWSTR read_script_from_file(LPCWSTR szFile, INT type) > > > > Should be static. > > > +/* JScript or VBScript? */ > > +LPCWSTR progid_from_type(INT type) > > > > Should also be static. > > > + > > +/* > > + * Call a script. This is our meat and potatoes. > > + * - Currently, since the function is relatively new, it will always end up returning S_OK. > > + * Think of it like a bonus feature, we can run the script - great. If we have a problem, > > + * we are no worse off than if this function had not been called. > > + */ > > +DWORD call_script(MSIHANDLE hPackage, INT type, LPCWSTR filename, LPCWSTR function, LPCWSTR action) > > +{ > > + LPCWSTR script = NULL, progId = NULL; > > + HRESULT hr; > > + IActiveScript *iActiveScript = NULL; > > + IActiveScriptParse *iActiveScriptParse = NULL; > > > > I haven't seen this variable notation style before. In Hungarian > notation "p" is used instead of "i" to show a pointer to an object > exposing the interface declared. > I have implemented all the changes you outlined (thanks a lot) in this and your other email, with the exception of the extra error checking in each of the individual Invoke functions as they are called from within AutomationObject::Invoke after the error checking already occurs. What do you think? Thanks Misha p.s. The 5th patch is not a part of my submission, but is just a hack I used to make the IDL file with the dispids using oleview. This patch will make oleview use the DISPID_PARENT_MEMBER notation for ids and will output the include file to standard output. Thought maybe it would be useful for someone.

Feb. 26, 2007

We should have a .desktop file for the Uninstaller application

by Scott Ritchie

As it is, most people don't even know this handy uninstaller applet exists. So let's fix that. Thanks, Scott Ritchie

Feb. 26, 2007

Re: Wine and XP Themes

by Dmitry Timoshkov

"Frank Richter" <frank.richter(a)gmail.com> wrote: > The comctl32 controls all do theming "natively". The subclassing is done > only for control residing in user32 (the motivation was to avoid copying > and pasting all the control implementations from user32 to comctl32, as > Microsoft supposedly did). Sounds like a deja-vu: http://www.winehq.org/?issue=267#Theming%20Revisited -- Dmitry.

Feb. 26, 2007

Re: wined3d: Use application provided fog range when fog is enabled.

by Stefan Dösinger

Am Montag 26 Februar 2007 02:03 schrieb Vitaliy Margolen: > This should fix fog issues with PoP SoT. > --- > dlls/wined3d/state.c | 6 ++++-- > 1 files changed, 4 insertions(+), 2 deletions(-) Just wanted to add that this would fix the fixed function Z vs specular color alpha selection with table and vertex fog. Vertex shaders seem to be treated as transformed vertices. That said, the way the fixed function pipeline uses was developed by looking at what games need. The patch Vitaly sent looks good to me, but if there are any regressions I will have to try to write a unit test(though it will be tricky due to the pixel exactness thingy)

Feb. 26, 2007