Vega02 wrote: I was considering just adding a daemon executable to the Startup path of whichever user installed the application. Yes, that would be a good approach. Vega02 wrote: Ideally the user could install and run this application without requiring administrator privileges. Also, I want to minimize as much as possible the possibility of cross-communication between clients and daemons running under different user accounts. Running the client piece without admin privs should be relatively simple. Installing without them might cause an issue on Vista. Vega02 wrote: In reality what I have going on is that the client is performing all the work. The client just needs to query the daemon for some state before work can commence, and it needs to tell the daemon how to update the state when the work is complete. When the next client queries the state, the daemon can respond with the updated information. It sounds like the service is really just being used as state management. Vega02 wrote: The problem with a system-wide service is that the daemon can be used quite broadly, and the client might update the state with some private information. If the daemon is used as a day planner, for example, the client might add a personal appointment to the database. This isn't information that should be accessible to any other user of the system. I'm not sure why this would be an issue. If the service is designed right and provides some sort of authentication mechanism between itself and it's clients, client A should never be able to see data from client B. Given the scenario you described, the underlying data store would need to be protected as well. ----------------------------- In just two days, tomorrow will be yesterday.

I've been working on our 2007 model since May 2006, so I've effectively been living in 2007 for 10 months. In about 4 months time, I'll be moving into 2008 :omg:

Well, yeah, but in my case no other thread will ever signal it. Creating a ManualResetEvent and waiting on it to perform an indefinite block - something just feels wrong about doing that. ;P

The CLR will not allow object references to overlap value types using FieldOffset, but it will allow object references to overlap other object references. But I think I just answered my own question. Changing the security permission set to require assembly verification causes the runtime to throw an exception when it tries to load the MyStruct type. Could not load type 'StructLayout.MyStruct' from assembly 'StructLayout, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' because objects overlapped at offset 4 and the assembly must be verifiable. So it looks like the runtime only allows you to do this only if you already had the proper security permission set to execute unsafe code to begin with, which I think should be fine. Still somewhat strange that the peverify utility says that the assembly is verifiable, though.

I think using pinned pointers is better in this case. eg byte[] buffer = new byte[256]; fixed (byte* pbuf = buffer) { // no pbuf will be fixed. You can merribly call subfunctions till the end of the block. } xacc.ide-0.1.1.4 - now with LSharp integration and scripting :)

waaa..tha...foook......!:laugh:

I'll try this - thanks!