With version .118 and before the installation use to modify the EXE.xml file to add its following statements correctly. But it did not handle the issues of EOF truncation very well; I think you all resolved this in version .120 by simply replacing the existing EXE.xml with a new one; Is this correct so far?
No. The installer hasn't changed the slightest bit. It is exactly the same code that is used to deal with DLL.XML, which has been used since Zurich has been released, it's just the file affected is EXE.XML, but the actual code is the same. So, there are absolutely no difference between the two versions.
The developer of AICArriers did not list the statements correctly in his installation of exe.xml file (see attached: exe.xml_Before_KJFK.xml); so really he's to blame.
That file is NOT corrupted! It simply have everything on a single line, which is STILL legal XML! In fact, *because* XML is *designed* to exchange data between different OS which might use different ways of indicating End-Of-Line, XML standard dictates that EOL characters are NOT required. That's why there are opening/closing tags in the first place!
However, writing back the XML file in a non-Dos standard, might confuse OTHER installers (NOT OURS!!) that, in these case, might create a *real* mess, because they parse the XML *assuming* it have CRLF linebreaks at each line, and THAN corrupting it, this time for real. So, it's not a good idea in any case.
But where your installation of KJFK is at fault is in that it doesn't recognize statements within an existing exe.xml file and merely just replaces the existing one with its own
That's not what it does. Our installer creates a new EXE.XML file ONLY if it doesn't find one on the hard drive, which is the default on a new FSX instalation. If an EXE.XML is already there, it obviously add its section to it.
HOWEVER, even if the EXE.XML created by AiCarriers wasn't really "corrupted" (if you open it in IE, is still legal XML and so is for FSX), they did a *different* type of "corruption". In our installer, we had some code to DEFEND ourselves against a slightly different kind of apparent corruption: those caused by Wilco installers, which instead convert the file from Dos to Unix line-endings. Still a legal file, but not very smart because, many of other installers were confused by this.
So, in order to fix the Wilco gotcha, we had some code that detected the Wilco-style "corruption" that is DIFFERENT from the AI-Carriers-style "corruption", which doesn't use Unix EOL chars, it simply doesn't use ANY EOL char at all..(I'm using the term corruption in quotes, to mean that is not really a corruption, but it's just a change of standard which might confuse other installers)
THIS code only took care of the "Wilco corruption" because we never heard of the other kind until now so, IN THIS CASE (and ONLY in this case), if an XML file was found with a *different* kind of "corruption" other than Wilco's, we assumed it was really corrupted, and replaced with a new one.
In ALL other cases (including after installing a Wilco product), when the XML is correct and hasn't suffered from any kind of messing with EOL indicators, we DON'T replace it, we just add our section.
So, the issue is not that our installer "replaces the EXE.XML with its own", it's just that it wasn't programmed to deal with ALL different kind of "corruptions", but just the Wilco one.
I think to have found a solution, by including a proper XML validator in the installer, that is able to deal with all cases, and by writing back the file in DOS format, it should "fix" any XML, even when it was "corrupted" by other installers.
This issue is now resolved; However, there is still one last CTD that occurs; the "Exit the Sim from the Flight CTD" which I believe is still related to KJFK but I'm NOT sure what the cause is yet; maybe you can suggest something?
I'm sorry, but I'm still not able to reproduce this. Nobody else is reporting it so far, so I must conclude it's nothing related to the scenery.
