I was asking bout the extention, that babylon-shoes's post

I don't see anything about extensions or firefox in his post.

Foxpro --- Firefox... Whats the difference, 🤣. Poor chap got confused by the look of it, like I once did when going into a shop and asking for a Snickers when I really wanted a Mars Bar 😉

DosBox is great (though I've only recently discovered it 😳 I didn't find any difficulty in using it, but was a DoS man for many years. My own opinion is that DoSBox should be as complex as it needs to be for maximum compatability and let the front-end writers deal with the people who are unsure how to work DoS or DoSBox.

Cheers

I have to confess, that although I run a Sierra-music based website I actually don't use DOSBOX. But it's only *partially* laziness and that I don't quite get everything about it, it's mainly that I have both a Windows 95 PC and that most Sierra games will run fine (in XP) without DOSBOX.

However I love DOSBOX for the simple reason that it has aided many in getting beloved oldies to work. Specifically lots of obscure games that doubtlessly would have died if such effort had not been put in by the devs/testers.

And I'm sure I'll need to use it sooner or later. <g>

ANd the newbie-code made me smile, but seriously- don't do it. If there's one thing tech-ignorant, lazy people hate being told, it's that they're.. tech ignorant and lazy ;B

- Spike

P.S. Edit: I have actually used it for Inca, that wonderful obscurity from Coktel. And countless obscure platformers.

Weird, I never came across anyone who hates DOSBox.

I'm not sure if this was mentioned but you might want to add to list "User mentions he is leaving forum never to return again."

I'd like to point out that while most users don't read the readme file, dosbox is indeed badly "packaged" for new users.

There is no config file initialy, the user tries and tries looks around and eventualy has to read the readme. Why not just give them a config file during the installation? is it that bad?

Ok, so the user spent 30 minutes trying to figure out how to get a config file and now he doesn't understand most of the options. The config options have very limited documentation. For example: "core -- CPU Core used in emulation: simple,normal,full,dynamic.", ok so what am i supposed to understand from that in order to make a choice?

Finished with the config options, i run dosbox and get a weird drive letter and i can't find anything... another 30 minutes wasted trying to learn how to mount stuff. So why is it so hard to have a default mount that (under Linux) loads the home directory? or under Windoze it loads the "My Documents" or whatever? It also makes it easy for the user, while reading the default configuration to just change the paths to whatever he likes...

So, game runs badly, too slow or whatever. Why use only 3000 cycles by default? why not 5000 which is enough to run properly? Especialy with the new patches for dosbox, people will be able to run at 10000 cycles...

I'm not trying to be insulting towards the developers, to the contrary, dosbox is an amazing application with features we couldn't even dream about (SDL, multiplatform, hardware and software compatibility, etc)..

BUT...

the developers could leave excuses behind and with a few minor changes make dosbox soooo much friendlier for new users, that i bet my avatar image, will cut all hate messages down to half. Even support requests will fall...

sehh wrote:

There is no config file initialy, the user tries and tries looks around and eventualy has to read the readme. Why not just give them a config file during the installation? is it that bad?

Not a bad idea really, but different setups call for different config file arrangements. And honestly, the file's named "readme" for a very good reason.

sehh wrote:

Ok, so the user spent 30 minutes trying to figure out how to get a config file and now he doesn't understand most of the options. The config options have very limited documentation. For example: "core -- CPU Core used in emulation: simple,normal,full,dynamic.", ok so what am i supposed to understand from that in order to make a choice?

The config file documentation could be a bit better sure, though once again readme and just looking at the online faq covers all of this.

sehh wrote:

Finished with the config options, i run dosbox and get a weird drive letter and i can't find anything... another 30 minutes wasted trying to learn how to mount stuff. So why is it so hard to have a default mount that (under Linux) loads the home directory? or under Windoze it loads the "My Documents" or whatever? It also makes it easy for the user, while reading the default configuration to just change the paths to whatever he likes...

Considering that dosbox has full control over it's mounted region this seems like a terrible idea really. Again, just glancing over the readme would cover mounting.

sehh wrote:

So, game runs badly, too slow or whatever. Why use only 3000 cycles by default? why not 5000 which is enough to run properly? Especialy with the new patches for dosbox, people will be able to run at 10000 cycles...

Different games have different needs, as do different computers. Only x86 users get the dymanic core. 10000 cycles doesn't run all that beautifully on a PPC system or anything else that can't use the dynamic core. Again, just read the readme. It's not much to ask people and it seems that the default options should be useable on any system.

sehh wrote:

the developers could leave excuses behind and with a few minor changes make dosbox soooo much friendlier for new users

What's so much friendlier for one user isn't necessarily going to be for others. If people don't want to bother reading a file called readme they're not being very friendly in the first place I think.

I bet there's some quiet agreement on this already from some of the developers, but I'll add my opinion... I think it's best to make it easiest for as many people to use as possible -- Even the ones who won't read the readme and then go to forums and moan. I wish they were able to get things running happily and I don't care to change their philosophy. There's a vast number of tools around, and many people will never feel it's best to start learning the details of all of them. This is not a bad strategy and in at least one sense, I find them rather wise. To be honest.. though I've got no trouble using dosbox (since I used DOS a lot in the past and have done plenty of various development), I'm kind of upset when I'm left with no recourse but to read a readme. It's simply not necessary and is sort of inefficient in that it offloads work onto scores of users where it could have been avoided through a lot of work by a developer or two. There are ways to give this information to the user in the interface, or at least put enough in their hands to allow them to experiment and find what works.

For me the issue is ultimately with how people want to spend their time. If you get into the development.. do you enjoy writing documentation, creating help systems, and adding user-friendly GUI's? Most probably not. Some of this isn't of any interest or use to a developer at all -- Wherever that's done in unsponsored opensource software, it's purely a gift, and these things shouldn't be solicited from anyone. That said, making dosbox more accessible needn't take anything away from those who would have no trouble handling it in its current state. It's just a pain to implement it all. Furthermore, it's a maintenance issue in a changing system. There's the matter of when to say enough is enough, and to sync the visible/accessible state with the internals.. and a little more delay is added to that process when the interface needs updating.. which prompts screams from the very users for which it was intended.. and the cycle of pain is complete. (or something -- anyway, there's my 2 cents.. 😀)

