March 2014 - Wine-Devel - list.winehq.org

Re: schedsvc: Add Task Scheduler service. Try 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> >> I also don't think that this limited usefulness justifies the cost of >> >> >> running the service in every single Wine session. It should be started >> >> >> only when there are actually tasks to schedule. >> >> > >> >> > The service also has a role of global xml task definitions storage, so >> >> > that any client application could add or query task status, or check >> >> > and change the task running state, and that's impossible to do without >> >> > a service, similar to the functionality provided by services.exe. >> >> >> >> Sharing global state doesn't imply a service, there are many other >> >> ways. That doesn't mean we can't have a service, but it doesn't justify >> >> having it run in every Wine session. >> > >> > How the tasks I described already could be performed without a service? >> >> There are plenty of ways to share global state, I'm sure you can think >> of a few yourself. Again, I'm not saying we can't have a service at all; >> but you need to find a way to not add extra cost to every single session >> for the sake of a few rare cases. > > Would starting the service from taskschd.dll when an application calls > ITaskService::Connect() be a viable compromise? Of course that would mean > that the scheduled tasks will be added to the queue only when the service > is running. If there are scheduled tasks then it's OK for the service to be running always; but as long as there aren't, it should be started on-demand. -- Alexandre Julliard julliard(a)winehq.org

March 6, 2014

Re: schedsvc: Add Task Scheduler service. Try 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> I also don't think that this limited usefulness justifies the cost of > >> >> running the service in every single Wine session. It should be started > >> >> only when there are actually tasks to schedule. > >> > > >> > The service also has a role of global xml task definitions storage, so > >> > that any client application could add or query task status, or check > >> > and change the task running state, and that's impossible to do without > >> > a service, similar to the functionality provided by services.exe. > >> > >> Sharing global state doesn't imply a service, there are many other > >> ways. That doesn't mean we can't have a service, but it doesn't justify > >> having it run in every Wine session. > > > > How the tasks I described already could be performed without a service? > > There are plenty of ways to share global state, I'm sure you can think > of a few yourself. Again, I'm not saying we can't have a service at all; > but you need to find a way to not add extra cost to every single session > for the sake of a few rare cases. Would starting the service from taskschd.dll when an application calls ITaskService::Connect() be a viable compromise? Of course that would mean that the scheduled tasks will be added to the queue only when the service is running. -- Dmitry.

March 6, 2014

Re: [PATCH] wined3d: Decouple private data from the resource structure (try 4).

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > This supersedes patch 103000. > > Try 4: Replace a leftover return E_OUTOFMEMORY with return FALSE. > > Try 3: Move this out of wined3d and wined3d.h and use its own header > with inline functions. This is to avoid COM-related code inside wined3d > among other reasons. I don't think that justifies adding a new global header. -- Alexandre Julliard julliard(a)winehq.org

March 6, 2014

Re: schedsvc: Add Task Scheduler service. Try 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> > Well, I've been thinking of it, and a Wine session lifetime could be >> >> > considered as a short-living Windows machine, with all the limitations. >> >> > And there are a lot of various things that the task scheduler is able >> >> > to do that I don't know how could be mapped say into cron for instance, >> >> > like executing a COM handler, or supporting many kinds of triggers. >> >> > >> >> > There are many known use cases for the task scheduler like a task >> >> > regularly checking for updates, or a task executed on user logon, >> >> > or a task being executed on a network connection. For a list of >> >> > various tasks you could check system32\tasks on any Vista+ system, >> >> > there are pretty interesting examples in there. >> >> >> >> I still think this needs more thought. Having triggers that only happen >> >> while some other random Windows app is running doesn't strike me as >> >> particularly useful. >> > >> > Well, that's how it's supposed to work actually, just like a scheduled >> > cron job for instance. >> >> A scheduled cron job runs no matter what the user is doing. > > That was just a plain analogy, I'm sure that there are other ways to > describe the task scheduler activities. The point is that if you schedule a task to run say on new network connections, it's supposed to happen on all new connections. If it's a Wine service, it would happen while the user is working with PowerPoint, but not when he's working with LibreOffice. That doesn't make sense from the user's standpoint. >> >> I also don't think that this limited usefulness justifies the cost of >> >> running the service in every single Wine session. It should be started >> >> only when there are actually tasks to schedule. >> > >> > The service also has a role of global xml task definitions storage, so >> > that any client application could add or query task status, or check >> > and change the task running state, and that's impossible to do without >> > a service, similar to the functionality provided by services.exe. >> >> Sharing global state doesn't imply a service, there are many other >> ways. That doesn't mean we can't have a service, but it doesn't justify >> having it run in every Wine session. > > How the tasks I described already could be performed without a service? There are plenty of ways to share global state, I'm sure you can think of a few yourself. Again, I'm not saying we can't have a service at all; but you need to find a way to not add extra cost to every single session for the sake of a few rare cases. -- Alexandre Julliard julliard(a)winehq.org

