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

Re: InstallShield and ole question...

by Juergen Schmied

> > > My question, is anyone currently working on implementing CLSCTX_LOCAL_SERVER > > > in compobj.c:CoGetClassObject, or have plans to work on this in the near > > > future? If not, I may go back to trying to figure out what is happening > > > with the 'native' configuration. > > > > This will require a lot of work, basically you will need to implement > > all of the OLE out of process, marshalling, rpc stuff. > > > > This is not a trivial 100 line patch, its more like 20000+ lines. > > The CLSCTX_LOCAL_SERVER is used for function calls in another process > on the same machine. So you wouldn't need any rpc, and I wouldn't think > you would need marshalling .. In the case of InstallShield v6 it isn't > really requesting anything from another process. It's requesting an > object from an EXE, instead of a DLL. Ok, not rpc but lpc so we might get along with 10000+ lines. ;-) Mashalling is nessesary in any case since the function calls have to go from one process to an other. The com object in the exe is likely an automation server. Bye Juergen

April 25, 2001

Re: Trouble with VirtualQuery()

by gerard patel

At 02:07 PM 25/04/2001 +0200, you wrote: >Do you mean >http://support.microsoft.com/support/kb/articles/Q171/7/93.ASP >? Yes Gerard

April 25, 2001

Re: Quickbooks 5 and printing

by Dmitry Timoshkov

"Dan Engel" <dengel(a)sourceharvest.com> wrote: > Using "--debugmsg warn+all,+relay,+text,+string" I found that it's trying > to load "wineps.drv.dll" which translates into "libwineps.drv.so". This > doesn't work, and it appears that the QB code is what's adding the .DRV to > the WINEPS print driver name. > > I hacked around that by checking for WINEPS.DRV at the beginning of > BUILTIN_LoadModule and replacing it with WINEPS. First of all, you didn't tell what type of application is QB: 16 or 32 bit. 16-bit applications nearly always look for printer driver themself. They look at win.ini in the following sections: [devices], [PrinterPorts] or just [windows].device= Starting from Win3.1, where common dialogs were introduced, applications started just call common dialog, which allowed easy printer selection. Vast majority of 32-bit applications also use common dialogs, but some "advanced" (read - stupid) appications try do read registry or even use old Win3.x method described above. You should look at all places (win.ini and registry), find all references to WINEPS and remove any extension from it (be it .DRV or .DLL). If that will not help, post somewhere a +relay,+module trace.

April 25, 2001

Re: New breakages

by gerard patel

At 09:30 AM 25/04/2001 +0200, I wrote: >There may be other problems, I have not the time to search for them all just now. Also several apps are not erasing parts of the screen : among others the word viewer 97 (freeware downloadable). A few other strange crashes. Gerard

April 25, 2001

Re: PATCH: drop relay stuff

by Andreas Mohr

Hi again, if we change the behaviour of that stuff (well, it's already changed), then this should also fix Win16 printer drivers, right ? So it seems wineps has just the very same problems as Win16 printer drivers... -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

April 25, 2001

Re: PATCH: drop relay stuff

by Andreas Mohr

On Wed, Apr 25, 2001 at 02:11:09PM +0200, Marcus Meissner wrote: > On Wed, Apr 25, 2001 at 01:25:11PM +0200, Andreas Mohr wrote: > > Oh yeah, and in case you didn't notice: it's me again complaining about > > yet another silencing ;-) > > > > This patch is not even "too early", it's simply "wrong" IMHO, as it is > > an ongoing problem (I did mention this before, didn't I ? :). > > > Oh, then implement a way to let it enabled _AND_ make it possible > to relay debug wineps, where pCreateDC must be called with GDI (DC) lock > held all the time (and which does hundreds of API calls into other dlls). Hmm, what's the problem ? AFAICS the problem is that these calls cause trouble because of the DebugBreak(). So just add another function without DebugBreak(). OTOH the real issue seems to be that we can't decide which function to use then, the enforced or unenforced one. So just drop (i.e.: comment out !) the DebugBreak() completely instead. Still much better than not showing anything at all. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

April 25, 2001

Re: PATCH: drop relay stuff

by Marcus Meissner

