LFS installer package test
(213 posts, closed, started )
Quote from Scawen :
I realise there are reasons behind the new Windows structure and all that. Personally I have no idea what it's all about and I must admit that I am not inspired to move past XP at this point while there are so many issues with Vista.

The new, in my opinion proper, structuring is basically as follows:
- Executables and other static data in Program Files
- All user specific and "dynamic" data in user home directory*

This approach has numerous advantages:
- Only admin can access Program Files, so viruses for example cannot infect the executable files or do other damage to installed data
- Executables and data files are shared between all users of the computer, but each user automatically has their own config settings etc. without any special "profiles" support in the application
- Easy transfer and backup of your personal data, ie. you only need to take a backup of your home directory and all your important data is safe: You can reinstall the application itself and then copy your home dir data back and all is back the way it was, without having to do backups of the whole program installations (not a big issue in LFS' case, but if all other applications behave this way and LFS doesn't then its an annoyance to do special steps for LFS)
- All your private data is safe from other users, ie. if a server admin password is saved in some config file then its in your home dir and other users of the computer cannot get to read it

* In XP this is a bit messy, with horrible names like "Documents and Settings", "Application Data", etc. but this has been made more sensible in Vista and especially Windows 7.

(All this is documented by Microsoft and they do provide guidelines for using them, for example here. I think the only reason why the situation today is such a mess is that many developers simply do not follow these guidelines)
Well said Kegetys.

I'd only add that in truth this is very probably a forking point in the road. The two paths to be chosen from are the XP way and the win7 way.

Staying with XP is just as valid as opting to go with win7. Staying with XP will lead to staying with it until it's no longer supported and going with win7 is the way to a future which MS will be supporting.

What Kegetys said is not all of it, but it is the greater and most relevant part for now as far as anyone can tell right now.

Having elected not to use vista, and stayed with XP; I have also been trying Win7 for daily use on it's own machine in parallel for very nearly a year now and in my view it is the new XP. It was not instantly wonderful to use (or move over to), but I realise that the "minimal or reduced attack surface" proposition that MS has opted for makes so much sense that one would be utterly crazy to try and move forward without it. I guess it took a couple of weeks to feel remotely at home with it. A further 2 months or so and I felt at home enough to start accurately guessing what might fix any problems I encountered. Turns out that over all it's just a slight shift of mindset needed to cope with how it all works now. I'd say I've found it a rather liberating experience by now. Feels fresher, and both easy and quick to work with. At last say I!

Only other safe option for the future which springs to mind is to use XP and set up LFS on it, and then make sure it's not connected to the net in any way, or for any reason. That's a bit stark for my taste though.
Quote from Kegetys :The new, in my opinion proper, structuring is basically as follows:
- Executables and other static data in Program Files
- All user specific and "dynamic" data in user home directory*

So apparently, making use of this functionality would possibly exceed the amount of work that should be put into it. I mean, to adopt to this system in a nice and solid way, the user should have the ability to store custom files (textures, sounds, mods etc.) in his user folder, and the original files should remain in the program files folder. Then, LFS must first check the user folder, and then the program files folder, which might result in slower loading times or other problems, like for example the auto updater might not work anymore, because the user will not have admin rights to change the executable.
And even if this was possible - what happens when user A makes an online update of LFS, and user B has still some older files in his user folder, which are not incompatible with the new LFS version in program files?
Quote :The two paths to be chosen from are the XP way and the win7 way.

I would actually put it that the two ways are the Windows 95 way and the Windows NT way. The guidelines above are written for Windows 2000 and they are just as valid still for Windows 7, so this is not actually a new thing at all. It just that (finally) in Vista the default user is not an administrator user so all of the "wrongdoings" have just now really come to surface.

Quote :Then, LFS must first check the user folder, and then the program files folder, which might result in slower loading times or other problems

I cannot imagine any kind of problems with adding support for this, the effect for loading times of checking for existance of another file would be entirely unmeasurable and easy to program as well. Also, the sounds mods etc. aren't in a way a "supported" feature right now either so you could just install the mods as admin user and everything would work like they do now.


Quote :for example the auto updater might not work anymore, because the user will not have admin rights to change the executable.

The updater would ask for admin password. There is some flag you can set in the executable as far as I know that will do this automatically.

Quote :what happens when user A makes an online update of LFS, and user B has still some older files in his user folder, which are not incompatible with the new LFS version in program files

I think LFS already handles this without problems - you can install a new version and the old configs are either used as they are or updated. Also user A should not be able to do such an update anyway, only admin should.
Quote from Kegetys :The new, in my opinion proper, structuring is basically as follows:
- Executables and other static data in Program Files
- All user specific and "dynamic" data in user home directory*


(All this is documented by Microsoft and they do provide guidelines for using them, for example here. I think the only reason why the situation today is such a mess is that many developers simply do not follow these guidelines)

Thanks for the link. I'm still not getting it though.

