[Openmcl-devel] relaunching CCL IDE on Windows problems

[Michael Minerva]

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.

--Mike
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'.)
> 
> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms682623%28v=vs.85%29.aspx>
> 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
>> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>