Problems with the "mwindows" switch

Problems with the "mwindows" switch

[NiGHTS]

I am trying to compile a GUI Windows application with Ada & Gtk in such a way as to only display the GUI window and not the console window. Early in my development I had success using the "mwindows" linker switch with my GTK window, but had to remove this switch at some point during development after I was no longer able to test run the program without it aborting immediately after startup. I suspect the problem is a conflict with something I've added to the GPR project file. 

In my program, the very first command it ever does is this:

Ada.Text_IO.Put_Line ("Hello World");

My expectation is that I would only see this "Hello World" message if I ran the executable from a console window but not when run directly from Windows Explorer.

Unfortunately when the "mwindows" flag is set not only does the GUI not appear as expected, but I don't get any feedback on the command console either. It makes me think that there is something fundamentally broken with the executable itself.

Here is a limited view of my GPR project file:


with "gtkada";
with "gnatcoll_sqlite";

project main is

    ...

    package Builder is
        for Default_Switches ("ada") use (
            "-g"         -- Compile with Symbols for Debugging
        );
    end Builder;

    package Compiler is
        for Default_Switches ("ada") use (
            "-g",        -- Compile with Symbols for Debugging
            "-gnat05",   -- Use Ada 2005
            "-gnata"     -- Compile all Assertions and enable all runtime checks
        );
    end Compiler;

    package Linker is
        for Default_Switches ("ada") use (
            "-g",            -- Compile with Symbols for Debugging
            "-pthread",      -- Link with pthread support
            "-lusb_driver",  -- Driver imported from C
            "-mwindows"      -- Launch Window, not console (* breaks program *)
        );
    end Linker;

    ...

end main;


Any hints on what could be wrong is be highly appreciated!

Thank you.

Re: Problems with the "mwindows" switch

[sbelmont700]

On Friday, May 22, 2015 at 2:35:59 PM UTC-4, NiGHTS wrote:
> 
> Any hints on what could be wrong is be highly appreciated!
> 

A Win32 executable is either 'console' or 'windows' (CUI or GUI).  This is, effectively, what the -mwindows switch controls, with its omission indicating CUI.

Essentially, a CUI executable gets its standard output handle from its parent console; so if you spawn a CUI from the shell, it uses the same console for output, and you get it in the same window as the shell.  Not so with a GUI app, that has no default output, and would open a new window should you try (via AllocConsole()).

So, if you use the -mwindows switch, you get no default console and your text goes nowhere.  If you remove it, you will always get a console whether you want it or not.  There is, officially, no way to create a windows executable that is dynamically both.

There is probably a more subtle reason as to why your GUI doesn't appear when -mwindows is present.


