VOGONS


DOSbox as a Windows console application

Topic actions

  • This topic is locked. You cannot reply or edit posts.

First post, by jez

User metadata
Rank Member
Rank
Member

-mwindows <--- the bane of my existance. 😀 Let me explain.

The official release of DOSbox 0.58 ran as a console application. This is exactly what's needed, because DOSbox uses STDOUT to output normal (non-debug) messages. It's not much good writing 'frameskip at 8' or whatever to a file, after DOSbox has been closed! You need live output to a console window.

But how to get DOSbox to compile as a console app? I was determined to use a Unix-like compiler (gcc port) and ended up using MingW, but Cygwin would probably work too. The MingW documentation tells you that it compiles applications as console apps by default, and indeed it does. You can also specify a -mwindows flag to get it to compile as a windowed application, and -mwindows -mconsole also spits out a console window for STDOUT and STDERR to go to. This seemed like the best solution, explicitly declaring a windowed app AND a console, so I went for that.

You'd think that, to get make to add these flags when compiling the relevant files (just dosbox.exe as far as I can tell), you'd need to change something in the DOSbox source directory. Wrong. DOSbox copies a load of flags from SDL, using the SDL_LIBS environment variable. After much searching, I found the origin of this variable to be SDL's ./configure script.

I recommend that anyone compiling DOSbox first changes SDL's ./configure and ./configure.in before making and installing SDL, to make DOSbox compile as an application with a console window. I did this by modifying the code like so:

# MODIFIED BY JEZ
# SDL_LIBS="-lmingw32 -lSDLmain $SDL_LIBS -mwindows -mno-cygwin"
SDL_LIBS="-lmingw32 -lSDLmain $SDL_LIBS -mwindows -mconsole -mno-cygwin"
;;
*-*-mingw32*)
# MODIFIED BY JEZ
# SDL_LIBS="-lmingw32 -lSDLmain $SDL_LIBS -mwindows"
SDL_LIBS="-lmingw32 -lSDLmain $SDL_LIBS -mwindows -mconsole"
;;

However, there's yet another complication (or 2). ./autogen.sh, the script that creates ./configure for SDL, doesn't seem to work on my system; it just screws up the configuration totally. Fortunately, SDL comes bundled with a premade ./configure, so I just use that. However, In order for that to work, ./configure.in must be a certain age or older, or ./configure just screws up the make. I have no idea why, Unix shell scripts are not my forté. Maybe it tries to recreate ./configure unsuccessfully, or something. So, after modifying ./configure and ./configure.in, you need to forcibly set ./configure.in's modified date back to before a certain date/time, probably a date/time that's hardcoded somewhere in the sourcetree for SDL; in my case, that date/time was Sunday, 06 October 2002, 13:34:54. I just set the modified date for ./configure.in to some time back in 2001. 😀 You can do this in Windows with a tool like FileDate, found here.

I said there was another complication. There is. SDL for Windows is configured, by default, to redirect STDOUT etc to textfiles, because it defaults to a non-console app and if it didn't do that redirection, STDOUT etc would just be discarded. You can change this by using the ./configure parameter --disable-stdio-redirect, but that's annoying to have to do every time you configure, so I just modified src/main/win32/sdl_main.c like this:

/* Do we really not want stdio redirection with Windows CE? */
#ifdef _WIN32_WCE
#define NO_STDIO_REDIRECT
#endif
/* ADDED BY JEZ */
/* What we want is NEVER to have STDIO redirection! */
#define NO_STDIO_REDIRECT

Simple.

So, now after finally making and installing SDL, DOSbox will compile as a console application, and what it outputs to STDOUT will be pushed into a console window live, instead of written to a textfile after DOSbox closes. Amazing how many of DOSbox's build settings are controlled by SDL's configuration. 😀

For anyone interested, I'm attaching a .zip file containing the 3 modified files (./configure, ./configure.in, and src/main/sdl_main.c) that I used in the SDL sourcetree to get this favourable configuration, complete with the 2001 modified date for ./configure.in and all. 😀 They can happily be overwritten into your SDL sourcetree (my version is SDL 1.2.5) before making and installing SDL.

*** Update: Stupid board doesn't let you delete an attachment then upload a new one, check below for the attachment posted in a seperate reply. ***

Sorry about the length of this post, but I think it's quite an informative tutorial, and it took me quite a while to figure it out (most people I asked didn't seem to know much about it).

Plans for my future builds:
- Get DOSbox to start outputting more messages again, like current CPU cycles/second.
- Get DOSbox to start pausing and waiting for a keypress again before exiting, when it crashes!
- Massively improve keyboard code, maybe even allow custom keyboard mappings.
- Try and achieve more speed by compiling SDL to use DirectX instead of the Windows GDI.
- Try and achieve more speed by compiling SDL and/or DOSbox with some extra compiler optimizations.
- Get native screenshot support into my builds by getting libPNG to work with DOSbox.
- And probably much much more... 😀

Ah, the adventures of trying to improve a cool app.

Just for the record, DOSbox rules. If I can run something like Magic Carpet at a few FPS, with perfect sound and good graphics emulation, right now on my AMD Athlon 1.4ghz, I'm sure that in 1 or 2 years' time, we'll have a perfect 386/486 w/ DOS emulator. Great work guys... keep it up, and NEVER let the DOS classics die out!!

Last edited by jez on 2003-09-02, 11:49. Edited 1 time in total.

== Jez ==

Reply 1 of 10, by mrsbrisby

User metadata
Rank Newbie
Rank
Newbie

