How to use #LINK ?

[Mannish Bhandari]

I saw a program that uses #LINK in the form :

#link "hashcode.lib"

the question is will the program be able to compile to an exe file and when you distribute the final program as a standalone exe file
and then you do not need to include its hashcode.lib file ?

am I correct ?

[Dale Yarker]

If hashcode.lib is a PB SLL, then you are correct.

Cheers,

(added from PB Help for #LINK - "The filespec may include an optional path name, and must include the extension ".SLL" or ".PBLIB"." You may have to change the file name extension.)

[Michael Mattias]

"#LINK filename.lib" (and/or "$LINK filename.lib") was also used by PowerBASIC for MS-DOS. I don't know where you saw this #LINK statement but if it was in an MS-DOS program the parameters (lib type and filename extension appearing in the command) are a little different in meaning.

[Mannish Bhandari]

Thank you, I downloaded the program codes from Steve's website http://masm32.com/board/index.php?to...7549#msg107549

and that its DupeRam.bas code contains
#link "hashcode.lib"

it was compiled by PBCC

as shown below:

' ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
'                                  CASE SENSITIVE DUPLICATE REMOVAL
' ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    #compile exe "DupeRem.exe"
    #compiler PBCC
    #link "hashcode.lib"

' ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

FUNCTION PBmain as LONG

    LOCAL tbl1() as STRING                              ' tables must be used in 1 2 order
    LOCAL tbl2() as STRING
    LOCAL indx   as DWORD
    LOCAL rtn    as DWORD
    LOCAL cnt    as DWORD
    LOCAL acnt   as DWORD

  ' -------------------------------------------

    cmd$ = command$

    src$ = parse$(cmd$," ",1)
    dst$ = parse$(cmd$," ",2)
    mbr$ = parse$(cmd$," ",3)

    If src$ = "" Then
      StdOut ""
      StdOut "no source file"
      HelpText
      Exit FUNCTION
    End if

    If dst$ = "" Then
      StdOut ""
      StdOut "no target file specified"
      HelpText
      Exit FUNCTION
    End if

    If mbr$ = "" Then
      StdOut ""
      StdOut "A count of members is required"
      HelpText
      Exit FUNCTION
    End if

  ' -------------------------------------------

    acnt = val(mbr$)

    If acnt < 10000 Then
      acnt = 10000
    End If

    indx = Hash_Init(acnt,tbl1(),tbl2())                ' acnt is nominal array size

    cnt = 0                                             ' unique word counter

    Open src$ for Input as #1
    Open dst$ for Output as #2

    Do
      Line Input #1, wrd$
      rtn = hash_write(wrd$,"?",tbl1(),tbl2(),indx)     ' 2nd text arg is not used
      If rtn = 0 Then                                   ' 0 is success, other is duplicate
        ! add cnt, 1
        Print #2, wrd$                                  ' write unique word to disk file
      End If
    Loop While not eof(1)

    Close #2
    Close #1

    StdOut "Done,"+str$(cnt)+" unique words from original list"

    erase tbl1()
    erase tbl2()

    '''' waitkey$

End FUNCTION

' ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

FUNCTION HelpText() as DWORD

    StdOut ""
    StdOut " Case sensitive duplicate removal"
    StdOut ""
    StdOut "SYNTAX : sourcefile targetfile arraycount"+$CRLF
    StdOut "         sourcefile is a CRLF delimited text file"
    StdOut "         targetfile is the name for the output file"
    StdOut "         arraycount is an integer to set the nominal"
    StdOut "                    array size for processing the input data"+$CRLF
    StdOut "NOTE :   arraycount should be at least as many as the lines in the source file"
    StdOut "                    higher counts are faster and more reliable"

End FUNCTION

' ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

[Michael Mattias]

Per the doc that should not compile.. or maybe not run correctly due to the stated limitation "The filespec may include an optional path name, and must include the extension ".SLL" or ".PBLIB"."
(.SLL and .PBLIB are two different filespecs).

I would test very carefully AND/OR I would write [email protected] or via private message to Adam Drake asking how it works when the doc limits the file extensions.

(FWIW I just last week got a support answer from '[email protected]' except it was answered by Mr. Drake. Same kind of thing... doc is fuzzy but it seems to work as I thought it should. So yes, you can still get factory support!)

MCM

[Steve Hutchesson]

Hi Mannish,

Looks like you found it OK. For techical data have a look at the HashHelp file as it has documentation on all of the functions exposed in the library's interface.

Its use is to link into a PowerBASIC app using the standard #link notation. As with PB documentation, the #link notation can be used with a remote path to a directory but with the examples, I have put the library in with each example to keep the examples simple to follow. Once the library is linked into an application, the library is not needed by the compiled EXE file, it is only ever used as a component in a compiled EXE file.

The file extension has deliberately been set to the more familiar ".lib" as few would be familiar with the suggested .pblib. The SLL module design is more powerful than a Microsoft /COFF library module as they are effectively self contained, and with the same capacity to design cross dependencies among modules, it puts a lot of power in the hands of PowerBASIC programmers.

If anyone has a need for a hash table of this type, it is genuinely fast and can be used with very large slot counts. The upper limit is 33 million which is way larger that most would ever need.

[Rod Macia]

Steve Hutchesson your are actually able to compile using
#LINK "hashcode.lib"

I get:
Compiling "C:\Users\Rod\Desktop\HashCode-Release\Examples\DupeRem\DupRem.bas"
Error 493 in C:\Users\Rod\Desktop\HashCode-Release\Examples\DupeRem\DupRem.bas(7:011): Compiler file not found/accessible
Line 7: #LINK "hashcode.lib"

if I rename both
#LINK "hashcode.sll"

and the File also to .sll
then it compiles.

[Steve Hutchesson]

Rod,

Works fine here. I just feed that example directly to PBCC with this command line.

\basic\bin10\PBCC.EXE "filename.bas"

What are you building it in ?

[Rod Macia]

I open in PBCC6.03 IDE
I press the compile current file "gear".

is it an sll that you renamed or you are performing some other magic.

when I rename it to SLL it compiles and I assume it works, I didn't really check the outputs yet between your exe, and the one I complied.
I will later when I have more time.

[Steve Hutchesson]

OK, that is pretty straitforward, the IDE is doing some filtering. I have two new installs of both PBCC and PBWIN so I will try it out there. It will also be useful to test whether the IDE allows the .PBLIB extension.

I just tested the same file using the newly installed PBCC IDE and it worked with no modification. I tried to copy the build results in the IDE but it cannot be copied.

With the setting showing results in message box,

    Successfully created "O:\Release\Examples\DupeRem\DupeRem.exe"

Ditto with the PBWIN IDE. Both IDE's are from new installs and there may be some difference in the versions. I could not find a setting in either that would enforce the naming.

[Rod Macia]

...It will also be useful to test whether the IDE allows the .PBLIB extension.

It does I use it all the time.

[Stuart McLachlan]

It does I use it all the time.

Standard in every PB application that uses SQLTools Pro and is compiled from the IDE:

#LINK "SQLT3Pro.PBLIB" 'SQL Tools Pro, using PBLIB

[Steve Hutchesson]

Thanks for testing Rod, I cannot track it down with either the PBCC or PBWIN IDEs but something must be blocking the .lib extension and its not the compilers. I use neither IDE and use my own editor but I will see if I can track it down. Its easy enough to rename the extension to .pblib or even .sll.

LATER : Give this a blast. Change the pbpath to your own setup. The rest is standard PBwin installation.

@echo off
: ---------------------------------------
: set your "bin" and "include" paths here
: ---------------------------------------
  set pbpath=O:\pbwin10\

  set bin=%pbpath%\bin\
  set include=%pbpath%\WinAPI\

  %bin%PBWin.exe /l /q /I.\;%include% "HashReplace.bas"

  type "HashReplace.log"
  pause

Works perfectly here with default PBwin..

[Steve Hutchesson]

Whilw waiting for Rod to come back, here is a link to another example, dual hash tables to handle very large word counts. Builds perfectly directly from PBCC or from the PBCC IDE.

http://masm32.com/board/index.php?topic=9848.0

[Rod Macia]

Just to be clear, I was just wondering how you were able to compile using #LINK "hashcode.lib"
when PBCC and PBWIN help file states (must include the extension ".SLL" or ".PBLIB")
and my attempts were getting a compile error, consistent with PB Help.

renaming BIN to SLL compiles without errors and generate same result. (I just open BAS in the IDE, rename bin to sll, and hit Compile)


Now some other intriguing observations.
DualHash.bas form post#14 compiles as is without any changes to extension .BIN

we must have different versions compiler because, the size of your EXE in zip file is 25088 bytes, and when I compile without any change I get 24576 bytes.
both EXE run and generate the same result.

ps: I use PBCC 6.03.0102 the only one I have.

[Steve Hutchesson]

Thanks Rod,

Apart from my old version dated from when Bob was still alive, I have used both the old versions and the most current ones and I cannot duplicate your initial report. Both compilers will produce SLL extension files but the compilers do not control the construction of libraries put together from a collection of SLL files. The supplied tool that Tom Hanlin wrote is no joy to use and I have long used one of my own so I can build large libraries quickly.

The extension for the combined library was never enforced and this is from being on the BETA team for the first versions that produced SLL files. My old version is 6.02 dated 2011 and the new version is 6.03 dated 2021 and neither ever enforced the library extension.

I have continued to use the ".lib" extension because it is far more familiar to folks who have used many different language compilers over time, Microsoft, Borland and a host of others over time from the MS-DOS era up to current and they have all been different module formats that were rarely ever compatible. To folks from other backgrounds, the PBLIB extension tends to be a WTF observation where LIB makes sense to them and it also says that PB compilers are LIB capable, sad to say something lost on many of the basic folk who aren't willing to present PB compilers as professional tools.

Again, thanks for your help here, it was an interesting aside that a combined library would run with an SLL extension, something that I did not expect and chasing down the initial observation has been useful, even though I could not duplicate the problem. Now if anyone gets the same problem that you initially reported, the solution is simply, just rename the library to the ".pblib" extension.

[Mannish Bhandari]

Thanks for the info, I got them compile to PBWin 10 and all results are good
I have changed hashcode.lib to hashcode.sll
and they all work out

one more question what's this file with extension sll it looks like an executable file?

[Stuart McLachlan]

Thanks for the info, I got them compile to PBWin 10 and all results are good
I have changed hashcode.lib to hashcode.sll
and they all work out

one more question what's this file with extension sll it looks like an executable file?

Read Help => What is an SLL
and
Help => Creating a Static Link Lirary.

[Dale Yarker]

It is executable code, but has no MAIN function. The #LINK "builds-it-in" to your executable during compile. Or, consider it a precompiled section.

You can make yourself a collection of these. Some people want to share useful procedures, but not the source code. An SLL allows this in a non-human readable form. Since it becomes part of the dot EXE you don't worry about which version is used (can be a problem with DLLs.)

Cheers,

[Michael Mattias]

Since it becomes part of the dot EXE you don't worry about which version is used (can be a problem with DLLs.)

???

The version of the compiler used to complie the EXE or any DLL is immaterial.

Any application version incompatibility is 100 percent a function of the application.