April 2001 - Wine-Devel - list.winehq.org

Re: InstallShield and ole question...

by Jeremy White

juergen.schmied(a)debitel.net wrote: > > > As for doing the 10k+ lines of coding myself, I have experience in > > (de)marshalling and network coding, spent many years doing it, it's more a > > matter of available time and learning the com wire protocols, neither of which > > are currently available to me. Here's to hoping someone is already working on > > it ;). > For local marshalling we could use our own protocol and even our own way of ipc if we don't try to mix processes with native and wine com-dll's. It com server is only interested in the result ;-). And isn't the com marshalling similar to the dce one? > For networking - the dcom protocoll is documented (IMHO). With COM, the other issue is that someone needs to look at the MS patents in this area. Mainsoft is telling people that they can't use Wine to port COM code, because Microsoft holds patents on some of the Vtable logic used in COM (and no, I don't have any more detail than that, this came to me third hand). I've also asked the FSF for help tracking this FUD down and refuting it. The upshot of my comment is that it's critical that we use our own marshalling/ipc protocol. DCOM is documented, and what's more it appears to be well documented, and what's more, it doesn't look as though the implementation will be particularly hard... BTW, if there's anyone who wants to volunteer to attack this sooner, I think there are some corporate sponsors who'd be willing to kick in some beer money (okay, maybe we'd even spring for some *nice* beer, and a sofa to drink it on). Jer

April 27, 2001

Re: InstallShield and ole question...

by juergen.schmied＠debitel.net

> As for doing the 10k+ lines of coding myself, I have experience in > (de)marshalling and network coding, spent many years doing it, it's more a > matter of available time and learning the com wire protocols, neither of which > are currently available to me. Here's to hoping someone is already working on > it ;). For local marshalling we could use our own protocol and even our own way of ipc if we don't try to mix processes with native and wine com-dll's. It com server is only interested in the result ;-). And isn't the com marshalling similar to the dce one? For networking - the dcom protocoll is documented (IMHO). juergen

April 27, 2001

Re: InstallShield and ole question...

by Mike Bond

On Thu, Apr 26, 2001 at 04:47:01PM -0700, Dan Kegel wrote: > http://freedce.sourceforge.net/ is an open source project to implement COM. > It's been around quite some time, and started off from the same > DCE sources that Microsoft based its stuff on. > (See also http://linas.org/linux/corba.html ) > It was dormant for a while, but I think it's being worked on again. > > I wonder if that might not be useful here? That sounds interesting. I could start looking into it, but I'm really not sure I am the best person to depend on for moving this effort forward. As I said, I have little time to myself, with two elementary school age kids. I may have a bit more time once the latest crunch at work ends, but not sure I will have enough to put the amount of time it will take to accomplish this. There is also the matter that I don't really have a lot of experience specifically with ole/com, most of my exerience lies both proprietary and CORBA protocols, almost exclusively on *nix platforms. On the other hand, I personally see this as a major stumbling block for the widespread use of Wine, beyond the stability of completeness of the basic system. So, until someone else steps forward, I will see what I can do to persue this a bit farther. -- TTFN MikeB

April 27, 2001

Re: InstallShield and ole question...

by Mike Bond

On Thu, Apr 26, 2001 at 10:41:07PM +0200, Ove Kaaven wrote: > Well, that's not in Wine, at least... the Black & White installer fails > after something about CLSCTX_LOCAL_SERVER that's not implemented. Do you > mean it's in the Corel tree? CLSCTX_LOCAL_SERVER and CLSCTX_REMOTE_SERVER are the class context types that are not implemented yet. Some, though I'm not sure all, InstallShield v6 installers use that feature of ole. So no, the installer for Black & White, and pretty much any recent game that uses InstallShield, probably will not work. -- TTFN MikeB

April 27, 2001

Re: AVI resource in shell32.dll

by eric pouech

> normally, you just need to add a simple > id AVI "myfile.avi" > to the shell32_xx.rc file... > however, wrc doesn't recognize yet the AVI type > this should be added in order to let this work my mistake. wrc handles it correctly, but it doesn't like file ending after a non empty line. so you should be able to add your own animation here... MS one may be copyrighted A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

