[Openmcl-devel] relaunching CCL IDE on Windows problems
minerva at agentsheets.com
Fri Nov 18 13:58:18 CST 2011
I wanted to try out some of the function Gary suggested but it seems the library EnumProcesses is in may not be used by CCL. When I call #_EnumProcesses I get the following error in CCL:
Error: Foreign function not found: WIN32::|EnumProcesses|
Does this imply that EnumProcesses is in a library not currently used by CCL?
I tried to call (#_TerminateProcess handle code) and this worked fine.
On Nov 16, 2011, at 9:59 PM, Gary Byers wrote:
> 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
>> It's conceptually straightforward to say "find all OS processes
>> that have
>> the same name as the current OS process but different process
>> 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?
>> Prof. Alexander Repenning
>> University of Colorado
>> Computer Science Department
>> Boulder, CO 80309-430
>> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel