November 2007 - Wine-Devel - list.winehq.org

Re: Problem with client manually starting services

by Roy Shea

On Thu, Nov 08, 2007 at 12:21:42PM -0800, Roy Shea wrote: > On Thu, Nov 08, 2007 at 12:00:28PM +0000, Robert Shearman wrote: > > Roy Shea wrote: > > >Howdy All, > > > > > >I'm developing missing services in Wine and am running into problems > > >with how Wine starts services. In Windows a service can be started > > >using "net start <service name>", assuming that the service is > > >properly added to the registry. In Wine it appears that the user must > > >manually start the service before calling "net start <service name>", > > >or the service fails to start. > > > > What makes you think that? There are quite a few programs, including > > InstallShield, that start their own services without the process being > > started beforehand. > > You could start with pulling +advapi,+relay log of "net start" executing > > to try to figure out what is going wrong. My guess would be that either > > svchost or the DLL isn't notifying the SCM of its started status. > > > > -- > > Rob Shearman > > Further testing shows that a server process actually is started by > Wine. Good! What set me off on this goose chase was the output > generated when I tried to start a process: > > ---- > $ ./programs/net/net start count_server > The count_server service is starting. > The count_server service failed to start. > ---- > > Despite the notice that the service failed to start, it is happily up > and running. A similar test for services started via svchost reveal > the same behavior; the service starts but "net" says that it did not > start. > > Debug logs with +advapi,+relay looked odd. In particular, > StartServiceW returns 0 (failure) triggering the error message from > net. I dug into this and it looks like the problem is in either > "service_start_process" in dlls/advapi32/service.c or "CreateProcessW" > in dlls/kernel32/process.c. > > The call to WaitForMultilpeObjectsEx from service_start_process fails > because the handle for the freshly created process is invalid. This > triggers the error message from net. This invalid process handle is > the result of CreateProcessW not setting process information when a > process started is a BINARY_UNIX_EXE. > > Should process info be set when a BINARY_UNIX_EXE processes is > created? > > Peace, > -Roy Okay, a little more information on this. The above email is specific to registry settings using the "wrapped" version of the executable. Ie. Specifying the symbolic link to winewrapper (named after the executable and created by make) in the reigstry rather than test_service.exe. Specifying test_service.exe in the registry causes the service to fail since CreateProcessW is unable to locate the file. Finally, setting the registry value to svchost.exe.so works without any errors. Unfortunately, this last version is not compatible with Windows registry configurations. CreateProcessW already preforms a search for the binary it is starting. Perhaps we could have it also look for a binary ending in ".so". Peace, -Roy

Nov. 8, 2007

Re: WineD3D: flush gl buffers are blt to drawable [attempt2]

by Stefan Dösinger

Am Donnerstag, 8. November 2007 23:40:18 schrieb Roderick Colenbrander: > Hi, > > This patch makes sure the gl buffer is flushed after blitting to the > screen. This fixes bug 9826 where traces of old frames appeared due to > this. You really shouldn't do this unconditionally, it is only needed if two contexts are drawing to the same drawable. A suggestion would be to mark the first use of a 2nd thread in a device in FindContext, and call the glFlush only if happened. The same glFlush is needed in all other places that draw something to the drawable: drawprim, clear and BltOverride come to my mind.

Nov. 8, 2007

Re: [1/6] WineD3D: Only glBindAttribLocation used attributes

by Stefan Dösinger

Am Donnerstag, 8. November 2007 22:54:49 schrieb Mirek Slugeň: > You can easily test performance with Nvidia SDK demo > AntiAliasingWithTransparency.exe not every game or application is affected > by this regression. Every affected application is using PS 3.0 (NFS > ProStreet, Call of Duty 4, Unreal Tournament 3). I found the problem, patch sent. Thanks for the constant testing work.

Nov. 8, 2007

Re: [1/6] WineD3D: Only glBindAttribLocation used attributes

by Mirek Slugeň

Nov. 8, 2007

Re: [1/6] WineD3D: Only glBindAttribLocation used attributes

by Stefan Dösinger

Am Donnerstag, 8. November 2007 22:54:49 schrieb Mirek Slugeň: > Stefan Dösinger napsal(a): > It is caused by those patches (they depends on each other): > > [2/6] WineD3D: Make pixel shader input an array > [3/6] WineD3D: Pixel Shader varying indexing > [4/6] WineD3D: Add a max varyings member to the gl info structure > [5/6] WineD3D: Handle ps 3.0 varyings in a different way > > You can easily test performance with Nvidia SDK demo > AntiAliasingWithTransparency.exe not every game or application is affected > by this regression. Every affected application is using PS 3.0 (NFS > ProStreet, Call of Duty 4, Unreal Tournament 3). I guess only the last patch finally "activates" the slowdown, right? It sounds like a fallback to software rendering by the driver. I thought the driver's shader optimizer can sort out issues like that, apparently this is not the case everywhere. What GPU do you have?

Nov. 8, 2007

Re: [1/6] WineD3D: Only glBindAttribLocation used attributes

by Mirek Slugeň

Nov. 8, 2007

Re: Problem with client manually starting services

by Roy Shea

On Thu, Nov 08, 2007 at 12:00:28PM +0000, Robert Shearman wrote: > Roy Shea wrote: > >Howdy All, > > > >I'm developing missing services in Wine and am running into problems > >with how Wine starts services. In Windows a service can be started > >using "net start <service name>", assuming that the service is > >properly added to the registry. In Wine it appears that the user must > >manually start the service before calling "net start <service name>", > >or the service fails to start. > > What makes you think that? There are quite a few programs, including > InstallShield, that start their own services without the process being > started beforehand. > You could start with pulling +advapi,+relay log of "net start" executing > to try to figure out what is going wrong. My guess would be that either > svchost or the DLL isn't notifying the SCM of its started status. > > -- > Rob Shearman Further testing shows that a server process actually is started by Wine. Good! What set me off on this goose chase was the output generated when I tried to start a process: ---- $ ./programs/net/net start count_server The count_server service is starting. The count_server service failed to start. ---- Despite the notice that the service failed to start, it is happily up and running. A similar test for services started via svchost reveal the same behavior; the service starts but "net" says that it did not start. Debug logs with +advapi,+relay looked odd. In particular, StartServiceW returns 0 (failure) triggering the error message from net. I dug into this and it looks like the problem is in either "service_start_process" in dlls/advapi32/service.c or "CreateProcessW" in dlls/kernel32/process.c. The call to WaitForMultilpeObjectsEx from service_start_process fails because the handle for the freshly created process is invalid. This triggers the error message from net. This invalid process handle is the result of CreateProcessW not setting process information when a process started is a BINARY_UNIX_EXE. Should process info be set when a BINARY_UNIX_EXE processes is created? Peace, -Roy

Nov. 8, 2007

Re: [1/6] WineD3D: Only glBindAttribLocation used attributes

by Stefan Dösinger

Am Donnerstag, 8. November 2007 20:12:48 schrieb Mirek Slugeň: > Hi, there is big performance drop in some games (NFS ProStreet) with your > latest patches (exactly this set), do you know why? Should I do some > regression testing and find critical patch? A regression test would be nice indeed.

Nov. 8, 2007

Re: [1/6] WineD3D: Only glBindAttribLocation used attributes

by Mirek Slugeň

Nov. 8, 2007

Typing Chinese Online On FireFox

by Jiang,Yi

I developped a site for Typing Chinese Online: http://www.typingChinese.com. It works on FireFox, IE, Mac. On test, I found FireFox is the fastest and used much less memory! Regards to all, Jiang,Yi

Nov. 8, 2007