December 2002 - Wine-Devel - list.winehq.org

Re: Excluding whole dlls from a relay log, was Re: [RESENT (20021013)]...

by Dmitry Timoshkov

"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > Please let me know in what way the user is supposed to exclude whole dlls > from a relay trace so I can fix the behaviour and docs. [Debug] "RelayExclude" = "user32.*;x11drv.*" should work. -- Dmitry.

Dec. 17, 2002

Re: How long does it take *you* to build wine?

by Alberto Massari

At 22.51 15/12/2002 -0800, Dan Kegel wrote: >[..] > >So how long does it take *you* to do a clean build >(just the 'make' part after 'make depend', say) of >Wine-20021125? On a notebook with a Pentium III-M 600MHz, 256Mb of RAM, (Mandrake 9 with gcc 3.2): 41m:32s Alberto ------------------------------- Alberto Massari eXcelon Corp. http://www.StylusStudio.com

Dec. 17, 2002

Re: PATCH: implemented Fiber APIs

by Alberto Massari

At 02.02 17/12/2002 -0500, Dimitrie O. Paun wrote: >On December 16, 2002 02:37 pm, Alberto Massari wrote: > > +void WINAPI SwitchToFiber(LPVOID lpFiber) > > +{ > > +#ifdef HAVE_UCONTEXT_H > > + PHFIBER pFiber,pCurrentFiber; > > + pFiber=(PHFIBER)lpFiber; > > + pCurrentFiber=(PHFIBER)TlsGetValue(fiber_tls_index); > > + TRACE("Switching from %p to %p\n",pFiber,pCurrentFiber); > > + TlsSetValue(fiber_tls_index,pFiber); > > + swapcontext(&pCurrentFiber->context,&pFiber->context); > > +#else > > + FIXME("stub\n"); > > +#endif > > +} > >Can you (pretty) please do without the ifdefs? They can probably >be located in only one spot, if you need to test for HAVE_UCONTEXT_H. I added them when I realized that ucontext.h could not be present on some systems, as "configure" tests for its presence and adds that preprocessor directive. The alternative layout would be #ifdef HAVE_UCONTEXT_H #include <ucontext.h> LPVOID WINAPI ConvertThreadToFiber(... { .... } LPVOID WINAPI CreateFiber(... { .... } .... #else LPVOID WINAPI ConvertThreadToFiber(... { FIXME("stub\n"); } LPVOID WINAPI CreateFiber(... { FIXME("stub\n"); } ... #endif It's just a matter of deciding what is best from a maintenance point of view: grouping the working code or grouping the functions. There are valid arguments in favour of both styles, and I have no strong feelings, so I will submit the new patch shortly. In any case... what is the policy in this case? a) there is an HOWTO on the subject, that I didn't read :-( b) there is no previous agreement on this, and Alexandre decides c) there is no previous agreement on this, and a poll is submitted to the mailing list d) other options Alberto ------------------------------- Alberto Massari eXcelon Corp. http://www.StylusStudio.com

Dec. 17, 2002

Re: How long does it take *you* to build wine?

by Alberto Massari

Nobody can beat my old Pentium 133 with 64 Mb.... it usually took more than 4 hours to just do a "make" after a refresh.... If you are really curious, I can time how long it takes to do a full build.... Alberto At 20.12 16/12/2002 -0700, Tony Lambregts wrote: >Bill Medland wrote: > >>On December 15, 2002 10:51 pm, Dan Kegel wrote: >>snip >> >> >>>So how long does it take *you* to do a clean build >>>(just the 'make' part after 'make depend', say) of >>>Wine-20021125? >>>- Dan >>> >> >>(I was wondering if mine was the slowest!) >>real - 47m0.357 >>user-43m1.631 >>sys-2m51.668 >> >>Celeron 450 with 128MB running RedHat 7.3 >> >>snip >> >No yours is fast compared to my <blush> 300mhz pentium with 96mb of ram >(around 3 hours) </blush> > >-- > >Tony Lambregts > > >

Dec. 17, 2002

Excluding whole dlls from a relay log, was Re: [RESENT (20021013)]...

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> Changelog: relay32/relay386.c: check_relay_include Treat whole dlls >> as advertised Alexandre> IMO the current behavior is correct. If the documentation Alexandre> says otherwise it needs to be fixed. I don't see any chance to exclude a whole dll from relay debugging in the present scheme. In most cases one doesn't want to see the output from x11drv and gdi32. Do we really want to deny such a user request? Or has the ability to do it on the command line (like --debugmsg -relay=x11drv") only been broken by chance and needs fixing? Please let me know in what way the user is supposed to exclude whole dlls from a relay trace so I can fix the behaviour and docs. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 17, 2002

Compiling problem

by winedevel＠007mundo.com

Hello, i have this compiling problem (sorry if this isn't the correct list, if yes, please let me know) make[2]: *** [ppy.tab.c] core dumped .. make[1]: *** [wrc/__depend__] Error 2 .. make: *** [tools/__depend__] Error 2 and what? Thanks ----------------------------------------------------- Obtenga su mail gratis con 007 Mundo www.007mundo.com -----------------------------------------------------

Dec. 17, 2002

Re: windows visual view ?

by Dimitrie O. Paun

On December 16, 2002 01:08 pm, Francois Gouget wrote: > Would this be more or less what you are looking for? That's OK, but I was looking for some of them architecture diagrams that explain the interaction between processes and wineserver. Something to shed some light on the more obscure corners of wine. This ones are OK, but we kinda already know that yeah, Wine is build on top on Linux... :) -- Dimi.

Dec. 17, 2002

Re: PATCH: implemented Fiber APIs

by Dimitrie O. Paun

On December 16, 2002 02:37 pm, Alberto Massari wrote: > +void WINAPI SwitchToFiber(LPVOID lpFiber) > +{ > +#ifdef HAVE_UCONTEXT_H > + PHFIBER pFiber,pCurrentFiber; > + pFiber=(PHFIBER)lpFiber; > + pCurrentFiber=(PHFIBER)TlsGetValue(fiber_tls_index); > + TRACE("Switching from %p to %p\n",pFiber,pCurrentFiber); > + TlsSetValue(fiber_tls_index,pFiber); > + swapcontext(&pCurrentFiber->context,&pFiber->context); > +#else > + FIXME("stub\n"); > +#endif > +} Can you (pretty) please do without the ifdefs? They can probably be located in only one spot, if you need to test for HAVE_UCONTEXT_H. -- Dimi.

Dec. 17, 2002

Re: stub handling

by Dimitrie O. Paun

On December 16, 2002 08:42 pm, Alexandre Julliard wrote: > We need to implement them, importing stubs no longer works (but of > course you can do a stub implementation instead ;-) Of, of, of, of, offff... :) ChangeLog Add stubs for {Start,End}{Doc,Page}Printer. Index: dlls/winspool/info.c =================================================================== RCS file: /var/cvs/wine/dlls/winspool/info.c,v retrieving revision 1.61 diff -u -r1.61 info.c --- dlls/winspool/info.c 12 Nov 2002 02:22:24 -0000 1.61 +++ dlls/winspool/info.c 17 Dec 2002 06:43:09 -0000 @@ -1274,6 +1274,51 @@ } /***************************************************************************** + * EndDocPrinter [WINSPOOL.@] + */ +BOOL WINAPI EndDocPrinter(HANDLE hPrinter) +{ + FIXME("(hPrinter=%p): stub\n", hPrinter); + return FALSE; +} + +/***************************************************************************** + * EndPagePrinter [WINSPOOL.@] + */ +BOOL WINAPI EndPagePrinter(HANDLE hPrinter) +{ + FIXME("(hPrinter=%p): stub\n", hPrinter); + return FALSE; +} + +/***************************************************************************** + * StartDocPrinterA [WINSPOOL.@] + */ +DWORD WINAPI StartDocPrinterA(HANDLE hPrinter, DWORD Level, LPBYTE pDocInfo) +{ + FIXME("(hPrinter=%p, Level=0x%lx, pDocInfo=%p): stub\n", hPrinter, Level, pDocInfo); + return FALSE; +} + +/***************************************************************************** + * StartDocPrinterW [WINSPOOL.@] + */ +DWORD WINAPI StartDocPrinterW(HANDLE hPrinter, DWORD Level, LPBYTE pDocInfo) +{ + FIXME("(hPrinter=%p, Level=0x%lx, pDocInfo=%p): stub\n", hPrinter, Level, pDocInfo); + return FALSE; +} + +/***************************************************************************** + * StartPagePrinter [WINSPOOL.@] + */ +BOOL WINAPI StartPagePrinter(HANDLE hPrinter) +{ + FIXME("(hPrinter=%p): stub\n", hPrinter); + return FALSE; +} + +/***************************************************************************** * GetFormA [WINSPOOL.@] */ BOOL WINAPI GetFormA(HANDLE hPrinter, LPSTR pFormName, DWORD Level, Index: dlls/winspool/winspool.drv.spec =================================================================== RCS file: /var/cvs/wine/dlls/winspool/winspool.drv.spec,v retrieving revision 1.16 diff -u -r1.16 winspool.drv.spec --- dlls/winspool/winspool.drv.spec 4 Nov 2002 23:53:42 -0000 1.16 +++ dlls/winspool/winspool.drv.spec 17 Dec 2002 06:01:17 -0000 @@ -56,8 +56,8 @@ @ stdcall DocumentPropertiesA(long long ptr ptr ptr long) DocumentPropertiesA @ stdcall DocumentPropertiesW(long long ptr ptr ptr long) DocumentPropertiesW @ stub EXTDEVICEMODE -@ stub EndDocPrinter -@ stub EndPagePrinter +@ stdcall EndDocPrinter(long) EndDocPrinter +@ stdcall EndPagePrinter(long) EndPagePrinter @ stub EnumFormsA @ stub EnumFormsW @ stdcall EnumJobsA(long long long long ptr long ptr ptr) EnumJobsA @@ -127,8 +127,8 @@ @ stub SpoolerInit @ stub StartDocDlgA @ stub StartDocDlgW -@ stub StartDocPrinterA -@ stub StartDocPrinterW -@ stub StartPagePrinter +@ stdcall StartDocPrinterA(long long ptr) StartDocPrinterA +@ stdcall StartDocPrinterW(long long ptr) StartDocPrinterW +@ stdcall StartPagePrinter(long) StartPagePrinter @ stub WaitForPrinterChange @ stdcall WritePrinter(long ptr long ptr) WritePrinter -- Dimi.

Dec. 17, 2002

Re: wrc options

by Dimitrie O. Paun

On December 9, 2002 04:57 pm, Francois Gouget wrote: > I agree with that one. As it is wrc just convert the filenames to > lowercase before trying to include them which is just plain wrong. In > particular it causes compilation errors if the file really has a > mized-case which is not that uncommon. ChangeLog Remove the -L wrc option, as no automatic fudging of filenames can ever be correct. Index: tools/wrc/parser.y =================================================================== RCS file: /var/cvs/wine/tools/wrc/parser.y,v retrieving revision 1.33 diff -u -r1.33 parser.y --- tools/wrc/parser.y 15 Aug 2002 21:57:36 -0000 1.33 +++ tools/wrc/parser.y 17 Dec 2002 05:33:45 -0000 @@ -2694,11 +2694,6 @@ *cptr = '/'; } - /* Convert to lower case. Seems to be reasonable to do */ - for(cptr = str->str.cstr; !leave_case && *cptr; cptr++) - { - *cptr = tolower(*cptr); - } return str; } Index: tools/wrc/wrc.c =================================================================== RCS file: /var/cvs/wine/tools/wrc/wrc.c,v retrieving revision 1.21 diff -u -r1.21 wrc.c --- tools/wrc/wrc.c 12 Dec 2002 22:23:55 -0000 1.21 +++ tools/wrc/wrc.c 17 Dec 2002 05:32:44 -0000 @@ -104,7 +104,6 @@ " -I path Set include search dir to path (multiple -I allowed)\n" " -J Do not search the standard include path\n" " -l lan Set default language to lan (default is neutral {0, 0})\n" - " -L Leave case of embedded filenames as is\n" " -m Do not remap numerical resource IDs\n" " -n Do not generate .s file\n" " -N Do not preprocess input\n" @@ -252,12 +251,6 @@ int auto_register = 0; /* - * Set when the case of embedded filenames should not be converted - * to lower case (-L option) - */ -int leave_case = 0; - -/* * The output byte-order of resources (set with -B) */ int byteorder = WRC_BO_NATIVE; @@ -433,9 +426,6 @@ error("Language %04x is not supported",lan); currentlanguage = new_language(PRIMARYLANGID(lan), SUBLANGID(lan)); } - break; - case 'L': - leave_case = 1; break; case 'm': remap = 0; Index: tools/wrc/wrc.h =================================================================== RCS file: /var/cvs/wine/tools/wrc/wrc.h,v retrieving revision 1.24 diff -u -r1.24 wrc.h --- tools/wrc/wrc.h 31 May 2002 23:41:01 -0000 1.24 +++ tools/wrc/wrc.h 17 Dec 2002 05:32:50 -0000 @@ -64,7 +64,6 @@ extern DWORD codepage; extern int pedantic; extern int auto_register; -extern int leave_case; extern int byteorder; extern int preprocess_only; extern int no_preprocess; -- Dimi.

