Board index FlightGear Development

For Developers: Windows Install and Runtime Best-Practices

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

For Developers: Windows Install and Runtime Best-Practices

Postby jharris1993 » Fri Apr 19, 2013 2:52 am

(NB I am sure that someone will want to move this to "Documentation" or something like that. However, I would like to suggest that it be placed where the developers, instead of the documentation maintainers, can clearly see, and have easy access to this document. Thanks!)

Issue:
  • The majority, if not all, of the developers on the FlightGear project are Linux developers. (Which isn't a bad thing.)
  • The Windows development, installation, and user paradigms are significantly different than the various Linux paradigms.
  • The result of this is that the developers and package maintainers who build the Windows installers make assumptions about how the packages should install and run that are not necessarily true within the Windows environment.
  • This also results in a, (ahem!), "less than optimal" installation, configuration, and run-time experience for the Windows user.

Therefore, the purpose of this document is to illustrate the various "best-practices" that help you as developers, package maintainers, and configuration managers develop installers and executables that work efficiently and smoothly within the Windows environment.

The result of all this will be to help:
  • Make it easier for the typical Windows user to successfully install and use FlightGear - which will help expand adoption of this excellent software.
  • Reduce maintenance headaches since - being installed correctly the first time - there is less to go wrong.
  • Make it easier to maintain when something does go wrong, since the necessary information will be more easily found.
  • Significantly improve the over-all user experience, helping to improve the reputation of Open Source (FOSS) software in general.

It might be interesting to note that, at the very least, some of these ideas can be carried back to the Linux installs as well.


Topic #1: Installation "Bitness"

It is important to carefully distinguish "bitness" (processor word-size), when installing any kind of software. The best-practices for respecting processor word-size during installation can be summed up by the following:
  • Make sure that you do not accidentally install software that depends on a 64 bit system on a 32 bit O/S. (I am sure there are API calls, or installer macros that can be used to test for this and throw the appropriate errors.)
  • If installing a 32 bit binary on a 64 bit system, make sure to install into the "Program Files (86)" directory as the "Program Files" directory is exclusively reserved for 64 bit executables on 64 bit systems.
  • TEST: If there is a C:\Program Files (86)\ directory, it is very likely a 64 bit system.

Even though you can install executables wherever you wish, and they will still work, installing them to the correct executable folders will help people understand if they are 64 or 32 bit executables later on.

Note:
This test will also work with earlier versions of Windows. Since they are all 32 bit systems, the installer will never find the "Program Files(86)" folder. (There is an exception: Win XP-64. IMHO, anyone who is still running WinXP-64 is an absolutely blithering idiot, and deserves what he gets.)


Topic #2: Correct Usage of the Program Files and Program Data folders

(Note: This particular issue still catches even seasoned Windows developers. :roll: :lol: )

In Linux, a user process automatically has write privileges in a number of different directories all over the filesystem. Unlike Linux, the write scope for a non-elevated, (non root), process in later versions of Windows is very narrowly defined.

Here is how the write-scope of these directories are defined:
  • Rule 1: NEVER, NEVER, EVER place anything in the Program Files directories except for STATIC binaries and STATIC data.
  • Rule 2: Non-elevated programs or processes should NEVER try to write to either the program files or program data directories.
  • Hint #1: If you find any program artifacts or fragments in the system's Virtual Store, then you need to move whatever you found there out of the directory that was moved - as this means that a non-elevated process tried to write somewhere it was not allowed to write.
  • Hint #2: FlightGear is a non-elevated process, so it should never try to write to either program files, or program data, (or sub-directories of these two directories). Particularly, FlightGear should not try to use Program Files or Program Data as data storage.
Definition:
"Static" executables, binaries, or data, are program objects that never change except if the program is patched, updates are applied, or the program itself is upgraded to a new version. (i.e. an elevated-process installer is used to modify them)

Note:
Even though earlier versions of Windows, (XP and earlier), do not enforce this, this is still an excellent "best-practice" that will work on these systems as well. Not to mention that it's a good thing to have a consistent install path and process. :D


Topic #3: Correct Placement of Volatile Program or User Data

Here are some tips on how to place volatile data in a Windows system so that it is easily modified by user processes, easily found, and easily maintained.
  • A user's home directory is absolutely guaranteed to be writable by that user.
  • In all versions of Windows the system variable "%userprofile%" returns the fully qualified path to the user's home directory. (i.e. In XP, 2000, or ME, %userprofile% is set to "C:\Documents and Settings\{username}". In Vista, Win-7, and Win-8, %userprofile% is set to "C:\Users\{username}"). It is useful to note that a "cd %userprofile%" command will always take you to the current user's home directory.
  • It is a best-practice to create a specific subdirectory in the user's home folder to act as a container for all of the program's files, (i.e. "%userprofile%\FlightGear"), with specific main subfolders underneath it, like "Terrasync", "Aircraft", "Scenery", "Settings", (which should be the default location of the settings.fgrun file), etc.
  • Installer Tip: These directories should be created, and the program default path parameters should be set to match them at install time. Likewise, the Terrasync directory should be set at install time as well.


Topic #4: Clear the VirtualStore

Verify, and if necessary clear, any cruft from the user's Virtual Store directory.
  • There is a "feature" in Windows Vista and later - if a non-elevated process tries to access what the operating system considers a "protected" area, a copy is created, placed in the virtual store, and the process is given access to that instead.
  • Though the actual, literal, path to the virtualized data is "C:\Users\{user}\AppData\Local\VirtualStore\Program Files\FlightGear\(etc)" the process using that data actually sees the data within the virtual store as "C:\Program Files\FlightGear\(etc)". In other words, the running, non-elevated process has no clue that it is actually running out of the virtual store.
  • To make things even MORE interesting, updating the data within the real directory DOES NOT update the data within the Virtual Store. The result is that if an update, or re-install is done, and there is old data in the virtual store, the running executable will never see the new data. ( :shock: ) (See my blog posting on this exact issue at http://www.qatechtips.com/2010/01/windows-7-windows-vista-virtual-store.html)

As a result of this, the package maintainer that creates the Windows installer package must manually navigate to the Virtual Store by using the literal path for the user installing the package, (C:\Users\{user}\AppData\Local\VirtualStore), see if there is any Program Files [86] or Program Data cruft for FlightGear, and physically and manually remove it.

It should also be noted that if this rule - checking for the existence of cruft in the VirtualStore - is tried on earlier versions of Windows, it will also work. Since there is no VirtualStore directory, the program path followed will always be the "nothing found so there is nothing to remove" path.


Topic #5: Separate configuration from running the program

Running the program and configuring the program should be two completely separate and distinct things.
  • It makes absolutely no sense whatsoever that the user should have to go through (almost) every configuration setting, every time when he wants to launch the program.
  • There should be two executable paths within the startup menu for FlightGear: A "Configuration" executable that brings up the configuration dialogs, and a "FlightGear" executable - which should be represented by the icon on the desktop - that launches the actual "fly the damn airplane already!!" program.
  • Most Windows users, not to mention the majority of reviewers, will do this exactly TWICE, and then say PUNT THIS!


Topic #6: Use the Windows path syntax

The directory configuration dialogs should use Windows default path syntax instead of the Unix syntax
  • The directory configuration dialogs currently use the "Unix" style path syntax, (/xxx/yyy/zzz - using the forward slash).
  • Windows systems have always used the "DOS" style path syntax, (..\xxx\yyy\zzz - using the back-slash).
  • Defaulting to the Windows style paths will allow the user to cut-and-paste literal pathnames from windows or dialogs and use them in the configuration dialog un-changed.
  • The current method requires the user to use the "browse" feature to find the path so that the path syntax is in Unix format.


Topic #7: Eliminate the Command Dialog

The background command dialog should not be shown to eliminate confusion.
  • Having the background command dialog showing is distracting, visually noisy, and can cause confusion among users who are not used to seeing something like this.
  • If something like this is ABSOLUTELY NECESSARY, (which I doubt, since it appears to never be used in normal use), this can be directed to a log-file somewhere.


Topic #8: Sensible Defaults at Installation

The installer should set, and enable, sensible defaults.
  • The installer should create all the top-level data container directories, (Terrasync, Aircraft, Scenery, etc), within the FlightGear container directory. (See the example directory screen-shot located at http://www.mediafire.com/view/?2c2daupsyxa4pk7)
  • The setup default directory paths should be set to the locations established above.
  • Any directories that require special "marking" or "enabling", (such as the Terrasync directory), should be marked or enabled by default.
  • The location of the "settings.fgrun" file should be located within the $FG_ROOT/Settings directory by default. (instead of the FlightGear program directory!)
  • The program should set a reasonable "default" airport, (some small airport out in the middle of nowhere), in a reasonable default aircraft, (the Cessna 172R is a good choice). I have had the program - at initial startup - want to put me smack-dab in the middle of San-Francisco Intl. in a Boeing 777! Yikes!
  • The program should set initial aircraft and flying defaults at the "fantasy" level. That is: perfect weather, easy flight settings, auto-coordination, inexhaustible fuel, crashes do no damage, etc. etc. etc. This allows the neophyte user to "get his hands dirty" relatively quickly with a minimum of frustration, allowing him to increase the realism settings as he grows more proficient. Of course, the experienced flight simmer already knows how to set things to his liking, set up multi-player, etc.

In essence, the ideal Windows setup would have the system set up in such a way that the typical user would be able to launch the program, crank up the throttle, and get into the air with an absolute minimum of trouble.

I am sure I will think of a few more things as I continue to work with FlightGear - so I may wish to update this.

What say ye?

Jim (JR)
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 139
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-7 / Linux

Re: For Developers: Windows Install and Runtime Best-Practic

Postby Hooray » Fri Apr 19, 2013 5:22 am

that must have been a lot of work, thanks for doing that - as you noted already, many of us don't use Windows, or have access to a Windows system (well, except for a VM).
Some of the things are more difficult to solve than others - so I would suggest to focus on things that can be easily/quickly solved, such as the installer settings. As far as I know, the Windows setup is scripted and created automatically by the build server:

http://www.mail-archive.com/flightgear- ... 39779.html
Zakalawe wrote:These are the first Windows releases produced automatically (Jenkins creates
the installer) instead of via Curt, so please be on the look-out for anything I
may have messed up / omitted. Based on very limited testing with my Windows VM
everything seems sane and the apps run.


So customizing and optimizing things there, should be mostly a matter of editing the template that is used for creating new config files. Also, that shouldn't be too difficult for people without programming experience - because it's really just a config file.

The scripts used by the build server to package things are maintained in the fgmeta repository: https://gitorious.org/fg/fgmeta/trees/master
Thus, patches can be sent through conventional gitorious merge requests.

Finally, please understand that it may be safer to either move this to the wiki (especially if you intend to maintain it anyways), or split it up and file feature requests via the issue tracker: http://flightgear-bugs.googlecode.com/

Speaking from experience, people won't otherwise remember what you wrote here 6 months from now - so the issue tracker/wiki are the safest way to ensure that things don't get lost. It may also be helpful to look for Windows-based contributors willing to help with improving the Windows deployment situation a little, you could for example try the newsletter (see my signature).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: For Developers: Windows Install and Runtime Best-Practic

Postby zakalawe » Fri Apr 19, 2013 12:53 pm

Patches (ideally Gitorious merge requests) to the installer script are most welcome - as are patches to the config.cxx code which places / locates FG_HOME and hence all the volatile data. Actions speak louder than words :)
zakalawe
 
Posts: 1141
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: For Developers: Windows Install and Runtime Best-Practic

Postby jharris1993 » Fri Apr 19, 2013 3:47 pm

Hooray wrote in Fri Apr 19, 2013 5:22 am:that must have been a lot of work, thanks for doing that - as you noted already, many of us don't use Windows, or have access to a Windows system (well, except for a VM).
Some of the things are more difficult to solve than others - so I would suggest to focus on things that can be easily/quickly solved, such as the installer settings.


Hooray,
You're right about one thing - this list represents many years of work in a Windows Software QA environment, working to figure out what even the developers didn't know about at that point in time.

As far as the "some things are more difficult than others" issue, since I don't know what's difficult and what's not at your end, I would suggest going for the low hanging fruit first.

You also mentioned the Wiki, and I looked there, but I could not find what seemed like a reasonable place to put this. The places that did look like they might work were guarded by packs of wild dogs with their own agendas, so I decided to stay away. Any help or suggestions you may have would be gratefully appreciated.

zakalawe wrote in Fri Apr 19, 2013 12:53 pm:Patches (ideally Gitorious merge requests) to the installer script are most welcome - as are patches to the config.cxx code which places / locates FG_HOME and hence all the volatile data. Actions speak louder than words :)


Zakalawe,
As you may have noticed - though I do work with Linux a bit, and I like it - I do the vast majority of my work on Windows boxes, so I wouldn't know a Gitorious from a green-snake if it bit me. (Gitorious: It sounds like the stupid green lizard that tries to sell GEICO insurance! :lol: )

<rant>
I have run into the exact same problem with the FlightGear documentation. I'd really like to help with the Windows installation docs, (and, I will once I get two seconds cobbled together!), but asking me to learn GIT, EMACS, LaTeX, and a whole host of other voodoo just to help update the docs is - from my point of view - not reasonable. It's not reasonable in the exact same way that expecting YOU folks to be instant experts in Windows build techniques and installation protocols is not reasonable.

Not to mention that carefully examining the results of several different Windows based FlightGear installs using different versions, taking careful note of what went awry, when, where, and how, and (if necessary), doing the research to find a better way - and then taking the time to create a document for you folks noting what the best-practices are. . . . IMHO, the comment "Actions speak louder than words" is a bit condescending, if not downright insulting. It's as if you are saying that all the effort I have put into this up to this point in time is essentially worthless.
</rant>

It is also important to note that I am not a build engineer, nor do I have any experience at all with Windows installers or installer scripts, since my experience is primarily as a software QA engineer, not a release engineer. However, I have been interested in learning about Windows installers and installer scripting, and this may be as good a place to start as any.

Since I don't know how to create the "patches" you expect, and you folks don't know what the correct installer requirements are, what say we meet in the middle somewhere instead of pulling out the claws. OK?

How does this sound?
  • Somehow or other, you folks send me everything you use to create the Windows installer package, (i.e. Pre-compiled binaries, installer software, installer scripts, whatever documentation you have, etc. etc. etc.), so that I can try to re-create the Windows installers here. Putting them somewhere where I could grab them via FTP, or on a file-share site like MediaFire, would work.
  • I will try to re-create the Windows installers as they currently exist. After figuring out how the installers, and the installer scripts work, I will then begin trying to implement some of the "best-practices" I mentioned.
  • Once I get these things working, I will transmit back to you folks the updated scripts, (or whatevers), that implement the changes.
  • You folks can make the necessary patches, or whatever you need, to get them into your workflow.

You can send me whatever you used for the current 2.10 stable release as I would prefer to work with that instead of some unknown alpha or beta code.

What say ye?

Jim (JR)
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 139
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-7 / Linux

Re: For Developers: Windows Install and Runtime Best-Practic

Postby Hooray » Fri Apr 19, 2013 4:10 pm

You also mentioned the Wiki, and I looked there, but I could not find what seemed like a reasonable place to put this. The places that did look like they might work were guarded by packs of wild dogs with their own agendas, so I decided to stay away. Any help or suggestions you may have would be gratefully appreciated.


Please feel free to find your own place (i.e. start a new article) - there are enough wiki admins able to move things as required (myself included). Once you have your own article, you can also act like a wild dog protecting it. Even though it does make sense to link to it from various places, so that it will be found - such as from the release plan article for example.

I'd really like to help with the Windows installation docs, (and, I will once I get two seconds cobbled together!), but asking me to learn GIT, EMACS, LaTeX, and a whole host of other voodoo just to help update the docs is - from my point of view - not reasonable.


We do have a bunch of people who do not mind acting as the "interface point" or middle man here - Stuart for example has an excellent track record of doing exactly that whenever new contributors needed a helping hand. And documentation updates are not really critical - there's no chance to break code, so you can just as well get in touch with other FGDATA committers and ask them to review/commit your changes (or convert them into LaTex for example). Note that you should ideally not get in touch with core developers here, because docs are generally not that critical - and core developers should ideally only be "used" to review source code changes.

It is also important to note that I am not a build engineer, nor do I have any experience at all with Windows installers or installer scripts, since my experience is primarily as a software QA engineer, not a release engineer. However, I have been interested in learning about Windows installers and installer scripting, and this may be as good a place to start as any.


You could probably install the installer tools locally and use the FG config files to optimize the setup a little - but Zakalawe will have to comment on that, because I am not familiar with the Windows specifics here.

And please don't misunderstand what Zakalawe said earlier regarding actions vs. words: All of us started out pretty much like you are now, i.e. finding areas that needed improvements, initially requesting changes - and eventually "scratching our own itch" (due to lack of action), and yes: Zakalawe included - which is why it's a good idea to listen to what he said now: He has made the very same experience over time, that "talking" does not matter as much as "acting" - so you can learn a lot from such statements, because not everybody can spend a decade becoming familiar with the project obviously :D
Then again, many long-term contributors have in fact been involved in the project for many years, i.e. at least 5-10 years - especially core developers, there are very few exceptions actually. So keep that in mind when dealing with the community. It may all seem a little overwhelming, but most people spent tons of time to get there in the first place.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: For Developers: Windows Install and Runtime Best-Practic

Postby jharris1993 » Fri Apr 19, 2013 5:41 pm

Hooray wrote in Fri Apr 19, 2013 4:10 pm:Please feel free to find your own place (i.e. start a new article) - there are enough wiki admins able to move things as required (myself included). Once you have your own article, you can also act like a wild dog protecting it. Even though it does make sense to link to it from various places, so that it will be found - such as from the release plan article for example.


I'd love to do that, yet I know that Wiki's can be quite personal - even Wikipedia has become a flame-fest in the past - so I like to walk very softly when treading on someone else's work. If for no other reason that respect. As you mentioned later on in your post, many people here have decades invested in this project, so it behooves neo's like myself to walk carefully.

Would you object to helping me here, perhaps by being the "point man", helping me find the correct place for such a new page?

We do have a bunch of people who do not mind acting as the "interface point" or middle man here - Stuart for example has an excellent track record of doing exactly that whenever new contributors needed a helping hand.


I will freely eat each and every one of my words with respect to Stuart.

He has gone above and beyond the call of duty to make sure that I felt as welcome as possible. In fact, though he didn't use these exact words, as far as he was concerned - so long as it was in English, in coherent sentences, and was topical - he didn't care WHAT format it was in, (so long as he could read it). IMHO, everyone in the Open Source / FOSS community - including myself! - could use a triple-dose of his polite and gracious manner. ( :oops: )

You could probably install the installer tools locally and use the FG config files to optimize the setup a little - but Zakalawe will have to comment on that, because I am not familiar with the Windows specifics here.


Isn't that what I suggested? ( :D )

I'd love to play with the Windows build environment for two reasons. First I would learn a valuable skill. Second, you folks would gain a great deal of "street cred" in the Windows community since your stuff would install better than half the expensive payware crap does.

All of us started out pretty much like you are now, i.e. finding areas that needed improvements, initially requesting changes - and eventually "scratching our own itch" (due to lack of action) . . . . Then again, many long-term contributors have in fact been involved in the project for many years, i.e. at least 5-10 years - especially core developers, there are very few exceptions actually. So keep that in mind when dealing with the community. It may all seem a little overwhelming, but most people spent tons of time to get there in the first place.


Oh so true!

If it weren't that I was so passionate about flying, (and unfortunately, will never pass the flight physical, so I'm stuck with simms), I'd have told you folks to 'naff off a long time ago.