Someone mentioned adding a default mount. I think it's a good idea to have dosbox ship with a subdirectory for programs, containing one small (freeware) dos application for test/example purposes. It'd be easy for the user to see that this coincides with what's seen on the host drive, which is a big aid for understanding. In the default conf, this would be mounted as C.. and Z would be in the path for access to those commands. Starting up in C, potentially with DOS apps on the drive, would make dosbox appear more like DOS - sort of an improvement to authenticity anyway. The startup screen would ideally describe 'dir' and 'cd' clearly, and mention where the visible subdirectory can be found. This would be familiar to anyone who's dealt with a 'roms' subdirectory in the past. 'Expert' users can ignore/delete this config, and go on with life as usual.

Of course there are many other ways that things could be made more usable.. This is just one idea.

Edit: I actually think doing the default mount through a regular mount command in the conf is probably not a good idea, since it must be relative to the dosbox root, and it would be bad to hardcode that into the conf because the user may move the dosbox directory sometime. Perhaps an extra 'mountrelative' command, an alias for the dosbox root, or some other sort of useful hackery could be added. My preference would be 'mountrelative', since an alias which references the host filesystem would only be useful for the mount command anyway, and would likely cause terrible confusion.

augnober, i think you've explained what i'm trying to say in much better english. Indeed, if the developers could invest some work on those little changes then it would make dosbox a bit friendlier to new users.

neowolf, i think we just have conflicting ideas about software development. Thats not necessarily bad. Obviously you want to force new users to read the readme file. My opinion is to make software as intuitive as posible in order to cover a wide range of users, thus avoid forcing the user to read the documentation. I personaly do something similar to what augnober mentioned, make the interface informative enough so that the user "learns" while working with the application.

Anyway, we are beating a dead horse here (i think thats the right expression?).

Someone mentioned adding a default mount. I think it's a good idea to have dosbox ship with a subdirectory for programs, containing one small (freeware) dos application for test/example purposes. It'd be easy for the user to see that this coincides with what's seen on the host drive, which is a big aid for understanding.

You propose a "Games" directory under the DosBox directory. (I say games because dosbox is not designed to run "Programs").

Thing is DosBox under alternative operating systems doesn't have it's own directory.....so therefore you'd be littering your filesystem with a Games directory in the wrong place.....or make assumption about where to place the "games" directory on the host system.

