How do I suppress the console?

[Benjamin_R_2]

I am new to Visual Studio and to this discussion group. I am sorry if this has been answered somewhere, but I looked on the web for quite a while. I am compiling a Fortran executable with Visual Studio 2013 on Windows 7 using the Intel Parallel Studio XE 2015 software. My Fortran executable is called from Matlab. It reads a input text file and writes and output text file. That is all I want it to do. I don't want the console ever to appear. Actually, I found a workaround way to do this, but I'd like to know the expert and elegant way to do this. Thanks.

[IanH]

How are you calling your program from Matlab?  What is your current work around?

I used to call Fortran programs from Matlab quite regularly.  I don't ever recall there being an issue with unwanted console windows.  From memory the Fortran program's output simply appeared in the matlab command window, or was captured in a matlab variable.

[Benjamin_R_2]

Hi IanH,

Thanks for answering. I call the Fortran executable with the Matlab statement: [s,w] = system('name of executable').

In Visual Studio, I chose the option: System/SubSystem/Console(/SUBSYSTEM:CONSOLE).

I think that is about all I changed except for adding some libraries. When I rebuild the project, everything is fine. When I Start Without Debugging, a console pops up asking me to press any key to return. This is undesirable for my purposes. However, when I just stick the executable (from the Debug directory) into the Matlab directory, it just runs, reads the input and writes the output, without a console popping up. This is my 'workaround'. It evidently works, but I'd feel that I had more control over the situation if the console never popped up in Visual Studio in the first place.

I tried the option Not Set in Linker/System/Subsystem/, but rebuilding produces the error:

   1>LINK : fatal error LNK1561: entry point must be defined

In my main Fortran routine, there are the usual READ and WRITE statements. Curiously, I found that when I put a PAUSE statement at the top of the main Fortran routine, then I can rebuild without errors. When I run it, I again get the console (a rather small one) that says 'Pause', and if I hit return twice, it proceeds as before.

I don't need to spend much time on this, since I found something that works. I just wanted to better understand what is going on.

For instance, does one ever want to choose the option: Linker/System/Subsystem/Not Set?

Thanks

[IanH]

When you run the program from Visual Studio in that way, you are not involving Matlab at all.

(You can debug a program in Visual Studio that you have started in Matlab, but that doesn't appear to be what you are asking about.)

The subsystem option sets a field in the header of the exe file for your program.  That field is used by the base operating system, and related programs such as cmd.exe and the graphical shell, to understand aspects of the operating environment that your program requires to run, so that they can "do the right thing".  Given the situation you describe, I would just stick with your program being marked as for the console subsystem.

(I suspect your linker error/rebuild observations just relates to a change in the default name used for the program entry point (what the compiler generates/what the linker expects) when you change that subsystem setting.  If you still see a console window, it is likely that you are still generating a console subsystem application.)

When you "start without debugging" a console subsystem program from within Visual Studio, a console window is created on your behalf by Visual Studio/the operating system, because that subsystem field in the executable indicates that perhaps your program needs a console.  If it doesn't need a console (and if your program has things like PAUSE statements in it then it will generally need console-like support, consider also the possibility of diagnostic messages from the compiler runtime - and if you are running from a debugging/development environment like Visual Studio, then generally you are interested in seeing those sorts of messages!!), then no harm done. 

Perhaps you could explain why you see the presence of a console as undesirable in that situation.

When you run your program from within Matlab, it emulates some aspects that are otherwise provided by a console - notably it provides the standard input and output files that console programs may use to communicate with users.  What you describe as a workaround is just the normal way of doing things.

If you ran your console program from within an existing console (i.e. from a command prompt), the operating system simply attaches your program to that existing console - it doesn't create a new one by default.  If you ran your program from another program of your creation using the CreateProcess API, you could run your console program "detached", where it will have no console services at all (if the program then requires console services, it will generally fail).  Some third party utilities give you access to this aspect of CreateProcess.

If you mark your program as using the WINDOWS subsystem, you are flagging that the program will manage interaction with the user itself through the graphical interface.  (This change may also result in a change in the default name of the entry point that the linker expects.)  The operating system and related components such as cmd.exe and the shell will then alter their behaviour to match that flag - for example the graphical shell will not create a console window for the program, and cmd.exe will,by default, run the program detached and not wait for your program to finish executing before it shows the next command prompt.  Again, if your program then happens to require a console for any reason, it will fail, without necessarily being able to inform the user why.  (I don't suggest making this change - for simple single task like programs with no graphical user interface, like yours, this altered behaviour would likely confuse things down the track.)

[Benjamin_R_2]

Wow! Thanks! That was a lot of work typing all that. I appreciate it.