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

[Munair]

Yes, I heard that before, that FPC is being maintained with Lazarus in mind these days. I think with any of these free* projects, maintenance is a big issue. If you look at FB header files, some are also very much out-of-date.

[jj2007]

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.

MASM and its clones handle types more or less like a C compiler. However, since they are macro assemblers, you can (correctly) do one-liners like Print Str$("The single: %f\n", MySingle), Str$("The double: %f\n", MyDouble), Str$("The integer: %f\n", MyInt) (it surely doesn't look like Assembly but it gets successfully assembled, so it is Assembly by definition).

Have you worked with NASM?

I had a look once, but NASM is really very limited.

[Munair]

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.

MASM and its clones handle types more or less like a C compiler. However, since they are macro assemblers, you can (correctly) do one-liners like Print Str$("The single: %f\n", MySingle), Str$("The double: %f\n", MyDouble), Str$("The integer: %f\n", MyInt) (it surely doesn't look like Assembly but it gets successfully assembled, so it is Assembly by definition).

Have you worked with NASM?

I had a look once, but NASM is really very limited.

MASM has stepped away from pure ASM too much IMO. NASM is definitely not limited, and it's very suitable as back-end for a HLL. SharpBASIC currently uses it and so far I have not found limitations that require work-arounds or anything. While I haven't looked at it yet, it is said that NASM's macro support is very powerful. A major advantage of NASM is that it is cross-platform (*nix, DOS, Windows).

[marcov]

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.

No. You probably got blasted for expecting first rate support for it, like it is 1995.

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.

And also doesn't functions out of the box anymore and neither has still support for it.

In that time probably the same kind of nagging was in the Quick Pascal fora why it didn't work on CP/M because UCSD Pascal worked so nicely on CP/M.

So the issue with freepascal is that it is doesn't have graphics.

How hard can it be?

1. install freepascal
2. launch a cmd.exe
2b. If you didn't let the installer add freepascal to the path (I usually don't), put the c:\fpc\<version>\bin\i386-win32 as first dir in the path.
PATH c:\fpc\3.0.4\bin\i386-win32;%PATH%
if you have multiple versions, make sure it is the only one in the path
3. go to c:\fpc\<version>\demo or wherever you installed it.
4. type 'make'
5 cd graph\graph (so go to c:\fpc\<version>\demo\graph\graph)
6 type "fpctris"

You should see a wincrt graph demo made by yours truly.

If I use Winapi stuff on freepascal, or even msvcrt.dll functions I get criticised for being windows only.

As long as you are aware of that, that is no problem.

Virtually the whole of freepascal now comprises of the Lazarus faithful, black boxers.
(Probably get kicked off the freepascal forum now)

Can be arranged. I know the moderator :-) (kidding)

[jj2007]

it is said that NASM's macro support is very powerful

Yes, NASM coders say that. Try to implement something simple like Print Str$("The single: %f\n", MySingle), Str$("The double: %f\n", MyDouble), Str$("The integer: %f\n", MyInt) in NASM.

A major advantage of NASM is that it is cross-platform (*nix, DOS, Windows).

UAsm and AsmC can do that, too (100% MASM clones; only masochists and Microsoft fans use the original MASM).

[marcov]

I'm more a Basm/Tasm person

[Munair]

it is said that NASM's macro support is very powerful

Yes, NASM coders say that. Try to implement something simple like Print Str$("The single: %f\n", MySingle), Str$("The double: %f\n", MyDouble), Str$("The integer: %f\n", MyInt) in NASM.

A major advantage of NASM is that it is cross-platform (*nix, DOS, Windows).

UAsm and AsmC can do that, too (100% MASM clones; only masochists and Microsoft fans use the original MASM).

I understand the features you compare, but for a compiler back-end I prefer an assembler without those kind of built-in functions that make it look like a cross-breed HLL. I've never been a fan of MASM-like syntax. IMO NASM is simpler and cleaner. Not to forget, I consider it a big plus that NASM doesn't auto-generate segment overrides as MASM & co.

[Munair]

I'm more a Basm/Tasm person

I did some TASM in the 90s. I should still have a copy of TASM 5.0 lying around somewhere. It is still installed on my 386sx (with 16MB RAM).

[jj2007]

for a compiler back-end I prefer an assembler without those kind of built-in functions that make it look like a cross-breed HLL.

No compiler back-end here, I use Assembly standalone. For the 5% of coding that I do with FreeBasic, I use an IDE programmed entirely in Assembly. Over 20k lines of code ;-)

[Munair]

for a compiler back-end I prefer an assembler without those kind of built-in functions that make it look like a cross-breed HLL.

No compiler back-end here, I use Assembly standalone. For the 5% of coding that I do with FreeBasic, I use an IDE programmed entirely in Assembly. Over 20k lines of code ;-)

SharpBASIC uses both NASM and LD.

[systemctl]

If you look at FB header files, some are also very much out-of-date.

Yes, but at least we have a working GTK+ 3 binding. Check what currently in your Lazarus and be ashamed.

We are a much smaller project. But we could do it but you can't. What a shame!

BTW, if we want we could do header update anytime we want. We have excellent tools like h2bi, fbfrog and even swig-fb. The nature of our language also make creating binding much much easier. Go home and update your h2pas, it's a shame! I know, you have a version of swig that compile, but it generated output is completely trash. Our swig-fb is much older but, just works.

We don't update the headers because we think we don't need to. You see, people use the ancient IUP 3.15 binding from 2015 but they still able to develop and build their software with the latest version of IUP. The compatibility is so good that nothing needs to modified and everything just work. If IUP doesn't break compatibility and old library versions still supported, I see no need to catch up to the latest greatest version. The latest greatest mindset is for kids, not for adults like us!

