- Wine-Devel - list.winehq.org

Re: Get AdjustWindowRect working better
by Dmitry Timoshkov Sept. 22, 2004

Sept. 22, 2004

"Richard Cohen" <richard(a)daijobu.co.uk> wrote: > Changelog: > + Improve AdjustWindowRect > + add a test dlls/user/tests/win.c already has AdjustWindowRect tests, see test_nonclient_area. If you could add your tests there that would be great. -- Dmitry.

3 2

Re: System font width
by Huw D M Davies Sept. 22, 2004

Sept. 22, 2004

On Tue, Sep 21, 2004 at 07:40:17AM -0700, Jon Griffiths wrote: > Hi, > > I have an app that calls GetObject on SYSTEM_FONT and then uses the > returned LOGFONT.lfWidth in a calculation. Wine currently returns 0 > for the width, which causes a divide by zero error here. > > Testing under XP home shows that the returned with is 7 for the > system font. This patch changes the width specified in the stock font > list. Although this makes my app run and doesn't appear to have any > ill consequenses, it may be better to get some advice from a font > expert before committing this patch. This probably won't hurt anything. The correct way would be to load the system font and get its metrics. Huw. -- Huw Davies huw(a)codeweavers.com

2 1

Re: Lostwages add seti@home link
by Ivan Leo Puoti Sept. 22, 2004

Sept. 22, 2004

> mybe some > other place? Resources -> others ? I would say links -> others but we don't > have that :) If you know about a better place, I'm open to suggestions. Ivan.

3 2

load_dll: MODULE_GetLoadOrderW on filename versus libname
by Uwe Bonnes Sept. 22, 2004

Sept. 22, 2004

Hallo, some installer (extracted from slvc009j.zip from Texas instruments (www.ti.com)) loaded the native msi.dll, also I gave WINEDLLOVERRIDES=msi=b on the command line. The program copies some msi.dll to some directory, and prepends that directory to the loadpath. Then it calls: 000d:Call kernel32.LoadLibraryA(010013f8 "msi.dll") ret=01004283 load_dll now does a find_dll_file and sees "L:\\temp\\IXP000.TMP\\msi.dll" . sets filename to "L:\\temp\\IXP000.TMP\\msi.dll" and compares "L:\\temp\\IXP000.TMP\\msi.dll" for the loadorder. 000d:Call ntdll.LdrLoadDll(403dc0e8 L"L:\\temp\\IXP000.TMP;.;c:\\nt4sp5g\\system32;c:\\nt4sp5g;d:\\wine95;d:\\ wine95\\system;c:\\cae\\pasic\\spde;f:;",00000000,4070f424,4070f404) ret=4052392b trace:module:load_dll looking for L"msi.dll" in L"L:\\temp\\IXP000.TMP;.;c:\\nt4sp5g\\system32;c:\\nt4sp5g;d:\ \wine95;d:\\wine95\\system;c:\\cae\\pasic\\spde;f:;" trace:module:MODULE_GetLoadOrderW looking for L"L:\\temp\\IXP000.TMP\\msi.dll" trace:module:open_app_key searching L"L:\\temp\\IXP000.TMP\\msi" in L"Machine\\Software\\Wine\\Wine\\Config\\A ppDefaults\\msiinst.exe\\DllOverrides" trace:module:MODULE_GetLoadOrderW got hardcoded path default "n,b" for L"L:\\temp\\IXP000.TMP\\msi.dll" trace:module:load_dll Trying native dll L"L:\\temp\\IXP000.TMP\\msi.dll" trace:module:load_native_dll loading L"L:\\temp\\IXP000.TMP\\msi.dll" This leads to the native dll getting loaded. Is this the right thing? Shouldn't MODULE_GetLoadOrderW compare for libname and not filename? Only if libname has an explicit path, we should compare for that path. Bye Index: wine/dlls/ntdll/loader.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/loader.c,v retrieving revision 1.77 diff -u -w -r1.77 loader.c --- wine/dlls/ntdll/loader.c 15 Sep 2004 18:02:49 -0000 1.77 +++ wine/dlls/ntdll/loader.c 22 Sep 2004 10:08:48 -0000 @@ -1507,7 +1507,7 @@ } main_exe = get_modref( NtCurrentTeb()->Peb->ImageBaseAddress ); - MODULE_GetLoadOrderW( loadorder, main_exe ? main_exe->ldr.BaseDllName.Buffer : NULL, filename ); + MODULE_GetLoadOrderW( loadorder, main_exe ? main_exe->ldr.BaseDllName.Buffer : NULL, libname ); nts = STATUS_DLL_NOT_FOUND; for (i = 0; i < LOADORDER_NTYPES; i++) -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 2

