The DOS-box config file isn't completely proprietary, it's based on Windows INI-files (which are probably based on something else), except for the "#"-comments (instead of ";").

Personally, I'm not a big fan of XML. It's bulky, and very hard to read without a tool. It has its used, but is imho highly overrated, and I wouldn't want to see it used in DOSbox.

JAL

I tend to agree - XML is getting to be a bit overused - all those tags, and usually no documentation to tell what they mean! Not to mention I have no idea how to get and use an XML editor 😢 .

An INI structure isn't much worse than XML - I really fail to see what the big differences are, other than the idea of using HTML-style tags instead of INI-style.

Cobra, I think I know why *you* think XML is of no particular use. It's because you only see ½ of what makes XML great. An XML document in itself is not worth more than an INI-file. But whenever you sit down and decide what you want your INI file to contain, you are also writing a specification for how to interprete the content. In the case of DOSBox and the INI-file, this specification is more or less hidden inside the code, or at best, described in a text document.

If you went down the XML route, your description would be in a machine-readable format known as the DTD (I have forgotten what it means - Document Type Definition I think). The DTD tells the reader (e.g. an editor/launcher/frontend) which field names that are valid in the XML (like 'fullscreen', 'machine', 'ems'), it tells the reader what type of data each field can contain ('fullscreen=<boolean>, 'fullscreen=<boolean>', 'machine=<one of auto,vga,hercules>', 'memory=<int_range[16-128]>), etc. It can even specify that each field has to contain a subfield decribing the meaning of the field.

The beaty of this is, that a generic, non-DOSBox specific, XML-editor can read the DTD, and use all this information to present you with a useable (I am not saying nice, just usable) interface for editing the DOSBox XML. More realistically, any of the upcoming DOSBox frontends, can just read the DTD and instantly know that there should be a configuration tab called 'SDL', the tab should contain 4 checkboxes named 'Full Screen', 'Full Double', 'Full Fixed' and 'Wait On Error', 2 sliders named 'Full Width' and 'Full Height', and 2 more sliders called 'HW Scale' and 'Sensitivity'.

And the same goes for all the other sections in the INI/XML file. Instead of having to update the front end whenever a new section/field is invented, e.g. the upcoming 'network' section and the 'ipxaddress' field, the front end would just need to read the updated DTD, and instantly a new section tab, with a new input field would become available in the frontend.

With an XML configuration, the XML could be loaded into a database (with a little help from an XSL document describing how a '<boolean>' field is mapped to the 'LOGICAL' datatype used in the database), together with information about which game it worked with. It would then be a simple matter to query the database for common differences in the DOSBox configuration between MicroProse games and LucasArts games.

A uniform, well-defined format for this kind of information makes a lot of things possible, things that currently are locked deep inside the actual DOSBox code.
--
MiniMax

phew MiniMax. I think you got it 😀

@Cobra & jal:
The reason for XMLs omnipresence are the nearly unlimited possibilities it provides. Of course there is nothing you cannot do in other ways but these suffer from inoperability and maintainability.

What's a good XML editor? I don't have one, I'd like to get one . . .

Also, dow do I create a DTD? Where can I get info?

Cobra, I do not have a good answer for you about the (meta) XML-editor right now. I use one at work - let me check out the name and I will post it here.

I might also have been a little in-precise in my initial response to you. Let me try to explain.

The normal meaning of the word 'XML-editor' is for a program for editing XML documents. With the help of a corresponding DTD, the XML-editor can ensure that the the resulting XML-document is valid. But it is seldom concerned with the presentation on the screen of the XML-document (except perhaps for some highlighting of the XML-tags). If you can live without the hightlighting, and without the automatic check of the XML-structure, your ordinary Notepad will do as an XML-editor.

The kind of XML-editor that I was refering too might better be called an meta-XML-editor. That is, the DOSBox XML is still constructed according to the DOSBox DTD, but the DOSBox DTD is in turn constructed according to the meta-editor DTD. The meta-editor can therefore read and understand the DOSBox DTD, and use that information to present the DOSBox XML in a semi-nice editable format. It's a bit confusing - much like bootstrapping a compiler written in its own language! But it should be clearer if I can do a cut'n'paste of the editor I use at work.

Oh, you also asked "Also, how do I create a DTD". Well, an DTD is just an XML-document, so you can just use Notepad.
--
MiniMax

For a different view on how/when to use XML - and when to not use XML - have a look at this article:

http://www-106.ibm.com/developerworks/library/x-sbxml.html
--
MiniMax

OK, well, I wait for information about "meta" XML Editor.

XML is very usable when doing data exchange, when validation of data is needed, or when doing data transformations etc. All the advantages MiniMax lists are true in a number of circumstances, but using XML in a configuration file is heavy overkill. It would be some use when a collection of programs would use the same DTD, and you'd want only one config frontend for all of them. But since the DOSbox DTD would be proprietary to DOSbox, there's really no sense in using XML.

JAL

XML is way to combursum (sp) for a simple config file. INI works fine, is perfectly readable and easy to follow. XML is too cluttered for hand reading and almost requires that you have an editor for it. Which in my book says no way. XML would be ok in the transfer of data over the internet because it's a text file and can be read back and forth between applications. .. ofcourse those are my views on XML ...

Anyone who says XML is cumbersome has missed the point by a *long* way... Another point is that the method of using a DTD to define the structure of the XML content is considered 'out-of-date'. These days it's preferable use an XML Schema which is much the same but is written in XML (rather than yet-another-language as the DTD is).

I don't think that there's any particular need to convert the config to XML format if no-one wants to. At the end of the day, it's up to the DOSBox team to see (or ignore) the benefit/drawback of any technology. An XML configuration file is potentially more flexible but will be slightly less readable.

All of my application development now uses XML files to store config data. Some elements are text whilst others are binary thus using the flexibility of XMl storage to the full. The config files are version tagged with in-built deprecated support for tags - again, something that just falls into place with the XML format.

It's long since been recognised (certainly in a Windows environment) that INI files, the Registry etc. can allow the user to do 'too' much. Therefore most application configuration elements are handled by a GUI within the application and so the user never gets to fiddle with the raw configuration data.

FYI:
A free (and good) XML editor - http://www.firstobject.com/dn_editor.htm
An XML/XSL editor (can be unstable on large files but has tons of features) - http://xmlcooktop.com/ (again, this is free). For some systems you may need to download the MSXML4 parser SDK.

For anyone who wants to know more this subject: http://www.w3schools.com/xml/default.asp

Let me add a report on the usability of xml in config files:
I'm part of the Open-Source-Project Exult (exult.sf.net) and Pentagram (pentagram.sf.net). Exult uses an xml-style config file and it is hell! I'm the maintainer of the FAQ and the Documentation of Exult and the config file is very well explained and people can look it up what each tag is meant to be.
That is fine for more advanced users, but you are aiming at end-users that have to struggle with the config file. Most of the problems users are having with the config file of exult is that it is too hard for them to use and "get" it. If we were using a plain ini-like file (like dosbox does) many, many problems wouldn't have been there.
Exult is too far gone to change, but with Pentagram we had a lengthy discussion and decided to change the config style from xml to ini (or similar).
XML-Style config would be fine when you have gui frontend for changing stuff but if you don'T have it then leave it be.