I was thinking of two problems with TailBite that some people have mentioned.
It's the fact that some TailBite libs will break after a PureBasic update, and the
users have to wait until the original author updates them. Not good. Also, the
users run the risk that if the original author decides to stop updating the lib for
whatever reason, the lib they depend on may cease to exist.
So, my suggestion is this: since TailBite creates the lib from an everyday
normal PureBasic source, maybe the source could be included, but also
encrypted, with each lib. So TailBite would read the encrypted source
and then compile the library using the latest PureBasic version, thus
allowing the lib users to do it without waiting for an official update.
Know what I mean? So the lib's author can keep it closed-source
if he desires, and the lib is effectively made future-proof, even if
the lib author decides to no longer maintain it.
Suggestion for future-proofing TailBite libs
Moderators: gnozal, ABBKlaus, lexvictory
Suggestion for future-proofing TailBite libs
I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.
"PureBasic won't be object oriented, period" - Fred.
what happens if a pb-command changes and you have to change that in source ?
i said no, no more encrypted sh*t .
Not the same as drm, please no.
-Source- is the only solution to avoid such, see PBOSL .
and remember, such a construct forces ppl
to encrypt (watch with a debuggertool) it
i said no, no more encrypted sh*t .
Not the same as drm, please no.
-Source- is the only solution to avoid such, see PBOSL .
and remember, such a construct forces ppl
to encrypt (watch with a debuggertool) it
Last edited by Rings on Thu Feb 28, 2008 10:44 am, edited 1 time in total.
SPAMINATOR NR.1
> what happens if a pb-command changes
True, I didn't think of that.
> no more encrypted sh*t
A lib without a source is effectively encrypted anyway, so that's irrelevant.
I wasn't asking for this for open-source libs, but for closed-source ones.
True, I didn't think of that.
> no more encrypted sh*t
A lib without a source is effectively encrypted anyway, so that's irrelevant.
I wasn't asking for this for open-source libs, but for closed-source ones.
I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.
"PureBasic won't be object oriented, period" - Fred.
-
- PureBasic Expert
- Posts: 4229
- Joined: Sat Apr 26, 2003 8:27 am
- Location: Strasbourg / France
- Contact:
Imho, one problem about PBOSL is that it's not maintained as it should / could be (no offense meant to anybody).Rings wrote:-Source- is the only solution to avoid such, see PBOSL .
Iirc, but I may be wrong, there are libs not working with PB4 and/or having problems with unicode / threadsafe (and PB4 is already 1.5 years old), and not many new libs are created.
For free libraries and tools, visit my web site (also home of jaPBe V3 and PureFORM).
the libs from pbosl, that comes with pb source, can also be used directly with source (also calling a ProcedureDLL directly in PB has no problems).gnozal wrote:Imho, one problem about PBOSL is that it's not maintained as it should / could be (no offense meant to anybody).Rings wrote:-Source- is the only solution to avoid such, see PBOSL .
Iirc, but I may be wrong, there are libs not working with PB4 and/or having problems with unicode / threadsafe (and PB4 is already 1.5 years old), and not many new libs are created.
The Problem mostly is that nobody looks into the sources
SPAMINATOR NR.1