On Wed, Apr 25, 2001 at 01:25:11PM +0200, Andreas Mohr wrote: > On Tue, Apr 24, 2001 at 09:33:16PM +0200, Marcus Meissner wrote: > > Hi, > > > > Changelog: > > Drop SYSLEVEL checks from relay debugging, since they break debugging > > builtin GDI dlls. > > Hmm, do we really want to do this ? > (I know it's already been applied) > > Shouldn't we create a different SYSLEVEL_CheckNotLevel_unenforced() function > instead which simply doesn't call DebugBreak() ? > > That way we don't lose the important information about possible syslevel > violations. > > Syslevel violations are an *ongoing* problem. They are not simply "solved". > OTOH I could take Alexandre's cvs commit as his firm promise to go through > every future patch line by line to check for syslevel mishaps/omissions ;-) > > Oh yeah, and in case you didn't notice: it's me again complaining about > yet another silencing ;-) > > This patch is not even "too early", it's simply "wrong" IMHO, as it is > an ongoing problem (I did mention this before, didn't I ? :). Oh, then implement a way to let it enabled _AND_ make it possible to relay debug wineps, where pCreateDC must be called with GDI (DC) lock held all the time (and which does hundreds of API calls into other dlls). Ciao, Marcus

April 25, 2001

Re: Trouble with VirtualQuery()

by Uwe Bonnes

>>>>> "Gerald" == <<gerard.patel(a)asi.fr>@s5.asi.fr> writes: Gerard > ... Gerard > Possibly I'll send a new patch if I find where is the flag Gerard > in the exe to handle the 3 gig memory space but as I am not Gerard > actively searching for it, you are welcome to do it yourself Gerard > :-) Do you mean http://support.microsoft.com/support/kb/articles/Q171/7/93.ASP ? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 25, 2001

Re: PATCH: drop relay stuff

by Andreas Mohr

On Tue, Apr 24, 2001 at 09:33:16PM +0200, Marcus Meissner wrote: > Hi, > > Changelog: > Drop SYSLEVEL checks from relay debugging, since they break debugging > builtin GDI dlls. Hmm, do we really want to do this ? (I know it's already been applied) Shouldn't we create a different SYSLEVEL_CheckNotLevel_unenforced() function instead which simply doesn't call DebugBreak() ? That way we don't lose the important information about possible syslevel violations. Syslevel violations are an *ongoing* problem. They are not simply "solved". OTOH I could take Alexandre's cvs commit as his firm promise to go through every future patch line by line to check for syslevel mishaps/omissions ;-) Oh yeah, and in case you didn't notice: it's me again complaining about yet another silencing ;-) This patch is not even "too early", it's simply "wrong" IMHO, as it is an ongoing problem (I did mention this before, didn't I ? :). Sorry for me being of such an opposing nature ;-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

April 25, 2001

New breakages

by gerard patel

Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x40a39b1b). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x40a39b1b (X11DRV_WND_SetGravity+0x1f [wnd.c:414]): cmpl $0,0x0(%edx) 414 if (data->window && data->bit_gravity != value ) Wine-dbg>bt bt Backtrace: =>0 0x40a39b1b (X11DRV_WND_SetGravity+0x1f(wnd=0x40367b80, value=0x1) [wnd.c:414]) (ebp=40c56b8c) 1 0x40a149dc (X11DRV_SetWindowPos+0x678(winpos=0x40c56c54) [winpos.c:1076]) (ebp=40c56c3c) 2 0x406acb69 (SetWindowPos+0x51(hwnd=0x1a20, hwndInsertAfter=0x0, x=0xdd, y=0xcf, cx=0x172, cy=0xef, flags=0x80000015) [winpos.c:2176]) (ebp=40c56c70) 3 0x40a3481e (EVENT_ConfigureNotify+0x1a6(hWnd=0x1a20, event=0x40c56d90) [event.c:983]) (ebp=40c56ccc) 4 0x40a33b0f (EVENT_ProcessEvent+0x49b(event=0x40c56d90) [event.c:438]) (ebp=40c56d70) 5 0x40a335ec (EVENT_ProcessAllEvents+0x68(arg=0x0) [event.c:209]) (ebp=40c56df0) 6 0x400c9b7f (SERVICE_Loop+0xbf(dummy=0x0) [services.c:76]) (ebp=40c56f1c) Hacked away by --- wnd.c.orig Wed Apr 25 01:43:41 2001 +++ wnd.c Wed Apr 25 09:28:52 2001 @@ -411,7 +411,7 @@ { X11DRV_WND_DATA *data = wnd->pDriverData; - if (data->window && data->bit_gravity != value ) + if (data && data->window && data->bit_gravity != value ) { XSetWindowAttributes win_attr; win_attr.bit_gravity = value; Another problem : now in the file open window, the tooltips for the toolbar buttons are appearing as managed windows (in managed mode of course) There may be other problems, I have not the time to search for them all just now. Gerard

April 25, 2001