What sort of "presentation" is it that you want to hide that you're using dosbox?

Iirc SDL does the output redirection, maybe check their sources if that
can be disabled/redirected to NUL or so.

By "presentation" I just mean that I don't want extra files created that I will just delete later, I'd rather they not be created at all, since I will never have a reason to look at them. Same goes for the console window, I don't need a window opening that I don't have a reason to look at. I'm running one app, I want one window to open, keeping it simple.

As it stands right now, I can wrap the working directory of a DOS prog into a single EXE, which I love beacsue it is so clean and it is also compressed. I just click the exe and play the game and it all resides in one file. However, my save games can be saved to the same directory next to EXE and that's totally fine. The problem is that DOSBox also puts the std*.txt files in there, and it's just kind of annoying and unecessary for me.

I've tried a couple variations on piping to NUL, but I'm not sure where I'm going wrong there. DOSBOX.exe -noconsole > NUL still produces the txt files, and DOSBOX.exe > NUL doesn't make the txt files, but it loads the console. I don't want either, i.e. no reporting is necessary whatsoever.

I'm trying to complete the illusion that the program has been made "windows native" as it were, and eliminate the need to keep separate DOSprogs in their own folders, hence the portability process. As for why I'm doing all of this, call it personal preference, I suppose. I just like keeping my ancient dos progs compressed and in stand-alone EXE form. To me this seems like an ideal way to archive such infrequently used DOS applications, particularily when progs are so old that they don't like long folder names as working paths.

I have no idea what Iirc SDL means or which "sources" you suggest I check. Sorry, but could you please explain?[/b]

dosbox uses libSDL and that one redirects the output. the console generation is code of us to work around that behavior.
Technically you can compile to disable this redirection. Then dosbox will (probably, got to check the code) have no output if you have -noconsole.

Make the directory read only if you don't want output 😉

Making the dir read only will also keep me from saving games...!

If I have to recompile libSDL, then that another story. I'll have to look into that.

I assume at this point that there is no straight-forward way to do what Iwant as DOSBox stands at this time. Thanks for your help and prompt replies.

well put the game in a subdirectory below dosbox.
make the dosbox dir readonly
the game subdirectory not.
Fairly simple right ?
enter

1mount c gamedir
2c:
3game

Note that the Windows version of SDL puts the stderr and stdout files where the process executable (DOSBox.exe) is located. Typically that will be in "Program Files" or some such, separate from where the DOS games are installed, but I suspect you're bundling DOSBox.exe into these packages you're making. If you're using centralized installations of DOSBox for all of your games, rather than a separate one for each game, you wouldn't even notice the appearance and disappearance of those redirect files.

That would be fairly simple were it not for this whole business about creating a portable version of the application. One made into an EXE, the "working directory" is already essentially made read-only, so that's not the problem. The folder where the game files live aready can't be alterede as it stands now, because they're compressed inside of an uneditable EXE file. My DOS prog is being converted from a folder full of DOS files into a single compressed EXE which I find very convenient.

When the EXE is run, the app is unpacked (i.e. streamed, no temp folders). There is no directory which I can make read-only except for the folder I place this EXE into, which is also the folder I want I want my saves to land. The entire folder structure for the game resembles:

THEGAME.EXE - The entire game as one EXE
SAVES - The folder where save go, generted by the game
stdout.txt - not needed
stderr.txt - not needed

I have a couple more ideas for workarounds, but they involve using a secondary launcher/script to clean things up after execution, and as you can probably tell, I'm a stickler for elegance so I don't want to make this too complicated. What I'd really like is "DOSBox.exe -noconsole -noreport" or something like that, which would suppress the creation of these files completely without resorting to folder attribute workarounds.

My goal is to have a simple exe load the game, save games go in the same folder (or subfolder therein), and no extra files or windows are opened and created. Elegance and simplicity.