Bugzilla Bug 2075: *printf incompatibilities
by Aneurin Price Sept. 22, 2004

Sept. 22, 2004

I've been looking at Warcraft III today, and had the problem of single player campaigns not showing up. The reason behind this is explained at http://bugs.winehq.org/show_bug.cgi?id=2075, and sure enough adding the special case described for the I64 argument type specification solves the problem in W3. Now I'm wondering how the problem should really be solved. Currently most (possibly all) of the *printf functions in msvcrt call MSVCRT_vsnprintfW. Should the same be done for vsnprintf, or should there be an independent MSVCRT_vsnprintfA? Either way I don't really know how the implementation would work. I was kind of hoping that this might be an okay place to start learning about WINE development, so if this in fact hinges on something far more complicated than I've been able to grasp, somebody please point this out to me :). Any pointers? Thanks, Aneurin Price

2 2

raw parallel port access
by BRC Sept. 22, 2004

Sept. 22, 2004

After quite a few days of perusing wine doc/source/config/mailing lists, I have found very scant references to accessing the raw parallel ports using wine. I am running FC2 linux (up-to-date) and have confirmed I can access the parallel port (dongle) presented to VMWare running a Windows 2000 guest OS successfully ie. access to /dev/parport0 works. I can also run all the programs included with wine-20040914 as well as some tests I wrote with mingw as well as those I compiled with VC++. The latter just cannot access the parallel port as VMWARE can though it runs normally until it can't access the dongle on LPT1. I've tried running as root too to no avail. What am I missing? If no answer is available, can someone at least point to the relevant sources so I can puzzle it out further: I am determined. Running with WINEDEBUG=+io yields no output yet WINEDEBUG=+all spews the world as expected. The relevant setup options I've played with are: ln -s /dev/parport0 ~chris/.wine/dosdevices/lpt1 When I run as root, I symlink ~root/.wine -> ~chris/.wine for convenience. The config ( I go back and forth on [ports] as I've found different messages/doc professing both). [parallelports] "lpt1" = "/dev/lp0" [ppdev] ;; key: io-base of the emulated port ;; value : parport-device{,timeout} ;; timeout for auto closing an open device ( not yet implemented) "378" = "/dev/parport0" ;;"278" = "/dev/parport1" ;;"3bc" = "/dev/parport2" [spooler] "FILE:" = "tmp.ps" "LPT1:" = "|lpr" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" [ports] "read" = "0x779,0x379,0x280-0x2a0" "write" = "0x779,0x379,0x280-0x2a0" #"read" = "0x378,0x379,0x37a,0x37c,0x77a" #"write" = "0x378,0x379,0x37a,0x37c,0x77a" Thanks! Chris __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

5 6

"optimized" assembly functions in wine
by Rein Klazes Sept. 22, 2004

Sept. 22, 2004

