Future and backwards compatibility

[Mistrel]

Can you answer this question:

If I write a Tailbite library that does not make use any functions from the PureBasic standard libraries would it still be susceptible to breaking in future versions of PureBasic?

I know that most (if not all) pre-4.0 Tailbite libraries broke from the update, as well as libraries from 4.10 to 4.20.

My concern is how to write a Tailbite library that is as impervious as possible to breaking from an update.

Do you know of any advantage in this to writing a PureBasic library in C/C++ instead of PureBasic/Tailbite?

[DoubleDutch]

I would like to know the answer to this too. Ideally there should be a way to write a single lib that wll work normally/multithreaded/unicode that will not break on updates to the string lib. Does this need to be done in C?

[lexvictory]

Sorry to drag up such an old thread, but in case you were both still wondering:

Yes, the only way to make a lib that won't break with an update is to code it in ASM (raw, non-PB kind)/C
Unless you can get it to not depend on internal PB libs (pretty impossible IMO). You can check this by looking at the commented asm output from pbcompiler. Look in the header.

; The header must remain intact for Re-Assembly
;
; Memory
; :System
; KERNEL32
; :Import
;
;

If the Memory PB lib is changed/renamed, this lib will break.

[blueznl]

Then don't write libs, write includes...