cristy | 3ed852e | 2009-09-05 21:47:34 +0000 | [diff] [blame^] | 1 | WINDOWS XP/Win2K/98 VISUAL C++ 6.0 AND 7.0 COMPILATION |
| 2 | |
| 3 | The Visual C++ distribution targeted at Windows XP, Win2K, or Windows |
| 4 | 98 does not provide any stock workspace (DSW) or project files (DSP) |
| 5 | except for those included with third party libraries. Instead, there |
| 6 | is a `configure' program that must be built and run that creates build |
| 7 | environments to satisfy various requirements. |
| 8 | |
| 9 | The Visual C++ system provides three different types of "runtimes" that |
| 10 | must match across all application, library, and DLL code that is built. The |
| 11 | `configure' program creates a set of build files that are consistent for |
| 12 | a specific runtime selection. |
| 13 | |
| 14 | The three options for runtime support are: |
| 15 | |
| 16 | 1) Dynamic Multi-threaded DLL runtimes (VisualDynamicMT). |
| 17 | 2) Static Single-threaded runtimes (VisualStaticST). |
| 18 | 3) Static Multi-threaded runtimes (VisualStaticMT). |
| 19 | 4) Static Multi-threaded DLL runtimes (VisualStaticMTDLL). |
| 20 | |
| 21 | In addition to these runtimes, the VisualMagick build environment allows |
| 22 | you to select whether to include the X11 libraries in the build or not. |
| 23 | X11 DLLs and headers are provided with the VisualMagick build environment. |
| 24 | Most Windows users do not use X11 so they will prefer to build without |
| 25 | X11 support. Without X11 support, the `animate', `display', and `import' |
| 26 | will not work. |
| 27 | |
| 28 | This leads to five different possible build options, which should cover |
| 29 | almost any particular situation. The default binary distribution is built |
| 30 | using #1 from above with the X11 libraries included. This results in an |
| 31 | X11 compatible build using all DLL's for everything and multi-threaded |
| 32 | support (the only option for DLL's). |
| 33 | |
| 34 | To do a build for your requirements, simply go to the configure subdirectory |
| 35 | under VisualMagick and open the configure.dsw workspace (for Visual C++ |
| 36 | 6.0) or configure.sln (for Visual C++ 7.0). Set the build configuration to |
| 37 | "Release" under the |
| 38 | |
| 39 | "Build..., Set Active Configuration..." |
| 40 | |
| 41 | menu. |
| 42 | |
| 43 | Build and execute the configure program and follow the on-screen |
| 44 | instructions. Generally you can accept the configuration defaults. |
| 45 | |
| 46 | The configure program provides a button titled |
| 47 | |
| 48 | Edit "magick_config.h" |
| 49 | |
| 50 | Clicking this button allows you to edit `magick_config.h' in a Windows |
| 51 | Notepad window for optionally changing any preprocessor defines. |
| 52 | This file is copied to `magick\magick_config.h'. You may safely open |
| 53 | `magick\magick_config.h', modify it, and recompile without re-running the |
| 54 | configure program. In fact, using the notepad program to edit the copied |
| 55 | file may be preferable since it preserves the original `magick_config.hi' |
| 56 | file. |
| 57 | |
| 58 | Key user tunables in magick_config.h include: |
| 59 | |
| 60 | MAGICKCORE_QUANTUM_DEPTH (default 16) |
| 61 | |
| 62 | Specify the size of PixelPacket color Quantums (8, 16, or 32). |
| 63 | If you need to preserve the fidelity of 16-bit images (gray, png, |
| 64 | etc), use 16. If you want to work in remote sensing or if you are |
| 65 | a mad scientist you might consider 32. Note, that a quantum-depth |
| 66 | 16 uses 4-times as much memory as the default quantum-depth of 8, |
| 67 | whereas a quantum-depth of 32 uses 16-times as much memory. |
| 68 | |
| 69 | MAGICKCORE_INSTALLED_SUPPORT (default undefined) |
| 70 | |
| 71 | Define to build an ImageMagick which uses registry settings or embedded |
| 72 | paths to locate installed components (coder modules and configuration |
| 73 | files). The default is to look for all files in the same directory |
| 74 | as the executable. |
| 75 | |
| 76 | ProvideDllMain (default defined) |
| 77 | |
| 78 | Define to include a DllMain() function ensures that the ImageMagick |
| 79 | DLL is properly initialized without participation from dependent |
| 80 | applications. This avoids the requirement to invoke IntializeMagick() |
| 81 | from dependent applications but only works for DLL builds. |
| 82 | |
| 83 | After creating your build environment you can proceed to open the DSW |
| 84 | (or SLN) file that was generated in the VisualMagick directory and build |
| 85 | everything from there. |
| 86 | |
| 87 | In the final DSW file you will find a project call "All". In order to |
| 88 | build everything in the distribution, select this project and make it the |
| 89 | "active" project. Set the build configuration to the desired one (Debug, |
| 90 | or Release) and do a "clean" followed by a "build". You should do the |
| 91 | build in a specific way: |
| 92 | |
| 93 | 1) Make the "All" project the active project (Bold) |
| 94 | Right click on the All project and select "Set As Active Project" |
| 95 | 2) Select "Build..., Clean" 3) Select "Build..., Build" 4) Go get some |
| 96 | coffee unless you have a very fast machine!. |
| 97 | |
| 98 | The "Clean" step is needed in order to make sure that all of the target |
| 99 | support libraries are updated with any patches needed to get them to |
| 100 | compile properly under Visual C++. |
| 101 | |
| 102 | All of the required files that are needed to run any of the command |
| 103 | line tools will be found in the "bin" subdirectory of the VisualMagick |
| 104 | subdirectory. This includes EXE, and DLL files. You should be able to test |
| 105 | the build directly from this directory without having to move anything to any |
| 106 | of the global SYSTEM or SYSTEM32 areas in the operating system installation. |
| 107 | |
| 108 | Note #1: |
| 109 | |
| 110 | The Visual C++ distribution of ImageMagick comes with the Magick++ |
| 111 | C++ wrapper by default. This add-on layer has a large number of demo |
| 112 | and test files that can be found in ImageMagick\Magick++\demo, and |
| 113 | ImageMagick\Magick++\tests. There are also a variety of tests that use |
| 114 | the straight C API as well in ImageMagick\tests. |
| 115 | |
| 116 | All of these programs are NOT configured to be built in the default |
| 117 | workspace created by the configure program. You can build these demos |
| 118 | and test programs to be built by checking the box in configure that says: |
| 119 | |
| 120 | "Include all demo and test programs" |
| 121 | |
| 122 | In addition, there is another related checkbox (checked by default) that |
| 123 | causes all generated project files to be created standalone so that they |
| 124 | can be copied to other areas of you system. |
| 125 | |
| 126 | This is the checkbox: |
| 127 | |
| 128 | "Generate all utility projects with full paths rather then relative paths" |
| 129 | |
| 130 | Visual C++ uses a concept of "dependencies" that tell it what other |
| 131 | components need to be build when a particular project is being build. |
| 132 | This mechanism is also used to ensure that components link properly. |
| 133 | With this feature enabled, you should be able to nab a copy of... |
| 134 | |
| 135 | VisualMagick\utilities\UTIL_convert_xxx_exe.dsp (for C) |
| 136 | |
| 137 | or |
| 138 | |
| 139 | VisualMagick\Magick++\demo\UTIL_demo_xxx_exe.dsp (for C++) |
| 140 | |
| 141 | and pop it into the notepad program, modify it (carefully) to your needs |
| 142 | and be on your way to happy compiling and linking. |
| 143 | |
| 144 | You can feel free to pick any of the standard utilities, tests, or demo |
| 145 | programs as the basis for a new program by copying the project and the |
| 146 | source and hacking away. |
| 147 | |
| 148 | The choice of what to use as a starting point is very easy. |
| 149 | |
| 150 | For straight C API command line applications use something from: |
| 151 | |
| 152 | ImageMagick\tests or ImageMagick\utilities (source code) |
| 153 | ImageMagick\VisualMagick\tests or ImageMagick\Visualmagick\utilities (project - DSP) |
| 154 | |
| 155 | For C++ and Magick++ command line applications use something from: |
| 156 | |
| 157 | ImageMagick\Magick++\tests or ImageMagick\Magick++\demo (source code) |
| 158 | ImageMagick\VisualMagick\Magick++\tests or ImageMagick\VisualMagick\Magick++\demo (project - DSP) |
| 159 | |
| 160 | For C++ and Magick++ and MFC windows applications use: |
| 161 | |
| 162 | ImageMagick\contrib\win32\MFC\NtMagick (source code) |
| 163 | ImageMagick\VisualMagick\contrib\win32\MFC\NtMagick (project - DSP) |
| 164 | |
| 165 | Note #2: |
| 166 | |
| 167 | The ImageMagick distribution is very modular. The default configuration |
| 168 | is there to get you rolling, but you need to make some serious choices |
| 169 | when you wish to change things around. |
| 170 | |
| 171 | The default options are all targeted at having all the components in one |
| 172 | place (e.g. the "bin" directory of the VisualMagick build tree). These |
| 173 | components may be copied to another folder (such as to another computer). |
| 174 | |
| 175 | The folder containing the executables and DLLs should contain all the |
| 176 | configuration files, *.xml. |
| 177 | |
| 178 | The "bin" folder should contains all EXE's and DLL's as well as the very |
| 179 | important "coder.xml" file. |
| 180 | |
| 181 | With this default setup, you can use any of the command line tools and run |
| 182 | scripts as normal. You can actually get by quite nicely this way by doing |
| 183 | something like "pushd e:\xxx\yyy\bin" in any scripts you write to execute |
| 184 | "out of" this directory. |
| 185 | |
| 186 | By default the core of ImageMagick on Win32 always looks in the place were |
| 187 | the exe program is run from in order to find all of the files as well as |
| 188 | the DLL's it needs. |
| 189 | |
| 190 | |
| 191 | ENVIRONMENT VARIABLES |
| 192 | |
| 193 | You can use the "System" control panel to allow you to add and delete what |
| 194 | is in any of the environment variables. You can even have user specific |
| 195 | environment variables if you wish. |
| 196 | |
| 197 | PATH |
| 198 | |
| 199 | This sets the default list of places were Windows looks for EXE's |
| 200 | and DLL's. Windows CMD shell seems to look in the "current" directory |
| 201 | first - no matter what, which may make it unnecessary to update the PATH. |
| 202 | If you wish to run any of utilities from another location, you must |
| 203 | add the path to your "bin" directory in. For instance, you might add: |
| 204 | |
| 205 | D:\CVS\ImageMagick\VisualMagick\bin |
| 206 | |
| 207 | to do this for the default build environment like I do. |
| 208 | |
| 209 | MAGICK_HOME |
| 210 | |
| 211 | If all you do is modify the PATH variable, the first problem you will run |
| 212 | into is that ImageMagick may not be able to find any of its "modules". |
| 213 | Modules are all the IM_MOD*.DLL files you see in the distribution. |
| 214 | There is one of these for each and every file format that ImageMagick |
| 215 | supports. This environment variable tells the system were to look for |
| 216 | these DLL's. The compiled in "default" is "execution path" - which says |
| 217 | - look in the same place that the application is running "in". If you |
| 218 | are running from somewhere other then "bin" - this will no longer work |
| 219 | and you must use this variable. If you elect to leave the modules in |
| 220 | the same place as the EXE's (a good idea), you can simply set this to |
| 221 | the same place as you did the PATH variable. In my case: |
| 222 | |
| 223 | D:\\ImageMagick\coders |
| 224 | |
| 225 | This is also the place were ImageMagick expects to find the configuration |
| 226 | files, *.xml, including module.xml, type.xml, etc. |
| 227 | |
| 228 | One cool thing about the modules build of ImageMagick is that you can |
| 229 | now leave out file formats and lighten you load. If all you ever need is |
| 230 | GIF and JPEG, simply drop all the other DLL's into the local trash |
| 231 | can and get on with your life. However, always keep the "xc" format, |
| 232 | since ImageMagick uses it for internal purposes. |
| 233 | |
| 234 | Also. You can elect to changes these things the good old "hard-coded" |
| 235 | way. Two #defines are applicable. |
| 236 | |
| 237 | defines.h has |
| 238 | |
| 239 | #define MagickConfigurePath "c:\\ImageMagick\\" |
| 240 | |
| 241 | To view any image in a Microsoft window, type |
| 242 | |
| 243 | convert image.ext win: |
| 244 | |
| 245 | Make sure Ghostscript is installed, otherwise, you will be unable to |
| 246 | convert or view a Postscript document, and Postscript standard fonts will |
| 247 | not be available. |
| 248 | |
| 249 | You may use any standard web browser (e.g. Internet Explorer) to browse |
| 250 | the ImageMagick documentation. |
| 251 | |
| 252 | The Win2K executables will work under Windows 98. |
| 253 | |