Could someone make a list of FreeBASIC GUI libraries/frameworks?

[Munair]

I am smilar "user" like JJ but he ask interesting questions:

- what exactly is the market niche of FreeBasic?
: i am not sure what that might be.
- why would anybody use a BASIC dialect that looks more and more like C++?
: yes indeed why ?
- which kind of user needs the C++ features, and why would they use FreeBasic instead of C++?
: i don't know which ..because i don't see big amount of C++ OOP users here ?
- why is this forum so crammed full of threads discussing the setup problems when trying to make xyz compile?
: compilation types is too confusing ,is really nececery to have all that command line options?

Not like C++, but rather like C.

[jj2007]

- why is this forum so crammed full of threads discussing the setup problems when trying to make xyz compile?
: compilation types is too confusing ,is really nececery to have all that command line options?

Hi Aurel,

There's nothing wrong with command line options as long as the defaults work fine (in practice, on Windows all I need is subsystem:console or windows). The real 'setup' problems here are...
a) 4 or 5 'backends' exist in parallel (gas, gcc, clang, mingw,...)
b) several competing IDEs are available (most are very good)
c) there is not one GUI framework (the topic of this thread) but several competing ones (and they are huge)
d) there is no clear and consistent rule where to place includes and libraries, especially when they would conflict among themselves
e) as a result, people need to fumble paths in environment variables, so sharing code is almost impossible

Compare that to Masm32:
a) 4 backends (M$ MASM, UAsm, AsmC, JWasm) but they do exactly the same - 100% compatible
b) beginners are pointed to one editor included in the download package (qEditor, not my taste but works just fine)
c) Gui framework is WinAPI (which is actually huge but produces 1024 byte windowed 'applications')
d) all includes refer to \Masm32\include, i.e. a path relative to the root of the current drive; old-fashioned but works like a charm
e) no need for any environment variables

[marcov]

True. I have no stakes in this since I am more an outside observer than a frequent FB user. My main problems are:
- what exactly is the market niche of FreeBasic?

Rumoured to be gaming, but that is mostly based on fbgfx being in the core distribution. And that might be bit archaic, both as the conviction that that fact makes the whole project gaming oriented, and as that fbgfx is an old (non 3D accelerated) way of doing games.

Moreover, the focus of little games seems to have moved away from PC to mobiles/tablets.

- why would anybody use a BASIC dialect that looks more and more like C++?

I also worry that the own vision for FB is too thin. The default seems to be copying C/C++ 1:1.

- which kind of user needs the C++ features, and why would they use FreeBasic instead of C++?

Yup. I call this the "cut out the middleman" argument.

- why is this forum so crammed full of threads discussing the setup problems when trying to make xyz compile?

This is IMHO not so bad. Open Source projects are in general a bit more diversified. But in time as soon as certain combinations pull through as default (e.g. Editor X + FB + libraries A,B,C and relevant DLLs) a good bundle would solve many of these things. (see the "I want a big bundle" thread)

On Windows at least. Linux remains an open wound in that respect, since everything has to be redone for every distro in every version. But maybe that in time a FLATPACK or so will make this easier, but personally seeing is believing(*).

(*) and then I mean a long term maintained FLATPACK that works on multiple distributions, not a one-off demonstration.

[dodicat]

jj2007
Environment variables for .a and .bi in fb files??

.a files go into the lib folder
.bi files go into the inc folder.

[marcov]

d) all includes refer to \Masm32\include, i.e. a path relative to the root of the current drive; old-fashioned but works like a charm

Hardcoded paths are always bad. On Windows you can specify everything relative to the relevant binary. So if most binaries are in %somedir%\bin, libraries are getpath(runningbinary)\..\libraries, includes are at getpath(runningbinary)\..\inc etc.

