Fresh update experience;

 

I was notified of an update once my aircraft was loaded (with no FSX restart comment in the brackets) and I decided to go for it since it was a GA flight and it did not matter if loose ten minutes or so. First thing I forgot, was that you have to switch to a windowed mode in order to see and click the buttons in the installer. Otherwise it is impossible to know about the update process and proceed at all with it. Ok, got it installed and returned back to my plane with a Couatl restart suggestion in front of me. I pressed go ahead and nothing happened and I pressed cancel or later or whatever the "go away" alternative was. It was stuck.

I did not want to fly that couatl interface as my HUD, so I choose sim restart. From first go fly-press I was back twelve minutes later with succesful update (I hope). Not so smooth as in the manuals...

Surely the elephant in the room is the fact that there's a thread titled   "I Loathe FSDT's COUATL!" with 361 posts which shows no signs of ending.

 

Surely the elephant in the room is the fact that there's a thread titled "I Loathe FSDT's COUATL!" with 361 posts which shows no signs of ending.

Perhaps, but about 182 of those posts are reasoned and polite responses from the developer, with explanations and offers of assistance.

I can honestly say I have had next to zero problems with FSDT/Flight Beam sceneries. They have worked pretty much as advertised with very few problems (no more than I have had with other developers for example)

 

I will add this, GSX sometimes bugs me and the auto update can be annoying. But now that I have learned how to shut that off it shouldn't be a problem.

 

Just my 2 pennies guys.

 

 

Perhaps, but about 182 of those posts are reasoned and polite responses from the developer, with explanations and offers of assistance.

 

Unfortunately only about 35 posts are from the developer - not 182. But don't let the facts get in the way.

No wonder LM has got rid of this in P3D...

 

They didn't get rid of OS security context.  P3D or FSX ... the entries Virtuali adds in the EXE.XML and the DLL.XML run under a security context you have NO control over.  Trying to run installers/updaters from within a security context you don't control is going to be problematic (best case) ... even more so with variables such as OS version and group policy settings and anti-virus software.

 

