C / C++ / MFC

13-Apr-11 8:20

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.

Albert Holguin13-Apr-11 8:27

Albert Holguin

13-Apr-11 8:27

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.

JohnnyG13-Apr-11 8:39

13-Apr-11 8:39

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.

Re: Tried Searching but Can't find the Answer [modified]

Albert Holguin13-Apr-11 9:56

Albert Holguin

13-Apr-11 9:56

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.

JohnnyG13-Apr-11 10:08

13-Apr-11 10:08

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

MicroVirus14-Apr-11 2:10

MicroVirus

14-Apr-11 2:10

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

JohnnyG14-Apr-11 3:22

Glui in visual studio 2008 ( c++ )

14-Apr-11 3:22

Thanks, MicroVirus. Took all your suggestions to heart. Besides msvcrt.dll, I also decided not to deliver comdlg32.dll.

Member 783376313-Apr-11 5:42

Member 7833763

13-Apr-11 5:42

I want to do an user interface in c++, I will use glui library.
I added the library as the net says.
But I could not the compile any code.
I always take the same errors:

Error 16 error LNK2019: unresolved external symbol "void __cdecl myGlutIdle(void)" (?myGlutIdle@@YAXXZ) referenced in function _main
Error 33 error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall std::locale::facet::_Register(void)" (__imp_?_Register@facet@locale@std@@QAEXXZ) glui32.lib

and so on....

How can I fixed it? I searched everywhere Frown | :(

Re: Glui in visual studio 2008 ( c++ )

nitchman238313-Apr-11 7:39

nitchman2383

13-Apr-11 7:39

If you are getting to the link stage of compilation then its probably that you are not linking in the required library but you have sufficient include files so there are no compile errors.

It's been a while since I have work with Glut but I think there is a Glut.lib that you should add to the linker section of the project settings.

Crash after installing KB2465361

jung-kreidler13-Apr-11 1:46

jung-kreidler

13-Apr-11 1:46

Help! After windows update with KB2465361 I get crashes everywhere. My application is based on Ultimate Toolbox. MS created an own CMFCToolbar. In Ultimate Toolbox this has been renamed to COXToolbar, but it crashes somewhere in there. I've replaced the toolbar with the MS CMFCToolbar, but now my app crashes while opening a file inside filecore.cpp. Anyone else out there suffering similar problems and a way out of this?

Regards,
Franz

Re: Crash after installing KB2465361

Hans Dietrich13-Apr-11 1:58

Hans Dietrich

13-Apr-11 1:58

If you don't want to debug into COXToolbar, probably the best thing is to create a new app, then move your old code into the new app structure, just to make sure everything is hooked up correctly.

Best wishes,
Hans

[Hans Dietrich Software]

Re: Crash after installing KB2465361

jung-kreidler13-Apr-11 4:13

jung-kreidler

13-Apr-11 4:13

Debugging should not be the problem Smile | :)

, but probably I do not understand what's going on Laugh | :laugh:

.
The problem is here:
afxbasepane.cpp line 133 does a call to SetPaneStyle(dwStyle | GetPaneStyle());
This runs into virtual COleDropSource* GetDropSource(), which I do not understand. It seems that there is some linking problem, since GetPaneStyle does not exist inside OXCoolToolBar. This is strange.

Re: Crash after installing KB2465361

jung-kreidler13-Apr-11 4:41

jung-kreidler

13-Apr-11 4:41

...found out. During the update of the ultimate toolbox to Version 9.3 (Update 05) I missed one line in OXCoolToolBar.h in 1722. Instead of #define CToolBar COXMFCToolBar there was a #define CToolBar CMFCToolBar, which lead to the confusion. As I was close to getting nuts and calling for the priest I recognized this new line in the new code base of 9.3.

Rotate View

giannib2k12-Apr-11 22:04

giannib2k

12-Apr-11 22:04

Hello, I need to rotate 90° my "graphical objects" on screen (text, lines, rect....)
Is it possible to do it just by changing any VIEW properties or anything similar ?

thanks

image processing toolkits | batch image processing

C^hris L^osinger13-Apr-11 2:52

C^hris L^osinger

13-Apr-11 2:52

if you don't need your app to work on Win9x boxes, you can use SetWorldTransform[^]

giannib2k13-Apr-11 3:16

giannib2k

13-Apr-11 3:16

Thanks for your suggestion, I'll try.
Don't you know if there is any MFC similar function ?

image processing toolkits | batch image processing

C^hris L^osinger13-Apr-11 3:25

C^hris L^osinger

13-Apr-11 3:25

CDC::SetWorldTransform[^]

giannib2k13-Apr-11 3:31

giannib2k

13-Apr-11 3:31

Many thanks again
It was simple !!!
But I just have VisualStudio 2003. Frown | :(

I think I need an upgrade !

thanks Chris