DosBox isn't just about selfish Win32 users.....it's for EVERYBODY. The minute you have the main DosBox project specializing in specific platforms is the minute that DOsBox development for alternative platforms suffers.

You want an optimized Win32 build? BUILD IT. The source code is there for everyone.

In the default conf, this would be mounted as C.. and Z would be in the path for access to those commands.

Again, under alternatives OS's there would be no DosBox "Games" subdirectory. You'd have to have DosBox create one in the users Home directory or whatever. So right there we'd waste time figuring out what the standard directory for DosBox games should be......which would interfere with the way that you should be using DosBox wich is to use seperate .conf files for each game.

Z:\ is already in the PATH statement. It's not really that big of a deal. If users cannot read the README or type HELP then that's their problem.

Starting up in C, potentially with DOS apps on the drive, would make dosbox appear more like DOS - sort of an improvement to authenticity anyway.

"Starting up in C:\"? Your making assumptions......Ideally each game should have their own DosBox.conf so therefore each "C:\" would be different.

The startup screen would ideally describe 'dir' and 'cd' clearly, and mention where the visible subdirectory can be found.

Ideally Windows/Linux on bootup would describe every possible command relative to what they need....WTF? Obviously that wouldn't work. If a user who does not understand DOS see's "DIR" or "CD" on startup they still won't understand it. They'll need examples (Hey!, Sort of like typing "INTRO" in DosBox!). An extensive tutorial is beyond the scope of the DosBox Intro. That's NOT THE PURPOSE OF THE INTRO.

This would be familiar to anyone who's dealt with a 'roms' subdirectory in the past. 'Expert' users can ignore/delete this config, and go on with life as usual.

No, newbies should not be altering .conf files anyway. This is why God...err D-Fend author created the FrontEnd D-Fend......To me a frontend is more confusing than editing dosbox.conf manually. To a newbie the frontend is probably easier.

Of course there are many other ways that things could be made more usable.. This is just one idea.

Exactly. Just one idea.....and there are many ideas possible. The problem is figuring out which ideas are the most optimal and cross-platform. This isn't just about Windows.....thank god.

DosFreak,
Yeah, it's best not to interfere with other platforms. I made the assumption that someone will package a release for each platform independently at each point release. To my knowledge, no one is officially responsible for each platform.

My reasons for mostly choosing to work on consoles or Windows would be off-topic. I'll just in short that it's because that's what my friends and family tend to use, and that's important to me. Keeping other platforms healthy and active is equally important.

I'll add that we're all aware that this issue of supporting the inexperienced is most prevalent in Windows - whether it's mentioned or not. If choosing to tackle it, it's a point of focus. Keeping dosbox working on all other target platforms is a constraint which must be kept in mind, and solutions that will benefit all platforms are best. I like your ideas, so let's not try to break down the discussion since there are possible improvements to be made.

Ideally DosBox would have PhysFS (games are contained in .zips) bult into it.

User would drag-n-drop .zip onto DosBox Icon.
Game specific dosbox.conf would be contained in the .zip.

DosBox would automagically write to current directory (since .zips are read only), or write to TMP directory if cannot write to same directory.

But unfortunately no DOS games are formatted as such and probably will never be. Relegating PhysFS to users who already own the games and have bothered to zip them, knowing WTF PhysFS is and how to use it.....

