I guess, that if you launch it from the GUI, the console output (going to stdout + stderr) is lost somewhere in cyberspace.

Have you tried launching it from a command prompt / terminal window? I bet you will see the console output right there.

yeah, I tried running from a terminal but it seems I don't know how 😀
I had a terminal open at the programs folder and tried starting dosbox by DOSBox.app but that didn't work (command not found). I have yet to find out with which command to start an app from the terminal...

Edit: Ok, I found out how to do that 😀 (you need to cd into the app bundle, and then into /contents/macos and there "open DOSBox")...
And yes, that way I see the console, thanks

There is still the question about stdout and stderr, but I have no clue...

If you create an alias of the dosbox unix file located in /DOSBox.app/Contents/MacOS/,
and drag it outside of the bundle onto your hard disk,
just double-click that alias to get the console window at DOSBox start.

Did you try to launch the "Console" app? I don't know if it's installed by default or if it requires you to install the Dev tools. Some program dump their log there.

If I'm not mistaken stdout/stderr are just what you can see "normally" in the Dosbox console, so if I can see that I'm just fine 😀 I'm going to do the alias way as IIGS suggested.

@Zorbid, I just tried with the OSX Console, but no, can't see the output there, but good suggestion, thanks.

I just tried it. The log appears in the Console window, but after you close DOSBox, making it mostly useless.

AFTER you close it? He he, interesting... I had closed the Console before closing Dosbox, so I didn't see that 😀

When I want a console window in my DOSBox session, I just drag the /Contents/MacOS/DOSBox unix exe onto the Terminal window (Terminal.app in your /Applications/Utilities folder.

This means, Terminal is started, then Terminal starts a new DOSBox session.

-> I could close DOSBox itself, but if I quit the Terminal, DOSBox will also be exited.

thanks for those useful tips 😀

IIGS_User wrote:

-> I could close DOSBox itself, but if I quit the Terminal, DOSBox will also be exited.

Hmm. Try starting it with

$ dosbox &

Or maybe

$ nohup dosbox &

Or

$ nohup dosbox 1> stdout.txt 2> stderr.txt </dev/null &

I tried MiniMax's thoughts, but no success.

I think it's because DOSBox is a sub thread of the Terminal application then,
so if you quit the Terminal, DOSBox will be exited by default.

IIGS_User wrote:

I think it's because DOSBox is a sub thread of the Terminal application then, so if you quit the Terminal, DOSBox will be exited by default.

Nah - can't be. MacOSX/Unix has no concept of "sub threads". The dosbox process will be a child from the terminal process, but it is in no way dependent on its father process. It will inherit everything from its parent - working directory, environment variables, open files, etc, etc.

What actually happens is that when the terminal process (or rather, the Bash command line interpreter that you enter the "dosbox" command into) clones itself, then quickly goes about closing open files (with the exception of stdin, stdout, and stderr), and then reads in the EXE-code for dosbox and transfers control to the new code - and then dosbox is running.

While all this cloning is going on, the terminal (Bash) sits around and waits for its clone-child to finish. Adding the magic '&' after the command tells Bash no to wait, but carry on, prompting you for the next command.

The child inherited everything from its parent, including how to react to certain events (signals), e.g. when you hit CTRL-C (which generates an INT-errupt signal). In the good old days, another event that could happen, was that your modem connection to the big, hulking box of iron that Unix was running on was dropped - known as a modem Hang Up (HUP). I am not sure, but I expect that closing down the terminal window would send a HUP signal to all child processes, including dosbox, and by default that HUP-signal would cause the child (dosbox) to terminate.

Prefixing the dosbox command with 'nohup' twists the handling of the HUP-signal so it is ignored by dosbox (again, a lot of cloning going on here - Bash clones itself, loads the EXE-code for nohup, the nohup code disables HUP-handling, and replaces its own EXE-code with that of DOSBox, which is now immune to HUP signals).

The convoluted >, >&, and < /dev/null stuff is desperate attempt to redirect stdin, stderr and stdin to something else before dosbox is launched - just in case that their disappearance (when the terminal window is closed) somehow causes a problem.

Alas - none of all that worked it seemed 🙁

Maybe I should try again - thanks for all these useful informations!