Re: Support remote operations in wineserver
"Alexander Yaworsky" <yaworsky(a)migusoft.ru> writes:
Hello
I guess that original patch was too large. I sent small pieces of it and they have been committed; however it seems that this part cannot be downsized.
Well, I'm not going to commit that part since it doesn't actually do anything with the remote operation, and it's not clear at all that the requests you added will be appropriate to whatever mechanism we use to do the remote operation. -- Alexandre Julliard julliard(a)winehq.org
Hello
Well, I'm not going to commit that part since it doesn't actually do anything with the remote operation, and it's not clear at all that the requests you added will be appropriate to whatever mechanism we use to do the remote operation.
Ok, here is a draft working implementation of NtAllocateVirtualMemory. There are four mechanisms at all: signals, ptrace, service thread and wait. This implementation uses so-called wait approach: request is passed via wait_fd. The drawback is that request may not always be handled but most sane applications sooner or later fall into wait state. Also i'm going to try other mechanisms but their implementations seem will be very similar. I hope that people will give suggestions.
Hello, --- Alexander Yaworsky <yaworsky(a)migusoft.ru> wrote:
Ok, here is a draft working implementation of NtAllocateVirtualMemory. There are four mechanisms at all: signals, ptrace, service thread and wait. This implementation uses so-called wait approach: request is passed via wait_fd. The drawback is that request may not always be handled but most sane applications sooner or later fall into wait state. Also i'm going to try other mechanisms but their implementations seem will be very similar.
Sorry but I dont understand the need of remote operations in Wineserver. Are you going to be adding support for remote starting of services using RPC like Windows does via "net start" or something like that? Thanks Steven _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
Hello
Sorry but I dont understand the need of remote operations in Wineserver.
They provide another kind of interprocess communications. We should force another process to execute desired operation. Added requests help to supply parameters and obtain the result. If we would use service thread (that was removed from wine long ago, do not mix with service thread i'm going to introduce in service subsystem), win32 api would be enough.
Are you going to be adding support for remote starting of services using RPC like Windows does via "net start" or something like that?
No. Services is another story. I'm not going to use RPC as windows does. Now it's essential to get local services working and RPC will only obstruct the code.
"Alexander Yaworsky" <yaworsky(a)migusoft.ru> writes:
Ok, here is a draft working implementation of NtAllocateVirtualMemory. There are four mechanisms at all: signals, ptrace, service thread and wait. This implementation uses so-called wait approach: request is passed via wait_fd. The drawback is that request may not always be handled but most sane applications sooner or later fall into wait state. Also i'm going to try other mechanisms but their implementations seem will be very similar.
The main problem is that you can't make any assumption on the state of the process, so you definitely cannot rely on it making a wait call. Also you cannot do anything that requires taking a lock, so you are basically limited to doing straight system calls in the remote operation. That will probably require some restructuring of the existing code, especially the memory management part. -- Alexandre Julliard julliard(a)winehq.org
participants (4)
-
Alexander Yaworsky -
Alexandre Julliard -
Mike Hearn -
Steven Edwards