FSUIPC4 Concerns

[Joshua Robertson]

I have a few questions about FSUIPC4 that I would like answered.

1. Is FSUIPC4 going to be released only as an installer package or will it retain the non-installer zipped format of its predecessors?

2. Is FSUIPC4 going to work with FS2004, FS2002, etc. or is it only for FSX?

3. How much will a registration key be for FSUIPC4?

Regards,

Joshua Robertson (Creator of FS Real Time)

3D Softworks Design Studios

http://www.3dsoftworks.net

[Pete Dowson]

1. Is FSUIPC4 going to be released only as an installer package or will it retain the non-installer zipped format of its predecessors?

Installer. This is only because there is no place in FSX for it to be installed -- the installer makes such a place -- and because installation involves editing of an XML file which may or may not already exist. If this is not done, FSX will not run FSUIPC4 so it won't be any use. I'm afraid there's no way to do it by simply copying over a DLL.

2. Is FSUIPC4 going to work with FS2004, FS2002, etc. or is it only for FSX?

Only FSX at present -- hopefully all future versions of FS as well. It is a completely new version.

3. How much will a registration key be for FSUIPC4?

It has been set at 24 Euros (plus VAT in the EU), a small increase from the original price for FSUIPC3 set over three years ago.

Regards,

Pete

[Wizball]

Hi..

Is it possible to preorder the FSUIPC4 ?..

So that I have the key when its ready for release?

Best Regards

Tom Stian Bjerk

[Pete Dowson]

Is it possible to preorder the FSUIPC4 ?..

So that I have the key when its ready for release?

Sorry, no. Don't worry, it will all run with super-efficiency from the 'Go'"! ;-)

Pete

[Joshua Robertson]

Installer. This is only because there is no place in FSX for it to be installed -- the installer makes such a place -- and because installation involves editing of an XML file which may or may not already exist. If this is not done, FSX will not run FSUIPC4 so it won't be any use. I'm afraid there's no way to do it by simply copying over a DLL.

In that case, will it be possible to create 2 versions of the distributable package? One as an installer that anyone can use and the other one as a zipped DLL with instructions for editing the proper XML? The reason I ask this is because I'd like to continue incorporating FSUIPC within the FS Real Time installer and that may not be possible if FSUIPC is now distributed with its own installer program.

Regards,

Joshua Robertson (creator of FS Real Time)

3D Softworks Design Studios

http://www.3dsoftworks.net

[webbm]

Thanks for the answers here Pete. I had the same questions in my mind.

Matt.

[Pete Dowson]

I'd like to continue incorporating FSUIPC within the FS Real Time installer and that may not be possible if FSUIPC is now distributed with its own installer program.

Why? You can include the installer and execute it.

As well as being sure the DL.XML is correct, my code checks for a later version of FSUIPC4 and won't overwrite one -- something which has been a real pain in my side when I allow others to install. Maybe you take care of such things too, but it is by no means a general practice.

Please, tell me why your installer cannot run the FSUIPC4 installer?

Pete

[Luke Kolin]

Please, tell me why your installer cannot run the FSUIPC4 installer?

We'd rather not be spawning external programs from our installers, when they are perfectly capable of doing the same thing as the FSUIPC installer. All of our installers currently detect the currently installed version of FSUIPC, determine wether an upgrade is necessary and prompt the user accordingly, without the additional overhead of a seperate installer.

I recognize and sympathize with your concerns and ensuring that installers behave responsibly. This is critical to ensuring that users have a positive FSUIPC experience, but I would very respectfully suggest that the solution is to provide complete documentation to third-party developers (just as you have to FSUIPC itself) and then ensuring (through cooperation and shaming) that we meet the same high standards as you.

The end-user experience is critical to us as well, which is why we want to have control over the entire installation process instead of merely spawning an external process that can probably only give us a "TRUE/FALSE" result. We want to work with you because our goals are the same. I've offered before and repeat now my desires to publicly release NSIS sources to our installers' FSUIPC installation code, so that other can "do it right" as well.

Realistically, the installer will never operate in a vaccuum. It won't take too long to reverse-engineer the changes it makes to a vanilla FSX installation (just like in the past), which is a situation where you cannot control what others do. Documenting and recognizing that other installers will want to install FSUIPC by themselves I think provides a better level of control for you, and better outcomes for everyone.

Cheers!

Luke

[webbm]

I agree a merge medule would be handy, but Pete's suggestion is fine.

The FSX installer (for the betas anyway), does launch the installation of the C++ runtimes as seperate, so it can't be a big issue.

In the long run; as long as everything installs correctly, the customer will be happy. :)

