home *** CD-ROM | disk | FTP | other *** search
- SDLS RELEASE 1.03 ERRATA
-
- _____________________________________________________________________________
-
-
- The section describing the macros for writing DLLs in C is incorrect. The way
- the macros work is described below.
-
- The preprocessing for the dll.h and the replacement standard header
- files are controlled by two macros:
-
- _DLL Define (e.g. using -D_DLL at the command line) to
- indicate that we are compiling code to be placed in
- a Dynamic Link Library. Do not define this macro
- if compiling for a statically linked version of the
- library.
-
- Precisely, defining _DLL will cause accesses to
- global SharedCLibrary variables (e.g. stdin or
- errno) to be translated into calls to find the
- address of the client's copy of these variables.
- Also, it enables translation of _dllEntry(name)
- into _dllEntry_name.
-
- _dll_NODLL Define (e.g. using -D_dll_NODLL) to indiciate that
- we should not perform any name translations or use
- DLLLib functions apart from the SWI veneers. Do not
- define if the program being compiled will not be
- using Dynamic Linking at all.
-
- Precisely, defining _dll_NODLL will make the
- following dllLib function calls into no-ops:
-
- * _dll_appspace
- * _dll_clibdata
- * _dll_setname
- * _dll_setjmp
- * _dll_longjmped
- * _dll_giveMemory
-
- It will also make the `safe *command' routines
- _dll_system etc. into direct calls to the `unsafe'
- versions (since we're not using SDLS, it doesn't
- matter). Note that the header file currently uses
- RISC_OSLib routines os_cli and wimp_starttask for
- this: you should change dll.h to use OSLib or DeskLib
- versions of these functions as appropriate.
-
- Finally, it will disable translation of
- _extEntry(name) into _extEntry_name.
-
- Note that _dll_setname is a synonym for dll_nameApp
- invented specifically so that defining _dll_NODLL
- makes it a no-op. It is recommended that you use
- the macro rather than the direct call in your own
- code.
-
- Note that you should never define both of these macros at the same
- time. Typical macro usage is shown in the table below.
-
- Compiling... _DLL _dll_NODLL
-
- code for a DLL defined not defined
- code for a static lib not defined as for client
- client using a DLL not defined not defined
- client not using DLLs not defined defined
-
- _____________________________________________________________________________
-
-
- The syntax for naming DLLs has been extended to allow DLLs to be held in
- directory heirarchies:
-
- The DLL Absolute Name (or DAN) is a way of specifying a DLL's
- name (as described in its header) and the location of its file.
- There are two styles of DANs:
-
- * A new-style DAN has the form [<path prefix>] `[' <DLL name> `]'.
- This unambiguously specifies the DLL name, since it is enclosed
- in square brackets, and provides information about the file's
- location, if this is necessary. If a path prefix is specified,
- the DLL's filename is built simply by prefixing the DLL name with
- the given path prefix. If the prefix is not present, the DLL's
- filename is built by prefixing the DLL name with `DLL:' so that
- it is searched for in the DLLs resource.
-
- * An old style DAN has the form [<path prefix> `.'] <DLL name>.
- If the prefix is specified, the DLL name is assumed to be the
- leafname of the DAN. The DLL's filename is the same as the
- DAN. This is provided for compatibility with older DLLs.
-
- Some examples will hopefully make this clearer:
-
- DAN DLL name Filename
-
- Steel Steel dll:Steel
- [Steel] Steel dll:Steel
- DLLs.MyDLL MyDLL DLLs.MyDLL
- DLLs.[MyDLL] MyDLL DLLs.MyDLL
- MyLib.Events Events MyLib.Events
- [MyLib.Events] MyLib.Events dll:MyLib.Events
- DLLs.[MyLib.Events] MyLib.Events DLLs.MyLib.Events
-
- The following SWIs now accept DANs instead of filenames:
-
- * DLL_Find should be passed a pointer to a DAN in R0.
-
- * The table passed to DLL_FindFromTable should contain pointers
- to DANs.
-
- In addition, the command *DLLEnsure should be passed a DAN as its
- first argument.
-
- Note that cdll from version 1.06 onwards will always generate the
- new-style DANs. We recommend that you always use the new-style
- DANs in your own code, although we plan to remain compatible with
- the old style indefinitely.
-
- _____________________________________________________________________________