Most of the listed benefits sound like they would only be useful in large corporate enviroments (roaming) and highly multi user machines with low diskspace (seperating static and dynamic data).

But even if it is a good idea to separate the location of data based on the type of data. How is the way this is done in Windows even close to being usable or practical?

You have to hunt down all the different locations that a program has installed itself to by searching in regedit and clicking through multiple hidden folders with names like 'C:\Users\<user>\AppData\LocalLow'. Hardly 'easy transfer and backup' is it?

And there isn't even a way to change the location of these special folders to another drive than the drive the OS is installed to.
Quote from J.B. :Most of the listed benefits sound like they would only be useful in large corporate enviroments (roaming) and highly multi user machines with low diskspace (seperating static and dynamic data).

Roaming is the only one in my opinion, and also the reason why I didn't include it in my list. Computers today are a whole-family thing and it is not unusual at all to have multiple users for one computer and I remember discussions on this forum as well where people would want to have different settings for different users in LFS. And while LFS is small, many other software (esp. games) for sure arent; My Dragon Age - Origins install is 15GB for example and duplicating this for all users would be a big waste, plus then also having to keep backups of all this data as well if the game would not separate the install data and user data.

Quote :You have to hunt down all the different locations that a program has installed itself to by searching in regedit and clicking through multiple hidden folders with names like 'C:\Users\<user>\AppData\LocalLow'. Hardly 'easy transfer and backup' is it?

You backup your whole home dir (and the user registry keys) and its done. You can do it manually of course but typical use scenario would be to use a tool that does this for you (afaik. Windows 7 for example comes with some kind of transfer wizard that allows you to transfer these to a new windows installation very easily). And if all software would follow these guidelines then these tools would be simple to use and would really work - You backup the user data and everything "irreplaceable" is safe with minimal effort. Look at an LFS install for example; how could a generic backup tool know which files are install data that does not need to be backed up and which files are the user data? With the user data under the separate user home dir, you backup all that and everything is safe.

Quote :And there isn't even a way to change the location of these special folders to another drive than the drive the OS is installed to.

You can change the user home dir to any path you want from the user profile settings any time. You can also change the default path from the registry, but it is better to change that before install... I dont know if there is an official and easy way to do this but tools like nlite allow it.
Worked without a problem for me, running Windows 7 X64 Professional. On the default folder discussion, I really don't care where it gets placed. I run my own folder at c:\games that houses all my games(much like Victor it seems). I actually recommend this to other people if you reinstall windows fairly often. It saves me having to reinstall about 70% of my games because most of them recreate the registry settings when you run them, or run perfect without them. Either way most modern games run just from the directory(which is strange I had more trouble with that near 2000 than I've had lately). Either way I'm in the habit of changing the install directory on everything I install anyways.

Luke
Quote from Kegetys :(All this is documented by Microsoft and they do provide guidelines for using them, for example here. I think the only reason why the situation today is such a mess is that many developers simply do not follow these guidelines)

Thank you for the link and comments.

I realise I should not really pass judgement on Microsoft's efforts before I have investigated and begun to understand it.
Quote from Kegetys :Roaming is the only one in my opinion, and also the reason why I didn't include it in my list. Computers today are a whole-family thing and it is not unusual at all to have multiple users for one computer and I remember discussions on this forum as well where people would want to have different settings for different users in LFS. And while LFS is small, many other software (esp. games) for sure arent; My Dragon Age - Origins install is 15GB for example and duplicating this for all users would be a big waste, plus then also having to keep backups of all this data as well if the game would not separate the install data and user data.

True, about large programs like games, I guess. But concerning home users using multiple accounts, I think that the trend is more likely to be less people sharing computers than in the past due to ultra cheap PC and laptop prices.

Quote from Kegetys :
You backup your whole home dir (and the user registry keys) and its done. You can do it manually of course but typical use scenario would be to use a tool that does this for you (afaik. Windows 7 for example comes with some kind of transfer wizard that allows you to transfer these to a new windows installation very easily). And if all software would follow these guidelines then these tools would be simple to use and would really work - You backup the user data and everything "irreplaceable" is safe with minimal effort. Look at an LFS install for example; how could a generic backup tool know which files are install data that does not need to be backed up and which files are the user data? With the user data under the separate user home dir, you backup all that and everything is safe.

But what if I only want to backup one program, not my whole User folder? As an example Oblivion is at 'C:\Users\<user>\Documents\My Games\Oblivion' and 'C:\Users\<user>\AppData\Local\Oblivion'.

So the backup procedure would be
-unhide folders
-set windows search to also search in hidden folders
-search the users folder for oblivion and hope nothing gets missed
-recreate the folder structures at your backup location
-copy the found folders

Hardly simple compared to just copying one folder, that you know exactly where it is, as you put it there yourself or were at least asked about it during install.


Quote from Kegetys :
You can change the user home dir to any path you want from the user profile settings any time.

Could you point me there, I couldn't find it. Would be extremely useful for Win 7 on my 4 GB SSD eee.

