January 2004 - Wine-Devel - list.winehq.org

CVS problem: stale lock?
by Sami Aario Jan. 15, 2004

Jan. 15, 2004

Hi all, I'm getting this message over and over while attempting an update from the wine cvs repository: "cvs server: [13:31:41] waiting for wineowner's lock in /home/wine/wine" I'm guessing a CVS process has died and left a stale lock in the repository. Could someone check it out?

1 0

signing off -- good luck
by Jeremy Shaw Jan. 15, 2004

Jan. 15, 2004

Hello, I am unsubscribing from wine-devel since I am no longer actively doing any wine development work. However, if any question arise about the patches I submitted recently, please feel free to email me. Good luck and have fun at wineconf! Jeremy Shaw.

1 0

Re: Build error in current cvs.
by Ivan Leo Murray-Smith Jan. 15, 2004

Jan. 15, 2004

Patches http://www.winehq.com/hypermail/wine-patches/2004/01/0201.html and http://www.winehq.com/hypermail/wine-patches/2004/01/0202.html fix the problem. Ivan.

1 0

dropped mouse movement when playing CS while running another application with Wine
by Jan Brunner Jan. 15, 2004

Jan. 15, 2004

Hello guys. I got CS running quite playable with and without Steam but with Steam mouse movement gets dropped sometimes (the sensitivity feels much lower). I experimented a bit and found out that this problem happens whenever Wine is running more than just hl.exe (e.g. CS + Winamp). In case this helps: Probably a bit of movement gets dropped while running CS only, too: Sensitivity 4.1 with Wine is about the same as 4.0 in Windows. It's constant though, so it doesn't matter. Any ideas on what causes the problem and how to fix it? -- Best regards, Jan Brunner <brunner(a)intergga.ch>

1 0

Fwd: Congratulations with your wine product.
by Dimitrie O. Paun Jan. 15, 2004

Jan. 15, 2004

Some good words for a happy user... ---------- Forwarded Message ---------- Subject: Congratulations with your wine product. Date: January 15, 2004 09:28 am From: Pascal Pype <pascal.pype(a)skynet.be> To: wine-faq(a)winehq.org Hello maintainers and developers of wine, The performance and configuartion of your product have been tremendously enhanced with respect to an experimental version I used nearly three years ago. There were two win3.1 applications that were written with turbo pascal for windows quite some time ago. When I tried to run those from within a wine environment , the performance of wine was so poor that the applications were useless when run in a *NIX environment. (linux , freeBSD) In a linux user & developer edition , I read an article about wine and its team leader Alexandre Julliard. The article have me a good impression , so I decided to give wine another try. Here are the conclusions: 1. outstanding documentation, 2. flawless install and configuration, 3. one out of the two windows applications works exactly as it did on win3.1 whilst the other does its job for about 60% of the total functionality without any fine tuning of the wine configuration. CONGRATULATIONS AND KEEP UP THE EXECELLENT WORK!!! Yours scincerely, Pype pascal. ------------------------------------------------------- -- Dimi.

1 0

Build error in current cvs.
by Ivan Leo Murray-Smith Jan. 15, 2004

Jan. 15, 2004

After a cvs update, there is this lovely build error, while building gdi, is it a problem with the recent gdi patches that have just got in or am I doing something wrong? make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/dlls/gdi' ../../tools/winebuild/winebuild -D__WINESRC__ -D_GDI32_ -o dispdib.spec.c --main-module gdi32.dll --spec dispdib.spec gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o dispdib.spec.o dispdib.spec.c ../../tools/winebuild/winebuild -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -o gdi.exe.spec.c --heap 65520 --main-module gdi32.dll --res version16.res --spec ./gdi.exe.spec gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o gdi.exe.spec.o gdi.exe.spec.c ../../tools/winebuild/winebuild -D__WINESRC__ -D_GDI32_ -o wing.spec.c --main-module gdi32.dll --spec wing.spec gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o wing.spec.o wing.spec.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o bidi16.o bidi16.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o gdi16.o gdi16.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o wing.o wing.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/bitblt.o ../../graphics/bitblt.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/dispdib.o ../../graphics/dispdib.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/env.o ../../graphics/env.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/escape.o ../../graphics/escape.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/fontengine.o ../../graphics/fontengine.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/mapping.o ../../graphics/mapping.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/painting.o ../../graphics/painting.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../graphics/path.o ../../graphics/path.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/bitmap.o ../../objects/bitmap.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/brush.o ../../objects/brush.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/clipping.o ../../objects/clipping.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/dc.o ../../objects/dc.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/dcvalues.o ../../objects/dcvalues.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/dib.o ../../objects/dib.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/enhmetafile.o ../../objects/enhmetafile.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/font.o ../../objects/font.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/gdiobj.o ../../objects/gdiobj.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/metafile.o ../../objects/metafile.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/palette.o ../../objects/palette.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/pen.o ../../objects/pen.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/region.o ../../objects/region.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ../../objects/text.o ../../objects/text.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o bidi.o bidi.c bidi.c: In function `BIDI_Reorder': bidi.c:75: error: `WINE_GCPW_DIR_MASK' undeclared (first use in this function) bidi.c:75: error: (Each undeclared identifier is reported only once bidi.c:75: error: for each function it appears in.) bidi.c:77: error: `WINE_GCPW_FORCE_LTR' undeclared (first use in this function) bidi.c:80: error: `WINE_GCPW_FORCE_RTL' undeclared (first use in this function) bidi.c:83: error: `WINE_GCPW_LOOSE_LTR' undeclared (first use in this function) bidi.c:86: error: `WINE_GCPW_LOOSE_RTL' undeclared (first use in this function) make[2]: *** [bidi.o] Error 1 make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/dlls/gdi' make[1]: *** [gdi] Error 2 make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/dlls' make: *** [dlls] Error 2 [ivan(a)localhost wine]$

