
The Estimate.xls now in this directory has been updated.

The APICOUNT utility provides API information, but it isn't 
easy to manipulate in that form.  This directory contains information
on how to analyze it.

1. Start with an API file as produced by APICOUNT (foo.api).  The
   extension must be .api
2. 'sno foo' will transform foo.api into a two column text file
   called foo.out.
3. Start up Excel 4.0, and load estimate.xls.  Read in foo.out as
   a text file.  Copy the B column from foo.out over the H column
   in estimate.xls.
4. Cell I5 in estimate.xls will now contain a raw conversion estimate
   for the program.

-------------- More info on Estimate.xls ---------------------------

With multiple api files to estimate, it is usually good to collect
your api info into one file, obtain a total, and 
'Paste Special ... Values' the Total column into H in estimate.xls.

In Estimate.xls you will find:
    Column B -- API Name
           E -- Qualitative estimate of the difficulty to convert.
           F -- Quantitative estimate of difficulty to convert 
                expressed in (# of API's ported / man day).
                These numbers are absolute references to information
                in the range B842:B847.  You may provide your own
                estimates for each classification easily.
           H -- Number of API's called by the module.
		   I -- Amount of time to port, a function of F and H.
           J -- Binary to indicate whether the api was used at all.
		   K -- Is Auto conversion available in os2env\xlate?
		        Note that the conversion may be available in a future
				relase but not in the current one.
		   L -- # API's auto converted.
		   M -- # API's used where conversion availble
		   N -- Time saved with auto conversion.

Other areas on sheet:
B842:B847 -- As listed above, these are where the porting estimate
             figures live.
A830:A840 -- Lists the number of API's used and the percentage of
             API's available.

-------------- Hints ----------------------------------------------

You might try to sort categories in descending order based upon Column J.
This points at the API calls that are likely to give you the most
trouble, or at least have the biggest effect on the estimate.

The macro sheet estimate.xlm has several macros for rearranging things
to taste.

It is entirely possible that for your application, these estimates
are wrong.  The estimates are conservative, but based on a knowledge
of your app you can get a better estimate.  For example, 
consider DosGetShrSeg().

DosGetShrSeg() is listed as Major (1 day / occurrence) not because
it is difficult to obtain shared memory (an hour the first time you
do it, 6 minutes tops after that) but because the nature of shared
memory is different.  Basically, you can't go sticking pointers in
shared memory on NT and expect the algorithm to work.  

[There is a very good reason for this, see the Docs].  So if you are
playing with linked lists in shared memory, you are going to have
to change the structure and rewrite code that walks the structure.
On the other hand, if you just pass blocks of memory around that
doesn't contain pointers, you are done -- no other work to do.




                

