Strange behavior

Hi All! It's been a LONG time since I've written to the list, but I've been busy scripting in REBOL ever since I worked at REBOL ('98 through '01). I'm working on a (hopefully) commercial project, but I'm having a really tough time. I'm using SDK-276. Here's a rundown of the project: There is an "agent" component that is an encapped REBOL script, and its job is to start as a service when the computer starts. Its only job is to babysit another encapped REBOL script called the "client". If the client locks up or quits unexpectedly, the agent kills any locked processes and restarts the client. If the agent locks up or quits unexpectedly, the client kills any locked processes and restarts the agent. The client polls a file for any new instructions to perform, and if found, it performs them. This file could contain any REBOL commands, including 'call. The agent starts up fine, and it will restart the client when needed. The client restarts the agent when needed. This is OK. However, the problem comes when the client needs to open a window of any sort (could be another executable using 'call, it could be a REBOL window, etc.). The executable that the client calls will usually execute, but the window will not appear most of the time. Sometimes, there will be a minimized window in the tray, but it cannot be maximized. Sometimes, there will be no window at all, but the executable will appear in the task manager. Any ideas? Also, I've tried having both the agent and the client bring up a window the first thing, but only the agent or the client's window will appear, not both. Thanks for your suggestions! -Bo

Bo There is an issue with the 'call command. Try the refinements such as call/show etc. On Wed, Oct 1, 2008 at 6:00 PM, <amicom-sonic.net> wrote:

> Hi All! > It's been a LONG time since I've written to the list, but I've been busy > To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject.

Graham, It appears it was partially 'call to blame (even though I also tried the 'run command from Autoit via REBOL's dll facilities with similar results). However, the main problem seems to be running a REBOL executable as a Windows service. Here are the service types: Type is a type REG_DWORD that specifies what this object represents: Value D e s c r i p t i o n 1 A kernel-mode device driver. 2 A file system driver. 4 A set of arguments for an adapter. 8 A file system driver service, such as a file system recognizer. 16 (0x10) A Win32 program that runs in a process by itself. This type of Win32 service.can be started by the Service Controller. 32 (0x20 A Win32 program that shares a process. This type of Win32 service can be started by the Service Controller. 272 (0x110) A Win32 program that runs in a process by itself (like Type16) and can interact with users. 288 (0x120) A Win32 program that shares a process and can interact with users. I've tried all these values with no success. Unless anyone has any ideas, here is my conclusion: REBOL executables running as a service are moderately to severely sterilized . Executables launched from a service-launched REBOL executable generally cannot display their interface and interact with the operating system in a normal manner. -Bo

Hi Bo, asn> REBOL executables running as a service are moderately to severely asn> "sterilized". Executables launched from a service-launched REBOL asn> executable generally cannot display their interface and interact with asn> the operating system in a normal manner. Are you using Doc's service tools? http://softinnov.org/rebol/nt-services.shtml What OS? My guess would be that it's related to the inherited security descriptor for the process, but that's just a guess. You might be able to do it with CreateProcess, where you can affect the security descriptor. Doc and Gab's async-call stuff may also help you work around the problem. -- Gregg

Hello Gregg! I didn't know about Doc's service tools. Thanks for the link! The following from Doc's service tools description looks like exactly what I was missing: ----- interactive: logic! no yes : allow the service to interact with the user's desktop (e.g.: display a window). In this mode, your application doesn't survive to session logoff. no : no interaction with user's desktop ----- Unfortunately, this is a showstopper for me. What I am wondering is how do the programs RealVNC Server and WinVNC Server display the Windows login screen if this is a requirement? They run as a service and can interact with the login screen even sending CTRL-ALT-DEL (another thing I haven't been able to duplicate) to display the login dialog for Windows. They also can move the mouse on the login screen and send keypresses. I thank you for your depth of knowledge and assistance! -Bo