PowerBASIC 10

[Mike Stefanik]

I wonder if the new ".SLL" extension (static linking) is compatible with the Microsoft LIB/OBJ standard?

They could have used PE/COFF, but .obj files emitted by Microsoft's compilers don't even contain pure object code by default anymore, it's an IL code used for whole-program optimization performed by the linker (you can disable this, but it's been the default since Visual C++ 7.0). Generally speaking, each compiler vendor has done their "own thing" when it comes to static link libraries and the conventions they use (be it COFF, OMF, ELF, etc.)

[Theo Gottwald]

"PowerBASIC just discards those which aren't necessary"
That sounds as not being optimized per function but per library.

As i see it, a SLL is somewhat what a DLL is, but just for inclusion in the EXE File.

As its the compiler who makes the "Dead Code removal" and not the Linker, and the SLL is already compiled (as i understand it), i would second your idea on this.

However so long we do not have the final thing we can not be sure on anything.
Nobody knows what finally will be presented by Bob.

He's always good for a surprise!

[Mike Stefanik]

As its the compiler who makes the "Dead Code removal" and not the Linker, and the SLL is already compiled (as i understand it), i would second your idea on this.

Not necessarily; it could well be that they perform certain optimizations at the link phase of the compilation process, Microsoft's languages certainly do this. There's two general ways I know of to remove "dead" code from an executable. One is through a pre-compilation phase where you build a directed call graph of the complete project, analyzing the relationship of each funtion to one another and eliminate those that aren't called. The other way eliminates unused code by packaging each function in its own COMDAT section and the linker ignores those sections that aren't referenced; Microsoft calls this "transitive COMDAT elimination" and it's an optimization option for their linker (/OPT:REF).

[Bob Zale]

Each SLL can contain any number of Subs, Functions, and Classes.  One or 1000.  Multiple SLL's can be combined in a PBLib file.  You can $LINK 1 SLL and/or 1 PBLib with a $LINK "MyLib.SLL".  You can have any number of $LINK metastatements in a program.

Unused code is removed from each SLL as it's created.  Any unused $LINKs are dropped.  Any unused SLL in a PBLib is dropped.

It works very well.  Very, very well.

Bob

[Edwin Knoppert]

Thanks Bob, sounds promising!

[Bob Zale]

Thank you, Edwin.  I can assure you it's very promising.

But that isn't all...    Wait 'til you see (and experience) the rest of our surprises...

Stay tuned...

Bob

[Theo Gottwald]

Wait 'til you see (and experience) the rest of our surprises...

Thanks Bob!
I love such surprises ... it's like christmas!

[Patrice Terrier]

Unused code is removed from each SLL as it's created.

Being accustomed to .OBJ, that's sounds very strange to me  

Suppose that, for the purpose of granularity, i create one SLL for each of my SUB or FUNCTION, how could you determine if they are used or not?

Another great concern for me, is how easy is it to share data (globals) between SLL modules?

...

[Theo Gottwald]

Suppose that, for the purpose of granularity, i create one SLL for each of my SUB or FUNCTION, how could you determine if they are used or not?

Patrice, you add all of these SLL's into an single INLCUDE FILE.
In this file,You call each of these "SLL's" using #LINK "Filename.sll"
Save it on your harddisk "MyLib.inc".