Dec. 17, 2002

Re: Serious problem with / and mount points

by Sylvain Petreolle

--- Tony Lambregts <tony_lambregts(a)telusplanet.net> a écrit : > Jeff Smith wrote: > > > What I have so far: > > in files/dos_fs.c:1343, drive is receiving the value -1. > > at line 1358, this is blindly added to 'A'. As you may > > know, in ASCII, 'A' - 1 = '@'. The problem is that we don't check the status of DRIVE_FindDriveRoot, as you spotted it. The sources clearly states that -1 is error. > > > > The next step is to determine why DRIVE_FindDriveRoot is > > returning -1. > > Well the reason DRIVE_FindDriveRoot is returning -1 is that > DOSDrives[drive].ino does not equal st.st_ino anymore. Line 440 of > drive.c is as follows > > if ((DOSDrives[drive].dev == st.st_dev) && > (DOSDrives[drive].ino == st.st_ino)) > > > > > > > > > > BTW, the same occurred in the reverse situation: > > (konsole) mount /mnt/cdrom > > (konsole) wcmd > > (wcmd) D: > > (wcmd) dir > > (konsole) umount /mnt/cdrom > > (wcmd) dir > > Now I am at @> > > If I remount and dir again, I am back to D> > > > Same problem with floppys too. > > -- > > Tony Lambregts > > > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Dec. 17, 2002

