That's what I thought, but I would also assume that other users would experience the same problem. Yet, when I go to the relevant forum I haven't found anything on it. It is possible I didn't look enough, but one would think it would be all over their forums...
Oh yes, this is a known problem:
http://ops.precisionmanuals.com/wiki/How_to_Fix_Your_FSX_DLL.XML_File#How_does_the_DLL.XML_file_get_corrupted.3FDon't know if it applies only to Wilco 737PIC, or also to the E-Jets.
However, if you want to know the REAL reason, here it is:
- It's probably not Wilco's fault *alone*. Perhaps is the combination of installing Wilco AND ActiveSky together. Try it...
The reason:
Technically, opposite of what many might think, Wilco installer doesn't do anything "wrong", after installing Wilco 737 (and maybe E-Jets), the DLL.XML file is not "corrupted", is STILL a valid XML, this can be easily tested by the simple fact that FSX can still read it and loads all the modules, and that IE can read it as well.
BUT, text files can be of several kinds, depending on the OS they are used, and there are different standards which have emerged over the years, with regard to how to handle a new line. Ms-Dos/Windows uses the CRLF (Carriage Return + Line Feed) wich are 2 characters, to indicate a new line. Unix uses just the LF and MacIntosh uses CR only...If you read a text file that was created on a Unix system, on Windows, it will appear as if it had all text on a single line, and this is exactly what happens to DLL.XLL after installing the 737PIC, that's why it was thought as "corrupted"
BUT, XML files are NOT text files! More precisely, they are like text files, but were *designed* to allow easy interchange of data between different systems and OS, so they need to be PARSED taking into account this, not as they were simple text files! Opening/closing tags are there for this reason, so a parsing program shouldn't worry about the concept of lines and line breaks at all.
From what I recall, Wilco use the DOM (a service that comes with Windows) library to read and write XML, which is probably the more logical choice. However, this backfired on them, because MS DOM library, to conform with universal standards on XML, starting from a specific release, didn't use the CRLF combination anymore to break lines, but switched to LF only, in Unix style (which is the more used on web servers, were XML use reigns). This means, if a program uses MS DOM library to open an XML file, reads all its nodes, make any modification, and write it back, the file will be written back in the "Unix style", and programs like Notepad will show it as if wasn't properly formatted, with everything on a single line. Of course, any serious text editor will recognize it as a proper Unix file, and IE will also open it correctly and FSX will too, because an XML in Unix style is STILL valid XML.
However, many installers (including the first releases of our own), usually because of limitations in their script engine which might or not allow complete XML parsing, or simply because the developers weren't aware of this issue, treated the DLL.XML always assuming it HAS to be a Windows file, with line breaks with the CR+LF sequence, and parsed it as a text file based on that assumption. This wouldn't work if the DLL.XML was converted to Unix (by the Wilco installer or, better said, by the MS DOM library which was called by the Wilco installer).
So, the *real* corruption DOESN'T happen after installing Wilco, but when you install ANOTHER product, which has an installer that gets confused by the DLL.XML file formatted in Unix style!
Technically, Wilco didn't do anything really "wrong", because the DLL.XML as Unix file is still valid and readable by FSX (which of course uses the MS DOM as well to parse it), they simply forgot to take into account that other installers might be fooled by this and then REALLY corrupting the file.
What we do in our current installer is this:
- We first just SCAN (without doing any modifications) the DLL.XML file, validating it with MS DOM. This action is entirely harmless, because the file will not be modified in any way, it will be simply read and analyzed for correctness. If this validation results in a problem, it means the file is REALLY corrupted, so we STOP doing anything else to the DLL.XML, and print a warning message so the user will know his DLL.XML was *already* corrupted before launching our installer.
- If the first validation passes (which is valid even for a Wilco-processed DLL.XML), we CONVERT the file back to Windows style so, even if the user ran Wilco before, it will not risk having problems with *another* installer that is not so smart to validate it first and to check how line breaks are handled.
- Once we converted it back to Windows style, we finally parse it, because it's now safe to assume its format, having just converted it to Windows, and we add the Addon Manager line, if it's no already present.
If another installer (for example ActiveSky's) is not doing this, and parse the file as being a text file always assuming it is of the Windows kind, you are going to have problems with it, because that would probably really corrupting it.
That's why you probably don't see that many posts about this, to have the issue, one probably needs to install Wilco and then ActiveSky in this sequence. If you, for example, install Wilco, then our Addon Manager (which put the file back into Windows format), then any other addon, the issue will not appear.
So, if anyone thought that making installers is easy...