April 27, 2001

Re: InstallShield and ole question...

by Dan Kegel

Jeremy White wrote: > > This getes me back to the other part of the question, is anyone currently > > working on this? I know people at CodeWeavers supposedly were working on > > getting the various mutations of InstallShield working, this error seems > > to be pretty common across all InstallSheild v6 based installers I've seen. > > I had also heard there was progress getting Alice install working at > > TransGaming, is that InstallSheild v6 based? > > AFAIK, no one is actively doing this. We're working hard on the > installers, including everything up to the point of actually > diving of the COM/DCOM cliff. http://freedce.sourceforge.net/ is an open source project to implement COM. It's been around quite some time, and started off from the same DCE sources that Microsoft based its stuff on. (See also http://linas.org/linux/corba.html ) It was dormant for a while, but I think it's being worked on again. I wonder if that might not be useful here? - Dan

April 26, 2001

Re: Quickbooks 5 and printing

by Dan Engel

eric pouech wrote: > I wonder if QB5 doesn't assume that all printer drivers must be .drv > files > (not .dll), and gets the name with basic heuristics... QB5 does just that. There's a call STRCAT-ing the .DRV extension to the driver name (WINEPS) just before trying to load the module. I can make it cat an empty string instead (by hexedit-ing the qbwpr.dll file), and the STRCAT is clearly using an empty string now, instead of '.DRV', but the result is still the same (i.e., the printer doesn't work, and the same message box is given.) > > we should perhaps build wineps as wineps.drv (for now it's built as > wineps.dll) > > A+ > -- > --------------- > Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) > "The future will be better tomorrow", Vice President Dan Quayle

April 26, 2001

Re: InstallShield and ole question...

by Ove Kaaven

On Thu, 26 Apr 2001, Gavriel State wrote: > Mike Bond wrote: > > > > This getes me back to the other part of the question, is anyone currently > > working on this? I know people at CodeWeavers supposedly were working on > > getting the various mutations of InstallShield working, this error seems > > to be pretty common across all InstallSheild v6 based installers I've seen. > > I had also heard there was progress getting Alice install working at > > TransGaming, is that InstallSheild v6 based? > > The fix we put into the TransGaming tree was from Andreas Mohr, and it > fixed some problems related to previous versions of InstallSheild. We > haven't made any progress on v6. > > We'd certainly like to see it get done, but our resources are somewhat > limited at the moment, and we're concentrating on the DirectX work. > > Something that's interesting about the InstallShield objects is this: > They seem to expose a fair amount of their interfaces through OLE > Automation. I don't know for certain, but I have a recollection that > some work was done to support Automation for WordPerfect. I can't > remember whether that work was actually completed, or bypassed through > the use of dde for scripting instead. Well, that's not in Wine, at least... the Black & White installer fails after something about CLSCTX_LOCAL_SERVER that's not implemented. Do you mean it's in the Corel tree?

April 26, 2001

Re: AVI resource in shell32.dll

by eric pouech

Stefan Leichter wrote: > > Hi all, > > during debugging an installer (of Wiso Homebanking Try&Buy Version from > Buhl Data) i found that native shell32.dll contains at least one AVI > resource (the magnifier that is spinning in front of a computer) that is > not implemented in the buildin shell32.dll. I have looked around in the > source tree of wine but i did not find any resource from typ AVI. > > Now my questions: > > Is someone working on an implementation of avi resources into the > buildin dlls? > If not, what needs to be done to start implementing avi resources into > the dlls? normally, you just need to add a simple id AVI "myfile.avi" to the shell32_xx.rc file... however, wrc doesn't recognize yet the AVI type this should be added in order to let this work A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

April 26, 2001

Re: fault handling - oof

by eric pouech

Do you mean start the debugger by itself and attach the app before it faults, or run the app with the debugger? it could be either way. The later is a bit easier to do. I just wanted to get rid of the debugger startup code when an exception occurs... if you've already messed a lot with the memory, you may not be able to start the debugger. For example, the debugger launch code uses the Heap (from CreateProcess), which be give strange results... > Sorry for the noise, and thanks for insisting on common sense. > There was nothing wrong with any of those patches after all. no sweat ;-) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

April 26, 2001