Re: Nearly all Installshield installers fail
Joaquín Fernández wrote: > With my application (Route 66), it enables me to start copying files, > however the progress bar never moves. However, the installer is doing > something but seems to be stuck somewhere. Maybe some deadlocks. I have had many problems with InstallShield but i was able to install the programs (about 3 or 4 programs using InstallShield that i need) using WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n,b". You can probe with this.. it worked for this programs in Wine 2004 and 2005. Obviously, you must verify that this DLLs exist in the system dir. This is not a good long-term solution since it requires a download from Microsoft. There are a number of issues with InstallShield currently. I had hoped that getting one working would get all working, but this doesn't seem to be the case from the current discussion on wine-devel. I am aware of 3 issues with ole32, 2 deadlocks and one error. The remaining issues appear to be with the typelib marshaler, which unfortunately lacks regression tests. Rob
Nearly all Installshield installers fail
> With my application (Route 66), it enables me to start copying files, > however the progress bar never moves. However, the installer is doing > something but seems to be stuck somewhere. Maybe some deadlocks. Español: Yo tuve varios problemas con algunos programas que usan InstallShield como instalador (alrededor de 3 o 4) pero pude instalarlos usando WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n,b". Puedes probar esto a ver si te funciona, para mí si funciona con estos programas en Wine 2004 y 2005. Obviamente, verifica que tengas esas DLLs en el sistema. English: I have had many problems with InstallShield but i was able to install the programs (about 3 or 4 programs using InstallShield that i need) using WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n,b". You can probe with this.. it worked for this programs in Wine 2004 and 2005. Obviously, you must verify that this DLLs exist in the system dir. Regards Joaquin -- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.4 (GNU/Linux) mQFCBEFI/gARAwDd2+ojasT3rCyRktSw+Ix3m+yoxSD0NkpMLlunmJxwvn6wKZVl mDw76/Zu9mqDWWeSGdSl+60T7fDLrJZSEB45O9T5jdujj01GFeer7xuiuHBTFw8o CXqD/hzhqYc46ecAoIQQjZ2qZtOWLPRBbegK/nyOIguNAv9QGiKPLBS8o0ksxEUp EfLAExVmu6Zp693uKGf6XrBWNcLriuwRPr1mjy3N/bhMlqc3vcTeUBwxiUuX5h2P NQgB3d2AbJS6oEvhmZL0Bn/8Ij/MSvVrartmCXuw9eSx0aMC/R7Kw9TtUfxFVUGx fQKwoA9BXNElPLcNohbBS/fH87IMMxCJyn+rmTeNCEcUEQ7UgvVCdlzZ8+L4PdlH qGR81nhZVEwPRnSSesLpSHRC1QQVoceBeb7PICr/b2eZiKMX+bQ+Sm9hcXXDrW4g TWFudWVsIEZlcm7DoW5kZXogUXVpbGVzIDxqb2FxdWluQGNhc2FkZWFsYWJhbnph Lm9yZz6IXgQTEQIAHgUCQUj+AAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBH 677/q7xL4e15AJwNfSpeaXXMH2EjuKblfeBe51MrUgCcCP5jEnpXrDXLWULIW5yD t6VdHlU= =a8BM -END PGP PUBLIC KEY BLOCK-
Re: wine/dlls wininet/netconnection.c user/text.c ...
Le mer 30/03/2005 à 00:40, Dimitrie O. Paun a écrit : [snip] > Other than that, are all strncpy() instances gone? If so we should > also nuke strncpyW() from wine/unicode.h too. No, they're not all gone yet (or are in not applied patches). Vincent
Re: Wine device drivers proposal
Le ven 01/04/2005 à 17:06, Kuba Ober a écrit : [snip] > All that without touching the kernel in any way. And I mean > here full support for *any* usb device, rain or shine. Network adapters > (visible in wine only, but so what?), Does that mean we'd need a database of USB identifiers? For network adaptors visible in Wine only: Wine doesn't have a TCP/IP stack. Would that be needed to use such network adaptors? Vincent
Re: discusion about a message loop in listview.c
On Tue, Mar 29, 2005 at 06:52:07PM +0200, Dietrich Teickner wrote: > I have some weeks before reported, FlashFXP v3.02 loops with a > message-loop in listview.c after login. It does this in Odin and in Wine. > In Odin it stops in smaller time (deep 1000). Wine has a bigger stack, > and so needs wine more time for this, bat I can see in the loog, the > args for the function are more and more locatet at lower stack adresses. > I have written this workarout for testing this problem in wine and in > odin. with this FlashFXH 3.02 will display the contence of the server > dir very fast at both environment. In the log I can see, that the > message-loop was reported and stopped. I thing, we need a flag inside > any item to report every function, that can called recursive, this item > is in work (function-separart, or global ?), that can stop recursions of > this type in the future or many programms. I have also found this try > does also helps Agent 2.0 in the groups->defailt propertys (only > odin-tested). > This does also every crashs in earlyer builds with stack overflow in odin. Dietrich, You need to create a small example app that exhibits this behaviour such that it crashes on Wine/Odin, but runs in Windows. As things stand, I can not test with either app since they don't install under Wine. In any event, a small example app would be better, since the source would be available too. -- Dimi.
Re: WineConf Agenda
Hi, On Fri, 2005-04-01 at 02:20, Jakob Eriksson wrote: > 2) What's almost never been brought up on wine-devel is the > unit testing in the XP sense. The problem is you need to write a stub interface for all of the functions the function or library you are testing due to all the cross-calls win32 makes. You end up spending a huge ammount of time just writting stubs. In the ReactOS CIS system Casper has implemented support for this and while its a good idea it a rather large beast. I think he developed a system to automagicly generate the stubs needed but then you end up having two sets of tests to test the same functions. Not to mention I don't see how it can work on Linux anyway. Thanks Steven
Re: Wine device drivers proposal
> I am not trying to _load_ a Windows driver (that > either requires kernel support for the Windows DDK, > like ndiswrapper has, or emulation of an entire x86, > like bochs does). Not really. It just needs some sort of device-class-specific forwarding protocol. usbfs and libusb already do that, and you should be able to run any windows driver that way without even touching the kernel. ndiswrapper does what it does because they want to expose non-usb devices and to the whole linux system at that. I.e. they support pci devices as well as usb. If they wanted to support usb only, it's all plain userspace. You can emulate network adapters in userspace using TAP or however it's called, and you can talk to arbitrary usb devices from userspace via usbfs and libusb. In fact, for a wide variety of PCI drivers out there it should be perfectly feasible to provide a "short-circuit" kernel driver that could expose full access to a PCI device do a userland application, thus allowing wine to support arbitrary PCI devices as well. Considering that 2.6 kernel already has hardware abstraction that disconnects actual hardware accesses (like port/read writes and so on) from the logic of the PCI device drivers, it wouldn't be that hard to make such a gizmo. http://vtun.sourceforge.net/tun/faq.html http://libusb.sourceforge.net/ Cheers, Kuba
Re: Wine device drivers proposal
> > I've been trying to add STI (still image) support to > > Wine, and I've made some progress. However, I see a > > deep and unsurmountable need to add (at least > > user-space) device drivers to Wine, and I would like > > some feedback on these ideas. > > Drivers belong in the kernel. Not necessarily. In fact, only the part that directly touches the hardware really belongs there. There's nothing wrong with doing rest of the processing (i.e. the non time-critical parts) in the userspace. In fact, that likely makes the kernel a safer place. > If there's no Linux driver for a device, > then Wine cannot support it. That would be stupid. > In that case, the first step is to write a > Linux device driver for it, which has the added advantage that other > native linux applications can use the hardware. Huh? What about sane? It can e.g. use libusb quite nicely and *portably* to say access usb scanners. I.e. it flies on both windows *and* linux. > You can't load a Windows driver that accesses hardware in Wine, as Wine > is a user-space application with no I/O privileges. You could, with help of a special kernel driver to forward the requests between hardware and userspace. libusb and usbfs do that already for usb, i.e. at the current point in time wine can be able to natively support any usb device minidriver that doesn't use a class driver. Class drivers can be easily developed by snatching code from linux kernel, as long as licenses are fine of course. All that without touching the kernel in any way. And I mean here full support for *any* usb device, rain or shine. Network adapters (visible in wine only, but so what?), scanners, cheap webcams whose manufacturers don't care enough to release the specs, and the list goes on. Cheers, Kuba
Re: WineConf Agenda
On Tue, Mar 29, 2005 at 10:31:33PM -0700, Brian Vincent wrote: > I'm going to start this off with a huge apology - there's a very real > chance I've asked someone to do a presentation and it's not on this > list. If so, you need to email me to remind me. If you were > definitely planning on presenting something because I emailed you, let > me know - there's lots of space available. I know this only affects 2 > or 3 people, but I tossed around a few ideas and didn't want to leave > any loose ends. (Any of those items would make nice topics.) > > This is the initial agenda for WineConf. I hope to add a few more > items, but Jeremy suggested I pull the trigger and announce it. I > agree - there's enough here to fill two days and leave a lot of time > for people to get together in small groups. Only the first two items > are in any formal order: > > Alexandre - Keynote (He said he's reusing last year's slides.) > Dimi - to do list / status update > Steven Edwards and the ReactOS crew > Charles W Stevenson - Winelib / Winelib porting / and a commercial > perspective > Andrew Barlett / Samba team? - Samba 4, authentication, lots of > intelligent ideas > Juan Lang - Wine's RPC + Samba or something like that :) > Jeremy White - CXTest > Jason Edmeades - DirectX 9 / wined3d / eye candy > > I think a full agenda would be about 11 items. If you would like to > present something let me know - there's definitely space available. I could give an introduction into reverse engineering, including an IDA Pro introduction (if there is interest.) Ciao, Marcus
Re: Riched20: thanks + regression "beta" not shown
On Fri, 01 Apr 2005 18:04:32 +0200 Tobias Burnus <[EMAIL PROTECTED]> wrote: > Hmm, I think the reason for my boxes was that I didn't install > symbol.ttf from Windows (I had only a "Symbol Set BT" and bitmap fonts > before). Yes, I also noticed some problems with font substitution... -- Ph.
Re: Riched20: thanks + regression "beta" not shown
Tobias Burnus wrote: Hmm, I think the reason for my boxes was that I didn't install symbol.ttf from Windows (I had only a "Symbol Set BT" and bitmap fonts before). Anyway, both displaying in the application _and_ (thanks to the patch) exporting to RTF work now. Wine can compile fonts from the sfd files produced by FontForge, so if we built our own symbol.ttf we wouldn't need to copy symbol.ttf from Windows. If somebody is interested in kicking off a Symbol font (just adding a beta symbol would help Tobias) then grab font forge from http://fontforge.sourceforge.net/ and have a look in wine/fonts. We could also explore the possibilty of using the one from Open Office... Mike
Re: Nearly all Installshield installers fail
With my application (Route 66), it enables me to start copying files,
however the progress bar never moves. However, the installer is doing
something but seems to be stuck somewhere. Maybe some deadlocks.
Max
PS(specially for Mike): I'm a man :)
On Fri, 2005-04-01 at 18:02 +0200, Uwe Bonnes wrote:
> > "Mike" == Mike Hearn <[EMAIL PROTECTED]> writes:
>
> Mike> On Fri, 01 Apr 2005 10:53:36 +0200, Uwe Bonnes wrote:
> >> nearly all recent install shield installer fail for me, similar like:
>
> Mike> I debugged this a bit with Maxime Bellenge, she sent me a full
> Mike> trace which revealed that this is a known problem. Here is a quick
> Mike> hacky patch to work around it:
>
> Mike> Index: stubmanager.c
> Mike> ===
> Mike> RCS file: /home/wine/wine/dlls/ole32/stubmanager.c,v retrieving
> Mike> revision 1.19 diff -u -p -r1.19 stubmanager.c --- stubmanager.c 17
> Mike> Mar 2005 10:26:20 - 1.19 +++ stubmanager.c 23 Mar 2005
> Mike> 21:51:08 - @@ -477,7 +481,7 @@ BOOL
> Mike> stub_manager_notify_unmarshal(struc default: WARN("object OID %s
> Mike> already unmarshaled\n", wine_dbgstr_longlong(m->oid)); - ret =
> Mike> FALSE; + ret = TRUE; /* FIXME */ break; }
>
> The altera installation proceeds a little bit, but not in a usefull way.
>
> Thanks
RE: WineConf Agenda
Title: RE: WineConf Agenda In presenting the commercial value of wine and why we chose to use it, etc. How much time do I have for the presentation? -Original Message- From: Jakob Eriksson [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 31, 2005 11:20 PM To: [EMAIL PROTECTED] Cc: Wine Devel; [EMAIL PROTECTED] Subject: Re: WineConf Agenda Brian Vincent wrote: >I think a full agenda would be about 11 items. If you would like to >present something let me know - there's definitely space available. >If you've been wondering, "There's a neat project I'd like to do if I >could only get a few more people interested", well, this is the >perfect time to bring it up. If there's something strategic to Wine >development, this is a great time to discuss it. > > I don't know if I can find the time to prepare a proper presentation, but if I do, I'd like talk about and get some input from you on the subject of testing. 1) I want the conformance tests done faster. (I have a clear idea how.) 2) What's almost never been brought up on wine-devel is the unit testing in the XP sense. 1 has been discussed on wine-devel quite a bit, so I'll skip it in this mail. regarding 2: CXTest is like application testing. This is good, high-level testing. The conformance tests test the Windows API. But in the case of a complicated API (and Windows is complicated) maybe we need to test the smaller units behind the API. So, the conformance tests often are somewhere between application testing and unit testing. Can we have an infrastructure for running unit tests of small units of code private to the implementation? I.e. these tests, we could call them "private tests", would not run on Windows, but during build of Wine. Would it be acceptable to just include extra test code in the implementation c file, surrounded by #ifdef COMPILE_PRIVATE_TESTS ? regards, Jakob
Re: Riched20: thanks + regression "beta" not shown
Hello,
Phil Krylov wrote:
Before it showed a beta character from the Symbol font, now it only
shows a box ("[]").
Did you check later CVS? I tried to read an RTF containing beta from the
Symbol font both as 'b' (CP_SYMBOL codepage) and as 0xF062 (Unicode),
and both did look like betas on the screen.
Hmm, I think the reason for my boxes was that I didn't install
symbol.ttf from Windows (I had only a "Symbol Set BT" and bitmap fonts
before). Anyway,
both displaying in the application _and_ (thanks to the patch) exporting
to RTF work now.
One feature request: Currently, tabs are shown as box ("[]"), how about
replacing them with a simple space - that would increase the readability
a lot.
I suppose this is more addressed to Krzysztof... The readability could be
even better if tab positions were supported :)
True ;) But failing to write patches for Wine myself, I'll try not to
ask to much.
Tobias
Re: Nearly all Installshield installers fail
> "Mike" == Mike Hearn <[EMAIL PROTECTED]> writes:
Mike> On Fri, 01 Apr 2005 10:53:36 +0200, Uwe Bonnes wrote:
>> nearly all recent install shield installer fail for me, similar like:
Mike> I debugged this a bit with Maxime Bellenge, she sent me a full
Mike> trace which revealed that this is a known problem. Here is a quick
Mike> hacky patch to work around it:
Mike> Index: stubmanager.c
Mike> ===
Mike> RCS file: /home/wine/wine/dlls/ole32/stubmanager.c,v retrieving
Mike> revision 1.19 diff -u -p -r1.19 stubmanager.c --- stubmanager.c 17
Mike> Mar 2005 10:26:20 - 1.19 +++ stubmanager.c 23 Mar 2005
Mike> 21:51:08 - @@ -477,7 +481,7 @@ BOOL
Mike> stub_manager_notify_unmarshal(struc default: WARN("object OID %s
Mike> already unmarshaled\n", wine_dbgstr_longlong(m->oid)); - ret =
Mike> FALSE; + ret = TRUE; /* FIXME */ break; }
The altera installation proceeds a little bit, but not in a usefull way.
Thanks
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Re: Nearly all Installshield installers fail
> "Mike" == Mike Hearn <[EMAIL PROTECTED]> writes: Mike> On Fri, 01 Apr 2005 12:03:46 +0200, Marcus Meissner wrote: >>> nearly all recent install shield installer fail for me, similar >>> like: Mike> Which InstallShield version is this? A "strings" on the installation file gives: >... >InstallShield Setup Player 2K2 >... >Created by MIDL version 6.00.0347 at Mon Dec 02 13:30:56 2002 Or how else to easy extract the version. This was with quartusii_42_sp1_web_edition_single.exe from thw www.altera.com site. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: wine/ windows/scroll.c dlls/x11drv/scroll.c dl ...
On Mon, 28 Mar 2005 07:54:12 -0500, you wrote: > As for the initial problem that I've > reported (http://www.winehq.org/hypermail/wine-devel/2002/09/0748.html), > you are correct, it's about interaction with the invalidated region. > I've figured that while you have your hands wet in that code, maybe > you can take a stab at it. Thanks for taking a look! It is a little more complicated then the way you explain it. First, if you do not move the window that obstructs the scrolling lists then there are no defects (use something else to cause the lists to scroll). Yet, some added tracing shows that ScrollWindowEx (creating invalidated regions) is called far more often then paintings (which validates those regions). So ScrollWindowEx will typically have to scroll invalidated regions of previous scrolls. And, as far as I can see, the code does this flawlessly. But, if you move the window that obstructs the scrolling list around, then areas that where obstructed and get exposed must be invalidated. This happens when the exposure events are processed. Now you can imagine that the area that needs to be invalidated is different if it is processed before the scroll or after the scroll. Since there is no synchronization between exposure events and ScrollWindowEx calls, this explains why it must go wrong in some cases and we see the defects. I've tried a few things but this is a problem that is beyond me, if it is solvable at all. Perhaps Alexandre can give a hint how this should be solved. Rein.
Re: WineConf Agenda
Brian Vincent wrote: I think a full agenda would be about 11 items. If you would like to present something let me know - there's definitely space available. If you've been wondering, "There's a neat project I'd like to do if I could only get a few more people interested", well, this is the perfect time to bring it up. If there's something strategic to Wine development, this is a great time to discuss it. I don't know if I can find the time to prepare a proper presentation, but if I do, I'd like talk about and get some input from you on the subject of testing. 1) I want the conformance tests done faster. (I have a clear idea how.) 2) What's almost never been brought up on wine-devel is the unit testing in the XP sense. 1 has been discussed on wine-devel quite a bit, so I'll skip it in this mail. regarding 2: CXTest is like application testing. This is good, high-level testing. The conformance tests test the Windows API. But in the case of a complicated API (and Windows is complicated) maybe we need to test the smaller units behind the API. So, the conformance tests often are somewhere between application testing and unit testing. Can we have an infrastructure for running unit tests of small units of code private to the implementation? I.e. these tests, we could call them "private tests", would not run on Windows, but during build of Wine. Would it be acceptable to just include extra test code in the implementation c file, surrounded by #ifdef COMPILE_PRIVATE_TESTS ? regards, Jakob
Fwd: Re: [Wine]winetest and winrash
Ivan Leo Puoti wrote: Mitchell Mebane wrote: Hey there, I ran it on my XP Pro SP2 desktop and Windows Server 2003 under VMWare just fine, but when I ran it on Win2K Pro SP4 under VMWare, it told me the log was too large (6.4 MB > 1 MB) and it would only send partial results. Is there any reason this log would be almost an order of magnitude larger than the others? >From the log it appears to be a problem with the PathIsValidCharA API, you may want to report this to wine-devel. Ivan. . OK, I'll do so. Results are on this page: http://test.winehq.com/data/200503311000/ Specifically, this: http://test.winehq.com/data/200503311000/2000_mmebane/shlwapi:path.txt The OS setup I ran the test under is pretty much a bare-bones Win2K Pro SP4 install. If you want any more information about it, let me know. --Mitchell -- The roots of education are bitter, but the fruit is sweet. --Aristotle
Re: Nearly all Installshield installers fail
On Fri, 01 Apr 2005 10:53:36 +0200, Uwe Bonnes wrote:
> nearly all recent install shield installer fail for me, similar like:
I debugged this a bit with Maxime Bellenge, she sent me a full trace which
revealed that this is a known problem. Here is a quick hacky patch to work
around it:
Index: stubmanager.c
===
RCS file: /home/wine/wine/dlls/ole32/stubmanager.c,v
retrieving revision 1.19
diff -u -p -r1.19 stubmanager.c
--- stubmanager.c 17 Mar 2005 10:26:20 - 1.19
+++ stubmanager.c 23 Mar 2005 21:51:08 -
@@ -477,7 +481,7 @@ BOOL stub_manager_notify_unmarshal(struc
default:
WARN("object OID %s already unmarshaled\n",
wine_dbgstr_longlong(m->oid));
-ret = FALSE;
+ret = TRUE; /* FIXME */
break;
}
But I suspect you will hit further problems later.
Re: Nearly all Installshield installers fail
On Fri, 01 Apr 2005 12:03:46 +0200, Marcus Meissner wrote: >> nearly all recent install shield installer fail for me, similar like: Which InstallShield version is this?
Re: Nearly all Installshield installers fail
On Fri, Apr 01, 2005 at 10:53:36AM +0200, Uwe Bonnes wrote: > Hello, > > nearly all recent install shield installer fail for me, similar like: > ... > fixme:ole:RegisterTypeLib Registering non-oleautomation interface! > fixme:sync:SetNamedPipeHandleState 0x1f0 0x42ad30e0 (nil) (nil) > fixme:sync:SetNamedPipeHandleState 0x214 0x42ddc0e0 (nil) (nil) > fixme:ole:RpcChannelBuffer_GetDestCtx (0x42551d8c,0x42551d90), stub! > fixme:sync:SetNamedPipeHandleState 0x214 0x432080e0 (nil) (nil) > fixme:ole:NdrConvert (pStubMsg == ^0x406cca80, pFormat == ^0x431041ba): stub. > fixme:ole:NdrConvert (pStubMsg == ^0x42551d18, pFormat == ^0x431041ba): stub. > err:ole:get_unmarshaler_from_stream Failed to read common OBJREF header, > 0x > fixme:ole:RpcChannelBuffer_GetDestCtx (0x42551d88,0x42551d8c), stub! > fixme:sync:SetNamedPipeHandleState 0x1e8 0x42ff00e0 (nil) (nil) > fixme:ole:NdrConvert (pStubMsg == ^0x406cca7c, pFormat == ^0x431041c8): stub. > fixme:ole:NdrConvert (pStubMsg == ^0x42551d14, pFormat == ^0x431041c8): stub. > fixme:sync:SetNamedPipeHandleState 0x1e4 0x432080e0 (nil) (nil) > fixme:sync:SetNamedPipeHandleState 0x1e4 0x42bd60e0 (nil) (nil) > fixme:sync:SetNamedPipeHandleState 0x1e4 0x42ad30e0 (nil) (nil) > fixme:sync:SetNamedPipeHandleState 0x1ec 0x42bd60e0 (nil) (nil) > fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from > 0x4003 -> 0x8) 42de13b4 > > Do I have some bogus registry entries, did I miss some dll registration or > is this the expected behaviour? Its one of the versions that do not work yet. Have not explored why yet ;) There is also one with MSI support that needs native MSI still. Ciao, Marcus pgpeajkmnusD4.pgp Description: PGP signature
Nearly all Installshield installers fail
Hello, nearly all recent install shield installer fail for me, similar like: ... fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:sync:SetNamedPipeHandleState 0x1f0 0x42ad30e0 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0x214 0x42ddc0e0 (nil) (nil) fixme:ole:RpcChannelBuffer_GetDestCtx (0x42551d8c,0x42551d90), stub! fixme:sync:SetNamedPipeHandleState 0x214 0x432080e0 (nil) (nil) fixme:ole:NdrConvert (pStubMsg == ^0x406cca80, pFormat == ^0x431041ba): stub. fixme:ole:NdrConvert (pStubMsg == ^0x42551d18, pFormat == ^0x431041ba): stub. err:ole:get_unmarshaler_from_stream Failed to read common OBJREF header, 0x fixme:ole:RpcChannelBuffer_GetDestCtx (0x42551d88,0x42551d8c), stub! fixme:sync:SetNamedPipeHandleState 0x1e8 0x42ff00e0 (nil) (nil) fixme:ole:NdrConvert (pStubMsg == ^0x406cca7c, pFormat == ^0x431041c8): stub. fixme:ole:NdrConvert (pStubMsg == ^0x42551d14, pFormat == ^0x431041c8): stub. fixme:sync:SetNamedPipeHandleState 0x1e4 0x432080e0 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0x1e4 0x42bd60e0 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0x1e4 0x42ad30e0 (nil) (nil) fixme:sync:SetNamedPipeHandleState 0x1ec 0x42bd60e0 (nil) (nil) fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0x8) 42de13b4 Do I have some bogus registry entries, did I miss some dll registration or is this the expected behaviour? Thanks -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
