Pete Dowson

Good. Happy flying! ;-0 Regards Pete

If you don't have six-pack annunciators being driven by pmSystems that won't make any difference. I only mentioned it as I wasn't sure how your backlighting was controlled. Versions 2.03 and 4.03 are now available in the Announcements above. The option to disable PFC's cooperation with pmSystems is on the first options page. It defaults to being enabled as it has been that way on all interim versions now for 18 months or so. Regards Pete

GPS data won't be requested by the Client if it cannot open the COM port you specified. Seems that COM1 is not actually available. The GPS data will be obvious when you see it. But Wideclient will not ask for it if it has no place to send it. Regards Pete

Inside the FSUIPC.ZIP file there is a User Guide document. Read the first parts of that and it will explain. Installation of an updated FSUIPC.DLL is only a matter of putting it into your FS Modules folder. It will replace the one already there. Pete

Hmmm .... that is a completely weird puzzle, then, because I only added the logging in 3.713-3.714 to find out why 3.712 didn't work. I cannot see any way that the logging part influenced the rest, especially as in the end the only fix was to replace a single call to mbtowbcs() (or something like that, I usually get the letters wrong someplace). Anyway, I haven't time to worry about it now, so i'll let it pass. Just another unsolved oddity. Regards Pete

Hmm .I don't know why you needed to re-install FS, though. Regards Pete

Maybe you have turned on the option for FSUIPC to affect FS's own weather -- it is off by default. See the Miscellaneous option page and uncheck it. Certain of the visibility options are visual effects rather than "weather" changes as such, so you may need to turn those off too -- or simply set them more reasonably so their effects are limiting on the extremes not where you'd reasonably expect changes. They won't change the visibility when it accords with the limits you've set. Regards, Pete

Hurrah! Thanks to all you Dr. Watsons, my latent Sherlock Holmes' logic succeeds! ;-) Thanks again, Pete P.S. In the 'proper' release (after Christmas now) I'll be removing the 'positive' Logging for this feature, only leaving in the logging for failure.

Yes, more to the puzzle. Thanks. I'm none the wiser, yet, but I think it may just be down to something different in the run-time libraries used by FS9 v. FSX. The filepath has to be converted to wide-character format before being used in the certificate chain, and that conversion is done by a library routine. Maybe, because I have the latest Development System installed my libraries are updated differently. In case this is it, I've changed the code slightly to supply the file handle instead of the path. Maybe that will fix it. I'll post FSUIPC 3.715 in the "Other downloads" Announcement in a liittle while for y'all to try and let me know, please. Thanks for your patience, everyone. I do need to solve this and I need your help. Regards Pete

I'm really really puzzled by this. I have the exact same certificate checking code in both FSUIPC4 and FSUIPC3 (since 3.712), and they both work fine in my systems here, yet I now have 5 users reporting that FSUIPC 3.712 or later fails on its certificate self-check (not on a user check) whilst FSUIPC4 doesn't on at least yours and probably Thomas's systems. So it doesn't appear to be bug in WinXP or its DLLs. I've tracked down the specific error being reported as from CRYPT32.DLL, and it is a file read/write error. But what that can be I've no idea. I'll be trying a few more little changes here and issuing updates until this is resolved. I feel it is important for the future -- I really want to get all my programs and modules into the same secure system if possible. (If nothing else it makes maximum use of the fees I paid for the certification, but I think it is going to be quite important for Vista in any case). Look out for 3.715 to try tomorrow. Thanks, Pete

Does that use FSUIPC? I'm afraid I know very little about it. Have you programmed anything in FSUIPC? If not then I really don't see how it can have anything to do with it. If you have but you don't know what you've done, simply delete the FSUIPC.INI file from the FS Modules folder, so it reverts to defaults. If you are not using FSUIPC 3.71 you should update in any case. Earlier versions aren't supported. Just download from the usual places, e.g. http://www.schiratti.com/dowson Please also note that there's a lot of information in the Announcements in this forum. Regards Pete

Ah, damn. That's a pity. I was hoping my WinTrust.DLL (same version number as yours but dated 2006!) was the "cure". There must be something else different. What Windows version, please? So far, of those who have told me about this, they all all still on XP SP1 or WinXP x64. All my systems are fuly up to date and are SP2 and I cannot reprodcue the problem. Are you running FSX on the same system? Because FSUIPC4 contains EXACTLY the same certificate checking code. Regards Pete

When FSUIPC won't run because of the signature check failure, the version number isn't readable through the offsets -- programs attempting it will get rubbish. I've no idea what program is telling you that "FSUIPC is too old", but it is not FSUIPC of course, but another add-in or add-on, and it is really nothing whatsoever to do with the current investigation into the signature checking problems. Please, tell me what Windows version you are using and what version your "WinTrust.DLL" is. Thank you. Pete

Thomas, this shows that the Certificate checking is failing on your system. This is why the "offsets" don't work. It is the same thing that happens when a pirated key is used or when the code is tampered with -- that is the whole point of the checking! But 3.712 and 3.714 are identical in all respects EXCEPT the logging of the signature checking, so when you say "3.712 is OK" I suspect you MUST mean 3.711 or 3.710!? If you do actually mean 3.712, please do a run with it and show me the log -- a complete log, start FS and close FS please. I have made no other changes between 3.712 and 3.714 except for the extra logging, and that is all done during initialisation, and there is no way I can see that logging the errors in the signatire check makes it fail if it succeeded before! :-( Are you running FSX on the same system? Because FSUIPC4 contains EXACTLY the same certificate checking code. Regards Pete

