May 2006 - Wine-devel - list.winehq.org

Re: wine.inf: Add user "Shell Folders\Font" entry.
by Alexandre Julliard 30 May '06

30 May '06

Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: > ChangeLog: > wine.inf: Add user "Shell Folders\Font" entry. This should go with the other shell folder registration stuff in shell32. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [WINMM] always check for open and close enents in wave test
by Alexandre Julliard 30 May '06

30 May '06

Robert Reif <reif(a)earthlink.net> writes: > Fix CreateThread/waveOutOpen race by forcing parent thread to sleep > which allows background thread to run and block before waveOutOpen is > called. If the background thread has to run for things to work, you need to add a real synchronisation mechanism. A Sleep is not fixing anything, it's just making the race condition less likely. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: building win32/wine .exe's
by Dan Kegel 30 May '06

30 May '06

Nik wrote: > [I build my Windows apps on Win2k. How can I do it on Linux? > winegcc doesn't seem the right way.] Depends. If your apps use C++, and you need to be able to access non-COM C++ DLLs compiled by other folks, I bet the best way to go is just run the same development tools you used on Win2k under Wine. You might be able to just run the Visual C++ setup under Wine and get the IDE running. Or if the commandline is enough for you, see http://kegel.com/wine/cl-howto.html for how I used to set that up. Or, if you can get away with using Mingw instead of Microsoft's compiler, see http://www.winehq.com/site/docs/winedev-guide/cross-compiling-tests for info about how to set up a mingw cross-compiler. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

World of Warcraft (WoW) patch/more address space layout stuff
by Nick Law 30 May '06

30 May '06

Opening up the debate again on the World of Warcraft ( WoW ) memory patch. Some facts about WoW that may explain why the AppDB page is pretty active and the wow patch for wine 0.9.12 was downloaded over 1000 times from the Appdb page during a 4 week period.... Wow has approximately 6 million players that each pay about $90/year for the priviledge of connecting to a WoW server (Realm). Assuming this figure is broadly correct, Blizzard therefore receives $500,000,000/year just from this game in subscriptions. ( This doesn't include the cost of buying the game in the first place ). Perhaps Blizzard would like to employee a programmer fulltime just to work on the wine project to help make Wow run 100% ?. Anyway with the popularity of this game in mind, you can see why there is a lot of interest in making this patch a thing of the past, so the thousands of gamers who play this game on wine don't have to keep applying a special patch. I would be grateful for any suggestions as to how we could incorporate this patch so that it is no longer necessary. I know we can't simply include the patch, but there must be some way around this problem ? Below is an email regarding this partiicular problem, I would be grateful for any comments that I can pass back to Jan Riewe. Thanks Regards Nick Law Appdb Maintainer - World of Warcraft 1.10.x Any feedback is much appreciated. Comment for 'World of Warcraft 1.10.x' added by jan riewe ------------------------------------------------------- To reply to this email please use the link provided below. DO NOT reply via your email client as it will not reach the person who wrote the comment http://appdb.winehq.org/appview.php?versionId=4031&mode=nested#Comment-12086 Subject: RE: is this a workaround or a real patch? is it posible to make a workaround with the user.reg? in the transgaming forum i`ve found something like : [Software\\Wine\\AppDefaults\\WoW.exe\\Memory] 1148134976 "MemoryLayoutOverride"="0x10000000" does it make sense on wine? (i am not so familiar to the wine syntax *shame on me*) is this perhaps the key to get rid of the patches and make the binary build of wine working with WoW also fine? if this is a posibility perhaps you can post a full "user.reg" fix for those of us, who love the update feature. and i just want to thank you ... your service this really great! wow is one of the biggest steps at the moment for gaming society to move more and more to an opensource system. ---- --- wine/libs/wine/mmap.c.orig 2006-05-11 17:02:13.000000000 +0100 +++ wine/libs/wine/mmap.c 2006-05-19 22:08:03.000000000 +0100 @@ -183,7 +183,26 @@ #endif /* (__svr4__ || __NetBSD__) && !MAP_TRYFIXED */ +static void *get_anon_mmap_null_address(size_t size) +{ + static int got_override = 0; + static void *low_alloc_ptr = NULL; + void * current_low_alloc_ptr; + + if (!got_override) + { + low_alloc_ptr = (void*)0x10000000; + got_override = 1; + } + + current_low_alloc_ptr = low_alloc_ptr; + + if (low_alloc_ptr) + low_alloc_ptr += size; + return current_low_alloc_ptr; + } + /*********************************************************************** * wine_anon_mmap * @@ -213,6 +232,8 @@ return start; #endif } + if ((start == NULL) && !(flags & MAP_FIXED)) + start = get_anon_mmap_null_address(size); return mmap( start, size, prot, flags, get_fdzero(), 0 ); } --- wine/loader/preloader.c.orig 2006-05-11 17:02:13.000000000 +0100 +++ wine/loader/preloader.c 2006-05-19 22:14:22.000000000 +0100 @@ -109,8 +109,8 @@ static struct wine_preload_info preload_info[] = { { (void *)0x00000000, 0x00110000 }, /* DOS area */ - { (void *)0x7ffe0000, 0x01020000 }, /* shared user data + shared heap */ - { (void *)0x00110000, 0x1fef0000 }, /* PE exe range (may be set with WINEPRELOADRESERVE), defaults to 512mb */ + { (void *)0x80000000, 0x01000000 }, /* shared user data + shared heap */ + { (void *)0x10000000, 0x00f00000 }, /* PE exe range (may be set with WINEPRELOADRESERVE), defaults to 512mb */ { 0, 0 } /* end of list */ }; -- Regards Nick Law Mobile: 07736 022165 Email: nick.law(a)mic-nucmed.co.uk Medical Imaging Consultancy Ltd (M.I.C) Sales and Service of ADAC and IS2 Products http://www.mic-nucmed.co.uk

5 7

Re: comctl32_tests: Janitorial: write-strings warning fix
by Vitaliy Margolen 30 May '06

30 May '06

Saturday, May 27, 2006, 11:57:33 AM, Andrew Talbot wrote: > Changelog: > comctl32_tests: Janitorial: write-strings warning fix. > diff -urN a/dlls/comctl32/tests/tab.c b/dlls/comctl32/tests/tab.c > --- a/dlls/comctl32/tests/tab.c 2006-05-27 17:25:57.000000000 +0100 > +++ b/dlls/comctl32/tests/tab.c 2006-05-27 18:45:43.000000000 +0100 > @@ -57,6 +57,9 @@ > { > HWND handle; > TCITEM tcNewTab; > + static char text1[] = "Tab 1", > + text2[] = "Wide Tab 2", > + text3[] = "T 3"; > handle = CreateWindow ( > WC_TABCONTROLA, > @@ -71,13 +74,13 @@ > SendMessage (handle, WM_SETFONT, 0, (LPARAM) hFont); > tcNewTab.mask = mask; > - tcNewTab.pszText = "Tab 1"; > + tcNewTab.pszText = text1; > tcNewTab.iImage = 0; > SendMessage (handle, TCM_INSERTITEM, 0, (LPARAM) &tcNewTab); > - tcNewTab.pszText = "Wide Tab 2"; > + tcNewTab.pszText = text2; > tcNewTab.iImage = 1; > SendMessage (handle, TCM_INSERTITEM, 1, (LPARAM) &tcNewTab); > - tcNewTab.pszText = "T 3"; > + tcNewTab.pszText = text3; > tcNewTab.iImage = 2; > SendMessage (handle, TCM_INSERTITEM, 2, (LPARAM) &tcNewTab); What warning are you talking about here? It's ascii constant text. It should not be ever written to. Nor I ever seen a single warning from this code. Vitaliy Margolen

4 6

Re: wineconsole: Improve 64bit compatibility.
by Alexandre Julliard 30 May '06

30 May '06

Mike McCormack <mike(a)codeweavers.com> writes: > @@ -153,7 +153,7 @@ static LRESULT WINAPI WCUSER_FontPreview > SetWindowLong(hWnd, 0, 0); > break; > case WM_GETFONT: > - return GetWindowLong(hWnd, 0); > + return GetWindowLongPtr(hWnd, 0); > case WM_SETFONT: > SetWindowLong(hWnd, 0, wParam); > if (LOWORD(lParam)) You should fix all the Get/SetWindowLong calls that set the same value, changing only half will make things worse. You also have to reserve the proper size in the window class. -- Alexandre Julliard julliard(a)winehq.org

1 0

wined3d: GLSL shader status
by Jason Green 30 May '06

30 May '06

I'm working on the conversion from DirectX pixel and vertex shaders to GLSL function and have made a good bit of progress this weekend. At the moment, I'm able to run just about every simple vertex shader (version <= 1.4, and a few 2.0's) that I can find which already works on ARB_vertex_program (the current way that Wine handles this). I'm having a bit more trouble with pixel shaders, but I haven't really dug into it yet. Some of the really simple ones work, but I believe I'm missing a step in the texture binding code somewhere. I've posted a patch to enable this shader generation here: http://cmhousing.net/wine/glsl_hack4.diff If you want to try this and help debug things, you'll have to apply the patch (it's against the current git tree as of 2:00 AM EST, May 30th). Plus, you'll need a video card and driver capable of using GLSL (type 'glxinfo' and look for "GL_ARB_shading_language_100") . You'll also have to set a new registry key in your Wine installation (it is case sensitve): HKEY_CURRENT_USER\Software\Wine\Direct3D\UseGLSL = "enabled" Here are a few comparison screenshots (note, yes, they should be identical ;-): http://www.cmhousing.net/wine/aniso_arb.png (vanilla wine, or with UseGLSL != "enabled") http://www.cmhousing.net/wine/aniso_glsl.png (using GLSL) http://www.cmhousing.net/wine/grass_arb.png http://www.cmhousing.net/wine/grass_glsl.png http://www.cmhousing.net/wine/dolphin2_glsl.png (DX8 SDK dolphin sample) http://www.cmhousing.net/wine/civ4_glsl.png (not *quite* there yet ;-) In theory, once this all works, we'll be able to support shader model 2.0+, which a lot of newer games either require or strongly suggest (aka prettier graphics). Now, there are plenty of other bugs to be worked out in wined3d, so this isn't the holy grail of patches or anything, but it will take us that much closer to supporting new games. Please lend a hand if you're able to. Thanks! (by the way, many thanks to the entire #winehackers crew for all the help along the way so far, it's been fun)

3 2

Compiling wine on an x86-64 system
by Pavel Troller 30 May '06

30 May '06

Hi! I would like to ask for a help with wine compilation on an x86_64 system. Today I successfully did the compilation, but the result is totally unusable. I've supplied -m32 switch to both CFLAGS and LDFLAGS (I have to specify my own C/LDFLAGS because of custom -I/-L options to find various packages). gcc as well as winegcc correctly generated 32bit output. There was just one error during compilation - it attempted to compile dlls/ntdll/signal_i386.c, which suffered from __NR_sigaction being undefined. Because my kernel headers are set up for a 64bit system, there is not such a define. __NR_rt_sigaction is defined instead. I'm not sure whether it's ok that wine tried to compile this file (it compiled signal_x86_64.c too, with no problems). I also don't know how to hack the kernel includes to define it correctly (I have just vanilla, unmodified set of native kernel headers for 2.6.17-rc5 set up). So I hacked it by copying the appropriate #define from asm-i386/unistd.h kernel header directly to signal_i386.c. wine then compiled and installed without a glitch. However, any attempt to run it ends up with immediate return without any diagnosis. It even doesn't output its usage help. I've already compiled a lot of "normal" programs for 32bit systems on my x86_64 system. However, wine resists. What am I doing wrong ? What's the correct way ? With regards, Pavel Trolle

4 4

server: Return an error for invalid requests instead of killing the client process.
by Mike Hearn 30 May '06

30 May '06

Hi Alexandre, I'm curious as to what the reason behind this change was. I was under the impression an invalid request must always mean a corrupted/destabilised client. Please give me insight! :) thanks -mike

2 1

building win32/wine .exe's
by NikNot 30 May '06

30 May '06

I am running wine (including winelib development packages) un Ubuntu 6.x beta, and I'd like, if possible, to migrate my Win32 development from Win2k to Ubuntu (where most of my development is done). Further to winelib information found in http://www.winehq.org/site/winelib and makefile examples from http://www.computersciencelab.com/Petzold.htm, I came to the conclusion that it should be possible to build, under Linux, a single .exe file that would run under both wine on Linux and on win2k. One of the simplest examples in ...Petzold.htm above (clover.c) can be compiled and linked as: winegcc -c -mno-cygwin clover.c winegcc -o clover.exe clover.o -mno-cygwin -mwindows -lcomctl32 -lcomdlg32 -lwinmm -ladvapi32 -lwinspool Both steps run with no errors, but the result is clover.exe.so and a shell script clover. Either will run under Ubuntu/wine, but .so is of course not a win32 executable. Is my assumption that it is possible to build a win32 executable using winegcc on Linux correct? If yes, I must be missing something rather obvious: any pointer will be appreciated. TIA, Nik N.

1 0