However, you folks have a phenomenal piece of work here - and if I can contribute to it - it is my pleasure to do so.

What say ye?

Jim (JR)
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 139
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-7 / Linux

Re: For Developers: Windows Install and Runtime Best-Practic

Postby Michat » Sat Apr 20, 2013 12:22 am

Excellent research and report, with great style jharris1993.

My experience with windows is using XP, the so called pro. Here in Spain we have Program files and also Archivos de Programa that is another folder which name is a translation of program files.

What is your opinion of this MS practice? I understand reading your article that there are a lot of problems caused by the diversity of those folder (x86), virtualstore, Archivos de Programa.

It sounds gothic.

I Used to install in C: before this MS practice. Do you recommend me using C: or better a C:/ my folder ?

Thank you
User avatar
Michat
 
Posts: 919
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: For Developers: Windows Install and Runtime Best-Practic

Postby jharris1993 » Sat Apr 20, 2013 2:58 am

Michat,

You've got me puzzled too. :roll:

I have absolutely never ever played with the Spanish version of Windows. Actually, the only other version of Windows I have seen is XP in Russian, and I didn't get a very good look at that one either.

My gut feeling would be to tell you to install the executables to the "Program Files" folder, and the rest of the data files to your C:\Documents and Settings\{username}\FlightGear folder, using sub-folders as I have described above. You can see a screen-shot of how I did it by grabbing the picture I stored here: http://www.mediafire.com/view/?2c2daupsyxa4pk7

Note that the path shown is for a Windows 7 machine. In your case it would be something like:
"C:\Documents and Settings\Michat\FlightGear"
assuming that your username on your XP box is "Michat" - and if it's not, just substitute your real username. :P

However, I would have to ask you this: When you install programs on your Spanish localized system, where do they normally get installed to? The "Program Files" folder? Or the "Archivos de Programa" folder?

In your case, since you have XP, you don't have a "VirtualStore" folder, and most of the issues I raised are not enforced. They should be because it leaves your system wide open to skumware and viruses, but XP doesn't care about that.

This "MS practice" is simply a way to try to make your system less vulnerable to bad guys who might want to leave all kinds of bad bogus software on your system - or worse - use your system as a zombie to attack something else more important. That way the police knock down YOUR front-door at 2:00 am, (0200 metric time :) ), and haul YOU off to prison instead of the real villain.

Jim (JR)
Last edited by Gijs on Sat Apr 20, 2013 8:59 am, edited 1 time in total.
Reason: No useless quoting please
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 139
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-7 / Linux

Re: For Developers: Windows Install and Runtime Best-Practic

Postby Hooray » Sat Apr 20, 2013 10:18 am

Would you object to helping me here, perhaps by being the "point man", helping me find the correct place for such a new page?


  • if you haven't already, get a wiki account (quick, simple, free)
  • log in
  • next, come up with a name for your article
  • something like http://wiki.flightgear.org/FOO
  • once you visit the URL, the wiki will tell you "article not found, do you want to create it ?"
  • click on "edit this page" to create a new article

