OSDev.org

the thing that I think is most annoying about most any OS out there today is all the programs must be installed! I can see compressing it for bandwidth, and then having to uncompress it somewhere...but installations are so messy!

I really am not completely for sure on hwo to go about doing this...

The main problem is global configuration stuff..
It's just not easy to copy it, but it's also not easy to form a relocatable way to handle it..

anyone have any ideas?

I don't understand. What are you asking? How to have your OS install itself on a computer's hard drive? Or how to have a program install itself?

I mean to make a program, but not have to install it, or to be very easily self installing..(and mostly self-contained)

Like when switching computers, you just be able to copy your program files, and they just work, no installing or migrating, just copying the actual files..

I believe this is what Mac OS uses. That's why there are not usually uninstall programs for Mac. You just delete the file that contains all of the program. You might want to look into that. Also I believe there are several packagers like that for Linux...

On OpenBSD it's rather simple, You can use ports or binary packages.. All your personal settings are stored in your home folder..

For example, ~/.mozilla/firefox has all my Firefox settings & preferences.. Which is all that is required to backup..

Even if I accidentally deleted the installation of Firefox, My settings would still be safe.. And I would just reinstall the package. (Or if using ports, Just change into the firefox tree and type make install..)

And one should rarely use global config files, Any system specific settings would go into /etc and any application specific settings would go into the users home directories..

I can't really see the point you're trying to make though.. Must be your bad experiences on Windows. (With the insanity that is "Registry")

yea..probably with windows...ok, so my theory is to not to make something like windows with the registry...

Ports-type systems require someone to actually maintain the ports tree. I personally like some mix of the Mac and Windows solutions: have a directory like Program Files where you can simply drop and unzip packages to install them.

Crazed123 wrote:Ports-type systems require someone to actually maintain the ports tree. I personally like some mix of the Mac and Windows solutions: have a directory like Program Files where you can simply drop and unzip packages to install them.

PC-BSD uses this through its PBI system.

How about keeping system-wide data in a settings file alongside the executable, and user-specific data in the user's home directory. Then, to migrate you just need the application directories and the home directory.

The question is how you want to support shared libraries. If you just place them all in /usr/lib then that's something else you might need to copy. Deleting it may affect other programs...

Regards,
John.

I like the idea of the entire program being contained in a single file (with the exception of user settings).

I thought there were two ways around this:
- Use a file format that supports adding, removing, and modifying attached resources.
- Place the executable and all resources into one archive, and make sure all necessary files are inside the archive, then run the program from within the archive (done in the background by the system of course!) Then when the program wants to access or modify one of it's resources, it's modifying it within the archive.

If you go with b) you could make the archive read only, and rather than having to 'install' or 'modify' itself. It couldl have access to a local file.

e.g.
You have a burning frontend inside a tarbal (stored on a read only media) along with all the back ends and libraries.
When you double click the tarball, the front end loads, it can access its own files within its archive, and if it needs to configure (say, detect the path to CD burner) then it can save its global settings under as /etc/[program name] and local settings under /usr/[user]/[program name]. It would be easy if the program only wrote to a file with the same name as its name, then from within the a you could have a "Remove config files" and it will only have to delete (at most) 2 files!

.net programs can be just copied to their destination (once you have the framework installed of course ) and resources can be embedded inside the executable file (I never really examined the technique but I know it can be done, as the splash screen for a project I am working now was built inside the executable)