Archive: Regisering DLLs that are in use?
Regisering DLLs that are in use?
When I try to distribute an application that I've written on a Win9X or ME system, it stops on a DLL called MSVCRT.DLL and asks you to Retry/Ignore/Abort. This file will always be in use on these systems (as far as I know). Other installers allow a file to be overwritten/registered on a reboot. Does NSIS support this in any way and if not, does anyone have a work-around for this type of error?
Any help will be greatly appriciated.
Paul
Re: Regisering DLLs that are in use?
Originally posted by paulh430use this:
When I try to distribute an application that I've written on a Win9X or ME system, it stops on a DLL called MSVCRT.DLL and asks you to Retry/Ignore/Abort. This file will always be in use on these systems (as far as I know). Other installers allow a file to be overwritten/registered on a reboot. Does NSIS support this in any way and if not, does anyone have a work-around for this type of error?
Any help will be greatly appriciated.
Paul
Rename [/REBOOTOK] source_file dest_file
Rename source_file to dest_file. Functions just like the win32 API MoveFile, which means you can move a file from anywhere on the system to anywhere else, and you can move a directory to somewhere else on the same drive. If /REBOOTOK is specified, and the file cannot be overwritten, then the file is moved when the system reboots. The error flag is set if the file cannot be renamed (and /REBOOTOK is not used) or if the source file does not exist.
Strange things are appening in here - fortunately I don't have to scroll across with my lovely 32" 69'000x47'000@147Hz monitor.
(If anyone fixes it, this post'll look very strange)
Re: Re: Regisering DLLs that are in use?
Originally posted by prodangleForgive me for being an idiot :), but if I use the Rename method, the file has to already be installed, my file NEEDS to be installed. Should I install all the files to a tmp and rename the files in question?
use this:
Rename [/REBOOTOK] source_file dest_file
Rename source_file to dest_file. Functions just like the win32 API MoveFile, which means you can move a file from anywhere on the system to anywhere else, and you can move a directory to somewhere else on the same drive. If /REBOOTOK is specified, and the file cannot be overwritten, then the file is moved when the system reboots. The error flag is set if the file cannot be renamed (and /REBOOTOK is not used) or if the source file does not exist.
You can then check the error flag and give the user a message if necessary
Generally if you ask me, updating the system version of MSVCRT.DLL is a bad idea. Why not just ship a copy in your application directory instead. That way you can't break other apps...
-J
Originally posted by justinOk, I did some reading on Microsoft.com and can't find what types of files support just putting the dlls in the app directory. Now, on a test win98 box, I put all the files in the app directory, but I still had to register a few dlls for my software to work right. If I register these dll's, won't that tell the system to use the dll in my app directory rather than another copy that is installed (meaning, breaking other apps)?
Generally if you ask me, updating the system version of MSVCRT.DLL is a bad idea. Why not just ship a copy in your application directory instead. That way you can't break other apps...
-J
if you have to register the DLL, then in most cases this will cause your copy to be loaded for every application which uses that DLL. I may be wrong, but I don't think you have to register MSVCRT.dll
If you put it in your app directory, then all should be fine.
About the easiest method I've found to determine if a DLL needs registering is just to try it. Run regsvr32 from a command line with the path/name of the DLL as the parameter. If it says it can't find the entry point, then you don't need to register it.
Originally posted by paulh430remember that VB applications aren't programs in their own right, they contain a strap that loads the vb runtimes which in turn execute the byte code in the '.exe' file, thus the applications actual directory where code is executed is the system directory where the vb runtime dll file is ... I think (not sure though, I haven't used vb before.. this is just what I can tell from seeing vb programs).
Ok, I did some reading on Microsoft.com and can't find what types of files support just putting the dlls in the app directory. Now, on a test win98 box, I put all the files in the app directory, but I still had to register a few dlls for my software to work right. If I register these dll's, won't that tell the system to use the dll in my app directory rather than another copy that is installed (meaning, breaking other apps)?
Do you have any links/text/help on what files a vb app will look for in its directory?
Ive been working with Visual Basic for about 5 years, but distribution wasnt my job, so this is my real first crack at DLL Hell.
Thanks
Paul
Re: Re: Re: Regisering DLLs that are in use?
Originally posted by paulh430Yeah, I probably should've said that too.
Forgive me for being an idiot :), but if I use the Rename method,
the file has to already be installed, my file NEEDS to be
installed. Should I install all the files to a tmp and rename the
files in question?
One silly thing to keep in mind, sometimes the $TEMP directory will be cleaned at shutdown, startup, or just by a user who wants to clean up. If you are going to extract files to rename on reboot, it would be better to put the files into $INSTDIR\temp or the destination directory but with a different extention. That way they stick around long enough to be renamed.
Originally posted by prodangle:eek: :eek: You lucky boy.
Strange things are appening in here - fortunately I don't have to scroll across with my lovely 32" 69'000x47'000@147Hz monitor.
(If anyone fixes it, this post'll look very strange)