Now, given that this is release related, I'd suggest to use the "Relase:" prefix, which I use as a namespace.
I did that when I created this release-related article: http://wiki.flightgear.org/Release:Airc ... n_Criteria
You can also add a custom category to all release related articles using a [[Category:Release]] tag to the end of the article.
Next, it would make sense to link to your new article from various places, to ensure that it can be found - preferably, really relevant places, such as the release plan: http://wiki.flightgear.org/Release_plan - the developers portal, and maybe the upcoming newsletter to announce your new article, and to get more volunteers involved (see my signature).

We can then use the wiki article and its talk page to coordinate various related efforts and contributions, I would suggest to add a simple roadmap, focusing on tangible/simple things first, which will also be a little more gratifying than doing the opposite.

I am sure we can find enough people to help with optimizing the windows installer a little - fortunately, there are many potential testers available.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: For Developers: Windows Install and Runtime Best-Practic

Postby jharris1993 » Sat Apr 20, 2013 5:30 pm

Hooray wrote in Sat Apr 20, 2013 10:18 am:
Would you object to helping me here, perhaps by being the "point man", helping me find the correct place for such a new page?


  • if you haven't already, get a wiki account (quick, simple, free)
  • log in
  • next, come up with a name for your article
  • something like http://wiki.flightgear.org/FOO
  • once you visit the URL, the wiki will tell you "article not found, do you want to create it ?"
  • click on "edit this page" to create a new article

