Return to dynlib.def CVS log

Up to [OS/2 SDKs] / os2sdk / demos / examples / dynlink

Annotation of os2sdk/demos/examples/dynlink/dynlib.def, revision 1.1

1.1     ! root        1: 
        !             2: ;dynlib.def
        !             3: ;provides the linker and loader with info about the dll
        !             4: 
        !             5: ; This file needs to specify that segment ETHEL contains NONSHARED data and
        !             6: ; that segment FRED contains SHARED data.  You might think that you could
        !             7: ; say
        !             8: ;      SEGMENTS
        !             9: ;              ETHEL   CLASS 'FAR DATA' NONSHARED
        !            10: ;              FRED    CLASS 'FAR DATA' SHARED
        !            11: ;
        !            12: ; and be done with it. This would be fine except that the
        !            13: ; C compiler generates null segments ETHEL_CONST, ETHEL_BSS, FRED_CONST,
        !            14: ; and FRED_BSS.  These are placed in GROUPS:
        !            15: ;
        !            16: ;     ETHEL_GROUP   GROUP   ETHEL_CONST, ETHEL_BSS, ETHEL
        !            17: ;     FRED_GROUP    GROUP   FRED_CONST, FRED_BSS, FRED
        !            18: ;
        !            19: ; The linker sees the segment definitions in this module first and in the
        !            20: ; sequence given here. If only the non-null segments (FRED and ETHEL)
        !            21: ; were defined here then the linker would be confused by seeing the
        !            22: ; segment definitions for ETHEL_GROUP and FRED_GROUP interspersed
        !            23: ; (when it encountered the definitions of the null segments in the
        !            24: ; C modules).
        !            25: ;
        !            26: ; So......
        !            27: ; Define attributes for all of the segments in your C modules for the dll
        !            28: ; here, in GROUP sequence.
        !            29: 
        !            30: ; In fact, it is possible to get away with only using SEGMENTS to define
        !            31: ; the attributes of the non-default segments.  In this case, there is no
        !            32: ; need to name FRED at all (even at compile-time).  Then, the default
        !            33: ; shared data will be placed in the library's DGROUP and the non-shared
        !            34: ; data will be placed in ETHEL.
        !            35: 
        !            36: 
        !            37: LIBRARY DYNLIB INITINSTANCE    ; required to specify the dynamic lib name
        !            38:                                ; INITGLOBAL = one-time initialization
        !            39:                                ;   i.e. library initialization is run once.
        !            40:                                ; INITINSTANCE = instance initialization
        !            41:                                ;   i.e. library initialization is run
        !            42:                                ;   once for each application that establishes
        !            43:                                ;   a link to it.
        !            44:                                ; default is INITGLOBAL
        !            45: 
        !            46: PROTMODE                       ; protected mode only
        !            47: DATA SHARED                    ; make the default to share data segments
        !            48: 
        !            49: SEGMENTS
        !            50:            ETHEL_CONST CLASS 'FAR_DATA' NONSHARED
        !            51:            ETHEL_BSS   CLASS 'FAR_DATA' NONSHARED
        !            52:            ETHEL       CLASS 'FAR_DATA' NONSHARED
        !            53:            FRED_CONST  CLASS 'FAR_DATA' SHARED
        !            54:            FRED_BSS    CLASS 'FAR_DATA' SHARED
        !            55:            FRED        CLASS 'FAR_DATA' SHARED
        !            56: 
        !            57: EXPORTS PRINTDATA              ; entry point for the dynamic link library

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