I'm sure people have posted problems regarding FSUIPC installation in these forums when they have been installed by our 3rd Party installers. I think it is in Pete's best interest (and the customer's) that he have full contol over how his product is installed.

Matt.

[Pete Dowson]

We'd rather not be spawning external programs from our installers, when they are perfectly capable of doing the same thing as the FSUIPC installer. All of our installers currently detect the currently installed version of FSUIPC, determine wether an upgrade is necessary and prompt the user accordingly, without the additional overhead of a seperate installer.

And what about the creation of the Modules folder in FSX, which doesn't exist initially, and the creation or editing of the DLL.XML file in the same folder as each and every instance of the FSX.CFG file?

There is much more to installing modules in FSX than there ever was in previous versions of FS. I do not want to have to support your installers because you don't get it right. You show me your module installer working, and then I'll consider supplying just the DLL (not that you cannot get it for yourself, of course, after running my installer).

If you want to know how to do this, simply look at the SimConnect documentation in the FSX SDK, supplied with the Deluxe Edition.

Pete

[webbm]

Sorry Pete - another question.

Will the installer detect previous versions of Flight Sim and install FSUIPC Version 3 for FS98-2004, or will it be seperate install packages - one for SimConnect (v4) and one without (v3)?

Thanks,

Matthew.

[Pete Dowson]

Will the installer detect previous versions of Flight Sim and install FSUIPC Version 3 for FS98-2004, or will it be seperate install packages - one for SimConnect (v4) and one without (v3)?

Separate packages. The current FSUIPC will stay as it is now, with development slowing down as we concentrate on FSX and the future. I will still support FSUIPC 3 in terms of answering questions and fixing bugs, but I cannot see much in the way of new facilities and especially not new FS data being added when there is so much potential in new FSX products.

Regards,

Pete

[webbm]

No worries - My installer will be able to check the version of FS.

Thanks for your top support.

Matt.

[Pete Dowson]

No worries - My installer will be able to check the version of FS.

For FSX there is more to it I'm afraid. SimConnect uses side-by-side installation, with multiple versions possible. FSUIPC4 needs to match at least one of those (preferably the latest, as that would give the best service/facility). Furthermore, SimConnect uses the Manifest system to be sure that it only loads programs compiled to run with one of its installed versions.

My installer does these checks using manifest probes. It all seemed rather complicated to start with, but was simplified immensely by upgradng to MSicrosoft Studio 2005 -- the 2003 version I've been use for FSUIPC3 (and still am) does not handle manifests much if at all.

All in all these are the steps my installer goes through:

1. Finds the path to FSX via the Registry -- asking the User to locate FSX.EXE if the Registry is not correct in this regard.

2. Checks the Version number of FSX.EXE is adequate.

3. Via the assorted probe manifests built in as resources, uses the CreateActCtx and ActivateActCtx/DeactivateActCtx APIs to make sure the SimConnect part will 'mesh' okay. These manifests are, by the way the Installer is compiled as part of my FSUIPC4 project, always inclusive of the actual run-time checked manifests built into FSUIPC4 itself.

[This is where I'm not sure how your installer, built separately from FSUIPC4, could reliably cope. If MS had no plans for any interim updates to SimConnect it wouldn't be such a problem, but I don't think it is the case -- at least I most certainly hope not!].

4. Checks whether there is already a Modules folder with a later version of FSUIPC4 already installed.

5. Creates the Modules folder if necessary and copies FSUIPC4 in.

6. Finds all of the user APPDATA paths which have an FSX.CFG installed, for each one found either checking an existing DLL.XML file to see if it already loads FSUIPC4 (otherwise inserting the appropriate lines), or, if no DLL.XML yet exists, creating one with the sole purpose of getting SimConnect to run FSUIPC4.

7. Finally copies some documents and other files into the Modules folder too.

Now, whilst I am not saying that your installer can't do all these things, I would be concerned especially about steps 3, 6 and 7.

I honestly cannot see why you are objecting to spawning my installer, just like most of MS's own installs spawn DirectX and other installers when they are run. If you wish to run it invisibly, with error or success codes returned, that can certainly be done via some command line switch. Why not think about it and say what you need, rather than rush in and complain about the fact that I need to have a little more control on installation with FSX?

Regards

Pete

[webbm]

Sorry, I meant that my installer will detect that FSX is installed and execute your installer as necessary, or just copy the .dll for FS98-2004. :)

Thanks for the info though - it shows how much thinking is behind the various processes - both from yourself and Microsoft - and gave me a greater understanding of what is happening...

Cheers,

Matt.

[Pete Dowson]

Sorry, I meant that my installer will detect that FSX is installed and execute your installer as necessary, or just copy the .dll for FS98-2004. :)

Ah, yes. Fine. That's cool. Acually, looking back up the thread I should have been clearer. My comment "I honestly cannot see why you are objecting to spawning my installer" was really aimed at LukeK, who I hope is still following this.

Don't forget you can have different versions of FS installed simultaneously. On one of my PCs I used to have FS98, FS2000, FS2002 and FS2004 (oh, yes, and CFS1 and CFS2) all installed and operational. you can only run one at a time of course.

