blob: 4ba828c1a21f5aaa8f910884c74ba131e5763195 [file] [log] [blame]
cristy3ed852e2009-09-05 21:47:34 +00001WINDOWS 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
191ENVIRONMENT 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