Jose's Read Only Forum 2023

I am glad to see the PB's announcement for version 10.

I re-read the gazette several times for my pleasure, looking at some of the features i have been waiting for long.

This is a very good step forward, even if i couldn't find anything about 64-bit.

Thank you Bob and Co.

...

Hi Patrice,

Has a bit more what the version is 10 more. Kan man they order but I would not yet buy a pig in a poke

Regards Peter

 
I wholeheartedly recomend it. It's a major update, and I know of what I'm talking.

My two major requests, native unicode support and dead code removal, have been implemented in a way far superior of what you can see elsewhere, even better than I expected, and Bob knows that my requests where high, yet clear and concise knowing that what I was requesting was possible and not an unrealistic dream.

Dead code removal has allowed me, for example, to write and include file with wrappers for every and each one OpenGL extensions (1,720, no less), and only the ones called will add code to your application.

Besides helping testing the compilers, I have been working very hard in a new version of my Windows API Headers (updated to the latest Windows 7 SDK) that allow to work with unicode transparently, just by defining %UNICODE = 1.

I also have written a new brand editor, CSED, a new version of my TypeLib Browser and several templates, and I'm working in documenting my wrapper functions and classes.

I will open a new subforum because these new headers can only be used with the new compilers.

I'm very happy because I finally can do low-level COM programming without having to use workarounds. Null terminated unicode strings where much needed for this work.

A few important wishes became true.
Static linking (with optimization!)
Dead code.., oh well certainly benefitial.
Unicode, yes that would be nice in a few/many cases.

It is a lot of work but weren't there more things being upgraded?
DDT and controls or so?

Oh, yes, but the list is very long and I'm not going to unveil anything that has not been unveiled by Bob first.

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

...

No, of course not Jose.
During my post i wasn't aware that it wasn't ready yet :)

For me the same. When i got that mail, i really thought "Yeah now i can get it !!!".
Then i read that its just a Pre-Sales and this means it can take a month until the final is here.

After my order is filled, you can all apply for your copy.  ;D

Theo, please don't use glow in your posts. The results are very ugly and annoying to people that use a decent explorer instead of IE.

Quote from: Patrice Terrier on December 25, 2010, 08:43:58 AM
I wonder if the new ".SLL" extension (static linking) is compatible with the Microsoft LIB/OBJ standard?

...

Unfortunately no... This is the proprietary format of PowerBASIC and can be used with PB products only ...

Quote from: Aslan Babakhanov on December 27, 2010, 09:25:14 AM

Quote from: Patrice Terrier on December 25, 2010, 08:43:58 AM
I wonder if the new ".SLL" extension (static linking) is compatible with the Microsoft LIB/OBJ standard?

...

Unfortunately no... This is the proprietary format of PowerBASIC and can be used with PB products only ...

http://www.powerbasic.com/support/pbforums/showpost.php?p=360229&postcount=36

Ok, i read Bob's answer, thank you.

...

If you think about it, seems many function declararions and maybe even interface declararions won't be needed as plain text anymore.
Put everything in a static lib and off you go..
This may well be the start of a new compiler, i mean a different kind of perspective towards this compiler.
For example functions to handle checkboxes and so on can now be part of the 'compiler-engine' as a library.
No more need for stupid (sendmessage)declarations.

A new era, unf. i was about to quit PB (sigh).

QuoteTheo, please don't use glow in your posts. The results are very ugly and annoying to people that use a decent explorer instead of IE.

Sorry i just did not think of this. Actually i must use FF as you know because after leaving my good old IE 6, IE 8 did not work on many sites.

Can someone explain the $LINK stuff?
Will the compiler allow multiple $LINK statements or do we need the librarian?

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

Quote from: Patrice Terrier on December 25, 2010, 08:43:58 AM
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.)

Quote"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!

Quote from: Theo Gottwald on January 10, 2011, 12:42:16 PM
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).

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

Thanks Bob, sounds promising!

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

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

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

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

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

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?

...

QuoteSuppose 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?

QuoteAnother 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?

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.

...

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.

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?

Edwin,

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

And the discusion was that:

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

...

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 (http://www.antonis.de/faq/qbmonfaq-dateien/1724238589.html)

Quote• 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).

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.

