Calling a DLL from PBCC

[Pablo A. Daroux]

Hi all,

I am trying to call a DLL from within PBCC5.0 but keep getting Memory Access Violations when calling BAS_LD_StartTranslate. Sorry I am not that familiar with pointers and such. The (very brief) documentation that came with the DLL for calling it using C says:

'int  LD_GetBufferSize();
'    // returns size of data buffer used by translate functions
'
'int  LD_StartTranslate(char *tranfile, void *Buffer);
'    // initialize data for translate

where "tranfile" is the filename to be processed and
Buffer = GlobalAlloc(GPTR, LD_GetBufferSize());

my code is:

#COMPILE EXE
#DIM ALL

DECLARE FUNCTION BAS_LD_GetBufferSize SDECL LIB "c:\lardav\slmutil\translatorv323\LDSlmTranslate.dll" _
                 ALIAS "LD_GetBufferSize" AS LONG
DECLARE FUNCTION BAS_LD_StartTranslate SDECL LIB "c:\lardav\slmutil\translatorv323\LDSlmTranslate.dll" _
                 ALIAS "LD_StartTranslate" (BYVAL tranfile AS DWORD, BYVAL Buffer AS DWORD) AS LONG

#INCLUDE "LD_Structures.INC"

FUNCTION PBMAIN () AS LONG

    DIM theBufferSize   AS LONG
    DIM fName           AS ASCIIZ * 256
    DIM ptr2Bufr        AS DWORD' POINTER
    DIM fnError         AS DWORD

    fName = "c:\lardav\Bin_Test.BIN"
    '
    '   Get the size of the buffer
    '
    theBufferSize = BAS_LD_GetBufferSize ()   ' returns 9899
    '
    '   Dimension the buffer based on the returned value from BAS_LD_GetBufferSize()
    '   // allocate memory for translate DLL internal data
    '
    GLOBALMEM ALLOC theBufferSize TO ptr2Bufr
    '
    '   Call the StartTranslate function to initialize things
    '
    fnError = BAS_LD_StartTranslate ( VARPTR(fName), ptr2Bufr )

END FUNCTION

This compiles just fine but when trying to execute BAS_LD_StartTranslate I get the memory violation exception with the message:
"Program tried to read or write an invalid memory address"

What am I doing wrong?

Thanks in advance

Pablo

[Michael Mattias]

"GLOBALMEM ALLOC theBufferSize TO ptr2Bufr"

... returns what? A pointer to a buffer? Not according to my help file it doesn't.

MCM

[Gösta H. Lovgren-2]

To be fair, the docs appear to use "handle" and "pointer" interchangably.:

GLOBALMEM LOCK:
The moveable memory block referenced by mHndl is locked at a specific memory location. A pointer to this location is assigned to the variable specified by vPtr. You may only read or write the memory block while it is locked, and you use the current pointer to its location.

GLOBALMEM UNLOCK:
The moveable memory block referenced by mHndl is unlocked, and the previous memory pointer is invalidated. If the memory block remains locked (perhaps because it had been locked more than once), the value TRUE (non-zero) is assigned to the result variable vLocked. If the memory block is now unlocked, or the parameter mHndl was invalid, the value FALSE (0) is assigned to vLocked instead.

Now a sophisticated programmer may see a distinct difference between Handlle and Pointer here but to the simple (ahhh... basic) mind, it is a distinction without a difference.

=========================================================
"One of the symptoms of an approaching nervous breakdown
is the belief that one's work is terribly important."
Bertrand Russell (1872-1970)
=========================================================

[José Roca]

To be fair, the docs appear to use "handle" and "pointer" interchangably.

No, they don't. They correctly use handle in the other GLOBALMEM statements and pointer in GLOBALMEM LOCK and GLOBALMEM UNLOCK.

Now a sophisticated programmer may see a distinct difference between Handlle and Pointer here but to the simple (ahhh... basic) mind, it is a distinction without a difference.

Nobody has called me "sophisticated" before, but yes, I can see a distinct difference between Handlle and Pointer here.

[José Roca]

The meaning of handles depend of the context. Regarding the GLOBALMEM functions, they are pointers to pointers. GLOBALMEM ALLOC allocates a moveable block of memory. If it returned to you a pointer to that memory, instead of a pointer to a pointer to that memory, the pointer will become invalid if the memory is moved. As long as the program uses the handle instead of the pointer, the operating system can freely move the data block and update the pointer, and everything will continue to resolve correctly.

