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

Re: AbiWord 0.9 problems even with latest Wine from CVS

by Uwe Bonnes

>>>>> "Uwe" == Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: Uwe> what effort is it to crosscompile AbiWord with either Uwe> mingw32/cygwin or even perhaps with winelib? Active debugging is Uwe> probably best done with a compilable source tree at hand. Sorry, I wasn't exact: I meant compile on Linux to a windows executable or a winelib executable. -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 7, 2001

Re: AbiWord 0.9 problems even with latest Wine from CVS

by Uwe Bonnes

>>>>> "Dan" == Dan Kegel <dank(a)kegel.com> writes: Dan> Dan Kegel wrote: >> The AbiWord win32 0.9 problems I described recently on wine-users Dan, what effort is it to crosscompile AbiWord with either mingw32/cygwin or even perhaps with winelib? Active debugging is probably best done with a compilable source tree at hand. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 7, 2001

Re: AbiWord 0.9 problems even with latest Wine from CVS

by Dan Kegel

Dan Kegel wrote: > > The AbiWord win32 0.9 problems I described recently on > wine-users with Codeweavers Preview 4 also happen > with the latest Wine built from CVS this afternoon. > These problems don't happen when run on Windows, nor > when running the native Linux version; they therefore appear > to be Wine bugs. > > Details at http://www.kegel.com/wine/abiword0.9/readme.html On the "Y step wrong when displaying more than one of text" problem, I added trace+font to the log. Result is at http://www.kegel.com/wine/abiword0.9/log5.tar.gz File it was loading is at http://www.kegel.com/wine/abiword0.9/foo3.txt Notepad has no problems, it's just AbiWord. - Dan -- "I have seen the future, and it licks itself clean." -- Bucky Katt

Aug. 7, 2001

Re: CoGetClassObject

by Ove Kaaven