p/s: I don't against updating fbc headers, though. Updated headers are good. But I'm more concerned about a better language and compiler.

[systemctl]

I appreciate marcov for his suggestions to improve FreeBASIC but sometime I can't stop the thought that he want FreeBASIC to copy Free Pascal 1:1. I don't like the way we currently copy C++ 1:1, too. Copying Free Pascal 1:1 is impossible, as the two languages are very different. But copying C++ 1:1 is always bad. We should select the best features and technologies from both languages.

@Munair: sorry about my harsh words. But I really think you should stop hijacking my thread for your SharpBASIC language. You should create a new thread for this.

[systemctl]

I have a new library to add to the list of C/C++ GUI libraries could be used as a backend for our FreeBASIC GUI toolkit. It's a C library, so creating binding for FreeBASIC should be straight forward.

http://libagar.org/

It's not just for GUI but also includes other features like Audio, Math, Network, Vector Graphic, 3D Engine,... All are in plain C. If we have a FreeBASIC binding for it we immediately have access to a wide range of features.

[paul doe]

I have a new library to add to the list of C/C++ GUI libraries could be used as a backend for our FreeBASIC GUI toolkit. It's a C library, so creating binding for FreeBASIC should be straight forward.
...
If we have a FreeBASIC binding for it we immediately have access to a wide range of features.

Indeed! So, when are you planning to release the bindings for testing?

[marcov]

I appreciate marcov for his suggestions to improve FreeBASIC but sometime I can't stop the thought that he want FreeBASIC to copy Free Pascal 1:1. I don't like the way we currently copy C++ 1:1, too. Copying Free Pascal 1:1 is impossible, as the two languages are very different.

No, I just name Object Pascal (Delphi, FPC) because

1. I know it best
2. It is a proven solution that works.
3. the C/C++ way is a dead end and scales bad. C++ has taken steps in C++20 to fix this.
4. In the case of modules and how to divide a source in multiple independent sources, Wirth was instrumental (with Pascal and Modula2 ) in developing these modularization concepts in the late seventies/early eighties, and are considered reference languages for this.
5. I also named C# and Java that go at it in a different way, more like in the Pascal/M2 successor Oberon. Niklaus Wirth even got mentioned in the Java VM credits for this, and Component Pascal (which is actually an Oberon, and not a Pascal) was an original .NET language, together with VB, C# and I believe a Fortran?. But this is a more radically different way.

Fun fact to the latter is that Oberon actually didn't map it to files but kept the sources in a key-value database, with the classes hierarchical name as key. C#/Java were more conventional here.

So in fact you have more classes of solutions: (note this is a circa 2005-2006 era comparison when I worked a lot with C# and Java and started to think about these things)

1. (level -1) nothing like old languages that didn't have a true header/compilation unit separation, and only have one big program that includes everything in the end.
2. (Level 0) C/C++ that do separate out pieces of source (CPP/C files), but not their interfaces (.h/.hpp) that are interpreted again and again in the context of inclusion, and need guards against multiple inclusion.
3. (level 1) Pascal/M2, have an automatic namespace per unit (roughly .h + .c), and headers are not evaluated in the context of the loading program and may be cached, and that binary cache might be dumped to file (.ppu/.dcu/.sym). Namespaces are not hierarchical (there are some hacks, but that is on top of what exists)
4. (Level 2) Java/C# where everything originally was wrapped in a class. A namespace per class per file, but with hierarchical (system.os.types.bla.classA).

This also has some consequences for compiler execution and how it finds it files.

1. (level -1) Compiler is run on main file, with maybe some directories as parameters, and compiler looks into those directories for include files if needed.
2. (level 0) All files to be compiled must be explicitly named. In theory each file compile has its own set of dirs, but commonly these are kept the same for groups of units. Main file must also be explicitly singled out (last in gcc line, for linking purposes). Usually needs makefile (or project that generates that) or very complicated script to make a compile work. Even more to also allow incremental builds.
3. (Level 1) Compiler is run on main file, with maybe some directories as parameters, and compiler looks into those directories for include files (and other modules) if needed. Modules are compiled recursively and incremental build or not is automatic (but can be forced to recompile everything with parameter)
4. (Level 2) compiler is run on main file with some class paths directories. These directories contain a hierarchical structure of directories that maps to the hierarchical namespaces. Compiler automatically can search these directories (for e.g. dir+"system/os/types/bla/classA.java in above example), and recursively compile all.

Both level 1 en 2 have in common that there must be no sideeffects when compiling a file. So if you use a certain piece of code (say module A, so a.bi + a.bas in FB speak), then the compiler state when you use A from piece of source B and when you use A from piece of source C must be _exactly_ the same. This means that effectively the preprocessor/compiler state must be reset before compiling a different piece of source OR its header.

So level 0 does this for the compilation unit (.c, .bas, .cpp), but not for the header (.bi/.h/.hpp). Level 1 does it for both. Level 2 does away with headers in general, since anything is already inside a class and has visibility modifiers like protected and public. But they do reinit the compiler too.

Anyway, all that I said is part of public record. If you doubt me, just research the subject. It is fine with me. The whole thing was meant as a suggestion to look into the subject anyway, and the broader future FB devels read in on the subject, the better IMHO.

The level 0 way is easy to implement, and has also some other nice properties. Despite its excessive reinterpretation of (textual) headers, the compilation is nearly infinitely and easy to parallelize (think make -j), something that the other systems must work hard for.

But copying C++ 1:1 is always bad. We should select the best features and technologies from both languages.

It should always be because you WANT that feature, not because it is doable and you haven't looked any further. Moreover there should be some concept of where FB wants to go.