1 0

Wine User's guide : using Windows ODBC driver manager seems to work
by Emmanuel Charpentier Jan. 15, 2004

Jan. 15, 2004

Following a suggestion in Wine User's Guide, (§ 1.1.2), I'd like to suggest an addition. The "ODBC" section (§ 5.12) gives details (§ 5.12.1) about the use of the native ODBC driver, routed through a fake "builtin" ODBC driver. I have not yet had to test it in real conditions. All I can tell is that I wasn't able to use it to "Attach" (M$ jargon) Postgres data in MS Access (see PPS for the setup) : when I tried to select "ODBC sources" from the "Attach tables" dialog, I got immediately an error box from unixODBC telling me that no data source was specified. However, the User's Guide is quite terse about the Windows ODBC driver. Exhaustive quotation : " Does anyone actually have any experience of this and anything to add?". Well, I do. In the same setup as before, I have been able to use the *native* odbc32.dll ODBC driver by pulling it from a real Windows instalation and adding "odbc32"="native,builtin" in the config file. I Installed the psqlodbc driver from the Postgres database, and retried : selecting "ODBC sources" in the "Attach tables" dialog box led me to the usual ODBC manager dialogs, where I have been able to create a DSN to my Postgres database. I have then been able to "Atach" my Postgres tables and views to an M$ Access database and peruse them. My conclusion is that such a setup can be used, if only to be able to export MS Access data to a more reasonable database manager. This information could be of some help to some people, and I'd like to see it reflected in the User's guide. Of course, I'm aware that such a quick test is no substitute to real tests and explorations. Feel free to reach to me for further information, test cases, etc ... Sincerely yours, Emmanuel Charpentier PS : I'm not on this list. Please Cc: me if you wishme to react to your answers. PPS : Setup : Debian (unstable), 2.4.21 kernel, Wine 20031212 as packaged in Debian, Win98SE (french), "fake windows" setup, using native stdole.tlb, ole32.dll, oleaut32.dll, rpcrt4.dll and, of course, odbc32.dll, MS Office 97 (installed without a hitch from the CD, except for a "Can't DDE connect to desktop" error in the setup, ignored) + SR1 parch. I have had success with SR2b, but this needs a lot more native DLLs, and I can't recall them at the moment (work machine). -- Emmanuel Charpentier

2 1

Re: Janitorial: Get rid of W->A calls for shlexec [RESEND]
by Marcelo Duarte Jan. 15, 2004

Jan. 15, 2004

Why my patch was not applied? If it will be because it conflicts with the patches of the ROS, can leave that in the next weekend I intend to make this, thus diminishes the work of them. But necessary to know if my patch it goes to be accepted, if I do not go to be losing my time. Thank you. Em Sáb 10 Jan 2004 04:51, Marcelo Duarte escreveu: > Updated with the lastest cvs. > > Changelog: > Marcelo Duarte <wine-devel(a)bol.com.br> > -Janitorial: Get rid of W->A calls for shlexec > -Implementation of FindExecutableW -- Marcelo Duarte

1 0

Re: Solaris specific configuration
by Alexandre Julliard Jan. 15, 2004

Jan. 15, 2004

Robert Lunnon <bobl(a)optushome.com.au> writes: > Changelog > Autodetection of XFREE86 as required for Solaris. This should be done in configure, assuming it is really necessary. Why can't we use the standard Xlib? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: ifenum.c mtu acquisition - Solaris
by Dimitrie O. Paun Jan. 15, 2004

Jan. 15, 2004

On January 13, 2004 09:46 pm, Robert Lunnon wrote: > +#if !defined sun > *mtu = ifr.ifr_mtu; > +#else > + *mtu=ifr.ifr_metric; > + #endif The #endif is not properly indented, any special reason? -- Dimi.

2 1

comctl32/imagelist -> ImageList_Remove problem
by hatky Jan. 15, 2004

Jan. 15, 2004

I run a free program call The All-seeing Eye, available for free at: http://www.udpsoft.com/eye2/index.html And run into a few errors like this: err:imagelist:ImageList_Remove index out of range! 0 ImageList_Remove gets( HIMAGELIST himl, int i) line 2040 of imagelist.c says: if ((i < -1) || (i >= himl->cCurImage)) { ERR("index out of range! %d\n", i); return FALSE; } But since "When an image is removed, the indexes of the remaining images are adjusted so that the ...." I assume most call do not include an index but only the handle as the case with this program from the trace I checked it sends 0 as the i and a true handle in himl and it makes since, since it first calls ImageList_Create to add images and ImageList_Create returns "Handle to the created image list" and not the place (remember the place changes anyway....) So..... I assume that in the case of the i = 0 the procedure should locate the i itself from the handle, am I right? getting close to his first patch :), Hatky. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

