I have .Net desktop app which users can download from my website. I want to customize this app to per user basis.
Is there way to modify exe before downloading, just to change few strings with appropriate for the users downloading ?
Or it is possible to pass command line parameters to this exe via URL ?
The .exe file needs to be customized for it to behave differently for certain downloads.
Skip below to find the solution I found tolerable.
Add section to the .EXE file – Not ideal.
The .exe file has sections one after the other. You could add a section with your data in it, which the executable would then read. This requires you to modify (have access to) the source code of the executable for it to do anything meaningful with the data. Also getting familiar with the .exe file format and modifying it on the web server side as well al playing with it in the program's source code is somewhat tedious.
Change resources section of the .EXE file – Not ideal.
A dedicated "resources" section exists in the executable. You could add custom strings or blob of data to it. Same cons as the first one.
Overwrite data in the .EXE at a fixed position – Passable.
Have the executable read data from itself from a fixed position in the file, which is overwritten with the customization data when serving the .exe file. Requires modifying the executable's source code.
Append data to the .EXE – Passable.
Append data to the executable. Again, reading it and doing anything special with it requires the executable itself doing so.
☑ Wrap the .EXE in another .EXE and append your data to it – Tolerable.
Create a program to which the original executable and the custom data will be appended to. When this custom program is then executed, it will extract the embedded executable and launch it with the custom data as it arguments.
This kind of a bundle-executable is also easy to produce on most server-side (scripting) languages. When the download is requested, the server sends the wrapper-exe, the original exe, the customized data and of course some statically-sized data fields denoting the sizes of both of those data blocks so it can extract them.
Cons: Requires such a wrapper program to be created, unless someone already has.
Related links:
1. Best practices to let my web users download custom .exe from my site using PHP
2. Modifying executable upon download (Like Ninite)
If the application is ClickOnce deployed, passing URL parameters is an option in the ClickOnce options dialog. However, I have not yet used this feature.
EDIT
You might want to change some user settings in your configuration depending on the user that actually runs the application. You could also make sure this is done only once per user by adding an appropriate SettingsNeedUpdate setting you set to true after the initial initialization.
Example:
Add new setting "Option1", "Option2" and "SettingsNeedUpdate" which are user settings. In Main you could add something like:
...
try
{
if (Properties.Settings.Default.SettingsNeedUpdate)
{
Properties.Settings.Default.Option1 = ...;
Properties.Settings.Default.Option2 = ...;
Properties.Settings.Default.SettingsNeedUpdate = false;
Properties.Settings.Default.Save();
}
}
catch (Exception exp)
{
...
}
...
You could write a library which can modify an assembly resources (here string table).
This library could benefit from reflection.
When a user asks for your file, asp.net page could customize the exe (using your library) and send it to client.
Not like that, No.
You could however automatically zip (on your server) your exe with a custom app.config file for each user.
Update
Point your download location to a custom HttpHandler that zips together your exe (using http://www.sharpdevelop.net/OpenSource/SharpZipLib/) with a generated (for the current user) application configuration file ( http://generally.wordpress.com/2007/09/27/using-appconfig-for-user-defined-runtime-parameters/).
The user then unzips the two files (MyApp.exe & MyApp.exe.config) to any location and run MyApp.exe.
This method does not work if you have an installer.
Related
lets say that I have a program, that is modifying registry in Windows. User can chose what keys will be changed. After this he will click "generate" to create new exe file which will do its job depending on user choices.
How can I achieve that "exe generating" by clicking generate?
First you need to have two EXEs. One is your main app, and the second is the app that changes the registry. Now you have to append some data to get a copy of your secondary app using your main app and append the data that specifies what keys to change.
One way is to use resources. Use your main app to append required data as resources to your target exe (The compiled to-be-generated exe).
Your target exe file should check and load data resource from its own executable file and retrieve the required data.
You might find these links useful:
How to attach a resource file to an existing executable file?
And how to retrieve the resource in your target exe:
http://delphi.about.com/od/objectpascalide/a/embed_resources_2.htm
Is it possible to persuade the stream result to download an entire directory and it's contents? And if so, how? I've no problem getting it to download individual files, but I have a need to download a series of files that must be in a specific directory structure.
I don't think so.
Stream result allow you to download ONE content, with its MIME type, its name, etc.
This makes it impossible to work with a lot of files, with different names and content type.
What you can do is:
Render in a JSP the list of files (in anchor tags for example), everyone targeting the Action that will download that single file;
Call multiple Actions via scripting opening multiple pages (target="_blank") for every file you have (dangerous, annoying, almost useless...);
Create a zip with Java in server side, containing all your files and directories, then output the zip with Stream result.
I think you may consider the third option.
If we want to store critical information, like passwords and server addresses, inside the executable file generated by the Delphi compiler, how can we do that, without knowing the final executable size and binary structure, like at the end of the file for example?
Side note:
The text to be stored is already encrypted; and in some computers the windows don't give access to write in the registry, specially when the user is not administrator, and there are hacks to monitor registry changes and the smart user can find the new windows registry entry.
Comment
Why this question was down voted? This is achievable! Doesn't meter if not interesting for most people.
I think about the bios and other firmware upgradeable, like satelite tv signal decoders that update themselves. How is that possible?
You can use an .rc file to put your data into a custom resource inside the final .exe file. You can then access that resource at run-time, such as with a TResourceStream, and decrypt and use its content as needed. However, you cannot write new data into the resource while the .exe is running, as the file is locked by the OS. If you need to write new settings, and do not have write access to the Registry, you will have to use a separate file instead. Windows has special folders set aside that users have write access to within their user profiles.
Create a string table resource is one way.
Create a text file. say secretstuff.rc (has to have .rc extension)
with something like this in it.
STRINGTABLE
{
1,"This is my encrypted password in say Base64"
}
Compile it to a .res file with BRCC32.
Include it in the relevant code with a compiler directive
{$R secretstuff.res}
After that you access with TResourceStream.
If you want to manage it a bit better might be wise to stuff them in a dll instead of an exe, then you can update things by delivering a new version of the dll.
There's an example with a it more detail, another purpose but same principle here
I would like to store some XML program preferences as a resource in a Delphi application. The resource would be modified based on user changes. I have no problem creating the XML and loading it as a resource, and can modify the xmlDocument that I load it into, but I don't know how to write the document back. Is this even possible? I would prefer not to end up with 2 files in the end (.exe and .xml).
The answer is both yes and no.
Yes, it is possible to update resources in a binary using Windows API routines. This link to BeginUpdateResource() should get you on the right track on that score.
However, you will note the following condition on the use of BeginUpdateResource():
"The binary file in which to update resources. An application must be
able to obtain write-access to this file; the file referenced by
pFileName cannot be currently executing."
In other words, it is not possible for an application to simply update it's own resources while running.
There are a number of strategies you could employ to achieve what you want - or something close enough to it as to be satisfactory. Which is most appropriate will depend on your precise needs.
Of the multitude of solutions, two might be:
1) Maintain all such resources in a DLL (resource only DLL - containing no actual code as such) which you open only when specifically loading resources (or updating them). Thus at the time you wish to write a resource back to the DLL you should be able to get the required write-lock.
or
2) When you need to update a resource rename the current running EXE to something like "myapp.OLD", copy it so that you have a new file with the current name "myapp.exe". You can then update "myapp.exe" because it is actually "myapp.old" that is executing.
This second approach is quite messy and has a "nasty smell" but is a technique that is (or used to be) quite commonly used by auto-updaters, for example. Obviously will involve a restart of your app at some point if the current running code is to make use of the updated resources in the modified EXE, so it may not be appropriate to your needs.
Something else to consider is that anti-virus software may flag the activity as suspicious.
Thinking about Deltics' answer I thought you could also create a console application that writes your resource back to the main exe. So your main exe saves it's changes to a file and also extracts the console app. When the main application terminates it calls the console app. The console app waits for a short period of time and then binds the resource file to the main executable, deletes the resource file and itself. The console app could do a check to make sure that the resource file was written successfully and, if not, leave the resource file open. The main executable could see the resource file upon start up and use it instead of the embedded file - as a safeguard.
All of this assumes a single user application.
How do i get the location of the file that i used to open my programs with?
Example: if i create a new extention ".xyz" say and i tell windows that i want to open the file type .xyz with myapplication, then it starts my aplication. Great, but how does my application get a handle on the file path of the file that was used to start it?
Also, is there a way to keep just one version of my app running and new files that are opened to just call a method in my application? For example if your using a torrent and you open 5 .torrent files they all just get passed to one application.
Side question: are all file extensions 3 letters long and is there a list of ones that are publicly used? If im creating a file extension I don't want to use one that is already used.
When you created your file association, you specified the command line that Explorer should run to activate your program. The shell puts the name of the document file on the command line, too, so in your program, check the command-line arguments. How you do that depends on your language and development environment. In Delphi, use the ParamCount and ParamStr functions.
When you create the file association, you can specify exactly where on the command line the document file name should go. Use %1 somewhere on the command line, and the shell will replace it with the file name. Since Windows file names frequently contains spaces, you should put quotation marks around the file name, so the command line in the file association would look like this:
ArthurApp.exe "%1"
With that association, double-clicking another document file will start another instance of your program. If you'd prefer to have the document opened in another window of the already-running instance, then you can write code to make your program look for already-running instances when it starts up. If it finds one, then it can communicate with that instance to tell it what file to open. You can effect that communication any number of ways, including mailslots, sockets, named pipes, memory-mapped files, and DDE.
The shell's file-association mechanism already has a way of communicating via DDE, so a second instance of your program wouldn't be started at all. Instead, the shell would start a DDE conversation with the already-running instance and tell it the new file name that way. However, DDE seems to be falling out of favor nowadays, so check out some of the other options first.
For your side question, no, extensions are not always three characters long. Look around, and that should be obvious: C code goes in .c files, Adobe Illustrator graphics go in .ai files, and new Microsoft Word documents go in .docx files.
But beware. If you ask for **.doc*, the results will include .docx files as well. That's because FindFirstFile matches both short and long file names, and long file names with long file extensions have three-character extensions in their short-file-name versions.
Rob covered the answer to your question(s) beautifully.
As to the last part, whether there is a public list of file extensions - not as such, but there is shell.windows.com, the web service Explorer uses to locate handlers for unknown file extensions. You can make up an extension then query shell.windows.com to see whether it's been registered. For example, to check whether the extension .blah has been registered by anyone on shell.windows.com, just open this URL in any browser:
http://shell.windows.com/fileassoc/0409/xml/redir.asp?ext=blah
Of course, replace the trailing blah with your extension.
You can find more details about this in KB929149 and in Raymond Chen's post Where does shell.windows.com get information about file extensions, and how do I get in on that action?.