On my current machines I only have FS2004 and FSX installed, excepting one remaining still with FS2002. ;-)

Regards,

Pete

[webbm]

Don't forget you can have different versions of FS installed simultaneously. On one of my PCs I used to have FS98, FS2000, FS2002 and FS2004 (oh, yes, and CFS1 and CFS2) all installed and operational. you can only run one at a time of course.

On my current machines I only have FS2004 and FSX installed, excepting one remaining still with FS2002. ;-)

Good point - I didn't think of that. Thanks Pete!

[Luke Kolin]

Ah, yes. Fine. That's cool. Acually, looking back up the thread I should have been clearer. My comment "I honestly cannot see why you are objecting to spawning my installer" was really aimed at LukeK, who I hope is still following this.

Thanks for the outline, Peter. I agree with your concerns that FSUIPC installation is not trivial when compared with previous versions. Based on a quick review of things, I agree that #3 and #6 are the most likely to have issues.

For #6, I'm already digging through the AppData folders to get the FS9.CFG, so adding another entry for DLL.XML and manipulating it won't be too hard. I then have to loop through and modify ALL of these files, but that's probably good practice if I'm installing something like FSSOUND.DLL.

For #3, since I haven't done more with the SimConnect API than install it on my PC, I need to examine this some more. If the functions needed to validate the SimConnect version are publicly exposed in the FS DLLs, then I believe our NSIS installers can call them just like we would any other part of the Win32 API. I already do so to detect FS running and multiple installer copies by checking for window handles and creating semaphores. If I've misread what's involved in step #3, I apologize in advance. I'm going to dig through some more.

Again, I think a silent version of the installer (perhaps with an optional parameter to supply the location of FSX) would probably be OK, but my inclination as a developer is to determine what is going on under the covers and ensuring that I am doing it right and can validate that the install is successful. I certainly don't want to cause additional headaches for you Peter, but I am also interested in ensuring that FSUIPC4 operates under the existing FSUIPC install framework we have.

Cheers!

Luke

[Pete Dowson]

If the functions needed to validate the SimConnect version are publicly exposed in the FS DLLs, then I believe our NSIS installers can call them just like we would any other part of the Win32 API.

Not FS. It's actually nothing to do with FS. With this manifest system it seems that unless the DLL has a manifest present which matches at least one of the side-by-side installed versions of SimConnect, then the DLL will simply not get loaded.

I embed the manifest into the DLL as a resource with a specific ID -- there are different specific IDs for DLLs and EXEs. I think a simpler alternative is to install a .manifest file alongside the DLL or EXE. However, apart from being one more file and one more thing to go wrong, that system seems precarious. I can't see any way to be sure that an external manifest file represents the true dependencies of that specific version of the DLL or EXE. It makes no sense to me doing it with a separate file.

The installer has the SAME manifest embedded, but with a different ID which stops it being subject to any version checking. This manifest is used to test out what would happen if the check on loading were really to take place -- a "probe manifest" (apparently). The probe takes place by using those Windows API functions I mentioned.

This all took me ages to sort out (time I would much rather have spent doing more interesting things with FSX), and that was with plenty of help from the SimConnnect author himself.

Again, I think a silent version of the installer (perhaps with an optional parameter to supply the location of FSX) would probably be OK

Write to me later, when I'm over this hump, and we'll sort something out. Maybe by then you'll have resolved all this for your DLL in any case?

but my inclination as a developer is to determine what is going on under the covers and ensuring that I am doing it right and can validate that the install is successful.

I can explain as much as you like, and/or return different codes for different problems in the 'silent install'. But I am still inclined really to try to keep control over the actual FSUIPC4 install. But I may change my mind. Let's see.

Regards,

Pete

[Luke Kolin]

I can explain as much as you like, and/or return different codes for different problems in the 'silent install'. But I am still inclined really to try to keep control over the actual FSUIPC4 install. But I may change my mind. Let's see.

That sounds just fine by me. I'm drinking from a firehose here and I'm probably going to take a serious stab at things once you release your installer and I can get some ideas of what should be done and the manifests you are embedding in your file.

Looking a little further, it looks like the ACTCTX calls are kernel32 functions, that appear to be XP and above. Again, I don't see a problem calling those but I'm going to wait and see what you do with your installer and take baby steps from there. I appreciate your willingness to help out here.

Rest assured, I have no intentions of putting out a crappy product that will cause you support headaches. It reflects poorly on both of us, deservedly so for me, and not so for you. I want to ensure that you have confidence that my installers do the right thing, just like they have done for v2 and v3.

Cheers!

Luke

[Pete Dowson]

Looking a little further, it looks like the ACTCTX calls are kernel32 functions, that appear to be XP and above.

YesFSX needs Windows XP or Vista. It won't run on anything earlier.

Regards,

Pete