2 1

Will function advapi32.dll.RegOpenUserClassesRoot will be implemented?
by MediaHost (TM) Jan. 14, 2004

Jan. 14, 2004

Hi, Is there a chance, that function advapi32.dll.RegOpenUserClassesRoot will be implemented? As I can see, most up 2 date software of Micro$oft (Explorer etc.) is using this function and can not run on a W2K environment. Any suggestions? Regards Signer: Eddy Nigg Company: StartCom Group at http://www.startcom.org MediaHostT at http://www.mediahost.org --- StartCom Ltd. http://www.startcom.org Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.560 / Virus Database: 352 - Release Date: 1/10/2004

3 3

strange warning message when buildint current cvs
by Ivan Leo Murray-Smith Jan. 14, 2004

Jan. 14, 2004

With current cvs, I get this strange warning message make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winetest' cp ../../dlls/advapi32/tests/advapi32_test.exe.so advapi32_test.exe.so && strip -s advapi32_test.exe.so cp ../../dlls/gdi/tests/gdi32_test.exe.so gdi32_test.exe.so && strip -s gdi32_test.exe.so cp ../../dlls/kernel/tests/kernel32_test.exe.so kernel32_test.exe.so && strip -s kernel32_test.exe.so cp ../../dlls/ntdll/tests/ntdll_test.exe.so ntdll_test.exe.so && strip -s ntdll_test.exe.so cp ../../dlls/user/tests/user32_test.exe.so user32_test.exe.so && strip -s user32_test.exe.so cp ../../dlls/winmm/tests/winmm_test.exe.so winmm_test.exe.so && strip -s winmm_test.exe.so cp ../../dlls/winspool/tests/winspool.drv_test.exe.so winspool.drv_test.exe.so && strip -s winspool.drv_test.exe.so LD_LIBRARY_PATH="../../libs/unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -fowinetest.res winetest.rc ../../tools/winebuild/winebuild -D_REENTRANT -fPIC -o winetest.exe.spec.c --exe winetest.exe --exe-mode gui winetest.res main.o send.o util.o winetest.exe.dbg.o -L../../dlls -luser32 -lwsock32 gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o winetest.exe.spec.o winetest.exe.spec.c {standard input}: Assembler messages: {standard input}:856275: Warning: .stabs: description field '1a385' too big, try a different debug format {standard input}:856278: Warning: .stabs: description field '1a38c' too big, try a different debug format {standard input}:856281: Warning: .stabn: description field '1a38c' too big, try a different debug format {standard input}:856287: Warning: .stabn: description field '1a38f' too big, try a different debug format {standard input}:856291: Warning: .stabn: description field '1a38c' too big, try a different debug format {standard input}:856299: Warning: .stabn: description field '1a38e' too big, try a different debug format {standard input}:856302: Warning: .stabn: description field '1a38f' too big, try a different debug format {standard input}:856305: Warning: .stabn: description field '1a38e' too big, try a different debug format {standard input}:856308: Warning: .stabn: description field '1a390' too big, try a different debug format {standard input}:856316: Warning: .stabn: description field '1a393' too big, try a different debug format {standard input}:856321: Warning: .stabn: description field '1a397' too big, try a different debug format {standard input}:856324: Warning: .stabn: description field '1a398' too big, try a different debug format {standard input}:856331: Warning: .stabn: description field '1a391' too big, try a different debug format {standard input}:856344: Warning: .stabn: description field '1a392' too big, try a different debug format {standard input}:856349: Warning: .stabn: description field '1a398' too big, try a different debug format {standard input}:856357: Warning: .stabn: description field '1a39a' too big, try a different debug format {standard input}:856378: Warning: .stabn: description field '1a39b' too big, try a different debug format {standard input}:856383: Warning: .stabn: description field '1a39c' too big, try a different debug format {standard input}:856389: Warning: .stabn: description field '1a39d' too big, try a different debug format {standard input}:856401: Warning: .stabn: description field '1a39e' too big, try a different debug format {standard input}:856413: Warning: .stabn: description field '1a39f' too big, try a different debug format {standard input}:856416: Warning: .stabn: description field '1a3a0' too big, try a different debug format {standard input}:856420: Warning: .stabn: description field '1a3a1' too big, try a different debug format {standard input}:856428: Warning: .stabn: description field '1a394' too big, try a different debug format {standard input}:856442: Warning: .stabs: description field '1a38d' too big, try a different debug format {standard input}:856443: Warning: .stabs: description field '1a38e' too big, try a different debug format {standard input}:856444: Warning: .stabs: description field '1a38f' too big, try a different debug format {standard input}:856445: Warning: .stabs: description field '1a38f' too big, try a different debug format {standard input}:856446: Warning: .stabs: description field '1a38f' too big, try a different debug format {standard input}:856509: Warning: .stabs: description field '1a3f3' too big, try a different debug format {standard input}:856513: Warning: .stabn: description field '1a3f3' too big, try a different debug format {standard input}:856522: Warning: .stabn: description field '1a3f5' too big, try a different debug format {standard input}:856530: Warning: .stabn: description field '1a3f6' too big, try a different debug format {standard input}:856548: Warning: .stabs: description field '1168a' too big, try a different debug format {standard input}:856549: Warning: .stabs: description field '12078' too big, try a different debug format {standard input}:856550: Warning: .stabs: description field '12fff' too big, try a different debug format {standard input}:856551: Warning: .stabs: description field '13f10' too big, try a different debug format {standard input}:856552: Warning: .stabs: description field '148d9' too big, try a different debug format {standard input}:856553: Warning: .stabs: description field '17277' too big, try a different debug format {standard input}:856554: Warning: .stabs: description field '181cf' too big, try a different debug format {standard input}:856555: Warning: .stabs: description field '18d39' too big, try a different debug format {standard input}:856556: Warning: .stabs: description field '19709' too big, try a different debug format {standard input}:856557: Warning: .stabs: description field '1a290' too big, try a different debug format {standard input}:856558: Warning: .stabs: description field '1a2a8' too big, try a different debug format {standard input}:856559: Warning: .stabs: description field '1a2f2' too big, try a different debug format {standard input}:856560: Warning: .stabs: description field '1a3cf' too big, try a different debug format gcc -shared -Wl,-Bsymbolic,-z,defs,-init,__wine_spec_init,-fini,__wine_spec_fini winetest.exe.spec.o main.o send.o util.o winetest.exe.dbg.o -o winetest.exe.so -L../../libs/wine -lwine -L../../libs/port -lwine_port -lm -lc make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs/winetest' make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winevdm' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs/winevdm' make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winhelp' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs/winhelp' make[2]: Entering directory `/home/ivan/Development/Wine/CVS/wine/programs/winver' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs/winver' make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/programs' make[1]: Entering directory `/home/ivan/Development/Wine/CVS/wine/server' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/server' Wine build complete. I've tried make distclean and I still get it. I'm using gcc 3.3.1-2mdk, does this classify as something that should be fixed? Ivan.

