Pete Dowson

Good. Hey, that's some phenomenally super-looking equipment you have there. You say you built that yourself? Wish I had such talents! Regards Pete

That is still only 16 seconds, not enough time for an auto-reconnection retry. What has Explorer access to explicitly shared directories got to do with firewall protection against other programs? I really cannot see any other possibility as the WideServer network code is identical in both FSX and FS9, and you just said that there's no change in the Client end. You tell me what else it could possibly be? Have you even checked yet? :-( When you are running FS9, FSX does not come into the picture at all. It is totally irrelevant. But if in that 2 years you never updated Windows then I don't think FSX would install. One of the updates to Windows automatically enables the WinXP firewall. It might be a good idea to check, don't you think? Regards Pete

I don't know of any reason not, but I don't know the CH control manager -- I don't have any CH equipment. You might want to pop over to http://www.ch-hangar.com and ask there if there are any pitfalls. Regards Pete

Which version? Sorry, I'm not envisioning what you are doing. If you are using the FSUIPC flap detentes facility then you move through the flap positions available via the little scroll icons next to the current flap number. #0 remains flaps up, and the "max" (initially #2) remains the full down. You need to calibrate the full up and full down (#0 and #2) values first, then as you calibrate the intervening values, the value 2 for full down will increment. For a 737 with 9 detentes you will finish up with #0 on the left, #8 on the right and a selected flaps detente, 1-7, in the centre. If you are using FSX you need the latest interim FSUIPC4 release from the announcement above. Please, in future ALWAYS mention version numbers, as well as FS version. Regards Pete

Can I assume that the Wideclient & Moving Map installation and files are identical (i.e. you run the same program from the same shortcut, or whatever) for both FSX and FS9? I hope so -- there is no need for any difference there. In this log: is the gap between the line of time 3141 and the line of 19360 really in the file, or have you added that to show something has been deleted? In other words, are there lines I cannot see because you removed them? Here you allowed 16 seconds only. The retry period in WideServer is something like 20 seconds, so the logs are missing any information about whether anything was detected and/or retried. Well, it is if you are using default INI files -- i.e. you have not edited them? If you have edited them I would need to see them of course. As WideClient can detect the Server, but the Server never sees the Client, it looks exactly like a firewall issue. You would need to allow FS9 and/or WideServer to receive data from your client. I suspect this has already been done for FSX, hence the difference in behaviour. The actual code driving the Network in WideServer.DLL and in FSUIPC4.DLL is the same, so the differences can only be in configuration (the INI files if you've edited them) or the Server PC's settings, and the Firewall settings are the only ones I can think would create this problem. Regards Pete

Thanks. Pete

More information would help. For instance: What "moving Map" is that -- is it a WideFS client directly, or does it use GPSout? What version of FSUIPC and WideFS are you using for the FS9 connection? What do the logs show (WideServer.LOG in the FS9 Modules folder, WideClient.LOG on the Client PC)? Have you edited INI files at all, if so show me those. Pete

I have known of cases of a corrupt WX file causing problems throughout a session. If the weather file loaded as part of your default flight is corrupted it can have strange results. The fix for that is to delete the default flight, or just its weather file, before loading FS. The same effect can be had by deleting the FS9.CFG but then you have to re-establish all the option settings. Regards Pete

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