I dunno, the conf files of Dosbox are clearly intended to be human readable. While most computer literate people can read XML pretty well, or at least get by, a newbie looking at an XML file with enumerations and such is going to be very confused. That's one important reason I could see keeping it as open text.

-Frob

True, but what newbie would really be looking at the config file source? Most people, including the computer literates, use front-ends nowadays.

Your perception doesn't match reality. No justification to move to ugly cluttered harder to read mess that is xml. Only if the objective were to flood the message board with newbs needing perpetual instruction to change anything.

It's a standard. People are moving towards standards. So, it matches reality.

MAME did it. And MAME is almost as cool as DOSBox.

No, it's a fad, it's not the standard, when most things use horrible xml, then it could be tragically called the standard. It doesn't matter that mame did it.

In my experience the xml style does NOT help. Additionally to confusing users it makes it that much harder to document if you go for readability 😀
I'm on two projects, Exult (http://exult.sf.net) and Pentagram (http://pentagram.sf.net). On Exult we are using an xml config and as the documents and FAQ guy, I can say with confidence that xml doesn't make it easier but harder. Because of that when we (a bunch of Exult devs) started Pentagram we quickly switched from the thing we knew (xml) to the thing that is much easier to use, an ini-based config file.
A little demonstration

1 <config>
2 <disk>
3  <save_compression_level>
4  1
5  </save_compression_level>
6  <game>
7   <blackgate>
8    <path>
9    ./blackgate
10    </path>
11    <waves>
12    drbgsfx.flx
13    </waves>
14    <savegame_path>
15    ./blackgate/savegames
16    </savegame_path>
17    <keys>
18    (default)
19    </keys>
20   </blackgate>
21   <serpentisle>
22    <path>
23    ./serpentisle
24    </path>
25    <waves>
26    jmsisfx.flx
27    </waves>
28    <savegame_path>
29    serpentisle/savegames
30    </savegame_path>
31    <keys>
32    (default)
33    </keys>
34   </serpentisle>
35  </game>
36 </disk>
37 <video>
38  <scale_method>
39  OpenGL
40  </scale_method>
41  <fullscreen>
42  no
43  </fullscreen>
44  <width>
45  400
46  </width>
47  <height>
48  300
49  </height>
50  <scale>
51  2
52  </scale>
53  <fps>
54  5
55  </fps>
56  <disable_fades>
57  no
58  </disable_fades>
59 </video>
60 <gameplay>

61  <skip_intro>
62  yes
63  </skip_intro>
64  <skip_splash>
65  yes
66  </skip_splash>
67  <right_click_closes_gumps>
68  yes
69  </right_click_closes_gumps>
70and so on...

1[pentagram]
2fullscreen=no
3midi_driver=windows
4defaultgame=u8
5ttf=yes
6scaler=hq2x
7scalex=320
8scaley=240
9width=640
10height=480
11bpp=32
12
13[u8]
14path=d:\spiele\dosi\u8
15skipstart=yes
16lastSave=@save/pent02.sav

Or look at the documentation at http://exult.sourceforge.net/docs.php#exult_config and http://pentagram.sourceforge.net/docs.php#advanced_ini. You will quickly spot the least confusing documentation...

And the way the config of Dosbox works right now it is very convenient, that it is so easily readable and commentable, so that users know what it is all about without having to look at the readme while editing...
And as long as there is no official frontend, and almost ALL help questions are answered with editing the config file, your

True, but what newbie would really be looking at the config file source? Most people, including the computer literates, use front-ends nowadays.

is not valid.

Well, that's your opinion. However XML is here to stay. 10 years ago you could've said it was a fad, but not now.

Being defined and validated by software worldwide confirms it is a standard. And just because of MAME, I never said follow suit. I only said that it is a standard, and standards are universally a good idea.

If you are the head developer and can say "yes" or "no", then fine. Otherwise, this feature request is for all developers to read.

In response to Dominus, that is poorly structured XML - opening and closing tags on separate lines. Plus if a newbie accidentally deletes an equal sign, they won't as easily know exactly what to fix. XML has DTD to validate and can pinpoint the error. Plus, all this stuff is freely available without needing custom code.

It's not poorly constructed but on purpose formatted to make it more newbie reader friendly. If you accidently delete something from either ini or xml you are screwed. In fact on an xml even more so, since when you are done with editing you (normal user) will want to start dosbox and not first validate the xml. So in the ini style the setting withe deleted equal sign won't work. With an opening/closing tag deleted in xml, dosbox probably wouldn't start...

There's absolutely no reason to switch to xml. If you don't like the current
layout, the sources are at sourceforge so have fun.

prometh wrote:

It's a standard. People are moving towards standards.

Text files are also standard and been around for decades.

For what it's worth standards are good and nice but don't fit every need. I just gave you an account of my seven/eight year experience with exult and pentagram (which is not yet that old) documentation AND more importantly with supporting both programs.

Fair enough.

I like XML.
It is expandable.
It is verifiable.
It is portable.
It is transformable.

And all with standard tools.

The .conf file in DOSBox fits all of those requirements.
😏

DosFreak wrote:

The .conf file in DOSBox fits all of those requirements.
😏

OH R'LY?

Please tell me how to verify and transform a config-file in the current format using standard tools.

Verify what?
Transform to what?

ih8registrations wrote:

Verify what?
Transform to what?

He is referring to common features of XML, and really the reason for its existence. XML can be self-validating in that it understands certain fundamental data types and can be extended to understand more (particularly of interest here, enumerated types in which your selection must be one of a set of discrete possibilities).

Further some standard methods exist to transform XML - process an input document against a criteria and result in a guaranteed accurate output document. A typical way this is done with XML would be via XSLT for instance.

Many of the benefits of XML exist from the perspective of the parser, not necessarily the human reader. If the dosbox authors wish to keep up a flexible parser that can put up with human input inaccuracies (weird formating, input errors) then that's their choice.

In terms of Dosbox, the only substantial tradeoff I can see is this: you lose the ability to guarantee a correct edit of the config file at edit time (which you can have with XML) versus the much more readable to a general audience nature of a straight text file. This means your edit of the dosbox.conf file can be in error and you won't find that out until run time.

-Frob

> This means your edit of the dosbox.conf file can be in error and you won't find
> that out until run time.

Doh...