Bin2Obj - Binary to object file conversion utility for OS/2


Introduction

This simple programers' utility converts a binary file to an object file 
which can be linked with other object files. This allows you to place any set 
of bytes into your executable module, which can be accessed with an 
"external" name you choose.

Borland used to (and may still) ship such a utility with their compilers. 
I've missed it a little bit since moving to OS/2 and the IBM CSet compiler.

You might wonder why this utility is needed since one can use RESOURCE
statements in an RC file for a similar purpose. The answer is that
BIN2OBJ is not strictly necessary, but it can be a little easier and
more efficient than RC. First, it's easier because you can "compile"
your binary file directly, without having to prepare an RC source.
Second, it's more efficient because you don't need to make any API call
(DosGetResource); the resource is available using a conventional memory
access.


Installation

This tool consists of one executable, BIN2OBJ.EXE; this documentation,
README.TXT; and optional examples in EXAMPLES.ZIP. To use the utility,
place BIN2OBJ.EXE somewhere in your PATH.


Usage

The following usage text is available by running BIN2OBJ without arguments.

Usage: BIN2OBJ [options] binfile symbolname [objfile]

   binfile    = name of the existing binary file.
   symbolname = symbolic name used in the object file.
   objfile    = name of the new object file; if not present.
                  the object file name will be same as the
                  binfile with an .obj extension.
   options    = any of the following:
     -n       = size of the binfile, as 32-bit value, will be put in front
                  of the binary block so it's size can be queried.
     -sName   = name of the segment; by default it is 'DATA32'.
     -cClass  = class of the segment; by default it is 'DATA'.
                  The recommended classes are 'DATA', 'CONST', or 'CODE'.


Examples

I've provided an example package EXAMPLE.ZIP. To use it, unzip that file in a 
convenient directory so you can delete the files later. EXAMPLE.CMD executes
BIN2OBJ and then compiles and links using the CSet compiler ICC.

[Although I'm not familiar with the other OS/2 compilers, they almost
certainly can compile and link, and can accept .OBJ files for linking.
To use your compiler name, change the "CC = icc" line in the .CMD file.]

See EXAMPLE.CMD for the use of BIN2OBJ, and EXAMPLE.C for the use of
BIN2OBJ's object files in C. The object files generated by BIN2OBJ
should be useable in any language implementation permitting linkage,
including C++ and assembler.


Compatibility

The object file produced by BIN2OBJ is compatible with LINK386.EXE, provided 
with OS/2. It will not be compatible with 16-bit linkers, and it is not known 
if it is compatible with other 32-bit linkers. However, it is highly likely 
that BIN2OBJ object files will be acceptable to any 32-bit OS/2 linker 
compatible with the IBM OS/2 Object Module Format (OMF). Executables linked 
with a BIN2OBJ object file were tested using IBM CSet++ 2.1. It was not 
tested with other compilers, but it is highly likely it will work with any 
32-bit compiler or assembler which can link with OS/2 OMF object files.


Distribution

BIN2OBJ.EXE, and the accompanying documentation and example files, are
Copyright 1996 by Peter Kobak. This set of files may be freely
distributed and used, but

1) This entire package, unchanged, must be distributed together.

2) You may not charge anything for this utility separately, nor include
it as part of a "commercial", "shareware", or other for-fee product.
However, the files _produced_ by BIN2OBJ may be used without
restriction.

3) Point 2 does not preclude nominal fees charged for common
distribution schemes, such as large collections of "shareware" and
"freeware" on diskettes or CDROMs, and on-line charges for electronic
distribution.

4) This package is provided "as-is" - in other words, it may not work
correctly, and even if it causes you financial harm, Peter Kobak will
not be held responsible.


Peter Kobak
kobak@voicenet.com
3/8/96