Anyway, thanks for the discussion, at least I now have an idea what it's all about. It does seem to me that the idea of data separation by type isn't a bad one, but is too complicated in Windows, or maybe missing tools and guidelines. Maybe each software should have a standard data manager, like it has an installer and an uninstaller, a tool that will tell you which data is where and let you move and copy it.
Quote from Kegetys :The new, in my opinion proper, structuring is basically as follows:
- Executables and other static data in Program Files
- All user specific and "dynamic" data in user home directory*

something tells me that this would end up with a proper mess and possibly broken used data during test patch runs

as far as test patching goes it doesnt get any easier and more userfriendly than selecting your entire lfs folder and copy pasting it to a new location that you can then apply the test patch to thus creating a entirely seperate copy of lfs (without any problems caused through not having that folder properly configured in the registry or whereever else)
I'm assuming we are all above average computer users (windows users) _in here_ and even we cannot come to a uniform conclusion or understanding. How on earth is an average windows user supposed to understand all this?
It's all good and well that windows programmers invented this security but they forgot that normal people will be using it. And linking to some articles written again by programmers isn't gonna help either if people won't find it. MS has totally forgot to inform people on how to use Windows, or did they expect us all to take a Windows class? And people complain about how *nix is hard to use...

So the result is that we will provide the default folder of C:\LFS
If you want your LFS somewhere else, you're totally free to do so.

Looks like there aren't any more problems, so prolly the installer will be replacing the 7zip tomorrow.
Replacing? Please nooo

Keep old 7zip too please, it is much easier to use
Quote from Shadowww :Replacing? Please nooo

Keep old 7zip too please, it is much easier to use

Both can be from the context menu in exactly the same way, there's no difference if you want to use the installer like a standard compressed archive.
Victor,the default folder is just as a suggestion after all.
Anyone is free to change it to suit his needs.
Quote from Victor :So the result is that we will provide the default folder of C:\LFS
If you want your LFS somewhere else, you're totally free to do so.

one solution that could make everybody happy would be to use the standard intended windows way by default but link to the file locations in the cfg so anybody can set it up to their liking
this would allow anything from %userfolder/appdata to the good old ./data or some other location on the drives
will try, but I'm not a fan of installers, they only do useless things and no body ever knows what it really does, registry etc.
if you can stay with the packed version (zip, rar, 7z, ...) it would be good, no installer needed, never had any problems, thx

Quote from Victor :...
Looks like there aren't any more problems, so prolly the installer will be replacing the 7zip tomorrow.

NOOO

just learn how to use your computer people, packed version much easier, download -> unpack -> play
Quote from JackCY :will try, but I'm not a fan of installers, they only do useless things and no body ever knows what it really does, registry etc.
if you can stay with the packed version (zip, rar, 7z, ...) it would be good, no installer needed, never had any problems, thx

Right click on the installer, "Extract to Live for Speed", click that, done.
No need to keep the 7z packed version, just the installer one, and anyone can extract it and play without running the installer.
Quote from Velociround :Right click on the installer, "Extract to Live for Speed", click that, done.
No need to keep the 7z packed version, just the installer one, and anyone can extract it and play without running the installer.

oh OK, if it can be extracted, but normal installers can't or only with some tools (not for normal users)
Quote from JackCY :oh OK, if it can be extracted, but normal installers can't or only with some tools (not for normal users)

InstallShield != normal installers.

I just did some research and found that NSIS, Inno Setup and Smart Install Creator-produced installers can be unpacked that way.
Quote from J.B. :Could you point me there, I couldn't find it. Would be extremely useful for Win 7 on my 4 GB SSD eee.

In XP one way to change it is from computer management, local users and groups, users and then right click on the user and go to properties. In the 'profile' tab there is a setting for home folder, which should default to empty (In which case it will use 'documents and settings', or 'users' in vista/7).
I installed this on my laptop, installation works fine... but where are my spr/setup/mpr folders? Can't find them, and if I try to open a MPR file, it gives the follow error: 'Error copying file'

Installed it in C:/Program Files/Live for Speed, should be possible right? Even if that's not the intention of you guys.

-Edit: Works after launching LFS.exe first. Still think mpr/spr/... folders needs to be in LFS default folder. (like now) Or isn't this possible with the auto-file association?
Quote from zeromussov :I installed this on my laptop, installation works fine... but where are my spr/setup/mpr folders? Can't find them, and if I try to open a MPR file, it gives the follow error: 'Error copying file'

Installed it in C:/Program Files/Live for Speed, should be possible right? Even if that's not the intention of you guys.

If you have Windows 7 or Vista(?), look at: C:\Users\user\AppData\Local\VirtualStore\Program Files\Live for Speed The AppData folder is hidden by default
Lol,people are complaining about the installer
I should've expected that.
worked well here.
liked the new file association feature.

chears.
All works great, good work.
This thread is closed

LFS installer package test
(213 posts, closed, started )
FGED GREDG RDFGDR GSFDG