Amen to that. I don't know how many times I've gotten nested trying to do something in code only to find that there was a simple way to do it in the first place.
Thanks again.
It means The simplest Solution is usually the correct one
Thanks - that did it. Just in case the comment spewers are correct I now know for sure what {commonappdata} produces on any system. Of course, I guess I knew that anyhow via the project code, but this way I'm protected against possible conflicts between the project code and ceratin systems.
BTW, what is Occam's Razor?
Just remove the space
{code:GetCommonAppDataFolder}
I take no stock in people who just spew out comment without any testing to back it up... So those comments have no merit to me.
Occam's Razor...
Thanks. Looks like a straightforward approach - via the .ini file I capture whatever folder {commonappdata} produces and use it in my first-run code.
However, as is usual with me, a problem. When I compile the modified Inno Setup script I get the following error:
Required function or procedure 'GetCommonAppDataFolder' not found
Here's what's in the script as copied directly from the script:
[INI]
Filename: {app}\GHM.url; Section: InternetShortcut; Key: URL; String: http://www.sportswaregolf.com (http://www.sportswaregolf.com)
Filename: {app}\GHM.ini; Section: System; Key: Commonappdata; String: {code: GetCommonAppDataFolder}
[Code]
function GetCommonAppDataFolder(Param: String): String;
begin
Result := ExpandConstant('{commonappdata}');
end;
What to do? I checked out the Inno Setup examples and the format and content of the [Code] section is the same as what we have.
BTW, as to the apparent claim made in the Inno Setup Newsgroup that all systems running with the same OS may or may not have the same folder for All Users data - is that accurate? Even if it is, the .ini should resolve things if we can get it to work - that is, I will have the name of the {commonappdata} folder whatever it is.
I found it.
If you want to test just put a line like this in a test Inno Setup Script. It will put the value of {commonappdata} in the myApp.ini file.
[Ini]
Filename: {app}myApp.ini; Section: System; Key: Commonappdata; String: {code: GetCommonAppDataFolder}
[Code]
function GetCommonAppDataFolder(Param: String): String;
begin
Result := ExpandConstant('{commonappdata}');
end;
If you could post a link to that thread it would help. I don't have the time to go searching for it.
Please do me a favor - check out the post titled {commonappdata} Paths that I started on the Inno Setup support board and tell me what you think (about other than how I managed to make duplicate posts). It contains some things that have left me more confused than ever. For example:
-- There's some GetSpecialFolderLocation discussion and code that seem to go beyond (expand) the project code you gave me.
-- There's the following statement: The path returned by Windows XP is not even identical to the path returned by Windows XP. (How's that for a confusing statement!)
-- Another statement: All Win2K systems (and presumably XP systems) do not have the folder: Drive Letter:Documents and SettingsAll UsersApplication Data.
That's just a sample. The bottom line is that now I'm not sure I can use my first-run code with the project code to determine where {commonappdata} placed the skeleton data files that I want to replace, at least not on all systems that use the same OS - even if I restrict use of my app to Win2K, XP and Vista.
Help - please!
2) With respect to what W98 supports and doesn't support, a point of logic: If {commonappdata} in Inno Setup produces an All Users Data Path why doesn't the project code?
You haven't answered this question. Plus, do I have to modidy the code to get something as straightforward as the System Drive that wasn't part of the Win98 output?
But enough, really. It's clear that I can't use the project directly for 98 (and probably Me) and I am not going to attempt to modify code related to system areas with which I'm not familiar. I'll revert to the options I mentioned earlier.
No need to respond to this post. The debate is over on my end.
The project was never titled Finished It was stated you could use it to get what you need. There are many items of which the code made no reference but if you used the code and expanded it you could get most anything you need. The module where you can get this information is very well commented. You have to modify the code to find the item you need.
Let's end this debate and the possible interpretation that I don't appreciate the excellent support you have provided. Before I close my end let make just two points based on your last few posts.
1) I do not consider the project code a sample. It was presented to me as a finished program with which I could support ALL systems.
2) With respect to what W98 supports and doesn't support, a point of logic: If {commonappdata} in Inno Setup produces an All Users Data Path why doesn't the project code?
Let's remember, I was not hired to write code. I am just suppling SAMPLES that can get you on your way as a courtesy.
the project is pretty well documented and the routine that receives the folder names is very straight forward. The results if empty would mean unsupported... It is well known some function would not return results in early Operating Systems. Look in the API-Guide...
You comment on code so much I suppose you write perfect code?
Now let's not get nasty. Of course, I, like anybody else, doesn't write perfect code. But I do try to explain what happened when the code produces an unexpected or unintelligible result.
You comment on code so much I suppose you write perfect code? to get so much help and still complain very badly...
There is no flaw... Research it and you will see that Windows 98 doesn't support a lot of things. What Windows 98 doesn't support does not constitute a flaw for Microsoft calls that do not work on said system...
You can argue with Microsoft on that one...
There is no such thing as one solution fits all just one solution fits most...
Last comment on the project code: A flawed solution doesn't fit most anybody. It's clear that there's a flaw in the code with respect to Win98. In the least, if the produced output is a reflection of a particular system situation, the reason(s) for that output should be communicated in some way. The output I received doesn't convey anything about what caused it.
Yes, you still need to do some of the work as with everything. There is no such thing as one solution fits all just one solution fits most...
That would be my suggestion... to test in the environment you want to deploy.
Not to be combative, but I believe it was you who encouraged me to support ALL systems vis the project code rather than hard-code the {commonappdata} paths I know for sure for Win2K, XP and Vista. Now you me, at least implicitly, to forget about 95 and Me.
As for used properly and you must do some of the work, what's that all about? What does used properly mean with respect to a program than one is simply supposed to run to receive information? Does doing some work mean I'm supposed to debug code that presents limited, unidentified and unintelligible output (I could call it garbage output) on a Win98 system (at least mine) that is different than what it provides on other systems?
Enough. Here's what I'm going to do. If Inno Setup Support can tell me what path {commonappdata} generates for WinMe, I'll support both 98 and Me. Otherwise, I'm just going to support Win2K, XP and Vista.
It is all I thought it was... Used properly it will give you everything. You must do some of the work.
I don't deploy to 95 or Me for they were really bad OS and I would not support either. MS won't even support either...
I don't know about Me I never use it and if I wanted to deploy to it I would just test on it.
Easily said but I don't have, and don't know where to get access to, an WinMe machine. Perhaps Google or the Microsoft KB can help (but I doubt the latter).
Again, why doesn't the project code show all the parameters? It looks as though this code isn't all you thought it was.
I'll explore options in Inno Setup.
To find out, In the project code all you need to do is change the message box to show the parameter in front of the actual data.
I don't know about Me I never use it and if I wanted to deploy to it I would just test on it.
In Inno Setup you could probably display a message box with the parameter you want to know about or you can just write the data to an ini file.
New news after a thought wave. I searched for one of the files that Setup installs. It's in C:WINDOWSAll UsersApplication DataGHMDATA. So obviously there's a disparity between what the project code presented and what Setup derived via {commonappdata}.
I guess I'm going to have to transport my project to the Win98 machine and use some test code to see what the project code returns. Or, is there some way Inno Setup can provide what it uses for {commonappdata}? Whichever, the question about WinMe remains.
Find out which parameter gave you that
I'm not sure how to do that given what was output from the project code in a standalone run. Given the DATAPATHCODE content in the first line of the output it seems logical that Local SettingsTemp is the data path. What's not shown is that Local Settings is a subfolder of the Windows folder.
So yes, if I knew that Local SettingsTemp is the data path for W98 I could recognize it and change it to WindowsLocal SettingsGHMDATA. What about WinMe? If it's the same as Win98, no problem. If it's not the same, I need to know what it is. Do you know?
Of course, my other less desirable option is not to support Win98 and WinMe systems.
BTW, why doesn't the project code show all the variables that it shows for XP and Vista?
That is becase windows 98 did no support security as we know it tday. So you do need to fudge it a bit. I would use the Local Settings folder and create your appdatapath there. Find ou which parameter gave you that and us that for your Win 98 systems.
Back to non-network. I'm trying my just for kicks install and run on the old Windows 98 machine I hauled out of the storeroom. Okay with Setup. It ran through, including something new - a direction to restart the computer Probably because of the AutoOSUpdater). However, when I ran the app I got a Path Not Found Error (76) in my first-run code.
I'm guessing the problem is related to the generation of the AppDataPath from your project code. To research I installed the project code and ran it. Instead of the usual list of all the constants I got the following in a small window:
Randem SystemsDATAPATHCODE
Local SettingsTemp
and the OK button.
What's happening? My purpose other than testing the install on W98 was to determine the AppDataPath on W98. I'm also interested in WinMe (which may be the same). I want to include these in the app's User Guide so users know where there data is.
Because of the added protection on Vista you may not be able to install in or share certain locations without going thru a lot of trouble. To the user (client) the location is immaterial but to the installer on the server it is important.
it's just where you install the files on the server that may change.
Do you mean the data files? If so, why may their location change?
Correction - I was thinking about data files not the app. The sharename can be Program FilesGHM for the app install.
No, you don't have to include a different share name for each OS. That part will remain the same, it's just where you install the files on the server that may change. The UNC will stay exactly the same, if you share it correctly...
PLEASE...
You should have capitalized PLEASE about starting a new thread.
At this point I am using the Beta version but I won't be distributing the app for another few weeks. As for the network install, I had a PDW-created Setup running on both a XP and Vista system. I understand app on each machine and database on the host (server). What I do for the client machines is have them install via a UNC Path to the host. The installation instructions tell the user to overwrite the C:\Program Files\GHM installation path with the UNC Path. That was simple when the app and the data files were in the same shared folder - I just used \computername\sharename where sharename was the folder name. I guess I'm now going to have to provide different sharename content for each OS.
Most of the users have only two or three client machines using the app. In fact, most of those on a network only use a single machine, in which case I have them install locally to C:\Program Files\GHM on that single machine.
I believe I'm okay with concurrency checking. I've read your Database Problems article and I will read it again.
Good,
No, well leave the title as is for others to read how one change actually change their minds about something with the proper support.
I take it you are using the Beta version to deploy your system?
On the Network install what do you expressly want to do? The app will still need to be installed on each users machine and the database on the network.
How many users will you support and does your app support concurrency checking for the database currently?
Look here for more information - Database Problems (https://randemsystems.support/multi-database-control-%28rsdbcontrol%29/database-problems/)
For the Network install... Please start a new thread...
After all I've been through, and all I've put you through, I believe I now have one Setup program for all Windows systems from Win98 through Vista. I specified 98 as the minumum Windows Version and NT 4.0 as the minimum NT Version, adapted a script, created a Setup program, and installed and ran the program successfully on my XP Virtual PC and Vista computer. (BTW, the Dymo dll register problem did not occur on either system.)
All I can say is a sincere Thank You. Although you may not be done with me yet as I move on to a Network install and test, I believe I have a decent handle on things. In fact, if you can, you can change the title of this enormous thread from I'm About to Give Up on InnoScript to I'm Comfortable With InnoScript.
That's good that you have found the templates useful. They were designed for users to add functionality to the program before it was actually in the program.
You are select the MINIMUM Windows version that your app will be installed on.
That is very clear and it is in the documentation. No need for intuition. I aplogize for the check boxes comment.
As for the ActiveX exe, I'm glad my experience with the dll found something for you. Although I didn't need it, thanks for the details on the template. Believe it or not, I've done so many things template-wise that I've become pretty good at it.
The line in your template file should look something like this:
[Files]
Source: e:workstombuggydymolbl.exe; DestDir: {app}; Flags: restartreplace sharedfile;
Use the template and copy the line with that exe into it and remove the regserver flag from the line in the template and re-run.
That should solve that problem. The correct to that will be in the next release of the Beta version.
I just realized that you are attempting to register a ActiveX exe. You should not be register that file it will register itself when it is run.
1) You are select the MINIMUM Windows version that your app will be installed on.
2) I got the error message on Vista also but not on XP.
1) I guess we have a bit of a communications and/or semantics situation, or I'm misinterpreting the sequence direction of the selections in the OS sections. I am assuming a top-to-bottom sequence - for example, if I select Win95 I also get 98 and ME covered. And, if I select NT 4.0 I also get Wink2K, XP and Vista covered. Is that correct? Or, is it the opposite - for example, selecting Vista gets you everything above it in the list? (BTW, check boxes instead of option buttons would be more intuitive.)
My Vista Setup has only the Vista button checked and None in the other section. The other Setup has Win95 and Win NT 4.0, which worked on XP.
2) That's interesting news. I'm going touninstall the Dymo printer on the Virtual PC XP system and see what happens.
1) it is exactly logical. The latter What???? Your app is the only thing that will support these OS's and you already stated that they did. So why would selecting that it would be OK to be installed on these OS matter?
2) I did not get a problem here when I installed your software and I definitely do not have the Dymo printer installed.
1) I interpret what you're saying is that I should make Windows 98 the Windows Version selection and Vista the selection for NT Version. It doesn't seem logical (or at least intuitive) that the latter will support XP and Win2K - ?
2) I do not believe that the situation with the Label Printer is just a Vista situation. I assume (research/testing required) that it will occur on any system that doesn't have the Dymo printer and software installed. I'll have to do some research on Tasks. I'm not aware that you can use questions to the user in the script or setup and base what is installed on the answers.
As for why the dll fails, the regservr error code is 0x4. I'll do some research.
1) If the script states that the lowest version of Windows is 95 (Which should not be supported without Advil or something stronger) and the NT version is Vista it will support all versions.
2) First Question: does the label printer work on Vista even with the file not registered? If so then on Vista just do not attempt to register the dll. Two of the same lines except one uses the OnlyBelowVersion parameter and one uses the MinVersion parameter to distinguish between Vista and every other OS.
You could put in a task that the user can select to install the label printer or not and on Vista you could disable the task and un-check it.
Second Question: Why is the dll failing. Research, research, research...
You will be pleased (and perhaps surprised) to know that your project code is now included in my app and that I have successfully installed and ran from Inno Setup packages for both XP and Vista. Now that the GetSpecialFolders code is in the app I can support any version of Windows if any users are foolish to be on any version less than Win2K. Just for kicks I may try to install and run on an old Win98 computer in the storeroom.
I'm looking forward to getting back to thorough testing of the app itself and network installations. Before I do I have two questions:
1) For whatever testing reason I have two Setups. One has Windows 95 selected in the Windows Version section of the script and NT 4.0 selected in the NT Version section. The other script has None selected in Windows Version and just Vista selected in NT Version. Can I use the first one for all systems, including Vista?
2) Not all users will be using the Dymo Label Printer. When I install on my Vista system that does not have the Dymo software installed I get an error during install that says the .dll for Dymolbl.exe cannot be registered. I can click Ignore without consequence but I'm concerned that users will be confused, especially given the presented Not Recommended associated with Ignore (even if I provide documentation about it). I've tried to use the noregerror flag in different parts of the Flags: section for the file but I still get the error message during install. Is there a specific place in the Flags section where noregerror has to be placed, or is there another way around the situation? I really don't want to have spearate Setups for those that do and don't have the Dymo printer.
Also add the folder to the Exclude Folder Tabs so that it won't happen again, if I am reading you correctly.
Oh Boy! The problem was not with the file copy code (although the adaptation of your project code is simpler and I'm now using it).
The problem had to do with where the GHM.EXE file is being sourced in the script. The Search Paths in the script include the location of the PDW Package files (where I have the default databases) and GHM.EXE is being sourced from that location. After I modified the app and recompiled to include the code for the files copy from GHMCONV I didn't run the PDW to place GHM.EXE in the Package files. Therefore, Setup was installing an old version of the app that did not contain the files copy code (Duh!).
Although I've resolved the problem by running the PDW, I want to change the script to source GHM.EXE from the VB folder so I won't have to run the PDW to get the latest version of GHM.EXE in the PDW Package files. I tried to add the new sourcing to my template but two Source items for the file were generated - my template addition from the VB folder and the original source from the PDW Package files. Apparently the inclusion of the Package files folder in Search Files is taking precedence. I suppose I can just source the other files I need from a folder outside of the PDW Package files, eliminate the PDW Package files folder from Search Files, and add the VB folder to Search Files.
I think you are over-complicating matters. In the code project I posted there is a simply few lins of code that copies whole folders. It can easily be modified for you situation. All of our apps use it with no failures...
I checked the clean Virtual PC XP machine. The only place where the .DAT files are present after installing and running the app is the GHMCONV folder where they are to be sourced from in the app's GetFile statements. For whatever reason they are not being copied by the fil.Copy statements. No error is reported on the statements. The app runs to a point where it repors that a file that is supposed to be in the AppDataPath folder isn't there.
BTW, while trying to resolve this situation AppDataPath is hard-coded as C:Documents and SettingsAll UsersApplication DataGHMDATA. And that's where the files get copied to when I run from the IDE.
BTW: Thats a lot of overhead when a simple FileCopy Statement will do. Beside the FileCopy command doesn't need all the overhead of the Scripting Runtimes...
Yes, the first-run code is in the app and the code snippet I posted is app code being used to copy the files. Dltr is a variable that contains the Hard Drive letter - e.g. C:. I create it from the first two characters of App.Path.
I'll check for the files in other places but the GetFile and fil.Copy statements are explicit - they include the Drive and Folder for both the source folder/file and the AppDataPath.
Also in your code:
fil.Copy (AppDataPath & GHM_V70.DBF), True
should be
fil.Copy (AppDataPath & GHM_V70.DBF, True)
How did you get away with this? Do you have Option Explicit at the top of each form/module/class? The way you did it Overwrite is possibly False...
I guess for upgrade users I could source in the script the database files and the .DAT files from the GHMCONV folder and not include the default database files. That would mean I'd need separate Setups for new users and upgrade users. However, I'm wondering why the first-run code works in the IDE and not after the install with the present Setup.
Is your first run code in your app? The code you posted is the code you use to attempt to copy the file?
What is Dltr?
It would seem that you are coping the file to another location. Check for that. That can happen if the current folder changes. You are not where you think you are when you try to copy.
I assume you mean your application copies the files to the correct location? -- Yes
Which files are we talking about? -- The user's real database files (such as GHM_V70.DBF) that are to replace the skeleton .DBF's) and a few .DAT files that contain user specifications such as options used, course definitions, etc.
Isn't this what you want? What else do you want there? -- For new users that's all I want. For upgrade users (which is this case) I want to replace the default database files and add the .DAT files. The first-run code is only used for upgrade users.
Script is attached.
When I run on my development machine out of the IDE everything is fine - all the files get to the app's data folder as desired.
I assume you mean your application copies the files to the correct location?
However, when I use the Inno Setup program to install on the Virtual PC XP machine or my development machine, the files don't get to the app's data folder
Which files are we talking about?
only the default database files placed there by Setup are present.
Isn't this what you want? What else do you want there?
I would need to see your script...
Okay - I've compiled your project and run it on my development machine, the Virtual PC XP machine and the Vista machine. Neat! I intend to use it in the near future. In the meantime I have a nagging problem that I hope you can help with.
As I've mentioned, for upgrade users I have first-run code in the app to place their data files in the app's data folder. This includes overwriting the default database files installed by Setup and copying some other data files that are in a folder (GHMCONV) that has been created and filled by conversion code in the old app. I am a using File System Object as illustrated by the following code snippet:
If FCfso.FolderExists(Dltr & GHMCONV) = False Then
MsgBox 'Error Msg conversion task not done in old version
Exit Sub
Else
Set fldr = FCfso.GetFolder(Dltr & GHMCONV)
Set fil = FCfso.GetFile(fldr & GHM_V70.DBF)
fil.Copy (AppDataPath & GHM_V70.DBF), True
.
.
.
End If
The two GetFile and fil.Copy statements are repeated for the remaining files.
Here's the problem. When I run on my development machine out of the IDE everything is fine - all the files get to the app's data folder as desired. However, when I use the Inno Setup program to install on the Virtual PC XP machine or my development machine, the files don't get to the app's data folder - only the default database files placed there by Setup are present. What could be causing this?
Ok, well you can use it...
With me there aren't any no brainers.
At least compile the project and run it on both your XP and Vista systems to see what I am talking about.
implementing it into your app would be basically a no brainier...
BTW, now that I've clearly established that I have a fallback, I AM going to see if I can understand how to apply and use your code.
Nice smiley!
Yes...
But, if I inadvisably ignored you, I could hard code the paths for the two installations - ?
In the installation {usercommondata}GHMDATA would be the same for either installation. What I a talking about is not having to have two different applications (one for XP and one for Vista). If you use the code I supplied you would not have to worry about which os your app was running on. The code would automatically handle it. No hard coding needed...
We have something in common and it's not an understanding of OS's, security, etc. My Handicap Index is 8.9. It used to be 5.0 a few years ago and I once was a 3 but that's as old as my systems knowledge. http://www.dutchessgolf.com (http://www.dutchessgolf.com) I see your club took advantage of your webmaster skills. Our folks (not including me) still use FrontPage. I'm the Club Historian.
So, I can use {commonappdata}. If I recall from previous discussion, the path for Win2K is the same as that for XP. As was also discussed, I am going to restrict the app to Win2K, XP and Vista. Now, IF (contrary to your recommendation) I were to go the simple route and have separate installation packages for Win2K-XP and Vista, I assume I can hard code the paths for each, including a subfolder for the app's data - {usercommondata\GHMDATA.
Yes, I understand handicapping, I am a 9 and I have a golf club Reggae Golf Crew (http://www.reggaegolfcrew.com)
Sure in that situation you can install it in the common (All Users) Folder. {commonappdata} will go to the All Users folder, mind you that this common area is different in some Windows version and if your app doesn't handle it properly it doesn't matter what you do in installation. This is why the project I gave you is so important in that area.
In XP it will go to C:\Documents and Settings\All Users\...
In Vista it will go to C:\ProgramData
Your application has to be able to seamlessly use either one and not care which. So it cannot be hard coded.
No, I CERTAINLY (not probably) don't understand security, but I don't think security understands my app. The user CANNOT affect the data in terms of physically adding to it, changing it, etc. - which is what I thought security was supposed to be all about. Again, the user does not have direct access to the data, only the app does.
Perhaps there's an aspect of the app that you do not understand. If the common data shared by all users in a given installation (again, each user does not have his/her own data) becomes erased, damaged, etc. I DO NOT want to replace the data with the default files. The current data has historical significance. Without going into all the specifics of golf handicappiing, a player's handicap is based on some number of the player's previous scores and is updated each time a new score for the player is entered. Therefore, in the erase/damage situation restoration of the databases is from a backup/restore capability provided within the app. Thus, I don't see a reason not to install the data files directly in Setup.
BTW, new users get the default files. For users upgrading to the app from its previous version that had a different database structure, there is a first run capability to replace the default files with converted files from the previous version. And, for future releases of the new app to existing users, data files will not be installed at all unless there are changes/additions to the database structure.
It's not that I refuse to look at your project. It's a matter of thinking that using {commonappdata} in Inno Setup is a more direct and simpler way of establishing the location for the data files. Perhaps I should ask the Inno Setup folks about the paths generated for each OS. If {commonappdata} is not a reliable source for the paths I will certainly consider your project.
The user can affect the data. You probably just don't understand security. The app is under user control therefore it can only do what the user is allowed to do nothing else. If the user has privileges then the app has the same privileges, Not so dumb...
Perhaps the users data was erase, corrupted or damaged or you just wanted to start over. All you would need to do is to erase the data files in the All users folder and new default files would be copied upon next run of the app. Installing them to that location would not allow you this option.
I gave you a project that would determine the correct folder for each OS but you refuse to even look at it. Understanding such issues as profiles would be done by running the app under different Windows version and all would be CRYSTAL CLEAR.
Testing is the way to verify hypothesis...
It's the user who is running the app so the app only has the privileges of the user.
Forgive the emotion but I think that's dumb. If the user can't directly affect the data, why should the app be dependent on user privileges? I can see user privileges affecting a user's ability to run the app but it seems to me that privileges to affect the data should be assignable to the app (and always be allowed). But what is, is - so there's no point in further comment.
If the users will share the data you copy the files to All Users Application Data Profile.
As we've discussed, that is the case. Forgive me if we've discussed this before but why have a first run situation where the app has to copy the data files - why can't they be installed by the Setup program to wherever they are to end up?
Either way, Profile is a new term to me. I assume you are referring to the subfolders in Documents and Settings and I'm still not positive which these are for the different Win versions. I assume that the path in Win2K and XP is Documents and SettingsAll UsersApplication DataAppNameDataFolder. What about Vista?
Also, if the app has to create the AppNameDataFolder folder to do the first run copying, is there a Permissions situation?
No it does not change things... It's the user who is running the app so the app only has the privileges of the user.
1) No, this is what started all of this discussion about the limited user...
2) You can have the app place the data file in the {app} folder, This too we discussed. You want to install them there and upon first run copy the default files to each user if the users will not share the data. If the users will share the data you copy the files to All Users Application Data Profile.
3) The permissions are the same in all NT security operations.
After all the dialog we've had on install locations for app and data files, permissions, etc. I just thought of something that hasn't been focused on and may have a major impact on how I set up the installation:
USERS DO NOT DIRECTLY MODIFY THE DATA FILES. All modifications are done BY THE APP based on user interaction with the app. (For example, the user enters a score for a player; the app adds the score to the database.)
Does this change things?
1) Can I just place the data files in a subfolder of the app's installation folder (Program FilesGHMGHMDATA)?
2) If so, can I (and how do I) specify things in Inno Script to do that and stay away from all the folders in Documents and Settings?
3) What are the Permissions implications in Win2K, XP and Vista, respectively?
With respect to 2) I'm thinking I can use my Template to directly specify the Destination Folder for the data files - DestDir: C:Program FilesGHMGHMDATA; Flags: ignoreversion uninsneveruninstall;
Yes, that is what I meant. I guess I got happy fingers on that one
In the first sentence of your last post I think you meant to say that you should only be able to modify folders under All Users that YOU CREATE (versus did not create). That's consistent with the second sentence.
You should only be able to modify sub folders under the All Users folder that your did not create, that is what security is for. If you did not create the folder you should not have privileges in that folder unless explicitly given to you by the creator.
Now I'm really confused. My small app does the following:
-- Fills a variable AppDataPath with C:Documents and SettingsAll UsersApplication Data
-- Makes a folder TESTDATA under AppDataPath
-- Creates a file in the TESTDATA subfolder
-- Writes some data to the file and closes it.
-- Reopens the file and writes some changed data.
It works from the Limited account with no Permissions problems, and what I did did not involve setting permissions with the TweakHound method.
So what's confusing? Well, I still can't add from the Limited account a text file via File/New/New Text Document to All Users or any of its subfolders except the new TESTDATA subfolder I created with the small app. Why the difference with the small app?
I've also made some corrections in the use of the File System Object code in my main app - the code that overwrites the skeleton data files placed in the Documents and SettingsAll UsersApplication DataGHMDATA folder by Setup. That works as well.
So, it looks like a have a solution but I don't know why!
No, neither InnoScript (at least the latest versions) or Inno Setup require administrator privileges.
I asked the wrong question - I should have asked about the Setup program created by Inno Setup with the script from Inno Script. Is not one of the InnoScript Parameters: Privileges Required: Admin?
BTW: I just finished installing XP Home and I can change/create/delete in those folders as a limited user...
Which folders are you referring to? If they're the Local ones with yourusername that doesn't do me any good. Again, my situation is a common set of data files used by All Users.
I'm going to test things beyond the text file insertion via the Run menu by creating a small app that creates folders and files in various Documents and Settings folders and then modifies the files.
BTW: I just finished installing XP Home and I can change/create/delete in those folders as a limited user...
No, neither InnoScript (at least the latest versions) or Inno Setup require administrator privileges. Neither app registers components, writes to restricted areas in the registry on the disk by default. That is basically what makes an app Limited User Compliant.
My unfamiliarity with the Security mess is showing. Conceptually, I see Run AS Administrator different than Run BY Administrator, and I'm thinking in terms of a PROGRAM (app) versus a USER. (Does not InnoScript and Inno Setup require Run as Administrator?)
But, I trust your knowledge and experience, and your conclusion that some entity can preclude Run as Administrator on an app.
With that I'm off to bed.
Let's say your app got into company hands and they operate on a network. They lock all the users down and they will not be able to run as administrator. You loose that sale. Or a household that shares one computer. Only the person who purchased the computer will likely have administrator privileges and the rest will be Limited Users. They will not be able to use your software. Possibly another sale lost.
If people can't get your software to run, they talk...
Yes, I have such a folder. I CAN'T create the text file there.
You say with respect to Run as Administrator: Especially if you want your app to be used widespread. Why is that?
Sure but avoid it at most cost!!! Especially if you want your app to be used widespread. Curious, Do your have a folder something like
C:Documents And SettingsyourusernameLocal SettingsApplication Data
If so then try the test there. The place where you are attempting is the roaming area of the profile. See if there is a local part.
It looks like the Vista Home editions (Basic and Premium) have the same situation as XP Home with respect to folder and file permissions - no built-in capability to change. Emotionally, how could Microsoft do such a restrictive thing?
It may be that the most direct way to overcome the situation is to get the app to Run as Administrator. Can that be done?
Can you run the System Thing Automatically on installation of your software?
I don't think so, at least for Method #1 - it includes a couple of GUI screens that require input. There is a Method #3 in the TweakHound article that might be able to be automated. I'll look at it further.
Good you found a solution. I haven't yet finished my installation of XP Home yet. It's still underway in the background... I'll let you know the results.
Can you run the System Thing Automatically on installation of your software?
Mystery solved - good 'ol Google. THERE IS NO BUILT-IN WAY TO SET FOLDER AND FILE PERMISSIONS IN XP HOME! Do a Google search on XP Home Permissions and you'll see a bunch of hits on the subject, including and article from TweakHound and some $10 software.
I tried the TweakHound Method #1 (SHRPUBW from Start/Run) on my Virtual XP Home machine and it worked - I was able to create the new text file in D&CAll UsersApplication DataGHMDATA in the Limited User account.
Notes on SHRPUBW:
-- It must be run in the Administrator account (get Access Denied in Limited User).
-- The first option on the second screen is different than the article (it says read only versus full control). Customize has to be used.
I suspect that most of my XP users have Home versus Pro. That means I'm going to have to burden them with a system thing. Also, I'm wondering if the situation exists in some of the Vista versions. I have the Business Edition which has built-in capability to change permissions. I'll have to find out about Home Premium and Home Basic.
To answer your question, no, I haven't yet taken a thorough look at your project - family visitors. I'll do so over the weekend after they leave.
We have XP Pro. I guess I could load up a Home version to see if I get the same results.
You will be able to get it to run in Inno. You do know that after you install a program in the ADMINISTRATOR account you should run it once so that any registration that the program needs will be done. However is the program attempts to register things on the fly each time it loads and does other things it should not do it will fail when running in Limited User Mode.
Did you look at the project I posted yet?
I have a XP Home machine on Virtual PC 2007 (the one I've been using for testing). The only thing that's been added to the original setup is the Dymo Label program, a screen capture program, and the PDW-created installation of my app -- plus a slew of automatic updates from Microsoft.
I get the same results when creating a text file on this machine as I do on my XP Home development machine:
-- Same results for BOTH the All Users and Application Data folders
-- Administrator: File created successfully
-- Limited User: Cannot create file - Access Denied
I suppose I can create another Virtual XP machine but it's quite a bother given the need to install XP again and I'm not sure it's going to make a difference. But I'll do it if you think it's worthwhile.
By the way, I tried to use the PDW-generated Setup for my app in the Limited Users account. When I tried to install as the Limited User it failed with Unable to generate installation log file. When I installed under my account (Administrator) it installed but the program does not appear in the list of program (All Programs) for the Limited User. However, it does appear in the Limited User's Program FilesAppName folder. I then installed as Administrator in Program FilesAppName1 (a new subfolder). That folder appears in the Program Files folder for both accounts.
I then tried to run the app from within Program Files in the Limited Users account, I got an error about a registration error with one of the components (ResizeKit.ocx).
Trying to be complete in what is becoming more confusing, I uninstalled everything (no app in either account) and installed as Administrator in the Limited User account. Again, the program did not appear in All Programs under that account but did appear in the Administrator account and could be run from All Programs. Also again, the program was in Program Files of the Limited account but could not be run from there because ofthe .ocx registration problem.
So, I can neither install nor run from the Limited User account. It looks like your warnings about PDW are valid. Then again, I can't get it to run via Inno either.
I just retried and all worked as was expected... Do you have Virtual PC 2007. If so you could create a new XP machine and try it there for something seems wrong on your machine.
Now I am going to bed. See you tomorrow.
I did that as Administrator. When I logged on to the other account I created I was UNABLE to create the file in either All Users or Application Data - Permission Denied.
Are you in as Limited User or Admin? If you can create/modify then something else is awry...
I was able to highlight/File/New/Text Document and have the file placed in both All Users and Application Data. I was also able to open the document, add info to it and save it.
It's now 2 AM here and I have 10 inches of snow to remove later this morning (be happy you're in Hawaii). If you come up with something please post it and I'll check it out later today. In the meantime I'm going to bed.
Did you highlight the folder and click on New?
Right-clicking doesn't show me anything about creating a text file - ?
Ok, wrong area was thinking registry. What you do is to go to the Application Data folder then right click and create a new text document. It should work. Do the same for All Users and it should fail.
I don't see anything about Permissions from the Advanced button, just stuff about archiving, indexing and compression. If I right-click on All Users and select Security and Sharing from the presented menu, what I see is only about this computer and network sharing.
Yes App and data in same folder works fine as long as you are not a Limited User...
You can't look just at the properties screen, you need to go into advanced and look at the permissions.
Not to get you excited, but I just installed on my XP test machine the PDW-generated Setup that I did before starting to use Inno -- App and Data in same Program FilesAppName folder -- and everything runs great. I know - I'm asking for trouble if I go that route!
On my XP development machine I was the only user and I'm the Administrator. I just created another account as a Limited User. Under that account All Users and Application Data are both Read Only.
No, that is not the case at all. All folder under a folder do not inherit the parents permissions, they can have permissions of their own.
Log in as another user and check the permission of the folder All Users and then Application Data under All Users and report what you find.
All users share the same data files.
What you tested seems strange to me. If C:Documents and SettingsAll Users is Read Only, it would seem that all folders under that would be the same. In my case all the folders under Documents and Settings, including th GHMDATA subfolder that Inno Setup added via {commonappdata}GHMDATA with Permissions: Modify, are Read Only.
I just tested in a limited users account and C:Documents and SettingsAll UsersApplication Data is Read/Write but C:Documents and SettingsAll Users is Read Only.
Do all users share the same data files or does each user have a copy of their own?
I think I may have answered my own question regards the overwriting of the skeleton files -- a .exe or batch file run WITHIN SETUP. True?
If so, what about app access to the files post-install? Obviously, the databases get updated during use of the program.
Good News / Bad News / Other News. I was able to use {commonappdata}GHMDATA and Environ(APPDATA) on my XP test system to get the separated data files in C:Documents and SettingsAll UsersApplication DataGHMDATA. That's the Good News.
The Bad News is that in the startup of my app I am trying to replace the skeleton database files installed in Setup with converted database files (ala what current users will do). I'm using a File System Object and able to establish the folder where the files reside. However, the files don't get copied. In testing within the VB IDE on the XP development computer I get Permission Denied on the file copying. I notice that all the folders from Documents and Settings and below are checked as Read Only. When I tried to uncheck Read Only a bunch of processing took place and the box became unchecked. But, when I went back to Properties the box was checked again. I tried setting Modify permissions on the files in Inno Setup but that had no effect (as I suspected given the Read-only status of the folders). What's strange (to me) is that Setup can write the skeleton files, or is that because Setup runs as Administrator. Is there a way around this?
The Other News is that I had to use the uninsnveruninstall flag on the data files in Inno Setup to prevent them from being uninstalled when the application is uninstalled. I've since modified my Template to keep the {commonappdata} and uninsneveruninstall things permanent in the script.
The change:
New: When uninstalling your application all empty installation folders will be removed from the installed location and the APPDATA location. Of course you can change this behavior by removing or changing the [UnInstallDelete] and [Dirs] entries.
Yes, Environ will work on Win2K.
The unistall method has changed I must update the history. The data files will no longer be deleted. the folder will only be deleted if it is empty.
I understand your point of view but, as you are surely awarae by now, I'm inclined to simpler things. Besides, you worry me with qualifications like MOST Windows systems and do ALMOST everything for you. I'll take a closer look at your posted methods tomorrow. In the meantime, will Environ work on Win2000?
I've installed Build 10 and reviewed the Release Notes, including the following:
New: When uninstalling your application all folders and files of the application will be removed from the installed location and the APPDATA location.
As you know, I don't want (in fact, can't have) the data files removed. Can I overcome what I think I'm reading with respect to data files via Template or Inno Setup? (BTW, if what I'm interpreting is true, why would you remove the data files/databases that the application uses and will likely continue to use? In the least there should be an option.)
Windows 2000 does have APPDATA just like XP.
Same thing. If you do it the correct way you won't need to redo it and you will save yourself possible headaches. The routines I posted do almost everything for you. Why not use them?
Right now I have exactly three users who aren't using XP or Vista (with just one on Vista). One of the three is on 98, another on 95, and the third on 2000. The 98 and 95 users are both in the snowbelt and are planning to get new computers over the winter. Plus, I doubt that any new users will be on systems prior to XP.
So, except for the possibility of Win2000, it looks like Environ(APPDATA) can be used. As for future Windows versions, I'm inclined to address them when they arrive and I'll still have the methods you posted to be used if necessary.
Therefore, what about Win2000?
When you update your Beta version make sure you check the Release History for some insight into what the latest Beta Builds have in them.
We are at Build 10 now...
No, the messages were moved to a new thread for speed (See I'm About to give up on InnoScript - Part 2) (https://randemsystems.support/index.php?topic=270.0).
If you used APPDATA and it is missing, as on systems prior to XP you wont get a location to place the data. If you used the methods like I posted in the project you will be fine under most Windows systems including future versions.
Looks like the thread got truncated a bit - the last few posts are missing. Anyway, I've taken just a quick look at the VB project you sent and will take a deeper look tomorrow. At first glance it seems (to me) to be a bit complicated way to get the application data folder. Plus, does it support beyond Win2000?
I've looked at the Inno Setup doc regards {commonappdata}. It says (using Ctrl-C and Ctrl-V):
The user constants below refer to the currently logged in user's profile. common constants refer to the All Users profile. Except where otherwise noted, shell folder constants work on all versions of Windows that Inno Setup supports, including Windows 95 and NT 4.0.
and:
{userappdata} & {commonappdata}
The path to the Application Data folder.
Given the above it would appear to a systems neophyte like myself that Environ(APPDATA) might be used. Why can't it?
Unfortunately, I've had an interruption. I'll look at your project later tonight or in the morning. You have me feeling optinistic.
Don't use the Environ statement anymore. Did you see the project I posted?
The rest is true...
In Inno Setup use the replaceable item {commonappdata} for All Users.
Is this a breakthrough? Does it mean that if I substitute in Inno Setup {commonappdata} for {app} under [Files] for the data files I can then use Environ(APPDATA) to get the path to where the data files are installed? If so, should I also add a folder name (Ex. {commonappdata}GHMDATA) to establish a subfolder for the files?
In Inno Setup use the replaceable item {commonappdata} for All Users.
Hmmm, I will have to look at that. BTW the latest Beta version in on the site...
And I put together a small project that could help you with your path issues...
Another question - why does the generated script include {userappdata}-related entries in {UninstallDelete] and [Dirs} when {userappdata} is not used in the script?
In case others are following this thread (God bless them), a typo -- it's Users (plural) in the Vista path not User.
Your Appdata paths:
XP: C:Documents and SettingsRalph JamesApplication Data
Vista: C:UserRalph JamesAppDataRoaming
Yes, I get those too (with my name). But again, I want a SINGLE PLACE FOR ALL USERS who all use the same data.
The other information was meant to get another folder or folders under the last folder in the APPDATA Path (I guess only one is required). I used what was generated in the script when {userappdata} was used. I see now that all that isn't necessary or desirable.
If you did not know about Ctrl-C to Cut then you want to know about Ctrl-V to Paste. You should not hardcode anything. There are system API's that can get you the OS dependent information since the files are going to end up in different locations and your program should not care which as long as they follow a standard.
Continuation from Part 1 (https://randemsystems.support/index.php?topic=272.0)