I've seen lots of threads scattered about the internet about this particular error message. All that I have seen have answers that seem to presuppose that the user has heard of something called Qt and wants to do something with Qt. I got this message while running TeXworks. TeXworks worked perfectly for me for years until someone being paid to do some maintenance on my computer decided to delete all my files and then recite boilerplate notices to me in a robot voice.
I have never heard of anything called Qt in any other connection and I have no interest in anything called Qt. I am trying to get TeXworks to function the way it always did. Is it possible to give an answer to the question of what to do about this that does not presuppose that I came to this with some interest in, and knowledge of, something called Qt?
First, detect what .dll files are missing. Download and run Dependency Walker. Open (or drag on the main window) application's .exe file. In the first level of the dependency tree there will be shown .dll files of the application
A .dll with the yellow question mark icon is missing. You should either copy all missing .dll files into the application folder or add the folder with .dll files into the PATH environment variable.
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.
I am building a C++ OpenGL card game in Xcode 4.3.3, with the intention of running it on both 64-bit and 32-bit Macs, which is not my problem. My problem is that I have reached a point in the development of the program where I would like to test that it works on a different 32-bit Mac (mine is 64-bit) without having to install Xcode. This, obviously, requires me exporting it as an .app. I can find and run the exported Unix Executable File from my project, after some cd'ing, through Terminal, but that is undesirable for me and the intended audience of the program. I have trawled the google and Stack Overflow, looking for anything to help me, but all the things mentioning Archiving seem to have been unsuccessful with my particular project, and I think that's because it's a C++ command line tool project. So, can someone please help me export my project as a .app?
Thanks in advance.
The simplest way of doing this would be to create a Cocoa project, go to 'build phases' and remove all the objective-c frameworks from the 'link with libraries' build phase, remove any objective-c files added by the template (app delegate, etc.) and then replace main.c with your main.cpp file.
There's nothing really special about a Cocoa project except for the fact that it links against Cocoa and calls NSApplicationMain() from its main() function.
There are also a bunch of .plist entries used by Cocoa which you'll no longer need. But they won't affect the way OS X treats your application.
I'm searching for an XCode Settings solution but here's my current way to create an app:
You have to take your binary file (let say myapp) and put it in "MyApp.app/Contents/MacOS/myapp" then it can now be launched as a .app. That's a trick.
Just go to the targets folder in the file navigator on the left, and there will be an executable listed there. Left click on that executable and click "show in finder". (I'm describing from memory so I may have the exact details wrong.) The file path is ridiculously long (there is an arbitrary alphanumerical pathname involved, I have no idea why), so you probably won't be able to find it with the command line.
If you want you can change the extension of the file from nothing to ".app", it shouldn't affect the nature of the file at all. Also if you want a custom icon, you can "get info" on it in the finder, then click on the icon in the info window, and use Cmd-V to paste it in (obviously you have to have your icon copied to the clipboard). There is also a way to do this inside of Xcode, but I don't remember it.
I'm having a difficult problem to solve. I'm having two Qt-based applications, first one is in the main folder and the second one is located in it's subdirectory (yes, I'm forced to have it this way). The issue I'm facing is that I have to deliver 5 exact the same DLL's files for each application. I wouldn't have problem with that, if they wouldn't weight so much (10 DLL files = 60~ MB). Which is, definately too much.
On my debug build I am able to set the PATH variable within Visual Studio settings, and I will be not able to do so on production machines.
Is there any way I could set one of those application to rely on DLL files located in subdirectory?
I don't know what kind of an installer you're using, but the dlls should be stored only once in the archive, and the files should be hard linked on installation. So it's a non-issue unless your installer is broken or the install script is.
I have made my project in C++ and used SFMl 2.1, I also have loaded images from disk and when I'm trying to run its .exe file its giving error in image loading.
For now I'm trying to run its own .exe fie (in Debug or Release folder of project).
i want to make this .exe file for my friends who are not programmers so that my game would run on their PCs as well.
If someone know to make .exe so please help!
First, try to put the images beside the exe file.
After that, your friends probably won't have all the development DLL and libs needed for your app to work. You can use depends.exe to know what is needed for your app to start. Put all those file beside your exe and it should work on most PCs.
Bonus tip
Often, when you experience this kind of problem (application crash when starting directly outside the project), the simplest solution, which is language-agnostic, is to make your app write to a new file within your main function and look where it ends up in your project hierarchy after you ran your app directly (outside the IDE/project).
You'll see right there where the relative root of your app is. Most of the time, it's right next to the compiled file, depending on the language you chose.
I have develped my GUI Application in Qt though Qt Creator IDE & MinGW compiler.
I plan to Open source it under the terms of GNU-LGPL.
Now since I had developed all the source code with my GUI Application in my mind, I am having difficulty in modifying the project so as to build a .dll which others can use in their applications. Here are some of my doubts:
Should I maintain a different sets of source files for .exe project & another for .dll project, considering that I will be maintaining my project on GitHub.
Should I delete all the GUI related code from the .dll project? Or it would be fine to just put bool flag's everywhere GUI is created/modified?
Should I delete those functions which were only used in .exe project & will never be called in .dll project? Or should I let them be as it is?
This is my first time at Application development as well as Open Source development. Since I have developed it myself, I dont have proper guidance.
Thank You.
I would separate the program into two projects. Place the GUI stuff in one project which uses a dll created by your other project. That way you only need to maintain one instance of the dll's code. Having duplicate code in any way is usually a bad idea.
(Credit where credit is due: I got this idea from the third comment in this question. It's about C#, but the solution applies to any kind of project.)