This means that you can have e.g. a release and development version on the same drive. And a 16-bits build, and a 64-bit build of both. (true example for FPC. I haven't made 8-bits builds (AVR) yet)

[jj2007]

jj2007
Environment variables for .a and .bi in fb files??

.a files go into the lib folder
.bi files go into the inc folder.

Absolutely, it's that simple! (note I am not a frequent FB user)

Code: Select all

98954   16.03.2019  12:23:26    doc\Print_to_Pdf-master\version_1.1\libPrint2Pdf_32.a
45108   08.03.2019  19:51:06    doc\Print_to_Pdf-master\libPrint2Pdf32.a
647940  31.01.2016  14:47:37    Fb64\lib\freebasic\win64\libfb.a
21808   31.03.2018  17:27:29    Fb64\lib\libLinked_Lists.a
3028    11.08.2008  09:14:00    FbEdit\Projects\Addins\fbShowVars\addins\libfbshowvars.dll.a
38560   21.08.2007  12:00:04    FbEdit\Projects\Addins\fbShowVars\needed\freebasic\lib\win32\libdisasm.a
6256    21.08.2007  12:00:04    FbEdit\Projects\Addins\fbShowVars\sample\libshowvars.a
8918    05.11.2007  08:25:38    FbEdit\Projects\CustCtrl\FBEPictView\libFBEPictView.a
3890    13.05.2007  19:50:32    FbEdit\Projects\CustCtrl\FBEVideo\libFBEVideo.a
3980    13.05.2007  19:50:34    FbEdit\Projects\CustCtrl\FBEWeb\libFBEWeb.a
6256    31.12.2000  23:00:00    FbEdit\Projects\Samples\Debug\libshowvars.a
349806  22.09.2016  16:23:58    lib\pcre-839-static\win32\libpcre.a
24286   27.12.2010  17:47:09    lib\win32\Cairo\libcairo-gobject.dll.a
3658    31.01.2016  12:09:12    lib\win32\libaclui.dll.a
5126    19.02.2020  22:22:57    Members\Chung\midipiano_dll\libmidipiano_dll.dll.a
2218    17.02.2019  22:48:35    Members\Juergen\FB64\lib\win64\lib6to4svc.dll.a
690364  14.08.2019  14:04:22    Members\Juergen\fbc-array\new\libfbmt_32.a
23214   01.04.2013  12:30:12    PngLib\libpnglib2.a
3028    16.12.2008  21:29:25    Projects\Addins\fbShowVars\addins\libfbshowvars.dll.a
38560   16.12.2008  21:29:26    Projects\Addins\fbShowVars\needed\freebasic\lib\win32\libdisasm.a
6256    16.12.2008  21:29:25    Projects\Addins\fbShowVars\sample\libshowvars.a
8918    03.11.2007  22:33:32    Projects\CustCtrl\FBEPictView\libFBEPictView.a
3890    23.08.2007  21:57:18    Projects\CustCtrl\FBEVideo\libFBEVideo.a
3980    23.08.2007  21:57:20    Projects\CustCtrl\FBEWeb\libFBEWeb.a
6256    23.08.2007  21:57:24    Projects\Samples\Debug\libshowvars.a
3658    31.01.2016  11:09:14    WinFBE_Suite\FreeBASIC-1.06.0\lib\win32\libaclui.dll.a
24456   25.03.2019  20:31:49    libminz_32.a

27 different folders containing *.a files found

P.S.: test your own setups

[aurelVZAB]

Well it looks to me that JJ have right in some points but
on the other side i don't see very much bigger simplicity in using masm
and that is why I prefer simple compiler like Oxygen
1. one compiler which compile dirctly into .exe
2. include can be anywhere included( just need simple path), in most cases where is your program source
3.Direct support of native WinApi trough win.inc
4, if you wish to use another api like openGL,SDL,iUP just add required dll into same folder where your program is .
that is it.

Ahh editor ..i have my own ..heh!

[aurelVZAB]

4 or 5 'backends' exist in parallel (gas, gcc, clang, mingw,...)

I don't know for what is all that good , gcc is ok if you work on Linux ,but then for gui app you need version for GTK
right?
For backward compatibility with QB..hmmm, i don't see real reson for that ,by the way there is alredy existing "clone" called QB64.

[jj2007]

i don't see very much bigger simplicity in using masm

Masm as a language is neither simple nor complex. The learning curve is a bit steep, but you can get along with a few dozen instructions, like mov, add, inc, sub etc. Compare that to the 1000+ commands of C++.

But that's not the point here. It's the setup, and that is done in 2 minutes for the Masm32 SDK (see here, steps 1-4).

From 199x to about 2017 I programmed a lot with GfaBasic. One of my sources was about 600kB as plain uncommented text, so well beyond Hello World proggies. Installation was done in 2 minutes, and I mean: done. No need for header files etc, the whole WinAPI was already integrated in the editor. In these 20+ years of programming with Gfa, I never learned what "include file" meant - no joke. The damn thing just worked, and at the time it beat C compilers for speed. I would still be using that language if there was a 32-bit implementation.

GfaBasic deserved the B in the title (and the A, too).

[Imortis]

...Search e.g. on unit or module system on this forum. It is not the first time (I brought it^H^H^H^H ) it came up.

Searching that on the forum just brought up a post from a while back of you saying there "search the forum for unit system or module system" so that was not terribly helpful.

From what I can see, it is just about not separating implementation from interface? If that is there case, there is absolutely nothing keeping you from doing that in FB. Just include a .bi or .bas file with both the Declares and Function bodies.

Is there some benefit that I am not seeing here?

[marcov]

From what I can see, it is just about not separating implementation from interface?

No. It is not just that. The base principle is separate compilation, like C does for multiple C files.

However there are multiple ways to practically implement that. Header/C file is basically rock bottom, with little checking. While C files are compiled separately, the header is still a dumb include.

If that is there case, there is absolutely nothing keeping you from doing that in FB. Just include a .bi or .bas file with both the Declares and Function bodies.

The whole point of module systems is that you don't do that. IOW that the state of the compiler is reset at the start of each compilation unit. This means you can compile the module independent from the source where it is used.

C is not entirely clean in that regard, because you still #include the header, so it _does_ get all the state before it is included, and this could be different when #included from source a.bas compared to when b.bas includes it. This means that headers must be recompiled everything they are used, which slows down compilation (you can imagine a fat windows.h header included in multiple C files can slow down quite a bit). Moreover, different sources can interpret headers slightly differently.

Is there some benefit that I am not seeing here?

One of the big problems with the C model is that the compiler doesn't notice things being out of sync. It also doesn't know which files to compile (must be done by makefile or something). The makefile does some crude checks with filetimes, but often you only notice if already compiled files don't match when linking.

Other systems do this differently. Pascal stores the declaration part in a separate file, and even parts from the compilation that are used directly. (e.g. inline functions and templates). This means that in Pascal you can inline functions that are not entirely in the header. Similarly the template doesn't have to be completely in the header. Also, this precompiled file has a checksum over a binary representation of the declarations, and every compiled file (.o file, or a file with associated metadata) lists these checksums.

This way if you have a units A en B that both use unit C, but have different checksums for the interface, then either one of the units will be automatically rebuilt, or if that still causes problems (e.g. there are multiple source files called "C"), the compiler halts with an error.

This avoids enormous list of missing symbols (that are often not very clear, specially when they are mangled like in C++) at the linking, and aborts earlier, so saves time.

But this is fairly old, though efficient. Java and C# do it differently. They don't have a separation but still each file is compiled in isolation. Symbols declared before the include (IMPORT/USING in C#/Java )or preprocessor state (#define) USING) don't influence the files that are referenced that way. But these languages work totally different internally, and often don't even compile the complete program before they start running.

Some terminology to search on. Assume a program is split into multiple parts.

- separate compilation, compile parts of a program separately from others. https://www.cs.bu.edu/teaching/c/separate-compilation/
- compilation unit. Each part of a program tsuch a split program in isolation. So the main ".c" file is a part, and all the other c files are also each a part. https://en.wikipedia.org/wiki/Single_Compilation_Unit
- unit system or module system: a system to also keep the above parts automatically in sync, and not only keep the implementation (.pas/.c./bas) but also declaration parts in a separate isolated compile. This is a form of https://en.wikipedia.org/wiki/Modular_programming

In Pascal you just point to the main file, and specify some search dirs, and the compiler will automatically compiler everything. No makefile or the like needed. A second compile will automatically only compile changed parts and parts that depend on it.

I can't find a large post quickly, but here are some fb.net threads with longer posts from me talking about it.

best I could quickly find:
viewtopic.php?f=17&t=14640&hilit=module+system

viewtopic.php?f=9&t=26728&p=247884&hilit=unit+system#p247884
viewtopic.php?f=2&t=26466&p=244109&hilit=unit+system#p244109
viewtopic.php?f=17&t=26275&p=242352&hilit=unit+system#p242352
viewtopic.php?f=17&t=14640&p=126653&hilit=unit+system#p126653
viewtopic.php?f=2&t=12517&p=109157&hilit=unit+system#p109157
viewtopic.php?f=3&t=11717&p=102450&hilit=unit+system#p102450
viewtopic.php?f=14&t=9540&p=85594&hilit=unit+system#p85594
viewtopic.php?f=8&t=25923&p=237949&hilit=module+system#p237949

[Imortis]

Thanks. That helps quite a bit more. I now understand what you mean by modules.

[Munair]

i don't see very much bigger simplicity in using masm

Masm as a language is neither simple nor complex. The learning curve is a bit steep, but you can get along with a few dozen instructions, like mov, add, inc, sub etc. Compare that to the 1000+ commands of C++.

No higher language should be compared to ASM. It is unavoidable that higher languages have more commands because they are designed to be an abstraction (such as the definition of types) that makes it easier for programmers to get the job done (arguably some HLL's may be more successful in this than others). Just look at a compiler's code necessary to manage types and compare that to the code needed to emit actual machine instructions, which is just a fraction.

Have you worked with NASM?

[Munair]

Pascal stores the declaration part in a separate file, and even parts from the compilation that are used directly.

I think one of the issues with (Free)Basic is that it doesn't have a clear declaration part. Pascal is more structured in this respect, which gives its compiler an advantage.

[dodicat]

You know Munair, I tried a little graphical thing on the freepascal site, just a screen and some circles and lines, (The travelling salesman algo), which is really very boring if you cannot show his/her route on the screen.
I got blasted for using the unit graph and wincrt units, way too out of date.
But there is no alternative unless you install Lazarus, but I don't want to install Lazarus to draw a few lines on a screen.
Even Microsoft Quick pascal had graphics.
So the issue with freepascal is that it is doesn't have graphics.
If I use Winapi stuff on freepascal, or even msvcrt.dll functions I get criticised for being windows only.
Virtually the whole of freepascal now comprises of the Lazarus faithful, black boxers.
(Probably get kicked off the freepascal forum now)