July 2007 - Wine-devel - list.winehq.org

Interesting bit on schedulers and Wine
by Juan Lang 31 Jul '07

31 Jul '07

Sorry for the spam. There's been a flame^H^H^H^H^Hthread over on lkml about CFS and SD schedulers, and Ingo's tested Quake3 on Wine using both: http://kerneltrap.org/node/14023 Someone else tested UT2004 with both as well, and there are pretty pictures: http://people.redhat.com/mingo/misc/cfs-vs-sd-wine-quake.jpg http://people.redhat.com/mingo/misc/cfs-sd-ut2004-perf.jpg Happy hacking, --Juan

1 0

About new environment variable
by Zhongli Xu 31 Jul '07

31 Jul '07

After I add an environment avriable in the system.reg file, e.g. [System\\CurrentControlSet\\Control\\Session Manager\\Environment] 1185851455 "MY_VARIABLE"="VALUE" I tried to read this variable thru the API GetEnvironmentVariable(), but it failed. Other variables, such as PATH, OS, are OK. Any idea is welcomed.

4 3

Re: [PATCH 3/5] winecfg: Make winecfg resources compilable by a Windows resource compiler
by Steven Edwards 31 Jul '07

31 Jul '07

On 7/30/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Subject: [PATCH 3/5] winecfg: Make winecfg resources compilable by a Windows resource compiler In this case do you mean windres or rc? I ask because if its rc then shouldn't we fix wrc to not accept these sources also? If its windres thats broken I think there is a workaround for the problem. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

4 13

Re: dpnlobby.dll implementation
by Maarten Lankhorst 31 Jul '07

31 Jul '07

Luis C. Busquets Pérez schreef: > File that just forwards one function included for compatibility issues Hi, I think you're missing a few files here, are you sure you've added the files from dlls/dpnlobby? Cheers, Maarten

1 0

Re: update of msvcrt.spec
by Dmitry Timoshkov 31 Jul '07

31 Jul '07

"Luis C. Busquets PÃ©rez" <luis.busquets(a)ilidium.com> wrote: > This patch updates the msvcrt.spec and adds the version number of the > product. Note that with the same file version number there are various > product version number files. msvcrt in Windows doesn't export APIs you have added by ordinal. Also there is no need to shuffle existing entries around. -- Dmitry.

1 0

Re: WineD3D: compile against standard GL headers [attempt3]
by H. Verbeet 31 Jul '07

31 Jul '07

On 31/07/07, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > In this version I have also added the prototype for the ARB multisample > extension. > Did you attach the wrong patch?

1 0

Re: user32: erase parent when hiding child
by Dmitry Timoshkov 31 Jul '07

31 Jul '07

"Clinton Stimpson" <cjstimpson(a)utwire.net> wrote: > ChangeLog: > user32: erase parent when hiding child As I already pointed out erasing a parent is supposed to be done in the server. You need to look there why it doesn't happen and add a fix there. -- Dmitry.

2 1

Re: WineD3D: compile against standard GL headers [attempt2]
by H. Verbeet 31 Jul '07

31 Jul '07

On 31/07/07, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > This is the second version of this patch. As Henri suggested extensions are > now defined to 1 and GL_EXT_LEGACY has been set too. > That's better, but you're still missing the functions for GL_ARB_multisample and GL_EXT_vertex_weighting. Since GL_EXT_vertex_weighting can be removed completely that would effectively only be a single function, glSampleCoverageARB.

1 0

Re: WineD3D: compile against standard GL headers
by H. Verbeet 31 Jul '07

31 Jul '07

On 31/07/07, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > This patch allows WineD3D to build against a standard GL.h and removes the > dependency on glext.h. This is useful for building WineD3D against > opengl32.dll. > > Regards, > Roderick Colenbrander > - You should #define the extensions to 1, like it's done for the other extensions. eg. #ifndef GL_NV_texture_env_combine4 #define GL_NV_texture_env_combine4 1 ... #endif - GL_ARB_multisample & GL_EXT_vertex_weighting also define new functions, you should add those as well. - If you're going to remove the glext.h include, you should also #define GL_GLEXT_LEGACY, or gl.h will potentially pull it in by itself. - You should also remove the GL_GLEXT_PROTOTYPES define, it should only be used by glext.h

2 1

[setupapi/tests] Any reason why we do a GetProcAddress for the functions?
by Paul Vriens 31 Jul '07

31 Jul '07

Hi, Is there any reason we do a GetProcAddress for the setupapi functions used in the setupapi tests? It look like they are exported properly on win95 until Vista. Or is it just because the first patch for these tests did LoadLibrary/GetProcAddress so the rest followed? Although most of the tests do a GetProcAddress, the result is actually never checked (neither in the init phase nor before calling a function). (We also do a LoadLibrary where the library is already imported, so GetModuleHandle seems more appropriate anyway). Anyone? Cheers, Paul.

1 0