Really strugling to get an .ini file in to a DLL and still be able to edit it.
Any one plz help send anything you can to help me to

Dani AI

Generated

— embedding an INI inside a DLL and expecting it to be editable at runtime is the core issue here. Resources become part of the PE image and are not meant to be opened for normal write-edit cycles while the DLL is in use. is right that it is not a straightforward pattern, and ’s pointers about DLLs and INI basics are useful background.

Practical, safe pattern

  • Keep a default INI as a resource inside the DLL only as a fallback.
  • On first run copy that default out to a writable location (per-user: Roaming\AppData; per-machine: ProgramData). You already have extraction working; after that always read/write the external file with TIniFile/TMemIniFile.
  • This avoids permission problems (Program Files is protected), avoids modifying a loaded binary, and keeps settings editable.

Example (Delphi) — use the external file for edits

var
  Ini: TMemIniFile;
  ConfigPath: string;
begin
  ConfigPath := 'C:\path\to\writable\config.ini'; // use AppData/ProgramData in real code
  Ini := TMemIniFile.Create(ConfigPath);
  try
    Ini.WriteString('General','Username','me');
    Ini.UpdateFile;
  finally
    Ini.Free;
  end;
end;

If you must update the DLL resource

  • This is advanced: use the WinAPI BeginUpdateResource / UpdateResource / EndUpdateResource on the DLL file on disk.
  • The DLL must not be loaded by any process while you update it. Typical solution: run a separate updater EXE (launched after the main app unloads the DLL or at install time).

Sample outline (C)

HANDLE h = BeginUpdateResourceA("c:\\path\\to\\your.dll", FALSE);
UpdateResourceA(h, RT_RCDATA, "MY_INI", MAKELANGID(LANG_NEUTRAL,SUBLANG_NEUTRAL), data, size);
EndUpdateResourceA(h, FALSE);

Troubleshooting/cautions

  • Check file locks (Process Explorer) and permissions.
  • Modifying signed binaries breaks signatures and may trigger AV.
  • For most apps the resource-as-default + external INI approach is the simplest, most robust solution.

Recommended Answers

All 3 Replies

Ok thanks for the advice. I has already check out delphi.about.com and found some usefull tips an tricks, but
there is nothing on using and re-using a resource within a DLL.

There are examples an using BMP's and WAV's, even extracting the file to the work Dir. This was the closest i found. but after extracting it and using it you cant get it back in.

[B]procedure[/B] TForm1.Button2Click(Sender: TObject);
[B]var[/B] 
rStream: TResourceStream; 
fStream: TFileStream; 
fname: [B]string[/B];
[B]begin[/B]
[B]{[/B][B]this is good but only goes 1way}[/B]
fname:=ExtractFileDir(Paramstr(0))+'Intro.mp3'; 
rStream := TResourceStream.Create(hInstance, 'Intro', RT_RCDATA);
[B]try[/B]  fStream := TFileStream.Create(fname, fmCreate);
     [B]try[/B]   fStream.CopyFrom(rStream, 0);
     [B]finally[/B]   fStream.Free;  
     [B]end[/B]; 
  [B]finally[/B]  rStream.Free; 
  [B]end[/B];

this is great to get it out and use it once off.

I need to reuse it and keep it in???:sad:

The other thing i found was a stringtable. once again you can read from it but not write to it.

Perhaps i got the wrong idea of a what Im tring to do. maybe some one has a better idea of how to keep information in a secure way. (reading and Writing)

Do you have ANY grasp at all about what a DLL is?

If you did you'd know that what you want simply isn't going to work.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.