Doug Glenn wrote in a message to All:

 DG> strcpy(PSZFILENAME,"KISOS2.INI");   /* copy INI name to
 DG> PszFileName */ 

 DG> HINI = PRFOPENPROFILE(HAB,PSZFILENAME); /* open file for
 DG> read/write */ 

 DG> printf( "This is what came back %d (HAB) %d (HINI)\n", HAB,
 DG> HINI); 

 DG> /* prints a set of values for HAB, and 0 for HINI */

HAB is not set by the call to PrfOpenProfile(); in fact, it is passed by
value and therefore cannot be modified.  You are supposed to obtain a HAB
value using the WinInitialize() API call when each thread in your PM app
starts up.

If PrfOpenProfile() is returning NULLHANDLE to indicate an error condition
as you are seeing, you should call WinGetLastError() to get details; you
need the HAB associated with your thread as an argument.

What you are dumping for HAB with the call to printf() is just random
garbage which happens to be in the uninitialized variable.

It is likewise good practice to call WinTerminate() before your thread dies.

 DG> rc = PRFQUERYPROFILESIZE(HINI, PSZAPP, PSZKEY, &PDATALEN);

 DG> printf("\nThe return code is %d", rc); /* prints 1 */

The 1 return is a successful completion code from PrfQueryProfileSize(). 
However, you do not say what comes back in *PDATALEN, which is most likely
0 -- which indicates that your requested App-Key combination was not
matched.

Note that you are passing 0 here in HINI, which happens by coincidence to
be the HINI_PROFILE predefined macro (from PMSHL.H), and this is a
legitimate code that signals PrfQueryProfileSize() to search both the user
and system profiles.  These may or may not be defined.

 DG> /* close file */
 DG> rc = PRFCLOSEPROFILE(HINI);
 DG> printf("\n\n\nThe return code is %d", rc); /* prints 0 */

A return code of 0 from PrfCloseProfile() is an error condition which
requires calling WinGetLastError() for details.

 DG>     I know the app and key exist, but I guess I am reading
 DG> the function wrong. I am expecting it to find key and
 DG> function. Yes, the case is correct also.

There are a lot of problems here, both with the C language and the PM API. 
I hope the analysis above points you in the right direction.

 DG>     One last question. Do all the !{at}#$ variables _have_ to
 DG> be in     caps? vs the above ie:
 DG>     HINI hini;
 DG>     HAB hab;
 DG>     char pszApp

No, of course not.  The typedef names have to be in the proper case, but
you are free to name variables anything you want as long as you do not
collide with a C language reserved word such as "int".  The names
are totally lost after compile and link anyway, and are purely human
readable conveniences.  If you want to make definitions such as "HAB
fReD;" and "HINI EtHeL;" this is perfectly legal, although
rather cryptic.

You should also observe the proper case format for OS/2 API calls.  Most of
them, and all of the ones you are using here, are defined to use the pascal
calling convention (APIENTRY) which forces the names to upper case for the
linker, but you should do it right.  You only need to write the API names
in upper case if your compiler is so brain-damaged that it does not
understand the pascal calling convention, in which situation it will be
passing the arguments on the stack backwards anyway.

 DG>     Doggone INF files are a royal pain in the you know what
 DG> to read vs an honest to gosh dead tree. But from what I
 DG> gathered, with the exception of 'char', is has to be in CAPs.

The OS/2 INF files are not intended to document the C language.  If you
want the PM Reference in paper form, you can buy it.  I believe Que
publishes it.  I know it is on the shelf here at the local Barnes &
Noble.
 
-- Mike


---