Programming Question Is the arrangement of files and folders in Orbiter typical for PC apps?

[Pithecanthropu]

I know that, for example, an accounting application might not have a "meshes" folder, but in general is this how shrink-wrapped software is developed? I refer to the way that different types of configurational input are distributed into "config", "meshes", "scenarios" folders and so on. Obviously, I wouldn't expect a project management tool to have a "Flights" folder. But would the overall architecture of the accounting app be similar?

I've noticed that Orbiter add-ons all seem to follow the same directory structure as Orbiter, and they all instruct the user to unpack them in the application root directory. Is this also a typical approach? If I develop something of my own using this general principle, do I need to get permission from Martin to use this design?

 

[TSPenguin]

This design is one of the most basic and transparent designs ever concieved. Also probably the first one that uses folders.
It has been used in many applications and even entire operating systems are based on this very basic principle.

You are free to use this basic and IMO best system wherever you like. May it be your own application, your emails or your laundry

Happy Orbiting

 

[garyw]

Application development is not the easiest thing in the world and the layout of the files and folders is largely up to the application programmer(s). There are some cases where a file HAS to go into a particular location but many times it's simply that the layout makes sense (or note) to the application designers.

Orbiter has one of the best layouts I've seen. No messing with the registry and it's easy to find the files you want/need to edit/updgrade/mess with.

 

[mjessick]

As a Windows app, Orbiter needs to stop writing to the install folder.
Per Wikipedia: "Windows XP was first released on 25 October 2001". About the same as Orbiter.

It has been almost 8 years now that this paradigm has been outdated. That is 64 years in "dog years."

 

[NukeET]

As a Windows app, Orbiter needs to stop writing to the install folder.

Sorry, missed your point. What exactly does Orbiter write to the install folder and why is that a bad thing?

 

[Scrooge McDuck]

Orbiter has one of the best layouts I've seen.

Re garyw, TSPenguin:
IMO, Orbiter does not have the best/most transparent directory structure. It's not bad, but maybe not the best.
For example, there is 1 config, 1 meshes, 1 modules, etc folder shared by all addons.
When you want to delete an addon manually, you need lots of time to find all those individual files between hundreds of other files. I know there are some addon managers to overcome this problem, but I'm talking about doing it manually. Often, simply extracting a new, clean Orbiter is even the quickest way to clean up.

Wouldn't it have been much simpler / more transparent if each addon had it's own mesh/config/modules subdirectories, using the same strict fixed layout? (ala FlightSim)
Removing an addon would then become as simple as deleting a single directory. You would be sure that it's completely done without leaving behind relics.


regards,
mcduck

 

[Pithecanthropu]

Re garyw, TSPenguin:
IMO, Orbiter does not have the best/most transparent directory structure. It's not bad, but maybe not the best.
For example, there is 1 config, 1 meshes, 1 modules, etc folder shared by all addons.
When you want to delete an addon manually, you need lots of time to find all those individual files between hundreds of other files. I know there are some addon managers to overcome this problem, but I'm talking about doing it manually. Often, simply extracting a new, clean Orbiter is even the quickest way to clean up.

Wouldn't it have been much simpler / more transparent if each addon had it's own mesh/config/modules subdirectories, using the same strict fixed layout? (ala FlightSim)
Removing an addon would then become as simple as deleting a single directory. You would be sure that it's completely done without leaving behind relics.


regards,
mcduck

I can see your point, although the problem of restoring earlier versions can easily be worked around by maintaining periodic archives of /orbiter. I am still really a noob at this, but I can see that merging the add-ons with the core product, the way it's been done, makes for simpler coding, and perhaps reuse. The core product comes with a number of spacecraft, many of which are slight variations of others, and we'd normally expect those to use many of the same programming objects. As I understand the system, there's just one Orbiter.exe that links in .dlls at need. Now, if the add-on and core spacecraft configs, meshes, and modules are all in the same directory level, doesn't that make it simpler to build and maintain the core program?

 

[Scrooge McDuck]

Now, if the add-on and core spacecraft configs, meshes, and modules are all in the same directory level, doesn't that make it simpler to build and maintain the core program?

Technically spoken, no. It would be just as easy to write a function for enumerating subdirectories, looking for fixed foldes inside these. Maybe using a single shared directory would look easyer at first, but I don't think it would take too much effort to to it the other way.

 

[Hielor]