It is most certainly a Networking problem, because there is nothing else that WideFs is doing which is going wrong. If it isn't being blocked it most certainly isn't working correctly, and I'm afraid I am not enough of a Networking expert to diagnose it from here. Have you been through all of the hints in the documentation I provide? They have been collected over the years from user's submissions -- i.e. from practical results. The documentation embodies ALL I know about networking, and some things I don't know. It may even be a driver or hardware fault, so re-installing or swapping things over may show things differently. I myself have had three Network cards go faulty over the years, and the symptoms they gave were similar -- messages blocking, sumcheck errors, timeouts. Check all the settings. If you want more advice on Networks you may find that Katy Pluta, on the FS2004 Forum, can help -- I've often had to ask her myself. If I was in your position I would be using a trial and error approach, trying each thing in turn till I found out what was causing the problem. One of the first things to do is see if there are any other processes running which may interfere with networking. You can set "Log=DebugAll" in both INI files and generate very large logs, but you won't get any more details about the errors that are occurring, simply because if errors occur they are logged anyway. It may help to see the context in which they do occur. But if you do this, keep things very short or the logs will be too large to plough through! Regards Pete

It's a message from FS itself, and it usually means the gauge file is missing or corrupt (hasn't got the requisite exports). Did you check it was actually there, in the Gauges folder? Regards Pete

Yes, there are now two of you. John's is the same error. That error number isn't in the main programming references I have, but a search via Google found this: 80092003 CRYPT_E_FILE_ERROR Error while reading or writing to the file Which is very strange. Why would the certificate system have problems reading or writing the file? Is it protected in some way, read only or anything? I don't think that affects it in any case. I am very suspicious of this, and I am concerned that it is actually a WinXP bug which has been corrected in a later version. I will have to contact GlobalSign, the Trust Authority for the signing facilities I use, to see what can be done. This may take a while. :-( That's certainly later than John's (which is 5.131.2600.0). Mine is 5.131.2600.2180 dated Feb 28th 2006. Strange that it is a lot later but your version number seems higher! Odd or what? It might be worth, in both your cases, to try just replacing that one DLL. Rename it and download the update from someplace like http://www.dll-files.com/dllindex/dll-fl?wintrust which is the link I gave earlier. That site has the same (up to date) version I am using (5.131.2600.2180). Could one or both of you try, please, and let me know? Otherwise, and this is less likely, possibly the GlobalSign certificate, which is supplied as part of Windows, is corrupted in your systems. That really does seem most unlikerly, though, and I'm not sure how you'd repair that. You could try right-clicking on te FSUIPC.DLL, selecting Properties, Signature, details, then "Install", to see if it can install the Root certificate properly. Regards Pete

INI files don't change in any interesting ways. They only record defaults. Unless you change them. Do you? It doesn't look like it. The logs don't show anything different. Sorry. Regards Pete

That's it then. Sorry. Over to MS Support I'm afraid. Pete

Hmm. Sounds like Enrico's version is ignoring the relevant SYSVAR variable settings. That's a bit sad. Easy enough to fix, though, if you don't want those subsystems handled. You just need to add logic to copy the pmSystems SYSVAR offset changes back to the FS offsets. I would have thought he would do that by default for variables he is not handling. I may need to tackle him about that after Christmas, but it is not a good time now. Sorry. Meanwhile I'll add the option to bypass pmSystems altogether, as I said. If you don't have a pair of sixpack annunciators it wouldn't have made any difference in any case. If you did have, the added PFC treatment is simply a superset of Enrico's defaults, but the extras would depend upon parts of the pmSystems logic which are only in Thomas's files in any case. Regards Pete

Well, before you fire up FS again, please check in the announcements above. Look for FSUIPC 3.714 or later. I am now adding more persistent logging in the case of a signature problem, and if there are any errors they will appear in your normal FSUIPC Log file, without the need for DebugView. Don't bother before tomorrow though -- take the rest of the day off and fuss the wife! ;-). Just don't use 3.71 next time. Let me know when you have a result, and show me the Log then, please. Regards Pete

Well, I think i said you need to check them, not actually delete them and start again! ;-). And I think I was clear that only applied to the recent change to AXIS assignments, which doesn't come into Button assignments -- they certainly haven't changed. If you still have your old INI file accessible, try cutting and pasting your old [buttons] section from the old INI file into the new one. Regards Pete

That certainly sounds like you are assigning them in FS and have the sensitivity less than 100% and/or the null zone set off zero.

Meanwhile I found the problem. The number of flaps used in the detente setting part was not beinig initialised in the SimConnect data read section, even though the displayed number of flaps was1 The maximum number of flaps was therefore set wrong. Duh! It'll be fixed in FSUIPC 4.065, probably late tonight or more likely tomorrow. Regards Pete

Something else is wrong then. Well, it it the Client which connects TO the Server, so perhaps this shows the blockage is on the Desktop. something is getting in the way, for sure. FSX didn't run at all? I'm wondering if something in your Network Settings on the desktop are wrong. maybe uninstalling and re-installing your Network card & drivers would sort something out? Yes, please tell me what happens. I'd like to know what the problem turns out to be! Regards Pete