BLIB library manager for current version of PB.

[Steve Hutchesson]

This is a multiple capacity tool for working with SLL modules and creating libraries. It is very simple to use and seems to be fast enough for the tasks it performs. When run from the command line it displays the information below. This style of tool is much closer to normal style library managers where instead of tediously picking individual modules out of a list interface, you explode the lot into a directory. For anyone who has dealt with libraries over the years, this is primarily how libraries are built, managed and modified.

Code Select Expand


Library tool for PowerBASIC

NOTATION:
    1. blib /c libname.ext
       COMBINE all SLL files in the current directory into a library.

    2. blib /e libname.ext
       EXPLODE all SLL modules in a library to seperate files.

    3. blib /l libname.ext
       LIST all SLL module file names in a library.


[James C. Fuller]

Steve,
  What are your perceived advantages / disadvantages of using SLL's?

James

[Steve Hutchesson]

Hmmmm,

1. Modular code design.
2. Viable method of encapsulation of complex code.
3. Free of the reliance on text source for reusable code.
4. Grouping of related functions in a single library, cad/graphics/FileIO/games etc ....
5. Industry standard capacity at last.
etc etc ....

[James C. Fuller]

Steve,
  In my opinion there is only one use for sll's: Commercial code distribution.
1,2,4 can all be done with source.
Why would you #3?
This is the  one item that makes PowerBASIC the BEST in optimization of all languages. Dead code removal.
All of the functions from an sll are included even if only one is used.

If you use both PBWin and PBCC you need to maintain 2 sll's for the same library.
#5 Oh WOW. We now can use a 40 year old standard.

Bob gave us SLL's because everyone was asking for it. With dead code removal they are completely redundant in all but commercial distribution of libraries.

James

[Steve Hutchesson]

James,

You are welcome to your opinion, if you don't comprehend libraries, then don't use them. As someone who has 18 years of PB code floating around in different archives, I join the rest of the programming community in the vast majority of commercially viable languages that do use libraries. Dead code removal is a good technology but it does not address massive volumes of code which libraries routinely do. Look in your VC LIB directory to see the difference. My VC2010 LIB directory has 153 megabytes of 32 bit libraries and there are plenty more with the aftermarket.

Mainstream versus the Mickey Mouse Club, Bob put PB into the mainstream with libraries but the Mickey Mouse Club has done its best to cripple the extra capacity that Bob built into his last versions. A compiler written in assembler, a high powered inline assembler in MASM format notation, dead code removal that at last caught up with linker resolved dependencies ALA Microsoft 1987 and later, industry standard libraries that raised PB out of the Mickey Mouse Club into a professional language. Then you have the COM and OOP stuff that I confess to being ignorant about as I work at lower level.

> If you use both PBWin and PBCC you need to maintain 2 sll's for the same library.

You are simply wrong here, any code that can be used in common between both compilers can be used by both in the same library. You only need separate libraries for compiler specific capacity.

> All of the functions from an sll are included even if only one is used.

This is simply nonsense, read the documentation supplied with the compilers and design your libraries properly. One SLL module for each function and you have no granularity problem. This is ancient technology, you did this in QB45 (1987) making libraries and quick libraries.

> Bob gave us SLL's because everyone was asking for it. With dead code removal they are completely redundant in all but commercial distribution of libraries.

You are wrong here, with Bob's normal security views (no vapour ware) the capacity was introduced to the customer base with the release in PBWIN10 and PBCC6. While the Mickey Mouse Club wallows in its own ignorance trying to cripple PB down to its own level of ignorance, Bob aimed at improving and making PB a lot more powerful and part of his legacy was that he succeeded.

If you wish to support pre 1990 crippleware, don't let me stop you but trying to mislead people about the capacity of the language is something we will differ about.

[Patrice Terrier]

LIB toto -+new.obj

[James C. Fuller]

Steve,
  As you know I am well aware of the functions of libraries.
In my opinion Bob did not put PB into the mainstream with a proprietary sll file format.
PB DOS is more modern in this resepect, able to use industry standard 16bit object files.

I can't even use an sll compiled with PBWin10 with PBCC6 or vice versa not to mention the inability to use an object file created with masm.
If I use just source, all my library routines are available to both PBCC and PBWin.

Why would I want to go to all the bother of creating 7000 separate sll's (to get granularity) of my 7000 library routines when I can just use the source and get just the functions I use?

Sorry Steve, it is you, with your push here of a system that is completely redundant to  all but the commercial developer, that has joined the Mickey Mouse Club.

James

[Steve Hutchesson]

James,

You are of course welcome to your opinion but inflicting it on other people is where we will differ. I would be far more interested in the PB code you post using advanced capacity than your opinion.

> In my opinion Bob did not put PB into the mainstream with a proprietary sll file format.

