dosbox.conf in the same folder as dosbox.exe will override the user profile one. So you can still use that if you prefer that.

Qbix wrote:

dosbox.conf in the same folder as dosbox.exe will override the user profile one. So you can still use that if you prefer that.

Awsome, thank you very much! 😀

So because in the default dosbox folder there is no .conf file, I should copy it from a profile folder?

If you want it in the DOSBox folder then yes.

It's probably best to generate a new one so:

1. Launch DOSBox as Administrator.
2. Inside dosbox type "config -wc dosbox.conf".
3. Check DOSBox folder for "dosbox.conf".
4. Make sure you give yourself write permissions to the file so you can edit it. IMPORTANT

Qbix wrote:

dosbox.conf in the same folder as dosbox.exe will override the user profile one.

That caught me out good on OSX.

I didn't notice that a DOSBox.conf had been created in /Applications, and I was tearing my hair out trying to figure out why it wouldn't use the one in my home directory.

Is there a way to get DOSBox to echo which config file is currently in use, if you don't have the console enabled?

That's exactly what the console is for. Is it off by default in OSX?

Unfortunately, whatever I do, it always creates .conf file under user profile in Windows 7. I have a wanted configuration inside C:\Program Files\DOSBox-0.74\DOSBox-0.74.conf but it still launches another one from user profile. Deleting dosbox folder under userprofile does not help.

Or am I missing here something?

Try dosbox.conf and also use a full admin account to avoid any sort of virtual storage of the program files directory contents.

IIRC the shortcut that DOSBox installs uses the -userconf parameter. You'll need to remove that if you want to use that shortcut or create a new one.

Wd: by default you don't get to see the console when starting the app bundle on OS X and there is no good way around it. The console ouput is ligged by OS X' console.app OR you have to start the dosbox binary in the app bundle which the normal user is probably not knowledgable enough. But I think dosbox readme says how to do it.

wd wrote:

That's exactly what the console is for. Is it off by default in OSX?

Basically, yeah. It doesn't open a separate console window if you double-click the bundle through Finder in /Applications

But, if you launch DOSBox from the command line, then it will output to the terminal window you started from:

1SquallBookPro:MacOS squallstrife$ pwd
2/Applications/DOSBox.app/Contents/MacOS
3SquallBookPro:MacOS squallstrife$ ./DOSBox 
4DOSBox version 0.74
5Copyright 2002-2010 DOSBox Team, published under GNU GPL.
6---
7CONFIG:Loading primary settings from config file /Users/squallstrife/Library/Preferences/DOSBox 0.74 Preferences
8MIDI:Opened device:coreaudio

The thing that was catching me out, though, is that when you double-click the bundle, "/Applications" is the current directory, and it was picking up the conf file from there; but then when I used the command line, "/Applications/DOSBox.app/Contents/MacOS" was the current directory, and the correct conf file was picked up.

Took me ages to figure out that there was a dosbox.conf in /Applications, because it showed up with the same icon as my text editor. Sneaky bugger.

wd wrote:

Try dosbox.conf and also use a full admin account to avoid any sort of virtual storage of the program files directory contents.

Okay thanks, now I got it working. The .conf file really needs to be named dosbox, not dosbox-0.74. And now it does not create anything under user profile, super!

Took me ages to figure out that there was a dosbox.conf in /Applications

I suppose one way around this would be putting the used location somewhere in the intro text (this may or may not be a stupid idea...).

I think this would be a nice idea.

DosFreak wrote:

2. Inside dosbox type "config -wc dosbox.conf".

I recently noticed that behavior in SVN builds has altered somewhat; using config -wc dosbox.conf always creates the conf file in AppData instead of the DOSbox.exe directory; seems -wcp is the required param to create conf files in the DOSbox.exe directory, now. What is the reason for this change (it breaks DBGL, and I guess other front-ends might break as well)? Would it be possible for the -wc param to behave as in DOSBox 0.74, and use another param for creating a conf in AppData?

rcblanke wrote:

I recently noticed that behavior in SVN builds has altered somewhat; using config -wc dosbox.conf always creates the conf file in AppData instead of the DOSbox.exe directory; seems -wcp is the required param to create conf files in the DOSbox.exe directory, now. What is the reason for this change (it breaks DBGL, and I guess other front-ends might break as well)? Would it be possible for the -wc param to behave as in DOSBox 0.74, and use another param for creating a conf in AppData?

UAC problem in Windows Vista / 7. By default, DOSBox cannot write dosbox.conf itself to C:\Program Files\DOSBox\ while UAC is being turned on.

With UAC on if it did not direct to the LocalAppData\DOSBox folder it would probably end up in the Virtual Store.

Thanks for your responses guys. I understand that UAC might influence this behavior, though in DOSBox 0.74 config -wc dosbox.conf _will_ write the configuration to the DOSBox.exe folder if the user has the rights to. I understand that it is good practice to use the AppData folder for user data, but I would merely suggest that the old behavior is used for the '-wc' flag (if the user has the rights to write a config to that disk location), and the 'improved' behavior with another flag.

I think rather the frontends should go with the changing times. Writing and using user data in the app folder is a big no these days and it won't change anymore.
I think Dosbox devs are right to go this way.
If you want to keep using the app folder you need to tell your users to do manual work.

If it breaks frontends these should change their behaviour. If they don't change it's a good sign that the frontend is abandoned anyway