Static Link Libraries - BYCOPY and other questions

[Michael Mattias]

You do NOT "pass information to a SLL" (or DLL for that matter).

You DO pass information to Procedures ( or interface METHODs).

[Rodney Hicks]

Define 'information'. Are values not information? Are they not going to the SLL?

[Stuart McLachlan]

Define 'information'. Are values not information? Are they not going to the SLL?

Pedantry? It's like quibbling that you don't store a file on a disk, you store it in a directory

[Steve Hutchesson]

I would be far more interested is seeing some published SLL modules than waffle about how they should be written. With all the noise, the yield is very small, when will someone deliver ?

Hmmmm, I wonder what happened to my signature ? Aha, its turned up again.

[Kurt Kuzba]

Pedantry? It's like quibbling that you don't store a file on a disk, you store it in a directory

It is a point, though.
Once compiled, there is no difference between a linked procedure and one in the compiled source.
They do lack references to UDTs defined in the source, but if they are UDTs also used by the SLL,
then they will already be defined within that source code.
That really is the entire idea behind linked libraries, that they function the same as your compiled source.
It may be a level of understanding not required for most users, of course.

[Rodney Hicks]

Once compiled, there is no difference between a linked procedure and one in the compiled source.
They do lack references to UDTs defined in the source, but if they are UDTs also used by the SLL,
then they will already be defined within that source code.

My point was that a UDT created for some SLL that returns results to the main program via that UDT also has to be defined in the main program. For UDTs included in the compiler it is not necessary, and most others can be included by $INCLUDEing the WinAPI32.inc.
An example:

#COMPILE SLL
#DIM ALL

TYPE SIDEANGLE
  length    AS DOUBLE
  oppangle  AS DOUBLE
  opprdns   AS DOUBLE
END TYPE

TYPE TRIANGLE
  A AS SIDEANGLE
  B AS SIDEANGLE
  C AS SIDEANGLE
END TYPE

DECLARE FUNCTION Radians(angleindegrees AS DOUBLE) COMMON AS DOUBLE

SUB AngleSideAngle(ang1 AS DOUBLE, leng AS DOUBLE, ang2 AS DOUBLE, tasa AS TRIANGLE) COMMON
  tasa.A.oppangle   = ang1
  tasa.A.opprdns    = Radians (ang1)
  tasa.B.oppangle   = ang2
  tasa.B.opprdns    = Radians (ang2)
  tasa.C.oppangle   = 180- tasa.A.oppangle- tasa.B.oppangle
  tasa.C.opprdns    = Radians (tasa.C.oppangle)
  tasa.C.length     = leng
  tasa.A.length     = tasa.C.length/SIN(tasa.A.opprdns)/SIN(tasa.C.opprdns)
  tasa.B.length     = tasa.C.length/SIN(tasa.B.opprdns)/SIN(tasa.C.opprdns)
END SUB

The two TYPE definitions from this SLL have to be included in the main program so the SLL can be accessed from the main program even though this code compiles as an SLL.

[Michael Mattias]

The two TYPE definitions from this SLL have to be included in the main program so the SLL can be accessed from the main program even though this code compiles as an SLL.

Actually, the two TYPE definitions used in the PROCEDURE have to be included in the main program so the PROCEDURE can be accessed from the main program.

Well, actually, were the procedure defined such that you don't need the TRIANGLE structure and instead used three DOUBLE precesion variables (the members) instead of the structure, you would not need the TRIANGLE structure in the main program and your library procedure would be more portable.

Precompiled code - EXE's, DLLs and SLLs - contain only procedures.

[Rodney Hicks]

Actually, the two TYPE definitions used in the PROCEDURE have to be included in the main program so the PROCEDURE can be accessed from the main program.

They are used in the PROCEDURE(chicken) in the SLL(egg). You can't get into the SLL to call the PROCEDURE without the TYPE definitions.Facetious or what?
Precompiled SLLs can contain COMMON SUBS and FUNCTIONs, and COMMON CLASSES and OBJECTS according to the documentation. See