2 1

Re: PATCH: Port Tim Ferguson's ICCVID codec to Wine
by Dmitry Timoshkov Jan. 14, 2004

Jan. 14, 2004

"Mike McCormack" <mike(a)codeweavers.com> wrote: > ChangeLog: > Tim Ferguson <Tim.Ferguson(a)infotech.monash.edu.au> > Mike McCormack <mike(a)codeweavers.com> > * Port Tim Ferguson's ICCVID codec to Wine Mike, could you put the iccvid sources at the same place as msrle32 (dlls/msvideo) and resend the patch? -- Dmitry.

4 4

Shell32 Patch 1.1
by Steven Edwards Jan. 14, 2004

Jan. 14, 2004

This patch replaces the prior patch. The ReactOS changelog wasnt very good and Martin pointed out that I missed the spec file. Changelog: "Martin Fuchs" <martin-fuchs(a)gmx.net> Implement RestartDialog and RestartDialogEx __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

1 0

Re: More Vacation backlog
by Hans Leidekker Jan. 14, 2004

Jan. 14, 2004

On Tuesday 13 January 2004 23:57, Uwe Bonnes wrote: > +HANDLE DEVICE_Open( LPCWSTR filenameW, DWORD access, DWORD attributes, LPSECURITY_ATTRIBUTES sa ) > { > const struct VxDInfo *info; > char filename[MAX_PATH]; > @@ -283,7 +283,7 @@ > > for (info = VxDList; info->name; info++) > if (!strncasecmp( info->name, filename, strlen(info->name) )) > - return FILE_CreateDevice( info->id | 0x10000, access, sa ); > + return FILE_CreateDevice( info->id | 0x10000, access, access, sa ); ^^^^^^ I think you want to pass 'attributes' here, right? -Hans

1 0

listview and LVS_OWNERDATA problems update
by Dan Kegel Jan. 14, 2004

Jan. 14, 2004

I just revisited http://bugs.winehq.org/show_bug.cgi?id=1268 and found that things are improved, but not fully working; there is corruption to the left of column 1 in the demo app. I have not yet rechecked http://bugs.winehq.org/show_bug.cgi?id=1404 to see how well that demo app is doing. - Dan

1 0

wwn #110 ??
by Tom Jan. 14, 2004

Jan. 14, 2004

If I look at WWN #110 on winehq.org I get this http://www.winehq.org/?issue=110 If I look at 110 at : http://kt.zork.net/wine/wn20011212_110.html it is almost toatly different!! Do I need to start reading both sites each week? And I guess ill send a patch to fix this as there is alot of good crap here to read! :) Tom

1 0

Oleaut32 tests fail
by Sylvain Petreolle Jan. 14, 2004

Jan. 14, 2004

Running the oleaut32 tests shows that vartype and vartest are failing. The 25 tests that fail are returning DISP_E_TYPEMISMATCH (0x80020005) Has someone an idea about these ? vartest.c:2653:======== Testing different VARTYPES ======== fixme:ole:VarParseNumFromStr dwInFlags & NUMPRS_HEX_OCT not yet implemented! vartest.c:2680: Test failed: 14: vt 83, return value 80020005, expected was 0 ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". _________________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Re: slight trouble running winetests under windows
by chmorgan＠charter.net Jan. 14, 2004

Jan. 14, 2004

Ahh yes, this appears to be the issue. If I go to "project settings->link->object/library modules" and add "uuid.lib" to the list then the test compiles without many other issues. Shouldn't the script be adding this to the .dsp/.dsw? I'm having great troubles compiling the test against vs6 header files as well, should I upgrade to the latest platform sdk? The wine headers work pretty well except for errors from the compiler about not being able to convert __uint64 to double. Chris > > From: Hans Leidekker <hans(a)it.vu.nl> > Date: 2004/01/13 Tue AM 05:20:29 EST > To: wine-devel <wine-devel(a)winehq.com> > CC: Chris Morgan <cmorgan(a)alum.WPI.EDU> > Subject: Re: slight trouble running winetests under windows > > On Tuesday 13 January 2004 05:47, Chris Morgan wrote: > > > I'm trying to get some of the wine tests compiling and running under > > windows, oleaut32 test specifically. I've got the project file built and > > everything opens fine under visual studio 6. The only issue is that during > > linking of the oleaut32 tests _IID_IFont is undefined. Oddly enough if I > > I get these linking errors too when compiling with MinGW. I solve > these by manually adding -luuid. The dsound test needs -luuid and > -ldxguid to link. There has been some discussion in the past as to > how to solve this. I proposed a number of changes to Wine's build > system to fix this but they were rejected. > > Let's see if I can sum up the issues. In Wine uuids are put in > a lib called libwine_uuid. It's called like that because a > libuuid already exists. Second thing is that in MinGW and MSVC > there are two separate libraries with uuids, uuid and dxguid, > whereas in Wine they're all in one. > > -Hans > >

3 2

Re: Implement LockWindowUpdate [take 2]
by Alexandre Julliard Jan. 14, 2004

Jan. 14, 2004

Mike Hearn <mike(a)theoretic.com> writes: > The other reason it might have bounced is if we're not allowed to extend > WND, though as it's purely internal and not accessible from the APIs that > should be OK? I'm not sure how to do this otherwise without exporting the > currently locked window variable from USER to X11DRV which probably breaks > dll separation. Either that, or adding a new driver procedure. Extending the WND structure is OK (though it doesn't seem necessary in that case), but accessing it from x11drv is a violation of dll separation. We still do that in a number of places but they will have to be fixed, so we probably shouldn't add new ones. -- Alexandre Julliard julliard(a)winehq.com

