[Openmcl-devel] relaunching CCL IDE on Windows problems

Gary Byers gb at clozure.com
Wed Nov 16 20:59:48 PST 2011

There's nothing in CCL that tries to enumerate running processes.
On Unix, doing so is very system-dependent (though I think that there
are some libraries that try to hide system dependencies and make it
easier to write programs like 'top' and 'ps'.)

shows how to do it on Windows, using functions defined in the "psapi" library.
The good news is that the CCL kernel uses some things in psapi and as a result
the library's always available.  The bad news is that that's typical Win32
code, but at least there isn't a whole lot of it.

(CCL::GETPID) behaves about the same way on Windows as it does on Unix systems.
If I understand the example correctly, #_EnumProcesses will fill in a buffer
with the process IDs of all running processes (after you wrestle with it
about the size of the buffer.)  If you iterate through that buffer (basically
a C vector of (UNSIGNED-BYTE 32)s), you should find exactly one entry that
matches the value returned by (CCL::GETPID).

The example shows how to get some information about a process given its
pid; it determines process's primary "module" (the main executable file)
and retrieves that module's basename.  I think that there are some
similar functions that'll return the module's full pathname.

Recall that (most ? all ?) Win32 functions that take string arguments
or return string results come in two flavors, one of which has a name
that ends in A (and deals with 8-bit ANSI strings) and the other having
a name that ends in W (and deals with UTF-16LE strings.)  C programs
typically select one or the other at compile-time and macros define
Foo to be either FooA or FooW according to which option was selected.
(Foo likely isn't defined, but both FooA and FooW will be.)

I'm sure that there's some way to kill a Windows process given its
PID, but I don't remember what it is and don't think that there's
any code in CCL that does that.  (Ah.  You need to use the PID to
get a handle to the process as in the example; that handle has to
have PROCESS_TERMINATE access rights.  Once you have that:

(#_TerminateProcess handle code)

will try to kill the process, and anything waiting for the process
to die will see that it died with the indicated exit code.)

On Wed, 16 Nov 2011, Alexander Repenning wrote:

> On Nov 16, 2011, at 6:42 PM, Gary Byers wrote:
>       If you tried to pursue option 3, I think that that'd be less
>       attractive.
>       It's conceptually straightforward to say "find all OS processes
>       that have
>       the same name as the current OS process but different process
>       identifiers
>       and kill them", but it's harder to believe that that's a good
>       idea. ?(Why
>       would you want to kill a copy of CCL that's running in Emacs ?
>       ?Why should
>       a healthy instance of your application die so that you should
>       live ? ?Does
>       this other process named "wx86cl.exe" have anything to do with
>       CCL ?)
> I suspect you are right about Cocotron being the main problem by not dealing
> the right way with starting a new copy of Cocotron. We will test this.
> Meanwhile, I think option 3 is not that unattractive. Our typical CCL app
> user would not be very likely to use any other CCL based app including
> Emacs. Also, we could, and probably should, rename "wx86cl.exe" to
> <ourapp>.exe This would minimize the risk of terminating the wrong process.
> There may be cases where running multiple copies of ourapp would be useful
> but this would probably require fixing Cocotron.?
> Is there some some simple way to "find all OS processes that have?the same
> name as the current OS process but different process identifiers?and kill
> them" using some already existing set of handy CCL process related functions
> or will this require the call of straight Win32 functions?
> Alex
> Prof. Alexander Repenning
> University of Colorado
> Computer Science Department
> Boulder, CO 80309-430
> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf

More information about the Openmcl-devel mailing list