mstools/mssetup/setup.wri - view

File: [WindowsNT SDKs] / mstools / mssetup / setup.wri
Revision 1.1.1.3 (vendor branch): download - view: text, annotated - select for diffs
Thu Aug 9 18:27:55 2018 UTC (7 years, 9 months ago) by root
Branches: msft, MAIN
CVS tags: ntsdk-nov-1993, HEAD

Microsoft Windows NT Build 511 (DDK SDK) 11-01-1993

1��_{ //0123 Win32 Application Setup Issues Table of Contents 1. Introduction 1 2. Win32 Applications on Windows NT 2 2.1. Windows NT Security 2 2.2. Windows NT Registry 3 2.2.1. Registry Structure 3 2.2.2. Global Application Configuration 5 2.2.3. User Configuration 6 2.3. Program Manager 7 3. Win32 Applications on Windows 3.1 and Windows NT 9 3.1. Using .ini Files on Windows NT and Windows 3.1 10 4. Win32 Setup Tools 12 4.1. Win32s System Setup 12 4.2. Platform Detection 13 Introduction Setup programs have the responsibility of installing an application's components and configuring any system parameters. Some setup programs for MS-DOS based applications do no more than copy files to the user's hard disk. More complicated MS-DOS and Windows 3.x based setup programs require modification of both MS-DOS and Windows parameters, such as changing config.sys and win.ini. The evolution of personal computing has placed new requirements upon application setup programs. Personal computers are being networked and shared between different users. System security and configuration management are extremely important in this multi-user network environment. Portable code is being developed to run on multiple operating systems and hardware platforms. Graphical user interfaces are becoming more popular as they make applications easier to use. These issues directly affect application setup, which must install securely on different platforms, configure the system for the multi-user environment, and provide an intuitive user interface to facilitate the installation process. Win32 applications may be written for two operating system platforms - Windows NT and Windows 3.1. In addition, Windows NT runs on Intel 386 and 486 based computers as well as RISC platforms such as R4000 ARC-compliant systems and DEC ALPHA based systems. In order to maintain portability, most Win32 code should not depend upon a specific operating system or hardware platform. Setup programs must therefore handle any environmental dependencies before the application is run. For example, a Win32 application may provide both x86 and R4000 binaries in a single package. The setup program must determine which hardware platform it is running and install the appropriate binaries. However, the actual code may have no dependencies on the hardware platform. This document will outline the requirements and establish conventions for Win32 application setup. Both the Windows NT and the Windows 3.1 operating systems will be discussed. Windows NT offers some features and requirements that directly relate to application setup but are not required for Windows 3.1. This document will address the differences and propose recommendations to ensure compatibility on both operating systems. Win32 Applications on Windows NT Windows NT has been designed for the multi-user, network environments. User-level security, networking, and configuration management is built into this operating system. Win32 applications installing on Windows NT must setup securely, be configured for different users, and maintain per-user preferences in this multi-user scenario. Windows NT Security Windows NT implements user level security. This implies that every user has a user-id and password. In Windows NT, a user-id corresponds to a security identifier (SID) which is a unique number used to identify the user. This allows for accountability and access restriction. Resources are protected by access control lists (ACLs), which are conceptually a list of SIDs and the corresponding permissions. Both files and directories are protected through ACLs. Files that are copied into a directory inherit the permissions of the directory by default. New sub-directories also inherit permissions from the parent directory. These permissions may be changed through the File Manager or security APIs. However, applications may be securely installed through a set of conventions without having to use the security APIs or File Manager to modify the ACLs. The applications are securely installed through inherited permissions. Administrators should be encouraged to install their applications into the \WIN32APP directory. ISVs should provide a default path for their application which is a sub-directory of \WIN32APP. Applications stored in this directory will be accessible by all users of the machine. The \WIN32APP directory has been established with the following permissions: Everyone - read and execute permission Administrator - all permissions These permissions imply that only an administrator may install software into this directory. Since users do not have write permission to this directory, shared applications are protected from one user corrupting, deleting, or replacing an application file with a Trojan horse. Although users may install their own software into their own directory, only administrators should have the permission to install securely software that is shared by different users. Independent software vendors (ISVs) encouraged to implement this convention as the default path in their setup programs. Their documentation must also communicate the requirement for an administrator to install the software. By installing into this path, applications gain security without having to modify ACLs through the Win32 security APIs. Since security is provided through inherited permissions, Win32 applications may use the same setup code to create directories and install files on both Windows NT and Windows 3.1. Windows NT Registry The Windows NT registry is a database for all hardware, software, security, and user configuration data. This data includes all of the information that was previously stored in config.sys, autoexec.bat, win.ini, system.ini, and other configuration files that are found on MS-DOS and Windows 3.1 systems. Conceptually, the registry can be thought of as a set of keys and values arranged in a set of trees - like a file system. A key corresponds to a node in the registry. It may have child keys and associated attributes which are called values. Using the file system analogy, the keys are like directories and the values are like files. Applications may modify the registry through an API. This API is completely remoteable through Remote Procedure Call (RPC) which therefore provides a standard interface to perform remote configuration and administration of a Windows NT workstation. Registry keys are protected by ACLs and new keys inherit the permissions of the parent key. Applications running on Windows NT do not have to use the registry. The alternative is to use .ini files as in Windows 3.1. However, the Windows NT registry offers benefits that are important to customers - especially for large, corporate environments. The registry can be accessed through APIs and may not be edited like config.sys or win.ini which reduces the chance of user error. Since this API is remoteable through RPC, the registry provides standardized remote management and administration for all aspects of a Windows NT workstation including hardware, software, security, and performance parameters. A Windows NT network can be configured such that user profiles follow the user from station to station. This user profile includes desktop preferences such as colors and bitmap as well as application preferences. Since the user profile is stored in the registry, the application preferences will follow the user in this scenario. Security may be set on a specific key rather than on the entire .ini file which allows system administrators tighter control of the user's environment. Registry Structure The registry contains four pre-defined roots which should be viewed as the top nodes of their respective trees (see Figure 1). �g1% g1%(@�� 1&��Z��* & ��&$��TNPPMicrosoft PowerPoint&TNPPP & ��&TNPP��Z�j41��45&��&��Z��)��-��-�-)��Z� & ��&��2��9��Arial��-. 2 �l�Security5-,1- & ��&��`@�l��-�-�-�l@�`��Times New Roman-�. 2 �� HKEY_USERSK@@:0F5@@6 & ��&��;I��Arial��-�. 2 ��.Default:,-0 & ��&��(e��ArialW�-�. 2 (� S-0-1-2-345675,---,-,- & ��&��S(��Arial��-�. 2 �� S-1-2-3-456785,---,-,- & ��&��P��X�-�-��"System-��-U�PAP--�'�� & ��&��O��--I�O�-��E--�'�� & ��&��O�--��qO�-E�--�'�� & ��&��O��---��O�-�E��--�'�� & ��&��r��-�-�r��Times New RomanAr-. !2 o$�HKEY_CLASSES_ROOTK@@:0@;@56@50@FE; & ��&��&��Hn��-�-��I;��G��-�-��I;��G� & ��&��(�?k�[��-�-�-� $c�G(�?*�S & �� & ��&��`��-�-�-��`��Times New Romanl-�. !2 o�HKEY_CURRENT_USERK@@:0@F@@@E;0E6@@ & ��&��JM�&��-�-��A��-�-��@�� & ��&��-�-�-� $�� & �� & ��&��EE��ArialW�-�. 2 �K�Description:,-,011 & ��&��@��-�-�-��@��Times New Roman��-�. "2 ��$�HKEY_LOCAL_MACHINEK@@:0;E@@;0U@@K&E@ & ��&��2��ArialW�-�. 2 ml�System5-,,H & ��&��2�5��Arial��-�. 2 �l�Hardware:,1>-- & ��&��2��u��ArialW�-�. 2 8l�Software51>,- & ��&��O��l�a&��--��-��;��-��+��--�'�� & ��&��J_�R--�_��-J��Ja�--�'�� & ��&��_��--�_�:��-��a�--�'�� & ��&��_��--)_��-��a�--�'�� & ��&��_�--�_�s��-a��--�'�� & �� & ��&��v��Arial��-. 2 9L�Classes:,-,-, & ��&��J��3---�3f�J��-i��--�'�� & ��&��8��--H8��-�L��--�'�� & ��&��08�9--�8��-2L�/��--�'�� & �� & ��&TNPP & ��--�� Figure 1: Windows NT Registry - four pre-defined roots. All the information that relates to the physical machine is stored in HKEY_LOCAL_MACHINE. The System child key stores the information required to load the proper device drivers during the boot process. The Security child key stores the user and policy information. The Hardware key contains the information related to the physical devices connected to the machine. The Software key stores software configuration information for all applications installed on the particular machine. HKEY_CLASSES_ROOT stores file association and object linking and embedding (OLE) information. This behavior is the same as Windows 3.1. HKEY_CLASSES_ROOT actually points to the key HKEY_LOCAL_MACHINE \ Software \ Classes. When a user logs on to a Windows NT workstation, the pre-defined root HKEY_CURRENT_USER points to the key corresponding to the SID of this user. The elements beneath this key contain the user profile information, which includes the user's desktop preferences, program manager information, and personal software configuration data. If a user does not have a profile stored on the particular machine, then a copy of the default profile will be provided for them. HKEY_USERS points to the root of all of the user profiles that have been stored on the particular machine. HKEY_CURRENT_USER points to a child key of HKEY_USERS. Figure 1 presents a clear split of the configuration information where the left stores all data that is particular to a specific machine while the right stores all of the user specific data. This separation of configuration information is extremely important to applications installing on Windows NT and Windows 3.1. Figure 2 summarizes the differences. Global Application Configuration User Configuration Same data accessed by all users Each user retains separate data Users may not change data Users may customize data Includes data in: Includes data in: HKEY_LOCAL_MACHINE HKEY_CURRENT_USER HKEY_CLASSES_ROOT Setup during installation Created at run time (if needed) Figure 2. Application versus user configuration in the registry. Global Application Configuration Configuration data that applies to all users of the machine and is available to every user in read-only mode should be stored as global application data. Examples of such data are a path to a help file, list of optional components that were installed, or a list of any installation parameters. Only an administrator should be able to change this data, although all users require this data to find, for example, the help file. This information should be written to the registry during the setup process since an administrator is performing the installation. Specifically, the following global application data should be written to the registry: HKEY_CLASSES_ROOT: File association and OLE information should be written into this key. This is the same as in Windows 3.1. HKEY_LOCAL_MACHINE \ Software \: under this key, create the keys \ <Vendor> \ <Product> \ <Version>. For example, Microsoft Excel Version 4 would create the key HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Excel \ 4.00. Within this key, the following values are recommended for software administration and management purposes. InstallDate: This value should be stored in the 64-bit Windows NT time format. PathName: This value is a fully qualified path string to the executable that initiates the application. SoftwareType: This value is an unsigned char where 1 = application, 2 = device driver, and 3 = system file. HKEY_LOCAL_MACHINE \ Software \ <Vendor> \ <Product> \ <Version> \ Parameters: Values under this key should correspond to the global application parameters. These values are specific different for each application and should address the requirements of the program. For example, a value called HelpFile could represent a fully qualified path to the help file for the application. Data that applies to all users that was previously written to win.ini or any other .ini file in Windows 3.1 should be stored here. User Configuration Some configuration information is different for each user and users must have the permission to update or modify this data. Data written into the global configuration sections described above may be modified by an administrator only. Therefore, user configuration information must be separated from the global data and stored in a section that allows the user to modify the values. Typical examples of user configuration information are a favorite font, last file opened, or position of the window. This information may be different for each user and each user should be able to maintain their own set of these preferences. The following convention should be used to store all user specific configuration data: HKEY_CURRENT_USER \ Software \ <Vendor> \ < Product> \ <Version>: The vendor, product, and version keys should be filled with the appropriate data for the application. This information should not be written during the setup procedure. Since the installation is being performed by an administrator, this data would be stored in the administrator's profile if it was written during setup. This data should be written at run time so that it is written into the user's own profile. Because HKEY_CURRENT_USER points to profile of the user currently logged on to the system, this convention allows each user to store their own preferences. Since this information is not written during setup, there will be no user data the first time a user runs the application. ISVs should therefore provide default values for all of these user preferences which should used if the user data is not defined. FOR AN EXAMPLE OF PROPER REGISTRY USE, PLEASE SEE THE REGMPAD SAMPLE in \MSTOOLS\SAMPLES\REGMPAD. Program Manager In most aspects, the Windows NT Program Manager is very similar to that of Windows 3.1. However, Windows NT has two types of Program Manager groups - common and personal. The differences between the two groups are similar to the differences between global application data and user configuration data since common groups correspond to a Windows NT workstation and personal groups correspond to a particular user. For example, a user that successfully logs on to a Windows NT workstation will see a combination of common and personal program groups. If the same user logs onto a different machine, the user will see the same personal groups with a different set of common groups. Similarly, a second user that logs on to the first machine will see the same set of common groups with his own set of personal groups. Program manager groups and items are stored in the registry. Common groups are stored under the key HKEY_LOCAL_MACHINE \ Software \ Program Groups while personal groups are stored in HKEY_CURRENT_USER \ Program Groups. Only administrators may create, delete, or modify common groups. However, users may copy items out of common groups and place the copy in one of their personal groups. Applications in common groups are therefore secure and users cannot replace them with a Trojan horse. Personal groups also provides flexibility and allows the user to customize the desktop. Applications should create common groups so that all authorized users of a machine can access the software. If personal groups are created, only the administrator will have the program items since the administrator is the current user during setup. Program groups and items are created through Program Manager DDE (Dynamic Data Exchange) functions. These functions are similar to those of Windows 3.1, except that an additional, optional field may be present which specifies whether the group is common or personal. When this parameter is not present, Program Manager will try the operation as a common group. If this fails (i.e. the user is not an administrator), Program Manager will attempt the same operation on a personal group. When the optional type field is specified, an error will be returned if Program Manager is not able to complete the request and the operation will not be attempted on a personal group. These defaults allow existing Windows 3.1 applications to install as common groups if the user installing the software is an administrator. Win32 application may choose to specify explicitly whether a common or personal group is required. Most applications should create common groups, although administrative packages such as network software may install as an administrator's personal group. Other applications may choose not to specify this parameter to maintain completely compatible with Windows 3.1. Win32 Applications on Windows 3.1 and Windows NT Win32s is a set of dynamic link libraries (DLLs) and a virtual device driver (VxD) that allows Win32 applications to run on Windows 3.1. Win32s can be thought of as the Windows 3.1 API expanded to 32-bits, or a subset of the Win32 API that is supported on Windows 3.1. Some Win32 functions will return an error when running on Windows 3.1. For example, Win32s does not provide multiple threads and therefore the Win32 CreateThread function would fail on Windows 3.1. Win32s does provide important benefits to the Windows 3.1 API such as 32-bit memory management and structured exception handling. Applications that are written for both Windows NT and Windows 3.1 must address certain compatibility issues. In terms of software installation, setup must be able to detect the operating system and make adjustments when needed. Although security is not provided in Windows 3.1, Win32 applications may install securely on Windows NT without any additional code if the \WIN32APP directory convention is used. Since this convention only requires setup to create directories and copy files, this method is completely compatible with Windows 3.1. HKEY_CLASSES_ROOT stores file association data for both Windows 3.1 and Windows NT and setup should write this information identically on both platforms. Program Manager DDE is also completely compatible if the group type parameter is not specified. Although Windows 3.1 has only one type of group, the same DDE command will create a common group on Windows NT and a standard group on Windows 3.1. The one remaining compatibility issue is that of software configuration. Windows 3.1. The registry as described above is only available on Windows NT. Windows 3.1 has a subset registry but only has one pre-defined root, HKEY_CLASSES_ROOT, and only allows for one value per key. Win32 applications on Windows 3.1 must therefore access .ini files through profile API calls to store their application and user configuration data. Applications that are targeted for Windows NT should only use the registry to store application configuration. Applications targeted at Windows NT and Windows 3.1 may choose to implement the registry on Windows NT and .ini files on Windows 3.1. This could be accomplished by abstracting the profile or registry API calls into a single DLL, for example config.dll. If setup determines that the operating system is Windows NT, then setup installs the version of config.dll that accesses the Windows NT registry. If setup determines that the operating system is Windows 3.1, then setup installs the profile API version of config.dll. In both these cases, the registry recommendations in section 2.2 should be implemented. Using .ini Files on Windows NT and Windows 3.1 Some ISVs may choose to implement .ini files on both Windows NT and Windows 3.1. In this case, ISVs should still separate their .ini data into global application and user configuration data. Without this separation, applications will not be able to securely store per-user preferences on Windows NT and this is completely compatible with Windows 3.1. This separation corresponds to two .ini files rather than two registry roots as in Windows NT only applications. Figure 3 is similar to figure 2 in comparing global application data to user data, but focuses on .ini files rather than the registry. Global Application Configuration User Configuration Same may be accessed by all users Each user retains separate data Users may not change data Users may customize data Stored with application files in a Stored in a sub directory of the user's sub directory of \WIN32APP home directory Parallel to data in: Parallel to data in: HKEY_LOCAL_MACHINE HKEY_CURRENT_USER Setup during installation Created at run time (if needed) Figure 3. Application versus user configuration for .ini files. For example, the global application configuration file could be called app.ini and should be stored in the \WIN32APP directory. All users would have read access to this file, but only administrators can change the contents and values within this file. Each user maintains their own user preferences in user.ini, which is stored in a sub directory of the user's home directory. This file contains the user preferences and each user of the application has his own copy. Applications should be able to store all of their configuration data in one of these files. Some existing Windows 3.1 applications write data to Windows configuration files such as win.ini. Although Windows NT has a win.ini file for Windows 3.1 compatibility, this file is not secure since some Windows 3.1 applications require users to have write access to this file. In this multi-user environment, if one user corrupts win.ini, the file is corrupted for all users. Applications are therefore discouraged from writing to win.ini. All configuration data should be placed in either the read-only global file app.ini or the per-user file user.ini. By separating configuration data into these two files, the configuration information is secure at the file level when running on Windows NT. In addition, per-user preferences are stored in the user's home directory. The parallelism between app.ini and HKEY_LOCAL_MACHINE will facilitate future migration to the Windows NT registry. Win32 Setup Tools The Win32 SDK currently includes a 32-bit version of the Setup Toolkit. This toolkit provides support for developing setup programs for Win32 applications. Win32s System Setup A 16-bit setup program is required to install the Win32s components on Windows 3.1. Each application running on Windows NT and Windows 3.1 should ship the Win32s DLLs and VxD since this may be the first Win32 application on a particular machine. A complete Win32s setup program with sources is included in the Win32 SDK which may be modified and redistributed. This program should be treated as a sample program which will install the Win32 components and make the necessary changes to the configuration file system.ini. An ISV may append their own application to the end of this setup program that installs their own application files. If an application is implementing a Windows NT specific feature that must be addressed at setup, then the setup program must have a 32-bit component. One way of handling this is to provide two setup programs - one 16-bit that installs Win32s on Windows 3.1, and a 32-bit setup program that runs after Win32s has been enabled. In the case of installing on Windows NT, the 16-bit setup program would detect that Windows NT is running and immediately start the 32-bit setup without installing Win32s. Another approach is to call WinExec to start a 32-bit executable on Windows NT that performs the Windows NT specific functions. If communication is required between 16-bit and 32-bit setup portions, then a DDE conversation may be established. There are many different solutions and the optimal one depends upon the requirements of the specific application. Platform Detection On Intel x86 based machines, Win32 applications may be running on Windows 3.1 or Windows NT. Windows NT also supports R4000 and ALPHA based systems. This level of portability requires setup to be able to distinguish between these various hardware and software platforms in order to make any necessary adjustments. For compatibility reasons, the method of platform detection is different for 16-bit and 32-bit applications. The setup toolkits, however, mask these differences from the setup programs. For 16-bit applications, the GetWinFlags function returns all of the necessary information. This function is a Windows 3.1 function that returns some new flags on Windows NT. The WF_WINNT flag indicates that the system is Windows NT. The CPU_R4000 and CPU_APLHA21064 flags indicate the respective RISC processor. For compatibility, the WF_STANDARD and WF_PMODE flags will always be set on Windows NT and the WF_CPU286 flag will also be set on both RISC platforms. 32-bit applications should use the GetSystemInfo function to determine the hardware platform. The GetVersion function should be used to determine if the Win32 application is running on Windows NT or Windows 3.1. The high bit of the upper word will be 1 if running on Windows 3.1 and 0 if running on Windows NT. The lower word will indicate the version of Windows that is running (e.g. 3.1). is not secure since some Windows��w�s�o�k�g�c�`�\"X,T1P8L$8�w�t�p+ lC h8dA`�\�X TPVLV^ws�o�k�gSc]__[kWmStOvKv�w�s�o�k�g�c�_t[xW�S�O�7K�7 8w8sT8of8km8gs8c�8_�8[9W&9S�9O�9K�9�9w :s�:o�:k�:g�:c#;_4;[�<W�<S=O,=K,=F=wP=s�>o�>k�>g�>cy?_�?[�?W�?S�?O�?K�?�?w�?s@oT@kX@g{@cC_C[�CW�CS�CO�CK�C+DwdDs�Do�Dk(Eg0Ec�E_�E[FWSFS-GO5GK5G�Gw�Gs�Go�Gk HgHc�J_-K[�LW�LSsNO�NK�N�Nw�Ns�No�Rk�Rg�Rc�R_Z[ZXEZT^P^L^�^w�^s>aoOak�ag�ac�b_�b[ucWcS�cO�cK�c�dw�ds�do�dk�dgec>e_Be[�eW�eS�fO�fK�fSgwWgs{go�gk�gg�gcLh_sh[�hW�hS�hO�hK�h�hw�hs�ho�hk�hg�hci_2i[giWkiSriO�iK�i�iw�is�io�jk�jglc l_*l[1lW�lSmO_mK_mfmw�ms�mo�mk�mg�nc�n_�n[�nW2oS3oPGoLGo�owpsrork�tg�tc�u_�u[xW xS�yOzKz3zw=zs�zo�zk�zg�zc_{_�u[xW xS�yOzK��L��zg.h��P�!.�h��P�!��L��zg.�h��P�!.h��P�!��L�L�L�L�L�L�L�L�L�L�L�L.�h��P�!��L�L�L�L�L�L�L�L�L�L�L�L.�h��P�!��L�"�L�L.��h��P�!.h��P�!"@L^L|��L.��h��P�!.��h��P�!��L�|��L.��h��P�!.��h��P�!�LN|��L.��h��P�!.��h��P�!NiL��L.��h��P�!.��h��P�!��L�L=��L.�h��P�!.h��P�!=?L=��L.�h��P�!.hh��P�!L ��L.�h��P�!.hh��P�!��L� ��L.h��P�!.�h��P�!�+ L- C ��L.h��P�!.�h��P�!C �L�L�L�LSLUL~L�L�LsLuL�L.�h��P�!��L��L�LSL.h��P�!.�h��P�!�|L~L�L�LSL.h��P�!.�h��P�!��Leg�LSL.�h��P�!.h��P�!g�7L�788SL.�h��P�!.�h��P�!8�9L�9L�:L�:L�<L�<LS=LU=L�>L�>L�>L3?L.�h��P�!3?g?L�?L�?L�?L@LV@LX@LU=L�>L�>L�>L3?L.�h��P�!X@{@LC�?L�?L@L.�h��P�!.h��P�!CCL�CL�CL�DL�DL�h��P�!.h��P�!�D&EL(EL�EL�ELFLFL�h��P�!.��h��P�!FHL H�EL�ELFL.�h��P�!.h��P�! HHL�J�EL�ELFL.�h��P�!.h��P�!�J�JLpMLrMLqNFL.�h��P�!.h��P�!qNsNL�NL�NL�NFL.h��P�!.�h��P�!�N!RL#RLmTLoTL�XL�XLZLZL��P�!.�h��P�!ZEZL�\�\�^�XL.�h��P�!.h��P�!�^�^Lb_Ld_LZ`L\`LbLbL�dL�dL��P�!.�h��P�! �deLyg{g�g\`L.�h��P�!.h��P�!�g�gL(hLuhL�hL�hL�hL2iLtiLviLNkLPkL�mL.�h��P�!�m�mL0oL2oLGo�hL.h��P�!.�h��P�!Go�oL�oLpL�r�hL.�h��P�!.h��P�!�r�rL�uL�uL�u�hL.h��P�!.�h��P�!�u�wL�wL�yL�yL]{L_{La{L��P�!.�h��P�!f�=�/��2�!�;��(��P�!�z��z��L.��h��P�!.��h��P�!Q)8��/<�D jN �Y�cam �n|uh��P�!Times New RomanTimes New Roman 0Courier New��P�!.hh��P�!

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.