How do I deploy riched20.dll?
-
Hey all. My application (ActiveX Control) requires Rich Edit Control v3. (v2 doesn't right-align correctly from some reason). I couldn't find a redistributable package on MS site. Can I just pick up the riched20.dll on my computer, along with 2 or 3 DLLs it depends on, and deploy them on the clients' machines (if they don't have a newer DLL)? Or is it somehow dangerous / illegal / etc.? Thank you!
I can find no reference to redist of riched32.dll. So, no you can't do it. http://www.microsoft.com/msdownload/platformsdk/sdkupdate/default.htm?p=/msdownload/platformsdk/sdkupdate/psdkredist.htm Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
Hey all. My application (ActiveX Control) requires Rich Edit Control v3. (v2 doesn't right-align correctly from some reason). I couldn't find a redistributable package on MS site. Can I just pick up the riched20.dll on my computer, along with 2 or 3 DLLs it depends on, and deploy them on the clients' machines (if they don't have a newer DLL)? Or is it somehow dangerous / illegal / etc.? Thank you!
Check in the Common\Redist\Redist.txt file of your VC6 install. (I can't as I'm running VS.NET). If it's listed in that file, you can redistribute it. Cheers, Tom Archer Author, Inside C# Please note that the opinions expressed in this correspondence do not necessarily reflect the views of the author.
-
Hey all. My application (ActiveX Control) requires Rich Edit Control v3. (v2 doesn't right-align correctly from some reason). I couldn't find a redistributable package on MS site. Can I just pick up the riched20.dll on my computer, along with 2 or 3 DLLs it depends on, and deploy them on the clients' machines (if they don't have a newer DLL)? Or is it somehow dangerous / illegal / etc.? Thank you!
What about compiling statically? -Jack To an optimist the glass is half full. To a pessimist the glass is half empty. To a programmer the glass is twice as big as it needs to be.
-
What about compiling statically? -Jack To an optimist the glass is half full. To a pessimist the glass is half empty. To a programmer the glass is twice as big as it needs to be.
It's not a source code issue. The winproc for the richedit window class is in the riched20.dll file. Therefore that file needs to be present and the window class registered for you to be able to use the rich edit control. Cheers, Tom Archer Author, Inside C# A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.
-
It's not a source code issue. The winproc for the richedit window class is in the riched20.dll file. Therefore that file needs to be present and the window class registered for you to be able to use the rich edit control. Cheers, Tom Archer Author, Inside C# A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.
So compiling statically in windows doesn't compile shared libs into your binary as it does in unix? Or am I missing something? -Jack To an optimist the glass is half full. To a pessimist the glass is half empty. To a programmer the glass is twice as big as it needs to be.
-
So compiling statically in windows doesn't compile shared libs into your binary as it does in unix? Or am I missing something? -Jack To an optimist the glass is half full. To a pessimist the glass is half empty. To a programmer the glass is twice as big as it needs to be.
Not system files. It would be a HUGE mistake. You don't want system files in your executables. Not only would it mean that you would have to build a special version for each OS, but it would also mean a special version for each SP. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
So compiling statically in windows doesn't compile shared libs into your binary as it does in unix? Or am I missing something? -Jack To an optimist the glass is half full. To a pessimist the glass is half empty. To a programmer the glass is twice as big as it needs to be.
You're confusing a couple of different things here. There are three ways a library can be used.
- A static (or object) library is an OBJ that is linked in with your application. This file contains the actual implementation of the code. When you select the link statically with MFC, you are including the MFC static link libaries into your build.
- Like static libraries, import libraries are used by the linker to resolve function calls. However, unlike static libraries, import libraries contain no code. Instead, import libraries contain information that helps Windows load and resolve (non-static) function calls at runtime. As an example, let's say you make a call to CreateWindow in your code. In order for this to compile, you must have that function declared somewhere. This is take care of with the inclusion of the windows.h header. Now for the application to link, you must either include an object library (static library) that contains the actual CreateWindow function or you must provide an import library that contains the information that is needed to load the DLL containing the function at runtime. For this particular function, you would always use an import library as you would never want to statically link to the system libraries.
- The last way to use a library is dynamically. To do this a DLL is loaded via the LoadLibrary function and functions are resolved via calls the GetProcAddress. Now the case of the richedit control (housed in the riched20.dll). When you use the CRichEditCtrl, you are simply using a class that wraps the RICHEDIT window class. In order for you to resolve to the CRichEditCtrl member functions you will either statically link to the MFC or dynamically link to the MFC. However, that's not all you have to do because at this point you're only making the compiler and linker happy with regards to calls to a C++ class. This has nothing to do with the underlying window. When you create a window, you do so by calling the CreateWindow function and passing a window class. In the case of the rich edit control, this value is "RICHEDIT". When you do that, Windows will look at an internal table and see if it any code has registered a window with the name of "RICHEDI". If so, your CreateWindow succeeds (assuming the other params are corred). If not, it fails. But how does Windows know if a Window is "registered" or not and what does that mean? If you have installed the riched20.dll, upon its loading by Windows, that DLL will call the RegisterWindow functi
-
Not system files. It would be a HUGE mistake. You don't want system files in your executables. Not only would it mean that you would have to build a special version for each OS, but it would also mean a special version for each SP. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
[Edited to be half-way intellible once I had a coke in me] It wouldn't matter anyway as user applications don't link with the libraries that contain the control code (e.g., commctrl, riched, etc.) The issue is that Windows needs to load the control's encapsulating library in order to associate the window class name (passed to CreateWindow) to the window's winproc. Cheers, Tom Archer Author, Inside C# A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.
-
Not system files. It would be a HUGE mistake. You don't want system files in your executables. Not only would it mean that you would have to build a special version for each OS, but it would also mean a special version for each SP. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
I rewrote my first response to you as upon re-reading it, I found it barely intelligible. I should never write anything before my first coke. :) Cheers, Tom Archer Author, Inside C# A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.
-
You're confusing a couple of different things here. There are three ways a library can be used.
- A static (or object) library is an OBJ that is linked in with your application. This file contains the actual implementation of the code. When you select the link statically with MFC, you are including the MFC static link libaries into your build.
- Like static libraries, import libraries are used by the linker to resolve function calls. However, unlike static libraries, import libraries contain no code. Instead, import libraries contain information that helps Windows load and resolve (non-static) function calls at runtime. As an example, let's say you make a call to CreateWindow in your code. In order for this to compile, you must have that function declared somewhere. This is take care of with the inclusion of the windows.h header. Now for the application to link, you must either include an object library (static library) that contains the actual CreateWindow function or you must provide an import library that contains the information that is needed to load the DLL containing the function at runtime. For this particular function, you would always use an import library as you would never want to statically link to the system libraries.
- The last way to use a library is dynamically. To do this a DLL is loaded via the LoadLibrary function and functions are resolved via calls the GetProcAddress. Now the case of the richedit control (housed in the riched20.dll). When you use the CRichEditCtrl, you are simply using a class that wraps the RICHEDIT window class. In order for you to resolve to the CRichEditCtrl member functions you will either statically link to the MFC or dynamically link to the MFC. However, that's not all you have to do because at this point you're only making the compiler and linker happy with regards to calls to a C++ class. This has nothing to do with the underlying window. When you create a window, you do so by calling the CreateWindow function and passing a window class. In the case of the rich edit control, this value is "RICHEDIT". When you do that, Windows will look at an internal table and see if it any code has registered a window with the name of "RICHEDI". If so, your CreateWindow succeeds (assuming the other params are corred). If not, it fails. But how does Windows know if a Window is "registered" or not and what does that mean? If you have installed the riched20.dll, upon its loading by Windows, that DLL will call the RegisterWindow functi
Very informative, thank you. Like I said before, I wasn't sure how windows would handle this. I was speaking from my unix experience. In unix if you are to include a library like PCRE (Perl Compatible Regular Expressions) for example, If you link normal the person running your binary has to have PCRE on their system, if you use the -static flag it compiles all the code in (resulting in a much larger binary) and you don't have to worry about your users having PCRE at all. I assumed windows would work similar. -Jack To an optimist the glass is half full. To a pessimist the glass is half empty. To a programmer the glass is twice as big as it needs to be.
-
Very informative, thank you. Like I said before, I wasn't sure how windows would handle this. I was speaking from my unix experience. In unix if you are to include a library like PCRE (Perl Compatible Regular Expressions) for example, If you link normal the person running your binary has to have PCRE on their system, if you use the -static flag it compiles all the code in (resulting in a much larger binary) and you don't have to worry about your users having PCRE at all. I assumed windows would work similar. -Jack To an optimist the glass is half full. To a pessimist the glass is half empty. To a programmer the glass is twice as big as it needs to be.
Jack Handy wrote: Like I said before, I wasn't sure how windows would handle this No problem. That's why into a bit of detail. Cheers, Tom Archer Author, Inside C# A total abstainer is one who abstains from everything but abstention, and especially from inactivity in the affairs of others.