I'm working on a project using Ogre3D. We recently ported our project to MacOSX but there are some things that were linked to the Windows API. In particular I don't know how this should be translated:
#if defined( __WIN32__ ) || defined( _WIN32 )
AllocConsole();
#endif
It would be nice to port the project under Linux someday, so is there an Unix-compatible way to allocate a console for standard output/input?
Thank you
From UNIX point of view, since I'm not that experienced in Mac-specific development.
A console is "allocated" by default. You cannot order the OS to open a console though. You could tell the IDE you are using to open it in a terminal, or, if it supports that, create your current application as a Console Application, despite using GUI.
What do I mean by saying that console is allocated by default? Each process actually gets its stdin, stdout and stderr (file identifiers 0, 1 and 2) from the calling process. So unless calling process (bash, Finder, whatever) conveniently forgets to leave those open, you always have a console open ... but perhaps invisible?
Easiest way to get a console is to launch the application from Terminal as Finder would do it from GUI. Remember, .apps are actually folders:
/projects/myapp$ ./BuiltApplication.app/Contents/MacOS/BuiltApplication
Finder sets the current working directory to the folder where the .app bundle is located, so the above emulates it all best.
Additionally, take a look at the Console application at /Applications/Utilities/Console.app, included with MacOS. Console is usually used for viewing stdout and stderr. I cannot test this since I'm not on Mac, but I've actually found some sources that say that stdout and stderr should be redirected there. See this post:
You can use Console.app to see the output of applications launched in the normal manner, because the launch infrastructure specifically sends their stdout and stderr there. You can also use the asl routines to query the log, or perform more sophisticated logging if you so desire.
Related
I ran into the following issue using Pascal/FPC/Lazarus, but I think it is universal to all Windows .exe files, regardless of the IDE/compiler they are created with:
I created a Windows GUI application and wanted to display some debugging infos in a simple text console. Usually in a Pascal console application Write and WriteLn are used to write to a console/StdOut, but without additional measures in the project configuration this crashes because in a GUI exe (at least if created with Lazarus) a console window does not exist, I get a "file not open" exception.
There are multiple ways in Lazarus (centered around controlling the -WG switch during the build process) to get a console attached "write /writeln" can write text to, this is not the question. My question is, whether support for a console device (StdIn, StdOut, StdErr) is a Windows feature, which is part of the Windows Runtime, probably controlled by some metadata embedded in the exe, which in turn is controlled by this -WG switch, or whether it is a feature of a runtime environment added by a specific development environment, in this case by the Lazarus IDE or a runtime coming with the underlying FPC compiler.
Thnx!
Yes, consoles are generally not used for Windows GUI apps, though you can afaik instantiate some with allocconsole manually. Very early versions of Lazarus did this.
As David says, in general on Windows Outputdebugstring() is used or a logging library.
Technical details: afaik all windows processes (so also console) must actively activate the console, a task typically done by the runtime. The -WG switch suppresses this by setting a special IsConsole boolean variable to false.
The console io initialization is in rtl/win/syswin.inc procedure SysInitStdIO around line 515.
In there you can see that if not IsConsole a dummy file description is made (assignerror), and errors are redirected to message boxes(and might pass by GUI users unnoticed).
In macOS one can normally get some appreciable console / shell output by executing a process by executing it's binary directly in the Terminal via:
/Applications/SOME_APPLICATION.app/Contents/MacOS/SOME_APPLICATION
This can be very useful from time to time for debugging and catching errors that occur. With the introduction of Catalina (10.15), direct execution of applications in this fashion is discouraged from scripts, etc. and causes various problems, ultimately requiring the use of /usr/bin/open.
How can we redirect STDERR / STDOUT of a process after it's been started?
There has been some discussion on this topic previously for Linux, but it's not clear as to whether some of this will work out for macOS now.
reptyr would be fantastic if it could be repurposed for macOS since it already works mostly for FreeBSD.
This answer is from 2013 but is mostly still relevant.
Prior to Mountain Lion, all processes managed by launchd, including
regular applications, had their stdout and stderr file descriptors
forwarded to the system log. In Mountain Lion and above, stdout and
stderr go nowhere for launchd managed applications. Only messages
explicitly sent to the system log will end up there.
If you're writing an application and would like some output to show up
in the console, then adopt an API built on syslog(3) or asl(3)
instead. NSLog is one such API, and it has the advantage of logging to
stderr too so you can easily see your output no matter how you've
launched your application. If you'd like that functionality but want
to use asl or syslog directly then you'll want to look in to the
ASL_OPT_STDERR option to asl_open, and the LOG_PERROR option to
openlog respectively.
Basically, when you double-click an app (same as /usr/bin/open) there is no stdout/stderr. The dev is expected to send any relevant output/errors to the available logging APIs such as NSLog.
I have a .exe file that I've compiled on windows. But when I run it from the command line I don't see any of the things my program outputs to std::cout or std::cerr. The program runs and continues to run even after the command line returns to the prompt (it's a GUI program and doesn't quit until I press the quit button). How can I see the output of my program?
I'm using cmake to make a visual studio project which I then compile with msbuild.
One way to see the output is to run:
program.exe > output.txt
and then monitor that file for the output. Or use a pipe to view it:
program.exe | find /v ""
To also monitor the error output you could use
program.exe > output.txt 2>&1
program.exe 2>&1 | find /v ""
I figured it out based on the documentation by Microsoft that leaves a lot to the imagination and from the
much more practical examples here and here.
This helps me see "hidden" stdout and stderr messages from my (and other peoples) windows applications. It's interesting to see what messages have been left in some programs, but usually aren't seen.
The simplest approach is to rebuild the program as a console application. The option to link.exe needs to be /SUBSYSTEM:CONSOLE instead of /SUBSYSTEM:WINDOWS; presumably there is a straightforward way of specifying this in cmake.
This change shouldn't affect your GUI at all, but it will cause Windows to allocate a console if the process isn't already associated with one. Also, command line shells will usually wait for console applications to exit before continuing.
The other approach is to call AllocConsole to explicitly create a new console, or AttachConsole if you want to use an existing one. Or, of course, you could send the output to a log file.
Additional
According to a Google search, you can build the program as a console application by adding the following line to your source code:
#pragma comment(linker, "/SUBSYSTEM:CONSOLE")
This is probably the easiest solution. You can put it in an #if block if you only want the console for debug builds.
See also CMake: How to use different ADD_EXECUTABLE for debug build?
Harry Johnston's answer is spot-on if you want to permanently alter your application to display this information. I would recommend the latter approach he suggests, because switching your app to targeting the console subsystem will cause it to always allocate and display a console window on startup, even if you don't want it to.
However, I notice that you mention you want to display output from std::cerr, which implies that you might be only interested in this information for debugging purposes. In that case, my recommendation would be to call the OutputDebugString function instead of outputting to either std::cout or std::cerr. Then, you can use a little utility like DebugView to monitor the debug output of your application. Everything it sends to the OutputDebugString function will be displayed in the DebugView window.
If you want to use this setup with minimal changes to your existing code base, you can actually redirect the output of streams like std::cout and std::cerr to the debugger, just as if you'd called the OutputDebugString function. Advice on how to do this can be found in the answers to this question and in this blog post.
Windows doesn't support dual mode. Which means that when you run gui, you cannot get output to your console that you run the app from.
I have a GUI Ruby tool that needs to spawn a child command-line process, for example ping. If i do this on Windows, the console window will appear and dissapear for console process, that is very annoying. Is it possible to start a process from GUI Ruby script with no console window visible? If i use backtick operator or Kernel#system, the console window will appear, see example below:
require 'Tk'
require 'thread'
Thread.new { `ping 8.8.8.8` }
TkRoot.new.mainloop
The issue is that every executable on Windows is defined to be either a GUI executable or a Console executable (well, there's more detail than that but it doesn't matter here) at the time it is built. The executable that's running your Ruby script is a GUI executable (it also happens to use Tk to actually build a GUI, even if only a very simple one in your screenshot) and the ping executable is a Console executable. If a GUI executable starts a Console executable, a console is automatically created to run the executable in; you can't change this.
Of course, the picture is more complex than that. That's because a console application can actually work with the GUI (it just needs to do the right API calls) and you can use a whole catalogue of tricks to cause the console window to stay out of the way (such as starting ping through an appropriately-configured shortcut file) but such things are rather awkward. The easiest way is to have the console window be there the whole time by making Ruby itself be a console app (through naming your script with the .rb suffix, not .rbw). Yes, it doesn't really get rid of the problem, but it stops any annoying flashing.
If you were using ping as the purpose of your app (i.e., to find out if services were up) then I'd as whether it is possible/advisable to switch to writing the checking code directly in Ruby by connecting to the service instead of pinging it, as ping just measures whether the target OS kernel is alive, and not the service executable. This is a fine distinction, but I've seen machines get into a state where no executables were running but the machine was still responding to pings; this was very strange and can totally break your mental abstractions but can happen. But since you're only using ping as an example, I think you can just focus on the (rather problematic) console handling. Still, if you can do it without running a subprocess then definitely choose that method (on Windows; if you were on any sort of Unix you wouldn't have this problem at all).
It is indeed possible to spawn processes with Ruby. Here is a couple of ways to do it. I am not sure what you mean with
the console window will appear and dissapear for console process
but I think the best way for you to do it is to simply grab out and err and show it to your user in your own window. If you want the native windows console to appear wou probably need to something fancy with windows scripting.
One way to keep a spawned console alive is to have it run a batch file with a PAUSE command at the end:
rungping.bat:
ping %1
pause
exit
In your ruby file:
Thread.new {`start runping.bat 8.8.8.8`}
Background: We develop win32 applications, and use the "Thompson Toolkit" on windows to give us a unix-like shell that we use as our command-line.
We have a GUI program (with a WinMain and message loop) that we want to write to the console, but printf and so on don't work, even when we launch the program from the console. How can we write to the console from a GUI program? We need to print text there so that an automated build system can display error messages and so on.
Thanks.
In short, you need to attach a console. For details and ready to use code, see http://www.codeproject.com/KB/dialog/ConsoleAdapter.aspx.
Basicly you have to create a console by your self with AllocConsole, AttachConsole. After that you have to get standard handles with GetStdHandle and "associates a C run-time file descriptor with an existing operating-system file handle" with help of _open_osfhandle.
The returned handle can be used to overwrite crt stdin and stdout. After that all crt methods like printf should work.
Instead of logging to the console, log to a file and then track the file with a separate gui application. This keeps the console uncluttered and gives you a more persistent record of your log, which occasionally is extremely useful. There are various libraries which will do most of this for you, or you can keep it simple and just do it yourself.
somewhere in the Visual Studio Project Settings you can switch on having a console, assuming you are using VS. (Can't say where because I currently don't have it)