It's a nobel idea to attempt to AutoUpdate from within the P3D/FSX, but I've done similar attempts (different product but similar context -- nothing to do with FS) and the OS will sometimes not return a failure code, just a valid status which is supposed to indicate all is good when in fact it is not ... Microsoft are purposely vague in some environments when it comes to security blocking (for obvious reasons, don't want to give malicious hackers any clues). 

 

Further more, as security holes are plugged in Windows (via Windows Updates) those updates can affect existing "legit" processes from operating correctly.  In the end, it was just too unreliable to attempt to do anything from within the security context of another application I had no control over.

 

Take this for what it's worth to you Umberto ... but I have been there, done that, and it was so problematic I went an alternate route.  I'd suggest you consider not trying to AutoUpdate from within FSX/P3D ... do what most other 3rd party vendors do, run their updates outside of FSX/P3D -- it'll reduce your support time.

 

Rob

They didn't get rid of OS security context.  P3D or FSX ... the entries Virtuali adds in the EXE.XML and the DLL.XML run under a security context you have NO control over.

First, it's not the same if it's the EXE.XML and the DLL.XML and, but in both cases, this issue is not that we don't have any control over it, because we don't have it on FS9, FSX and P3D just the same.

 

Fact is, that neither FS9 nor P3D triggers any certificate verification themselves and, as I've said, there's some kind bug in FSX that appears ONLY when the module IS digitally signed, to generate bogus "unsafe 3rd party module" messages. I got them randomly here and then from every 3rd party module from every developer, pmdgoptions.dll does that, lvld.dll does that too and bglmanx.dll does that too, occasionally.

 

NONE of this is happening under FS9 and P3D. Which is quite telling in case of P3D, since the bglmanx.dll executable is bit-by-bit identical to the FSX one. Nobody ever saw the infamous 3rd party module alert in P3D, with any module from anyone so, there IS a difference between the two.

 

Not that this has any relevance to your point that our modules "finally" were digitally signed, as you said.

 

They have been digitally signed since FSX was released, that was the point of my clarification; you made it sound as if, since we "finally" decided to digitally sign modules, we might have improved reliability in some way. Well, not really, because of that bug (and just to be absolutely precise, my research shows the bug is more likely to happen with *Comodo* certificates which, incidentally, is one of the most popular provider of authenticode certificates...), we only improved the end user peace of mind, so users will at least KNOWN if the executable they have is the right one and, for example, hasn't been corrupted/altered, which is a feature in itself, but it has such side-effect (ON FSX ONLY), but I guess that it's best risking to get that message *sometime*, rather than present the other, more scarier, red flag about the "unknown publisher"...

 

Trying to run installers/updaters from within a security context you don't control is going to be problematic (best case) ... even more so with variables such as OS version and group policy settings and anti-virus software.

That's not the case.

 

- The auto-update that starts from FSX DOES NOT run in the same security context as FSX. The Couatl_Updater.exe file is started from FSX, but it start its own security context that we DO have control over, because that exe is flagged to ask Windows to permission to escalate with admin permission. This will of course trigger the standard UAC question, possibly asking user/password of an admin user, in case the logged user is not an admin. So, if the user allows it, it will run in its own security context, and it the user will not allow it, it will just not run.

 

- The auto-update that starts from FSX DOES NOT try to modify files that might be opened or in any case under FSX control.

 

THAT'S why we have the concept of "minor" and "major" updates.

 

The "major" update is one that can modify files that might be controlled by FSX, like the bglmanx.dll or the Couatl.exe, or the scenery AFCADs, and THIS one asks to QUIT from FSX, it simply won't run with FSX running, you will only get the NOTIFICATION of its availability, but it won't try to do anything until you quit FSX, download the updater and apply it with FSX not running.

 

The auto-update that starts from FSX, is what we call "minor" update, and this one (the Couatl_Updater.exe, running in its own separate security context with admin rights) will NOT try to update anything that FSX might use (bglmanx.dll and its open files) or that might still running (Couatl.exe and its opened files). It will ONLY try to update the Python code files, that are entirely safe to update, because they are not kept open while the Python interpreter is running, they are *copied* in memory when the Couatl.exe starts and are executed from RAM so, the copies on the hard drive can be updated freely, because they are not locked. I guess we might have an idea how the Couatl interpreter loads its own files in memory, since we wrote it...

 

And, of course, to have the code updates being applied without an FSX restart, the Couatl.exe itself is restarted by the updater. That's not obviously something brutal like just killing the process and restarting it, but it's a proper mutex system as it should be.

 

Further more, as security holes are plugged in Windows (via Windows Updates) those updates can affect existing "legit" processes from operating correctly.  In the end, it was just too unreliable to attempt to do anything from within the security context of another application I had no control over.

As I've said, we are in control of the security context the updater works under, when referring to the one that starts from FSX.

 

And we have an entirely different update method (quit FSX, download the updated Stand-Alone Addon Manager, and install that one without FSX running) to update things that *might* be more tricky to update while FSX is running, anything executable that interacts with it, basically.

 

Take this for what it's worth to you Umberto ... but I have been there, done that, and it was so problematic I went an alternate route.  I'd suggest you consider not trying to AutoUpdate from within FSX/P3D ... do what most other 3rd party vendors do, run their updates outside of FSX/P3D -- it'll reduce your support time.

We don't have much support issues related to the self-update procedure, it's probably one of the areas that requires less support.

 

The N.1 support issue BY FAR ( like 90% of the issues ) is antivirus interference. The most common cause of the remaining one, is problems with runtimes libraries missing/corrupted/conflicting with other runtimes, and finally general trouble with user configuration, like the example I've made before. This covers probably 99% of the support cases, the self-update is really something that we don't have much issues with, the only issues are some users annoyed by the frequency of the updates, but that's not really an issue, both because the whole self-update notification can be turned off entirely, but also because the update can be ignored.

 

If I don't turn on my desktop PC for a week or two (it happens, I usually do all my work on the laptop), the first start take ages because, I get self-update notifications from Windows Update, Adobe Acrobat, Java, Apple QuickTime, Java, Dropbox and Steam, sometimes all trying to start at the same time...

 

Fact that other developers don't try to do self-updates without FSX restarting, doesn't mean it would be the best for us too.

 

Most of the other FSX products that would need updates to begin with, are .EXE/.DLL/.GAU executables, or scenery .BGLs or textures, and these are ALL things that we DO NOT try to "update from FSX" too.

 

But since we also have lots of code running an interpreter running in a separate process that we can quit and restart independently from FSX, we CAN use this chance to offer the so called "minor update", which offers users the CONVENIENCE of having some kind of updates (not really "minor" ones, the whole GSX code, for example, can be updated this way) being applied without restarting FSX so, why not taking advantage of it ?

 

It looks like a complex explanation, but in fact it's very simple:

 

- We PROMPT (the user is always in control to accept the update or not) to update what we CAN, without restarting FSX. That's the "minor update"

 

- We PROMPT to update what we CAN'T (or that might not entirely foolproof to do) update while FSX is running, asking to quit from FSX and download and install the new update. That's a "major update"

 

If you still don't trust this system, and you are still concerned about updating from FSX, regardless of my explanation, the solution is very simple:

 

IGNORE ALL THE MINOR UPDATES, and just do the MAJOR ones!

 

Since a major update INCLUDE all the minor updates too, that's your "do what most other 3rd party vendors do, run their updates outside of FSX/P3D"...simple.

Surely the elephant in the room is the fact that there's a thread titled   "I Loathe FSDT's COUATL!" with 361 posts which shows no signs of ending.

 

I propose this thread be merged with the ubiquitous Windows 8 Joystick thread as the thread to end all threads. Their combined weight might be enough to drag both debates down to a watery grave.

 

"With our combined strength, we can end this destructive conflict and bring order to the galaxy!"

First thing I forgot, was that you have to switch to a windowed mode in order to see and click the buttons in the installer. Otherwise it is impossible to know about the update process and proceed at all with it.

Ok, I must say that this comment has been quite useful. We might add a check to force the user to switch to Windowed mode, and not starting the update if the sim is running in full-screen.

 

The issue is, whether you can see the installer dialog (it's not really the installer dialog, it's basically the UAC window asking if you authorize the the updater to start) or not, depends both on the video drivers and how they behave in full screen AND by other FSX add-ons you have running in the background, especially those with the bad habit of forcing themselves to be always on top of everything, which is a questionable behavior (what if *several* programs all competed against each other to be always on the foreground ?)

 

But yes, I can take this as a suggestion for an additional safety check to add, so you are not supposed to *remember* to put the sim in Windowed mode first.

 

Ok, got it installed and returned back to my plane with a Couatl restart suggestion in front of me. I pressed go ahead and nothing happened and I pressed cancel or later or whatever the "go away" alternative was. It was stuck.

I'm not sure if this was a side-effect of the full screen issue but, I assure you this doesn't happen normally and doesn't seem like a very common issue, since nobody ever reported it to us.

 

But even in this case, there's always the "Restart Couatl" menu option, which is basically a panic button in case something happens that appears as if the program got "stuck" for any reason, keeping the concept of trying NOT force you to restart FSX, if not absolutely necessary.

It's really too bad that the wanna-bees continue to peck away only to be proven wrong time and time again. You would the think that the bees would give it a rest after awhile.

It's really too bad that the wanna-bees continue to peck away only to be proven wrong time and time again.

 

Agree, you would think wouldn't ya Jim  :lol: ... re-install your OS, yep that'll fix it!  Have you tried turning it Off and On again LOL!  15 pages deep and you really feel there isn't a problem ... oooookay.

 

Umberto has tried to explain away several issues with inaccurate and/or partial information ... BUT I'm not interested in getting involved in long technical discussions and a game of "he said you said" with him about security context and how and why his product is problematic - I'm not selling, I'm not the vendor.  He seems to have his mind set on how it works and that is that, we're all wrong ... not really much to debate or discuss is there?

 

But your mission Jim appears to be consistent at least ... not sure why it exists or what it does for you, but to each his or her own.

 

Cheers, Rob.

Umberto has tried to explain away several issues with inaccurate and/or partial information

Why would on earth would he do that for, seems to me  that he has answered all your questions but you seem to ignore them completely or don't want  to believe him. At least he came in here an answered your questions. Maybe you can link us  where he  has answered your question inaccurate .    You keep saying  that re installing the o/s is not  an option well maybe,  maybe  that will fix your issue  than again you don't want  to try since it  may work and will prove some thing

Perhaps, but about 182 of those posts are reasoned and polite responses from the developer, with explanations and offers of assistance.

...if you need 182 posts to explain then I'm afraid something is not right!

Why would on earth would he do that for, seems to me  that he has answered all your questions but you seem to ignore them completely or don't want  to believe him.

 

I know this is a long thread, but just to remind you my original response #2 in this thread was to offer a possible solution to Manny's problem with Virtuali.  It's unfortunate that we're on Page 15 now -- perhaps Umberto needs to ask "why are we on page 15"?

 

http://forum.avsim.net/topic/419631-i-loathe-fsdts-couatl/?p=2784583

 

I've provided my own solution and shared that solution.  My solution isn't an exact solution because the exact problem has not been identified - this is where I would hope Umberto would be more proactive in trying to identify rather than reactive to end user input.  But my solution is a lot less work than a blanket solution to re-install one's OS (which may or may not work once 100's of Windows Updates and security patches are applied after a fresh OS install).

 