March 6, 2014

Re: schedsvc: Add Task Scheduler service. Try 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > Well, I've been thinking of it, and a Wine session lifetime could be > >> > considered as a short-living Windows machine, with all the limitations. > >> > And there are a lot of various things that the task scheduler is able > >> > to do that I don't know how could be mapped say into cron for instance, > >> > like executing a COM handler, or supporting many kinds of triggers. > >> > > >> > There are many known use cases for the task scheduler like a task > >> > regularly checking for updates, or a task executed on user logon, > >> > or a task being executed on a network connection. For a list of > >> > various tasks you could check system32\tasks on any Vista+ system, > >> > there are pretty interesting examples in there. > >> > >> I still think this needs more thought. Having triggers that only happen > >> while some other random Windows app is running doesn't strike me as > >> particularly useful. > > > > Well, that's how it's supposed to work actually, just like a scheduled > > cron job for instance. > > A scheduled cron job runs no matter what the user is doing. That was just a plain analogy, I'm sure that there are other ways to describe the task scheduler activities. > >> I also don't think that this limited usefulness justifies the cost of > >> running the service in every single Wine session. It should be started > >> only when there are actually tasks to schedule. > > > > The service also has a role of global xml task definitions storage, so > > that any client application could add or query task status, or check > > and change the task running state, and that's impossible to do without > > a service, similar to the functionality provided by services.exe. > > Sharing global state doesn't imply a service, there are many other > ways. That doesn't mean we can't have a service, but it doesn't justify > having it run in every Wine session. How the tasks I described already could be performed without a service? -- Dmitry.

March 6, 2014

Re: [PATCH 1/5] wined3d: Decouple private data from the resource structure (try 3).

by Stefan Dösinger

Am 06.03.2014 um 13:13 schrieb Henri Verbeet <hverbeet(a)gmail.com>: > On 6 March 2014 10:42, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> +static inline BOOL wined3d_private_store_set_private_data(struct wined3d_private_store *store, >> + const GUID *guid, const void *data, DWORD data_size, DWORD flags) > ... >> + return E_OUTOFMEMORY; > That's pretty ugly. Oops, yes :-( . I missed that when I changed things to BOOL.

March 6, 2014

Re: schedsvc: Add Task Scheduler service. Try 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > Well, I've been thinking of it, and a Wine session lifetime could be >> > considered as a short-living Windows machine, with all the limitations. >> > And there are a lot of various things that the task scheduler is able >> > to do that I don't know how could be mapped say into cron for instance, >> > like executing a COM handler, or supporting many kinds of triggers. >> > >> > There are many known use cases for the task scheduler like a task >> > regularly checking for updates, or a task executed on user logon, >> > or a task being executed on a network connection. For a list of >> > various tasks you could check system32\tasks on any Vista+ system, >> > there are pretty interesting examples in there. >> >> I still think this needs more thought. Having triggers that only happen >> while some other random Windows app is running doesn't strike me as >> particularly useful. > > Well, that's how it's supposed to work actually, just like a scheduled > cron job for instance. A scheduled cron job runs no matter what the user is doing. >> I also don't think that this limited usefulness justifies the cost of >> running the service in every single Wine session. It should be started >> only when there are actually tasks to schedule. > > The service also has a role of global xml task definitions storage, so > that any client application could add or query task status, or check > and change the task running state, and that's impossible to do without > a service, similar to the functionality provided by services.exe. Sharing global state doesn't imply a service, there are many other ways. That doesn't mean we can't have a service, but it doesn't justify having it run in every Wine session. -- Alexandre Julliard julliard(a)winehq.org

March 6, 2014

Re: [3/3] ws2_32/tests: Get rid of the do_oob_send helper function

by Bruno Jesus

On Wed, Mar 5, 2014 at 10:24 PM, Marvin <testbot(a)winehq.org> wrote: > === wvistau64 (64 bit sock) === > sock: unhandled exception c0000005 at 000007FEFF0720C0 > > === w2008s64 (64 bit sock) === > sock: unhandled exception c0000005 at 000007FEFE4220C0 It looks like the crashes are not related to WSACleanup then... I don't have any idea then... Maybe valgrind can help finding a leak or something like that. It didn't happen in the old testbot but I'm not sure these Windows versions where present there. Regards, Bruno

March 6, 2014

Re: [PATCH 1/5] wined3d: Decouple private data from the resource structure (try 3).

by Henri Verbeet

On 6 March 2014 10:42, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static inline BOOL wined3d_private_store_set_private_data(struct wined3d_private_store *store, > + const GUID *guid, const void *data, DWORD data_size, DWORD flags) ... > + return E_OUTOFMEMORY; That's pretty ugly.

March 6, 2014

Re: [PATCH 1/1] d3d9/tests: Use create_device() in more tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5436 Your paranoid android. === build (build) === Patch failed to apply

March 6, 2014