FreeBasic and PowerBasic Compatability Issues

[Donald Darden]

FreeBasic and PowerBasic both can be seen as extensions of the original QuickBasic syntax and dialect.  Each being an extension, they have evolved in different ways.  But there is still considerable similarity between the three languages.

There are many under-the-hood differences.  However, there are also suppose to
be some points where they match up.  The most significant one is probably the
ability to work with DLL files.

Dynamiic Linked Libraries have largely replaced static libraries that have to be linked to create the executable file.  Instead, DLLs are only loaded at runtime when the executable tells Windows to locate and load the file, then link up the
procedure entry points with the call statements in the executable.  If the same DLL is used by more than one program, there can be a great savings in the amount of RAM consumed, since each executable can work with the same copy of the DLL.  Executables can also be made much smaller, since the library or shared portion of the code is not permanently a part of the executable.

The other significant advantage of DLLs is that they, like shared libraries, can be  written in any programming language.  It just has to be able to produce a DLL-formated file as its output.  PowerBasic's CC (Console Compiler) writes code very similar to its big brother, PB/Win and PB/DLL, but cannot produce a DLL file as an output.  On the other hand. PB/DLL was initially developed explicitly for this purpose, and later evolved into the PB/Win compiler which does much more.

In FreeBasic folder examples\dll, there are three files:  Mydll.bas, Test,bas, and TestLoad.bas.  Mydll.bas can be compiled to create a DLL, which can then be called by Test.bas and TestLoad.bas after they are compiled. Test treats Mydll as a normal DLL that is expected to be available when the program is used.  TestLoad instead attempts to verify that Mydll is available before attempting to call it.  The first way is simpler, and the second can be more robust.

I've compiled and tried these programs with FreeBasic, and they work fine.  Then I adapted each source file slightly to work under PowerBasic, and again they compile and work fine.

But if I try to use the FB version of Test or TestLoad to call the PB-produced version of Mydll.dll, or the PB version of Test or the adapted TestLoad to call the FB-produced version of Mydll.dll, I get errors.  That shows that there is a compatability issue in the way the DLLs are produced and called, yet FB is consistent with itself, and PB is likewise consistent with itself.  So is one right and the other wrong, or are they both wrong?  For this, you need a third opinion.

I used PE Explorer on both versions of Mydll.dll, and checked to see what was being exported in each.  The PB version showed me a procedure called AddNumbers, which is correct.  However, the FB version showed me a procedure called AddNumbers@8, which is incorrect.   PE Explorer also returned this warning:

Code Select Expand


28.06.2007 21:01:08 : Warning! Section <.rdata> (2) extends beyond the raw file offset of section <.bss> (3).

That, and the fact that PowerBasic has been around for a good while and has been doing this a lot, tends to make me think it is a problem with the way that FreeBasic currently builds and calls DLLs.



 

[José Roca]

 

However, the FB version showed me a procedure called AddNumbers@8, which is incorrect.

It is not incorrect. It is a decorated function name. The @8 are the number of bytes (2 parameters of 4 bytes each). To use it with PB, put the decorated name in the alias clause, i.e. ALIAS "AddNumbers@8".

[Donald Darden]

Okay Jose, I will have to give that a try.  It still bothers me that PE Explorer finds the error above. but the critical thing is to make sure the call succeeds.  I keep having problems with LD.EXE failing to access the mydll.dll file after a certain period of trial and errors, to which I've reinstalled the FBEdit bundle several times.  This last time I wiped out the entire FreeBasic directory tree and just installed the bundle on its own, hoping that will somehow keep these problems from coming back.

The question is, if FreeBasic creates this "decorative" feature you mention without me asking, then what is the FB version of Test looking for from the PB version of mydll.dll?  As you know, the ALIAS name, number of parameters, and parameter
types are rather critical for matching up a call to a procedure in a DLL.

[José Roca]

 
It should look for the name you use in the ALIAS clause.

Decorated names, also know as mangled names, are generated by compilers that support function overloading and/or namespaces. It is a technique used to generate unique names for identifiers in a program.

The problem is that different compilers use different mangling schemes. This is not a problem with DLLs, thanks to the ALIAS clause, but make static libraries incompatible.

[Chuck Hicks]

Donald,

Here's a good reference regarding decorations: 

http://www.geocities.com/yongweiwu/stdcall.htm

FreeBASIC is a considerably more sophisticated compiler than PB, providing far more compatibility with standard libraries, so will require a bit more effort to learn.  If you've ever used any of the excellent gcc compilers (g++, gcj, etc), you'll be at home with FB.