Sorry, missed your point. What exactly does Orbiter write to the install folder and why is that a bad thing?

Orbiter writes scenarios/logs/etc to the install folder.

This is a Bad Thing because non-administrator users will not always have permission to write to the install folder.

Moreover, on Windows Vista and later, the Program Files directory is pretty much strictly read-only even to administrators, unless you have UAC turned off.

It's a security thing, apparently.

 

[Rathelm]

Orbiter writes scenarios/logs/etc to the install folder.

This is a Bad Thing because non-administrator users will not always have permission to write to the install folder.

Moreover, on Windows Vista and later, the Program Files directory is pretty much strictly read-only even to administrators, unless you have UAC turned off.

It's a security thing, apparently.

Which is why I turned off UAC.

 

[Hielor]

Which is why I turned off UAC.

"Turn off UAC" should never be in the installation instructions of any application. As much as I disagree with the program files directory being read-only, that's the way it is.

 

[Rathelm]

"Turn off UAC" should never be in the installation instructions of any application. As much as I disagree with the program files directory being read-only, that's the way it is.

Can't argue with that, but my issue is more with old software. Sometimes I like pulling games out from pre XP and it's a hassle with UAC on.

 

[Pithecanthropu]

"Turn off UAC" should never be in the installation instructions of any application. As much as I disagree with the program files directory being read-only, that's the way it is.

I might have to do just that in order to make use of the Vessel Wizard I've seen floating around somewhere (can't remember the link now). IIRC it's necessary to unpack this into one of the VS folders to make it available, and mine is in Program Files.

Perhaps I could uninstall/reinstall it to a different top level folder on my hard drive, but I hate to do that since I"m told that uninstalling and reinstalling things it can cause the /winsxs folder to gobble up more space on the drive.

 

[Hielor]

Can't argue with that, but my issue is more with old software. Sometimes I like pulling games out from pre XP and it's a hassle with UAC on.

Even a lot of games made post-XP (notably World of Warcraft, which in one of their patches would detect if the user was on Vista and offer to move the game out of the Program Files directory) did it.

It's a giant pain the the butt, though, especially for moving applications between computers. In a game made using the old (and logical) method, saved games are in the SavedGames subdirectory of the application's root directory. Using the new method, saved games are in some random wacky place.

IMO, a program's folder should be it's folder, and it should be allowed to do whatever it wants in there.

Easiest way to get around it without turning of UAC is to just make a C:\Games folder, and put all your games there instead of Program Files.

 

[garyw]

Re garyw, TSPenguin:
IMO, Orbiter does not have the best/most transparent directory structure. It's not bad, but maybe not the best.
For example, there is 1 config, 1 meshes, 1 modules, etc folder shared by all addons.
When you want to delete an addon manually, you need lots of time to find all those individual files between hundreds of other files. I know there are some addon managers to overcome this problem, but I'm talking about doing it manually. Often, simply extracting a new, clean Orbiter is even the quickest way to clean up.

Wouldn't it have been much simpler / more transparent if each addon had it's own mesh/config/modules subdirectories, using the same strict fixed layout? (ala FlightSim)
Removing an addon would then become as simple as deleting a single directory. You would be sure that it's completely done without leaving behind relics.


regards,
mcduck

Valid point. I've deleted items in the past by redownloading the archive and then searching for the files that are listed in the archive. I did that a few times before I decided to give up. However it's still better than some apps that install crap all over the place and don't remove it even when you uninstall.

---------- Post added at 10:07 ---------- Previous post was at 10:04 ----------

IMO, a program's folder should be it's folder, and it should be allowed to do whatever it wants in there.

Almost agreed. As long as the app passes some basic tests then yes but this isn't always possible with Windows apps as they will reference DLL's in %systemroot% unless you want every application to install a copy of the DLL's which would then make patching a nightmare.

Easiest way to get around it without turning of UAC is to just make a C:\Games folder, and put all your games there instead of Program Files.

I don't use Vista but I've heard little good about UAC. I do have an E:\Simulation folder which is where I put FSX, Orbiter, FreeFalcon, etc.

 

[Hielor]

Almost agreed. As long as the app passes some basic tests then yes but this isn't always possible with Windows apps as they will reference DLL's in %systemroot% unless you want every application to install a copy of the DLL's which would then make patching a nightmare.

Why would allowing applications to save things in their own directory prevent the use of DLLs in %systemroot%?