FB dll for PowerBASIC

New to FreeBASIC? Post your questions here.
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FB dll for PowerBASIC

Post by dodicat »

I tried extern "Windows" in the dll.
But it is not needed.
The 'end extern should have been rubbed out.

Powerbasic can grow.
It defines itself.
FreeBASIC (IMHO) has stagnated due to the C backend.
FreeBASIC developers now must be experts in C.

I prophesied this a while ago.
When something loses originality it dies after a while.
For FreeBASIC to grow, gcc must grow.
But where's the sense in that?
St_W
Posts: 1619
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: FB dll for PowerBASIC

Post by St_W »

dodicat wrote:FreeBASIC (IMHO) has stagnated due to the C backend.
FreeBASIC developers now must be experts in C.
I prophesied this a while ago.
When something loses originality it dies after a while.
For FreeBASIC to grow, gcc must grow.
I don't know whether FreeBasic grows or not (and in what sense you're meaning that) but making the C backend responsible for any FreeBasic issues is just wrong. The new backend didn't change anything of the language or its usage and neither does FB depend on any special gcc features or requires users to be "experts in C". The backend is (nearly) completely transparent to the user and as a user one doesn't have to care whether one's using the old gas backend or the newer gcc backend.

Maybe you could give some examples what would be better assuming that the gcc backend wouldn't have been written?
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: FB dll for PowerBASIC

Post by deltarho[1859] »

Had PowerBASIC's author, Bob Zale, not died in 2012 then the flagship products would probably be on versions 11 and 7 with 12 and 8 just a couple of years from today according to the cycle since I bought back in 2003. A 64 bit compiler would, probably, have been published about three years ago.

Bob would not tolerate any nonsense at the forums. Nonsense crept in fairly quickly after his death. Whilst many members were, and still are, courteous and honourable the rest degenerated into a shower [British, informal, disapproval] and most of us know what happens if a barrel of apples has some bad ones. Hopefully, Adam Drake and his brother at Drake Software will not tolerate any nonsense either. Drake Software was established in 1977 and has in excess of 325 employees.

For PowerBASIC to survive I reckon something 'big' must happen in the next 12 to 18 months. I hope so.
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FB dll for PowerBASIC

Post by MrSwiss »

[off topic]
@dodicat,
dodicat wrote:FreeBASIC developers now must be experts in C.
Before, they had to be experts in ASM (by the very same token)!

I'm not certain, that those are easier to find, nowadays.[/off topic]
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FB dll for PowerBASIC

Post by dodicat »

St_W
It would have been better if 64 bit FreeBASIC wasn't purely Gcc.
I know it would have been a load of extra work, but I think that FreeBASIC would have been better for it, and perhaps the development team would have grown, not shrunk.

Original / Clone
There is a difference.
OK the libraries were mostly always written in C.
But that is acceptable.

All this is only my own opinion of course.
And I realise that a C back end had been in the offing early on in FreeBASIC.
But total C future?
Seems a dead end to me.
But again IMHO only.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: FB dll for PowerBASIC

Post by marcov »

dodicat wrote: Original / Clone
There is a difference.
OK the libraries were mostly always written in C.
But that is acceptable.
Not dogfooding wrt libraries encourages substandard thinking, which was the first step to having gcc as backend. :-) Good enough is a slippery slope.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: FB dll for PowerBASIC

Post by caseih »

dodicat wrote:Powerbasic can grow.
It defines itself.
FreeBASIC (IMHO) has stagnated due to the C backend.
FreeBASIC developers now must be experts in C.

I prophesied this a while ago.
When something loses originality it dies after a while.
For FreeBASIC to grow, gcc must grow.
But where's the sense in that?
Sorry but that doesn't make any sense. What does any of this have to do with gcc? Lots of current, popular, growing languages, compile to C. I don't understand at all why you think a C backend causes stagnation. A C backend is no different than an ASM backend. Why must FreeBasic users become experts in C? One of FB's strengths is how easy it is to interface with C libraries. And of course you do need to know a little C to use these libraries effectively. But FB itself requiring C knowledge?

FB is stagnating, but not because of C. It's because it's essentially a volunteer effort and those that were volunteering have moved on to other projects and endeavors. But the bigger problem is that very few FB users can agree on what FB should be. Should it be a tool for maintaining QB-era code or should be a new language that embraces features like OOP and lambda functional programming? And if it does the latter, is it really BASIC anymore, and if not, how is it better than any number of other non-BASIC languages out there?

