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
DOSBox 60 seconds guide | How to ask questions
_________________
Lenovo M58p | Core 2 Quad Q8400 @ 2.66 GHz | Radeon R7 240 | LG HL-DT-ST DVDRAM GH40N | Fedora 32