Re: Possible regression in CVS wine
> Hi, > I haven't tried to run the game but maybe the problem is that wine now > defaults to behave like Win 2000[1] which does not allow privileged > instructions. > You could try to set windows version to 98 with winecfg Hi! Thanks, it was really the problem. Program runs now, and even better than before. We upgraded wine because some programs were not getting the keyboard and this problem now seems to be fixed. With regards, Pavel Troller
Re: Problems with winecfg and theming
On 05.09.2005 02:17, Ron Jensen wrote: > The Appearance tab worked before, it doesn't work now. Removing > all the msstyles files from windows\resources\themes\*\ stops the > crashing. This is probably the fixing patch: http://www.winehq.org/pipermail/wine-cvs/2005-September/017912.html -f.r.
Re: Suggestions for improvement of the emulator
On Mon, 5 Sep 2005 06:24, Alex Tanner wrote: > If all the companies worked together on a > single WinXP-Pro-emulating flavour of Wine, the > manpower problem would be solved. Not really. Firstly there is not (yet) enough commercial interest in contributing to Wine development to provide the manpower, although that is changing. Secondly, even if there were sufficient manpower, the way the Wine project is currently structured would prevent the manpower from being used efficiently.
Re: Suggestions for improvement of the emulator
Hi Alex, Firstly, Wine is not an emulator, it it a binary loader and an implementation of the Win32 API. Alex Tanner wrote: companies. If all the companies worked together on a single WinXP-Pro-emulating flavour of Wine, the manpower problem would be solved. Different companies have different goals. For CodeWeavers, the goal is not to full emulate any version of Windows, but to allow more useful applications that were originally written for Windows to work. IMO, the best way to contribute to Wine is to test applications, and write patches to fix them :) Mike
Problems with winecfg and theming
On Wed Aug 31 14:19:53 CDT 2005, Kevin DeKorte wrote: >On Wednesday 31 August 2005 01:03 pm, Paul Vriens wrote: >> Hi, >> >> I'm not able to use winecfg and theming. If I select to add a theme I >> get an exception after selecting the file and clicking OK. >> >> the .msstyles files seems to have been copied to the right place. When I >> however start winecfg again and go to the Appearance tab I get a new >> exception. Remove everything under Resources/Themes 'fixes' this so >> there must be something wrong with the enumeration. >> >> Anybody else experiencing this? >> >> Paul. > > Yes, I can duplicate this crash as well. > > Kevin I was playing with theming after pulling from CVS on the 27th. I tried to use theming today after pulling from CVS on Sep 1. The Appearance tab worked before, it doesn't work now. Removing all the msstyles files from windows\resources\themes\*\ stops the crashing. I reversed patches 19901 and 19915 but that didn't seem to help. Ron
Re: Need help debugging a memory corruption bug in shfldr_unixfs.c
Michael Jung wrote: On Monday 29 August 2005 18:09, Duane Clark wrote: I am seeing it now, using winecfg and browsing to "Add application..." in the Applications tab. And this entirely within wine drives. Are you saying you are not using the unix filesystem namespace and you are seeing the crash anyway? As of the current CVS, the problem seems to have disappeared for me. It is not clear to me what patch fixed it.
Suggestions for improvement of the emulator
I can't understand why the members of the Wine project are always complaining about lack of manpower. The lack of manpower is probably due to there being different flavours of Wine developed by different companies. If all the companies worked together on a single WinXP-Pro-emulating flavour of Wine, the manpower problem would be solved. There would be other advantages to this: - a) Windows API functions would be implemented more quickly. b) There would be better support for the latest Windows applications. c) People would no longer have problems running applications that fail to work simply because they need support files from more than one Wine flavour. d) There wouldn't be multiple teams of people pointlessly trying to implement the same Windows API functions as each other for different flavours of Wine, because each team would no longer be going its own way. ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: Possible regression in CVS wine
On Sunday 04 September 2005 20:41, Pavel Troller wrote: > Hi! > I've just upgraded wine on my son's computer by today's CVS. He tried > some games and one of them stopped working. It's hind95 and the game bails > out on an illegal instruction - outb, jumping into winedbg. Backtrace shows > just 3 levels of game code itself, no dlls involved. > I understand that user code cannot perform direct hardware I/O, but the > game worked just before the upgrade (on wine about 1 month old). I don't > know whether wine is normally intercepting and emulating these > instructions, and the CVS version doesn't, or whether a new wine caused > that another code path has been activated in the game code, leading to such > a problem. > There is also native w2k version of the game (hind.exe) but it still > doesn't work in wine: it very sow renders the splash > screen and then sits there and does nothing more. > The game can be freely downloaded from www.abandonia.com; just search > "hind" in the title page. There is probably a dynamic download URL used so > I'm not posting it there. > With regards, Pavel Troller Hi, I haven't tried to run the game but maybe the problem is that wine now defaults to behave like Win 2000[1] which does not allow privileged instructions. You could try to set windows version to 98 with winecfg Greetings Peter [1] Patch from 15.08.2005 that changed the default version: http://cvs.winehq.org/patch.py?id=19564
Re: Delphi edit control created in Unicode instead of ANSI mode
On 04.09.2005 16:47, Michael Kaufmann wrote: > Hi Frank, > > One of your theming patches ( > http://www.winehq.org/hypermail/wine-cvs/2005/08/0313.html ) has caused > a problem in many Delphi applications. The edit controls of Delphi > applications are now created in Unicode mode. I hope you have an idea > why this happens... Of course Delphi applications are ANSI and expect > ANSI controls in their windows. I know. > Because the Delphi edit controls are now in Unicode mode, the messages > sent to them have to be translated from ANSI to Unicode and back. When a > program reads the "Text" property of a TEdit control, Delphi sends a > WM_GETTEXTLENGTH message. Wine doubles the return value when translating > back from Unicode to ANSI because of double-byte character sets. > (dlls/user/winproc.c) Windows (2k+ at least) in this case actually also sends a Unicode WM_GETTEXT in this case and determines the true ANSI length from the Unicode string. Wine should (IMO) be fixed to do the same. Try this patch: http://www.winehq.org/pipermail/wine-patches/2005-August/020285.html Unfortunately, it is as-is not CVS-worthy... -f.r. signature.asc Description: OpenPGP digital signature
Re: DINPUT: protect FF_STATUS usage
Now it compiles...
Thank you!
Daniel Remenak escreveu:
Changelog:
Protect FF_STATUS usage to avoid compile errors on machines with old
linux/input.h
This patch should fix Marcelo Duarte's reported compile error on FC2.
This patch was made against a copy of joystick_linuxinput.c that
already had "linuxinput axis enumeration fixes" and "allow the
creation of an effect while unacquired" applied to it, but it should
apply to an earlier revision.
--Daniel Remenak
--- ../wine2/dlls/dinput/joystick_linuxinput.c 2005-09-03 14:29:30.0
-0700
+++ dlls/dinput/joystick_linuxinput.c 2005-09-03 23:00:35.0 -0700
@@ -302,7 +302,9 @@
newDevice->ref = 1;
newDevice->joyfd = -1;
newDevice->dinput = dinput;
+#ifdef HAVE_STRUCT_FF_EFFECT_DIRECTION
newDevice->ff_state = FF_STATUS_STOPPED;
+#endif
memcpy(&(newDevice->guid),rguid,sizeof(*rguid));
for (i=0;iwantmin[i] = -32768;
@@ -723,9 +725,11 @@
break;
}
break;
+#ifdef HAVE_STRUCT_FF_EFFECT_DIRECTION
case EV_FF_STATUS:
This->ff_state = ie.value;
break;
+#endif
default:
FIXME("joystick cannot handle type %d event (code
%d)\n",ie.type,ie.code);
break;
Possible regression in CVS wine
Hi! I've just upgraded wine on my son's computer by today's CVS. He tried some games and one of them stopped working. It's hind95 and the game bails out on an illegal instruction - outb, jumping into winedbg. Backtrace shows just 3 levels of game code itself, no dlls involved. I understand that user code cannot perform direct hardware I/O, but the game worked just before the upgrade (on wine about 1 month old). I don't know whether wine is normally intercepting and emulating these instructions, and the CVS version doesn't, or whether a new wine caused that another code path has been activated in the game code, leading to such a problem. There is also native w2k version of the game (hind.exe) but it still doesn't work in wine: it very sow renders the splash screen and then sits there and does nothing more. The game can be freely downloaded from www.abandonia.com; just search "hind" in the title page. There is probably a dynamic download URL used so I'm not posting it there. With regards, Pavel Troller
MMIO error
Hi, I have been trying to get a professional Audio restoration program, DCart32, to work in wine. Everything goes well until you try to run one of the "filters." These process wav files to remove clicks, hiss etc. The filter runs OK, but when it comes time to write the wav file modified in memory back to disk, it fails saying "The file contains a format not supported by DCart." At this point wine gives the error err:mmio:MMIO_ParseExtA No . in szFileName: "", which I have taken to mean that their is a problem in wine's implementation of the MMIO api. I have tried a native winmom.dll, but naturally that does not work at all; wine crashes on load. I have heard through another mailing list that this is an ancient regression, that this used to work. It is true that the filters work in Cedega, but run their DCart has so many graphical, and other problems, it is not usable. Any other suggestions or hints as to where I could start diffing code would be much appreciated. Thanks, Matthew D'Asaro
Re: Re: Wined3d: added A2R10G10B10 and D3DFMT_D24FS8
Added A2R10G10B10 and D3DFMT_D24FS8 modes to all other functions. Karsten > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Oliver Stieber > Gesendet: Samstag, 3. September 2005 22:15 > An: wine-devel@winehq.org; [EMAIL PROTECTED] > Betreff: ***SPAM*** Re: Wined3d: added A2R10G10B10 and D3DFMT_D24FS8 > > > > --- Karsten Elfenbein <[EMAIL PROTECTED]> wrote: > Can you put together a patch to add A2R10G10B10 and > D3DFMT_D24FS8 to utils.c as well please. > > D3DFmt2GLIntFmt needs to return GL_RGBA, D3DFmt2GLFmt needs > to return GL_RGBA, D3DFmt2GLType needs to return > GL_UNSIGNED_INT_2_10_10_10_REV, D3DFmtGetBpp needs to return 4, > D3DFmtMakeGlCfg needs to > PUSH2(GLX_ALPHA_SIZE, 2); > PUSH2(GLX_RED_SIZE, 10); > PUSH2(GLX_GREEN_SIZE, 10); > PUSH2(GLX_BLUE_SIZE,10); > > Also in surface.c IWineD3DSurfaceImpl_UnlockRect needs to use > > glDrawPixels(This->lockedRect.right - This->lockedRect.left, > (This->lockedRect.bottom - > This->lockedRect.top) - 1, GL_BGRA, GL_UNSIGNED_INT_2_10_10_10_REV, > This->resource.allocatedMemory); > when unlocking the back buffer > > > Thanks, > Oliver. > > Changelog: > > * added A2R10G10B10 and D3DFMT_D24FS8 modes > > > > > eve2.diff Description: Binary data
Delphi edit control created in Unicode instead of ANSI mode
Hi Frank, One of your theming patches ( http://www.winehq.org/hypermail/wine-cvs/2005/08/0313.html ) has caused a problem in many Delphi applications. The edit controls of Delphi applications are now created in Unicode mode. I hope you have an idea why this happens... Of course Delphi applications are ANSI and expect ANSI controls in their windows. If you believe that this is a real problem, you won't need to read the rest of this email :-) Because the Delphi edit controls are now in Unicode mode, the messages sent to them have to be translated from ANSI to Unicode and back. When a program reads the "Text" property of a TEdit control, Delphi sends a WM_GETTEXTLENGTH message. Wine doubles the return value when translating back from Unicode to ANSI because of double-byte character sets. (dlls/user/winproc.c) Now Delphi gets the doubled text size (should be no problem because WM_GETTEXTLENGTH only returns an upper limit of the text size, but Delphi doesn't regard this fact). Because Delphi does NOT use zero-terminated strings, Delphi will return a string that has twice the size of the text in the edit control and contains a '\0' character. If the application then concatenates this string with another string and passes the result to a Windows API function, the API function will only see the first string because of the '\0' character. I've discovered the problem because installers created by InnoSetup ( http://www.innosetup.com/ ) are now failing. You may use my simple Delphi demo program to test the bug: http://www.michael-kaufmann.ch/WINE/DelphiEdit.zip Regards Michael
Re: http://cvs.winehq.org/patch.py?id=19897 (shlfolder.c test)
On Sun, 2005-09-04 at 16:17 +0300, Saulius Krasuckas wrote:
> * On Sat, 3 Sep 2005, Saulius Krasuckas wrote:
> > * On Sat, 3 Sep 2005, Paul Vriens wrote:
> > >
> > > this change to shell32/tests/shlfolder.c fails on Win98/WinNT and
> > > W2KProf because ILFindLastID is not exported on those platforms.
> > >
> > > I tried to change shlfolder.c to test for the export, but that shows
> > > that it's not exported on Wine either ? The .spec file says different.
> >
> > I have made pretty trivial change and it worksforme. See below.
>
> I believe the test works a lot better now. Still I tried upgrading my RH8
> glibc to one of FC4 and now I sit even w/o XF. :-/
>
>
> Log message:
> Saulius Krasuckas <[EMAIL PROTECTED]>
> SHELL32.dll.ILFindLastID is exported by an ordinal on an older
> platforms.
...
> /* This test shows that Windows doesn't allocate a new pidlLast, but
> returns a pointer into
> * pidlTestFile (In accordance with MSDN). */
> -todo_wine{ok (ILFindLastID(pidlTestFile) == pidlLast,
> +todo_wine{ok (pILFindLastID(pidlTestFile) == pidlLast,
> "SHBindToParent doesn't return the last id
> of the pidl param!\n");}
Shouldn't we (for consistency sake) surround the call to pILFindLastID
with a:
if (pILFindLastID)
Cheers,
Paul.
Re: mail address
On Sat, 03 Sep 2005 20:22:16 +0300, Saulius Krasuckas wrote: > This doesn't work anymore for me. I still would like to prevent winetest > from being compiled. You may need to re-run make_progs or whatever the script is called in the programs directory. Alternatively just brute force it out of the build system. Incidentally, I'm just stopping by, off on holiday soon then onto final year of university so I won't be around much, and will only be keeping half an eye on wine-devel. Mail me privately or grab me on IRC if you want me. thanks -mike
Re: http://cvs.winehq.org/patch.py?id=19964
On Sat, 2005-09-03 at 11:13 -0700, Juan Lang wrote: > > this latest change to the shellpath test produces the attached error on > > Windows XP. Haven't looked into this further. > > Damn. Alexandre, would you mind backing out this patch? It needs more > work. > http://cvs.winehq.org/patch.py?id=19964 > > Thanks, > --Juan > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > Hi, that should have been http://cvs.winehq.org/patch.py?id=19963 instead of 19964 (my fault). Cheers, Paul.
Re: Installers freezing - ole, games
On Sun, Sep 04, 2005 at 02:17:06AM -0500, Robert Shearman wrote: > Ivan Gyurdiev wrote: > > >Hi, > > > >I've been trying to get GTA: San Andreas, > >and Battlefield 2 running on Linux, so far > >without success. > > > >I suspect they are running into the same bug, > >because they produce very similar output (ole fixmes). > >Both games will freeze at some point during the install. > > > >Strangely, I don't see any errors, but I have provided > >an ole trace for each. Do you have any suggestions as to > >what the problem might be, or how to track it down? > > > >http://bugs.winehq.org/show_bug.cgi?id=3108 > > > Thanks for reporting this. In order for the logs of these types of > programs to make sense, you really need to give me one with > +ole,+olerelay,+seh,+tid options. I suspect it is the following bug though: > > In newer InstallShields, there is a marshaled object that contains a > function with a VT_PTR -> VT_USERDEFINED( TKIND_ENUM ). This should be > treated as "int *", but is actually treated as "int". This is due to > some broken logic in the typelib marshaler that is designed to fix the > problem with VT_PTR -> VT_USERDEFINED( TKIND_INTERFACE ) -> "IUnknown > *", but where we should dereference the pointer any more. > We probably need to use the logic in ITypeInfo::Invoke to appropriately > transform the soup of pointers and userdefined types into something we > can use. I should also need to check what things are accepted in the > native version. i.e. is VT_PTR -> VT_PTR -> VT_USERDEFINED( TKIND_ENUM ) > supported? If so, that isn't representable by the VARIANT vt's, so we > would need to treat it differently than the ITypeInfo::Invoke case. Do you have a freely downloadable installer that exposes this? Ciao, Marcus
Re: winedebug/gdb crashes
Simon Kissane a écrit : Hi Using latest wine CVS (checked out today), trying to debug the PackageForTheWeb self-extracting EXE that MS uses to distribute MSDE 2000 The EXE works fine (albeit with some visual bugs) when running under plain wine instead of winedebug Anyone have any idea what might be wrong? (I am very new to wine, although I've been following the wine-devel archives for a while...) Cheers Simon Kissane = winedebug window == winedbg --gdb --no-start z:/home/skissane/downloads/MSDE2000A.exe 001b:001c: create process 'Z:\home\skissane\downloads\MSDE2000A.exe'/0x7fff003c @0040ce00 (0<0>) 001b:001c: create thread I @0040ce00 target remote localhost:32815 001b:001c: loads DLL c:\windows\system\ntdll.dll @0084 (0<0>) 001b:001c: loads DLL c:\windows\system\kernel32.dll @00e5 (0<0>) 001b:001c: loads DLL c:\windows\system\advapi32.dll @0077 (0<0>) 001b:001c: loads DLL c:\windows\system\gdi32.dll @0037 (0<0>) 001b:001c: loads DLL c:\windows\system\user32.dll @0027 (0<0>) 001b:001c: loads DLL c:\windows\system\comctl32.dll @0043 (0<0>) fixme:dbghelp:elf_new_wine_thunks Duplicate in comctl32: refDataPropName<004b4d60-0020> subclasses<4b4d60-> 001b:001c: loads DLL c:\windows\system\iphlpapi.dll @00b0 (0<0>) 001b:001c: loads DLL c:\windows\system\rpcrt4.dll @004e (0<0>) 001b:001c: loads DLL c:\windows\system\ole32.dll @006b (0<0>) 001b:001c: loads DLL c:\windows\system\shlwapi.dll @00d9 (0<0>) 001b:001c: loads DLL c:\windows\system\shell32.dll @0055 (0<0>) 001b:001c: loads DLL c:\windows\system\lz32.dll @003e (0<0>) 001b:001c: loads DLL c:\windows\system\winex11.drv @00ca (0<0>) 001b:001c: loads DLL c:\windows\system\imm32.dll @0071 (0<0>) 001b:001c: exception code=0x8003 wine-pthread: gdbproxy.c:1984: extract_packets: Assertion `i == gdbctx->out_len' failed. wine: Unhandled exception (thread 001d), starting debugger... WineDbg starting on pid 0x1e Unhandled exception: assertion failed in 32-bit code (0x595a97e2). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:595a97e2 ESP:7fcbf38c EBP:7fcbf3a0 EFLAGS:0202( - 00 - - I1) EAX: EBX:4e8c ECX:4e8c EDX:0006 ESI: EDI:2014fff4 Stack dump: 0x7fcbf38c: 200521f8 4e8c 2014fff4 0x7fcbf39c: b7efe9e0 7fcbf4cc 20053948 0006 0x7fcbf3ac: 7fcbf440 0060 7d00bf80 0x7fcbf3bc: 0068 2008bae7 7fcbf404 0x7fcbf3cc: 7d00bf88 7d00bfec 7fcbf4dc 2014fff4 0x7fcbf3dc: 0059 005a 7fcbf4b0 20086515 0200: sel=1007 base=b7f04000 limit=1f97 32-bit rw- Backtrace: =>1 0x595a97e2 (0x7fcbf3a0) 2 0x20053948 (0x7fcbf4cc) 3 0x2004b38e (0x7fcbf510) 4 0x75ff7e2f gdb_remote+0xaab(flags=0x1) [/home/skissane/osdevel/wine/programs/winedbg/gdbproxy.c:1981] in winedbg (0x7fcbfddc) 5 0x76002b9b main+0x473(argc=0x2, argv=0x7fee04a8) [/home/skissane/osdevel/wine/programs/winedbg/winedbg.c:1285] in winedbg (0x7fcbfeac) 6 0x75fef26f __wine_exe_main+0x176 in winedbg (0x7fcbff2c) 7 0x4bdbe9e2 start_process+0xb6(arg=0x0) [/home/skissane/osdevel/wine/dlls/kernel/process.c:996] in kernel32 (0x7fcbfff4) 8 0x20004935 wine_switch_to_stack+0x11 in libwine.so.1 (0x) 0x595a97e2: ret Modules: Module Address Debug info Name (21 modules) ELF 0x0051b000-00537000 Deferred ld-linux.so.2 ELF 0x00539000-00663000 Deferred libc.so.6 ELF 0x00665000-00669000 Deferred libdl.so.2 ELF 0x0066b000-0068f000 Deferred libm.so.6 ELF 0x00a05000-00a17000 Deferred libpthread.so.0 ELF 0x2000-20018000 DIA libwine.so.1 ELF 0x20154000-201c6000 Deferred ntdll \-PE 0x2017-201c6000 \ ntdll ELF 0x201ea000-201f5000 Deferred libnss_files.so.2 ELF 0x201f5000-2020b000 Deferred psapi \-PE 0x2020-2020b000 \ psapi ELF 0x39fc3000-39fff000 Deferred advapi32 \-PE 0x39fd-39fff000 \ advapi32 ELF 0x45dc6000-45e01000 Deferred dbghelp \-PE 0x45dd-45e01000 \ dbghelp ELF 0x4bd54000-4be4f000 Stabs kernel32 \-PE 0x4bd8-4be4f000 \ kernel32 ELF 0x6be33000-6bf28000 Deferred libwine_unicode.so.1 ELF 0x75fd7000-76019000 Stabs winedbg \-PE 0x75fe-76019000 \ winedbg ELF 0x7bf0-7bf03000 Deferred Threads: process tid prio (all id:s are in hex) 001b 001c 0 001e (D) c:\windows\system\winedbg.exe 001d 0 <== 000e 000f 0 000a 000b 0 WineDbg terminated on pid 0x1e = gdb window == gdb GNU gdb Red Hat Linux (6.3.0.0-1.21rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu". (gdb) target remote localhost:32815 Remote deb
Re: Installers freezing - ole, games
Thanks for reporting this. In order for the logs of these types of programs to make sense, you really need to give me one with +ole,+olerelay,+seh,+tid options. I suspect it is the following bug though: I've attached the necessary logs to: http://bugs.winehq.org/show_bug.cgi?id=3108 Thanks for the reply...
Re: More debugger quesions
Robert Lunnon a écrit : OK I am back onto the trail but the code doesn't make sense to me Continue Debug Event Sends a message continue_debug_event to the wineserver which ends up in this function in thread.c basically what happens: let's call P the process that sends the debug event (ie the process being debugger) and D the debugger - P gets an exception, and first wants to notify the debugger - P calls queue_exception_event in wineserver - WS (wineserver) then suspends P (ie signals every thread of P with SIGUSR1) - WS queues debug event - D gets the event (wait_debug_event) - D handles the event - D informs WS it's done with the event (continue_debug_event) - WS then resumes every thread of P (that's the wakeup_thread function) - P (in fact the thread that queued the event) resumes and can fetch the result of the handling of the debug event HTH A+ -- Eric Pouech
Re: Installers freezing - ole, games
Ivan Gyurdiev wrote: Hi, I've been trying to get GTA: San Andreas, and Battlefield 2 running on Linux, so far without success. I suspect they are running into the same bug, because they produce very similar output (ole fixmes). Both games will freeze at some point during the install. Strangely, I don't see any errors, but I have provided an ole trace for each. Do you have any suggestions as to what the problem might be, or how to track it down? http://bugs.winehq.org/show_bug.cgi?id=3108 Thanks for reporting this. In order for the logs of these types of programs to make sense, you really need to give me one with +ole,+olerelay,+seh,+tid options. I suspect it is the following bug though: In newer InstallShields, there is a marshaled object that contains a function with a VT_PTR -> VT_USERDEFINED( TKIND_ENUM ). This should be treated as "int *", but is actually treated as "int". This is due to some broken logic in the typelib marshaler that is designed to fix the problem with VT_PTR -> VT_USERDEFINED( TKIND_INTERFACE ) -> "IUnknown *", but where we should dereference the pointer any more. We probably need to use the logic in ITypeInfo::Invoke to appropriately transform the soup of pointers and userdefined types into something we can use. I should also need to check what things are accepted in the native version. i.e. is VT_PTR -> VT_PTR -> VT_USERDEFINED( TKIND_ENUM ) supported? If so, that isn't representable by the VARIANT vt's, so we would need to treat it differently than the ITypeInfo::Invoke case. This is a high priority for me as this one bug prevents a number of installers from working correctly. However, I'm in the middle of some other work at the moment, so I don't know when I'll get around to it. -- Rob Shearman
