Annotation of mstools/mssetup/readme.wri, revision 1.1.1.1
1.1 root 1: 1� � ]4 ~ � � � � � � README.WRI
2:
3: This file contains extra information about the MS Setup 2.0 Toolkit. This information is provided as an update to the User's Manual.
4:
5:
6: Topics:
7: User Manual Updates - Chapter 4 - Using the Disk Layout Utilities
8: User Manual Updates - Chapter 5 - Script Procedures
9: Command Line Arguments to the Setup Toolkit
10: Notes about MS-TEST include file optimizations
11:
12:
13: User Manual Updates - Chapter 4 - Using the Disk Layout Utilities
14:
15: Built-in compression algorithm in DSKLAYT2.EXE --
16:
17: DSKLAYT2.EXE is now built with a compression tool incorporated. By specifying '-ZI' on the command line, this internal compression will be used instead of whatever COMPRESS.EXE tool you might otherwise specify with the -Z switch. The built in compression results in better compression ratios than the SDK compress tool, particularly on binary files such as EXEs and DLLs. The compression time is noticably slower, but the decompression time is only a little slower and usually not significant when reading from floppy drives. The files compressed by this tool are recognized by all the components of the MS Setup Toolkit. This means both as source files referenced in the .INF and as Setup components listed in the .LST file. FILES COMPRESSED WITH THIS INTERNAL TOOL ARE NOT RECOGNIZED BY THE WINDOWS' CONTROL PANEL OR LZEXPAND.DLL. SO DO NOT USE THIS COMPRESSION FOR FONTS, PRINTER DRIVERS, ETC.
18:
19: Having to mix compression schemes can be troublesome; we suggest you have a batch file to launch DSKLAYT2.EXE initially with the '-ZI' option, then remove the special files from the compress directory, and then call DSKLAYT2.EXE again with '-Z COMPRESS.EXE' which will compress only these special files with the SDK compression tool.
20:
21: Command line arguments for Layout and INF file --
22:
23: When specifying a Layout file and/or an INF file on the command line to DSKLAYT2.EXE, do not use just a drive letter and filename (e.g. "c:project.lyt"). Either use just the filename or a complete path which includes the drive letter, colon, root backslash, any necessary subdirectories, and the filename. The latter method is the most foolproof.
24:
25: Comments about the Layout file format --
26:
27: The format of the Layout file generated by DSKLAYT.EXE and read by DSKLAYT2.EXE is very restrictive, and we very strongly suggest that users should use DSKLAYT.EXE rather than their favorite editor to modify these files. The file description lines are sorted alphabetically, and each attribute field is required and has a limited number of valid values. Prefixes and contractions are not recognized. Extra whitespace is not expected. The tools may not handle syntax errors gracefully. If you do edit a Layout file directly, we strongly suggest you keep backup copies of the tool generated files.
28:
29: Comments about size checking problems --
30:
31: If you specify that a source file is to be compressed when it is layed out, but that it is not to be decompressed at installation time, then at installation time you will get an error message claiming that files have been corrupted because the size of the file written doesn't match the size listed in the INF file description line. This is because the Disk Layout Utility uses the size of the original source file to fill the SIZE field of the INF file description line. There are several work arounds to this:
32: You can manually compress your source file in the source tree (so it is compressed before the Disk Layout Utility even sees it), and then turn off compression at layout time for this file.
33: You can manually fix up the SIZE entry in the generated INF file to be that of the compressed file. You will have to do this each time after you run DSKLAYT2.EXE.
34: Your script can call SetSizeCheckMode(scmOff), but this may mask real errors.
35:
36:
37: User Manual Updates - Chapter 5 - Script Procedures
38:
39: Changes to Lookup Table (pages 5-1 to 5-3) --
40:
41: The section 'Query the user's environment' (page 5-3) should also include the API GetWindowsDir.
42:
43:
44: Modified API --
45:
46: CopyFile subroutine
47: Arguments cmo%
48: cmoOverwrite is not a valid flag for this argument. This API will always overwrite an existing file. Use the function DoesFileExist() if you do not want to overwrite an existing destination file. cmoTimeStamp is not useful for this routine; the destination file will always be stamped with the current system time.
49:
50: CreateIniKeyValue subroutine
51: Arguments szKey$
52: Defines the name of the symbol you want to create. If szKey$ already exists and you do not specify cmoOverwrite for the command option flag, this subroutine will do nothing. (It will not fail, it will not display any message, it will just return without taking any action.)
53:
54: DoMsgBox(...) function
55: Arguments wType%
56: SETUPAPI.INC only defines MB_OK, MB_ICONHAND, and MB_TASKMODAL as CONST expressions. If you use any other constants, you will need to define them either in your .MST script or appropriate .INC include file. You can look them up in your WINDOWS.H to find the value they are #defined to, and then add a line such as:
57: CONST MB_YESNO = 4
58:
59:
60: Broken APIs --
61:
62: RemoveDir subroutine
63: This API was broken late in the development cycle and the problem was discovered too late to fix. If you need to remove an existing directory, write your own routine in a DLL (we suggest putting it in the MSCUISTF.DLL) and prototype it in your .MST script or an appropriate .INC include file. Sorry for the inconvenience.
64:
65:
66: Missing APIs --
67:
68: GetExistingFOTFileForTTF function
69: Integer% = GetExistingFOTFileForTTF (szTTFFile$, szBuf$, cbBuf%)
70: Determines whether a specified TrueType Font (TTF) file has an associated FOT file. This is done by extracting the TypeFace name from the TTF file, querying the WIN.INI [fonts] section to determine if there is a FOT file listed, and if there is, extracting the path to the TTF file actually associated with the FOT file and checking to see if it is the same as the specified TTF file.
71: Arguments szTTFFile$
72: Specifies the full path of the TTF file to query.
73: szBuf$
74: Buffer to store path to associated FOT file if one is found.
75: cbBuf%
76: Size of szBuf$. If the return value is longer than this, it will be truncated.
77: Return Value 0 if no associated FOT file otherwise the length of the buffer needed to hold the full path to the FOT file associated with the specified TTF file (return may be greater than, less than or equal to cbBuf%).
78:
79:
80: MakeListFromSectionDate subroutine
81: Exactly like MakeListFromSectionKeys except it produces a list of date fields from an INF section of file description lines. Split files (those with APPEND fields) are not duplicated but rather the field of the final piece is returned.
82:
83: MakeListFromSectionFilename subroutine
84: Exactly like MakeListFromSectionKeys except it produces a list of destination filename fields from an INF section of file description lines. Split files (those with APPEND fields) are not duplicated but rather the destination of the initial piece is returned.
85:
86: MakeListFromSectionSize subroutine
87: Exactly like MakeListFromSectionKeys except it produces a list of size fields from an INF section of file description lines. Split files (those with APPEND fields) are summed together and returned as one entry.
88:
89: MakeListFromSectionVersion subroutine
90: Exactly like MakeListFromSectionKeys except it produces a list of version fields from an INF section of file description lines. Split files (those with APPEND fields) are not duplicated but rather the field of the initial piece is returned.
91:
92: PrependToPath subroutine
93: PrependToPath (szSrc$, szDest$, szDir$, cmo%)
94: Copies szSrc$ to szDest$ and adds szDir$ to any PATH statements found in the file.
95: Arguments szSrc$
96: Full path of file to read as source.
97: szDest$
98: Full path of file to create as destination.
99: szDir$
100: Full directory path to add to any PATH statements.
101: cmo%
102: cmoOverwrite, cmoVital, cmoNone, or cmoAll.
103: Comments If the first line of the file is not a PATH statement, then a simple statement of the form 'SET PATH=<szDir$>' is always added to szDest$ as the first line. For every PATH statement encountered which does not include %PATH%, szDir$ is added to the front of the value associated with PATH. So 'SET PATH=...' becomes 'SET PATH=<szDir$>;...'. There is no attempt to check if szDir$ is already on the PATH or if adding to the PATH will make it too long and create problems for DOS. These checks should be done prior to calling this routine by calling GetEnvVariableValue.
104:
105: SetSizeCheckMode function
106: Integer% = SetSizeCheckMode (scmMode%)
107: Determines whether File Copying will check the resulting length against the SIZE field of the INF file description line during CopyFilesInCopyList.
108: Arguments scmMode%
109: Specifies what the new mode is. Acceptable values are scmOff, scmOnIgnore, and scmOnFatal.
110: Return Value The previous value of the Size Check Mode.
111: Comments scmOff will disable all size checking; scmOnIgnore will generate an error message for mismatches, but the user will be able to ignore this error and continue; scmOnFatal generates an error message that only allows the user to abort.
112:
113:
114:
115: Command Line Arguments to the Setup Toolkit
116:
117: Command line arguments can be passed to the Setup BASIC script by calling _MSTEST.EXE with /C "<command line arguments>" which will set the initial value for the Setup BASIC script global string variable COMMAND$. This is exactly what SETUP.EXE (the bootstrapper program) does. If you look at the CmdLine line in the SETUP.LST, you will see it has the form _MSTEST SAMPLE1.MST /C "/S %s %s". The first %s gets replaced by the original source directory and so the /S switch specifies the source directory to the Setup Toolkit (by default it uses the Current Working Directory which would be incorrect after SETUP.EXE has bootstrapped the setup files to a hard drive.) The second %s is replaced by any command line arguments passed to SETUP.EXE.
118:
119: There are several command line arguments to the Setup Toolkit which you will find useful during development and for the end-user:
120: /? will generate a usage message.
121: /S <src-dir> can be used to set the value of the symbol STF_SRCDIR. This can be very useful during script development when you run _MSTEST.EXE directly rather than through the SETUP.EXE. You can create a network image of your product that does not yet include the Setup files (which will change as you develop them). You can use the /S switch to point at you network image sources without having to copy the new Setup files into the image.
122: /Z <srcfile> <destfile> will copy (and decompress if necessary) one file and then exit the setup program back to Windows.
123: /Y <srcfile> <destfile> will copy (and decompress if necessary) one file but will append to an existing <destfile> and then exit back to Windows. <destfile> must already exist. This will be required if the end-user is manually recreating a split file.
124: /W <srcfile> <destfile> will copy (and decompress if necessary) one file and then exit Windows and return all the way back to DOS. This can be used by a batch file to verify a disk image build has correctly compressed files.
125: /A will cause the symbol STF_MODE to be set to the value "ADMIN". The default value of STF_MODE is "NORMAL". The /A switch is meant to signify that a Network Administrator intends to install your product as a Shared installation on a network node such that several workstations will run the network image without having to physically copied the files to the hard drives of the workstations. You need to inform your clients if you support this mode and your script needs to react accordingly.
126: /N will cause the symbol STF_MODE to be set to the value "NETWORK". This is intended as the second phase of the Shared Application installation. You may want to dispense with this argument and instead have the Admin phase create a special marker such as a particular INI file in the network location which will mean any subsequent installs run from that network image will result in Workstation mode setups. Or you can modify the SETUP.LST file after the Administrator phase to automatically specify this flag.
127:
128: You may specify your own command line arguments, but your MST script must process them out of the COMMAND$ global string variable before you call $INCLUDE 'setupapi.inc', otherwise the unrecognized arguments will generate a Usage message and cause Setup to abort. Also be careful not to remove Setup Toolkit arguments (particularly the /S set).
129:
130:
131:
132: Notes about MS-TEST include file optimizations
133:
134: Just before shipping your product, you can save disk space and execution startup time by editting the MS-TEST include files (.INC) to remove all DEBUG code and unused APIs. Be careful while undertaking the latter that you do not remove too much too fast. The MS-TEST parser will inform you if you do remove too much. Always keep a backup copy of the latest versions of the files that successfully compiled.
135:
136: The symbol table will support string values to a length of 8192 characters, but there is a constant defined in SETUPAPI.INC which further limits this length to 512 characters. If you find this limit is too restrictive, you can relax it by editting the SETUPAPI.INC file (search for cbSymValMax).
137:
138: will set the initial value for the� � w &