Something to consider on the accuracy front:

 

1.  What method is being used by FSX.EXE and/or the Prepar3D.EXE to make the call to launch the executable it finds in the EXE.XML (where Couatl.exe is referenced)?  Do you know?  Does Umberto know?  I've used a dependency walker and that doesn't show anything about what method is called, nor does the SDK give specifics.  There are several ways to start a process (another executable) from within C#/C++ compiled product (aka FSX/P3D) ... these are "some" (not all) of the ways:

 

CreateProcess

CreateProcessAsUser

System

ShellExecute

 

Each one of these methods has a different security context which is managed by the OS .. they are not all the same.

 

2. FSX/P3D doesn't manage the security context, security context/restrictions are ALWAYS managed by the OS (if they weren't Viruses would be abundant).  An Executable can only operation in a context they ask (important ASK the OS) to work under ... and it's more than just a user prompt difference.

 

Clearly Umberto has a different understanding, so be it (happy to leave it at that) -- I know what works for me and I really don't want to get into lengthy discussions (too late I guess) about something I've already solved myself.

 

Cheers, Rob.

You keep saying that re installing the o/s is not an option well maybe, maybe that will fix your issue

Couatl, Couatl, how do I love thee? Let me count the ways. I'm certain the counting will be short lived and the week+ of labor required to reinstall my OS will not be numbered among them.

 

It's mind numbingly laughable - borderline retarded to me (oops, there I go spouting the 'r' word again: looks like another ban is waiting for me) - that this is even batted around as a viable support option. Only slightly less retarded is the fact that this thread has been allowed to linger in perpetuity for this long. Guess we all love a good pig roast