Steve Dower | bb24087 | 2015-02-05 22:08:48 -0800 | [diff] [blame] | 1 | Quick Build Info |
| 2 | ================ |
Martin v. Löwis | 8ffe9ab | 2004-08-22 13:34:34 +0000 | [diff] [blame] | 3 | |
Steve Dower | bb24087 | 2015-02-05 22:08:48 -0800 | [diff] [blame] | 4 | For testing, the installer should be built with the Tools/msi/build.bat |
| 5 | script: |
Martin v. Löwis | 8ffe9ab | 2004-08-22 13:34:34 +0000 | [diff] [blame] | 6 | |
Steve Dower | bb24087 | 2015-02-05 22:08:48 -0800 | [diff] [blame] | 7 | build.bat [-x86] [-x64] [--doc] |
Martin v. Löwis | 8ffe9ab | 2004-08-22 13:34:34 +0000 | [diff] [blame] | 8 | |
Steve Dower | bb24087 | 2015-02-05 22:08:48 -0800 | [diff] [blame] | 9 | For an official release, the installer should be built with the |
| 10 | Tools/msi/buildrelease.bat script and environment variables: |
Martin v. Löwis | 8ffe9ab | 2004-08-22 13:34:34 +0000 | [diff] [blame] | 11 | |
Steve Dower | bb24087 | 2015-02-05 22:08:48 -0800 | [diff] [blame] | 12 | set PYTHON=<path to Python 2.7> |
| 13 | set SPHINXBUILD=<path to sphinx-build.exe> |
| 14 | set PATH=<path to Mercurial (hg.exe)>; |
| 15 | <path to HTML Help Compiler (hhc.exe)>;%PATH% |
Martin v. Löwis | 8ffe9ab | 2004-08-22 13:34:34 +0000 | [diff] [blame] | 16 | |
Steve Dower | bb24087 | 2015-02-05 22:08:48 -0800 | [diff] [blame] | 17 | buildrelease.bat [-x86] [-x64] [-D] [-B] |
| 18 | [-o <output directory>] [-c <certificate name>] |
| 19 | |
| 20 | See the Building the Installer section for more information. |
| 21 | |
| 22 | Overview |
| 23 | ======== |
| 24 | |
| 25 | Python is distributed on Windows as an installer that will configure the |
| 26 | user's system. This allows users to have a functioning copy of Python |
| 27 | without having to build it themselves. |
| 28 | |
| 29 | The main tasks of the installer are: |
| 30 | |
| 31 | * copy required files into the expected layout |
| 32 | * configure system settings so the installation can be located by |
| 33 | other programs |
| 34 | * add entry points for modifying, repairing and uninstalling Python |
| 35 | * make it easy to launch Python, its documentation, and IDLE |
| 36 | |
| 37 | Each of these is discussed in a later section of this document. |
| 38 | |
| 39 | Structure of the Installer |
| 40 | ========================== |
| 41 | |
| 42 | The installer is structured as a 'layout', which consists of a number of |
| 43 | CAB and MSI files and a single EXE. |
| 44 | |
| 45 | The EXE is the main entry point into the installer. It contains the UI |
| 46 | and command-line logic, as well as the ability to locate and optionally |
| 47 | download other parts of the layout. |
| 48 | |
| 49 | Each MSI contains the logic required to install a component or feature |
| 50 | of Python. These MSIs should not be launched directly by users. MSIs can |
| 51 | be embedded into the EXE or automatically downloaded as needed. |
| 52 | |
| 53 | Each CAB contains the files making up a Python installation. CABs are |
| 54 | embedded into their associated MSI and are never seen by users. |
| 55 | |
| 56 | MSIs are only required when the related feature or component is being |
| 57 | installed. When components are not selected for installation, the |
| 58 | associated MSI is not downloaded. This allows the installer to offer |
| 59 | options to install debugging symbols and binaries without increasing |
| 60 | the initial download size by separating them into their own MSIs. |
| 61 | |
| 62 | Building the Installer |
| 63 | ====================== |
| 64 | |
| 65 | For testing, the installer should be built with the Tools/msi/build.bat |
| 66 | script: |
| 67 | |
| 68 | build.bat [-x86] [-x64] [--doc] |
| 69 | |
| 70 | This script will build the required configurations of Python and |
| 71 | generate an installer layout in PCBuild/(win32|amd64)/en-us. |
| 72 | |
| 73 | Specify -x86 and/or -x64 to build for each platform. If neither is |
| 74 | specified, both platforms will be built. Currently, both the debug and |
| 75 | release versions of Python are required for the installer. |
| 76 | |
| 77 | Specify --doc to build the documentation (.chm) file. If the file is not |
| 78 | available, it will simply be excluded from the installer. Ensure |
| 79 | %PYTHON% and %SPHINXBUILD% are set when passing this option. You may |
| 80 | also set %HTMLHELP% to the Html Help Compiler (hhc.exe), or put HHC on |
| 81 | your PATH or in externals/. |
| 82 | |
| 83 | If WiX is not found on your system, it will be automatically downloaded |
| 84 | and extracted to the externals/ directory. |
| 85 | |
| 86 | |
| 87 | For an official release, the installer should be built with the |
| 88 | Tools/msi/buildrelease.bat script: |
| 89 | |
| 90 | set PYTHON=<path to Python 2.7> |
| 91 | set SPHINXBUILD=<path to sphinx-build.exe> |
| 92 | set PATH=<path to Mercurial (hg.exe)>; |
| 93 | <path to HTML Help Compiler (hhc.exe)>;%PATH% |
| 94 | |
| 95 | buildrelease.bat [-x86] [-x64] [-D] [-B] |
| 96 | [-o <output directory>] [-c <certificate name>] |
| 97 | |
| 98 | Specify -x86 and/or -x64 to build for each platform. If neither is |
| 99 | specified, both platforms will be built. Currently, both the debug and |
| 100 | release versions of Python are required for the installer. |
| 101 | |
| 102 | Specify -D to skip rebuilding the documentation. The documentation is |
| 103 | required for a release and the build will fail if it is not available. |
| 104 | |
| 105 | Specify -B to skip rebuilding Python. This is useful to only rebuild the |
| 106 | installer layout after a previous call to buildrelease.bat. |
| 107 | |
| 108 | Specify -o to set an output directory. The installer layouts will be |
| 109 | copied to platform-specific subdirectories of this path. |
| 110 | |
| 111 | Specify -c to choose a code-signing certificate to be used for all the |
| 112 | signable binaries in Python as well as each file making up the |
| 113 | installer. Official releases of Python must be signed. |
| 114 | |
| 115 | Ensure %PYTHON% and %SPHINXBUILD% are set when passing this option. You |
| 116 | may also set %HTMLHELP% to the Html Help Compiler (hhc.exe), or put HHC |
| 117 | on your PATH or in externals/. You will also need Mercurial (hg.exe) on |
| 118 | your PATH. |
| 119 | |
| 120 | If WiX is not found on your system, it will be automatically downloaded |
| 121 | and extracted to the externals/ directory. |
| 122 | |
| 123 | To manually build layouts of the installer, build one of the projects in |
| 124 | the bundle folder. |
| 125 | |
| 126 | msbuild bundle\snapshot.wixproj |
| 127 | msbuild bundle\releaseweb.wixproj |
| 128 | msbuild bundle\releaselocal.wixproj |
| 129 | msbuild bundle\full.wixproj |
| 130 | |
| 131 | snapshot.wixproj produces a test installer versioned based on the date. |
| 132 | |
| 133 | releaseweb.wixproj produces a release installer that does not embed any |
| 134 | of the layout. |
| 135 | |
| 136 | releaselocal.wixproj produces a release installer that embeds the files |
| 137 | required for a default installation. |
| 138 | |
| 139 | full.wixproj produces a test installer that embeds the entire layout. |
| 140 | |
| 141 | The following properties may be passed when building these projects. |
| 142 | |
| 143 | /p:BuildForRelease=(true|false) |
| 144 | When true, adds extra verification to ensure a complete installer is |
| 145 | produced. For example, binutils is required when building for a release |
| 146 | to generate MinGW-compatible libraries, and the build will be aborted if |
| 147 | this fails. Defaults to false. |
| 148 | |
| 149 | /p:ReleaseUri=(any URI) |
| 150 | Used to generate unique IDs for the installers to allow side-by-side |
| 151 | installation. Forks of Python can use the same installer infrastructure |
| 152 | by providing a unique URI for this property. It does not need to be an |
| 153 | active internet address. Defaults to $(ComputerName). |
| 154 | |
| 155 | Official releases use http://www.python.org/(architecture name) |
| 156 | |
| 157 | /p:DownloadUrlBase=(any URI) |
| 158 | Specifies the base of a URL where missing parts of the installer layout |
| 159 | can be downloaded from. The build version and architecture will be |
| 160 | appended to create the full address. If omitted, missing components will |
| 161 | not be automatically downloaded. |
| 162 | |
| 163 | /p:DownloadUrl=(any URI) |
| 164 | Specifies the full URL where missing parts of the installer layout can |
| 165 | be downloaded from. Should normally include '{2}', which will be |
| 166 | substituted for the filename. If omitted, missing components will not be |
| 167 | automatically downloaded. If specified, this value overrides |
| 168 | DownloadUrlBase. |
| 169 | |
| 170 | /p:SigningCertificate=(certificate name) |
| 171 | Specifies the certificate to sign the installer layout with. If omitted, |
| 172 | the layout will not be signed. |
| 173 | |
| 174 | /p:RebuildAll=(true|false) |
| 175 | When true, rebuilds all of the MSIs making up the layout. Defaults to |
| 176 | true. |
| 177 | |
| 178 | Modifying the Installer |
| 179 | ======================= |
| 180 | |
| 181 | The code for the installer is divided into three main groups: packages, |
| 182 | the bundle and the bootstrap application. |
| 183 | |
| 184 | Packages |
| 185 | -------- |
| 186 | |
| 187 | Packages appear as subdirectories of Tools/msi (other than the bundle/ |
| 188 | directory). The project file is a .wixproj and the build output is a |
| 189 | single MSI. Packages are built with the WiX Toolset. Some project files |
| 190 | share source files and use preprocessor directives to enable particular |
| 191 | features. These are typically used to keep the sources close when the |
| 192 | files are related, but produce multiple independent packages. |
| 193 | |
| 194 | A package is the smallest element that may be independently installed or |
| 195 | uninstalled (as used in this installer). For example, the test suite has |
| 196 | its own package, as users can choose to add or remove it after the |
| 197 | initial installation. |
| 198 | |
| 199 | All the files installed by a single package should be related, though |
| 200 | some packages may not install any files. For example, the pip package |
| 201 | executes the ensurepip package, but does not add or remove any of its |
| 202 | own files. (It is represented as a package because of its |
| 203 | installed/uninstalled nature, as opposed to the "precompile standard |
| 204 | library" option, for example.) Dependencies between packages are handled |
| 205 | by the bundle, but packages should detect when dependencies are missing |
| 206 | and raise an error. |
| 207 | |
| 208 | Packages that include a lot of files may use an InstallFiles element in |
| 209 | the .wixproj file to generate sources. See lib/lib.wixproj for an |
| 210 | example, and msi.targets and csv_to_wxs.py for the implementation. This |
| 211 | element is also responsible for generating the code for cleaning up and |
| 212 | removing __pycache__ folders in any directory containing .py files. |
| 213 | |
| 214 | All packages are built with the Tools/msi/common.wxs file, and so any |
| 215 | directory or property in this file may be referenced. Of particular |
| 216 | interest: |
| 217 | |
| 218 | REGISTRYKEY (property) |
| 219 | The registry key for the current installation. |
| 220 | |
| 221 | InstallDirectory (directory) |
| 222 | The root install directory for the current installation. Subdirectories |
| 223 | are also specified in this file (DLLs, Lib, etc.) |
| 224 | |
| 225 | MenuDir (directory) |
| 226 | The Start Menu folder for the current installation. |
| 227 | |
| 228 | UpgradeTable (property) |
| 229 | Every package should reference this property to include upgrade |
| 230 | information. |
| 231 | |
| 232 | The .wxl_template file is specially handled by the build system for this |
| 233 | project to perform {{substitutions}} as defined in msi.targets. They |
| 234 | should be included in projects as <WxlTemplate> items, where .wxl files |
| 235 | are normally included as <EmbeddedResource> items. |
| 236 | |
| 237 | Bundle |
| 238 | ------ |
| 239 | |
| 240 | The bundle is compiled to the main EXE entry point that for most users |
| 241 | will represent the Python installer. It is built from Tools/msi/bundle |
| 242 | with packages references in Tools/msi/bundle/packagegroups. |
| 243 | |
| 244 | Build logic for the bundle is in bundle.targets, but should be invoked |
| 245 | through one of the .wixproj files as described in Building the |
| 246 | Installer. |
| 247 | |
| 248 | The UI is separated between Default.thm (UI layout), Default.wxl |
| 249 | (strings), bundle.wxs (properties) and the bootstrap application. |
| 250 | Bundle.wxs also contains the chain, which is the list of packages to |
| 251 | install and the order they should be installed in. These refer to named |
| 252 | package groups in bundle/packagegroups. |
| 253 | |
| 254 | Each package group specifies one or more packages to install. Most |
| 255 | packages require two separate entries to support both per-user and |
| 256 | all-users installations. Because these reuse the same package, it does |
| 257 | not increase the overall size of the package. |
| 258 | |
| 259 | Package groups refer to payload groups, which allow better control over |
| 260 | embedding and downloading files than the default settings. Whether files |
| 261 | are embedded and where they are downloaded from depends on settings |
| 262 | created by the project files. |
| 263 | |
| 264 | Package references can include install conditions that determine when to |
| 265 | install the package. When a package is a dependency for others, the |
| 266 | condition should be crafted to ensure it is installed. |
| 267 | |
| 268 | MSI packages are installed or uninstalled based on their current state |
| 269 | and the install condition. This makes them most suitable for features |
| 270 | that are clearly present or absent from the user's machine. |
| 271 | |
| 272 | EXE packages are executed based on a customisable condition that can be |
| 273 | omitted. This makes them suitable for pre- or post-install tasks that |
| 274 | need to run regardless of whether features have been added or removed. |
| 275 | |
| 276 | Bootstrap Application |
| 277 | --------------------- |
| 278 | |
| 279 | The bootstrap application is a C++ application that controls the UI and |
| 280 | installation. While it does not directly compile into the main EXE of |
| 281 | the installer, it forms the main active component. Most of the |
| 282 | installation functionality is provided by WiX, and so the bootstrap |
| 283 | application is predominantly responsible for the code behind the UI that |
| 284 | is defined in the Default.thm file. The bootstrap application code is in |
| 285 | bundle/bootstrap and is built automatically when building the bundle. |
| 286 | |
| 287 | Installation Layout |
| 288 | =================== |
| 289 | |
| 290 | There are two installation layouts for Python on Windows, with the only |
| 291 | differences being supporting files. A layout is selected implicitly |
| 292 | based on whether the install is for all users of the machine or just for |
| 293 | the user performing the installation. |
| 294 | |
| 295 | The default installation location when installing for all users is |
| 296 | "%ProgramFiles%\Python 3.X" for the 64-bit interpreter and |
| 297 | "%ProgramFiles(x86)%\Python 3.X" for the 32-bit interpreter. (Note that |
| 298 | the latter path is equivalent to "%ProgramFiles%\Python 3.X" when |
| 299 | running a 32-bit version of Windows.) This location requires |
| 300 | administrative privileges to install or later modify the installation. |
| 301 | |
| 302 | The default installation location when installing for the current user |
| 303 | is "%LocalAppData%\Programs\Python\Python3X" for the 64-bit interpreter |
| 304 | and "%LocalAppData%\Programs\Python\Python3X-32" for the 32-bit |
| 305 | interpreter. Only the current user can access this location. This |
| 306 | provides a suitable level of protection against malicious modification |
| 307 | of Python's files. |
| 308 | |
| 309 | Within this install directory is the following approximate layout: |
| 310 | |
| 311 | .\python[w].exe The core executable files |
| 312 | .\DLLs Stdlib extensions (*.pyd) and dependencies |
| 313 | .\Doc Documentation (*.chm) |
| 314 | .\include Development headers (*.h) |
| 315 | .\Lib Standard library |
| 316 | .\Lib\test Test suite |
| 317 | .\libs Development libraries (*.lib) |
| 318 | .\Scripts Launcher scripts (*.exe, *.py) |
| 319 | .\tcl Tcl dependencies (*.dll, *.tcl and others) |
| 320 | .\Tools Tool scripts (*.py) |
| 321 | |
| 322 | When installed for all users, the following files are installed to |
| 323 | either "%SystemRoot%\System32" or "%SystemRoot%\SysWOW64" as |
| 324 | appropriate. For the current user, they are installed in the Python |
| 325 | install directory. |
| 326 | |
| 327 | .\python3x.dll The core interpreter |
| 328 | .\python3.dll The stable ABI reference |
| 329 | .\appcrt140.dll Microsoft Visual C Runtime |
| 330 | .\desktopcrt140.dll Microsoft Visual C Runtime |
| 331 | .\vcruntime140.dll Microsoft Visual C Runtime |
| 332 | |
| 333 | When installed for all users, the following files are installed to |
| 334 | "%SystemRoot%" (typically "C:\Windows") to ensure they are always |
| 335 | available on PATH. (See Launching Python below.) For the current user, |
| 336 | they are installed in the Python install directory. |
| 337 | |
| 338 | .\py[w].exe PEP 397 launcher |
| 339 | |
| 340 | System Settings |
| 341 | =============== |
| 342 | |
| 343 | On installation, registry keys are created so that other applications |
| 344 | can locate and identify installations of Python. The locations of these |
| 345 | keys vary based on the install type. |
| 346 | |
| 347 | For 64-bit interpreters installed for all users, the root key is: |
| 348 | HKEY_LOCAL_MACHINE\Software\Python\PythonCore\3.X |
| 349 | |
| 350 | For 32-bit interpreters installed for all users on a 64-bit operating |
| 351 | system, the root key is: |
| 352 | HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\PythonCore\3.X-32 |
| 353 | |
| 354 | For 32-bit interpreters installed for all users on a 32-bit operating |
| 355 | system, the root key is: |
| 356 | HKEY_LOCAL_MACHINE\Software\Python\PythonCore\3.X-32 |
| 357 | |
| 358 | For 64-bit interpreters installed for the current user: |
| 359 | HKEY_CURRENT_USER\Software\Python\PythonCore\3.X |
| 360 | |
| 361 | For 32-bit interpreters installed for the current user: |
| 362 | HKEY_CURRENT_USER\Software\Python\PythonCore\3.X-32 |
| 363 | |
| 364 | When the core Python executables are installed, a key "InstallPath" is |
| 365 | created within the root key with its default value set to the |
| 366 | executable's install directory. Within this key, a key "InstallGroup" is |
| 367 | created with its default value set to the product name "Python 3.X". |
| 368 | |
| 369 | When the Python standard library is installed, a key "PythonPath" is |
| 370 | created within the root key with its default value set to the full path |
| 371 | to the Lib folder followed by the path to the DLLs folder, separated by |
| 372 | a semicolon. |
| 373 | |
| 374 | When the documentation is installed, a key "Help" is created within the |
| 375 | root key, with a subkey "Main Python Documentation" with its default |
| 376 | value set to the full path to the installed CHM file. |
| 377 | |
| 378 | |
| 379 | The py.exe launcher is installed as part of a regular Python install, |
| 380 | but using a separate mechanism that allows it to more easily span |
| 381 | versions of Python. As a result, it has different root keys for its |
| 382 | registry entries: |
| 383 | |
| 384 | When installed for all users on a 64-bit operating system, the |
| 385 | launcher's root key is: |
| 386 | HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\Launcher |
| 387 | |
| 388 | When installed for all users on a 32-bit operating system, the |
| 389 | launcher's root key is: |
| 390 | HKEY_LOCAL_MACHINE\Software\Python\Launcher |
| 391 | |
| 392 | When installed for the current user: |
| 393 | HKEY_CURRENT_USER\Software\Python\Launcher |
| 394 | |
| 395 | When the launcher is installed, a key "InstallPath" is created within |
| 396 | its root key with its default value set to the launcher's install |
| 397 | directory. File associations are also created for .py, .pyw, .pyc and |
| 398 | .pyo files. |
| 399 | |
| 400 | Launching Python |
| 401 | ================ |
| 402 | |
| 403 | When a feature offering user entry points in the Start Menu is |
| 404 | installed, a folder "Python 3.X" is created. Every shortcut should be |
| 405 | created within this folder, and each shortcut should include the version |
| 406 | and platform to allow users to identify the shortcut in a search results |
| 407 | page. |
| 408 | |
| 409 | The core Python executables creates a shortcut "Python 3.X (32-bit)" or |
| 410 | "Python 3.X (64-bit)" depending on the interpreter. |
| 411 | |
| 412 | The documentation creates a shortcut "Python 3.X 32-bit Manuals" or |
| 413 | "Python 3.X 64-bit Manuals". The documentation is identical for all |
| 414 | platforms, but the shortcuts need to be separate to avoid uninstallation |
| 415 | conflicts. |
| 416 | |
| 417 | Installing IDLE creates a shortcut "IDLE (Python 3.X 32-bit)" or "IDLE |
| 418 | (Python 3.X 64-bit)" depending on the interpreter. |
| 419 | |
| 420 | |
| 421 | For users who often launch Python from a Command Prompt, an option is |
| 422 | provided to add the directory containing python.exe to the user or |
| 423 | system PATH variable. If the option is selected, the install directory |
| 424 | and the Scripts directory will be added at the start of the system PATH |
| 425 | for an all users install and the user PATH for a per-user install. |
| 426 | |
| 427 | When the user only has one version of Python installed, this will behave |
| 428 | as expected. However, because Windows searches the system PATH before |
| 429 | the user PATH, users cannot override a system-wide installation of |
| 430 | Python on their PATH. Further, because the installer can only prepend to |
| 431 | the path, later installations of Python will take precedence over |
| 432 | earlier installations, regardless of interpreter version. |
| 433 | |
| 434 | Because it is not possible to automatically create a sensible PATH |
| 435 | configuration, users are recommended to use the py.exe launcher and |
| 436 | manually modify their PATH variable to add Scripts directories in their |
| 437 | preferred order. System-wide installations of Python should consider not |
| 438 | modifying PATH, or using an alternative technology to modify their |
| 439 | users' PATH variables. |
| 440 | |
| 441 | |
| 442 | The py.exe launcher is recommended because it uses a consistent and |
| 443 | sensible search order for Python installations. User installations are |
| 444 | preferred over system-wide installs, and later versions are preferred |
| 445 | regardless of installation order (with the exception that py.exe |
| 446 | currently prefers 2.x versions over 3.x versions without the -3 command |
| 447 | line argument). |
| 448 | |
| 449 | For both 32-bit and 64-bit interpreters, the 32-bit version of the |
| 450 | launcher is installed. This ensures that the search order is always |
| 451 | consistent (as the 64-bit launcher is subtly different from the 32-bit |
| 452 | launcher) and also avoids the need to install it multiple times. Future |
| 453 | versions of Python will upgrade the launcher in-place, using Windows |
| 454 | Installer's upgrade functionality to avoid conflicts with earlier |
| 455 | installed versions. |
| 456 | |
| 457 | When installed, file associations are created for .py, .pyc and .pyo |
| 458 | files to launch with py.exe and .pyw files to launch with pyw.exe. This |
| 459 | makes Python files respect shebang lines by default and also avoids |
| 460 | conflicts between multiple Python installations. |
| 461 | |
| 462 | |
| 463 | Repair, Modify and Uninstall |
| 464 | ============================ |
| 465 | |
| 466 | After installation, Python may be modified, repaired or uninstalled by |
| 467 | running the original EXE again or via the Programs and Features applet |
| 468 | (formerly known as Add or Remove Programs). |
| 469 | |
| 470 | Modifications allow features to be added or removed. The install |
| 471 | directory and kind (all users/single user) cannot be modified. Because |
| 472 | Windows Installer caches installation packages, removing features will |
| 473 | not require internet access unless the package cache has been corrupted |
| 474 | or deleted. Adding features that were not previously installed and are |
| 475 | not embedded or otherwise available will require internet access. |
| 476 | |
| 477 | Repairing will rerun the installation for all currently installed |
| 478 | features, restoring files and registry keys that have been modified or |
| 479 | removed. This operation generally will not redownload any files unless |
| 480 | the cached packages have been corrupted or deleted. |
| 481 | |
| 482 | Removing Python will clean up all the files and registry keys that were |
| 483 | created by the installer, as well as __pycache__ folders that are |
| 484 | explicitly handled by the installer. Python packages installed later |
| 485 | using a tool like pip will not be removed. Some components may be |
| 486 | installed by other installers (such as the MSVCRT) and these will not be |
| 487 | removed if another product has a dependency on them. |
Martin v. Löwis | 8ffe9ab | 2004-08-22 13:34:34 +0000 | [diff] [blame] | 488 | |