Re: linking between wine books

by Tony Lambregts

Bill Medland wrote: >What to people think? Should we be linking between different books in the >wine-doc set? > >I had put a link from wine-user to a section in wine-devel. The pdf was happy >enough with it but the sgm-to-html choked on it. Easiest solution is to drop >the link. Otherwise can someone point me at an example where it works? > > > Linking between books at a local level only works <easily> if you are building as a set. If you are building just one book then AFAIK there is no way to tell it about an id in another book. (One way around it is to point to the tag point in the winehq documentation). If anyone knows different please speak up. -- Tony Lambregts

Dec. 17, 2002

Re: include msvcrt/ fix (take 2)

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > What about this one? Currently {ming,wine}wrap are badly broken. > > I hope this one is rather uncontroversial, but it does depend on > that bit from crtdll, and I think that is the problem. I'd prefer that we simply get rid of these includes. This avoids having to do hacks in crtdll that will need to be removed later anyway. -- Alexandre Julliard julliard(a)winehq.com

Dec. 17, 2002

Re: include msvcrt/ fix (take 2)

by Dimitrie O. Paun

On December 14, 2002 02:10 pm, Dimitrie O. Paun wrote: > ChangeLog > Do not explicitly include msvcrt files from msvcrt headers. > Include windef.h instead of winnt.h to get all appropriate types. Alexandre, What about this one? Currently {ming,wine}wrap are badly broken. I hope this one is rather uncontroversial, but it does depend on that bit from crtdll, and I think that is the problem. -- Dimi.

Dec. 17, 2002

Re: How long does it take *you* to build wine?

by Tony Lambregts

Bill Medland wrote: >On December 15, 2002 10:51 pm, Dan Kegel wrote: >snip > > >>So how long does it take *you* to do a clean build >>(just the 'make' part after 'make depend', say) of >>Wine-20021125? >>- Dan >> >> > >(I was wondering if mine was the slowest!) >real - 47m0.357 >user-43m1.631 >sys-2m51.668 > >Celeron 450 with 128MB running RedHat 7.3 > >snip > > No yours is fast compared to my <blush> 300mhz pentium with 96mb of ram (around 3 hours) </blush> -- Tony Lambregts

Dec. 17, 2002

Re: stub handling

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > printing.o: In function `printer_start_job': > printing.o(.text+0x1fa): undefined reference to `EndDocPrinter' > printing.o(.text+0x20a): undefined reference to `EndPagePrinter' > printing.o(.text+0x237): undefined reference to `StartDocPrinterA' > printing.o(.text+0x24a): undefined reference to `StartPagePrinter' > printing.o: In function `printer_finish_job': > printing.o(.text+0x2b6): undefined reference to `EndPagePrinter' > printing.o(.text+0x2bd): undefined reference to `EndDocPrinter' > collect2: ld returned 1 exit status > > How shall we proceed? We need to implement them, importing stubs no longer works (but of course you can do a stub implementation instead ;-) -- Alexandre Julliard julliard(a)winehq.com

Dec. 17, 2002

Re: regression - 'wine notepad.exe' now has fixme

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > >>>>> "Dan" == Dan Kegel <dkegel(a)ixiacom.com> writes: > > Dan> With today's cvs, I see fixme:win:SetWindowTextA cannot set text > Dan> "Notepad - (untitled)" of other process window (nil) when I run > Dan> notepad.exe. This also happens with wine20021125, but not with > Dan> wine20020904. > > SetWindowText can not yet set the text across process boundary. But more > functions do the right thing and use SetWindowText and not a workaround or > don't use it at all. So this is not a regression. Actually the window is (nil) so this is not an inter-process issue at all; the error message is a bit misleading in that case. And if it didn't happen before then it's clearly a regression. -- Alexandre Julliard julliard(a)winehq.com