2 2

Cdrom driver
by Robert Lunnon Jan. 13, 2004

Jan. 13, 2004

I have just finished embelishing the cdrom driver to support solaris but I have nothing to test it against. Can anyone recommend a good test program for excercising CDROM ioctls ? Thanks Bob

2 1

Re: Solaris compile time fixes for CVS wine
by Dimitrie O. Paun Jan. 13, 2004

Jan. 13, 2004

On January 8, 2004 01:22 am, Robert Lunnon wrote: > Here are a buch of Solais compatibility patches for wine (Some but not all > of them). Within the enclosed tarball the diffs are structured according to > the wine cvs tree. There is a readme file accompanying each diff to explain > what the change is. Please break the archive into one patch per message, not compressed (preferably inlined). Here are a few pointers on how to send patches: http://www.winehq.org/site/sending_patches BTW, what's the status of building Wine under Solaris? What architecture (i386, etc) are you using? -- Dimi.

4 3

Re: [Bug 521] WINE removes trailing backslash in GetFullPathNameA/W in dos_fs.c.
by Eric Pouech Jan. 13, 2004

Jan. 13, 2004

Mike McCormack a écrit : > > This closes bug 521, and removes a couple of wine_todos from the > regression test for pathes. The test for setting "lastpart" in both > GetFullPathNameA/W was wrong (would always pass). for the record, I also sent a patch regarding (among other things) this issue, which also has never been applied. I don't know Alexandre's state on this. A+

2 3

WWN Links are busted
by Tom Jan. 13, 2004

Jan. 13, 2004

Hi, If you try to go to a WWN article from the status page's they don't work. example : Wine's fundamental architecture #154 = http://www.winehq.com/site/status_wine?issue=154#Kernel%20Module%20/%20Shar… the current link is: <a href="?issue=154#Kernel%20Module%20/%20Shared%20Memory%20Revisited">#154</a></td> when I think it should be: <a href="{$root}/site/?issue=154#Kernel%20Module%20/%20Shared%20Memory%20Revisited">#154</a></td> Jeremey N is this correct? If so I can fix all the links in the next day or so.. Tom

2 1

Re: WWN Links are busted
by Brian Vincent (C) Jan. 13, 2004

Jan. 13, 2004

> the current link is: > <a > href="?issue=154#Kernel%20Module%20/%20Shared%20Memory%20Revisited">#154</a> </td> I think it should be: href="/?issue=154#Kernel%20Module%20/%20Shared%20Memory%20Revisited" sed -e "s/href=\"\?/href=\"\/\?/g" --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

1 0