being as I don't run windows; is this any different from how dosbox runs under linux? It seems like this is just spitting the logs out to standard output- not the regular program output.

Is the logfile redirected by SDL buffered? Is there some other reason opening a command prompt and running "tail -f" woudln't have a similar effect? I run "tee" on my output from dosbox so I can keep a copy in the logs _as_well_as_ display it, but I do like those logs after dosbox bombs and I want to find out why 😀

Reply 2 of 10, by jez

User metadata
Rank Member
Rank
Member

Is the logfile redirected by SDL buffered? Is there some other reason opening a command prompt and running "tail -f" woudln't have a similar effect?

Seems to be. It's empty when I open it, until DOSbox exits.

I run "tee" on my output from dosbox so I can keep a copy in the logs _as_well_as_ display it

Well with DOSbox compiled as a console mode app, that option would now be open to me as well 😀

== Jez ==

Reply 3 of 10, by mrsbrisby

User metadata
Rank Newbie
Rank
Newbie
jez wrote:

Seems to be. It's empty when I open it, until DOSbox exits.

It might be a better idea to convince SDL to unbuffer (or linebuffer) output on win32. I'm not 100% sure if this is necessary, but you may be able to convince them to open+append, write, close for each line written out a whole lot easier than you can convince them to hold-open a command prompt window-- that is, getting debug info from an SDL app is something necessary enough that you want anyone to be able to do it, but not so hairy that they need to download 20 megs of tools and files, recompile and reinstall stuff they don't understand just to get the last few lines of a debug list and check it against a (presently ficticious) "known problems" file

Reply 4 of 10, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Plans for my future builds:
- Get DOSbox to start outputting more messages again, like current CPU cycles/second.
- Get DOSbox to start pausing and waiting for a keypress again before exiting, when it crashes!

number one simple. Look in cpu.cpp and change the first 1 to a zero 😉
number two even easier. sdlmain.cpp:main:
sdl_sec->Add_bool("nowait",true) change the true in false and you're done.

Water flows down the stream
How to ask questions the smart way!

Reply 5 of 10, by jez

User metadata
Rank Member
Rank
Member
mrsbrisby wrote:

It might be a better idea to convince SDL to unbuffer (or linebuffer) output on win32. I'm not 100% sure if this is necessary, but you may be able to convince them to open+append, write, close for each line written out a whole lot easier than you can convince them to hold-open a command prompt window-- that is, getting debug info from an SDL app is something necessary enough that you want anyone to be able to do it, but not so hairy that they need to download 20 megs of tools and files, recompile and reinstall stuff they don't understand just to get the last few lines of a debug list and check it against a (presently ficticious) "known problems" file

I find it interesting that you should say this. You seem to be under the impression that I want live STDOUT output to see a debug message just before DOSbox crashes. I don't but if I did, I could just use the unbuffered stdout.txt for that anyway. I want STDOUT for *live* output, stuff like 'frameskip at 8', 'CPU cycles at 6000', 'sound recording saving to xxx.wav', etc.

Quite apart from that, STDOUT seems better than a textfile because it's more flexible. Because it is, as its name might suggest, standard, it can be very easily redirected to another filehandle, displayed in a console window, both, or discarded. Why anyone would prefer even a linebuffered textfile output is beyond me.

== Jez ==

Reply 7 of 10, by mrsbrisby

User metadata
Rank Newbie
Rank
Newbie
jez wrote:

I find it interesting that you should say this. You seem to be under the impression that I want live STDOUT output to see a debug message just before DOSbox crashes. I don't but if I did, I could just use the unbuffered stdout.txt for that anyway. I want STDOUT for *live* output, stuff like 'frameskip at 8', 'CPU cycles at 6000', 'sound recording saving to xxx.wav', etc.

Quite apart from that, STDOUT seems better than a textfile because it's more flexible. Because it is, as its name might suggest, standard, it can be very easily redirected to another filehandle, displayed in a console window, both, or discarded. Why anyone would prefer even a linebuffered textfile output is beyond me.

Oh I agree; I'm just saying it'd be nice to get this information without having to modify SDL. I'm not saying that you'd want information "right before it crashed" - I'm saying that someone might. I'm not saying that you couldn't use an unbuffered text file or a linebuffered textfile for your project (and get it in a console window) - I'm just saying if it were unbuffered (or line buffered) it too would be live- and if SDL can be convinced to do this, no modifications to SDL are necessary.

As to why someone would _prefer_ a linebuffered textfile output- simply because it doesn't _require_ a console to be open. You can still open one, and tail -f it so you get _live_ information (-f means "follow").

Reply 8 of 10, by jez

User metadata
Rank Member
Rank
Member

That sounds more of a hack than just using STDOUT, though.

Whatsmore, SDL could just as easily get a console window to open in Windows if the ./configure option --disable-stdio-redirect is specified; why they don't is beyond me. Instead, they leave it to you to hack SDL to make it a console app, or the STDOUT is just discarded.

== Jez ==

Reply 9 of 10, by WvdW

User metadata
Rank Newbie
Rank
Newbie
jez wrote on 2003-09-02, 17:40:

That sounds more of a hack than just using STDOUT, though.

Whatsmore, SDL could just as easily get a console window to open in Windows if the ./configure option --disable-stdio-redirect is specified; why they don't is beyond me. Instead, they leave it to you to hack SDL to make it a console app, or the STDOUT is just discarded.

Do you perhaps have a build of your DosBox console App available for download ?
I would love to have the Standard Output available