Tried Searching but Can't find the Answer
-
I'm looking to see what files are delivered with each Windows Operating system and/or what can be replaced if older versions exist on PCs we are delivering to. I'm testing another developer's product including the installation CD. He is delivering several DLLs and Active X components (.OCX files). The program will be installed on Windows 98, XP (none or up to Service Pack 3) and Windows 2000. The OCX's are fine. No problems. The problem is that of some of the files he is delivering, I do not know if they are already a part of the Windows Operating System and whether they should be replaced. My testing has revealed that at least for XP (at least for Service Packs 2 and 3), XP is protecting the files from being replaced even after a temporary file is created and a reboot is performed. Dlls won't be replaced in this situation but OCXs will. We have an older installation program called Setup Factory 6 which may not be up with all of the advances to XP. Here are the culprits: comdlg32.dll (does this have to be replaced if a newer version is avail in the delivery?) msvcrt.dll mfc42.dll Which of these files are already expected to be there and should they be replaced if the delivery package has newer versions? I replaced an older version of comdlg32.dll on Windows 98 and it broke 98 because it has a dependency on a newer version of shell32.dll. I've since changed the option to install that file on Windows 98 to "never overwrite existing file". I also do not know why he is delivering commdlg32.ocx. Any help would be appreciated. TIA.
-
I'm looking to see what files are delivered with each Windows Operating system and/or what can be replaced if older versions exist on PCs we are delivering to. I'm testing another developer's product including the installation CD. He is delivering several DLLs and Active X components (.OCX files). The program will be installed on Windows 98, XP (none or up to Service Pack 3) and Windows 2000. The OCX's are fine. No problems. The problem is that of some of the files he is delivering, I do not know if they are already a part of the Windows Operating System and whether they should be replaced. My testing has revealed that at least for XP (at least for Service Packs 2 and 3), XP is protecting the files from being replaced even after a temporary file is created and a reboot is performed. Dlls won't be replaced in this situation but OCXs will. We have an older installation program called Setup Factory 6 which may not be up with all of the advances to XP. Here are the culprits: comdlg32.dll (does this have to be replaced if a newer version is avail in the delivery?) msvcrt.dll mfc42.dll Which of these files are already expected to be there and should they be replaced if the delivery package has newer versions? I replaced an older version of comdlg32.dll on Windows 98 and it broke 98 because it has a dependency on a newer version of shell32.dll. I've since changed the option to install that file on Windows 98 to "never overwrite existing file". I also do not know why he is delivering commdlg32.ocx. Any help would be appreciated. TIA.
this always turns into a bit of a mess, safest way is to use your own local copy of the dll (without installing on the system folders), although some would disagree because it defeats the purpose of shared dlls (on a system level), but its such a pain sometimes. if you maintain your own local copy (in your own install directory) then its up to you to maintain the version that's appropriate for your software and just do regular updates after that.
-
this always turns into a bit of a mess, safest way is to use your own local copy of the dll (without installing on the system folders), although some would disagree because it defeats the purpose of shared dlls (on a system level), but its such a pain sometimes. if you maintain your own local copy (in your own install directory) then its up to you to maintain the version that's appropriate for your software and just do regular updates after that.
Actually, the whole reason I am doing it this way is because during testing I discovered some of the OCX's were registered in the program's local directory. Of course, if and when you do an uninstall of the program, its best to leave those files in the program's directory and not delete them. The problem is that a user who knows he uninstalled the program may look at the program's directory and see there's nothing there but DLLs and OCX and do a delete *.* and then other programs that were using the registered locations will no longer work. Same as DLL hell. I would prefer that the files are left in the system directory such that at least there is less risk of accidental deletion by the user.
-
Actually, the whole reason I am doing it this way is because during testing I discovered some of the OCX's were registered in the program's local directory. Of course, if and when you do an uninstall of the program, its best to leave those files in the program's directory and not delete them. The problem is that a user who knows he uninstalled the program may look at the program's directory and see there's nothing there but DLLs and OCX and do a delete *.* and then other programs that were using the registered locations will no longer work. Same as DLL hell. I would prefer that the files are left in the system directory such that at least there is less risk of accidental deletion by the user.
why are you registering them? i don't think you're doing this right... if you use them in your local install directory, they should be uninstalled with your program.
-
why are you registering them? i don't think you're doing this right... if you use them in your local install directory, they should be uninstalled with your program.
What? I believe that an Active X control must be registered (DLLRegisterServer and/or RegSvr32) If not, that's new to me. The problem is that other programs may have registered their version and location of an Active X control and then this program (even if it stores it in the program's local directory) changes the location (because it registers it) so that any program using the previous version now is using the just installed control in a different location. If I am not being clear, there are two problems. One with DLLs which I am not registering, and one with OCX's which I registering. I may be able to do as you suggest with the DLLs but not with the OCX's.
modified on Thursday, April 14, 2011 6:57 AM
-
I'm looking to see what files are delivered with each Windows Operating system and/or what can be replaced if older versions exist on PCs we are delivering to. I'm testing another developer's product including the installation CD. He is delivering several DLLs and Active X components (.OCX files). The program will be installed on Windows 98, XP (none or up to Service Pack 3) and Windows 2000. The OCX's are fine. No problems. The problem is that of some of the files he is delivering, I do not know if they are already a part of the Windows Operating System and whether they should be replaced. My testing has revealed that at least for XP (at least for Service Packs 2 and 3), XP is protecting the files from being replaced even after a temporary file is created and a reboot is performed. Dlls won't be replaced in this situation but OCXs will. We have an older installation program called Setup Factory 6 which may not be up with all of the advances to XP. Here are the culprits: comdlg32.dll (does this have to be replaced if a newer version is avail in the delivery?) msvcrt.dll mfc42.dll Which of these files are already expected to be there and should they be replaced if the delivery package has newer versions? I replaced an older version of comdlg32.dll on Windows 98 and it broke 98 because it has a dependency on a newer version of shell32.dll. I've since changed the option to install that file on Windows 98 to "never overwrite existing file". I also do not know why he is delivering commdlg32.ocx. Any help would be appreciated. TIA.
Actually, Microsoft has declared msvcrt.dll to be a system level component and not to be used anymore by applications. So, probably somewhere starting XP (SP2?) you should at least not touch that component. See http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx[^]. For more on known dll's, check out http://blogs.msdn.com/b/larryosterman/archive/2004/07/19/187752.aspx[^] for instance. And for the love of god, don't touch comdlg32.dll. On older systems, if you are delivering a newer version I'm guessing it's ok, but I've had multiple times that poor installers overwrote the proper version of it, making me download a proper version from the internet again. And mfc42.dll, it seems to have a version number in the filename, so I'd say don't touch it if its there. If it's not, install it. Then again, I'm not an expert on any of this. But please be very reluctant to overwrite dll's (and ocx's for that matter). Only if you know you have a good installer that can check and be sure that a version on the system is newer should you consider overwriting. And, you can always display a pop-up to the user asking for confirmation as some installers do. Best Regards, MicroVirus
-
Actually, Microsoft has declared msvcrt.dll to be a system level component and not to be used anymore by applications. So, probably somewhere starting XP (SP2?) you should at least not touch that component. See http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx[^]. For more on known dll's, check out http://blogs.msdn.com/b/larryosterman/archive/2004/07/19/187752.aspx[^] for instance. And for the love of god, don't touch comdlg32.dll. On older systems, if you are delivering a newer version I'm guessing it's ok, but I've had multiple times that poor installers overwrote the proper version of it, making me download a proper version from the internet again. And mfc42.dll, it seems to have a version number in the filename, so I'd say don't touch it if its there. If it's not, install it. Then again, I'm not an expert on any of this. But please be very reluctant to overwrite dll's (and ocx's for that matter). Only if you know you have a good installer that can check and be sure that a version on the system is newer should you consider overwriting. And, you can always display a pop-up to the user asking for confirmation as some installers do. Best Regards, MicroVirus