January 2003 - Wine-Devel - list.winehq.org

RtlpWaitForCriticalSection?

by Mike Hearn

Using the latest Wine release, I see this error repeated over and over: err:ntdll:RtlpWaitForCriticalSection section 0x70460350 "?" wait timed out, retrying (60 sec) tid=08436988 when clicking on the CML demo at Adobes SVG demo site. Google indicates that this error can be caused by all sorts of things, one guy said it was due to Wine being a lot slower than Windows. So, could anybody write an explanation of what this error means? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 22, 2003

Re: Installshield 6 crash: ole trouble

by Mike Hearn

Why not just use threads? Is there a particular advantage to using IPC in this instance? I'd guess that ikernel.exe is the program that does the installing, and the program you launch does the front end code? On Tue, 2003-01-21 at 16:48, Greg Turner wrote: > On Tuesday 21 January 2003 04:38 am, Marcus Meissner wrote: > > On Tue, Jan 21, 2003 at 09:43:29AM +0000, Mike Hearn wrote: > > > Would this be fixed by the work that's being done on Wines RPC > > > implementation? > > > > This is a different implementation, when it is finished ... yes. > > don't hold your breath :) But I concur, implementing the RPC APIs, > including the DCOM specific ones, will fix it eventually. Now that I > have an actual working test, I can continue work on the actual > implementation side. But first I want to do some more cabextract > stuff, since it appears that it's not 100% working yet. > > > The current implementation should be capable of doing that too. > > > > > Why exactly does an installer require such complex parts of OLE > > > anyway? That seems like overkill for a self-extracting exe to me. > > > > No clue. > > Well, it's not hard to imagine why an installer might need some > interprocess communicaiton. And since RPC is available for basically > every MS OS out there, and even non-MS platforms, it's easy to see how > they came to the decision to use it. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 22, 2003

Re: App works almost perfectly, but one MDI screen won't draw

by Mike Hearn

Could you explain this to me please? I tried Kaleidograph and started looking at why the "Demo version only" dialog that pops up at the beginning wasn't blanking the background properly, which I decided was because the app didn't call BeginPaint but I am very much a novice. So, if you could explain how you tracked down these bugs I'd very much appreciate it! thanks -mike On Wed, 2003-01-22 at 02:15, Duane Clark wrote: > Dan Kegel wrote: > > Installing my company's app is still a bear -- the only > > way I've found to avoid the dreaded "object reference not set" is > > to run with --debugmsg +ole and redirect to a file > > (not to the screen, and not to /dev/null). > > > > Once installed, the app runs quite well... except for one screen, > > which remains nearly blank. The MDI frames draw fine, but the > > contents (which include a hex memory dump area and a tree control) > > remain blank. > > I was going to spend this weekend fixing another MDI app to fix a draw > problem that several exhibit (for example, Kaleidegraph). Oddly it is > just the opposite; the contents draw ok but not the frames. I already > have a good idea of where the problem on them is. > > Would a demo version of your app be available for download somewhere? I > would be interested in testing it. > > -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 22, 2003

AbiWord display problem

by Dan Kegel

At a demo in front of our LUG, I ran Abiword 0.99 win32 on yesterday's cvs wine. It really impressed the crowd until I tried to load a file, at which point the horribly smeared and splayed text quickly brought the audience back to earth. Has anyone looked at what's up with that? I think it's been that way for a while. Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 22, 2003

Re: PATCH: Adds my name to the AUTHORS list

by Shachar Shemesh

Waldeck Schutzer wrote: > Now that my patches were incorporated to the tree, it would make me > feel happier if my name was listed too :-) > > Best, > Waldeck I think it's time Alexander regenerates the entire Authors list. People want the credit, Alexander. There is a script in "tools" that does something, but I think it only alphabetizes the list, it does not actually add names. Shachar

Jan. 22, 2003

Re: Stdole32.tlb (was: Installshield 6 crash: ole trouble)

by Marcus Meissner

> > And what's wrong with importing lots of structures, > > if unused typedefs aren't stored in the type library? > > The main problem is that the typelibs import all kinds of stuff. Stdole2.tlb > imports declarations from guiddef.h, oaidl.idl, unknwn.idl, ocidl.idl, > olectl.h, plus some functions and interfaces that are not in any other file. > Also, the IFont interface has been slightly modified in the type lib which > might break an app if it were to use our ocidl.idl version of it. Huh? How that? > Is there any point in cluttering our typelib? In my opinion our typelib should at least contain all of the stdole2/32.tlb stuff. If there are some more entries, it does not really matter I guess. > > > Where should I put such a file? > > > > I'd go for dlls/oleaut32. Standard ole32 has no need for typelibs, they're > > a feature of oleaut32. > > I'll wait a bit longer for opinions from a few more people, although your > logic about type libs being an oleaut32 feature seems right to me. Go ahead with what you consider best. My acceptance criteria would be basically 'InstallShield v6 still works' ;) Ciao, Marcus