Hi, Just did not feel like chasing bugs the other day. I decided to have some fun with something that I wondering for a long time: the usefulness of inline i86 assembly in string functions. This is the test program as.c: ---------------------------------8<------------------------------------- #include <malloc.h> typedef unsigned short WCHAR, *PWCHAR; static inline WCHAR *strcpyW( WCHAR *dst, const WCHAR *src ) { #ifdef ASM int dummy1, dummy2, dummy3; __asm__ __volatile__( "cld\n" "1:\tlodsw\n\t" "stosw\n\t" "testw %%ax,%%ax\n\t" "jne 1b" : "=&S" (dummy1), "=&D" (dummy2), "=&a" (dummy3) : "0" (src), "1" (dst) : "memory" ); #else WCHAR *p = dst; while ((*p++ = *src++)); #endif return dst; } #define SZ 3000 main() { int i; PWCHAR s,d; s=malloc(SZ*sizeof(WCHAR)); d=malloc(SZ*sizeof(WCHAR)); memset(s,'x',SZ); s[SZ-1]=0; for(i=0;i<1000000;i++) strcpyW(d,s); } ---------------------------------8<------------------------------------- The function strcpyW is a copy from Wine with the #ifdef modified. I used the following commands gcc-3.3 -O2 as.c -o as -DASM ; time ./as;time ./as; time ./as and gcc-3.3 -O2 as.c -o as ; time ./as;time ./as; time ./as The resulting times are (all user time): test# asm C ----------------------- 1 15.970 15.899 2 15.966 15.943 3 15.959 15.941 ------ ------ ave 15.964 15.928 Notes: - tested on a PII 450 MHz; - I tested with gcc 2.95 and 3.4.2 as well, result are essentially the same. - size of main() is 0x7a (assembly) vs 0x82 (C-code) bytes; - I experimented with longer strings to see if there was any mem cache hit/miss effects and found none. Conclusions: 1. these routines are so fast that it is hard to imagine that these functions will be a bottleneck, justifying such optimization; 2. nothing shows here that inline assembly brings any advantage. Rein. -- Rein Klazes rklazes(a)xs4all.nl

4 4

Re: Epoll patch (rev 6)
by Marcus Meissner Sept. 22, 2004

Sept. 22, 2004

On Wed, Sep 22, 2004 at 04:54:53PM +0900, Mike McCormack wrote: > > Updated epoll patch for the current cvs. > Shachar, take heart! One hunk of the epoll patch has been committed, > only 15 to go! :) > > Mike > > > ChangeLog: > * add support for using epoll instead of select to the wineserver > > Index: configure.ac > =================================================================== > RCS file: /home/wine/wine/configure.ac,v > retrieving revision 1.310 > diff -u -r1.310 configure.ac > --- configure.ac 22 Sep 2004 04:08:38 -0000 1.310 > +++ configure.ac 22 Sep 2004 06:15:27 -0000 > @@ -132,6 +132,10 @@ > AC_CHECK_LIB(xpg4,_xpg4_setrunelocale) > dnl Check for -lpoll for Mac OS X/Darwin > AC_CHECK_LIB(poll,poll) > +dnl Check for -lepoll > +AC_CHECK_LIB(epoll,epoll_create, > + [AC_SUBST(LIBEPOLL,-lepoll) > + AC_DEFINE(HAVE_LIBEPOLL)]) Newer glibc versions have epoll_create built-in, so better use something like: LIBEPOLL= AC_SUBST(LIBEPOLL) AC_CHECK_FUNC(epoll_create,[ AC_DEFINE(HAVE_LIBEPOLL) ], [ AC_CHECK_LIB(epoll,epoll_create,[ LIBEPOLL="-lepoll" AC_DEFINE(HAVE_LIBEPOLL) ] ) ] )

1 0

Re: winefile sync with ReactOS
by Alexandre Julliard Sept. 22, 2004

Sept. 22, 2004

"Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > + if (order1 && order2) { > + order1 = fd1->cFileName[0]!='.'? 1: fd1->cFileName[1]=='.'? 2: fd1->cFileName[1]=='\0'? 3: 1; > + order2 = fd2->cFileName[0]!='.'? 1: fd2->cFileName[1]=='.'? 2: fd2->cFileName[1]=='\0'? 3: 1; You need to check that cFileName[2] == 0 too; but I'd suggest getting rid of the ?: operator abuse first, otherwise this is going to become totally unreadable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: fonts: 20 ppem Wine Sans Serif
by Dimitrie O. Paun Sept. 21, 2004

Sept. 21, 2004

On Mon, Sep 20, 2004 at 11:51:24AM +0100, Huw D M Davies wrote: > Huw Davies <huw(a)codeweavers.com> > Add a 20 ppem strike with cp1252 coverage to Wine Sans Serif. > Add U+201a to all strikes. Huw, What's the current status for fonts. I think they deserve a section under the UI Status: http://www.winehq.org/site/status_ui What do we have currently, in what state, what's left to do? -- Dimi.

4 4