October 2006 - Wine-Devel - list.winehq.org

Re: Make.rules.in: Add a new make variable "C_GEN_SRCS" for C files that need to be generated before makedep can be run on them.
by Alexandre Julliard Oct. 5, 2006

Oct. 5, 2006

Robert Shearman <rob(a)codeweavers.com> writes: > This is useful for generated files such as *_i.c and *_p.c (when widl > can generate them). > diff --git a/Make.rules.in b/Make.rules.in > index 9e7ec07..68544dc 100644 > --- a/Make.rules.in > +++ b/Make.rules.in > @@ -8,6 +8,7 @@ # MODULE : name of the module bein > # > # Each individual makefile may define the following additional variables: > # C_SRCS : C sources for the module > +# C_GEN_SRCS : C sources that are generated for the module You shouldn't need that. IDL files will be listed as sources and make depend will be able to handle that properly, just like it handles idl headers already. -- Alexandre Julliard julliard(a)winehq.org

2 4

Compiling Wine on Ubuntu AMD64
by Ryan Walklin Oct. 5, 2006

Oct. 5, 2006

Check this forum thread - http://www.ubuntuforums.org/showthread.php?t=167765 , the original post with my modifications on page 7 lets me build Wine with Freetype and OpenGL - WoW works really well. Good luck, feel free to email or post in the thread if you need any more help

1 0

Mem usage in Mac OSX
by Nick Burns Oct. 5, 2006

Oct. 5, 2006

Im seeing some very odd behaviour in Mac OSX using wine -- and wondered if anyone could enlighten me When I run any application -- I see it start with ~4GB of VM then depending on the app -- it goes upwards of 5.7GB in VM usage (>4GB?) in Activity Monitor (usually because of texture loading or other context loading -- so this is seen in games where you start moving around a map and it starts loading textures into OGL/D3D(->OGL)) Usually when it gets this high -- bad things happen -- basically mallocs start to fail, and the app crashes. I personally dont like the app to crash -- i ha just started playing. So, lets say in GTAVC -- thats me in a heli going from Downtown -> New Haiti == crash. Thats only a few blocks worth of carnage. ---- So, I tested a coule theories -- 1 - Was it bad OGL calls? **No**, the glTexImage calls looked decent -- some even very small (128x128 compressed) 2 - Was it too many mallocs/calloc/reallocs? **No**, none of these were in the GB range... 3 - Finally I found out some very large mmaps/vm_allocates (2x256MB 2x512MB) taking a significant portion of the VM space away from any system libs. I tested this out a bit by printing the mmaps/vm_allocates that I was getting (found the huge 256/512 MB ones) So, in mmap.c:175 -- try_mmap_fixed I put in ' if(len>0x10000000) { printf("len very big -- 0x%08X\n",len); len=0x10000000; } ' to cap the mmaps that i was seeing Yes yes, I realize thats a HORRIBLE thing to do -- but its for the sake of testing and science! This 'cured' my problems in GTAVC -- I no longer crashed (But i would have given enough allocations... or time). My VM usage droped from an initial ~4gb -> ~3gb as I expected I was unable to track down these specific huge allocations... And would like some advice on this situation -- from the sages of Wine... ---- I would like to fix this the correct way I have no idea what happen on Linux in these cases.... - Nick

6 7

[SOLVED] Re: wined3d/CopyRects bug fix
by Christopher GAUTIER Oct. 5, 2006

Oct. 5, 2006

On Fri, Sep 22, 2006, Stefan Dösinger wrote: > So the idea is to find out what the application does and fix the opengl > blitting code :-) After a debugging session, I found out that the cause of the graphical glitch is that the extension GL_REGISTER_COMBINERS_NV was enabled, and it breaks IWineD3DSurface_BltFast. As a conclusion, Stefan's patch should be applied (and mine too :) ), as they fixes graphical issues. I'll post both of them on wine-patch. Cheers, -- krys

1 0

Implementing sxs?
by Dan Kegel Oct. 5, 2006

Oct. 5, 2006

http://bugs.winehq.org/show_bug.cgi?id=5276 and its ilk are becoming increasingly annoying. I marked two more bugs as being blocked by this just now. Presumably more semi-intelligent futzing with the stubs will get us by for a lot of apps, but I wonder: how soon are we going to have to really implement side-by-side assemblies?

2 1

Re: msi [3/12]: Assign the property to path if the property is empty
by Mike McCormack Oct. 5, 2006

Oct. 5, 2006