Re: shell32 patches to be usable by ReactOS Explorer
by Alexandre Julliard Jan. 13, 2004

Jan. 13, 2004

"Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > This was no joke. If you say, you would accept such as reformating patch, > I can easyly create one that eliminates all tab-characters, and generates > nice and uniform indented code. > This will make it a bit easier to create the small self-contained patches > you want to see instead of the big one. As additional bonus you will get > a very better formated shell32 code base. There's no reason to reformat all of shell32. If a given function is messed up you can fix it (in a separate patch), but otherwise it doesn't really matter if all functions don't use the exact same style. -- Alexandre Julliard julliard(a)winehq.com

2 1

stray file
by Hans Leidekker Jan. 13, 2004

Jan. 13, 2004

Hi, There's a stray file, dlls/checklink.c, in Wine CVS with these contents: int main(void) { return 0; } It must be a leftover from a configure run. I suspected my own tree but but it came back after I removed it and did a cvs update. -Hans

4 4

Re: uxtheme: lots of infrastructure
by Alexandre Julliard Jan. 13, 2004

Jan. 13, 2004

Kevin Koltzau <kevin(a)plop.org> writes: > This is a ton of infrastructure for my future patches, and a full > implementation of GetThemeDocumentationProperty which I primarilly > used to test my INI file processing, and its now possible to set the > current theme through the API..not that its much use to do that yet The part about storing the string maps as resources seems unnecessarily complicated and inefficient. Why can't you store an array directly in the code? -- Alexandre Julliard julliard(a)winehq.com

2 4

[Janitorial] Remove CopyMetaFileW->A call
by Vincent Béron Jan. 13, 2004

Jan. 13, 2004

Indentation in CopyMetaFileW is a bit inconsistent (there are some tabs which I left since I didn't touch those lines). Should I redo my patch to get rid of them (adds some noise to the patch), keep them in a separate patch (limited to this very function) or leave it as is? Also, should I change MF_CreateMetaHeaderDisk to accept a LPCWSTR, even though it then needs to convert it back to Ascii, or is the proposed way sufficient? Changelog: Removed a W->A cross-call (CopyMetaFileW->CopyMetaFileA). Vincent

1 0

Re: Implemention of LockWindowUpdate
by Mike Hearn Jan. 13, 2004

Jan. 13, 2004

On Tue, 13 Jan 2004 00:10:20 +0000, Mike Hearn wrote: > This patch makes the halflife menu screen look a bit better, with less > flashing. Unfortunately it also makes it feel a bit slower, but I think > that's just an optical illusion caused by less screen activity. The > bottleneck is elsewhere. Just had a hunch, and yes, switching off XRender and antialiasing speeds things up nicely. I guess I should yell at keithp or something.... :)

1 0

Re: wine/ windows/scroll.c include/user.h dlls/x11 ...
by Dimitrie O. Paun Jan. 12, 2004

Jan. 12, 2004

On Mon, 12 Jan 2004, Alexandre Julliard wrote: > Log message: > ScrollDC doesn't need to be in the graphics driver. Yay! (I submitted a similar patch some time ago, but you didn't like the {Start,End}GraphicsExposures functions. I still think they are decent GUI abstractions :)): http://www.winehq.com/hypermail/wine-patches/2002/09/0196.html Speaking of these things, I also don't think the driver should know about the caret. I see no need for the USER driver to know anything about the caret, we can just always implement it ourselves, no? http://www.winehq.com/hypermail/wine-patches/2002/09/0174.html I think there is a bug in the above patch (IIRC, I used to get some freezing in certain situations), but the idea still stands. -- Dimi.

2 1

Re: [WINEALSA] Add Midi IN support (take 3)
by Alexandre Julliard Jan. 12, 2004

Jan. 12, 2004

Christian Costa <titan.costa(a)wanadoo.fr> writes: > +static int npfd; > +static int pfd_array_size = 0; > +static struct pollfd *pfd = NULL; This isn't thread-safe. Why don't you simply allocate the array in the function and free it when you are done? -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: shell32 patches to be usable by ReactOS Explorer
by Martin Fuchs Jan. 12, 2004

Jan. 12, 2004

On 12.01.2004 01:41:45 Alexandre Julliard wrote: > "Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > > > Mhh - could you please tell me which "ugly hacks" you are speaking of? > > From a quick look at the patch, what I noticed is mostly the ifdefs > and other various disabling/commenting out of parts of the code. We had to disable some calls to internal functions, which are only exported from WINE, no real Windows OS. > There are also a number of unneeded whitespace changes that make the > patch larger than it should be. Yes, I tried to make some functions I had to alter a bit more readable. What about running a pretty printer, for example astyle (http://astyle.sourceforge.net/) on the whole code (or at least the shell32 directory) ? Some sections are currently indented with 2, some with 4 and some with 8 spaces - even mixed in the same function. Regards, Martin

1 1

Re: [Janitorial] ResetDCA->ResetDCW
by Dmitry Timoshkov Jan. 12, 2004

Jan. 12, 2004