Edwin,

When Bob wrote "Unused code is removed from each SLL as it's created".
I think he had something else in mind.

Anyway i am sure that unused SLL won't be embedded in the final EXE at LINK time.
SLL is rather an OBJ than a LIB.

Thus there is a PowerBASIC LIB equivalent, to embed several SLL altogether: PBLib.

...

I understand you, Edwin. We have all more wishes then possibly this next version can fullfill.
While - i can't say because its not yet out!

But anyway i am sure it will be one of the most welcome releases for me - ever!.

Leave away the SLL's if you don't like them so much.
Did you read when Bob said that he increased compiling speed by another 400% !!!

Why did people in earlier years use these UNIT-Libraries?
Yes for selling stuff.

But mostly because the compiling process was taking long time!

This is not the case with PB!

Believing the numbers i have heared from Bob, even your largest project will compile in 0.3 seconds!
You can just take a breath and its compiled and linked!

Then for what do you need UNITS?

Just put all your stuff in "INCLUDE" Files, and voila you have the "Dead Code Removal" as you want it.

After all, we can always look for a hair in the soup and if we look long enough we will find one.
But this new release opens a lot new doors once its out, especially with the "Dead Code Removal" - it also works inside OBJECTS!

I have for myself taken the consequence and decided, that when i re-organize my libraries for PB 10 (and they are large over the years) I'll just always INCLUDE them. All my collected PB Libraries .... always available. They will be Compiling in 0.3 seconds ... with PB 10.

It is my understanding that PowerBASIC static linking, will be very welcomed by some of the third party addon providers.

...

Yes, no more same-old-code to compile along with the compile process each time.
Protection is not really a serious issue, but sometimes.
Speed 400%, i doubt it, i assume when one precompiles his existing code to a SLL and therefore maybe it skips a '4-step' compile process? (we'll see of course :) )

One of the bigger issues is the debugging, it *may* help when the heart of your form engine (as in PwrDev) is skipped during debug (step-over) so one does not get bothered with code he doesn't need to inspect anyway.
That's something i would like to see in practise.

I also think that the debugger remains a problem, it's a bit slow but more of a problem is the way things work.
Like bookmarks, they are not stored for the next time, so far in PB9 and earlier it is far from a Microsoft Visual Studio.
In the early days i was pretty fast without the debugger but the projects are getting bigger and nastier, something the current debugger can't help much imo.
Also.., debugging a dll would have been nice, my biggest issue currently resides in a dll.
But asking for a solid debugger undermines my remarks about the bare-bones compiler i made earlier :)

Edwin,

Bob, wrote a few post above in this thread, that several SLL units can be combined altogether to create a PBlib.

...

How about changes in PB IDE and PB Forms? I suppose they're should be...
If compiler has been changed significantly, then IDE must be on the same route.

Also, the most important changes is UNICODE! It is also unclear, whether controls will be unicode capable or not?

