Rinat Sadretdinow wrote in a message to Mike Bilow:

 MB> Most of these keywords are useful only with regard to segmented 
 MB> Ring 0 code, such as device drivers, which are technically not 
 MB> supported under LINK386.

 RS> Well. But why device drivers are not supported under LINK386? 
 RS> For example, SIO.SYS has been linked by LINK386 (I guess) and 
 RS> although it is a device driver, it has an ordinary LX 
 RS> structure. And if I cannot link drivers with LINK386 (I still 
 RS> do not believe that, I made my own drivers for the ATM I'm 
 RS> programming for and linked them with LINK386), so which linker 
 RS> should I have to produce such device drivers?

I guess I need to explain my subtle English.  By using the word
"technically," this connotes that IBM officially says that
physical device drivers are not supported under LINK386, and that IBM does
not make any of their own physical device drivers using LINK386, but that
LINK386 actually can be used to make physical device drivers regardless of
what IBM says officially.

The real story is that support for physical device drivers was written into
LINK386, but that it has been traditionally unreliable and is therefore
left undocumented.  The problems are not necessarily in LINK386 itself, but
in some cases are bugs within the OS/2 loader.  As long as the programmer
avoids taking certain kinds of actions, LINK386 will make a working target.
 However, if the programmer does certain kinds of rather ordinary things,
the loader may very well set the wrong addresses when applying fixups.

I own several APARs against LINK386 and the loader.  For example, PJ18521
("OS/2 loader does not load LX-format driver correctly")
basically meant that pointers to code would not work in an LX-format
physical device driver, or at least worked only by coincidence.  Although
this particular APAR was corrected as of FixPack 15, IBM does not seem to
consider LINK386 use with physical device drivers to be a high priority
since the 16-bit LINK remains the officially supported linker for this
purpose.  It would also obviously be unwise to ship a device driver which
only worked if FixPack 15 or later had been installed, and which caused an
Internal Processing Error trap otherwise.

 MB> Some of the keywords simply set attribute bits in the EXE 
 MB> header; see the EXE386.H file in the OS/2 Toolkit for more 
 MB> information, specifically the O32_FLAGS definition.

 RS> There are a number of keywords that can not be found neither in 
 RS> EXE386.H nor in NEWEXE.H. For example ROBASE (ReadOnly BASE) 
 RS> and SYSBASE. What the gain I may have if use these ones?

These are all intended for special kinds of operations which are meaningful
only during the boot process.  Both ROBASE and SYSBASE are actually
modifiers for the BASE statement, which is itself not very useful to the
practical programmer.  You cannot use these things unless your program is
being loaded before swapping is turned on, and even ordinary physical
device drivers are generally loaded after that.  When the kernel is loaded,
some of it needs to be able to come into memory as an image because fixups
are not yet available since these are handled by the kernel.  The kernel,
and only the kernel, will therefore require special flags which control
loading without fixups.

BASEDEV drivers are also loaded under special conditions, but they are
always assumed to be written in such a way that fixups are segment-local,
which is usually not a problem because BASEDEVs are written in small model.
 In cases where fixups are specifically constrained in a BASEDEV, this is
explicitly documented although often with no explanation.  For example,
this is why IORB structures must be allocated in the default near data
segment of a BASEDEV.

 RS> The main reason I am interested in these keywords was the
 RS> question: "how had OS2KRNL been linked? which linker did IBM
 RS> use?" I explored an LX header from OS2KRNL and found it has
 RS> very interesting structure.

This is an interesting question, and you are right in your guess that
OS2KRNL is linked with LINK386.  However, you should also consider the
possibility that certain keywords might be used with LINK386 which cause it
to output a file that can be specially reprocessed by another tool which
you do not have.

> 1) Look, virtual address is 0x00000000, OS2KRNL is a DLL, LINK386 does
> not allow to use base value lower than 0x10000. How did IBM made such
> address?

OS2KRNL is not really a DLL.  The only reason that OS2KRNL has the DLL flag
set is so that idiot users who type "OS2KRNL" at the command
prompt get some sort of reasonable error message instead of bizarre
behavior.  This is true of all device drivers and OS/2 internals, whether
linked in LX- for NE-format.

As for the unusual virtual address, remember that a segment without fixups
but with explicit BASE will be loaded as a raw memory image, and that the
interval between loadable objects will be set by the BASE.  The virtual
base then has only local significance within the segment.  The fact that
PJ18521 could even exist and that OS/2 would still boot tells you a
critical piece of information about what OS2KRNL does not do.

> 2) Segments from 1 to 8 all have *identical* virtual addresses,
> 0x00000000, but LINK386 builds the address of the next segment
> from the address of the previous segment incremented by rounded length
> of the previous segment. How did IBM made such addresses?

Again, an explicit BASE is used to control load position, provided that
fixups are not at issue.  This is documented behavior for LINK386, although
the documentation is very obtuse on the point and this information is of no
practical use as applied to anything other than the kernel.

> 3) The rest segments all have their own, unique addresses, that cannot
> be computed as base of the previous segment plus length of the previous
> segment. How did IBM specify such addresses?

At this point, fixups would be enabled, and the segments are loaded
relative to those fixups.  However, the BASE chain is still in effect.

 RS> I think if IBM uses LINK386 for their OS/2 developing some
 RS> reserved keywords can answer my questions. If IBM uses a
 RS> third-party linker I'd like to know what linker they use and
 RS> where I can obtain it if it's possible.

There is really nothing mysterious about this.  LINK386 will do most of
what is necessary to make the kernel, and it is primarily through
restrictions on what the programmer can do in the first few segments of the
kernel that things are made to work.

 RS> Well, I'd pay some bucks to see OS2KRNL.DEF :-)

I don't think this is possible. :-)

There are a lot of clues in OS2KRNL.SYM with the debugging kernel, however:
you can derive OS2KRNL.MAP, which is pretty handy.
 
-- Mike


---