[Openmcl-devel] External processes on Windows

[Gary Byers]

It's not clear to me from your last few messages abour running on Windows
whether you're running CCL in a Windows console or whether you're using
Cocotron, and that may be significant.

Windows applications have a field in the executable file that indicates
whether they're intended to run under the "console subsystem" or the
"gui subsystem"; I think that there used to be a few other options but
I'm not sure how widely used those other options are at this point.  (Windows
NT offered a "POSIX" subsystem, which supposedly satisfied some purchasing
requirement imposed on US government agencies.)

A Windows console application behaves like (and runs in an environment
that's very much like) a traditional Unix application: they read input
from and write output to standard file handles (files, pipes, a "console"
device ...)  Somewhat confusingly, they can also open the appropriate
libraries, run an event loop, and do GUI things (though they may have
been lauched with an option that keeps the first window that they try
to show from appearing and may have to call "showWindow()" or whatever
it's called twice for it to have any effect.  I'm not making that
up.)

By contrast, a program that uses the "GUI subsystem" has its stanard
I/O handles set to NULL (binary 0) and attempts to use those file
handles will get some sort of memory fault.  A GUI program can create
a console window and do I/O to it.  I'm not sure what happens if a GUI
application is run via something like CCL:RUN-PROGRAM with standard
I/O handles redirected to somehthing useful, and I'm unclear on whether
any of this behaves any differently if the parent process is a GUI process.

I'm sure that these problems have solutions (and the fact that you're
seeing two different Python processes may be an attempt by that program
so solve something), but I'm pretty near the point where I conclude that
the first step in the best solution involves inserting a Linux installation
disk and rebooting.

If that isn't an option for you, you might want to try to see if your
Python interpreter has options that control whether it can be built as
a console or GUI application and build it as a console application if so.

On Tue, 31 Dec 2013, Ron Garret wrote:

> I?m having a problem porting a CCL application to Windows.  I?m using run-program to spawn a Python interpreter (quick and dirty hack until I can port the functionality I need to Lisp).  That works on OS X, Linux, and Windows.
>
> But on Windows I need to produce a standalone executable, so I used PyInstaller (http://pyinstaller.org) to produce a self-contained python interpreter with all my code pre-loaded into it, and that works too, but only when I run it from the command line.  When I try to invoke that self-contained Python executable from Lisp using run-program, two strange things happen.  For the sake of discussion let is say that my self-contained python is called scpy.exe.  The first strange thing is that I get TWO scpy.exe processes showing up in the task manager, not just one.  They have different memory usages, so they are (apparently) not identical.  Killing either one will cause the other one to terminate as well.
>
> The second (and more serious) problem is that none of the output from scpy.exe shows up in the external-process-input-stream of the external-process object i get when I start scpy.exe.  I?m using the exact same code as I?m using to launch the regular python interpreter, in which case everything works.
>
> My question is: what could possibly be causing this behavior?  Do Windows pipes differ substantially from unix pipes?  I?ve never done any Windows development before, so I might be missing something very elementary here.
>
> I?m running CCL 1.8-r15286M on 32-bit Windows XP.
>
> Thanks, and happy new year!
>
> rg
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>