Creating a Static Link Library

The TRIANGLE udt returns 9 values, the length of the three sides, the three angles in both degrees and radians so three doubles aren't enough, but yes, it could have been done differently.

[Kurt Kuzba]

My point was that a UDT created for some SLL that returns results to the main program via that UDT also has to be defined in the main program. For UDTs included in the compiler it is not necessary, and most others can be included by $INCLUDEing the WinAPI32.inc.

Your point is correct.
Have you tried to compile as SSL with an undefined UDT being used?
It won't compile, will it?
So, you cannot pass a UDT, that the SSL doesn't use or know about, and expect it to work properly.

[Dale Yarker]

Over discussion of obvious???? (running since post 15, or about half the trad.)

For every separate compile to EXE, DLL or SLL the compiler needs to know the "construction" of the variable types used and/or passed.

"Construction" of LONGs, DWORDs, STRINGs, etcetera, etcetera is built into the compiler. By definition the "construction" of User Defined Types (UDTs) is not built into the compiler. Therefore, every separately compiled module must have a TYPE/END TYPE for every UTD variable(s) type used in that module.

[Steve Hutchesson]

Outside of the normal binary isolation (caller cannot see inside an SLL and an SLL cannot see inside its caller, what's the difference between a calling source and the contents of an SLL ?

A rhetorical question, there isn't any. They are both basic code and as long as you don't mix compiler specific code (PBWIN versus PBCC specific code), you do the normal things where visibility across files is not available, you make sure that data passed to the SLL as arguments can be read by the SLL and if its a structure (UDT) or any other data type, you must have either the prototypes (declarations) or data types defined in both caller and SLL.

This has been normal technology with libraries for a very long time across different brands and compiler/assembler types.

[Dale Yarker]

Thread subject was solved.

More interesting (to me at least) is use of GLOBALs between EXE, DLL(s) or SLL(s).

Someone might be tempted to declare a global with the same variable name and expect the value to be shared between modules. As noted already, it won't of course.

But if in another module a GLOBAL pSameName AS whatevertype PTR
and pointer of original global is passed, then the other module can access the value with @ or PEEK/POKE.

Cheers,

[Michael Mattias]

and pointer of original global is passed, then the other module can access the value with @ or PEEK/POKE.

And how do you pass that pointer? You pass the variable by reference to a PROCEDURE

There actually is another way, which is to create a named memory object e.g.,,

#COMPILE SLL

$OBJECT_NAME = "ABCDEFG"
%OBJECT_SIZE  =  1028&

FUNCTION CreateMMF ()

LOCAL szFileName AS ASCIIZ * %MAX_PATH

szFileName =  $OBJECT_NAME

     hFileMapping     = CreateFileMapping (%INVALID_HANDLE_VALUE,  BYVAL %NULL, %PAGE_READWRITE , %NULL, %OBJECT_SIZE, szFileName)

     Put some values into the mapped object
     DO NOT CLOSE THE HANDLE

END FUNCTION

Now in your main program, after calling the CreateMMF() function (procedure) in the SLL you can simply "OpenFileMapping" or even "CreateFileMapling" using the same $OBJECT NAME.

It would not be too dissimilar from sharing memory this way across processes, as demo'd here..

Win32: Memory Mapped Files/Control User Count April 26, 2001

Clearly I have not fleshed this out all the way - for example I have not made a provision to close the File Mapping object. But the point is, you could create a reuseable library to share memory using any of the mechanisms which are used to share memory across processes. Or for that matter, sharing across threads using Thread Local Storage.


MCM

[Dale Yarker]

Oops.

in SLL or DLL for GLOBAL in EXE code:

GLOBAL gpMyNumber AS LONG PTR 'for example
SUB SetGlobal(BYVAL LP AS LONG PTR) COMMON (or EXPORT)
gpMyNumber = LP
END SUB

in EXE code:
GLOBAL A_Number AS LONG
probably in MAIN()
SetGlobal(VARPTR(A_Number))