On Tue, 7 Aug 2001, Rein Klazes wrote: > On Tue, 7 Aug 2001 01:12:34 +0200 (CEST), you wrote: > > > > > > > It couldn't get it from the ikernel.exe because I think > > > it's encoded somehow (unicode, MultiByte??). > > > > It doesn't look encoded, it's just different (it's most likely what is > > boasted as the "Typelib 2 Format"). Win2000's stdole32.tlb also uses this > > new format (it has a "SLTG" signature instead of the old "MSFT"). > > > SLTG is the old format, MSFT came later. Wine can (natively) only read > MSFT. Allright, but the most important question remains: who will volunteer to reverse engineer these SLTG typelibs and make Wine able to read them, so I can concentrate on the actual COM marshaling stuff (which is pretty hard enough as it is), so we can finally get those @#&% InstallShields up?

Aug. 7, 2001

Re: CoGetClassObject

by Rein Klazes

On Tue, 7 Aug 2001 01:12:34 +0200 (CEST), you wrote: > > > It couldn't get it from the ikernel.exe because I think > > it's encoded somehow (unicode, MultiByte??). > > It doesn't look encoded, it's just different (it's most likely what is > boasted as the "Typelib 2 Format"). Win2000's stdole32.tlb also uses this > new format (it has a "SLTG" signature instead of the old "MSFT"). SLTG is the old format, MSFT came later. Wine can (natively) only read MSFT. I have no knowledge of a still newer format. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Aug. 7, 2001

AbiWord 0.9 problems even with latest Wine from CVS

by Dan Kegel

The AbiWord win32 0.9 problems I described recently on wine-users with Codeweavers Preview 4 also happen with the latest Wine built from CVS this afternoon. These problems don't happen when run on Windows, nor when running the native Linux version; they therefore appear to be Wine bugs. Details at http://www.kegel.com/wine/abiword0.9/readme.html I stand ready and willing to apply and test patches, but might not have time to write any fixes myself. Thanks, Dan -- "I have seen the future, and it licks itself clean." -- Bucky Katt

Aug. 6, 2001

Re: CoGetClassObject

by Ove Kaaven

On Thu, 19 Jul 2001, Daniel Walker wrote: > I had to use a separate "ikernel.tlb" to get Wine to read the type > information. Where did you get that .tlb file from, and could you send it to me? > It couldn't get it from the ikernel.exe because I think > it's encoded somehow (unicode, MultiByte??). It doesn't look encoded, it's just different (it's most likely what is boasted as the "Typelib 2 Format"). Win2000's stdole32.tlb also uses this new format (it has a "SLTG" signature instead of the old "MSFT"). > So then in CoGetClassObject you would create and return a dummy object > that would act like the actual interface the program is looking for. > Then the dummy object would accept parameters, do the marshaling, and > make the IPC request to the Local Server? Something like that, except it's called a "proxy", not a "dummy object".

Aug. 6, 2001

Re: ownerdrawn button fix

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > A full fix would be to make sure we never call the paint function > directly. However the only time this seems to actually cause a crash is > with owner drawn. This patch corrected the problem with owner drawn so > that we do not have to retest everything with buttons. This seems to defeat the purpose of having the ODA_* constants. Would it also fix your problem to only do the PAINT_BUTTON when the window is visible? -- Alexandre Julliard julliard(a)winehq.com

Aug. 6, 2001

Re: CS_PARENTDC with WS_CLIPSIBLINGS

by Alexandre Julliard

Ladislav Sladecek <lsla(a)post.cz> writes: > Maybe the printer driver never gets initialised? (Just a stupid speculation). Not stupid at all, actually the 16-bit driver support is temporarily broken (not that it really worked well before anyway). It shouldn't be too hard to fix, but I haven't had time yet. Volunteers are welcome... -- Alexandre Julliard julliard(a)winehq.com

Aug. 6, 2001

Re: CS_PARENTDC with WS_CLIPSIBLINGS

by Ladislav Sladecek

On Pá, 03 srp 2001, Andreas Mohr wrote: > It's a totally dainbread application, that's why. I agree (no news for me:-) ) but this does not explain why the application worked fine on 2001/07/26. I looked into the change log and found * dlls/wineps/init.c, dlls/wineps/wineps.spec, dlls/x11drv/x11drv.spec, graphics/Makefile.in, graphics/driver.c, graphics/win16drv/init.c, graphics/x11drv/bitmap.c, graphics/x11drv/init.c, graphics/x11drv/oembitmap.c, include/gdi.h, include/x11drv.h, objects/dc.c, dlls/gdi/Makefile.in, dlls/gdi/driver.c, dlls/gdi/gdi_main.c, dlls/ttydrv/bitmap.c, dlls/ttydrv/dc.c, dlls/ttydrv/ttydrv.spec: Build the DC function table by using GetProcAddress on the graphics driver module. Moved driver support to dlls/gdi. I think that the problems were started by this patch. (I do not say that the patch is wrong, maybe the patch only found some stupid bug in the app). Thus I did cvs -diff -D 20010727 -D 20010728 I do not pretend that I do understand the code but some coincidences exist. For example the crash is near the code which get changed, drivers and DCs are involved etc. Please look at this: Index: dlls/gdi/gdi_main.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/gdi_main.c,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- dlls/gdi/gdi_main.c 2001/03/05 19:30:18 1.10 +++ dlls/gdi/gdi_main.c 2001/07/27 19:37:31 1.11 @@ -17,14 +17,7 @@ BOOL WINAPI MAIN_GdiInit(HINSTANCE hinstDLL, DWORD reason, LPVOID lpvReserved) { if (reason != DLL_PROCESS_ATTACH) return TRUE; - - /* GDI initialisation */ - if(!GDI_Init()) return FALSE; - - /* Create the Win16 printer driver */ - if (!WIN16DRV_Init()) return FALSE; - - return TRUE; + return GDI_Init(); } And this: Index: graphics/win16drv/init.c =================================================================== RCS file: /home/wine/wine/graphics/win16drv/init.c,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- graphics/win16drv/init.c 2001/07/22 23:13:09 1.34 +++ graphics/win16drv/init.c 2001/07/27 19:37:32 1.35 @@ -144,17 +144,16 @@ }; - - - +/* FIXME: this no longer works */ +#if 0 /********************************************************************** * WIN16DRV_Init */ BOOL WIN16DRV_Init(void) { return DRIVER_RegisterDriver( NULL /* generic driver */, &WIN16DRV_Funcs ); - } +#endif Maybe the printer driver never gets initialised? (Just a stupid speculation). > What happens if you run this program on a windoze box without any printer > installed ? (and thus the device= line should not exist, there, too...) > Does it fail the same way or does it seem to recognize somehow that there > is no printer installed ? > I tried just now and the application worked fine, no problems. It did not tell anything about missing printer; which is OK as I did not start to print. I have installed the application several houndred times previously, sometimes to boxes with no printers and never noticed similar problems on windoze. Thank you for your advice. Ladislav Sladecek

Aug. 5, 2001