I have a Windows exe file, which I want to make hardware-locked. I want it to run only on computers, which have a valid license key. For this I use Winlicense.
I created a project in Winlicense and all is OK, but when I click "Protect" the protection finishes successfully, but the exe is running without any problems on any Windows computer. I expect to see a message that this program requires a valid key in order to run.
I can send the XML of my Winlicense project together with the exe file (the exe file is absolutely empty).
What is the right way to protect the exe, so that it asks for a valid key when it is run?
Related
for a self-built installer I need a way to execute code after closing of an application itself.
Application structure
Main application: The installer is started from it when needed, it closes itself in the process.
Installer: This is also located in the folder of the main application and therefore also accesses all dll files. When an update is available, a zip file is first downloaded and then unpacked into the temp folder. Afterwards, all files are moved from there to the shared application directory.
The problem
The problem is that the updater can only update a few dll files at runtime that are not used by itself, because some are write-protected due to the installer's access.
A solution
Moving the files from the temp folder to the shared application folder must happen after closing the installer. But I don't know how to realize that.
Thanks a lot!
If your problem are the DLLs shared by the installer and main application, then you can do this: Before you run the installer, your main application can copy all the needed DLLs and the installer EXE from your main application folder to a temporary folder and run it from there. Your installer must then only wait until the main application gets closed and then replace all its files in the main folder. And once your update is finished, delete this temporary copy of the installer with its DLLs.
Note that if you want to overwrite files in Program Files folder, your installer will have to be run with elevated privileges. Google for "runas" command... you will need it when starting your installer with QProcess.
But there may be also other problems. If your first installation was with normal installer, it typically creates some entries in registry and also generates list of files for later uninstall. And if your new versions will contain different files than originally installed version, then your subsequent uninstall may malfunction or may leave some files existing on users' computers. And you certainly do not want this.
And yet another potential problem. You may have running several instances of your application. In that case quitting one instance will still leave the other instances running and hence their files will not be replacable by the installer - it will fail.
So as you can see, these are quire serious aspects to take into account.
How I do it in my software and I suggest you try it too? I prepare one installer file (.exe) with InnoSetup (freeware!). This can be used for first installation as well as for automatic updates. Then if I create a new version and put it on the server, the running main application detects it, downloads the new installer and runs this installer (of course it asks the user if it should proceed). The installer then asks for elevated privileges, asks to close the running application (it usually is closed automatically when starting the installer) and overwrites the existing installation. All this is standard functionality built in the installer created by InnoSetup. And correctly updates the uninstall instructions... It took me several days to set up everything to my needs but it works well. The only "drawback" is that it is not completely silent, it shows some dialogs. But this is no real issue for me. Maybe it is better for the users to see what is happening on their computer...
Your question implies Windows. I'll make a suggestion from a Win32 perspective.
In our application, we have a similar issue. Periodically, our application downloads an update executable into a temp folder and then launches it. When the update EXE runs, it makes sure the main application has exited, unpacks the files into the application's installation folder, and then starts the application back up again. It's actually more complicated than that, as it really copies the new files into a different install folder, but I'll save those details unless you really need it.
The problem is that the updater can only update a few dll files at runtime that are not used by itself, because some are write-protected due to the installer's access.
This is the core of your issue. My advice is to have the Installer EXE statically linked to both the VC runtime and the other code its sharing with the application. That is, no DLL dependencies all. If you really need to share code between the installer and the application, but still want the application to use a DLL, you can do this. Have the shared code built as both a DLL (with a stub lib) and also built as a full LIB. May require some minor refactoring to your build or redundantly build the same source files. The Installer code links with the full LIB. The application code links with the stub LIB for the DLL like it does now.
If you are just looking for a way to launch the process, the API you want is CreateProcess.
Also, have you looked at the open source options like Omaha - which is what Google Chrome has used for silent updates?
Moving the files from the temp folder to the shared application folder must happen after closing the installer. But I don't know how to realize that.
The "Windows way" would be to use PendingFileRenameOperations as described in this blog-post and have Windows do the move during the next startup. Of course that implies one more of the annoying "Please reboot to finish the installation" messages.
This is very specific, and I have very little to go on, but I am at my wits end.
Here's the scenario:
My c++ application runs an executable using CreateProcess. The Process Attributes, Thread Attributes and Environment are all inherited from the application.
The executable loads a DLL.
When I run my application normally, all is fine.
When I launch my application from Outlook ("Open" my applications data file, as an email attachment, from Outlook, which launches my application) the CreateProcess succeeds, but the executable that is run returns immediately with a return code of 1, and there is nothing in std out or std err.
Investigation shows that the Path environment variable in my application is the same when it is run normally, and when it is run from Outlook except that Outlook adds its directory to the path. All other paths are the same.
The executable I am running is g++ cross compiler.
I know this is a tiny amount to go on, but I'm hoping someone has had a similar experience.
I have a Win32 program that will delete a directory if it has deleted all files in it. The directory delete succeeds and the directory is deleted but until the program exits, the directory will still be displayed in a Windows Explorer window. Attempting to open the folder in Explorer will produce a pop up error message to the effect: "Location is not available" " is not accessible. Access is denied."[OK].
Calling _unlink() for files in a folder update in an Explorer window almost immediately. Is there some way to "flush" the file system other than exiting the program. The program is typically left running for days, so having phantom folders that give errors until the program exits is not acceptable. Is there a way to do this with _unlink() or am I going to have to switch to Windows API version of the call?
Do you hold any descriptors to that directory? Use Process Explorer to check for file handles containing its name.
Since Windows Explorer is showing the directory while the application is running, but stops showing it after it exits, the problem is likely that your application is holding a handle or file descriptor to that directory, which somehow keeps the directory from being completely deleted, or it tricks Windows Explorer into thinking it still is in the file system.
I need to copy a virtual file from my Windows Explorer namespace extension to a restricted location (for example to C:). Normally for such task one need to run a new process elevated that should do the operation.
However in this case I'm running in explorer.exe process context, and I need to get the same "You'll need to provide administrator permission to copy..." dialog that Windows Explorer presents, rather than a UAC dialog for a new process.
Anyone knows what function Windows Explorer uses to achieve this? ShFileOperation does what I need, but seems to work only for file system objects. How Windows Explorer copies files from zip archives which are represented via namespsace extensions too? Thank you
I have some EXEs for which I do not have code. Can I still add manifest files?
Also, according to my understanding of the topic, for a program to be Vista compliant, it should not write to any secured locations like HKLM, Program Files etc.
For registry we can use HKCU, but about the files that are getting created in Program Files? should they be created in an unsecured location during the execution of EXE?
Thanks
You can add a manifest using an external file. Just place the manifest in the folder with the exe and name it "file.exe.manifset" where file.exe is the executable file name. However on Server 2003, Vista and later if the program has an embedded manifest, the external manifest will be ignored by default. There is a registry key that will override this behavior or you can use the mt.exe from the Windows SDK tool replace the manifest in the exe. See this link for more details.
For existing applications that try to write to Program Files or HKLM, they should work on Vista because Vista redirects the writes to another location and makes it appear to the application that the write succeeded.
You should be able to create a manifest file without source code.
It it OK to require administrative privileges for installation or updates, so you can put the EXEs and DLLs (and supporting files) in Program Files.
It is not OK to require administrative privileges for regular usage, so you should put data files and settings in the registry in HKCU or in the user's Application Data folder.