[Ecls-list] Patch to prevent crash on Windows GUI applications

[Dan Hristodorescu]

I completely agree, it was just a proposal for someone working on ECL to
integrate something along these lines in the initialization of the
runtime.
I know about redefining the *terminal-io* to some dummy streams but that
way  I cannot interact with ECL to do debugging at least during
development.

In my case there is no way to run as an external process, the plugin is
a DLL loaded inside the application and I have no control over the
loading.

I first tried in a small standalone program to open the console in the C
code and hope ECL would be able to use the input and output stream.
My knowledge of Windows programming is not that good and I don't know
why I could use the streams in my C program before and after calling
inside ECL but not in the lisp code. It must have something to do with
the fact that ECL is loaded as a DLL but I don't know how to get around
that.
If someone knows how I would like to find out.
If I start the console in ECL DLL I still can use it in my C program
afterwards.

If there is not possible to reuse the console opened in the C program
inside ECL DLL then I think the best solution would be to pass something
(even as one of the  string arguments) in cl_boot() to ask the runtime
to create a console in case the input and output streams are invalid.
This way both cases (console and redirected streams) will be covered.

Thanks,
Dan.


-----Original Message-----
From: ecls-list-admin at lists.sourceforge.net
[mailto:ecls-list-admin at lists.sourceforge.net] On Behalf Of Goffioul
Michael
Sent: Monday, August 29, 2005 3:36 AM
To: ecls-list at lists.sourceforge.net
Subject: RE: [Ecls-list] Patch to prevent crash on Windows GUI
applications

I also had that problem when integrating ECL in MATLAB, however I
solved it in a LISP programmatical way: during the initialization of
my module, I redefined *terminal-io* and *error-output* streams
(all other standard streams are somehow linked to those 2 streams).

The only problem left was related to ext::run-program which duplicates
standard handles to pass them to the child process, but this part
have been solved partially.

Regarding your proposal, I don't like the idea of having a console
window opening in *all* cases without controlling possibilities. I
would go for a more flexible solution where the developper could
say "do not open a console and redirect standard streams to nowhere".
At least in my case, I don't want to see a console opening in my
MATLAB integration.

Michael.


> Hi,
> 
> I'm working on a plugin for a Windows application and I 
> noticed there is
> a problem when creating a GUI application because the stdin, 
> stdout and
> stderr streams are invalid and ECL tries to use them.
> Based on what I've seen done in GambitC to solve this problem 
> I propose
> this patch to the file src/c/file.d after the variable 
> initialization in
> init_file():
> 
> void
> init_file(void)
> {
> 	cl_object standard_input;
> 	cl_object standard_output;
> 	cl_object error_output;
> 	cl_object standard;
> 	cl_object x;
> //----- this is the new code -----------------
> #if defined(_MSC_VER) || defined(mingw32)
>   HANDLE h = GetStdHandle (STD_OUTPUT_HANDLE);
>   if (GetFileType (h) == FILE_TYPE_UNKNOWN)
>   {
>     AllocConsole();
>     freopen("CONOUT$", "a", stdout);
>     freopen("CONIN$", "r", stdin);
>   }
> #endif
> //--------------------------------------------
> .....
> 
> Basically in GUI mode the handles to stdout, stdin and stderr 
> are of an
> invalid type. The code will then create a console and 
> redirect input and
> output to the newly created console allowing user interaction (like
> debugging). The stderr by default is sent to stdout in console.
> Any console version of a program won't be affected by this 
> patch and it
> would work like before.
> 
> Thanks,
> Dan Hristodorescu.
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development 
> Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * 
> Testing & QA
> Security * Process Improvement & Measurement * 
http://www.sqe.com/bsce5sf
_______________________________________________
Ecls-list mailing list
Ecls-list at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Ecls-list mailing list
Ecls-list at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list