In your final project you include only the single include file - and you do not care for anything else!
Bob('s PB 10)  will sort out which of the SLL's are used and compile only those to the final project.
This is how i understand it!

Bob said that this works. I believe what he said.
How does he do it? Why should we care so long it works?

Another great concern for me, is how easy is it to share data (globals) between SLL modules?

This is another question, maybe Bob can tell us more about this?

[Patrice Terrier]

Theo,

As i see it, SLL, while good for in-house programming, doesn't match my personnal needs, that is to ease mixing inter-languages and to conform to the industry standard.

And my question of "when creating a SLL made of one single SUB or FUNCTION, how could you determine if they are used or not?" is still valid, because Bob wrote "Unused code is removed from each SLL as it's created".

While i can understand how unused code could be removed at LINK time, i can't understand how this could be done at the time of the SLL creation.
This is why i am asking for clarification.

Indeed, what i was trying to figure is this:
"Would i be able to convert some of my DLLs (like WinLIFT or GDImage) into PBLIB, to create one single EXE, because i know that this is the question PB's user will ask me for."
So far, from what i have understood, my answer is NO, because some mechanisms like "LIBMAIN and shared globals" are provided only from standard DLL, and some advanced hooks (like detour/trampoline), can only be done from a DLL.

...

[Theo Gottwald]

Hooks are only possible from DLL's, Patrice. There are very few exceptions. But i doubt they apply here.

Because a DLL is the only thing that can enter the adress space of the target process.
This is not a shortcoming of a SLL, it's just a fact under Windows OS.

Another thing is, if there is a GLOBAL-Variable type thinkable that would connect SLL's.
Maybe Bob will tell us something about this ... when he comes back?

About the useless code that is remove at creation time of a SLL, i do not see your problem.

If you create an EXE File and useless code is removed at compile-time, the same thing can apply to a DLL and a SLL as well.
As long as these SUB or FUNCTIONS are not marked with EXPORT (in a DLL) or in the equivalent way in a SLL.
And they are not called internally, they can be "cleaned away" from intelligent compilers.

And i believe PB 10 will be intelligent.

What i can imagine is, that you split things in smaller boxes. Whatever needs a hook must be in the DLL.
What ever doesn't need an hook can be in an SLL, if you get it connected as needed.

[Edwin Knoppert]

A SLL has nothing to do with DLL's or EXE's as a 'process'.
It's just a library and you are using it in the target of desire.
So linking the SLL in a DLL makes the code part of the dll, what's the discussion about?

[Patrice Terrier]

Edwin,

I think that SLL uses the same concept than the formal PowerBASIC Unit (PBU).

And the discusion was that:

unused code will be removed from the SLL at it is created.

...

[Theo Gottwald]

I have never heared from these "Units" before, but anyway it doesn't make an difference how it is internally implemented so long it works fine. Also i do not think that the stuff, the internet says about these Units does apply today anymore. See below. Maybe there are similarities.
Any UNIT concept even the one from Turbopascal or Delphi has something in common with any other Unit-Concept. Therefore at this point nobody can or should redevelop the wheel. There are always similarities. Onthe other side we can be really sure that stuff from DOS times will not more work today, without beeing significantly adapted.

If there is working code in the house, that is tested and can be extended, nobody will do everything from scratch.Me not, you not, why should PB?

If the concept of the units has been good at that time, why should an improved version of it not be good for today?
I like the SLL thing.

Source

• Die in der Unit enthaltenen SUB/FUNCTIONs müssen in der Unit-Datei als PUBLIC deklariert werden.
• Die vom Hauptprogramm benutzten, in der Unit enthalltenen SUB/FUNCTIONs müssen im Hauptprogramm mit dem korrekten Typ der Übergabeparameter deklariert werden.
Variablen, auf die sowohl das Hauptprogramm als auch die Unit zugreifen soll, müssen im Hauptprogramm als PUBLIC und in der Unit als EXTERNAL deklariert werden (betrifft nicht die Übergabeparameter an die SUB/FUNCTIONs der Unit).
• Die Unit-Verwaltung differiert zwischen den PowerBASIC-Versionen. Im Zweifelsfall solltest Du die Unit für anderen neueren Compiler neu generieren.
PowerBasic Units sind ein eigenes System zum Verwalten von Libs in Power Basic. Dies sind allerdings in keinster Weise mit den LIBs von Microsoft kompatibel und soviel ich weiß gibt es teilweise auch Unterschiede zwischen den einzelnen PowerBASIC Versionen. In PowerBaSIC gibt es das Programm PBLIB zum Verwalten der LIBs. Es wird hier kein Unterschied zwischen Laufzeit version und Entwicklungsversion gemacht, wie in QB mit OBJ/LIB.

Let's see what possibilities the final things can give us!
The compiler is not yet out - nobody can now (with one exception).

[Edwin Knoppert]

I think this is wrong, the SLL should contain all functions and during compilation the compiler takes out what's been used.
So if the SLL has 10 functions and your code refers 3 of them then the compiler takes only the 3 functions and thus a smaller piece of the assembly.
This is what i mean about optimized linking.