Dec. 17, 2002

Re: How long does it take *you* to build wine?

by Bill Medland

On December 15, 2002 10:51 pm, Dan Kegel wrote: snip > So how long does it take *you* to do a clean build > (just the 'make' part after 'make depend', say) of > Wine-20021125? > - Dan (I was wondering if mine was the slowest!) real - 47m0.357 user-43m1.631 sys-2m51.668 Celeron 450 with 128MB running RedHat 7.3 snip -- Bill Medland

Dec. 17, 2002

Re: [RESENT (20021013)]RelayExclude/Include

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > relay32/relay386.c: check_relay_include > Treat whole dlls as advertised IMO the current behavior is correct. If the documentation says otherwise it needs to be fixed. -- Alexandre Julliard julliard(a)winehq.com

Dec. 16, 2002

Re: How long does it take *you* to build wine?

by Joerg Mayer

On Sun, Dec 15, 2002 at 10:51:59PM -0800, Dan Kegel wrote: > So how long does it take *you* to do a clean build > (just the 'make' part after 'make depend', say) of > Wine-20021125? current cvs on an athlon 550 with 192 M Ram and gcc 3.2: real 47m40.902s user 40m25.200s sys 3m1.410s Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Dec. 16, 2002

linking between wine books

by Bill Medland

What to people think? Should we be linking between different books in the wine-doc set? I had put a link from wine-user to a section in wine-devel. The pdf was happy enough with it but the sgm-to-html choked on it. Easiest solution is to drop the link. Otherwise can someone point me at an example where it works? -- Bill Medland

Dec. 16, 2002

Re: winmm test extension

by Francois Gouget

On Mon, 16 Dec 2002, Paul Millar wrote: [...] > In the future, there might be many interactive tests: or at least, ones > that require someone to sit in front of the computer. These could all be > turned off by default, but could be turned on through an option to > runtest, or via an environment variable (WINETEST_INTERACTIVE). > > Does this sound reasonable? Sounds reasonable to me. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Dec. 16, 2002

Re: fdopen behaviour correction

by Uwe Bonnes

>>>>> "Bill" == Bill Currie <bill(a)taniwha.org> writes: Bill> fdopen is not supposed to rewind the file descriptor being given a Bill> FILE *. Proof of this comes from quakeforge working in windows Bill> natively but not in wine without the attatched patch. Bill> ChangeLog * dlls/msvcrt/file.c don't rewind the file after Bill> creating the FILE* handle It is good to have a test case for such cases in wine/dlls/msvcrt/tests. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 16, 2002

Re: winmm test extension

by Paul Millar

On Mon, 16 Dec 2002, Francois Gouget wrote: > How to make it play a sound? > Simple. Just pass the 'play' parameter to the test. Playing a sound is a nice idea, but perhaps there's a more general way of choosing to hear it. In the future, there might be many interactive tests: or at least, ones that require someone to sit in front of the computer. These could all be turned off by default, but could be turned on through an option to runtest, or via an environment variable (WINETEST_INTERACTIVE). Does this sound reasonable? (no pun intended ;) ---- Paul Millar

Dec. 16, 2002

stub handling

by Dimitrie O. Paun

