Q58688: Why the First Module in the Code Segment Starts at Offset 16

Article: Q58688
Product(s): See article
Version(s): 3.x 4.06 4.07 5.01.21 5.03 | 5.01.21 5.03
Operating System(s): MS-DOS | OS/2
Keyword(s): ENDUSER | s_c s_quickc s_quickasm h_masm h_fortran | mspl13_basic
Last Modified: 14-FEB-1990

Question:

Under some circumstances, I get 16 zero bytes at the beginning of my
code segment. I'm linking with my own replacement C library with
start-up code. The entry point to this start-up module is the first
item in the module, and it always ends up at offset 16. Why is this?

Response:

The linker will insert 16 bytes at the beginning of the code segment
if it determines that you are using standard segment naming
conventions (/MS-DOSSEG) and the NULL segment is not explicitly
removed (/NONULLSMS-DOSSEG). In your case, the linker assumes that you
need support for signal() and allocates the first 16 bytes for it.

Note: This will always be done for C programs by the compiler.

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Copyright Microsoft Corporation 1986-2002.