Re: Configure question about Wine / HAL
Kris Moore kris at pcbsd.com writes: Here you go! http://www.pcbsd.org/~kris/config.log Hey Kris, It seems something is wrong with your pthread library? configure:12388: checking for dbus_connection_close in -ldbus-1 configure:12423: cc -o conftest -O2 -fno-strict-aliasing -pipe -I/usr/local/include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/local/include/hal -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -L/usr/local/lib conftest.c -ldbus-1 -L/usr/local/lib -lhal -ldbus-15 /usr/local/lib/libdbus-1.so: undefined reference to `pthread_equal' /usr/local/lib/libdbus-1.so: undefined reference to `pthread_cond_timedwait' and also: configure:15254: checking for -ljack configure:15289: cc -o conftest -O2 -fno-strict-aliasing -pipe -I/usr/local/include -L/usr/local/lib conftest.c -ljack 5 /usr/local/lib/libjack.so: undefined reference to `pthread_create' /usr/local/lib/libjack.so: undefined reference to `pthread_attr_init' /usr/local/lib/libjack.so: undefined reference to `pthread_exit' /usr/local/lib/libjack.so: undefined reference to `pthread_cancel' /usr/local/lib/libjack.so: undefined reference to `pthread_equal' /usr/local/lib/libjack.so: undefined reference to `pthread_testcancel' /usr/local/lib/libjack.so: undefined reference to `pthread_attr_setscope' /usr/local/lib/libjack.so: undefined reference to `pthread_attr_setinheritsched' /usr/local/lib/libjack.so: undefined reference to `pthread_setschedparam' /usr/local/lib/libjack.so: undefined reference to `pthread_attr_setstacksize' /usr/local/lib/libjack.so: undefined reference to `pthread_attr_setdetachstate' /usr/local/lib/libjack.so: undefined reference to `pthread_join' Can you check pthread is present in your /usr/local/lib? Best regards, Jeroen Janssen
cygwin and -luuid build error?
Hi, I don't know if building wine with cygwin is/should be supported. However, I get a linker error in dlls/atl with IID_IOleInPlaceSiteWindowless. It seems this symbol is in the uuid library. The problem it seems is that this library is linked with EXTRALIBS in Makefile.in and this doesn't result in the correct -L path to be set (essentially the libuuid.a can not be found by the linker). When I move -luuid from EXTRALIBS to IMPORTS, -L../../dlls/uuid is added to the linker and the library is correctly linked. Since it works ok on Linux, moving the -luuid option around is probably not a good solution, but I was wondering if anyone has looked into this before and if so what a good solution would be. Any thoughts on this? Best regards, Jeroen Janssen
SOC Direct3D - Implement missing D3D9_xx DLLs?
Hi, I was looking at the Wine SOC wiki ( http://wiki.winehq.org/SummerOfCode ) and noticed an entry on Direct3D - Implement missing D3D9_xx DLLs. As far as I can see there are already lots of D3D9_xx dlls in the tree that seem to forward stuf correctly. Can someone confirm this to be already finished (and then remove this item from the wiki?) If it isn't finished yet, what IS missing then? D3D10_xx DLLs seem to be currently missing (I know we don't have any d3d 10 implementation yet in wine) and it probably isn't a SOC project, but would completely stubbed D3D10_xx DLLs (patches) be accepted if I submit them to the patch mailinglist or not? Best regards, Jeroen Janssen
Re: SOC Direct3D - Implement missing D3D9_xx DLLs?
On Tue, Apr 1, 2008 at 3:06 PM, H. Verbeet [EMAIL PROTECTED] wrote: As far as I can see there are already lots of D3D9_xx dlls in the tree that seem to forward stuf correctly. Can someone confirm this to be already finished (and then remove this item from the wiki?) If it isn't finished yet, what IS missing then? It isn't so much that the dlls themselves are missing, but rather that a lot of the functions they're supposed to implement are still unimplemented. Ok, then the SOC text on the wiki for this item is slightly misleading / outdated.
Re: SOC Direct3D - Implement missing D3D9_xx DLLs?
On Tue, Apr 1, 2008 at 3:30 PM, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Dienstag, 1. April 2008 15:06:37 schrieb H. Verbeet: Personally, I don't think it makes sense to have stubbed d3d10x dlls without at least a partial d3d10 implementation. Yes, I agree. It would make more sense to take the unfinished stub from Andras' D3D10 project last year, finish it and write tests. For starting a D3D10 implementation we need some tests regarding pixel formats, the shader bytecode format and how the new buffer resource model works exactly. Would it be worth mentioning this on the wine SOC 2008 page? Also, is there some info on what is left to do? ( I found the code Andras wrote at http://code.google.com/p/google-summer-of-code-2007-wine/downloads/list ) Best regards, Jeroen Janssen p.s. I'm not a student, but just interested in something that I could work on, so if someone else claims this for the SOC, that's ok with me.
wine + mono instead of .net framework?
Hi, I was wondering if it is possible to use mono instead of the (microsoft) .net framework for windows applications running under wine. i.e. I have an application that 'requires' .net 2.0, and wants me to install it. With mono 'installed' it would see that .net 2.0 is already installed and just work ;) Any thoughts on if this is possible (or even wanted?) Best regards, Jeroen Janssen
Re: Can WINE be made for DOS using GCC for DOS?
Hi, For those interested, I remember there is this thing called 'wdosx' ( http://michael.tippach.bei.t-online.de/wdosx/ ), that is a DOS eXtender containing a stubbed subset of the WIN32 API. From the README.TXT: Probably the most advanced feature of WDOSX is its emulation of a subset of the Win32 API, making it work with compilers that were not originally designed to create 32 bit DOS programs. As of current, the following Win32 API functions are emulated by WDOSX, either completely, in parts or as stubs: (Note: This table is a bit out of date and reflects the status of WDOSX 0.95. I've got more important things to do at the moment.) ModuleExports KERNEL32 AllocConsole, AreFileApisANSI, Beep, CloseHandle, CompareStringA, CreateConsoleScreenBuffer, CreateDirectoryA, CreateDirectoryW, CreateFileA, CreateFileW, CreateProcessA, DebugBreak, DeleteCriticalSection, DeleteFileA, DeleteFileW, DosDateTimeToFileTime, EnterCriticalSection, EnumCalendarInfoA, ExitProcess, FileTimeToDosDateTime, FileTimeToLocalFileTime, FileTimeToSystemTime, FillConsoleOutputAttribute, FillConsoleOutputCharacterA, FindClose, FindFirstFileA, FindNextFileA, FlushConsoleInputBuffer, FlushFileBuffers, FormatMessageA, FreeConsole, FreeEnvironmentStringsA, FreeEnvironmentStringsW, FreeLibrary, GetACP, GetCPInfo, GetCommandLineA, GetConsoleCP, GetConsoleCursorInfo, GetConsoleMode, GetConsoleOutputCP, GetConsoleScreenBufferInfo, GetCurrentDirectoryA, GetCurrentProcess, GetCurrentThreadId, GetCurrentTime, GetDateFormatA, GetDiskFreeSpaceA, GetDriveTypeA, GetEnvironmentStrings, GetEnvironmentStringsA, GetEnvironmentStringsW, GetEnvironmentVariableA, GetExitCodeProcess, GetFileAttributesA, GetFileAttributesW, GetFileInformationByHandle, GetFileSize, GetFileTime, GetFileType, GetFullPathNameA, GetLargestConsoleWindowSize, GetLastError, GetLocalTime, GetLocaleInfoA, GetLogicalDrives, GetModuleFileNameA, GetModuleHandleA, GetNumberOfConsoleInputEvents, GetNumberOfConsoleMouseButtons, GetOEMCP, GetPrivateProfileStringA, GetProcAddress, GetStartupInfoA, GetStdHandle, GetStringTypeA, GetStringTypeW, GetSystemDefaultLCID, GetSystemInfo, GetSystemTime, GetTempFileNameA, GetThreadLocale, GetTickCount, GetTimeZoneInformation, GetVersion, GetVersionExA, GetVersionExW, GetVolumeInformationA, GlobalAlloc, GlobalFlags, GlobalFree, GlobalHandle, GlobalLock, GlobalMemoryStatus, GlobalReAlloc, GlobalSize, GlobalUnlock, HeapAlloc, HeapCreate, HeapDestroy, HeapFree, HeapReAlloc, HeapSize, InitializeCriticalSection, InterlockedDecrement, InterlockedExchange, InterlockedIncrement, IsBadCodePtr, IsBadHugeReadPtr, IsBadHugeWritePtr, IsBadReadPtr, IsBadWritePtr, LCMapStringA, LCMapStringW, LeaveCriticalSection, LoadLibraryA, LoadLibraryExA, LocalAlloc, LocalFileTimeToFileTime, LocalFree, LocalReAlloc, MoveFileA, MultiByteToWideChar, OutputDebugString, PeekConsoleInputA, QueryPerformanceCounter, QueryPerformanceFrequency, RaiseException, ReadConsoleA, ReadConsoleInputA, ReadFile, RemoveDirectoryA, RemoveDirectoryW, RtlUnwind, ScrollConsoleScreenBufferA, SetConsoleCtrlHandler, SetConsoleCursorInfo, SetConsoleCursorPosition, SetConsoleMode, SetConsoleScreenBufferSize, SetConsoleWindowInfo, SetCurrentDirectoryA, SetCurrentDirectoryW, SetEndOfFile, SetEnvironmentVariableA, SetFileAttributesA, SetFileAttributesW, SetFilePointer, SetFileTime, SetHandleCount, SetLastError, SetStdHandle, SetUnhandledExceptionFilter, Sleep, SystemTimeToFileTime, TerminateProcess, TlsAlloc, TlsFree, TlsGetValue, TlsSetValue, UnhandledExceptionFilter, VirtualAlloc, VirtualFree, VirtualQuery, WaitForSingleObject, WideCharToMultiByte, WriteConsoleA, WriteConsoleOutputA, WriteFile, WritePrivateProfileStringA, _hread, _hwrite, _lclose, _lcreat, _llseek, _lopen, _lread, _lwrite, lstrcat, lstrcatA, lstrcmp, lstrcmpA, lstrcmpi, lstrcmpiA, lstrcpy, lstrcpyA, lstrcpyn, lstrcpynA, lstrlen, lstrlenA USER32CharToOemA, CharToOemBuffA, CharToOemW, EnumThreadWindows, GetKeyboardType, GetSystemMetrics, IsCharAlphaNumericA, LoadStringA, MessageBoxA, MessageBoxExA, OemToCharA, OemToCharBuffA, OemToCharW OLEAUT32 SysAllocStringLen, SysFreeString, SysStringLen, VariantChangeType, VariantChangeTypeEx, VariantClear, VariantCopy, VariantCopyInd, VariantInit ADVAPI32 RegCloseKey, RegOpenKeyA, RegOpenKeyExA,
Re: Remove typelib ProxyStubClsid registration when no oleautomation interface is being registered
Jeroen Janssen wrote: As far as I see it I have two options (to run this outprocess client/server program): 1) use the available proxy/stub code 2) use the typelib marshaller if a typelib is registered And maybe a 3rd option: use native ole/rpcrt/etc dlls? --- Jeroen
Re: Anyone writing COM tests?
Duane Clark wrote: Howdy, Debugging a problem I am having in COM (mentioned a few weeks ago), I think I know what the problem is but not where. So I figured some COM test would help me to understand how things should work. I was a bit surprised to see no COM tests, or at least I didn't find any in the ole* directories. So I figured if no one else is working on them, I might take a shot at it over the next few weeks/months. And maybe this would encourage some updates to the COM implementation. I think writing (COM) tests is a great idea. I have 'hit' a few bumps in the road of wine COM in the past few weeks and I would appreciate it if I can help with writing (specific) testscenarios. It would be great to have a small 'com test framework' sample code to base specific tests upon. I'm wondering though if all can be build without problems : I'm used to VC6, but it would be better if things can be (cross) build with mingw and/or gcc + with winelib. Also generating proxy/stub code (without using midl) might be a problem at this point. --- Jeroen Janssen
Re: RPCRT4_NdrClientCall2 stub (fixme)?
Filip Navara wrote: Alexandre Julliard wrote: Mike Hearn [EMAIL PROTECTED] writes: Yes, I have an implementation of NdrClientCall2 in my local tree, but I'm a bit busy with other COM things at the moment. I'll send an updated patch to the list either tonight or sometime over the weekend. Alexandre, why was this not merged when it was originally sent? No idea, please resubmit. IIRC Robert said that the patch isn't cleaned up yet and so it shouldn't be commited. He also said that he hasn't tested it much except for simple tests and the complex types weren't tested at all. Since I'm trying to run an application that is in the need of NdrClientCall2, I can probably do some tests with it (but I don't know what types are being used in it). I'm wondering when is a patch 'good enough' to be included? (both from an 'enduser', an author's point of view and from Alexandre's view (who eventually commits the patch)? Is there an official way to track that a patch submitted to wine-patches has been comitted? Also can I somehow find out which (interesting) patches have not been comitted yet? Also, I noticed there is currently only one person with CVS write permissions for Wine? Has this always been the case? --- Jeroen
Re: RPCRT4_NdrClientCall2 stub (fixme)?
Mike Hearn wrote: Is there an official way to track that a patch submitted to wine-patches has been comitted? Also can I somehow find out which (interesting) patches have not been comitted yet? Unfortunately there is no way to track this in an automated fashion. It has been talked about but nobody created a system yet. We just watch wine-cvs and see when it's been checked in. Hmmm, so it can (unfortunately) happen that a patch is 'forgotten' Also, I noticed there is currently only one person with CVS write permissions for Wine? Has this always been the case? Yes. Before we had CVS it was like the kernel, people just mailed Alexandre patches and didn't know if they'd been merged until the next release (as far as I know, but that was long before my time, back then I thought Win98 was the bees knees ;) Oh, well.. I actually ment to compare 'one person with CVS write permissions' to 'multiple persons with CVS write permissions'. In the past, (open source) projects I worked on had multiple persons with CVS write access to the repository. Related to the kernel, some people keep their 'personal' tree (like -mm, -ac, etc) that can be used to structurally test certain patches, etc and then subsequently patches can be gradially merged from these trees to the 'official main tree' (after some testing). Is this something that also would work for wine? --- Jeroen
RPCRT4_NdrClientCall2 stub (fixme)?
Hello,
I have 'hit' upon a RPCRT4_NdrClientCall2 stub/fixme call.
It seems some discussion on this has been happening in a the past few
months?
Can someone maybe explain the current status on this?
(probably Rob or Mike, since they seem to be the Wine COM gurus?)
Below is is a short snip of trace logging I get:
trace:ole:COMPOBJ_DLLList_Add
trace:ole:CStdPSFactory_QueryInterface
(0x660cea80)-QueryInterface({d5f569d0-593b-101a-b569-08002b2dbf7a},0x4067faa4)
trace:ole:CStdPSFactory_CreateProxy
(0x660cea80)-CreateProxy((nil),{11ef83d1-553a-11d3-bb12-0004ac9658d6},0x4067faa0,0x4067fbfc)
trace:ole:FindProxyInfo found: ProxyInfo 0x660cbc48 Index 65
trace:ole:StdProxy_Construct
((nil),0x660cd048,0x660cea80,0x4067faa0,0x4067fbfc) ICoKMFactoryManager
trace:ole:StdProxy_Construct stubless=0x660c5230
trace:ole:StdProxy_Construct iid={11ef83d1-553a-11d3-bb12-0004ac9658d6}
trace:ole:StdProxy_Construct vtbl=0x660cd050
trace:ole:StdProxy_Construct stubless thunks: count=6
trace:ole:StdProxy_Construct method 3: stacksize=12
trace:ole:StdProxy_Construct method 4: stacksize=16
trace:ole:StdProxy_Construct method 5: stacksize=4
trace:ole:CStdPSFactory_AddRef (0x660cea80)-AddRef()
trace:ole:CStdPSFactory_Release (0x660cea80)-Release()
trace:ole:StdProxy_Connect (0x4034f1f0)-Connect(0x4034f288)
trace:ole:StdProxy_Release (0x4034f1f0)-Release()
trace:ole:ObjectStubless (0x4034f1f4)-(3)([12 bytes]) ret=4067fc94
fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x660c7c08,pFormat =
^0x660c7d30,...): stub
trace:ole:IUnknown_Release_Proxy (0x4034f1f0)-Release() ICoKMFactoryManager
wine: Unhandled exception (thread 0014), starting debugger...
Best regards,
Jeroen Janssen
generation date/version of the (online) wine documentation
Hi, I have a few questions: * is it possible to add the date/version in the online wine documentation at http://www.winehq.com/site/documentation (for the user, devel docs) * when exactly are these pages generated? (nightly/daily/?) best regards, Jeroen
Re: DCOM: Pass -Embedding switch to EXE servers, more tracing
James Hawkins wrote:
WCHAR is a wide (unicode) character. sizeof(embedding)/sizeof(WCHAR)
will return the length of the strength in characters and not the size
of it if I'm not mistaken.
Yes, and I think you will want to have the length in characters when
declaring a (C) array in the example code below:
With
static const WCHAR embedding[] = { ' ', '-','E','m','b','e','d','d','i','n','g',0 };
You will want
WCHAR command[MAX_PATH+(sizeof(embedding)/sizeof(WCHAR)+1];
instead of
WCHAR command[MAX_PATH+sizeof(embedding)+1];
Because if sizeof(WCHAR) == 2, then command will be strlen(embedding) to
large.
On Mon, 26 Jul 2004 18:24:48 +0200, Jeroen Janssen [EMAIL PROTECTED] wrote:
Mike Hearn wrote:
ChangeLog:
Pass -Embedding switch to EXE servers, more tracing
diff -u -p -r1.15 rpc.c
--- dlls/ole32/rpc.c15 Jul 2004 22:07:44 - 1.15
+++ dlls/ole32/rpc.c21 Jul 2004 22:43:59 -
@@ -471,8 +471,10 @@ create_server(REFCLSID rclsid) {
char buf[200];
HRESULT hres = E_UNEXPECTED;
char xclsid[80];
- WCHARdllName[MAX_PATH+1];
- DWORDdllNameLen = sizeof(dllName);
+ WCHARexe[MAX_PATH+1];
+ DWORDexelen = sizeof(exe);
+ static const WCHAR embedding[] = { ' ', '-','E','m','b','e','d','d','i','n','g',0 };
+ WCHAR command[MAX_PATH+sizeof(embedding)+1];
On a side note, what exactly is a WCHAR?
Is it a 'char' or a 'unicode char' (2bytes)?
This in relation to sizeof(embedding) instead of
sizeof(embedding)/sizeof(WCHAR)?
---
Jeroen
Re: Implement StdMarshal::ReleaseMarshalData
Mike Hearn wrote: You're right, good catch. I'm not sure it's worth resending the patch though as really hardly any of our COM implementation is thread safe at all. What exactly does this mean? (the impact on running programs that make use of COM) --- Jeroen Janssen
Re: COM outproc CFProxy unhandled interface for IRunnableObject
Forwarding this to the wine-devel mailinglist. Robert Shearman wrote: Jeroen Janssen wrote: Hello, I'm mailing the both of you with a small (com) example attached. It is a client/server/proxystub example (with binaries), so you need to /RegServer the server and regsvr32 the proxy. Now I first manually start the server in a seperate console and then I manually start the client. I modified the client to look for input, so there are basically two paths in the client: * you press: 1 enter; the normal path, goes OK hr = CoCreateInstance(CLSID_Calculate,NULL,CLSCTX_LOCAL_SERVER,IID_ICalculate,(void**) pICalculate); * you press: 2 (or something else) enter; the other path, FAILURE hr = CoCreateInstance(CLSID_Calculate,NULL,CLSCTX_LOCAL_SERVER,IID_IUnknown,(void**) pIUnknown); hr = pIUnknown-QueryInterface(IID_ICalculate, (void **) pICalculate); Now either there is something wrong with my sample, or there is something wrong in wine that causes this to fail. Can you verify that the client code path is ok (the very few above mentioned lines that differentiate in scenario 1,2). If the client code is ok, then any idea what is actually causing the problem? Yes, I can see the problem. What happens with native OLE is that the IUnknown part of the object is handled by the proxy manager. What this basically means is that it is translated into IRemUnknown (remote unknown) calls that will do the appropriate thing. However, this is currently not implemented on Wine. I'm not sure we (Mike and I) will have time to properly implement this, but I could maybe write a quick hack for you sometime over the weekend. Ok, thanks for this explanation (that explains why this is not working yet on wine). Btw, is it ok to forward this information to the mailinglist too? (I didn't want to sent the example attachment to everyone on the mailinglist, but this discussion seems interesting enough to have the conclusion posted on the wine development mailinglist. I had a short look at the 'world of com' patch, and it looks like there is something in there that implements the IRemUnknown stuff. Is there any easy way to determine if/how this can be 'ported' to the current wine? --- Jeroen
daily wine cvs source snapshots?
Hello, I was wondering since: 1) wine uses CVS (and not svn with httpwebdav) and 2) CVS doesn't go through the firewall at my work (and possible also not for other people) Would it be possible to have daily cvs snapshots (cvs export) of the wine HEAD tree? This makes tracking the latest HEAD possible for people that can't use CVS to access the repository. I know that the CVS repository itself is available, but that sounds a bit overkill to me. best regards, Jeroen Janssen
COM outproc CFProxy unhandled interface for IRunnableObject
Hello,
I'm trying to run 2 programs:
1) is a COM server program
2) is a COM client program
Now, program 2) tries to access a COM component from 1) (outproc).
It seems some marshalling is being done, but eventually I get:
fixme:ole:CFProxy_QueryInterface Unhandled interface:
{0126---c000-0046}
This interface seems to be IRunnableObject.
Now I'm not exactly sure how this is supposed to work, or even if this is
the reason why my test currently fails. I can provide more logging/info if
I know what exactly to provide.
Note that I tried a small outproc client/server test that seems to go ok
without this error, so the 'basic' outproc mechanism seems to work ok.
Can someone provide more information on how wine deals with Outproc COM?
On a side note, what are the main differences in COM implementation
between wine and winex (if I understand correctly, Transgaming rewrote the
COM implemenation for winex in order to better support the InstallShield
installer?).
Best regards,
Jeroen Janssen
Re: daily wine cvs source snapshots?
SSH tunneling not possible either? Nope, unfortunately not. Would it be possible to have daily cvs snapshots (cvs export) of the wine HEAD tree? Err... we've already been having that for a VERY long time ;-) http://lisas.de/~andi/wine_files/wine-cvs-hopefully-current.tar.bz2 (I thought that was mentioned at WineHQ? Not sure, though, especially with all those changes in the meantime...) Thanks a lot!! I was not aware of this being available (and it's not on the http://www.winehq.com/site/download page either). --- Jeroen Janssen
Re: COM outproc CFProxy unhandled interface for IRunnableObject
From: Mike Hearn [EMAIL PROTECTED] Maybe my 'real' problem is that based upon the logging, I also see a CFProxy Unhandled interface for the first interface that the client is trying to access (but I need to know more about how COM/wine deals with this). Are you sure you're using COM right? I have also written an outproc server test and it works OK - at least I've been able to marshal a Hello World RPC across. Well, it seems to work ok on Windows, so there must be something 'ok' about it. Also, I did not write the application myself. I'm just trying to get it run under wine. I am not sure, but there seems to be a difference in the outproc handling of the CoCreateInstance call? This goes ok: hr = CoCreateInstance(CLSID_Component1, NULL, clsctx, IID_IX, (void**)pIX) ; However this seems to go wrong?: hr = CoCreateInstance(CLSID_Component1, NULL, clsctx, __uuidof(IUnknown), (void**)pIUnknown); hr = pIUnknown-QueryInterface(IID_IX, (void **)pIX); Summary: If you perform a CoCreateInstance for IUnknown (outproc), you get back the classfactory instead of the proxy to the object itself? Maybe you can check this behaviour? (I don't know exactly if this is indeed what seems to wrong or that I might have made a mistake with the simple test program). Me and Rob are starting to scrape together a plan, I think, and as part of working on other apps we're fixing bits as we go, but it's a long long road we have ahead of us. Any help would certainly be welcome. Well, I'm trying get this application running with wine, I don't know what else I might walk into, but I surely hope to do some contributions to wine in the process. --- Jeroen Janssen
Re: urlmon missing InternetSecurityManager
Are there any (wine) pointers on implementing a new (stubbed) COM interface? You will need to update the corresponding urlmon.h header file too, so that it can be used by C code. You can do this by running make idl in the wine/include/ directory. Yes, I expected something like that too.. On a side note, why is this not done during the regular make process? Lionel Ulmer had a script to create a stubbed out COM interface, so maybe he could give you the script or create the interface for you. Any idea why this script is not in the wine tree somewhere? (tools/?) --- Jeroen