Jan. 22, 2003

Re: dos4gw stub exec failed

by EnricoHorn＠t-online.de

On Tuesday 21 January 2003 22:32, Sylvain Petreolle wrote: > please give me the name of the program, all dos4gw programs I have > tried before just hang. > the message is from the game Callahans Crosstime Saloon, an old Legend adventure. It happens when I try to run the setsound.exe that comes with the game but the main game exe (ccs.exe) shows the same error so i guess the behaviour is similar. I have also installed other legend adventures that all exhibit the same behaviour. which have you tried that just hang? Ciao Enrico farmboy1(a)subdimension.com

Jan. 22, 2003

RE: Stdole32.tlb (was: Installshield 6 crash: ole trouble)

by Robert Shearman

> -----Original Message----- > From: Ove Kaaven [mailto:ovehk(a)ping.uio.no] > Sent: 22 January 2003 01:20 > To: Robert Shearman > Cc: wine-devel(a)winehq.com > Subject: Re: Stdole32.tlb (was: Installshield 6 crash: ole trouble) > > On Tue, 21 Jan 2003, Robert Shearman wrote: > > > Attached (now) is the IDL file (really an ODL file) used to create > > stdole32.tlb > > Why do it this way? There are surely going to be more types than that in > the stdole32 file, or? No, that's it. There are a few more in stdole2.tlb, but only a couple that are in idl files > And what's wrong with importing lots of structures, > if unused typedefs aren't stored in the type library? The main problem is that the typelibs import all kinds of stuff. Stdole2.tlb imports declarations from guiddef.h, oaidl.idl, unknwn.idl, ocidl.idl, olectl.h, plus some functions and interfaces that are not in any other file. Also, the IFont interface has been slightly modified in the type lib which might break an app if it were to use our ocidl.idl version of it. Is there any point in cluttering our typelib? > If the problem is > that mktyplib is inflexible, use midl instead. Then you can just import > oaidl.idl and be done with it, almost no future maintenance needed. If you change anything in a type library you are supposed change the version number (which is what Microsoft has done transitioning from stdole32.tlb->stdole2.tlb). In short, I'd rather not take the risk when this way seems so straightforward. If or when Microsoft release version 3 of the standard type library, it will have to be examined for new material (like version 2 has) that is not in any .idl file anyway. At least this would put up a definite error that it needs attention rather than waiting for a corner case for an error to occur. It's not that mktyplib is inflexible, it's that it does the job with the minimum amount of fuss. In fact midl is more inflexible in that you cannot turn off its inclusion of oaidl.idl > > Where should I put such a file? > > I'd go for dlls/oleaut32. Standard ole32 has no need for typelibs, they're > a feature of oleaut32. I'll wait a bit longer for opinions from a few more people, although your logic about type libs being an oleaut32 feature seems right to me. Rob

Jan. 22, 2003

Re: App works almost perfectly, but one MDI screen won't draw

by Duane Clark

Dan Kegel wrote: > Installing my company's app is still a bear -- the only > way I've found to avoid the dreaded "object reference not set" is > to run with --debugmsg +ole and redirect to a file > (not to the screen, and not to /dev/null). > > Once installed, the app runs quite well... except for one screen, > which remains nearly blank. The MDI frames draw fine, but the > contents (which include a hex memory dump area and a tree control) > remain blank. I was going to spend this weekend fixing another MDI app to fix a draw problem that several exhibit (for example, Kaleidegraph). Oddly it is just the opposite; the contents draw ok but not the frames. I already have a good idea of where the problem on them is. Would a demo version of your app be available for download somewhere? I would be interested in testing it.

Jan. 22, 2003

Re: Stdole32.tlb (was: Installshield 6 crash: ole trouble)

by Ove Kaaven

On Tue, 21 Jan 2003, Robert Shearman wrote: > Attached (now) is the IDL file (really an ODL file) used to create > stdole32.tlb Why do it this way? There are surely going to be more types than that in the stdole32 file, or? And what's wrong with importing lots of structures, if unused typedefs aren't stored in the type library? If the problem is that mktyplib is inflexible, use midl instead. Then you can just import oaidl.idl and be done with it, almost no future maintenance needed. > Where should I put such a file? I'd go for dlls/oleaut32. Standard ole32 has no need for typelibs, they're a feature of oleaut32.

Jan. 22, 2003