In the end I suppose I can live with these extra files since they don't take up any space, I just wish I could turn them off. That's what should be fairly simple, right?

ripsaw8080 wrote:

Note that the Windows version of SDL puts the stderr and stdout files where the process executable (DOSBox.exe) is located.

Bzzzzt!! Wrong. The stdout.txt and stderr.txt files are created in the current working directory.

Edit: ripsaw8080 is correct. I was referring to another set of txt-files. Please see below.

Bzzzzt!! Wrong. The stdout.txt and stderr.txt files are created in the current working directory.

You're incorrect about my being incorrect. You should try it before saying so. Make a shortcut with a different "start in" folder and you'll see the files are still created where the .exe is located.

Then you can look in SDL_win32_main.c and look up GetModuleFileName() on MSDN.

1pathlen = GetModuleFileName(NULL, path, SDL_arraysize(path));

SDL always creates redirect files where the .exe is located. Try it, if you're skeptical. When using DOSBox with -noconsole, it will use those same redirect files if the working directory is the same as the location of the .exe, or create another set if it's not the same. The point still stands that you can arrange it so those files don't get created amongst your DOS files.

Explain please.

1C:\Documents and Settings\MiniMax\Mina dokument\x
2> dir /b
3x.bat
4
5C:\Documents and Settings\MiniMax\Mina dokument\x
6> type x.bat
7C:\Program\DOSBox-0.72\dosbox.exe -noconsole %*
8
9C:\Documents and Settings\MiniMax\Mina dokument\x
10> x.bat -c exit
11
12C:\Documents and Settings\MiniMax\Mina dokument\x
13> C:\Program\DOSBox-0.72\dosbox.exe -noconsole -c exit
14
15C:\Documents and Settings\MiniMax\Mina dokument\x
16> dir /b
17stderr.txt
18stdout.txt
19x.bat
20
21C:\Documents and Settings\MiniMax\Mina dokument\x
22>

Look where the .exe is located while DOSBox is still running. SDL deletes its redirect files when the app closes if nothing is written to them.

Still don't understand you ripsaw. I am in directory X. I run a bat-script that starts dosbox.exe (located somewhere in %ProgramFiles%). And the files are created in the current directory (X), and not deleted.

Win32 SDL creates its own redirect files, always where the .exe is located.

When you use -noconsole, if the working directory is the same as the location of the .exe, DOSBox will "share" the redirect files with SDL. But if the working directory is different, DOSBox will create another set of redirect files in the working directory.

SDL removes its redirect files if they are empty when the app closes. If DOSBox was sharing them, it is SDL that cleans them up. Typically this means stderr.txt is deleted, but stdout.txt is not because DOSBox always writes some stuff there.

This is easy to see in operation: when you run DOSBox, leave it running and then go look in the folder where the .exe is located and you will see SDL's redirect files in there whether the working directory is different or not.

Ahhh! So many files....

How would all this work on a Vista install (or even XP) when DOSBox is installed by an administrator? Wouldn't the folder with dosbox.exe be write-protected for normal users? So std*.txt would never be created?

XZQVenus2, for your personal needs you can just change the following 4 strings in dosbox.exe to zero bytes: "stdout.txt", "stderr.txt", "/stdout.txt", "/stderr.txt".

Is there still no way to prevent these files from being created? Also is there a command I can type into my custom config file that works the same as -noconsole?

GromPE had the right answer; here's a slight modification. Open DOSBox.exe in any hex editor. Replace the strings stdout.txt and stderr.txt with

NUL

followed by seven spaces (ASCII 20) in order to blank out the rest of the existing string. The files don't get written.

MiniMax wrote:

How would all this work on a Vista install (or even XP) when DOSBox is installed by an administrator? Wouldn't the folder with dosbox.exe be write-protected for normal users? So std*.txt would never be created?

They would end up in \Users\Username\AppData\Local\VirtualStore\Program Files\DOSBox-0.74