Cannot Load 16-bit API Interface

Cannot Load 16-bit API Interface

Post by Jeff Bake » Thu, 11 Jul 1996 04:00:00



I'm getting a strange problem in FPD2.6a.  Everything works fine in
the development version but if I run the same EXE with the extended
run-time library I consistently receive "Cannot load 16-bit API
interface" from Foxpro.  I'm trying to load a PLB when this error occurs.

The Foxpro help file suggests that FOXPRO.EXE is corrupt.  It mentions
nothing about the run-time libraries.  Any suggestions?

 
 
 

Cannot Load 16-bit API Interface

Post by George Sext » Fri, 12 Jul 1996 04:00:00



>I'm getting a strange problem in FPD2.6a.  Everything works fine in
>the development version but if I run the same EXE with the extended
>run-time library I consistently receive "Cannot load 16-bit API
>interface" from Foxpro.  I'm trying to load a PLB when this error occurs.

Check the help for DOSMEM=ON or OFF.  If you have it set the wrong way
it can prevent API libraries from loading.  This command is in the
CONFIG.FP file.

 George Sexton
 http://www.mhsoftware.com
 MH Software, Inc.

 
 
 

Cannot Load 16-bit API Interface

Post by Larry Keb » Tue, 16 Jul 1996 04:00:00


Hello,
  Has anyone out there ever encountered this problem:

An API function begins to return the wrong return value type to the calling FP
program? In both of the examples I have seen, the functions returned a logical
T. to the program, when in one case it should have returned a character
string, and in the other, the return value should have been numeric. The first
case was one of GPLIB's functions, I don't remember which. The other (which I
am experiencing now) is Black&White's Dr. Switch drshell() function. I
originally thought that there seemed to be a correlation between low DOS
memory, and this problem, but that doesn't seem to be the case now.
----
     |    Larry Keber              They'll take away my CLI when they pry my

o==///:========================-
 `-- | GCS d? s++:-- a29 C+++ UL+ P L+>+++ E>+++ W+ N++(+++) K- w--- O++ M--

 
 
 

Cannot Load 16-bit API Interface

Post by George Sext » Wed, 17 Jul 1996 04:00:00



>An API function begins to return the wrong return value type to the calling FP
>program? In both of the examples I have seen, the functions returned a logical
>T. to the program, when in one case it should have returned a character
>string, and in the other, the return value should have been numeric. The first
>case was one of GPLIB's functions, I don't remember which. The other (which I
>am experiencing now) is Black&White's Dr. Switch drshell() function. I
>originally thought that there seemed to be a correlation between low DOS
>memory, and this problem, but that doesn't seem to be the case now.

I seem to remember that one of GPLIB's functions had a problem causing
it to return logicals when it should have returned numerics.
Basically under the LCK if you don't explicitly  return a variable it
returns a logical.  For example:

void FoxFunc(ParamBlk FAR *p)
{
int n;
if (p->pCount<1)
        return;
else
        n=3;
_RetInt(n,6);

Quote:}

In the sample code, FoxFunc will return a Logical if p->pCount (the
parameter count) is 0.

 George Sexton
 http://www.mhsoftware.com
 MH Software, Inc.

 
 
 

Cannot Load 16-bit API Interface

Post by Larry Keb » Wed, 17 Jul 1996 04:00:00


Quote:

> I seem to remember that one of GPLIB's functions had a problem causing
> it to return logicals when it should have returned numerics.
> Basically under the LCK if you don't explicitly  return a variable it
> returns a logical.  For example:

In the original instance I saw the problem, it worked fine on some machnes, and
not on others. Once the user freed up some memory, etc, and tried again, it
worked. Likewise at the moment, with drshell(), it works just fine on many
machines and only a couple experience the problem.  I still haven't had time to
completely examine ther machines' configurations yet to look for what is
different between them. I, also, seem to remember some of my own LCK code
behaving the same way, but I think I was doing something wrong at the time (a
couple of years ago).

LArry