Now, given that this is release related, I'd suggest to use the "Relase:" prefix, which I use as a namespace.
I did that when I created this release-related article: http://wiki.flightgear.org/Release:Airc ... n_Criteria
You can also add a custom category to all release related articles using a [[Category:Release]] tag to the end of the article.
Next, it would make sense to link to your new article from various places, to ensure that it can be found - preferably, really relevant places, such as the release plan: http://wiki.flightgear.org/Release_plan - the developers portal, and maybe the upcoming newsletter to announce your new article, and to get more volunteers involved (see my signature).

We can then use the wiki article and its talk page to coordinate various related efforts and contributions, I would suggest to add a simple roadmap, focusing on tangible/simple things first, which will also be a little more gratifying than doing the opposite.

I am sure we can find enough people to help with optimizing the windows installer a little - fortunately, there are many potential testers available.


Just the advice I was looking for. :D

I already have a Wiki account - and have taken the trouble to weigh-in on a couple of talk pages.

This might get delayed for, oh, maybe fifteen minutes or so, ( :roll: ), as we have company coming from Russia in a week or two, and my wife is cracking the whip for me to get the basement cleaned up, house painting done, etc. However, I will be checking in fairly frequently, and if I get an hour or two to spare, I'll start working on the Wiki article, road-map, etc. I'm assuming that there is a way for me to begin an article and save it off-line while I work on it so I don't publish a half-baked unfinished article while I work on it. Right?