James Hawkins wrote: > @@ -1456,6 +1456,9 @@ static void msi_dialog_update_pathedit( > prop = msi_dialog_dup_property( dialog, control->property, indirect ); > > path = msi_dup_property( dialog->package, prop ); > + if (!path) > + path = prop; > + > SetWindowTextW( control->hwnd, path ); > SendMessageW( control->hwnd, EM_SETSEL, 0, -1 ); Later on in that code block, it does: msi_free( path ); msi_free( prop ); If path and prop point to the same thing, then we'll try free and illegal pointer. Looks like it would be better to replace msi_dup_property() with another (new) macro function that understands this behavior, rather than changing the code similarly in 4 places. Mike

1 0

Re: KERNEL: honor additional DLL search paths under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths
by Mike McCormack Oct. 5, 2006

Oct. 5, 2006

Alex Villacís Lasso wrote: > Changelog: > * Check under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App > Paths\\EXENAME.EXE for > additional directory locations to search for DLLs. Fixes Dreamweaver MX > 6.0. This change is incorrect. The App Pathes key is checked by ShellExecute, not by CreateProcess. Try running "wine start exename.exe" Mike

3 5

Re: Wine 0.9.21 fails to run
by Ken Zalewski Oct. 4, 2006

Oct. 4, 2006

Hi Nick, Thanks for the advice and patches. However, Wine still fails to run ANY programs at all. This is with both of the patches applied (the "ATI" patch and the "NVidia" patch). Moving back to 0.9.20 makes everything work again. My OpenGL library is from NVidia driver 8774 (the most recent), and x11 is 6.8.2. If there is anything you would like me to provide in order to diagnose this, let me know. Thanks. -kz Nick Law wrote: > Ken Zalewski wrote: >> I just upgraded from 0.9.20 to 0.9.21, and now nothing will run, >> including simple programs such as sol.exe and notepad.exe. >> >> The error message I'm receiving is: >> >> X Error of failed request: BadWindow (invalid Window parameter) >> Major opcode of failed request: 145 (NV-GLX) >> Minor opcode of failed request: 4 () >> Resource id in failed request: 0x242 >> Serial number of failed request: 19 >> Current serial number in output stream: 19 >> >> >> My system is a Slackware 10.2 system, running kernel 2.6.17.13, x11 >> 6.8.2, and NVidia driver 8774. >> >> I have seen some other postings on the Net about this, including >> postings in the Ubuntu forums (which means that this is not limited >> to Slackware). >> >> Downgrading to 0.9.20 gets everything working again. My guess, based >> on the "NV-GLX" message, is that something was changed in the OpenGL >> support between 0.9.20 and 0.9.21, and it has broken Wine. >> >> I'll be happy to help debug this. >> >> Sincerely, >> >> Ken Zalewski >> Slackware package maintainer >> Linuxpackages.net >> >> >> >> >> > That's correct, on the wow 1.12 AppDB page in the latest news section > you'll find two patches, the patch marked ATI ( or FBconfigregression > ) will fix the opengl & D3D problems. > > You can download and apply both irrespective of what graphics card you > have. > > Regards > Nick Law >

2 2

Re: wined3d: Report the correct number of available 4-component float vectors for GLSL
by Mirek Oct. 4, 2006

Oct. 4, 2006

This patch caused regresion in Half-Life 2 Episode One, if i have "UseGLSL"="enabled" HalfLife 2 Episode One crash about 20 seconds after start and menu page is completly white! Only the second part (second gl_max /= 4;) is the bad one, with first part evrything works well. Mirek H. Verbeet napsal(a): > GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB and > GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB return the number of available > uniform components. A 4-component float vector need 4 uniform > components. > > Changelog: > - Report the correct number of available 4-component float vectors for > GLSL > > > ------------------------------------------------------------------------ > > --- > > dlls/wined3d/directx.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index fdde6ea..0e61c67 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -546,6 +546,7 @@ #undef USE_GL_FUNC > } else if (strcmp(ThisExtn, "GL_ARB_fragment_shader") == 0) { > gl_info->supported[ARB_FRAGMENT_SHADER] = TRUE; > glGetIntegerv(GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB, &gl_max); > + gl_max /= 4; > TRACE_(d3d_caps)(" FOUND: ARB_fragment_shader (GLSL) support - max float ps constants=%u\n", gl_max); > gl_info->ps_glsl_constantsF = gl_max; > } else if (strcmp(ThisExtn, "GL_ARB_imaging") == 0) { > @@ -618,6 +619,7 @@ #undef USE_GL_FUNC > } else if (strcmp(ThisExtn, "GL_ARB_vertex_shader") == 0) { > gl_info->supported[ARB_VERTEX_SHADER] = TRUE; > glGetIntegerv(GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB, &gl_max); > + gl_max /= 4; > TRACE_(d3d_caps)(" FOUND: ARB_vertex_shader (GLSL) support - max float vs constants=%u\n", gl_max); > gl_info->vs_glsl_constantsF = gl_max; > } else if (strcmp(ThisExtn, "GL_ARB_vertex_blend") == 0) { > > > ------------------------------------------------------------------------ > >

3 16

Re: oleaut32 1/2: [try 3] Implements function varformat:VarWeekdayName
by Alexandre Julliard Oct. 4, 2006

Oct. 4, 2006

"Benjamin Arai" <me(a)benjaminarai.com> writes: > + if (fAbbrev) > + if (iFirstDay == 0) > + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + LOCALE_IFIRSTDAYOFWEEK - 1) % 7); > + else > + localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); > + else > + if (iFirstDay == 0) > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + LOCALE_IFIRSTDAYOFWEEK - 1) % 7); > + else > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); This obviously can't work, LOCALE_IFIRSTDAYOFWEEK is a constant. -- Alexandre Julliard julliard(a)winehq.org

1 0