Well, if you knew as much about libraries as you say you would know that every language has its own library format, the ancient OMF, COFF, Microsoft COFF, Unix ELF, Open Watcom has a flavour of its own and the old Borland object modules did not work with other languages. PB is no different here, the most common library format, Microsoft COFF cannot handle PB data types.

> If I use just source, all my library routines are available to both PBCC and PBWin.

If you bothered to learn how to write SLL modules, you could separate common code from compiler specific code so that you would end up with 3 library types,

Code Select Expand


common.lib
ui.lib
con.lib


> Why would I want to go to all the bother of creating 7000 separate sll's (to get granularity) of my 7000 library routines when I can just use the source and get just the functions I use?

I don't particularly care what you can be bothered about, the software industry for the last 30 years or so has used libraries and continues to do so and this means both current Unix and Windows mainstream compilers.

When you try and do comparisons of a basic wrapper of a C wrapper of FASM to a MASM executable you have simply made the point that you cannot write assembler code. FASM is an excellent assembler which can compete with MASM in terms of file size, its just that you have tried to inflict your own restrictions on other people.

> PB DOS is more modern in this resepect, able to use industry standard 16bit object files.

16 bit object files (modules) and modern do not go together well unless you teleport yourself back to 1987.

When you start posting code that shows the advantage of doing things the wrong way, you may have something to say but gabfest attempts to cripple a language down to your own understanding is a waste of space. We have all seen how you and a few others destroyed Gary Beene's attempt to get API based code and the advanced capacities built into the current PB versions up and going but I can and will keep posting PB code using both in the MASM forum where there will be no nonsense at all.

Should we hold our breath waiting for you to post some viable PB modern code ?

[José Roca]

I comprehend libraries and I did help to debug PB's SLL's implementation, and I don't use libraries with PB because include files offer more advantages with it (with other compilers is another story).

Contrarily to C++ and other tools, you don't get faster compiles using libraries with PB, and you lose conditional compilation.

[James C. Fuller]

Thanks José. That is exactly what I was trying to say.
Steve,
After all these years I should know better than to get into a pissing match with you.
You are a far superior low level coder with a knowledge that exceeds most PowerBASIC users.

James

[Steve Hutchesson]

Jose,

Perhaps you would find a use for the capacity to fully encapsulate complete complex objects as individual SLL components. The fun part is you can do anything that can be done in PB from line numbered basic to raw opcodes in hex and as long as you can get it to work, it becomes an object.

[José Roca]

I already tried it converting my OLE container in an SLL and did not find any advantage.

I also did tests making libraries with some of my wrappers only to find that it compiled slightly faster using include files than SLLs.

In my CWindow class I make heavy use of conditional compilation, a feature that I will lose if I converted it to a SLL.

Other than to hide the code, that is useful for third party vendors, I still have to see any advantage of using SLLs.

[José Roca]

And how to convert a class to a SLL without losing dead code removal? You can't split the code putting each method/property into a separate SLL.

[Steve Hutchesson]

I would imagine that a system designed for interconnected text based source file would be very difficult to duplicate in object modules but equally a system designed from scratch around object modules probably would not convert to text all that well either. Being reasonably familiar with the capacity of Microsoft COFF format libraries, there is very little they can do that a PB SLL cannot yet Microsoft provide their particular flavour of OOP in library format so I imagine it can be done if it is designed that way.

For any OOP based system, there is by necessity a base of procedures below it and it is here in primitives that libraries work fine as long as the basic rules of granularity are observed (one procedure for one module) the performance is not degraded by wasted code that is not used. Now while Microsoft COFF maintain their dependence on modules that they may call from other parts of a library, a PB SLL wraps that whole lot into one SLL if that is what you require and importantly without the need to resolve dependencies like a Microsoft linker must do.

Its a gradient from bare components in each module up to very high level objects wrapped in a single SLL and any combination inbetween. As far as hiding code, a vast amount of primitives are not visible when they are buried in the compiler's own runtime library and I doubt that many would be interested in the guts of a dynamic string engine or the amount of floating point maths behind the arithmetic and maths functions built into the compiler.

What SLLs and libraries do is extend the compiler without users of various level of experience needing to know what x86 assembler looks like at a compiler level, if they have access at a function that is reliable and works correctly, then it is just an extension of the compiler. This has been the great strength of C compiler for many years, they have very little runtime library support directly from the compiler and must rely on external object modules contained in COFF libraries. You can of course supply the source code with the SLL if you wish but if the code in complex few would be interested in climbing through.

[Marc Pons]

I don't like to use SLL , it's more simple with code source, as José said.

And Sll are simply for PowerBasic , not compatible with VC libs, nor with gcc libs , nor pellesC libs...


In Freebasic , I use/ make libs in gcc type, at least it is possible to share with c/c++ ...

And in that case : the libs are extensions of the core compiler .