Definition of a File

The keyword for a file definition is File. A global ID of a file should begin with gid_File_ . Files have to be assigned to modules in the definition block of the module. If a file is not assigned to any module, it is automatically assigned to the root module by the scplinker. A typical definition of a file in the scp projects looks like:

File gid_File_Lib_Dbp
BIN_FILE_BODY;
Name = LIBNAME(dbp);
Dir = gid_Dir_Program;
Styles = (PACKED, UNO_COMPONENT);
RegistryID = gid_Starregistry_Applicat_Rdb;
End

This definition describes the library dbp. The macro LIBNAME is defined in the included file macros.inc. You find there some very important macro definitions:

#ifdef UNX
#define LIBNAME(name) STRING(CONCAT5(lib,name,OFFICEUPD,DLLSUFFIX,.so))
#define LIBSHORTNAME(name) STRING(CONCAT4(lib,name,DLLSUFFIX,.so))
#define LIBVERYSHORTNAME(name) STRING(CONCAT3(lib,name,.so))
#define FILTER_LIBNAME(name) LIBNAME(name)
#define EXENAME(name) STRING(name)
#define PROFILENAME(name) STRING(CONCAT2(name,rc))
#else
#define LIBNAME(name) STRING(CONCAT4(name,OFFICEUPD,DLLSUFFIX,.dll))
#define LIBSHORTNAME(name) STRING(CONCAT3(name,DLLSUFFIX,.dll))
#define LIBVERYSHORTNAME(name) STRING(CONCAT2(name,.dll))
#define FILTER_LIBNAME(name) LIBNAME(name)
#define EXENAME(name) STRING(CONCAT2(name,.exe))
#define PROFILENAME(name) STRING(CONCAT2(name,.ini))
#endif

You can see, that for many different kinds of names exist different macros. LIBNAME(dbp) will be expanded for Solaris-Sparc in a src641 to libdbp641ss.so, but for Windows to dbp641mi.dll. If there is a language dependent name, like for resource files, there are other macro definitions:

File gid_File_Res_Dba
TXT_FILE_BODY;
RESFILE_ALL_LANG(dba);
Dir = gid_Dir_Resource;
Styles = (PACKED);

End

RESFILE_ALL_LANG is also defined in macros.inc. You find there:

#define RESFILE_ALL_LANG(name) \
Name (01) = RESFILENAME(name,01); \
Name (03) = RESFILENAME(name,03); \
Name (07) = RESFILENAME(name,07); \
Name (30) = RESFILENAME(name,30); \
Name (31) = RESFILENAME(name,31); \
Name (33) = RESFILENAME(name,33); \
Name (34) = RESFILENAME(name,34); \
Name (35) = RESFILENAME(name,35); \
Name (37) = RESFILENAME(name,37); \
Name (39) = RESFILENAME(name,39); \
Name (45) = RESFILENAME(name,45); \
Name (46) = RESFILENAME(name,46); \
Name (48) = RESFILENAME(name,48); \
Name (49) = RESFILENAME(name,49); \
Name (81) = RESFILENAME(name,81); \
Name (82) = RESFILENAME(name,82); \
Name (86) = RESFILENAME(name,86); \
Name (88) = RESFILENAME(name,88); \
Name (90) = RESFILENAME(name,90); \
Name (96) = RESFILENAME(name,96); \
Name (99) = RESFILENAME(name,99)

and also RESFILENAME is a macro defined in macros.inc:

#define RESFILENAME(name,lang) STRING(CONCAT4(name,OFFICEUPD,lang,.res))

At the moment there are many macros for different file names, that is would be too much, to desribe here. Take a look into the macros.inc file, and you will find the macro you need.

Back to the definition of File gid_File_Lib_Dbp. Another entry in the definition block defines the directory. In this case the library shall be intalled into gid_Dir_Program. As you can see, this is also a global ID, which has to be defined in the script before the definition of this file. You see, everything in the setup script is defined in these definition blocks.

The next two lines in the definition of gid_File_Lib_Dbp are important for registering the services inside this library to the internal registry:

Styles = (PACKED, UNO_COMPONENT);
RegistryID = gid_Starregistry_Applicat_Rdb;

The second line describes, in which internal registry file, the service shall be registered. This is the global ID gid_Starregistry_Applicat_Rdb, which again has to be defined in this setup script, before the definition of this file. That there is a service to register, shows the style UNO_COMPONENT. All libraries, that want to register a service need this flag.

At the moment there are many flags for files and very often new flags are created or some that are no longer needed are deleted. Here a short description of the available flags:

PACKED: This is the mostly used flag. It says, that the file is zipped into the file f_xyz in the installation set.

ARCHIVE: This is important for files, that are already zipped in the output tree. In the packing process, these files must not be zipped once more, therefore they have to get the flag ARCHIVE.

UNO_COMPONENT: This flag is important for all libraries, that want to register a service. If this flag is set, you also have to define the RegistryID, as shown in the example above.

FONT: This flag marks all font files.

DONT_DELETE: This flag shows, that the file is not deleted, if the Office installation is removed. This is for example important for all fonts.

FONT_WARN_IF_EXISTS: Also a typical font flag. If there is already a font defined with the same name, a dialog box must appear during setup, to ask the user, whether he wants to overwrite the existing font.

OVERWRITE: Overwrite the file, if it already exists, without warning. For example the Shellnew files have this flag.

DONT_OVERWRITE: Do not overwrite the file, if it already exists, for example in one of the Windows system directories.

DELETE_ONLY: This is important for a deinstallation of the Office. This file definition block describes a file, that does not exist during setup, but is created by the Office. This flag shows, that this new created file, shall also be deleted during the deinstallation.

CHECK_TIMESTAMP: This flag is also only important for the deinstallation and the DELETE_ONLY flag. If this flag is set, the installation date is also controlled before deleting the file.

PATCH: Files containing this flag are included into a patch product. For more information please look at Understanding the PATCH flag.