"Vincent Beron" <vberon(a)mecano.gme.usherb.ca> wrote: > Changelog: > Get rid of a W->A crosscall (ResetDCA->ResetDCW). > -HDC WINAPI ResetDCW( HDC hdc, const DEVMODEW *devmode ) > +HDC WINAPI ResetDCA( HDC hdc, const DEVMODEA *devmode ) > { > - return ResetDCA(hdc, (const DEVMODEA*)devmode); /* FIXME */ > + DEVMODEW *devmodeW; > + HDC ret; > + > + if (devmode) devmodeW = GdiConvertToDevmodeW(devmode); > + else devmodeW = NULL; > + > + ret = ResetDCW(hdc, (const DEVMODEW*)devmode); It would be better to pass a real, newly allocated DEVMODEW* to ResetDCW(). That way you shouldn't need to cast type of a pointer. -- Dmitry.

2 1

Re: #2 - Mdi Win16/32 Split
by Dimitrie O. Paun Jan. 12, 2004

Jan. 12, 2004

On January 2, 2004 10:31 am, Steven Edwards wrote: > Split up the Win16/32 MDI support a bit. Any idea what the status of the Win16/32 split is? What DLLs are still not properly split? -- Dimi.

4 11

Re: shell32 patches to be usable by ReactOS Explorer
by Dimitrie O. Paun Jan. 12, 2004

Jan. 12, 2004

On January 11, 2004 08:04 am, Martin Fuchs wrote: > This patch consists of a number of changes we implemented in the ReactOS > CVS tree in order to use Wine's shell32.dll implementation for ReactOS > explorer. Please see the following changelog lists for the individual patch > descriptions: Martin, sending a bunch of patches compressed and in one message, makes them almost unreviewable but by the most die hards readers of wine-patches. It also makes it so much more difficult for Alexandre to split them up, match the ChangeLog, review them, etc. Please stick to one-(uncompressed, inlined)-patch-per-email-messsage rule, it's so much better for everybody. Here are some relevant links: http://www.winehq.org/site/sending_patches http://www.winehq.org/site/docs/wine-devel/patches -- Dimi.

4 6

Re: [Janitorial] ResetDCA->ResetDCW
by Dimitrie O. Paun Jan. 12, 2004

Jan. 12, 2004

On January 11, 2004 03:43 pm, Vincent Béron wrote: > Dimi, do you prefer to keep track of progress on this yourself, or > should I send a patch for the janitorial page too? It would be great if you'd send the update to the janitorial page. I try to keep track, but it's so much easier if patch authors lend a hand. But please wait until Alexandre commits it. -- Dimi.

1 0

Re: bogus patch to bind() dlls/winsock/socket.c (request removal)
by Ivan Leo Murray-Smith Jan. 11, 2004

Jan. 11, 2004

> With this change, we can use the 6.3 version of Quicktime > to see streamed video from Wineconf... This would break Grand Prix Legends and Nascar 2002 (Thats why the patch was written in the first place), maybe you should contact the author of the patch, a proper fix would be better, why should we chose between 2 games and quicktime? It should be possible to run all these apps. Ivan.

4 4

Re: [WINEALSA] Add Midi IN support (w/o alloca)
by Eric Pouech Jan. 11, 2004

Jan. 11, 2004

Christian Costa a écrit : > + for (wDevID = 0; wDevID < MIDM_NumDevs; wDevID++) > + if ( (ev->source.client == MidiInDev[wDevID].addr.client) && (ev->source.client == MidiInDev[wDevID].addr.client) ) > + break; Why do you do twice the same test ? A+

2 1

exception outside of stack limits
by Robert Lunnon Jan. 11, 2004

Jan. 11, 2004

There is a warning in signal_i368.c WARN( "exception outside of stack limits in thread %04lx eip %08lx esp %08lx stack %p-%p\n", GetCurrentThreadId(), EIP_sig(sigcontext), Can anyone tell me what this "means" in terms of what would have to go wrong to generate this warning ??

2 2

Correction to wineps spec file
by Vincent Béron Jan. 11, 2004

Jan. 11, 2004

Changelog: CreateDC in wineps is Unicode now, change the spec file accordingly. Vincent

1 0

Re: [WINEALSA] Add Midi IN support
by Alexandre Julliard Jan. 11, 2004

Jan. 11, 2004

Christian Costa <titan.costa(a)wanadoo.fr> writes: > + int npfd; > + struct pollfd *pfd; > + > + npfd = snd_seq_poll_descriptors_count(midiSeq, POLLIN); > + pfd = (struct pollfd *)alloca(npfd * sizeof(struct pollfd)); You should not use alloca in Wine, it's not portable enough. -- Alexandre Julliard julliard(a)winehq.com

4 3

Direct3D8 - OpenGL header problem
by Thomas Brix Larsen Jan. 11, 2004

Jan. 11, 2004

Hi list, just upgraded to 2.6.0 and the NVIDIA driver from minion.de and now I get this error when compiling wine: directx.c: In function `IDirect3D8Impl_GetDeviceCaps': directx.c:639: `GL_MAX_VERTEX_UNITS_ARB' undeclared (first use in this function) My X11/include/GL/ headers date, 2001-2002. Greetings, --Thomas _________________ My worst enemy gave me a copy of Windows...

3 2

Re: shell32 patches to be usable by ReactOS Explorer
by Martin Fuchs Jan. 11, 2004

Jan. 11, 2004

Sorry, I forgot to include the new file "shlcpanel.c" into the shell32 patch mail. Changelog: - Implementation of control panel folder in shgell namespace -- Martin Fuchs martin-fuchs(a)gmx.net

1 0

Build fails for current CVS update
by Sami Aario Jan. 11, 2004

Jan. 11, 2004

Hi, Building with tools/wineinstall fails with the latest CVS update on my system with the following: gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINE SRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-stri ct-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ddraw.spec.o ddraw.spec.c {standard input}: Assembler messages: {standard input}:654: Error: no such instruction: `yes "ddraw.dll"' {standard input}:655: Error: no such instruction: `yes "DDHAL32_VidMemAlloc"' {standard input}:656: Error: no such instruction: `yes "DDHAL32_VidMemFree"' {standard input}:657: Error: no such instruction: `yes "DDInternalLock"' and so on, lots more of the same. Anyone else getting these?

3 4

Re: bogus patch to bind() dlls/winsock/socket.c (request removal)
by Mike Hearn Jan. 11, 2004

Jan. 11, 2004

That looks familiar. In fact, the TRACE was originally a FIXME but it caused so much spew with so many apps I changed it. I couldn't see exactly what needed to be fixed given the contents of the message - it seems to be simply informing us of progress, but it's a possibility somebody knew this wasn't correct. On Sat, 10 Jan 2004 17:09:52 -0600, Jeremy White wrote: > Index: dlls/winsock/socket.c > =================================================================== > RCS file: /home/wine/wine/dlls/winsock/socket.c,v > retrieving revision 1.144 > diff -u -r1.144 socket.c > --- dlls/winsock/socket.c 2 Jan 2004 20:12:00 -0000 1.144 > +++ dlls/winsock/socket.c 10 Jan 2004 22:56:57 -0000 > @@ -1302,10 +1302,6 @@ > else > { > int on = 1; > - /* The game GrandPrixLegends binds more than one time, > but does > - * not do a SO_REUSEADDR - Stevens says this is ok */ > - TRACE( "Setting WS_SO_REUSEADDR on socket before we > bind it\n"); > - WS_setsockopt( s, WS_SOL_SOCKET, WS_SO_REUSEADDR, > (char*)&on, sizeof(on) ); > > if (bind(fd, uaddr, uaddrlen) < 0) > {

2 1

bogus patch to bind() dlls/winsock/socket.c (request removal)
by Jeremy Shaw Jan. 10, 2004

Jan. 10, 2004

As a result of this patch (which is currently applied in cvs head): http://www.winehq.com/hypermail/wine-patches/2002/12/0009.html WS_bind() currently does this before every call to bind(): WS_setsockopt( s, WS_SOL_SOCKET, WS_SO_REUSEADDR, (char*)&on, sizeof(on) ); Basically, it sets SO_REUSEADDR for every call to WS_bind(). I can't imagine this is the correct thing to do. According to MSDN, bind() should fail unless the program has explicitly set SO_REUSEADDR. See Error code WSAEADDRINUSE at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/wi… I found that this patch causes major problems with the xten sipphone client. The xten client does not explicitly set SO_REUSEADDR and depends on bind() failing if it tries to bind to the same local address/port twice. When the sipphone client needs a socket, it starts at port 8000, and calls bind() on successive ports until bind() returns success. So normally, if the program is already using port 8000, then bind() will fail and will try port 8001. However, with the above patch in place, bind() always works. So then the sipphone client will be using port 8000 twice, which the program is not designed to handle. If I remove the call to WS_setsockopt(), the xten sipphone client works correctly. I am proposing that the portion of the patch applied to WS_bind() be removed unless someone has a convincing arguement that the patch is actually valid. Jeremy Shaw.

2 1

WWN broken
by Brian Vincent (C) Jan. 10, 2004

Jan. 10, 2004

> We scan the XMl with tidy before posting. What is odd is that tidy > reports the XML is valid, but yet PHP's XML parser barfs on it. Whatever > the case, I just patched it, so it should be fixed online soon. Whoops. Sorry about that. I was running out the door when I put it up. I did run it through tidy, but tidy kind of sucks. The only way to really catch things is to run it through xmllint. But xmllint has a terrible interface for finding malformed problems.. hence tidy. Thanks for fixing that. Also, if anyone is bored and wants to do something easy, it might be nice to change all references in the WWN issues from winehq.com to winehq.org. I've just recently switched over to trying to be consistent on the .org thing. There's about 200 issues that could be run through sed. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

2 1

Re: dsound global variable use reduction
by Eric Pouech Jan. 10, 2004

Jan. 10, 2004

Robert Reif a écrit : > Reduce the use of the dsound global variable by > passing address to functions. This is in preparation > of supporting multiple DirectSound devices. We can't > remove all uses because an mmtimer callback can be > called even after the timer is killed. Windows has an > mmtimer flag that prevents this but wine doesn't > implement it. Could you be more specific on this one ? timeKillEvent is not 100% thread safe (I'll send a patch later on), but timeKillEvent in Wine is always synchronous (ie the killer is killed when timeKillEvent returns).

2 3