Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. How do I deploy riched20.dll?

How do I deploy riched20.dll?

Scheduled Pinned Locked Moved C / C++ / MFC
questioncom
12 Posts 4 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • O Oz Ben Eliezer

    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!

    T Offline
    T Offline
    Tom Archer
    wrote on last edited by
    #3

    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.

    1 Reply Last reply
    0
    • O Oz Ben Eliezer

      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!

      J Offline
      J Offline
      Jack Handy
      wrote on last edited by
      #4

      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.

      T 1 Reply Last reply
      0
      • J Jack Handy

        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.

        T Offline
        T Offline
        Tom Archer
        wrote on last edited by
        #5

        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.

        J 1 Reply Last reply
        0
        • T Tom Archer

          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.

          J Offline
          J Offline
          Jack Handy
          wrote on last edited by
          #6

          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.

          T T 2 Replies Last reply
          0
          • J Jack Handy

            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.

            T Offline
            T Offline
            Tim Smith
            wrote on last edited by
            #7

            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?

            T 2 Replies Last reply
            0
            • J Jack Handy

              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.

              T Offline
              T Offline
              Tom Archer
              wrote on last edited by
              #8

              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
              J 1 Reply Last reply
              0
              • T Tim Smith

                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?

                T Offline
                T Offline
                Tom Archer
                wrote on last edited by
                #9

                [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.

                1 Reply Last reply
                0
                • T Tim Smith

                  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?

                  T Offline
                  T Offline
                  Tom Archer
                  wrote on last edited by
                  #10

                  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.

                  1 Reply Last reply
                  0
                  • T Tom Archer

                    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
                    J Offline
                    J Offline
                    Jack Handy
                    wrote on last edited by
                    #11

                    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.

                    T 1 Reply Last reply
                    0
                    • J Jack Handy

                      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.

                      T Offline
                      T Offline
                      Tom Archer
                      wrote on last edited by
                      #12

                      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.

                      1 Reply Last reply
                      0
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • World
                      • Users
                      • Groups