Re: docu patch
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.
GetWindowTextLengthA()/WM_GETTEXTLENGTH issue
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: LSchlie\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
How long does it take *you* to build wine?
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.
