App Packages -- The proper way to organize an OS
	
	Forward -- Every OS developer has run into the problem of keeping  track of where applications keep their support files and how the end user organizes them.  Some systems are better than others.  WiNGs has adopted a concept called the App Package, or App Folder. --
	 

	Complex applications in WiNGs use a modern structure for organizing the support files (resources) and data files that the application needs and uses.  The concept was borrowed in part from Risc OS, and partly from Apple's MacOS X.  It is called APP Packaging.  An app package is a directory structure, with the first directory in the structure, or the Root directory of the structure having an extension ".app" at the end of the name.  The Operating System WiNGs knows that a folder that ends with ".app" is not an ordinary folder. it is in fact the start of the structure of an Application package.  

	A standard package goes as follows:

	mail.app/
	mail.app/start
	mail.app/resources/
	mail.app/data/

	This is the most basic App Package structure.  The file "start" is the actual binary executable file that is run when you ask WiNGs to run "mail.app".  Resources should contain files that are customizable or changeable by the advanced end user.  The datadirectory should contain all of the raw data that the application needs. In the case of the mail application, there are more directories under data, that it creates when it needs too.  When you add an email account, mail adds a directory for each account to the data/servers/ directory.  

	The binary "start" file, is aware of the structure and can reference files within the structure regardless of where the App Package resides in terms of the whole filesystem.  

	Some files that are common to the entire System are still kept in special directories under the wings directory.  Examples of these are drivers and libraries.  

	The App Package structure leads to a very clean system.  All the files specific and necessary for running the application are kept With the application where ever you choose to put the application.  And if you delete the application, you delete it's associated files without any further effort, and without the need for complex and error prone uninstall "wizards".  

	Simple tools and utilities that have no data and no resources do not need app packages.  They can simply be a binary file with a unique name.  

	Here is how you use App Packages (in C Language):


#include <wgslib.h>
#include <xmldom.h>

extern char* getappdir();

//This is necessary for the function that can reference the app structure.

void main() {
	char * configfile;
	DOMElement * config;

	configfile = fpathname("resources/config.xml", getappdir(), 1);
  	
	config = XMLloadFile(configfile);
}

-- 

	And that's all there is to it!  We use fpathname() and getappdir() together to reference a file that we give a relative path to, from the root of the app package structure.  In the case above, we specified the config.xml file in the app folder's resources directory.  Then we used XMLloadFile on the "path-as-string" returned from fpathname, and bingo, "config" is now a pointer to the start of the XML tree.  The entire tree is in memory and all of the config data is in it.  Saving the XML file back into the App package is equally painless.  See below. 

#include <wgslib.h>
#include <xmldom.h>

extern char* getappdir();

void main() {
	char * configfile;
	DOMElement * config;

	configfile = fpathname("resources/config.xml", getappdir(), 1);
	config = XMLloadFile(configfile);

	//We've loaded it just as we did before. 

        /*
	Here we can read and modify any of the XML tree structure that we 
	want to. How to do that is the subject of another article. 

	And when we're ready, we just give the save command. Giving it the root
	XML element, and the path string that we got originally.
	*/

	XMLsaveFile(config, configfile);
}

--

	The App Package can be moved from the directory to directory by the user, and the config file will always be referenced in the same way.  Because fpathname() and getappdir() allow you to reference from a relative starting point. Which is the root of the App Package. 

	I hope this info is of use to some developers out there. For complex WiNGs applications that need multiple files, it is Extremely recommended that you use this standard App Packaging method of organizing the application and it's support files. 

	Greg.