PureBasic Forums - English

Unfortunately, there is no way for now to tell which userlib does the linker error.

traumatic wrote:

Fred wrote:

traumatic wrote: Do I see this right? Compiling a DLL also generates the corresponding .exp and .lib in the 'save-to' directory now?? Shocked

That's it

Does that mean that now DLL's generated by PureBasic can OFFICIALLY be used with applications programmed with other compilers

Fred, did you had a look at my problem with the Docmaker ? I can't wait to start doing some docs

The problem was the additonal japbe-constants. I have correct this.

please only download the complete file, when the uiu doesn't work:
http://gpihome.de/purebasic/jaPBe/

GPI wrote:The problem was the additonal japbe-constants. I have correct this.

please only download the complete file, when the uiu doesn't work:
http://gpihome.de/purebasic/jaPBe/

thank's , uiu and japbe work fine

fsw wrote:Does that mean that now DLL's generated by PureBasic can OFFICIALLY be used with applications programmed with other compilers

Nothing change here, it allows you to use your dll in VC++ (or any other compilers) for your own projects easily.

Err, sorry to repeat myself, but i would like to know
Je sais, je suis chiant

Ahh, it looks like it is aXend's COMLIB that is causing me the problems..

I'll see if he can recompile it or something.. Does he just need to use the latest tailbite or wait for a future version that supports the soon-to-be 3.93 ?

It depends; if he doesn't use arrays nor linked lists, a recompile with the current TailBite version should be enough. Otherwise, it'll have to wait for the final PB 3.93 release, and subsequent TailBite release.

Regards,

Fred wrote:

fsw wrote:Does that mean that now DLL's generated by PureBasic can OFFICIALLY be used with applications programmed with other compilers

Nothing change here, it allows you to use your dll in VC++ (or any other compilers) for your own projects easily.

And all this time I thought it's prohibited to use pb's lib functions in dll's for other compilers... :roll:

> all this time I thought it's prohibited to use pb's lib functions in dll's for other compilers... :roll:

It depends on how you're using the PureBasic lib functions. See Num3's
explanation here: viewtopic.php?t=8895

In other words, you can't just "wrap" the PureBasic functions in the DLL...
You need to code your own actual routines, or use the Win32 API instead.

@pb: Thanks for pointing me to the right topic.

The newest help file says (under 'Terms And Conditions'):

All components, libraries, and binaries are copyrighted by Fantaisie Software. The PureBasic license explicitly forbids the creation of DLLs whose primary function is to serve as a 'wrapper' for PureBasic functions.

Some time ago I coded an EVENT-DRIVEN OOP-GUI that I use for my own projects.
Because of OOP's and EVENT-DRIVEN nature it's not a wrapper of pb's gui commands, but rather a big pile of code.

But now I'm also a FreeBASIC user - and would like to use it with this compiler too.
And maybe when my OOP-GUI is grown up (still some inconsistencies and quirks in it...) make it usable for somebody else...

fsw wrote:@pb: Thanks for pointing me to the right topic.

The newest help file says (under 'Terms And Conditions'):

All components, libraries, and binaries are copyrighted by Fantaisie Software. The PureBasic license explicitly forbids the creation of DLLs whose primary function is to serve as a 'wrapper' for PureBasic functions.

Some time ago I coded an EVENT-DRIVEN OOP-GUI that I use for my own projects.
Because of OOP's and EVENT-DRIVEN nature it's not a wrapper of pb's gui commands, but rather a big pile of code.

But now I'm also a FreeBASIC user - and would like to use it with this compiler too.
And maybe when my OOP-GUI is grown up (still some inconsistencies and quirks in it...) make it usable for somebody else...

fsw you bring up a good point that has buged users for a while. Why is this limitation in PureBasic. Just imagine if Microsoft had that in there API Fred couldn't even make his compiler. Programmers wrap libraries all the time. The C runtime for example is probably the most used in wrappers for other languages. Imagine how unpopular C would be if it had such odd restrictions.

I know the bid deal about a whole other language being built from PureBasic but instead of be offened just realize that it is a compliment and a promotion of your product being so good. These statements of limitation just scare users away and I know that Fred and company just want to protect there intelectual property but then there should be A LOT more detail on what this clause means to the users.

RJP, I don't think it unreasonable to forbid wrapping of PB commands. Otherwise other less honest BASIC authors might just wrap up PB commands and pass them off as their own.

I can't imagine a time when you need a wrapper DLL around PB commands except for the explicit purpose of ripping PB commands off to pass as "native" for some other language. PB doesn't have anything all that special that isn't offered through the win API or through any other language worth a salt. PB's value is in it's ability to be used as a single language to develop small, fast applications.

Having said that, there is no way to prevent this from happening so only honest users are going to abide by the license.