Config writes a file to whatever directory you started dosbox from. So if you exit dosbox, you should find the files aaa and lll there. (Though it would be a good idea to use dosbox.conf as the config file name. Anything other than that or the file .dosboxrc in your home directory only and while running Linux only, will require you to tell dosbox to look for whatever you call the config file when you start dosbox.)

And if you are trying to write to the directory that you are running in, you will need rescan (Ctrl-F4) the directory to adjust for any changes. But in this case, you might as well shut down dosbox, and edit the file under Linux.

Assuming that you leave the dosbox.conf in your home directory, it would probably be a smart idea to only use sub-directories for mounting, just in case something goes wrong, or some application decides to delete files.

Maybe change title to user seems broken?

While I thank you for your feedback, on this platform at this tmie, it is incorrect:

roland@linux-uz4n:~> cd /
roland@linux-uz4n:/> sudo find -name aaa*.*
root's password:
./home/roland/stuff/aaa_base-11.1-10007.11.x86_64.rpm
find: `./home/roland/.gvfs': Permission denied
./etc/ssl/certs/aaa45464.0
./windows/D/os/root/i386/aaaamon.dl_
roland@linux-uz4n:/>

roland@linux-uz4n:/> sudo find -name lll*.*
find: `./home/roland/.gvfs': Permission denied
roland@linux-uz4n:/>

config simply isn't generating any output on 64-bit OpenSuSE 11.1

Here is the answer.

OpenSuSE 11.1 (and probably many other Linux distros) add DOSbox to the KDE menu. When it is launched from there, it doesn't have a user writable directory. I can get output if and only if I start dosbox from the command line.

I would have expected some kind of priv/protection error when the other write was unsuccessful.

seasoned_geek wrote:

I would have expected some kind of priv/protection error when the other write was unsuccessful.

Sounds reasonable. Please submit a patch.

I advise everyone about using PNG files for screenshots.

As far as i see the checks for a writeable output directory are fully functional:

1MSG_Add("PROGRAM_CONFIG_FILE_ERROR","Can't open file %s\n");

Look back at the screen shot. You will see no output file was created and no error was issued.

I believe this is all because whoever put the RPM together had DOSbox install itself on the menu without acquiring the value of $home for the user when it gets launched.

OpenSuSE 64-bit 11.1 is free, so it's a matter of having the time, spare machine, and energy to prove it out if you don't believe me. If you have another RPM based distro to check it out with and you are running 4.x of KDE where they have the little menu, click on the K button, type DOS in the search box, then click on DOSbox to launch, use a file name you have never used before and see if CONFIG gives you output.

My guess is the menu entry isn't configured properly upon install. I believe this points the "default" output directory to NUL. You don't get an error or output because everything gets routed to the bit bucket.

Then I would suggest running dosbox from a terminal, and contacting whoever built that rpm for OpenSuse 11.1. They are the ones you should be talking to.

That's what I love about the OpenSource community. The OpenSuSE forum points the finger here and when one comes here, they point the finger back at the OpenSuSE people. So much gets resolved. It is a vast improvement over having multiple commercial vendors involved in the equation. 😳

DOSBox doesn't host distribution specific Linux builds so therefore DOSBox isn't to blame, whoever compiled and packaged DOSBox for that Linux distro is to blame.

http://sourceforge.net/project/showfiles.php? … lease_id=535033

It's the same as if someone downloaded the Windows build from sourceforge, extracted all of the files and created a custom installer that didn't work right. User downloads this and then blames DOSBox for the issue.

The DOSBox devs have better things to do than create specific builds of DOSBox for all the distributions of Linux.

Only way around this issue to to have a compile and packaging system that created distro specific packages. I think I remeber seeing that somewhere once. Problem there is they would still have to be tested. The issue really is with the Linux distro's themselves not using a unified package manager for all distros.

Hell, you can use an installer from Windows 3.1 all the way up to Windows 7 and it will still install on Windows. No reason it couldn't be the same for Linux. I'm sure it's like most things just a matter of priorities.

Perhaps you might say where they suggested coming here? It could be seful in opening lines of communication.
Because in looking at the OpenSuse forums, I found
http://forums.opensuse.org/applications/41418 … talled-rpm.html
In which they suggest either filing a bug report to OpenSuse, or contacting the packager.

http://forums.opensuse.org/applications/41418 … talled-rpm.html

message 8

The only "link" in that output sent me to sourceforge which ultimately lead me here.

Every distro has the same *&^)(&)*(Uing problem. Some group of OpenSource developers hacks out a package/tool/product for whatever reason. They test it on their own machines, post it somewhere, but wash their hands of building official bundles for distros. Each distro will add some of those packages while they are new, assign someone to be a "maintainer", they will set up some kind of automated feed for updates, and that's it. Nobody tests anything after that point.

With the token few exceptions of OpenSource products put out by huge corporations paying developers to work on them, it doesn't matter what package you choose, if the developers don't build official releases for the few distros they use regularly, what gets sent out with the actual distro release is busted bad.

If you want to have a very good laugh and are running OpenSuSE, you should try installing BOINC from the official repositories. It doesn't work and hasnt' worked in years. Anyone who wants to use it has to build their own from the official BOINC site. This is only one example, but it is a good one...nice and flagrant. Pick any distro you want and a person can find hundreds, if not thousands of examples in the "officially bundled software".

From what I can tell, the RPM for DOSbox should have worked prior to KDE 4.x. Menu stuff changed. Aparently the maintainer didn't bother to test.

Then again, should DOSbox be smart enough to know its default directory is the NUL device and issue warning/error?

From that output, personally I saw two links. One for the dosbox project, and the other for bug reporting. (Though perhaps it was tweaked or created by the forum engine after posting, or is browser-specific?)
The section
"Submitting Bug Reports - openSUSE"
shows up on my browser as a link to http://bugs.opensuse.org

That's what I love about the OpenSource community. The OpenSuSE forum points the finger here and when one comes here

You said that. As MiniMax already pointed out, check out the problem on
your system, put up a patch, and everybody will benefit. That's what the
open source community is all about. Not "i have a problem, they fix it".

Hell, you can use an installer from Windows 3.1 all the way up to Windows 7 and it will still install on Windows.

Really? I thought since they've done away with the 16-bit programs support in Vista that should not work anymore 😀

Dominus wrote:

[Really? I thought since they've done away with the 16-bit programs support in Vista that should not work anymore :)

AFIAK that only applies to the 64 bit version of vista.

It did not show up that way for me and when I clicked I ended up in Sourceforge.

Older Windows installation program ceased working when the Registry was introduced. The registry was redefined (almost completely) in XP which caused another round of Install-Shield and similar product upgrades. You can get a "new" version released with one of those installers which will install in any version, but you cannot take the version which was actually released with an older Windows version and get it to install...well...it might think it installed...but it won't run correctly.

Of course, if your application is single directory simple and doesn't have to install stuff all over the Windows directory tree, it doesn't matter.