But when you need to access the memory, then you need a pointer to that memory, not a handle, and you need to lock it so it isn't moved. This is what GLOBALMEM LOCK does,

[José Roca]

where "tranfile" is the filename to be processed and
Buffer = GlobalAlloc(GPTR, LD_GetBufferSize());

GPTR means fixed memory initialized to zero. When GlobalAlloc is called using this flag, the return value is a pointer, not an handle. GLOBALMEM ALLOC always allocates moveable memory and returns an handle.

So use:

ptr2Bufr = GlobalAlloc(%GPTR, theBufferSize )

instead of GLOBALMEM ALLOC.

[Michael Mattias]

The meaning of handles depend of the context.

No, the meaning of 'handle' does not depend on the context.

Perhaps "how the operating system or compiler product assigns a value to a handle" differs from context to context; but that value is immaterial, since handles must always be treated opaquely by the programmer.

MCM

[Jeff Blakeney]

My understanding of the term "handle" is that it is a pointer to a pointer. This is done so that the pointer to a block of memory and the memory it points to can be moved around by the operating system and your program can continue to access that memory through the handle regardless of where it is.

Some people have started using the word handle incorrectly, in my opinion. For example, PB has what they call "file handles" but it is more of a file index.

[Michael Mattias]

>My understanding of the term "handle" is that it is a pointer to a pointer

Not so.

Microsoft provides this definition....

handle
A value that uniquely identifies something such as a file or data structure. Handles are meaningful only to the software that creates and uses them but are passed by other software to identify things.

.. which is as good as any other. "Unique Identifier" is the short version.

Note that handles have meaning ONLY to the software which assigns them. When GLOBALMEM ALLOC returns a handle, it has meaning ONLY to other GLOBALMEM statements.

When you obtain a PB file handle (eg. ' hFile = FREEFILE') 'hfile' has meaning only to PRINT[#], PUT/PUT$, GET/GET$, LINE INPUT and CLOSE statements.

When you obtain a handle to a window (hWnd = CreateWindowEx() or DIALOG NEW... TO hdlg), that handle has meaning only to other statement requiring a "handle to a window."

DIALOG NEW or CONTROL HANDLE return a handle usable by both DDT and Windows' API functions requiring 'a handle to a window,' but only because the creating software (the PB compiler) says that handle may be used that way.

Never ever ever assume a handle has any meaning beyond its intended use; and use handles only as designed and documented.

And just for the record...
>For example, PB has what they call "file handles" but it is more of a file index.

Not so. It is a handle.. a unique identifier. PB changed way the FREEFILE function assigned file handle values in one version release (7x-8x?). Had you made assumptions about that handle value in your 7x code and wanted to move to the 8x or 9x compiler, you'd still be sucking your thumb trying to figure out why your program doesn't work anymore.

MCM

[Jeff Blakeney]

Well, I suppose I didn't mention the fact that my definition of the term handle comes from my programming the Apple IIgs where they seemed to be a little more careful with terms to try to be less confusing. The way Windows seems to be using the term it can mean a pointer, a pointer to a pointer, a file number, an index into a list of items or pretty much anything which, in my mind, makes the term confusing.

I think I'll stick with my way of thinking so that I don't confuse myself.

[José Roca]

If they were implemented today, they will be called objects

[Michael Mattias]

>If [functions returning handles] were implemented today, they will be called objects

Yup.

> think I'll stick with my way of thinking so that I don't confuse myself

If your way of thinking is "handle=pointer to a pointer" don't do that. Thread and process handles certainly can't be used like that.

"Unique Identifier!"

MCM

[Michael Mattias]

>When GLOBALMEM ALLOC returns a handle, it has meaning ONLY to other GLOBALMEM >statements.

Technically, that's inaccurate.... as documented under GLOBALMEM ALLOC.:

GLOBALMEM ALLOC
A moveable memory block of the size in bytes specified by count is allocated. A unique handle is assigned to this memory object (for later identification). This handle is assigned to the LONG or DWORD variable specified by vHndl. If the requested allocation fails for any reason, the value zero (0) is assigned to vHndl instead.

Since that is a proprietary handle, its underlying data must be part of the runtime library... except the runtime library data are limited to the current code module.

So I should have said ,

"When GLOBALMEM ALLOC returns a handle, it has meaning ONLY to other GLOBALMEM statements in the same code module."

Unless of course the compiler publisher forgot to tell us the GLOBALMEM ALLOC statement returns a WINDOWS-USABLE global memory handle. If this were the case then the handle could be passed as a parameter to a function in another code module.

MCM