I'm sorry to say that PB is dead and has been dead for years now. And despite the buyout I don't see it going anywhere. The main reason is that it's a bunch of legacy ASM code. So far as I know it's not even 32-bit ASM code even. It was a marvel in its day, but now it's stuck where it is. No chance of using it on ARM, little chance of using it on 64-bit Windows. Also charting ones own course is a blessing and curse. As PB charted its own course, it became it's own proprietary language. So with PB dead, you have to port the code to another BASIC compiler, which isn't an easy task.
St_W
Posts: 1619
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: FB dll for PowerBASIC

Post by St_W »

dodicat wrote:It would have been better if 64 bit FreeBASIC wasn't purely Gcc.
I know it would have been a load of extra work, but I think that FreeBASIC would have been better for it, and perhaps the development team would have grown, not shrunk.
[...]
And I realise that a C back end had been in the offing early on in FreeBASIC.
But total C future?
Seems a dead end to me.
I do not see a big advantage of a GAS backend for 64-bit. Neither do I see any disadvantage of having a GCC backend. Using C libraries doesn't work better or worse with the GCC backend than with the GAS one. And the GCC backend doesn't encourage to use C code instead of FB code.
dodicat wrote:Original / Clone
There is a difference.
I do not understand - what do you mean is original or a clone?
Josep Roca
Posts: 564
Joined: Sep 27, 2016 18:20
Location: Valencia, Spain

Re: FB dll for PowerBASIC

Post by Josep Roca »

> So far as I know it's not even 32-bit ASM code even.

It is 32 bit since many years ago, otherwise won't run in 64-bit versions of Windows. Its future is uncertain because its author died. Could be further developed by the new owners; could be translated to a mix of Power Basic code and assembler to allow self-compiling... We don't know what will happen.

Some Power Basic users have come here in search for a Basic compiler that allows to write both 32 and 64 bit applications. I have written a framework for Windows, Paul Squires is working in an editor and a few others are working on other projects. Using Free Basic is easy for a Power Basic user that is skilled in the use of the Windows API.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: FB dll for PowerBASIC

Post by marcov »

caseih wrote: Sorry but that doesn't make any sense. What does any of this have to do with gcc?
How do you grow into FB development? Can you use FB at any level without hitting the influence of C? (just start with the heavy preprocessor use in sources posted on this forum)
Lots of current, popular, growing languages, compile to C.
Yes, but they usually have other driving forces other than beginners, like major multinationals pushing them.
I don't understand at all why you think a C backend causes stagnation.
  1. C features bleed through into the frontend due to quick-fix choices, rather than design.
  2. non C language features (e.g. deviant stack frame handling or choices) are difficult or a forever pain in the *
  3. developers need multiple language skills, knowledge of arcane *nix build procedures and C runtimes.
  4. platforms changing compiler mean extra trouble (LLVM on Apple and FreeBSD).
  5. Users too. Much less in proportion of course, but proportionally also much less equipped to deal with it
  6. Open source compilers pretty much suck on non Unix, Windows inclusive. UNC drives, spaces in names, path length and commandline limits, bad catering for Windows more costly project creation, the list goes on. Love or hate it, but Windows is a tier one, if not absolute number one target.
  7. Managing and following it costs time that is pretty much losts, rather than going into a fundament you can build on.
These are challenged, and in theory they could be dealt with. In practice all solutions are Πss poor makeshift compromises, though the improvements of mingw gcc has brought some relief. After two decades of pain that is.
A C backend is no different than an ASM backend.
Yeah, as in both are temporary solutions till you poop out the binaries directly. (GAS intel mode bugs anyone?) External code is pain.
FB is stagnating, but not because of C. It's because it's essentially a volunteer effort and those that were volunteering have moved on to other projects and endeavors. But the bigger problem is that very few FB users can agree on what FB should be. Should it be a tool for maintaining QB-era code or should be a new language that embraces features like OOP and lambda functional programming? And if it does the latter, is it really BASIC anymore, and if not, how is it better than any number of other non-BASIC languages out there?
The fact that your reasons are absolutely true, doesn't mean that the C hypothesis isn't. Even though I absolutely dislike the C route (mainly because it never stays in the backend, but one could argue that with a RTS in C, FB was already a goner), I'm not sure that if the C route was a main killer.

This because most of the disadvantages I cite are more on the longer term, and FB avoided the epochs that were really a pain. So acceleration of the 64-bit target might have been worth it, at least on the timescale from introduction till now.

But I don't doubt that it moved FB away from any pretence of newbie friendliness, and maybe even developers. They would have encountered the forum, looked at the average content, and decided to cut out the middleman and go directly to C++
I'm sorry to say that PB is dead and has been dead for years now. And despite the buyout I don't see it going anywhere. The main reason is that it's a bunch of legacy ASM code. So far as I know it's not even 32-bit ASM code even. It was a marvel in its day, but now it's stuck where it is. No chance of using it on ARM, little chance of using it on 64-bit Windows. Also charting ones own course is a blessing and curse. As PB charted its own course, it became it's own proprietary language. So with PB dead, you have to port the code to another BASIC compiler, which isn't an easy task.
In short PB is like VP:-) An old commercial project that never modernized, except for some haphazard twitches when it was already too late, and died while the few remaining users still think it was the greatest invention since, well, forever of course!
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: FB dll for PowerBASIC

Post by caseih »

Since the OP has solved his problem, I'll beg his forgiveness and reply here, even though we probably should have broken this out into its own topic, probably in the General section (Mods, can you do this to existing posts?).
marcov wrote:How do you grow into FB development? Can you use FB at any level without hitting the influence of C? (just start with the heavy preprocessor use in sources posted on this forum)
I think you can, absolutely. Don't mistake a preprocessor with anything C-related. Lots of non-C languages have a preprocessor meta language to ease the task of making code configurable and modular. Does metaprogramming get complicated and not-beginner friendly? Yup it does.
  1. C features bleed through into the frontend due to quick-fix choices, rather than design.
  2. non C language features (e.g. deviant stack frame handling or choices) are difficult or a forever pain in the *
  3. developers need multiple language skills, knowledge of arcane *nix build procedures and C runtimes.
  4. platforms changing compiler mean extra trouble (LLVM on Apple and FreeBSD).
  5. Users too. Much less in proportion of course, but proportionally also much less equipped to deal with it
  6. Open source compilers pretty much suck on non Unix, Windows inclusive. UNC drives, spaces in names, path length and commandline limits, bad catering for Windows more costly project creation, the list goes on. Love or hate it, but Windows is a tier one, if not absolute number one target.
  7. Managing and following it costs time that is pretty much losts, rather than going into a fundament you can build on.
How do C features bleed through into FB? Have any examples? I'm still not sure what you mean by that.

How would you do "deviant stack frame handling or choices" in any other language that needs to remain compatible with external libraries and the OS API, which uses a specific calling convention throughout the entire operating system? Are you referring to things that could be done in SmallTalk or Java because those languages run in a virtual machine with its own characteristics independent of the OS platform (they are basically their own OSes)?

I concede the point about Windows support for third-party compilers, and also FB's dependence on the Gnu linker. That's not a hard requirement of course, but might as well be until someone adds support for visual studio's compiler.
A C backend is no different than an ASM backend.
Yeah, as in both are temporary solutions till you poop out the binaries directly. (GAS intel mode bugs anyone?) External code is pain.
You mean until FB writes its own macro assembler? All compilers I'm aware of target ASM because it's the native language of the CPU. They may not keep the intermediate representation (FB doesn't either for that matter) but it's still there and you can dump it out if you want to to see what the code generator is doing. Without implementing an internal assembler I have no idea how a compiler would "poop out" binaries directly.

If you're arguing that depending on GAS instead of writing their own assembler is leading to issues from bugs on Windows, then yes, you're correct.

As far as Windows goes, yes it is the major platform out there, but for a volunteer effort, I can understand why supporting it is not the highest priority. Supporting Unix-like operating systems is so much easier, because of the standardization of the tools across platforms, and the widespread availability of really good, free compilers that come with the OS (and always have).

Getting good Windows support requires commercial intervention (or at least commercially-backed OSS projects such as the fantastic Qt, I think, since Windows is primarily a commercial OS. That's not an indictment of the free software ideal, or free software greybeards. Different traditions, combined with some radically different approaches to basic OS primitives, which makes supporting Windows quite a bit harder than supporting random Unix OS's on random CPU. I'd say porting code from Linux to Windows is almost as hard as porting code from Windows to Linux, for similar reasons. It's just that the majority of free software developers are already familiar with Linux for the reasons I mentioned earlier.
St_W
Posts: 1619
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: FB dll for PowerBASIC

Post by St_W »

caseih wrote:How do C features bleed through into FB? Have any examples?
While I do see that C concepts and features were integrated into the FreeBasic language and it got more complex and harder to use due to that (simple example: pointers) I don't think that that is related to the GCC backend. The discussion about the language itself is iMHO a completely separate topic and not related to the backend. btw I agree that the language itself has gotten more complex and would have needed a more thoroughly thought / better design before implementing certain features, but again, I don't think that this is related to the backend, which I would consider as internal implementation detail that (typical) users shouldn't need to care about at all.
caseih wrote:I concede the point about Windows support for third-party compilers, and also FB's dependence on the Gnu linker. That's not a hard requirement of course, but might as well be until someone adds support for visual studio's compiler.
I don't think that it's that easy to replace the compiler or assembler used by FreeBasic because it relies on quite a lot GCC internals, which are not available or working differently on MSVC. I once patched the rtlib / gfxlib so that they compile in MSVC and that already required lots of changes. And modifying the emitter(s) to generate MASM or whatever-compatible code is more difficult than that for sure.
caseih wrote:If you're arguing that depending on GAS instead of writing their own assembler is leading to issues from bugs on Windows, then yes, you're correct.
I don't think that a new, custom implementation of an assembler would be more bug free than GAS within reasonable time. Although writing an assembler is not utterly hard, it's no simple thing either.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: FB dll for PowerBASIC

Post by marcov »

caseih wrote: How do C features bleed through into FB? Have any examples? I'm still not sure what you mean by that.
Just that I have the feeling that lately new features align with C, and not with Basic.
How would you do "deviant stack frame handling or choices" in any other language that needs to remain compatible with external libraries and the OS API, which uses a specific calling convention throughout the entire operating system?
Only very broad assumptions, and on many architectures only till the point that you actually call the next function. Inbetween you are free.

I'm talking about nested functions accessing the parent frame, SEH-like exception systems etc.
Are you referring to things that could be done in SmallTalk or Java because those languages run in a virtual machine with its own characteristics independent of the OS platform (they are basically their own OSes)?
No, definitely not, I consider those a different world. It is more that there is a limit to what you can express in portable C together with the effort to keep such a amalgam of various projects running.
I concede the point about Windows support for third-party compilers, and also FB's dependence on the Gnu linker. That's not a hard requirement of course, but might as well be until someone adds support for visual studio's compiler.
That only strengthens my point. All that time managing various C compilers and other parts of their toolchain and their versioning is lost time.

I do realize that I probably feel too strongly about this because I have seen the GCC backend compilers pretty much all fail (except the ones with heaps of corporate sponsoring. Even Java/GCJ didn't make it). While C backend stuff has the same issues, the magnitudes are different. Still it is hardly the free ride it often is pretended to be.
A C backend is no different than an ASM backend.
Yeah, as in both are temporary solutions till you poop out the binaries directly. (GAS intel mode bugs anyone?) External code is pain.
You mean until FB writes its own macro assembler?
No, just poop out machine code .o's. No macros, no text, not needed so more an own "libbfd", not an own "gas".
All compilers I'm aware of target ASM because it's the native language of the CPU.
No machinecode is. Asm is a human representation of machinecode, which is often only used to occasionally check output, but generally is only slowing. Moreover a purely backend assembler needs to support only very little.
They may not keep the intermediate representation (FB doesn't either for that matter) but it's still there and you can dump it out if you want to to see what the code generator is doing. Without implementing an internal assembler I have no idea how a compiler would "poop out" binaries directly.
Well as said assembler is the wrong word. We use binwriter, and I've also heard the time asmlist.
If you're arguing that depending on GAS instead of writing their own assembler is leading to issues from bugs on Windows, then yes, you're correct.
It is also a problem on e.g. macosx or FreeBSD, where the default assembler is LLVM. Basically the only Tier one platforms that default to GAS are Linux and its derivative Android.

But I'm not arguing GAS, but I'm argueing creating a FB distribution and deploying it on many platforms with all their own AS versions (with their own bugs) etc. There are also speed issues (again, Windows) You can still use GAS as second rate fallback for minor targets, but it is a good thing to realize it is a stopgap rather than a goal.
As far as Windows goes, yes it is the major platform out there, but for a volunteer effort, I can understand why supporting it is not the highest priority.

Supporting Unix-like operating systems is so much easier, because of the standardization of the tools across platforms, and the widespread availability of really good, free compilers that come with the OS (and always have).
IMHO that is very weak way of reasoning to justify prior choices. Windows and the VC toolchains are very longtime stable and go back to times when GCC was cumbersome and went to a.out->ELF and GCC-vs-EGCS shenigans. And worse, every major version is incompatible again to all that came before.
Getting good Windows support requires commercial intervention (or at least commercially-backed OSS projects such as the fantastic Qt, I think, since Windows is primarily a commercial OS
I also think this is nonsense. Many OSS projects came from DOS e.g. BBS) origins, not Unix which was unaffordable till the late nineties.

I see as *nix as a bad construction kit that is never finalized. (and I say that as a Linux user since '96, and BSD user since '91, and some assorted commercial Unix thrown in for good measure)
That's not an indictment of the free software ideal, or free software greybeards. Different traditions, combined with some radically different approaches to basic OS primitives, which makes supporting Windows quite a bit harder than supporting random Unix OS's on random CPU.
IMHO those hardships only come from first chosing a direction, and only then judging Windows based on the principles of the direction already chosen. In reality, an investment in Windows binary generation in '95 still largely pays of to this day. Would wish I could say the same for *nix. (for interested people, I still have a syscall based RTS from '95, for people that want to have a go at porting)
I'd say porting code from Linux to Windows is almost as hard as porting code from Windows to Linux, for similar reasons. It's just that the majority of free software developers are already familiar with Linux for the reasons I mentioned earlier.
I think the majority of software developers is familiar with Windows. Yes, even today. Only if you first preselect the wider development community with adjectives that are equal to "linux developer"

Btw, I was a *nix user since early nineties, and *nix developer for years (roughly 1997-2008), adding FPC 1.0.x BSD targets, and redoing the entire *nix rtl for 2.0, but went back to Windows disillusioned.

p.s. as somebody from the BSD side of things I of course don't acknowledge the hacking of the word "free" by various organizations named after African ruminants. I like my free beer.
Last edited by marcov on Aug 02, 2017 5:10, edited 2 times in total.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: FB dll for PowerBASIC

Post by caseih »

Fair points, Marcov. FB was originally written in QB and obviously DOS-based. Even after FB was self-hosting, at what point did it become reliant on the Gnu linker chain?
TeeEmCee
Posts: 375
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: FB dll for PowerBASIC

Post by TeeEmCee »

I have to agree with St_W that the design of FB being inspired by C, and FB libraries and backends being implemented with C, are mostly different issues.

Yes, keeping support for compiling to C does impose some annoying limits. For example I really wish that FB supported nested functions. And yes, GAS as a backend sucks. It's even worse than compiling to C-with-GCC-extensions. (FB does use some GCC extensions, which is something I really want to be rid of.)
I agree that over the long run it would have been less work, less pain and even more portable for FB to generate machine code directly instead of assembly.
But what's this about FB's Windows support being bad? As a Linux user, I never noticed. I compile my FB code on Windows without problems. OK, I'm guessing maybe that's what this thread is about, but I haven't read it.

Writing the rtlib in anything other than C seems like a pain, needing to translate the system headers for every flavour of Unix. So FP is written purely in FP? How does it do that? Does it call into libc for Unix system calls, or use syscalls?

Yes, FB is very very heavily inspired by C and C++. I always describe FB as a superset of C and subset of C++ with BASIC syntax, better strings, and a graphics library. Features of C/C++ have been methodically copied verbatim into FB over the years. I do question whether this was a wise design. However, personally I'm quite happy with it, because I link lots of C, C++ and FB code together, and it makes interoperability easy. So I'm reliant on a C++ compiler anyway.

But you're mistaken in arguing that FB supporting features of C is because FB compiles to C or uses library written in C. FB has all these features of C because they've been reimplemented from scratch, not because it relies on a C compiler.
Of course, if you dig you will find semantics of the C runtime or ncurses libraries that bubble through to FB (e.g. the effect of LANG environmental variable on 8bit -> wstring conversions)
Post Reply