Title
I do not get it
Delphi 7 window 7 and ini file.
If i exe my program outside Program Files (x86) the program reads the
ini OK.
If i exe my program with Delphi 7 IDE (the file is at Program Files
(x86) ) ini is OK
If i exe my program as usual (the file is at Program Files (x86) ) ini
is not OK as it is EMPTY.
I thought administrator rights so i added manifest for that and checked
that the program
has administrator right with procedure isAdmin; it is ok program has
admin rights.
Now what buffed me is that if i run the program with "Run as
administrator" (the file is at Program Files (x86) the ini file is
loaded OK.
I tried with TMemIniFile also.
Ini is where the exe is
try maybe setting to have the ini file in \Users\[username]\Documents ?
ReplyDeleteYou are affected by folder virtualisation (starting with Windows Vista). Every application which does not declare itself as Vista compatible will not see the real Program Files folder (and many more), but a redirected folder. You need to add an application manifest to your application to stop windows from cheating. Please google for it, and how to add it to your Delphi project.
ReplyDeleteYou say you've added a manifest for admin privileges? If you start the program by double clicking, do you get the UAC dialog? If you don't get that dialog, Windows is ignoring that manifest and redirecting your file access to a virtual store. It's called a feature, but in my opinion it's a bug.
ReplyDeleteIsAdmin will return true, if you are in the administrator group. Without UAC you still don't have admin rights.
This all changed back in 2006. Your real problem is that you don't yet understand how Windows is secured, how UAC and standard user works, virtualization, manifests and so on. It's time to go back to the Vista developer docs and catch up on your lost decade.
ReplyDelete"I thought administrator rights so i added manifest for that and checked
ReplyDeletethat the program
has administrator right with procedure isAdmin; it is ok program has
admin rights."
I did add the manifest and checked it with procedure isAdmin
+David Heffernan can you point to somthing to do beside manifest?
ReplyDeleteWith all due respect to ALL. I can say that with OTHER programs ,at the same location ,who use ini IT DOSE NOT HAPPENED. In any case thank you.
ReplyDeleteWe don't know what you've done exactly. You've added a manifest. But we don't know what it is. We can't see any code. You say that the manifest has requireAdministrator but the program behaves differently when you explicitly run as admin, which makes no sense.
ReplyDeleteI don't think you really understand these issues clearly. If I were you I'd take some time to understand them fully. It looks like you are flailing somewhat, without a clear understanding.
Once you have the clear understanding you'll realise that expecting to modify files under program files is not the done thing, and you'll move the file somewhere else where you can write.
shlomo abuisak no reason to shout. What you describe is exactly the behaviour you get in Windows 7 when your manifest is faulty or ignored. So, as long as you don't answer our questions and suggestions regarding this, we keep on thinking that's the cause.
ReplyDelete"If you start the program by double clicking, do you get the UAC dialog? If you don't get that dialog, Windows is ignoring that manifest ..."
Sorry. It seem it has nothing to do with window 7.
ReplyDeleteas other programs work ok. What i do is to delete slowly all forms and then i will take off components. I will find what dose this strange problem. As all ini never gave me that problem yet.thanks.
shlomo abuisak I also prefer having all data in one location. So, I just give my application folder in "program files" access rights to "everyone", during installation.
ReplyDeleteThat's a really bad idea. Nothing that you say hangs together. You claim to have added a permissive acl, and also the require admin manifest.
ReplyDeleteAnyway, it seems that you think you know better than us. We can't help you in that case.
Crazy . The project has no forms except the main EMPTY of components and uses. The problem persist. Mad a new project clean.Form. just reading the ini. NOW IT IS OK.
ReplyDeletedid i said crazy. Delphi. I keep investigating.
Just a short question in between -
ReplyDeleteWhat I understood is: If I want to keep all files and settings (databases, ini files, ...) in one folder below "Program Files" or any other "problematic" folder of windows, I need to add/change the manifest file.
What I REALY don't want is to show a UAC dialog to the user - as my users often don't have admin rights on their machines.
Currently we simply install our software in a seperate folder like "C:\Apps\CompanayName\SoftwareName".
Is there any way to use the Program Files folders without requiring UAC dialogs or admin rights ?
Thanks for any help on this.
Christian Ziegelt
ReplyDeleteAs I posted previously. We give our program in the "program files" folder access to "everyone" during installation. Then you have the same behaviour as under WinXP. It works like a charm for our software.
I never had such a problem. I had no problems with putting database, ini and more under program file. All in the same directory. In my case it has nothing to do with directory not even Delphi or window 7 since a NEW project in that directory read the INI ok . Some thing i cannot figure out yet.
ReplyDeleteshlomo abuisak Just in case: Please check your "empty" test-project for any "WinXP" in the "uses" list. Remove that. Unit WinXP was an old and now outdated way to include a manifest for the XP common controls. This simple manifest may interfer with any manifest file which you add later.
ReplyDeleteTo be sure that the correct manifest file is included in your project, load the compiled application into a resource viewer/editor (like Resource Hacker; google for it). You should see a section containing the manifest. Is it equal to the manifest you've added to your project?
You don't seem to be listening. If your program behaves differently depending on whether or not it is run as admin, and it has the requireAdministrator manifest, how can that possibly be? You cannot run your app as standard user if what you say is true.
ReplyDeleteClearly you are somewhat muddled. Instead of flailing around, the canny choice is to step back, take a deep breath, and gather some real facts.
Achim Kalwa Ok i am not Microsoft guy ,may be Delphi. To the point there is something in the DIRECTORY that dose it. I took my test file which is empty (read only ini ) and my ini to another new directory under program file and it is ok.
ReplyDeleteI cannot find why the ini is empty (is nor loaded) only on that directory. crazy.
To add information another new project in the same dir with another ini name is ok.
Sounds like virtualization. Do you know what virtualization is? Is your app virtualized? Check this with Process Explorer or Process Hacker. When you start your app to you see the UAC elevation dialog?
ReplyDeleteNo i do not know. But in this case is dose not matter. The name i am using is MultiLaunch.
ReplyDeleteIf the exe and ini have this name in THIS folder
it dose not work. Making the name longer or shorter with the ini name the same workes. P.S i also copied the folder and did the test over there,same result.
Could you plz tel me where to learn about virtualization? although i do not believe it will help. thanks
You can just do a search on MSDN. You've already decided that it's not relevant, even though you don't understand what it is. I cannot understand your approach.
ReplyDeleteSorry
ReplyDeleteshlomo abuisak "No i do not know. But in this case is dose not matter." Yes it does - because that's what is causing your problem.
ReplyDeleteDavid Millington What i did now is moved the WHOLE folder to "C:\2\MultiLaunch - Copy" and still the problem persist. One program name do not read the ini the other one dose with the same one line of ini read.
ReplyDeleteRegIni :=TIniFile.Create(ExtractFilePath(Application.ExeName) + ChangeFileExt(ExtractFileName(Application.ExeName), '.ini'));
//
try
MessageDlg(RegIni.ReadString('Labels', 'KeyLabel_1', ''), mtWarning, [mbOK], 0);
that's it.
You are still flailing. Make the smallest possible program that reproduces the problem, and ask a question on Stack Overflow.
ReplyDeleteDavid Heffernan that is the smallest . 2 lines same uses. As a matter of fact duplicating the exe and ini and changing the exe name and ini dose the trick. I know it is hard to believe . i toght it is Delphi but it is not.
ReplyDeleteshlomo abuisak In that case, can you post the complete code to an app that shows the issue to Stack Overflow, and link the question here? Second, if you change the EXE name and it works, what do you change it from and to? That information will also help.
ReplyDeleteI have some experience in solving people's problems. Please do what I said. Make a small but complete reproduction and post in on Stack Overflow. Please do not post partial code. If you just let us help you, we will.
ReplyDeleteThe guy's on Stack Overflow band me from using it since i did not understand how to use it i think 10 years ago. I still do not understand what i did wrong.
ReplyDeleteSO is not 10 years old. Judging from the carry on here, I can see why your questions were not well received. I'd like to help, but you don't make it easy.
ReplyDeleteNot every body is the same. And perfect.
ReplyDeleteSimpler then that ?
ReplyDeleteunit Main;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;
type
TMultiLaunchMainForm = class(TForm)
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
MultiLaunchMainForm: TMultiLaunchMainForm;
implementation
{$R *.dfm}
uses inifiles;
procedure TMultiLaunchMainForm.FormCreate(Sender: TObject);
var
RegIni:TIniFile;
begin
RegIni :=TIniFile.Create(ExtractFilePath(Application.ExeName) + ChangeFileExt(ExtractFileName(Application.ExeName), '.ini'));
try
MessageDlg(RegIni.ReadString('Labels', 'KeyLabel_1', ''), mtWarning, [mbOK], 0);
finally
RegIni.Free;
end;
end;
end.
That's incomplete because we cannot see the rest of the program, we don't have the ini file, we don't know about your ACL, we don't have your manifest, and the code is unreadable here.
ReplyDeleteobject MultiLaunchMainForm: TMultiLaunchMainForm
ReplyDeleteLeft = 571
Top = 102
Width = 711
Height = 353
Caption = 'MultiLaunch'
Color = clBtnFace
Font.Charset = DEFAULT_CHARSET
Font.Color = clWindowText
Font.Height = -14
Font.Name = 'MS Sans Serif'
Font.Style = []
OldCreateOrder = False
OnCreate = FormCreate
PixelsPerInch = 120
TextHeight = 16
end
and the ini
[Labels]
KeyLabel_1=Calcu
P.S I moved the files to c:/ need manifest? why. Before i had manifest it did not changed the problem
You know, this is just a waste of time. You don't listen. And nobody can make any sense of this stream of partial code.
ReplyDeleteMake it so that we can easily reproduce your problem. Perhaps ZIP everything up and upload it somewhere. Maybe somebody will look at that.
But make sure we can reproduce. Do we need to do this in a specific directory? With a specific ACL? Test your reproduction by trying to follow your own instructions before posting.
Bottom line, stop flailing and be precise.
Thanks i give up
ReplyDeleteThirty odd comments in and everyone's lost enthusiasm. If you'd started with a good MCVE it would have been easy.
ReplyDeleteFile virtualization:
ReplyDeletehttps://support.microsoft.com/en-us/kb/927387
Somewhat related:
Registry virtualisation:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa965884(v=vs.85).aspx
General advise - ensure that you do NOT put writable files in the Windows or Program Files folders or sub-folders, but use the User and/or AppData folders.
Some examples:
http://delphi.about.com/od/kbwinshell/a/SHGetFolderPath.htm
Lars FosdalI am not sure i understand the scenario. Let me explain last time again.
ReplyDeleteThe program is one line of Delphi reading ini.(see above)
MultiLaunch.exe + MultiLaunch.ini it dose NOT read the ini. at a certain file position.
NOW COPYING the above to P.exe+P.ini (same file -changing name ,same file position) works.!!!!!!
I went to the above page and eventvwr.exe nothing help.
I think the problem lies some were else not Delphi.
Thanks in any case
What you describe is consistent with virtualization.
ReplyDeleteP.S one more thing this program usually loads on start up on my computer. Wile developing i close it.
ReplyDeleteI am using in the dpr OgFirst unit and if IsFirstInstance then.... else ActivateFirstInstance; May be it has to do with that?
However for testing i do not use the above as i said only one line of code.
shlomo abuisak I agree with David Heffernan that it most likely is virtualization which is playing you a trick.
ReplyDeleteHave a look under C:\Users\\AppData\Local\VirtualStore\ folder and see if you find something there?
The simplest way of avoiding virtualisation issues, is to keep any form of config or data save files out of Program Files completely - and this has basically been the advice from Microsoft since XP, and they started enforcing it in Windows Vista.
C:\Users\LimElect\AppData\Local\VirtualStore\Program Files (x86)\Borland\Delphi7\OutPut\MultiLaunch
ReplyDeletewhat dose it mean?
it means that any files you try to access in
ReplyDeleteC:\Program Files (x86)\Borland\Delphi7\OutPut\MultiLaunch will be accessed from
C:\Users\LimElect\AppData\Local\VirtualStore\Program Files (x86)\Borland\Delphi7\OutPut\MultiLaunch
instead - i.e. your OutPut catalog has been virtualized.
Move your output somewhere else, and your problem should disappear?
Me: Sounds like virtualization. Do you know what virtualization is? Is your app virtualized? Check this with Process Explorer or Process Hacker. When you start your app to you see the UAC elevation dialog?
ReplyDeleteYou: No i do not know. But in this case is dose not matter.
Well, now it transpires that it really does matter. It's time to step back and attempt to learn about this. It's not new. This was current 10 years ago.
So, instead of flailing and thrashing around, are you prepared to spend some time to learn about this?
Lars FosdalThanks.
ReplyDeleteThanks i will always cherish your knowledge guys
ReplyDelete