Alexandre, In the past functions that were declared stubs in the .spec file got a dummy definition, so programs using them could link. This doesn't seem to be the case anymore: mingwrap -mwindows -mno-cygwin -s -o putty.exe be_all.o cmdline.o ldisc.o \ ldiscucs.o logging.o misc.o noise.o pageantc.o portfwd.o \ printing.o proxy.o raw.o rlogin.o settings.o sizetip.o ssh.o \ sshaes.o sshblowf.o sshbn.o sshcrc.o sshcrcda.o sshdes.o \ sshdh.o sshdss.o sshmd5.o sshpubk.o sshrand.o sshrsa.o \ sshsh512.o sshsha.o sshzlib.o telnet.o terminal.o tree234.o \ unicode.o version.o wcwidth.o wildcard.o win_res.res.o \ winctrls.o windlg.o window.o winnet.o winstore.o winutils.o \ x11fwd.o -ladvapi32 -lcomctl32 -lcomdlg32 -lgdi32 -limm32 \ -lshell32 -luser32 -lwinmm -lwinspool -lwsock32 printing.o: In function `printer_start_job': printing.o(.text+0x1fa): undefined reference to `EndDocPrinter' printing.o(.text+0x20a): undefined reference to `EndPagePrinter' printing.o(.text+0x237): undefined reference to `StartDocPrinterA' printing.o(.text+0x24a): undefined reference to `StartPagePrinter' printing.o: In function `printer_finish_job': printing.o(.text+0x2b6): undefined reference to `EndPagePrinter' printing.o(.text+0x2bd): undefined reference to `EndDocPrinter' collect2: ld returned 1 exit status How shall we proceed? -- Dimi.

Dec. 16, 2002

Re: resend: ConvertThreadToFiber stub

by Rein Klazes

On Mon, 16 Dec 2002 13:47:10 -0600, you wrote: > On Monday 16 December 2002 01:08 pm, Rein Klazes wrote: > > Use this one, the previous patch wasn't clean > > > > > > Changelog: > > > > dlls/kernel : kernel32.spec > > scheduler : thread.c > > > > Add a stub for ConvertThreadToFiber > > > > Rein. > > funny, I recently implemented same but never submitted. using HTML Help > by any chance? Yes, so I can use the the MSDN library help files. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Dec. 16, 2002

Re: resend: ConvertThreadToFiber stub

by Greg Turner

On Monday 16 December 2002 01:08 pm, Rein Klazes wrote: > Use this one, the previous patch wasn't clean > > > Changelog: > > dlls/kernel : kernel32.spec > scheduler : thread.c > > Add a stub for ConvertThreadToFiber > > Rein. funny, I recently implemented same but never submitted. using HTML Help by any chance? -- gmt

Dec. 16, 2002

Re: winmm test extension

by Francois Gouget

Hi Dan, Dan Kegel wrote: [...] > I may have a counterexample. The patch I submitted recently was > to fix a hang in playing sound. So if you add a timeout to > your test, it would at least verify that sounds played in > the proper amount of time, and didn't hang wine. Yes, there are a number of failure modes that could be tested automatically. Wine could crash for instance... What I could do is modify the test to play silence by default, and only play an actual tone if the user asks for it. I should also document the goals of playing a tone a bit more in the test itself. Maybe printing a trace telling the user how to play a tone could be nice (otherwise it's hard for someone running the test to know that the test has options). The message could look something like: winmm.c: Playing silence, use 'tone' option for an actual tone The idea of timing the sound and verifying that it does not play in less time than it's supposed to could work too. I'm a bit worried by that but I guess all that can happen is that we will overestimate the time it took to play the tone, not underestimate it. Well, if nobody objects I can add all that to the test once it's committed. -- Francois Gouget fgouget(a)codeweavers.com

Dec. 16, 2002

Re: winmm test extension

by Dan Kegel

Francois Gouget wrote: > This test extends the winmm test and makes it possible to play actual > sound. Of course the test will not do that unless you specifically ask > for it: > * I doubt anyone would be happy to do 'make test' in Wine's main > directory and to get annoying long beeps comming out of their computer > * tests are usually run unattended and there is not much point playing > the sounds if no-one listens to them to make sure they got played > correctly. > > So what does it do? > For each supported format it plays the international 'LA', i.e. a 440Hz > sinusoid. It is expected that on some sound cards and for some formats > the signal will have to be converted from 8 to 16 bit or from mono to > stereo, or even resampled. Normally this should not affect the sound > being played so you should keep hearing the same tone. If that's not the > case then something went wrong during th I may have a counterexample. The patch I submitted recently was to fix a hang in playing sound. So if you add a timeout to your test, it would at least verify that sounds played in the proper amount of time, and didn't hang wine. - Dan

Dec. 16, 2002

Re: DrawCaptionTempW patch

by Rein Klazes

On Mon, 16 Dec 2002 19:45:51 +0100, you wrote: > >>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: > > Rein> Hi, This bug caused uninitialised height and width data to be fed > Rein> to the font rasterizer, allocating more then 1.2 GB of VM. > > What action or program triggered that bug? TheBat! email program. It has stopped working for some time, perhaps two months. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Dec. 16, 2002

Re: DrawCaptionTempW patch

by Uwe Bonnes

>>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: Rein> Hi, This bug caused uninitialised height and width data to be fed Rein> to the font rasterizer, allocating more then 1.2 GB of VM. What action or program triggered that bug? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 16, 2002

Re: windows visual view ?

by Francois Gouget

On Mon, 16 Dec 2002, Tom Wickline wrote: > Is was just wondering if there was any type of Windows visaul view ? > view as in how evreything is layed out ? and how wine compares to Win32 ? > Say if you had a visual view of how win32 is layed out and just how > close wine comes to this . Would this be more or less what you are looking for? * Windows Architecture http://www.lugod.org/presentations/crossover/Diapositive5.html * Wine Architecture http://www.lugod.org/presentations/crossover/Diapositive6.html * API stats (the 'diff' part) http://fgouget.free.fr/wine/winapi_stats-en.shtml -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

Dec. 16, 2002

It now hangs when running an install shield

by Ben Clewett

Wine, You gues have already given me loada help, but straight onto my next stage, and I get (my old friend) the Wine Console error traceback. Running an Install Shield instalation, starts OK, gets past the initial 'Install Shield will now guide you through your instalation'. Then blanks the screen for about ten minutes, returning with the console showing: Unhandles exception: page fault on write access to E:\_ITSTMP.DIR\_INS55765._WP): movl %eax,0x28(%edx,%ecx,4) Looked in /tmp/winetmp-root/_ITSTMP.DIR/* & can't see anything wrong. 'df' shows a few dozen gig free. And clues? I hope at the end of this, I can return the great feedback by answering some questions my self :) Ben

Dec. 16, 2002

Workaround for Wine to produce dead-keys with Brazilian ABNT-2 keyboards

by Mauro Carvalho Chehab

I spent a lot of time looking for a solution for using my Brasilian ABNT-2 keyboard. I've already sent a new patch to wine-patches in order to correct keytables and vkey tables. But it remained a small problem: It was NOT generating the correct dead-key codes. So, I developed a *workaround*. This patch has to be applyied to dlls/x11drv/keyboard.c (It was tested with CVS 20021125). I advice that it wil work only for ABNT-2 keyboards. ---------------------------------------------------------------------------------------------------------------------------------------- --- keyboard.c 2002-11-28 22:33:07.000000000 -0200 +++ keyboard.c 2002-12-16 15:10:07.000000000 -0200 @@ -1759,6 +1794,10 @@ else TRACE("Found keycode %d (0x%2X)\n",e.keycode,e.keycode); ret = XLookupString(&e, (LPVOID)lpChar, 2, &keysym, NULL); + +/* Gambiarra para funcionarem os acentos em teclado ABNT-2 */ +if ((e.keycode==48)||(e.keycode==34)||((e.keycode==15)&&(e.state & ShiftMask))) ret=0; + wine_tsx11_unlock(); if (ret == 0)

Dec. 16, 2002

Re: How long does it take *you* to build wine?

by Drew Ogle

On Sun, 15 Dec 2002, Dan Kegel wrote: > I got tired of waiting for wine to build, and started looking > for ways to speed it up. > > Wine-20021125? > - Dan Well, with a dual 1800+ MP system ( cvs from 20021216 ) takes real 6m49.808s user 12m0.330s done with make -j2 > > p.s. > No fair using ccache! That's the next tool I want to investigate; > it's probably the biggest win of all, at least for regression > testing. > >

Dec. 16, 2002

Re: Wine, Windows.Forms on Linux, GC and segfaults.

by Marcus Meissner

On Wed, Dec 11, 2002 at 01:05:32PM -0500, Miguel de Icaza wrote: > Hello, > > > > The problem is that by the time that Wine has been initialized, > > > using setjmp/longjmp will always lead to a crash. The code > > > in pthreads > > > that performs the longjmp will first try to invoke the pthread cleanup > > > routines, and then invoke longjmp. This never happens. > > > > You can't and needn't link with -lpthread. Wine has its own > > pthread implmentation. > > > > I tried your included code and it works just fine unless you > > link with -lpthread, then it crashes in the same way as in your > > attached picture. But then you should never link Wine with > > -lpthread so that is not really a bug. > > > > Of course Wine pthread implementation it not in any way complete > > so some function might be missing and some might only be only > > partially implemented and of course some might be incorrectly > > implemented. > > > > So please try again without linking with -lpthread. > > The problem is that this is very hard for us to do as two of the > underlying libraries we are using (libmono and libgc) both link against > pthread to achieve their threading capabilities. > > It might be better to investigate what are Wine's requirements for > having its own pthread implementation, and have those changed pushed to > the maintainers of pthreads. > > In particular, we are interested in using WineLib, maybe it would be > possible to have WineLib use the standard pthread implementation instead > of rolling its own? This would be very difficult. WINE implements the Win32 threading/process and synchronisation model. It needs to use the OS native threads so it gets the stack maintenance and the correct handling of the %fs. So WINE cannot change to pthreads without major hacks to the pthread library I guess. Ciao, Marcus

Dec. 16, 2002

windows visual view ?

by Tom Wickline

Is was just wondering if there was any type of Windows visaul view ? view as in how evreything is layed out ? and how wine compares to Win32 ? Say if you had a visual view of how win32 is layed out and just how close wine comes to this . If there was a negitive of Win-ME for example and one of wine how would wine look if it was layed on top of the Win-ME negitive ? I am trying to view Win32 in my head and wine and how they ( scope ) up..... could this cause a brain hemorrhage ?? ......... :) comments , flames , views, insight most welcome Tom

Dec. 16, 2002

Quick silly question, registering DLL's

by Ben Clewett

Forgive any stupidness implied, I am UNIX not MS! How does one check whether a DLL is registered, and how does one actually register a DLL in wine? Thanks,

Dec. 16, 2002

Re: VarOr / oleaut32

by us＠the-edmeades.demon.co.uk

> It's a VB6 application of our own description. I have not had a chance > to hack the source code to see where it comes into play, but probably > something to do with a third party DLL we use for remote database > connectivity. There's a significant number of Var* routines not implemented. I implemented the missing ones for a VB6 app I had written, but each app executes different ones, so there's still quite a few missing. If you try the patch already submitted, see if you get further and potentially hit other missing functions. Most of the missing fn's are not too bad to implement, so keep reporting them Jason

Dec. 16, 2002

Re: How long does it take *you* to build wine?

by Michael Stefaniuc

On Sun, Dec 15, 2002 at 10:51:59PM -0800, Dan Kegel wrote: > It does look like distributing the load helps a tiny > bit, but it's not clear it's a big win over just building > on the dual 650MHz machine. > The fastest build I've seen so far is 19 minutes. I'm pretty > sure I'm not doing things optimally yet. > > So how long does it take *you* to do a clean build > (just the 'make' part after 'make depend', say) of > Wine-20021125? On a athlon 900 with 512 MB RAM it takes about 30 minutes for a full build, but only for the first run. On the second run it takes about 3-4 minutes :). Ok, i'm using ccache and it realy paid out during my -DSTRICT work. The cache hit rate had varied between 30% and 80%, depending what i've done. You get 30% - 40% hitrate for normal updates from cvs without doing a "make clean". > No fair using ccache! That's the next tool I want to investigate; > it's probably the biggest win of all, at least for regression > testing. I've thought about buying a new computer before i started to use ccache. With ccache i'll wait for the Hammer. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Dec. 16, 2002

Re: VarOr / oleaut32

by Andreas Mohr

On Mon, Dec 16, 2002 at 09:20:18AM +0000, Ben Clewett wrote: > us(a)the-edmeades.demon.co.uk wrote: > >Hiya, > > > >What app shows this? Can I get hold of it - I should be able to knock > >something up for it as a test regardless, but it might not be til mid next > >week. > > > >Jason > > > > It's a VB6 application of our own description. I have not had a chance > to hack the source code to see where it comes into play, but probably > something to do with a third party DLL we use for remote database > connectivity. > > Thanks for the offer of a fix. > > I was hoping there was a generic fault, and somebody might have a > generic fix. Since it seems to be more indepth, I will try any get an > exact location of location of failure first. Even though I now implemented VarOr, I guess you might want to be careful about that and use a native oleaut32 instead, since oleaut32 contains tons of variant calculation functions (mul, add, and, xor, various conversions, div, round), so if there's *any* bug in there affecting some function your program uses, boom goes your data eventually. That's why I'd use native oleaut32 for production use. OTOH I'm still waiting for some builtin oleaut32 test reports ;) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

Dec. 16, 2002

Re: VarOr / oleaut32

by Ben Clewett

us(a)the-edmeades.demon.co.uk wrote: > Hiya, > > What app shows this? Can I get hold of it - I should be able to knock something up for it as a test regardless, but it might not be til mid next week. > > Jason > It's a VB6 application of our own description. I have not had a chance to hack the source code to see where it comes into play, but probably something to do with a third party DLL we use for remote database connectivity. Thanks for the offer of a fix. I was hoping there was a generic fault, and somebody might have a generic fix. Since it seems to be more indepth, I will try any get an exact location of location of failure first. Ben

Dec. 16, 2002

Re: How long does it take *you* to build wine?

by Martin Fuchs

Here are my timings for a 1.8 GHz P4: time ./configure real 0m55.767s user 0m15.590s sys 0m14.530s time make clean real 0m9.166s user 0m2.980s sys 0m2.270s time make real 16m55.724s user 11m47.180s sys 1m2.460s I wonder, if it's really necessary to change configure scripts and do a "configure/make clean all" that often as it's done right now. The good thing about it is, that it shows how well Linux' mutlitasking does work compared to Windows. You can just let it build it in the background and do other things meanwhile. ;-) -- Martin Fuchs martin-fuchs(a)gmx.net

Dec. 16, 2002

Re: How long does it take *you* to build wine?

by Dan Kegel

Dan Kegel wrote: > So how long does it take *you* to do a clean build > (just the 'make' part after 'make depend', say) of > Wine-20021125? OK, got some numbers building 20021125 on my home machines: 30min : 750MHz PIII laptop 17min 21sec: dual 650MHz PIII, 7200RPM disks, make -j2 16min 1sec: distcc on the dual 650MHz as localhost, 750MHz laptop, and a 1.1GHz celeron, make -j4 And on another machine not at home: 8 min : dual 1.2GHz P4 Xeon, make -j2 So the fastest build I've seen so far (not including configure or make depend) is about 8 minutes. distcc seems to help a tiny bit. it's kind of looking like I should get a faster motherboard if I want sub-ten-minute builds. Next step should be to measure benefit of using ccache when searching through cvs for the patch that broke something, but I'll probably just go out and get a faster motherboard. I want one with gigabit ethernet onboard; pricewatch says $320 for an Asus A7V8X with "2400" Athlon XP, $353 for an Asus P4PE with 2.4GHz P4. Hmm. I bet either one of those would get me Wine builds below ten minutes... Does anyone have a good recipe for building an inexpensive machine that can build Wine quickly? - Dan

Dec. 16, 2002

How long does it take *you* to build wine?

by Dan Kegel

I got tired of waiting for wine to build, and started looking for ways to speed it up. I have three systems handy: a dual 650MHz PIII, a 750MHz PIII laptop, and a 1.1 GHz Celeron with shared memory video (i.e. dog slow). To see if a parallel compile would help, I installed Red Hat 8.0 on all systems, and installed the RPM for distcc from http://distcc.samba.org. I then timed how long it took to do a 'make' after 'make clean' in a recent copy of the wine tree. It does look like distributing the load helps a tiny bit, but it's not clear it's a big win over just building on the dual 650MHz machine. The fastest build I've seen so far is 19 minutes. I'm pretty sure I'm not doing things optimally yet. So how long does it take *you* to do a clean build (just the 'make' part after 'make depend', say) of Wine-20021125? - Dan p.s. No fair using ccache! That's the next tool I want to investigate; it's probably the biggest win of all, at least for regression testing.

Dec. 16, 2002

Re: regression - 'wine notepad.exe' now has fixme

by Uwe Bonnes

>>>>> "Dan" == Dan Kegel <dkegel(a)ixiacom.com> writes: Dan> With today's cvs, I see fixme:win:SetWindowTextA cannot set text Dan> "Notepad - (untitled)" of other process window (nil) when I run Dan> notepad.exe. This also happens with wine20021125, but not with Dan> wine20020904. SetWindowText can not yet set the text across process boundary. But more functions do the right thing and use SetWindowText and not a workaround or don't use it at all. So this is not a regression. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 15, 2002

GetWindowTextLengthA()/WM_GETTEXTLENGTH issue

by Andreas Mohr

Hi all, Steuertipps PC 2003 (yeah, right, it's that time of the year again ;) has corrupted button text - drawing beyond the last actual string character. This is because the supplied OWL (Borland, I believe ?) DLL calls DrawTextA with twice the amount of string length (yeah, must be a Unicode issue, of course... :), thus forcing DrawTextA into drawing way too much. (side note: OWL seems to implement its own custom buttons) This doubled value comes from GetWindowTextLengthA() (0x14 bytes instead of 0x0e bytes), which thus comes from WM_GETTEXTLENGTH. WINPROC_UnmapMsg32ATo32W does for a WM_GETTEXTLENGTH unmapping: case WM_GETTEXTLENGTH: case CB_GETLBTEXTLEN: case LB_GETTEXTLEN: /* there may be one DBCS char for each Unicode char */ return result * 2; The button text in question is: L"&Schlie\00dfen" (aka "&Schliessen") (so it's a Unicode string with 0x0e units) MSDN says that both WM_GETTEXTLENGTH and GetWindowTextLength return inexact amounts of string lengths for certain Unicode/DBCS combos (and always at least as much as the minimum storage it requires). However, I guess that we really *shouldn't* double the string length in this case (I guess we better avoid that corruption ;). Hmm, any idea how the unmapping can be improved ? To me it seems that the generic unmapping in WINPROC_UnmapMsg32ATo32W is exactly the place where s^Hcrap happens. (there seems to be a pretty direct connection between GetWindowTextLengthA and DrawTextA) Andreas Mohr

Dec. 15, 2002

Re: docu patch

by Dimitrie O. Paun

On December 15, 2002 07:25 am, Andreas Mohr wrote: > - comment out mapping to home drive in default config and add > a comment on why we don't include it This renders Wine useless for all but the most trivial of tasks. But maybe playing winmine is good enough ... :) If we want to be really secure, we should recommend that the user removes the floppy drive, and _all_ network cards, as there are virii that are known to use such mediums... :))) -- Dimi.

Dec. 15, 2002

SHELL32.DLL.ILFindLastID segfault

by Dimitrie O. Paun

If you run the winGTK installer (wingtk-0.2.exe, available from http://wingtk.sourceforge.net/) and click on the "Browse" button to select the installation directory, you get: [dimi(a)dimi wine.src]$ wine ~/dev/wine/wingtk-0.2.exe fixme:shell:BrsFolderDlgProc flags 1 not implemented wine: Unhandled exception, starting debugger... fixme:console:SetConsoleCtrlHandler (0x4057e554,1) - no error checking or testing yet And the backtrace is: Wine-dbg>bt Backtrace: =>0 0x40a0707a (SHELL32.DLL.ILFindLastID+0x3e in shell32.dll.so) (ebp=40761750) 1 0x40a0884e (SHELL32.DLL.SHGetPathFromIDListW+0x1be in shell32.dll.so) (ebp=40761774) 2 0x40a0b0bf (SHELL32.DLL.SHGetFileInfoA+0x2e7 in shell32.dll.so) (ebp=40761c9c) 3 0x40a0b745 (SHELL32.DLL.SHGetFileInfoW+0x8d in shell32.dll.so) (ebp=40761e28) 4 0x409fec9f (SHELL32.DLL.SHGetFreeDiskSpace+0x213f in shell32.dll.so) (ebp=40762108) 5 0x409fecde (SHELL32.DLL.SHGetFreeDiskSpace+0x217e in shell32.dll.so) (ebp=40762124) 6 0x409fef9a (SHELL32.DLL.SHGetFreeDiskSpace+0x243a in shell32.dll.so) (ebp=407623dc) 7 0x409fec2d (SHELL32.DLL.SHGetFreeDiskSpace+0x20cd in shell32.dll.so) (ebp=40762400) 8 0x409ff35e (SHELL32.DLL.SHGetFreeDiskSpace+0x27fe in shell32.dll.so) (ebp=4076241c) 9 0x4089d13f (USER32.DLL.GetTaskmanWindow+0xbb in user32.dll.so) (ebp=40762440) 10 0x4089d19d (USER32.DLL.GetTaskmanWindow+0x119 in user32.dll.so) (ebp=4076246c) 11 0x408a210a (USER32.DLL.CallWindowProcW+0xda in user32.dll.so) (ebp=407624a0) 12 0x40879ed8 (USER32.DLL.DefDlgProcW+0x44 in user32.dll.so) (ebp=407624cc) 13 0x4089d13f (USER32.DLL.GetTaskmanWindow+0xbb in user32.dll.so) (ebp=407624f0) 14 0x4089d19d (USER32.DLL.GetTaskmanWindow+0x119 in user32.dll.so) (ebp=4076251c) 15 0x408a19dd (USER32.DLL.GetTaskmanWindow+0x4959 in user32.dll.so) (ebp=40762544) 16 0x408a1ffe (USER32.DLL.CallWindowProcA+0xda in user32.dll.so) (ebp=40762578) 17 0x408b20d4 (USER32.DLL.IsCharAlphaW+0x2b90 in user32.dll.so) (ebp=407625d4) 18 0x408b2d9e (USER32.DLL.SendMessageTimeoutA+0x1ba in user32.dll.so) (ebp=4076263c) 19 0x408b2e25 (USER32.DLL.SendMessageA+0x31 in user32.dll.so) (ebp=40762668) 20 0x4087d005 (USER32.DLL.DefWindowProcW+0x1885 in user32.dll.so) (ebp=407626f8) 21 0x4087d87c (USER32.DLL.DialogBoxParamW+0x44 in user32.dll.so) (ebp=40762728) 22 0x409ff691 (SHELL32.DLL.SHBrowseForFolder+0xd1 in shell32.dll.so) (ebp=40762770) 23 0x00405575 (wingtk-0.2.exe.EntryPoint+0x1017 in F:\dev\wine\wingtk-0.2.exe) (ebp=407629c0) 24 0x4089d13f (USER32.DLL.GetTaskmanWindow+0xbb in user32.dll.so) (ebp=407629e4) 25 0x4089d19d (USER32.DLL.GetTaskmanWindow+0x119 in user32.dll.so) (ebp=40762a10) 26 0x408a1ade (USER32.DLL.GetTaskmanWindow+0x4a5a in user32.dll.so) (ebp=40762a38) 27 0x408a2129 (USER32.DLL.CallWindowProcW+0xf9 in user32.dll.so) (ebp=40762a6c) 28 0x40879ed8 (USER32.DLL.DefDlgProcW+0x44 in user32.dll.so) (ebp=40762a98) 29 0x4089d13f (USER32.DLL.GetTaskmanWindow+0xbb in user32.dll.so) (ebp=40762abc) 30 0x4089d19d (USER32.DLL.GetTaskmanWindow+0x119 in user32.dll.so) (ebp=40762ae8) 31 0x408a210a (USER32.DLL.CallWindowProcW+0xda in user32.dll.so) (ebp=40762b1c) 32 0x408b2073 (USER32.DLL.IsCharAlphaW+0x2b2f in user32.dll.so) (ebp=40762b78) 33 0x408b2bc9 (USER32.DLL.SendMessageTimeoutW+0x135 in user32.dll.so) (ebp=40762bdc) 34 0x408b2de9 (USER32.DLL.SendMessageW+0x31 in user32.dll.so) (ebp=40762c08) 35 0x40850e65 (USER32.DLL.UnregisterDeviceNotification+0xc8d1 in user32.dll.so) (ebp=40762ce0) 36 0x40851269 (USER32.DLL.UnregisterDeviceNotification+0xccd5 in user32.dll.so) (ebp=40762d04) 37 0x4089d13f (USER32.DLL.GetTaskmanWindow+0xbb in user32.dll.so) (ebp=40762d28) 38 0x4089d19d (USER32.DLL.GetTaskmanWindow+0x119 in user32.dll.so) (ebp=40762d54) 39 0x408a210a (USER32.DLL.CallWindowProcW+0xda in user32.dll.so) (ebp=40762d88) 40 0x40886a56 (USER32.DLL.DispatchMessageW+0x96 in user32.dll.so) (ebp=40762dcc) 41 0x4087de12 (USER32.DLL.IsDialogMessageW+0x96 in user32.dll.so) (ebp=40762de4) 42 0x4087d6a1 (USER32.DLL.CreateDialogIndirectParamW+0xe1 in user32.dll.so) (ebp=40762e28) 43 0x4087d826 (USER32.DLL.DialogBoxParamA+0x52 in user32.dll.so) (ebp=40762e44) 44 0x00404cef (wingtk-0.2.exe.EntryPoint+0x791 in F:\dev\wine\wingtk-0.2.exe) (ebp=00420160) 45 0x74676e69 (SHLWAPI.DLL..reloc+0x3a5de69) (ebp=775c3a63) Wine-dbg> -- Dimi.

Dec. 15, 2002

Re: crtdll revisited

by Dimitrie O. Paun

On December 13, 2002 02:32 am, Dimitrie O. Paun wrote: > The msvcrt/ removal patch allows for a simpler fix to > the crtdll problem. > > I don't include a ChangeLog because if you like this one, > you should commit it together with the msvcrt/ removal patch, > as it's part of the same logical unit of work. While this works OK, it does break 'make depend' so... -- Dimi.

Dec. 15, 2002