I had to port one of my huge commercial PBWIN9 project to .NET due to one reason - unicoded controls.. :(

Ok. Let's wait for final announcement.

Aslan,

It has been said in several posts, that PB10 will have both native ASCII and UNICODE support (WSTRING).

...

Quote
Also, the most important changes is UNICODE! It is also unclear, whether controls will be unicode capable or not?

Windows controls have always been unicode capable. SDKers just needed to create them using CreateWindowExW, instead of CreateWindowEx, and use the "W" API functions instead of the "A" functions with them.

Hi Jose,

Anyway that would be better to see UNICODED DDT controls besides SDK.

WSTRING is a good step forward in the world of unicode, but i expect full unicode support.
Believe me, writing a code using SDK and API with "W" suffix to get proper unicode support is a kind digging a hole with needle. (see support for many controls).

You don't know where is the next problem may occur.  Even if you won't faced with any problems, you'll be step backward from other developers as the speed of coding with SDK including debug/edit/redesign might take some time.
May be that requires some experience to play around SDK, but i don't see cons in using SDK where your applications contains 20+ forms with complex inputs...  

Hope, I'm not put here so aggressive notes as this is my personal opinion from the real world of programming where many .NET sharks is floating around PB dolphins.  

BTW, might be interesting, In my country the government decided to switch to unicoded communication on every IT (an iT law).
That law of course affected on developers, so they're have to rewrote all commercial projects to unicode.

Forgot one point: If PB 10 supports unicode strings, then i suppose that the compiler + IDE must be capable of handling unicode strings.  ???

>Forgot one point: If PB 10 supports unicode strings, then i suppose that the compiler + IDE must be capable of handling unicode strings.
To me it seems every IDE uses ansicode for their properties and texts in code and converts it to unicode.
Not sure how this works but i wonder'd it myself.

Aslan,

The whole API declarations are available with either a "A" or "W" append to the end of the function.

And when you write C or C++, you must choose the good declaration as well.

José, wrote that he will have a new set of include files for PB10, that will take care of that transparently.

...

Aslan, i have no idea if DDT will be UNICODE or not. But take a look on Jose's new CWIndow-Class, when its available.
It looks to me like its made for Projects like your!
I have seen a preview, the HELP/Documentation for it is superb!

Theo,

Thanks for route. will take a look at Cwindow class. looks interesting.

Cheers!

Maybe Jose can give you a hint how you can get it.
Anyway - it will be the best Mix together with PB 10 because then
automatically all unused Methods are "cleaned out" at compiletime.

PB-Forum down?

I only get: Service Unavailable

Maybe the run to PB 10 is too big!

Quote
Maybe Jose can give you a hint how you can get it.

The new headers will be available when the new compilers will be released. There is nothing you can do with them without having the compilers.

Quote
José, wrote that he will have a new set of include files for PB10, that will take care of that transparently.

They work the same way that with C++.


DECLARE FUNCTION RegisterClassExA IMPORT "USER32.DLL" ALIAS "RegisterClassExA" ( _
   BYREF lpwcx AS WNDCLASSEXA _                         ' __in CONST WNDCLASSEXA *lpwcx
) AS WORD                                              ' ATOM

DECLARE FUNCTION RegisterClassExW IMPORT "USER32.DLL" ALIAS "RegisterClassExW" ( _
   BYREF lpwcx AS WNDCLASSEXW _                         ' __in CONST WNDCLASSEXW *lpwcx
) AS WORD                                              ' ATOM

#IF %DEF(%UNICODE)
   MACRO RegisterClassEx = RegisterClassExW
#ELSE
   MACRO RegisterClassEx = RegisterClassExA
#ENDIF


You can call RegisterClassExA or RegisterClassExW individually, or you can call RegisterClassEx. When calling RegisterClassEx, if %UNICODE is defined, RegisterClassExW will be called, else RegisterClassExA will be called.

Same with structures:


' // Size = 48 bytes
TYPE WNDCLASSEXA BYTE
   cbSize        AS DWORD        ' UINT
   ' /* Win 3.x */
   style         AS DWORD        ' UINT
   lpfnWndProc   AS DWORD        ' WNDPROC
   cbClsExtra    AS LONG         ' int
   cbWndExtra    AS LONG         ' int
   hInstance     AS DWORD        ' HINSTANCE
   hIcon         AS DWORD        ' HICON
   hCursor       AS DWORD        ' HCURSOR
   hbrBackground AS DWORD        ' HBRUSH
   lpszMenuName  AS ASCIIZ PTR   ' LPCSTR
   lpszClassName AS ASCIIZ PTR   ' LPCSTR
   ' /* Win 4.0 */
   hIconSm       AS DWORD        ' HICON
END TYPE

' // Size = 48 bytes
' // Predefined as of PBWIN 10
TYPE WNDCLASSEXW BYTE
   cbSize        AS DWORD        ' UINT
   ' /* Win 3.x */
   style         AS DWORD        ' UINT
   lpfnWndProc   AS DWORD        ' WNDPROC
   cbClsExtra    AS LONG         ' int
   cbWndExtra    AS LONG         ' int
   hInstance     AS DWORD        ' HINSTANCE
   hIcon         AS DWORD        ' HICON
   hCursor       AS DWORD        ' HCURSOR
   hbrBackground AS DWORD        ' HBRUSH
   lpszMenuName  AS WSTRINGZ PTR ' LPCWSTR
   lpszClassName AS WSTRINGZ PTR ' LPCWSTR
   ' /* Win 4.0 */
   hIconSm       AS DWORD        ' HICON
END TYPE

#IF %DEF(%UNICODE)
MACRO WNDCLASSEX = WNDCLASSEXW
#ELSE
MACRO WNDCLASSEX = WNDCLASSEXA
#ENDIF ' UNICODE


Just take a look on this attached screenshot.
With PB 10 and Jose's Add On's it will be easy doing - even if you have to make things for Aserbaidshan or Peking.

Please note that this is a "Work in Progress". I just show it as an example.

PS: Again trouble to reach the PowerBasic WEB-Site. Possibly they can not stand the rush on people want to get infos on PB 10 ?
Maybe they should look for a new provider. There are good providers in USA which virtually unlimited bandwith.
If not choose our provider (1&1). We'll NEVER have that problem with Jose's Forum, as my provider can handle any rush.

QuoteFehler: Netzwerk-Zeitüberschreitung
       
         Der Server unter www.powerbasic.com braucht zu lange, um eine Antwort zu senden.

About José include files:

QuoteThey work the same way that with C++.

From a SDK coder like myself, always moving from one language to another, i would say that without the José's set of API, i probably had no other choice than to move my low level tools to another platform.

The tremendous work he does, allows me to still use my PB's stuff, because his include files embrass the whole SDK including SDK 7 like with Visual Studio 10.

José, your are the only reason why i can still use my favorite programming language, THANK YOU!

In case you do not get a free PB10 upgrade, please let me know, and i shall have one free for you.

...

QuoteJosé, your are the only reason why i can still use my favorite programming language, THANK YOU!

You are not alone, Patrice. I have heared more voices like you, saying they can only stay with PB because of Jose.

Still thats not the reason why i support him. The reason for me is that he is just genial in what he's doing.
Or let me say an artist.

What ever he starts in this area - he brings it to an good end.

Thats the first thing that is different to others who may also be Top-Talented programmers.

There is a saying in germany which states that only "Talent paired with dilligence" makes a Genius.
Thats a short description of Jose, who doesn't believe take a look at the results.

A normal programmer from flesh and blood can not compete with his work and knowledge.

Is this the email address to send PayPal donations to José?
~~~~~~~~~*
James


*[Theo: Adress removed by me to prevent publication to Spambots. The adress to use, see below.)

Yes, please verify Jose's paypal donation address. I want to also send Jose a token of my appreciation.

The address, as I use it, is JRoca@com.it-berater.org
~~~~~~~* is an alias used by the server.

*[Theo: removed by me to protect from spamming.]

Thanks José, money sent.

Treat yourself to something nice and relaxing. Get away from the computer screen for a while.   ;D

Hi José,

I've sent money...and i agree with Paul.

Theo,
I can open PB forum and main web page without any problems and delays for a long time since PB10 teaser.
May be something wrong with your internet provider?

I remember old days when PB7 teaser started on main web page.At that time a thread about new compiler exceeded 100 pages and forum worked very slow.

Paul and Aslan: Thanks very much for your donations.

Patrice: Thanks very much for your generous offer. Guess I won't need to accept it because I have $250 of credit from a contest I did win a few years ago, and I only can spend that money buying PB products.

 
For new applications, the way to go is to use unicode. With the new headers, it's a matter of using WSTRINGs and WSTRINGZs instead of STRINGs and ASCIIZs.

As we are in a period of transition, support for both ansi and unicode is offered. Ideally, in a few years, the ansi stuff will no be longer needed. Currently, with the new compilers, is only needed for existing applications.

Unicode applications run also slightly faster because all the API functions are written in unicode and the ansi functions are mere wrappers that convert the ansi strings to unicode and call the unicode version.

We no longer need to use workarounds to work with low-level COM interfaces. No more UCODE$/ACODE$ and BYVAL STRPTR.

The headers can be used by everybody, not just SDK programmers. You can even use them to do GUI programming with the console compiler!

Thanks to dead code removal, I'm offering thousands of wrappers to make easier the use of the Windows API.

I'm attaching a draft help file with documentation for the ones that will be more often needed.