utils.doc

一些网络上用到的知识

   BINOBJ  <source[.BIN]>  <destination[.OBJ]>  <public name>

where source is the binary file to convert, destination is the
name of the .OBJ to be produced, and public name is the name of
the procedure as it will be declared in your pascal program.

The following example, the procedure ShowScreen, takes a pointer
as a parameter and moves 4000 bytes of data to screen memory. The
file called MENU.DTA contains the image of the main menu screen
(80 * 25 * 2 = 4000 bytes).

Here's a simple (no error-checking) version of MYPROG.PAS:

   program MyProg;

   uses Crt;

   procedure ShowScreen(ScreenData : Pointer);
   { Display a screenful of data--no error-checking! }
   var
     ScreenSegment: Word;

   begin
     if (Lo(LastMode) = 7) then      { Mono? }
       ScreenSegment := $B000
     else
       ScreenSegment := $B800;
     Move(ScreenData^,               { From pointer }
      Ptr(ScreenSegment, 0)^,        { To video memory }
      4000);                         { 80 * 25 * 2 }
   end;

   var
     MenuP : Pointer;
     MenuF : file;
   begin
     Assign(MenuF, 'MENU.DTA');      { Open screen data file }
     Reset(MenuF, 1);
     GetMem(MenuP, 4000);            { Allocate buffer on heap }
     BlockRead(MenuF, MenuP^, 4000); { Read screen data }
     Close(MenuF);
     ShowScreen(MenuP);              { Display screen }
   end.


The screen data file (MENU.DTA) is opened and then read into a
buffer on the heap. Both MYPROG.EXE and MENU.DTA must be present
at run-time for this program to work. You can use BINOBJ to
convert MENU.DTA to an .OBJ file (MENUDTA.OBJ) and tell it to
associate the data with a procedure called MenuData. Then you can
declare the fake external procedure MenuData, which actually
contains the screen data. Once you link in the .OBJ file with the
$L compiler directive, MenuData will be 4000 bytes long and
contain your screen data. First, run BINOBJ on MENU.DTA:

   binobj MENU.DTA MENUDTA MenuData

The first parameter, MENU.DTA, shows a familiar file of screen
data; the second, MENUDTA, is the name of the .OBJ file to be
created (since you didn't specify an extension, .OBJ will be
added). The last parameter, MenuData, is the name of the external
procedure as it will be declared in your program. Now that you've
converted MENU.DTA to an .OBJ file, here's what the new
MYPROG.PAS looks like:

   program MyProg;

   uses Crt;

   procedure ShowScreen(ScreenData : Pointer);
   { Display a screenful of data--no error checking! }
   var
     ScreenSegment: Word;
   begin
     if (Lo(LastMode) = 7) then             { Mono? }
       ScreenSegment := $B000
     else
       ScreenSegment := $B800;
     Move(ScreenData^,                      { From pointer }
      Ptr(ScreenSegment, 0)^,               { To video memory }
      4000);                                { 80 * 25 * 2 }
   end;

   procedure MenuData; external;
   {$L MENUDTA.OBJ }
   begin
     ShowScreen(@MenuData);                 { Display screen }
   end.

Notice that ShowScreen didn't change at all, and that the ADDRESS
of your procedure is passed using the @ operator.

===================================
 4. Using TPUMOVER, the Unit Mover
===================================

When you write units, you want to make them easily available to any
programs that you develop. We'll now show you how to use TPUMOVER to
remove seldom-used units from TURBO.TPL, and how to insert often-used
units into TURBO.TPL.


 A Review of Unit Files
========================

There are two types of unit files: .TPU files and .TPL files. When you
compile a unit, Turbo Pascal puts the resulting object code in a .TPU
(Turbo Pascal Unit) file, which always contains exactly one unit.

A .TPL (Turbo Pascal Library) file, on the other hand, can contain multiple
units. For example, several units that come on your Turbo Pascal disks
are in the file TURBO.TPL. The file TURBO.TPL is currently the only
library file Turbo Pascal will load units from.

You may have noticed, though, that you can use the standard Turbo Pascal
units without giving a file name. That's because these units are stored in
the Turbo Pascal standard unit file--TURBO.TPL on your distribution disk.
Because the units are in that file, any program can use them without
"knowing" their location.

Suppose you have a unit called TOOLS.TPU, and you use it in many different
programs. Though adding Tools to TURBO.TPL takes up memory (TURBO.TPL is
automatically loaded into memory by the compiler), adding it to the
resident library makes "using" Tools faster because the unit is in memory
instead of on disk.

There are five standard units already in TURBO.TPL: System, Overlay,
Printer, Crt, and Dos.


 Using TPUMOVER
================

You can use several command-line parameters that let you manipulate units
quickly. The syntax for these parameters is

   TPUMOVER filename operations

where filename is either a .TPU file or a .TPL file,
      and operations is an optional list of one or more of the following
      commands:

         +unitname    Add a unit to the library.
         -unitname    Delete a unit from the library.
         *unitname    Extract a unit from the library.

If no operations are specified, TPUMOVER lists the units in the library
file along with size and dependency information.


=================================
 5. The Stand-Alone MAKE Utility
=================================

This section contains complete documentation for creating makefiles and
using MAKE.


 Creating Makefiles