BTW, with respect to the release plan, is it possible to create, not so much a "fork", but a "siding", (or "service road"), that will parallel the main release plan where I can work on the Windows installer - without holding up the normal release process, and then merge updates back into the mainline code? Eventually, when these updates are mature, the "service road" itself would merge back into the mainline code-base. However, IMHO, while the work, (let's call a spade a spade here), blatant experimentation, is being done - the normal mainline release process isn't affected and we don't break the Release Windows installer with something stupid I did.

And I don't want to sound greedy here, but - at least for the time being - I'd like to own this experimental process for two reasons:
  • At the present time, I think I have probably the clearest picture of what the initial goals are.
  • I really want to dig in and get my hands dirty with learning about Windows installers without others mucking up the waters for me.
  • (OK, I can't count! :P ) It will give me valuable experience working within a managed development environment.

Of course, I will be all ears listening to advice from people who already know the Windows installer build process for FlightGear - it will save me much grief! And I have already learned much and gone far "on the shoulders of Giants" as it were, so why stop now?

You know - I a-gonna have to put you on my "friends" list!

Thanks!

Jim (JR)
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 139
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-7 / Linux

Re: For Developers: Windows Install and Runtime Best-Practic

Postby Hooray » Sat Apr 20, 2013 7:19 pm

  • yes, I saw you commenting on the wiki - I just tend to re-use previously posted stuff and copy/paste it into responses as applicable, which is admittedly less personal, but a little more efficient :lol:
  • I would have to suggested to simply move your original posting to the wiki and edit/customize it as required, just to get started.
  • regarding the release plan and branching articles, that's a pending feature request - and people seem to have different opinions here (Stuart actually liked the idea), but it boils down to server admins installing certain extensions, which a lowly wiki admin cannot do - so it's beyond our powers here. But we could use that branching support for a number of purposes, including having "stable/peer reviewed" articles - but also articles for different FG versions. Which is why I am all for it, and actually volunteering to tag/branch articles as required to provide docs for different FG versions.
  • For wiki related "feature requests", there's a dedicated place to discuss such things: http://wiki.flightgear.org/Portal:Wiki
  • Regarding gitorious and the installer config itself, branching is supported "out of the box", so it should be a no brainer - and if you don't want to use git, you could even just use a word document to have a revision history
  • I don't think there's any problem with you owning your own experiments :D

Regarding the jenkins build server and the scripts running there, you may want to get in touch with Zakalawe to see if there's any straightforward way to accommodate your needs and let you do your experiments - otherwise, I can also provide you with shell access to a Linux server to run your experiments there if that'd help - including full inbound/outbound 100MBIT network access.

As far as I know, the build server uses a Windows VM to run stuff - so that might be another option (something like VMWare or VirtualBox should do).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: For Developers: Windows Install and Runtime Best-Practic

Postby Gijs » Sat Apr 20, 2013 7:53 pm

Nothing wrong with publishing work in progress stuff at the wiki. We may be able to save you a lot of redundant work, if we can for example point you to existing documents that are related to what you write.

If you add the following line to the top of your article, it will be clear to everyone that it's unfinished:
Code: Select all
{{WIP}}

For more info, see http://wiki.flightgear.org/Template:WIP
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9288
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: For Developers: Windows Install and Runtime Best-Practic

Postby jharris1993 » Sat Apr 20, 2013 8:46 pm

Hooray wrote in Sat Apr 20, 2013 7:19 pm:[*] I would have to suggested to simply move your original posting to the wiki and edit/customize it as required, just to get started.
[*] regarding the release plan and branching articles, that's a pending feature request - and people seem to have different opinions here (Stuart actually liked the idea), but it boils down to server admins installing certain extensions, which a lowly wiki admin cannot do - so it's beyond our powers here. But we could use that branching support for a number of purposes, including having "stable/peer reviewed" articles - but also articles for different FG versions. Which is why I am all for it, and actually volunteering to tag/branch articles as required to provide docs for different FG versions.


I hadn't even thought of branching articles, I was thinking of branching the mainline code.

[*] I don't think there's any problem with you owning your own experiments :D

Regarding the jenkins build server and the scripts running there, you may want to get in touch with Zakalawe to see if there's any straightforward way to accommodate your needs and let you do your experiments - otherwise, I can also provide you with shell access to a Linux server to run your experiments there if that'd help - including full inbound/outbound 100MBIT network access.


Wow! Thanks! I'd like to do stuff locally, so that would be great for doing FTP or Secure FTP access for downloads.

As far as I know, the build server uses a Windows VM to run stuff - so that might be another option (something like VMWare or VirtualBox should do).


My idea, at least initially, was to export the build environment to a dedicated local machine, mess with it there creating trial installs of the 2.10.x.x.x stable build - and then, once I get a clue, start migrating stuff back to you folks.

I have messed with VMware and VirtualBox - I have installations of both of them live right now, they're damn handy, and I may use them for the initial experiments with the builds. Maybe I can grab a copy of the VM itself?

Gijs wrote in Sat Apr 20, 2013 7:53 pm:Nothing wrong with publishing work in progress stuff at the wiki. We may be able to save you a lot of redundant work, if we can for example point you to existing documents that are related to what you write.

If you add the following line to the top of your article, it will be clear to everyone that it's unfinished:
Code: Select all
{{WIP}}

For more info, see http://wiki.flightgear.org/Template:WIP


Gijs,

Both you and Stuart have been a Godsend in the past, (and Hooray is rapidly catching up!), so I just wanted to say "Thanks!"

Re: The Windows installer article - IMHO, if I am going to work on the actual installer process itself, the article should wait until the installer is stable. Make sense?

I haven't heard a peep from Zakalawe, since his original post. Maybe I should PM him and see if I can get him on board with helping me with this stuff, 'eh?

Thanks again!

Jim (JR)
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 139
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-7 / Linux

Re: For Developers: Windows Install and Runtime Best-Practic

Postby Hooray » Sat Apr 20, 2013 9:48 pm

jharris1993 wrote in Sat Apr 20, 2013 8:46 pm:Wow! Thanks! I'd like to do stuff locally, so that would be great for doing FTP or Secure FTP access for downloads.
[...]My idea, at least initially, was to export the build environment to a dedicated local machine, mess with it there creating trial installs of the 2.10.x.x.x stable build - and then, once I get a clue, start migrating stuff back to you folks.[...]
I have messed with VMware and VirtualBox - I have installations of both of them live right now, they're damn handy, and I may use them for the initial experiments with the builds. Maybe I can grab a copy of the VM itself?
[...]I haven't heard a peep from Zakalawe, since his original post. Maybe I should PM him and see if I can get him on board with helping me with this stuff, 'eh?


Even though I do agree that this would seem like the best approach, I have really no idea just how "custom" (=easily replicable) the build server setup is. As far as I know Zakalawe set all of this up a long time ago, so he's certainly the right guy to get in touch with - but keep in mind that he's usually juggling tons of different FG related projects and infrastructure related efforts (such as the build server or the cmake migration) .
That said, a couple of years ago, the same issue (=replicating the setup) was raised on the developers mailing list, and the answer was pretty promising back then:

Release engineering (aka, continuous integration, aka, nightlies)

Zakalawe wrote:> That's an awesome setup, very interesting.
> Would you have a tarball of this configuration and some details of how you
> set up the system?

Quick answer is no, not yet, but I will. The configuration is exportable as XML
files, and I'm using the official Hudson apt-get package for Ubuntu, so it's a
fairly repeatable setup. Configuring the Windows slave VM with mingw is proving
the biggest hassle


Just let me know if you'd still like to get access to a server to test everything on, I can provide pretty much everything you may need, including full network, and root, access. That said, I do understand that using a local VM may be a little more convenient.

If on the other hand, the build server setup isn't yet sufficiently replicable, it might be possible to provide you with a restricted account on the server to directly test your changes there, you'll probably want to get in touch with its maintainer then, for the maintainer's eMail address, see: http://www.mail-archive.com/flightgear- ... 30123.html
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11100
Joined: Tue Mar 25, 2008 8:40 am

Re: For Developers: Windows Install and Runtime Best-Practic

Postby jharris1993 » Sat Apr 20, 2013 10:09 pm

Hooray wrote in Sat Apr 20, 2013 9:48 pm:Even though I do agree that this would seem like the best approach, I have really no idea just how "custom" (=easily replicable) the build server setup is. As far as I know Zakalawe set all of this up a long time ago, so he's certainly the right guy to get in touch with - but keep in mind that he's usually juggling tons of different FG related projects and infrastructure related efforts (such as the build server or the cmake migration) .
[. . . .]
Just let me know if you'd still like to get access to a server to test everything on, I can provide pretty much everything you may need, including full network, and root, access. That said, I do understand that using a local VM may be a little more convenient.


In my case, it would be even simpler than that. I keep a fairly catholic assortment of pre-built bare-metal images that I can restore to any one of a number of machines in a matter of minutes. This is how I ran my "Virtual Machines" long before "Virtual Machines" became reasonable to work with. Using an eSATA 3G/s connection, I can restore a bare metal image faster than I can copy a virtual machine. Believe it or not, it's only within the last year or so that I have taken any serious interest in virtualization.

First: Being a new-fangled buzz-word, I wanted to get some "stick-time" (laughing!) on the technology.
Second: Recently I have had episodes where there were more sticks in the fire than machines to burn them, :P so I had to take a couple of my more beastly machines and install VMware on them to handle the load.

However, IMHO, virtual PC hardware is like flight simming: Flight simms may be great, but NOTHING beats cockpit time in a REAL aircraft! :D

If on the other hand, the build server setup isn't yet sufficiently replicable, it might be possible to provide you with a restricted account on the server to directly test your changes there, you'll probably want to get in touch with its maintainer then, for the maintainer's eMail address, see: http://www.mail-archive.com/flightgear- ... 30123.html


I've PM'd Zakalawe on this, and we'll see what he says when he surfaces.

Thanks again!

Jim (JR)
What say ye?

Jim (JR)

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb
jharris1993
 
Posts: 139
Joined: Sun Nov 18, 2012 9:20 pm
Location: Worcester, MA. / Moscow, Russia
Callsign: $%^&ing Idiot!
Version: Whatever..
OS: Win-7 / Linux

Next

Return to Development

Who is online

Users browsing this forum: No registered users and 2 guests