(http://blogs.msdn.com/b/oldnewthing/archive/2009/01/01/9259142.aspx)


-sb

Re: Problems with the "mwindows" switch

[NiGHTS]

On Friday, May 22, 2015 at 3:24:32 PM UTC-4, sbelm...@gmail.com wrote:
> There is probably a more subtle reason as to why your GUI doesn't appear when -mwindows is present.
> -sb

Thank you for your explaination.

Since my little "Hello World" test is not possible in mwindows mode, what series of steps would you recommend that I take to locate the source of the problem and solve it?

Re: Problems with the "mwindows" switch

[Dmitry A. Kazakov]

On Fri, 22 May 2015 12:51:49 -0700 (PDT), NiGHTS wrote:

> Since my little "Hello World" test is not possible in mwindows mode, what
> series of steps would you recommend that I take to locate the source of
> the problem and solve it?

Which is?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Problems with the "mwindows" switch

[NiGHTS]

On Saturday, May 23, 2015 at 1:33:27 AM UTC-4, Dmitry A. Kazakov wrote:
> On Fri, 22 May 2015 12:51:49 -0700 (PDT), NiGHTS wrote:
> 
> > Since my little "Hello World" test is not possible in mwindows mode, what
> > series of steps would you recommend that I take to locate the source of
> > the problem and solve it?
> 
> Which is?
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

The problem is that the program will not start when the "mwindows" linker option is used. I don't know how to go about debugging this problem.

Re: Problems with the "mwindows" switch

[Dmitry A. Kazakov]

On Sat, 23 May 2015 00:20:57 -0700 (PDT), NiGHTS wrote:

> The problem is that the program will not start when the "mwindows" linker
> option is used. I don't know how to go about debugging this problem.

It quite difficult to imagine how mwindows could have anything to do with
that.

"Will not start" means what, technically? Any properly linked executable
will start, otherwise Windows gives a message box that the executable is
corrupted etc. Thus, again, what is the problem? No window? No process?

There are three vital stages of a GTK program execution before it becomes
operational and anything visible happens:

1. Elaboration phase includes initialization of static objects and
sections, loading and linking to dynamic libraries etc.

2. Execution prior to entering the main messages loop.

3. Creation of GTK objects, like the main Window, within the messages loop.

(Note that during #1 no Text_IO could ever help)

P.S. GTK is not task/thread-safe. Any GTK (GDK, Glib, Gobject etc) calls
shall be done on the context of the main task, the one running the messages
loop.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Problems with the "mwindows" switch

[gautier_niouzes]

Le vendredi 22 mai 2015 20:35:59 UTC+2, NiGHTS a écrit :

> Unfortunately when the "mwindows" flag is set not only does the GUI not appear as expected, but I don't get any feedback on the command console either. It makes me think that there is something fundamentally broken with the executable itself.

It is an unfortunately normal behavior. Each console output when there is not console due to -mwindows will stop the program...
So you need to remove all you put's or put_line's or frame them inside a condition.

if trace then
  put(...);
en if;

_________________________ 
Gautier's Ada programming 
http://gautiersblog.blogspot.com/search/label/Ada 
NB: follow the above link for a valid e-mail address 

Re: Problems with the "mwindows" switch

[Randy Brukardt]

<sbelmont700@gmail.com> wrote in message 
news:00836c9e-9ed0-4638-9d0b-0b3cd4e07c65@googlegroups.com...
>A Win32 executable is either 'console' or 'windows' (CUI or GUI).  This is, 
>effectively,
>what the -mwindows switch controls, with its omission indicating CUI.

>Essentially, a CUI executable gets its standard output handle from its 
>parent console; so
>if you spawn a CUI from the shell, it uses the same console for output, and 
>you get it in
>the same window as the shell.  Not so with a GUI app, that has no default 
>output, and
>would open a new window should you try (via AllocConsole()).

Right so far.

>So, if you use the -mwindows switch, you get no default console and your 
>text goes
>nowhere.  If you remove it, you will always get a console whether you want 
>it or not.
>There is, officially, no way to create a windows executable that is 
>dynamically both.

Of course there is, you just need some support from the runtime. For 
Janus/Ada we attempt to write to Text_IO for a GUI program create a console, 
else it's impossible to see what is going on when there is a problem at 
start up. I can't quite imagine how one could figure out anything without 
that, because its not at all unusual to have an exception raised during 
package elaboration, and there is no possible way to handle such an 
exception.

There is a weird effect with those windows, through, in that they appear and 
go away in a hurry when displaying unhandled exceptions. On some Windows 
systems, redirection works and you can capture the text that way. On other 
systems, it doesn't. I've never been able to figure out what controls that 
so I can suggest it to people (and set it myself).

                                      Randy.

Re: Problems with the "mwindows" switch

[sbelmont700]

On Thursday, May 28, 2015 at 6:19:09 PM UTC-4, Randy Brukardt wrote:
> 
> Of course there is, you just need some support from the runtime.
>

The ability of which I was referring was the ability to have a program that can dynamically select whether to use the inherited console (i.e. if you run the executable from a command prompt, to output the text to the existing console) or to open a new window.  A GUI app that allocates its own console but is ran from the command prompt will open a new window to print the text, which is normally not the desired behavior.  Making a CUI app will work right when spawned from the command line, but will always open its own console when spawned by double clicking the icon, even if there is no output, which is also normally not the desired behavior.

Re: Problems with the "mwindows" switch

[Björn Lundin]

On 2015-05-29 00:19, Randy Brukardt wrote:
> 
> On some Windows 
> systems, redirection works and you can capture the text that way. On other 
> systems, it doesn't. I've never been able to figure out what controls that 
> so I can suggest it to people (and set it myself).
> 

Many years ago I found that Windows system based on Windows NT
would handle redirection of both stdout and stderr,
but systems like w95/98/ME did not redirect stderr, only stdout.

At least, I never got it work, and I was enlightened by a news group.
Might have been this one, but I'm not sure.

--
Björn

Re: Problems with the "mwindows" switch

[Randy Brukardt]

<sbelmont700@gmail.com> wrote in message 
news:37731869-bfb2-47b1-b0cf-7e4e806019c1@googlegroups.com...
On Thursday, May 28, 2015 at 6:19:09 PM UTC-4, Randy Brukardt wrote:
>>
>> Of course there is, you just need some support from the runtime.
>>

>The ability of which I was referring was the ability to have a program that 
>can dynamically
> select whether to use the inherited console (i.e. if you run the 
> executable from a command
> prompt, to output the text to the existing console) or to open a new 
> window.  A GUI app
> that allocates its own console but is ran from the command prompt will 
> open a new window
> to print the text, which is normally not the desired behavior.

That's harmless, though, since the primary reason to use Text_IO in the 
first place is for error/crash reporting. Where that goes is not 
particularly relevant. And if you really mean to write to a console in the 
GUI program, a separate window is usually a benefit, as it is much more 
similar to the way the rest of the app works.

The one thing that I do want in some cases is to be able to capture the 
output (that is, redirect the output to a file), and that works on some of 
my machines but not others (even with the separate window, and differing 
even for the same Windows version). I'm not sure why that is, but it's 
clearly possible to redirect the output that is going to a separate console 
window.

> Making a CUI app will work right when spawned from the command line, but 
> will always
> open its own console when spawned by double clicking the icon, even if 
> there is no output,
> which is also normally not the desired behavior.

Agreed, although the problem there is that CUI apps should never be run by 
clicking on icons. That's fairly easy to do, too, don't register the silly 
icon to the desktop or the start menu -- it's not designed to be run there. 
(No one navigates to a directory to click something.)

So while I understand what you are thinking is missing, it seems pretty 
unnecessary to me.

                                  Randy.

Re: Problems with the "mwindows" switch

[Jeffrey R. Carter]

On 05/29/2015 02:24 PM, Randy Brukardt wrote:
> 
> (No one navigates to a directory to click something.)

All this time I thought I was somebody, but it turns out I'm no one.

-- 
Jeff Carter
"Drown in a vat of whiskey. Death, where is thy sting?"
Never Give a Sucker an Even Break
106

Re: Problems with the "mwindows" switch

[Simon Wright]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> On 05/29/2015 02:24 PM, Randy Brukardt wrote:
>> 
>> (No one navigates to a directory to click something.)
>
> All this time I thought I was somebody, but it turns out I'm no one.

That makes two of us.

Re: Problems with the "mwindows" switch

[Dennis Lee Bieber]

On Fri, 29 May 2015 14:36:32 -0700, "Jeffrey R. Carter"
<spam.jrcarter.not@spam.not.acm.org> declaimed the following:

>On 05/29/2015 02:24 PM, Randy Brukardt wrote:
>> 
>> (No one navigates to a directory to click something.)
>
>All this time I thought I was somebody, but it turns out I'm no one.

	And no one is legion
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Problems with the "mwindows" switch

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:mkam2p$olr$1@dont-email.me...
> On 05/29/2015 02:24 PM, Randy Brukardt wrote:
>>
>> (No one navigates to a directory to click something.)
>
> All this time I thought I was somebody, but it turns out I'm no one.

I should have made it clear that I was only talking about clicking on 
programs in a directory, not ordinary files (which might run a program). 
One's much more likely to use the desktop or start menu. But clicking on a 
program in a directory is the only way that a CUI program would be run from 
the GUI if one doesn't register it (which is useless, because the output 
doesn't go anywhere).

I admit I've occassionally clicked on CUI programs and batch files, but only 
by accident. They're only supposed to be run from the command line (and the 
majority of them take arguments that won't be provided by clicking on them 
anyway). I occassionally click on a GUI program that I have under 
development, but even that is very rare (and it's unique to developers).

If you're clicking on programs in directories outside of development, I have 
to ask why. And nothing about developers is typical for Windows, it doesn't 
have anything to do with the way most people use Windows.

                                      Randy.


                                    Randy. 

Re: Problems with the "mwindows" switch

[sbelmont700]

Admittedly I've never had the need to do so, but whenever I see it happen with other programs it's the other way round; i.e. a GUI (subsystem) app that wants to take command line parameters.  VLC Media Player, for instance, normally runs a GUI when you run the executable (parameterless), but also has the ability to take switches to run in an automated, command line fashion.  This makes things like "--help" particularly strange, since a new console opens to display the parameters, and then vanishes when you need to return to the first one to actually type them in.  (IMHO two apps with a shared DLL would have been the better route).

-sb

Re: Problems with the "mwindows" switch

[NiGHTS]

On Saturday, May 23, 2015 at 4:23:46 PM UTC-4, gautier...@hotmail.com wrote:
> Le vendredi 22 mai 2015 20:35:59 UTC+2, NiGHTS a écrit :
> 
> > Unfortunately when the "mwindows" flag is set not only does the GUI not appear as expected, but I don't get any feedback on the command console either. It makes me think that there is something fundamentally broken with the executable itself.
> 
> It is an unfortunately normal behavior. Each console output when there is not console due to -mwindows will stop the program...
> So you need to remove all you put's or put_line's or frame them inside a condition.
> 
> if trace then
>   put(...);
> en if;
> 
> _________________________ 
> Gautier's Ada programming 
> http://gautiersblog.blogspot.com/search/label/Ada 
> NB: follow the above link for a valid e-mail address

This worked. 

I don't mind this limitation though as I expected to eventually pipe all debug data to SQLite. I'm surprised that Windows doesn't give me any useful feedback about the problem, especially since this problem appeared to have occurred before main thus out of reach of debugging. 

Wouldn't it be the Ada way to scream violently before its death instead of quietly accepting its fate? I have a feeling Windows is inherently the problem here.

Re: Problems with the "mwindows" switch

[Simon Wright]

NiGHTS <nights@unku.us> writes:

> Wouldn't it be the Ada way to scream violently before its death
> instead of quietly accepting its fate? I have a feeling Windows is
> inherently the problem here.

I think it's been fixed .. but for a long time GNAT tasks which suffered
an unhandled exception would die silently, leaving the developer
mystified.

Re: Problems with the "mwindows" switch

[J-P. Rosen]

Le 03/06/2015 08:42, Simon Wright a écrit :
> NiGHTS <nights@unku.us> writes:
> 
>> Wouldn't it be the Ada way to scream violently before its death
>> instead of quietly accepting its fate? I have a feeling Windows is
>> inherently the problem here.
> 
> I think it's been fixed .. but for a long time GNAT tasks which suffered
> an unhandled exception would die silently, leaving the developer
> mystified.
> 
That's the required behaviour. After all, raising an exception is a good
way to immediately terminate a task, and there is no way to tell whether
it is intended.

What's new is the ability to have "last wishes" procedures, called upon
any task termination (whether normal or abnormal).

But it is certainly good practice to always have a catch-all exception
handler in every task (this can be enforced by AdaControl, of course :-) ).

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr