Printable View
Hi all.
We are experimenting the creation of thinBasic SDK specific for Freebasic.
Still some little bug to fix and some Freebasic behave to understand.
If we will succeed, a lot of new options will be available to thinBasic arsenal.
Stay tuned.
Eros
Eros, what does that mean? Sorry for my confusion?
1. FreeBasic I think supports OOP, so does this mean use freebasic for the oop parts and tie it into thinBasic?
2. Or does that mean making true compiled apps?
Also there is talk about freebasic being a front end to a very popular compiler I think? Does that tie into that also?
Thanks for info when you have time.
It will just mean that you will be able to create thinBasic module (so compiled code) using Freebasic as development language like we do using Power Basic. Nothing more. Nothing will change in script structure.
At the moment we are changing some thinCore interfaces to be suitable with Freebasic. One problem is that Freebasic has no EXTENDED data type (10 bytes of pure power) so we need to use Double numbers for floating point numeric interfaces. We heavily use Extended inside thinBasic so we have to make some internal arrangements.
Another problem is the strange (for us) way to manage external dlls. This is mainly due to the way Freebasic use linker. So we are making all the thinCore interfaces as static linking lib to be found by Freebasic linker.
Remember, Freebasic, like many other "compiler" around, is not a real compiler but a sort of translator from Basic sources to ASM sources. Then ASM source is compiled into an obj file and linked, to finally produce an executable. I'm not aware of any further Freebasic development rumours because I just started yesterday to look at Freebasic so, for the moment, I'm getting into step by step day by day. I've already produced my first module developed using Freebasic but before releasing the SDK interface I want all the main problems fixed.
Ciao
Eros
I see thanks Eros, I looked at FreeBasic and it seems it is undergoing heavy development and because of this with many new releases programs before need lots of rewriting, at least the impression I got from reading posts. I think once they get it to where they plan, it will be something.
On Mike's site he has support in his editor for a Basic I never heard about either named Hot Basic. It looked interesting and affordable. I don't know anything else about it. But you might want to check that out too.
That is a great idea! FB is a very good BASIC implementation and has a very dynamic community. I am looking forward to it.
We are having some problem with FB SDK.
FB seems quite unstable when creating using dynamic strings in DLL but to be honest I'm not 100% familiar with it so I suppose I still need to get many FB tricks.
Anyhow we will go on with it.
Thanks.
Eros
Situation is the following:
- no big interface problems when dealing with numbers.
Well little problems because FB has no EXTENDED data type (10 bytes) and we use it a lot in almost any numeric interfaces- some important problems when dealing with strings.
From FB help:
thinBasic uses OLE32 strings so compatibility is not there. We have to think about some internal in/out on the fly string conversion.Quote:
A FreeBASIC String is essentially a built-in user-defined type that, among other things, contains a pointer to the string data and it's length. This type is called a 'descriptor' internally, and it is this descriptor that is passed to procedures when it's parameters are passed by reference.
When passed by value, however, the actual string data is passed, not the descriptor. Internally, the string data is terminated with the NULL character (chr(0)). When the temporary String is created for the procedure, FreeBASIC copies the string data passed up until the first NULL character. If the String argument passed contained NULL characters within the string, then the rest of the string data after the first NULL is not copied, and the string is truncated. You also run the risk of writing outside the bounds of the allocated memory.
This behavior will eventually be fixed to act as it should: a temporary descriptor will be created for the procedure and a 'deep copy' of it's fields will be made (notably, the entire string data itself will be copied into new memory, and the new descriptor will point to that memory).
To be safe, pass Strings by reference. If you need to simulate the correct behavior of passing a String by value, either 1) create a temporary String, initialize it with the String you want to pass and pass the temporary by reference, or 2) pass the String by reference and have the procedure create and initialize a temporary String and work with the temporary.
Will let you know.
Eros
Wow, sounds confusing to me for sure. Good luck, freebasic looks really nice, I was surfing around their site again this weekend. I also saw that freebasic compiles down to nice speed and size on a table for compiled languages.