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

RE: check box in group box regression

by Zach Gorman

Is this a general problem, or just in the hour.exe example? Is there source for hour.exe? Zach -----Original Message----- From: wine-devel-admin(a)winehq.org [mailto:wine-devel-admin(a)winehq.org] On Behalf Of Robert Reif Sent: Tuesday, August 24, 2004 8:02 AM To: Wine Develop Subject: check box in group box regression With current cvs, check boxes in group boxes are no longer displayed. See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html

Aug. 24, 2004

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)

by Mike McCormack

Alexander Yaworsky wrote: > I even tried to submit a patch but it was silently ignored. Let me remind about this patch -- > http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe it will be useful. If you have suggestions, I promise to > rewrite it as required ;)) Hi Alexandre, Your patch is very large. It's difficult to find regressions in large patches, and it's difficult to review as so much code is changed. It may be all perfectly correct, but it's not obviously perfectly correct :) I'd suggest that you resubmit the patch and break it up into smaller chunks, so that as much as possible, each one is easy to review and makes a small understandable, atomic and necessary change. Test cases also help, if you can write them. From the looks of things your patch is well researched, and you understand what you're doing. If you submit your work in smaller chunks, I'm pretty sure it will be accepted. Mike

Aug. 24, 2004

check box in group box regression

by Robert Reif

With current cvs, check boxes in group boxes are no longer displayed. See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html

Aug. 24, 2004

Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by Mike Hearn

>>Well, apparently we don't use sched_yield, so the problem must >>> lie somewhere else. Maybe Con can help us out here? Alexandre says he >>> doesn't know what the issue is either and somebody needs to investigate. I >>> guess we do need to concern ourselves over the details :) > > > Interesting. Probably the most valuable information is that it seems to > work fine if we artificially limit the threads to exactly the same > timeslice _or_ we put them at such a low priority that they are forced > to be guaranteed to round robin one task at a time. This is the way 2.4 > used to work which is why with the new 2.6 schedulers which do far more > out-of-order rescheduling some applications have a problem; particularly > under load. I suspect it's actually the latter issue. Locking between > threads should prevent that being a problem, though. You already > mentioned that you dont use sched_yield() and I couldn't even begin to > look at the wine code myself so perhaps you know something more. Hi Con, One thought that occurred to me, and this is just a random theory, is that maybe the issue is not with the Wine code but the Win32 code run on top of it. Do you know how 2.6 scheduling compares with 2.4 and Windows (NT) scheduling? Could it be that some apps are written to expect Windows-style scheduling and fail to work if they don't get it? In case you hadn't noticed, I'm afraid I only have first-year CS knowledge of scheduling :/ thanks -mike

Aug. 24, 2004

Re: A new regression

by Lionel Ulmer

On Tue, Aug 24, 2004 at 09:37:58AM +0100, Mike Hearn wrote: > For those following along, translated that means: fix that works all the > time blocks on the window management 'rewrite' which means we use X > windows only for toplevels. Last I heard this rewrite was about 2-3 > months away from completion but obviously it's not a fixed thing and > could easily take longer. Note that this will break even more all the non-fullscreen OpenGL applications pending adaptation of the GL code to support GL rendering on non-top level windows. >From what I expect, this may not be trivial at all. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 24, 2004

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)

by Alexander Yaworsky

Hello > Dont take offence if your patch goes to the void. Just resubmit after a > a week to give it a chance to filter through Alexandre's tree. Its > possible either I merely meant that maybe something wrong with implementation. Well, I will resubmit it soon.

Aug. 24, 2004

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)

by Shachar Shemesh

Steven Edwards wrote: >Hi Alexander, > >--- Alexander Yaworsky <yaworsky(a)migusoft.ru> wrote: > > >>I even tried to submit a patch but it was silently ignored. Let me >>remind about this patch -- >>http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe >>it will be useful. If you have suggestions, I promise to >>rewrite it as required ;)) >> >> > >Dont take offence if your patch goes to the void. Just resubmit after a >a week to give it a chance to filter through Alexandre's tree. Its >possible either > >1. He is going to merge it and its just taken him a while >2. He rejected it and just forgot to send a note due to the constrants >of time. >3. It went to the void in space where the lost patches go. > >Just resubmit and you should hear something back from someone. > >Thanks >Steven > > Actually, during the last wineconf, "There's nothing obviously wrong with it, but it makes Alexandre uneasy" for the usual reason patches go to void Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 24, 2004

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)

