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.
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.
The short of it is, I have VMs for building different scenarios of software. I do not wish to snapshot the code as it is backup elsewhere so I am storing all my code on the host PC and only building/testing in VMs to save space. Unfortunately I am receiving program database update errors when I try to build from a location mapped to the host hdd.
I know there is nothing wrong with the C++ projects as they build fine if moved inside the VM.
I have tried:
-cleaning/rebuilding
-removing the debug/release folders entirely
-checking out a copy of the source onto the host drive from within the VM
*Even when the idb and pdb files that the compiler complains about are created by VS, the problem persists.
How can I stop these C2471 errors when building from a non-local drive?
Perhaps, problem in the files that was created by compiler at previus build. Try to remove Debug (or Release) folder and build project again.
I'm not entirely sure as to why, but the issue seems to be related to using shared folders in VirtualBox. If the folders are referenced via a direct UNC path to the host machine it appears to work fine, but accessing through a shared folder (mapped or unmapped to a drive letter) doesn't appear to have the correct permissions.
I cannot use Webstorm on my Citrix account because the screen isn't rendered properly. It is not easy to describe, it looks like a screen refresh would help. When I scroll through the source, the lines appear one by one, but some regions of the gui (icon, menues,...) are never shown.
Not likely the answer you would expect, but I can only suggest installing WebStorm on a local machine and working with source files located on local drives. All IDE functionality is based on the index of the project files which WebStorm builds when the project is loaded and updates on the fly as you edit your code. To provide efficient coding assistance, WebStorm needs to re-index code fast, which requires fast access to project files. The latter can be ensured only for local files, that is, files that are stored on you hard disk and are accessible through the file system.
Moreover, the fsnotifier tool IDE uses to synchronize its virtual file system with external changes doesn't support remote drives, so you might have problems synchronizing files generated by LESS/SASS compilers and other external tools...
See also https://community.oracle.com/thread/1353486
I have a quick question on a topic that I'm quite a noob about. I have a program I made that sends a command to another .exe in a folder I called "tools". I send it in this format:
system("tools\\program.exe -r -w file.dat file_new.dat");
Everything works great, however, when I build my program into a .exe it will require the other executable to be in a second folder, obviously. Is there any way to include the external .exe into my project so the final product is just one .exe?
I am using Visual Studio 2008 (lol) and run windows 7 64bit.
Thanks :)
Typically, the management of external dependencies would be handled by the installer. NSIS is my favoured solution for the Windows platform.
The alternative: Convert the binary to a base64 encoding and embed it as a header file in your project. When the application is run, convert the base64 representation of the exe to a binary sequence and then output that sequence of bytes to a file in a temporary directory (like C:\windows\temp or %AppData%\Local\Temp). Then run the exe. Once you're done with it, remove the exe.
You can add the file to resources. And before the command is executed, you can check, if the second executable exists. If it doesn't exist, you have to extract the data from resource and store to the file...
This thread was dealing with reading html from resource. It is very similar with binary file.
I have created a windows application and a folder with the release executable and appropriate Dlls.
First problem is that I want to package it all into one setup.exe For this task I plan on using windows default iexpress application....(is there better software available for this...must be free though, since this is only for a university assignment)
Second problem is I want to structure the installation so that the actual program along with included libraries are saved in their disk drive, i.e program files(x86) for w7. And at the same time make a desktop shortcut so its easier to run and access for the user.
The issues arising with my second problem is:
Am I wrong to assume that a user will have a 'program file' folder ??
I am thinking of making a vbscript to handle the creating shortcut, but does a vb.exe also need library files to be included ??
Assignment due in 2 days so I would really be grateful if I could get this off my chest
Thx :)
You may be interested in following SW:
Advanced installer
NSIS
WIX
I would recommend first option, it's free for your purpose, you don't need to buy professional license and you can make MSI package in 5 minutes.
No, Program Files folder is common to the valid Windows installation. But you shall not assume that it's always C:\Program Files. You must use corresponding environment string to get program files folder:
%ProgramFiles% - to store 32 bit programs on 32 bit OS and 64 bit programs on 64 bit OS.
%ProgramFiles(x86)% - to store 32 bit programs on 64 bit OS.
VBScript has nothing to do with Visual Basic (VB.exe) itself. It's running by Windows Script Host and does not require any additional libraries. Windows Scripting Host is included by default into any modern Windows OS.
You just create script source file with extension .vbs and run it as any usual executable. Example of creating shortcut could be found here.
You have an environment variable ProgramFiles with in it the path to this folder.
Doesn't include the software you used to build the exe and dll files an installer/packager ?
Otherwise I would search a free packaging program, it should be the easiest way, making the shortcut could also be done by this package. On the other hand if you want to use vbscript you could do it all from there too but your script would have to be executed by the user with administrative rights, not for the everyday user...
free packaging: Some googling gave me http://www.windowsnetworking.com/articles_tutorials/msi-packaging-tools.html, check it out