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

Comments

  1. try maybe setting to have the ini file in \Users\[username]\Documents ?

    ReplyDelete
  2. You 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.

    ReplyDelete
  3. You 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.
    IsAdmin will return true, if you are in the administrator group. Without UAC you still don't have admin rights.

    ReplyDelete
  4. 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
  5. "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."
    I did add the manifest and checked it with procedure isAdmin

    ReplyDelete
  6. +David Heffernan can you point to somthing to do beside manifest?

    ReplyDelete
  7. With 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.

    ReplyDelete
  8. We 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.

    I 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.

    ReplyDelete
  9. 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.

    "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 ..."

    ReplyDelete
  10. Sorry. It seem it has nothing to do with window 7.
    as 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.

    ReplyDelete
  11. 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.

    ReplyDelete
  12. That'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.

    Anyway, it seems that you think you know better than us. We can't help you in that case.

    ReplyDelete
  13. 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.
    did i said crazy. Delphi. I keep investigating.

    ReplyDelete
  14. Just a short question in between -
    What 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.

    ReplyDelete
  15. Christian Ziegelt
    As 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.

    ReplyDelete
  16. 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.

    ReplyDelete
  17. shlomo 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.

    To 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?

    ReplyDelete
  18. 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.

    Clearly you are somewhat muddled. Instead of flailing around, the canny choice is to step back, take a deep breath, and gather some real facts.

    ReplyDelete
  19. 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.
    I 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.

    ReplyDelete
  20. 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?

    ReplyDelete
  21. No i do not know. But in this case is dose not matter. The name i am using is MultiLaunch.
    If 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

    ReplyDelete
  22. 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.

    ReplyDelete
  23. shlomo 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.

    ReplyDelete
  24. David 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.
    RegIni :=TIniFile.Create(ExtractFilePath(Application.ExeName) + ChangeFileExt(ExtractFileName(Application.ExeName), '.ini'));
    //

    try

    MessageDlg(RegIni.ReadString('Labels', 'KeyLabel_1', ''), mtWarning, [mbOK], 0);
    that's it.

    ReplyDelete
  25. You are still flailing. Make the smallest possible program that reproduces the problem, and ask a question on Stack Overflow.

    ReplyDelete
  26. David 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.

    ReplyDelete
  27. shlomo 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.

    ReplyDelete
  28. I 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.

    ReplyDelete
  29. The 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.

    ReplyDelete
  30. SO 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.

    ReplyDelete
  31. Not every body is the same. And perfect.

    ReplyDelete
  32. Simpler then that ?

    unit 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.

    ReplyDelete
  33. 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.

    ReplyDelete
  34. object MultiLaunchMainForm: TMultiLaunchMainForm
    Left = 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

    ReplyDelete
  35. 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.

    Make 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.

    ReplyDelete
  36. Thirty odd comments in and everyone's lost enthusiasm. If you'd started with a good MCVE it would have been easy.

    ReplyDelete
  37. File virtualization:
    https://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

    ReplyDelete
  38. Lars FosdalI am not sure i understand the scenario. Let me explain last time again.
    The 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

    ReplyDelete
  39. What you describe is consistent with virtualization.

    ReplyDelete
  40. P.S one more thing this program usually loads on start up on my computer. Wile developing i close it.
    I 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.

    ReplyDelete
  41. shlomo abuisak I agree with David Heffernan that it most likely is virtualization which is playing you a trick.

    Have 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.

    ReplyDelete
  42. C:\Users\LimElect\AppData\Local\VirtualStore\Program Files (x86)\Borland\Delphi7\OutPut\MultiLaunch

    what dose it mean?

    ReplyDelete
  43. it means that any files you try to access in  
    C:\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?

    ReplyDelete
  44. 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?

    You: 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?

    ReplyDelete
  45. Thanks i will always cherish your knowledge guys

    ReplyDelete

Post a Comment