The best and easiest option at the current time would therefore be to use a frontend with game specific configuration files (a central site with dosbox.conf's for each game and only the specific entries needed), and mabye a search program integrated into the frontend to search for these games and then setup each game and use the specific dosbox.conf entries for each one.

Therefore a cross-platform frontend with these capabilities would be the best option for DosBox.

Of course we then have the problem of DosBos development changing so rapidly that a DosBox.conf create for a game today may not apply to in the future......(Don't think we have to worry about this too much tho....need to look through my game list and think about it).

Hmm.. I'm not a big fan of the PhysFS approach, though it would have some usefulness. As you mentioned, not all users will have them.. and the true game owners would have to give themselves the hassle of packaging their own zips (distribution of the packaged ones would afterall be a violation of copyright in many cases).

I think it's best to abstract each game config away from dosbox. For example, a King's Quest 1 config would perhaps specify a 286, a certain MHz value, EGA, 4:3 aspect ratio, a plain US keyboard, whatever. This is the kind of information that separates PC emulators from console emulators. The relevant info for configuration could have been written back in 1988, and is not dosbox-specific in any way. User preferences and host capabilities could be taken into account in generation of the final configuration used by dosbox internally. In practice, I believe it would be best to have each configuration specify a certain 'best' target configuration, and also a range of target platforms which were able to run the game adequately. This is because many games really targetted more than just a single target system, and it would be best to facilitate allowing users to experience any one which is desired while still supplying guidelines. The range portion is advanced functionality however, which should probably be in a file separate from the particular target config. The important point is that this information is not dosbox-specific, and if an adequate amount of information is supplied, could be written just once with no future revisions or maintenance required. This point is something which makes it so a definitive game target-system database is a real possibility and something of potential value (it would be subject to improvement and never become obsolete). Dosbox itself, a version conversion utility, or a frontend could be responsible for the interpretation/conversion of this type of configuration. As a bonus, it would be nice to allow for this final config to be written to disk and hand-tweaked.

To all the "how dare you requiring us to READ" shouters:

DOSBox is a sophisticated emulation environment more complex than many other programs in that area. It is a tool, and like every tool, you have to LEARN how to use it. The problem is that DOS was complex and unser-unfriendly. An emulator can only be more complex than the original.

Look at ZSNES for example. How complex was the SNES? A Power switch, a cartridge to swap, one or two controllers, not even enough buttons for all letters of the latin alphabet. How complex is ZSNES? There are tens, maybe more than hundred options, for something that in the original had 3 simple elements. Keep this in mind and look at DOS: almost 30 years, thousands of different hardware combinations, millions of software configurations. And that's the original - how can you expect that a DOS emulator experience is even nearly as easy as ZSNES? Try running a game under XP - wait, you probably tried, funny thing, it didn't work, eh? Even though it's closer to the original?

The config file wasn't made by some anal developers who like to torture mere users, but because every option in there is actually needed. Picking up the example of the "core" option, the docs in the config file are not meant to teach you everything you should know about it, but to help you remember what you have learned (you did read the docs, did you?). If the default cycles value is raised, some users will shut up, while others will start whining that their sound is broken. Gain: null.

The problem is not in how DOSBox was designed, but that the environment we try to emulate spans 30 years and millions of possibilities. It can't ever be easy. Plus, we're not even as far as providing complete emulation. One of my favourite games (Frontier: First Encounters) doesn't work and might never work. The DOSBox developers care about the Tool, not the Experience. And a clean separation of duties has evolved: DOSBox does everything to RUN better, while frontends and non-programming volunteers help at making it better USABLE. If you don't like to read a README and if you find a config file too troublesome, use D-Fend, period. That's what it was made for.

And now something which will probably make you happy: There are people working on userfriendliness. I myself am doing something which will still take a month or two, but which will improve DOSBox user experience vastly. If you want to contribute, there has already be a discussion about how to make DOSBox installation more user friendly on windows. Search the forum, I have outlined a way to make a very good installer, autoconfiguring DOSBox as far as possible, without modifying DOSBox in any way. Search for that post (I think in the wishlist thread, or in here), and create that installer. It is clearly possible, and it follows the silent agreement: DOSBox concentrates on emulation, and others, like you, work on user experience.

Sorry for being verbose, I am in a hurry.

augnober wrote:

Hmm.. I'm not a big fan of the PhysFS approach, though it would have some usefulness. As you mentioned, not all users will have them.. and the true game owners would have to give themselves the hassle of packaging their own zips (distribution of the packaged ones would afterall be a violation of copyright in many cases).

PhysFS is totally painless. It's nothing that you need to have, it's just a DLL shipped with DOSBox, like SDL or all the other things used by DOSBox.

Use a correctly prepared shortcut and you can Drag'n'drop ZIP files. Use a correctly prepared [autoexec] section in your single, global dosbox.conf, and you can have dosbox reconfigured and your game started automatically. (requires CVS for on-the-fly reconfiguration)

That's how I use DOSBox every day. The things are out there, ready to use. See the PhysFS patch description for more details.

Batch files containing the neccessary commands to configure DOSBox for a given game and to run it properly can be distributed without any problems. And no one wants to distribute the games themselves, after all you'd want to play your own version, not that of some stranger.

This is in reply to DosFreak's post a ways up. I haven't read the rest of the discussion yet, so sorry for jumping in in the middle:

DosFreak wrote:

DosBox isn't just about selfish Win32 users.....it's for EVERYBODY. The minute you have the main DosBox project specializing in specific platforms is the minute that DOsBox development for alternative platforms suffers.

If that were 100% true, then the dynamic core would be a bad thing, as it isn't supported on non-x86 platforms. Of course it's best to make the platform-independent aspects of DOSBox as robust and optimized as possible, but sometimes you still have to work around the quirks of particular platforms. I trust that both the devs and the community will move DOSBox in whichever direction technology moves in to keep it working optimally on whatever platforms people are interested in playing DOS games on.

You want an optimized Win32 build? BUILD IT. The source code is there for everyone.

Some people want to play games rather than build executables from their source code (I like to do both 😉). Those people shouldn't expect to have their needs catered to, but I still respect their ability to ask about it on the forum (as long as it's done politely).

"Starting up in C:"? Your making assumptions......Ideally each game should have their own DosBox.conf so therefore each "C:" would be different.

Now you're the one making assumptions. My own preference is to have one folder/directory (which I mount as C:\) with subdirectories for each game, and to have a single dosbox.conf that I tweak just a little for whichever game I'm trying to run.

Also, it's bad to mount a game's directory as C:\, as some games actually expect to be installed in a subdirectory. No sane person would have installed all their game files to the root directory of their C: drive under real DOS (although I did hear rumors of people who did this, I never actually saw it).

The startup screen would ideally describe 'dir' and 'cd' clearly, and mention where the visible subdirectory can be found.

Ideally Windows/Linux on bootup would describe every possible command relative to what they need....WTF? Obviously that wouldn't work. If a user who does not understand DOS see's "DIR" or "CD" on startup they still won't understand it. They'll need examples (Hey!, Sort of like typing "INTRO" in DosBox!). An extensive tutorial is beyond the scope of the DosBox Intro. That's NOT THE PURPOSE OF THE INTRO.

Both are valid points, but consider this: Would you rather mention DIR and CD in the intro, or answer as many posts in the forum as we've been seeing about related questions...

HunterZ wrote:

This is in reply to DosFreak's post a ways up. I haven't read the rest of the discussion yet, so sorry for jumping in in the middle:

DosFreak wrote:

DosBox isn't just about selfish Win32 users.....it's for EVERYBODY. The minute you have the main DosBox project specializing in specific platforms is the minute that DOsBox development for alternative platforms suffers.

If that were 100% true, then the dynamic core would be a bad thing, as it isn't supported on non-x86 platforms. Of course it's best to make the platform-independent aspects of DOSBox as robust and optimized as possible, but sometimes you still have to work around the quirks of particular platforms. I trust that both the devs and the community will move DOSBox in whichever direction technology moves in to keep it working optimally on whatever platforms people are interested in playing DOS games on.

My post was concerning DosBox development focusing primarily on Windows users.....Dynamic core was included in DosBox because X86 to X86 is far easier than X86 to PPC/ARM/Whatever. I don't have statistics but I think it would be safe to say that most of the DosBox userbase are using X86 processors. Obviously the most used hardware/platform will effect DosBox development in some ways. Thankfully the lack of dynamic core for other processors doesn't affect DosBox Compatibility....which is the main thing.

"Starting up in C:"? Your making assumptions......Ideally each game should have their own DosBox.conf so therefore each "C:" would be different.
Now you're the one making assumptions. My own preference is to have one folder/directory (which I mount as C:\) with subdirectories for each game, and to have a single dosbox.conf that I tweak just a little for whichever game I'm trying to run.

Also, it's bad to mount a game's directory as C:\, as some games actually expect to be installed in a subdirectory. No sane person would have installed all their game files to the root directory of their C: drive under real DOS (although I did hear rumors of people who did this, I never actually saw it).

Not sure about this. I haven't done extensive testing (I plan to) but all of my games in .ZIP using Physfs seem to work fine as "C:". No reason for them not to since most game are only concerned with the files in their directory structure.

I think you can agree that one single DosBox.conf is not the best configuration for new people.....simply because newbs shouldn't be using the .conf file. Ideally this would all be behind the scenes and controlled through the GUI, loaded automagically through the GUI for each game.

DosFreak, there are a few games which don't work in C:\, my collection of several hundred games (over a time of 10 years) has one or two of them.