by Steven Edwards

Hi Alexander, --- Alexander Yaworsky <yaworsky(a)migusoft.ru> wrote: > I even tried to submit a patch but it was silently ignored. Let me > remind about this patch -- > http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe > it will be useful. If you have suggestions, I promise to > rewrite it as required ;)) Dont take offence if your patch goes to the void. Just resubmit after a a week to give it a chance to filter through Alexandre's tree. Its possible either 1. He is going to merge it and its just taken him a while 2. He rejected it and just forgot to send a note due to the constrants of time. 3. It went to the void in space where the lost patches go. Just resubmit and you should hear something back from someone. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

Aug. 24, 2004

Re: A new regression

by Mike Hearn

> The problem is that the app uses OpenGL for painting, and OpenGL > doesn't support the IncludeInferiors clipping mode. Fixing that > properly will require getting rid of X windows for child windows, but > in the meantime I have added a workaround that should work in most > cases. For those following along, translated that means: fix that works all the time blocks on the window management 'rewrite' which means we use X windows only for toplevels. Last I heard this rewrite was about 2-3 months away from completion but obviously it's not a fixed thing and could easily take longer. The reason it's being taken slowly is exactly so these sort of regressions can be shaken out. In the absence of branching it's the only way. thanks -mike

Aug. 24, 2004

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)

by Alexander Yaworsky

Hello In fact, the existing implementation of service subsystem in advapi32 is very poor and is sufficient only for very simple services or test programs. I tried to launch oracle 7 database under wine and that trial has been failed. The main problem was inability of parameter passing. Not only oracle -- most services require that. I did some improvements. Although I still cannot start database, because its launcher, oradim, requires CreateRemoteThread, the listener service works well (although, it cannot be fully tested because no database instance exists, but there is nothing suspicious in trace logs). I even tried to submit a patch but it was silently ignored. Let me remind about this patch -- http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe it will be useful. If you have suggestions, I promise to rewrite it as required ;)) Also, maybe the diagram shown below will be useful. Thanks. This simplified diagram shows interaction between three main components of win32 service subsystem. Service Control | Service Control Manager | Service Program Program | | ----------------+-----------------------------+----------------------------- | | StartService-----> LockServiceDatabase | | IF OWN_PROCES or | | (SHARE_PROCESS and Service | Program is not running)| | THEN | | | | CreateProcess===============> ... | wait for call to | initialization | StartServiceCtrlDispatcher| must not be longer | timeout=30s | than 30 seconds | | ... | if wait timed out then | ... | TerminateProcess | ... failure <---- UnlockServiceDatabase | ... | | ... | wait satisfied <============= StartServiceCtrlDispatcher | | | END IF | | | | CreateThread ***************> ServiceMain | (or CreateRemoteThread | ... | for SHARE_PROCESS; | * | if SHARE_PROCESS then | * | find entry in service | ********************** | table by service name; | * | if OWN_PROCESS then use | * | first entry) | * success <---- UnlockServiceDatabase | * | | * | accept control requests | * | | * ControlService---> request accepted ===========> ServiceControlHandler * | | ... * status <----- return status <============== SetServiceStatus * | | * | | * | | ********************** | | * | | ... | | SetServiceStatus | ExitThread <***************** (STOPPED) | if Service Program has | | now only one thread | | return control from | | StartServiceCtrlDispatcher==> ... | | ExitProcess legend: --- Service Control Program's thread === Service Program's main thread (control thread) *** Service Program's service thread OWN_PROCESS == SERVICE_WIN32_OWN_PROCESS SHARE_PROCESS == SERVICE_WIN32_SHARE_PROCESS Implementation. completely win32-based Two basic things: a) The only time the service control manager requests ownership of the lock is when it is starting a service. (C) M$DN; b) When StartService creates a new service process, it must pass arguments, or at least argv[0] - the service name - for ServiceMain across process boundary. So, use the existence of shared memory object as lock indicator and the content of object for passing service name. Also we need a wait object for monitoring process startup. The call to StartServiceCtrlDispatcher will satisfy wait condition. A dedicated shared memory object is used for each service thread. It holds other arguments, control requests and status. Also we need mutex object for serialization of control requests and two wait objects for serialization of service control program thread and service control handler thread.

Aug. 24, 2004