Mike> about memory layout. When we call run_in_other_process, Mike> we're going to allocate memory in the child process which Mike> will affect the layout of memory if it's done too soon. Mike> That's what was confusing the MSK Toolkit shell Shades of Mike> non-portable dumping in XEmacs. I don't understand the last sentence above. Mike> I have three different versions of sleep on my machine: (1) Mike> the one you tried which came with Cygwin 1.1, (2) the one in Mike> the NT Resource Kit, and (3) the one that came with the MKS Mike> Toolkit. For each of them I tried starting it with (for Mike> example) Mike> (start-process "sleep" nil "C:/cygwin/bin/sleep.exe" "3000") Mike> and then interrupting it with (interrupt-process "sleep"). Mike> It turns out that (1) fails to interrupt regardless of Mike> whether my patch is in or not and both (2) and (3) work Mike> fine, they are interruptible regardless of whether the patch Mike> is in or not. All three are killed by kill-process whether Mike> or not the patch is in. This is running on NT 4.0 SP 5, Mike> which may not be the same system you are using. I have NT 4.0 SP 5 also, VS C++ 6.0. I can interrupt the sleep process when started with: (start-process "sleepy" nil "sleep" "60") (interrupt-process "sleepy") I cannot interrupt it, when started und "a shell": (start-process "shell" nil "cmd" "/c" "sleep" "60") (interrupt-process "shell" t) Are you saying you cannot even interrupt the first case above? What about following perl example? (start-process "perl-forever" nil "perl" "-e" "\"while(1) {};\"") (interrupt-process "perl-forever" t) I get #<process "perl-forever" pid 338 state:run> Cannot send signal to process #<process "perl-forever" pid 343 state:run> Cannot send signal to process #<process "perl-forever" pid 339 state:run> Cannot send signal to process consistently, but each process gets killed. All of my examples above are run from (emacs-version) "XEmacs 21.1 (patch 10) \"Capitol Reef\" [Lucid] (i386-pc-win32) of Sun May 07 2000 on ZJ75T" with my patch http://www.xemacs.org/list-archives/xemacs-patches/200005/msg00016.html applied. Thanks for your detailed explanations! Best regards, Adrian