====================

A makefile contains the definitions and relationships needed to help MAKE
keep your program(s) up to date. You can create as many makefiles as you
want and name them whatever you want. If you don't specify a makefile when
you run MAKE (using the -f option), then MAKE looks for a file with the
default name MAKEFILE.

You create a makefile with any ASCII text editor, such as Turbo Pascal's
built-in interactive editor. All rules, definitions, and directives end
with a carriage return; if a line is too long, you can continue it to the
next line by placing a backslash (\) as the last character on the line.

Whitespace--spaces and tabs--is used to separate adjacent identifiers (such
as dependencies) and to indent commands within a rule.

Creating a makefile is almost like writing a program--with definitions,
commands, and directives. 

 Comments
----------

Comments begin with a number sign (#); the rest of the line following the #
is ignored by MAKE. Comments can be placed anywhere and never have to start
in a particular column.


 Explicit Rules
----------------

Explicit rules take the form

   target [target ... ]: [source source ... ]
      [command]
      [command]
      ...

where target is the file to be updated, source is a file upon which target
depends, and command is any valid MS-DOS command (including invocation of
.BAT files and execution of .COM and .EXE files).

Explicit rules define one or more target names, zero or more source files,
and an optional list of commands to be performed. Target and source file
names listed in explicit rules can contain normal MS-DOS drive and
directory specifications, but they cannot contain wildcards.

Syntax here is important. target must be at the start of a line (in column
1), and each command must be indented (preceded by at least one space
character or tab). As mentioned before, the backslash (\) can be used as a
continuation character if the list of source files or a given command is
too long for one line. Finally, both the source files and the commands are
optional; it is possible to have an explicit rule consisting only of

   target [target ...] followed by a colon.

The idea behind an explicit rule is that the command or commands listed
will create or update target, usually using the source files. When MAKE
encounters an explicit rule, it first checks to see if any of the source
files are target files elsewhere in the makefile. If so, those rules are
evaluated first.

Once all the source files have been created or updated based on other
explicit (or implicit) rules, MAKE checks to see if target exists. If not,
each command is invoked in the order given. If target does exist, its time
and date of last modification are compared against the time and date for
each source. If any source has been modified more recently than target, the
list of commands is executed.

A given file name can occur on the left side of an explicit rule only once
in a given execution of MAKE.

Each command line in an explicit rule begins with whitespace. MAKE
considers all lines following an explicit rule to be part of the command
list for that rule, up to the next line that begins in column 1 (without
any preceding whitespace) or up to the end of the file. Blank lines are
ignored.

An explicit rule, with no command lines following it, is treated a little
differently than an explicit rule with command lines.

   o If an explicit rule exists for a target with commands, the only files
     that the target depends on are the ones listed in the explicit rule.

   o If an explicit rule has no commands, the targets depend on the files
     given in the explicit rule, and they also depend on any file that
     matches an implicit rule for the target(s).

Here are some examples of explicit rules from a makefile:

   myutil.obj: myutil.asm
     tasm myutil.asm,myutil.obj;

   myapp.exe:  myapp.pas myglobal.tpu myutils.tpu
     tpc myapp /Tc:\tp5\bin

   o The first explicit rule states that MYUTIL.OBJ depends upon
     MYUTIL.ASM, and that MYUTIL.OBJ is created by executing the given
     TASM command.

   o The second rule states that MYAPP.EXE depends upon MYAPP.PAS,
     MYGLOBAL.TPU, and MYUTILS.TPU, and is created by the given TPC
     command. (The /T plus path name in these examples will be explained
     later.)

If you reorder the rules so that the one for MYAPP.EXE comes first,
followed by the others, MAKE will recompile (or reassemble) only the files
that it has to in order to update everything correctly. This is because a
MAKE with no target on the command line will try to execute the first
explicit rule it finds in the makefile.


 Implicit Rules
----------------

MAKE also allows you to define implicit rules, which are generalizations of
explicit rules. Here's an example to illustrate the relationship between
the two types. Consider this explicit rule from the previous sample
program:

   myutil.obj: myutil.asm
     tasm myutil.asm,myutil.obj;

This rule is a common one, because it follows a general principle: An .OBJ
file is dependent on the .ASM file with the same file name and is created
by executing TASM (Turbo Assember). In fact, you might have a makefile
where you have several (or even several dozen) explicit rules following
this same format.

By redefining the explicit rule as an implicit rule, you can eliminate all
the explicit rules of the same form. As an implicit rule, it would look
like this:

   .asm.obj:
     tasm $*.asm,$*.obj;

This rule means, "any file ending with .OBJ depends on the file with the
same name that ends in .ASM, and the .OBJ file is created using the command

   tasm $*.asm,$*.obj

where $* represents the file's name with no extension." (The symbol $* is a
special macro and is discussed in the next section.)

The syntax for an implicit rule follows:

   .source_extension.target_extension:
     {command}
     {command}
     ...

Note the commands are optional and must be indented. The source_extension
(which must begin in column 1) is the extension of the source file, that
is, it applies to any file having the format

   fname.source_extension

Likewise, the target_extension refers to the the file

   fname.target_extension

where fname is the same for both files. In other words, this implicit rule
replaces all explicit rules having the format