Announcement

Collapse
No announcement yet.

Static Link Libraries - BYCOPY and other questions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    You DO pass information to Procedures ( or interface METHODs).
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #22
      Define 'information'. Are values not information? Are they not going to the SLL?
      Rod
      In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

      Comment


      • #23
        Originally posted by Rodney Hicks View Post
        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

        Comment


        • #24
          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.
          hutch at movsd dot com
          The MASM Forum - SLL Modules and PB Libraries

          http://www.masm32.com/board/index.php?board=69.0

          Comment


          • #25
            Originally posted by Stuart McLachlan View Post

            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.
            The world is strange and wonderful.*
            I reserve the right to be horrifically wrong.
            Please maintain a safe following distance.
            *wonderful sold separately.

            Comment


            • #26
              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:
              Code:
              #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.
              Rod
              In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

              Comment


              • #27
                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.
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #28
                  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.
                  Rod
                  In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.

                  Comment


                  • #29
                    Originally posted by Rodney Hicks View Post
                    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.
                    The world is strange and wonderful.*
                    I reserve the right to be horrifically wrong.
                    Please maintain a safe following distance.
                    *wonderful sold separately.

                    Comment


                    • #30
                      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.
                      Dale

                      Comment


                      • #31
                        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.
                        hutch at movsd dot com
                        The MASM Forum - SLL Modules and PB Libraries

                        http://www.masm32.com/board/index.php?board=69.0

                        Comment


                        • #32
                          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,
                          Dale

                          Comment


                          • #33
                            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.,,

                            Code:
                            #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

                            Michael Mattias
                            Tal Systems (retired)
                            Port Washington WI USA
                            [email protected]
                            http://www.talsystems.com

                            Comment


                            • #34
                              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))
                              Last edited by Dale Yarker; 12 May 2022, 07:15 PM.
                              Dale

                              Comment

                              Working...
                              X