After a frankly unreasonable amount of work, I've updated https://deb.fbxl.net with FreeBASIC FBXL Edition 1.20.1.
I want to say the important part first: this is unofficial, unsupported, experimental, and built mostly by some dummy from the sticks because I wanted it to exist. The FreeBASIC core developers did the real work over the years. I came along later and pushed on packaging, ports, cleanup, docs, testing, and a few new toys. If something here is useful, excellent. If something here is broken, assume my intern who definitely exists and isn't just me probably broke it.
*Universal installer*
The front page has a universal installer that tries to detect what you are running and install the right FreeBASIC package for it.
For Debian, Ubuntu, and Raspbian-style systems, it can add deb.fbxl.net as an apt repo. For other systems it tries to do the least surprising thing for that OS.
Windows users also get standalone installers right up front. There is one for normal Win32/Win64 x86 and x86_64 systems, and one for Windows on ARM64.
*The FBXL FreeBASIC Insanity Matrix (of compatibility)*
There are FreeBASIC packages now for a lot more systems than I ever expected to see in one place before I started working on this: Windows, Linux, macOS, Haiku, the BSDs, Solaris/illumos, Android, JavaScript through Emscripten, original Xbox, Wii, DOS, Cygwin, MinGW, and more.
On Linux in particular, there are packages across a pile of CPU families: x86, x86_64, armel, armhf, arm64, ppc64el, riscv64, and s390x. Not every OS gets every CPU, because emulated builds and testing already took three days and three nights, but the coverage is much wider than it was.
There is also a specific Raspbian repo for the ARMv6+VFP Raspberry Pi 1 and Raspberry Pi Zero world, which matters because those little machines are not the same thing as generic armhf but they also aren't armel.
Most of this was not just "compile it once and throw it on a web server." I wasn't ready to publicly release until the ports were tested with fbctests, example builds, smoke tests, old BASIC programs, graphics tests, sound tests, and whatever strange hardware I could get my hands on. I've got hacked up armhf Chromebooks, and android set top boxes running Linux, I've got an old Motorola telephone running postmarketos, and more odd ducks so I could see it working on hardware and not just in an emulator. Each package was also tested as much as we (I keep saying 'we' but I mean me) could by trying to install and test on a blank docker container or VM (or in the case of arm64 windows, spinning up an azure VM)
*What works and what does not*
Most parts are functional, but there are still limits, since some platforms just don't do certain things.
DOS support does not have threads or TCP support, and its audio support is blocking. JavaScript support also does not have threads or TCP support. Some external libraries are only realistic on certain platforms, and some platforms are always going to be weirder than others.
That said, a surprising amount of this works. I didn't expect for example to get networking working on... well, we'll talk about that in a moment.
*Sfxlib*
FreeBASIC has always had gfxlib, but sound was still mostly a "go find a library and hope it works where you need it" situation.
This edition adds sfxlib, a simple built-in sound library in the same spirit as gfxlib. It gives BASIC programs a straightforward way to make sound, play samples, use wavetable-style audio, and deal with MIDI-style behavior without immediately dragging the programmer into a giant external dependency mess.
It is not meant to replace every serious audio library. It is meant to make sound available in the same plain, beginner-friendly way graphics already are.
*Gfxlib, touch, and gamepads*
Gfxlib got a lot of attention too.
There are new multitouch commands for modern touch devices, plus getxpad support for Xbox-style controllers and similar gamepads. The goal was to make contemporary input feel like it belongs in BASIC because otherwise we would be spending a lot of time pretending screens are mice and Xpads are 4 button joysticks.
This matters a lot more now that FreeBASIC can target phones, odd handhelds, old consoles, little ARM boards, and normal desktop machines from the same general language.
*Native TCP support*
FreeBASIC already had old-school BASIC-style file and device I/O, but networking usually meant reaching for outside libraries.
This edition adds OPEN TCP and OPEN TCP SERVER, so simple network programs can use the same style people already know: print #, input #, get #, put #.
It is not trying to be a full web framework. It is just trying to make basic network communication feel like BASIC.
I was able to port my old network game Duel to the new framework, and got to experience having a game with a windows host, an android client, a Wii client, an Xbox client, and a haiku client playing the same game.
*Android and JavaScript*
The Android and JavaScript ports already existed in some form. The work here was making them much more usable.
Android now has packaging scripts that hide a lot of the Android SDK/NDK nonsense. JavaScript builds are wrapped up better too, so getting something from .bas to a browser project is less of a scavenger hunt.
Both have gfxlib and sfxlib work behind them. Both are still special targets with special rules, but they are a lot less theoretical now.
*Original Xbox and Wii*
This is the part where things got silly.
The original Xbox port is now split out as its own installable target. It builds .xbe files using the descendant of openxdk. It has enough runtime, graphics, sound, and packaging support to be a real target instead of a fossilized curiosity.
The Wii port came out of PowerPC work and a bad idea that turned out to be a good test. It forced us to care about endian assumptions, old-console constraints, graphics behavior, and whether this whole thing could survive outside the comfortable PC world.
Both are separate packages on windows and ubuntu questing and resolute now. If you want them, install them.
*General cleanup*
A lot of this work was boring the way you want your runtime library to be boring.
Warnings were cleaned up. Unsafe C library usage got replaced where it made sense. Build scripts were tightened. Installers were built. Platform code was separated more cleanly.
There was also a lot of work making the compiler less surprised by unusual architectures. Big-endian machines, ARM machines, Windows ARM64, old consoles, tiny systems, and weird Unix-like systems are excellent at finding assumptions.
Along the way, we fixed a lot of little hidden bugs just to pass fbctests properly.
*External libraries*
One thing this work made obvious is that FreeBASIC's external library story has always been a little optimistic.
Some libraries are easy on Windows and annoying elsewhere. Some work on Linux but not on smaller or stranger targets. Some examples compile everywhere. Some are really only honest on one platform/processor combination (usually just ms-dos or windows on x86).
I tried to improve the documentation around that so people have a better sense of what is realistic instead of being handed a list of headers and sent into the woods. The windows installer is so big because I also tried to keep as many library promises as I could, and that means carting around a boatload of library files. It's been a while since I've run the win32 exampleageddon and we've had a lot of work after that, but I believe every non-MSDOS library compiles on win32 at this point, and we've greatly improved the library example situation on windows x86_64 and linux.
*Why I did it*
I did this because I wanted this specific FreeBASIC to be a thing -- easy to install anywhere, easy to run, easy to use, and holding onto a basic set of APIs you can rely on.
FreeBASIC was set up brilliantly to have a lot of secret cross-compatibility. It has a base, then it has code specific to certain OS platforms, then different CPU architectures, and we just get that for free. I wanted to leverage that to keep that promise.
If we can keep that promise, then it becomes easier for the next generation of programmers to get started. Just install and go, whether you're on arm or x86 or for some reason an IBM z-series mainframe (who are you and what are you doing?)
I do not know how much more I will be poking at FreeBASIC after this. This took a lot. I was up late night after night, it's been months of continuous effort. But I am glad it exists now.
Hopefully it'll be useful to someone else as well.
I want to say the important part first: this is unofficial, unsupported, experimental, and built mostly by some dummy from the sticks because I wanted it to exist. The FreeBASIC core developers did the real work over the years. I came along later and pushed on packaging, ports, cleanup, docs, testing, and a few new toys. If something here is useful, excellent. If something here is broken, assume my intern who definitely exists and isn't just me probably broke it.
*Universal installer*
The front page has a universal installer that tries to detect what you are running and install the right FreeBASIC package for it.
For Debian, Ubuntu, and Raspbian-style systems, it can add deb.fbxl.net as an apt repo. For other systems it tries to do the least surprising thing for that OS.
Windows users also get standalone installers right up front. There is one for normal Win32/Win64 x86 and x86_64 systems, and one for Windows on ARM64.
*The FBXL FreeBASIC Insanity Matrix (of compatibility)*
There are FreeBASIC packages now for a lot more systems than I ever expected to see in one place before I started working on this: Windows, Linux, macOS, Haiku, the BSDs, Solaris/illumos, Android, JavaScript through Emscripten, original Xbox, Wii, DOS, Cygwin, MinGW, and more.
On Linux in particular, there are packages across a pile of CPU families: x86, x86_64, armel, armhf, arm64, ppc64el, riscv64, and s390x. Not every OS gets every CPU, because emulated builds and testing already took three days and three nights, but the coverage is much wider than it was.
There is also a specific Raspbian repo for the ARMv6+VFP Raspberry Pi 1 and Raspberry Pi Zero world, which matters because those little machines are not the same thing as generic armhf but they also aren't armel.
Most of this was not just "compile it once and throw it on a web server." I wasn't ready to publicly release until the ports were tested with fbctests, example builds, smoke tests, old BASIC programs, graphics tests, sound tests, and whatever strange hardware I could get my hands on. I've got hacked up armhf Chromebooks, and android set top boxes running Linux, I've got an old Motorola telephone running postmarketos, and more odd ducks so I could see it working on hardware and not just in an emulator. Each package was also tested as much as we (I keep saying 'we' but I mean me) could by trying to install and test on a blank docker container or VM (or in the case of arm64 windows, spinning up an azure VM)
*What works and what does not*
Most parts are functional, but there are still limits, since some platforms just don't do certain things.
DOS support does not have threads or TCP support, and its audio support is blocking. JavaScript support also does not have threads or TCP support. Some external libraries are only realistic on certain platforms, and some platforms are always going to be weirder than others.
That said, a surprising amount of this works. I didn't expect for example to get networking working on... well, we'll talk about that in a moment.
*Sfxlib*
FreeBASIC has always had gfxlib, but sound was still mostly a "go find a library and hope it works where you need it" situation.
This edition adds sfxlib, a simple built-in sound library in the same spirit as gfxlib. It gives BASIC programs a straightforward way to make sound, play samples, use wavetable-style audio, and deal with MIDI-style behavior without immediately dragging the programmer into a giant external dependency mess.
It is not meant to replace every serious audio library. It is meant to make sound available in the same plain, beginner-friendly way graphics already are.
*Gfxlib, touch, and gamepads*
Gfxlib got a lot of attention too.
There are new multitouch commands for modern touch devices, plus getxpad support for Xbox-style controllers and similar gamepads. The goal was to make contemporary input feel like it belongs in BASIC because otherwise we would be spending a lot of time pretending screens are mice and Xpads are 4 button joysticks.
This matters a lot more now that FreeBASIC can target phones, odd handhelds, old consoles, little ARM boards, and normal desktop machines from the same general language.
*Native TCP support*
FreeBASIC already had old-school BASIC-style file and device I/O, but networking usually meant reaching for outside libraries.
This edition adds OPEN TCP and OPEN TCP SERVER, so simple network programs can use the same style people already know: print #, input #, get #, put #.
It is not trying to be a full web framework. It is just trying to make basic network communication feel like BASIC.
I was able to port my old network game Duel to the new framework, and got to experience having a game with a windows host, an android client, a Wii client, an Xbox client, and a haiku client playing the same game.
*Android and JavaScript*
The Android and JavaScript ports already existed in some form. The work here was making them much more usable.
Android now has packaging scripts that hide a lot of the Android SDK/NDK nonsense. JavaScript builds are wrapped up better too, so getting something from .bas to a browser project is less of a scavenger hunt.
Both have gfxlib and sfxlib work behind them. Both are still special targets with special rules, but they are a lot less theoretical now.
*Original Xbox and Wii*
This is the part where things got silly.
The original Xbox port is now split out as its own installable target. It builds .xbe files using the descendant of openxdk. It has enough runtime, graphics, sound, and packaging support to be a real target instead of a fossilized curiosity.
The Wii port came out of PowerPC work and a bad idea that turned out to be a good test. It forced us to care about endian assumptions, old-console constraints, graphics behavior, and whether this whole thing could survive outside the comfortable PC world.
Both are separate packages on windows and ubuntu questing and resolute now. If you want them, install them.
*General cleanup*
A lot of this work was boring the way you want your runtime library to be boring.
Warnings were cleaned up. Unsafe C library usage got replaced where it made sense. Build scripts were tightened. Installers were built. Platform code was separated more cleanly.
There was also a lot of work making the compiler less surprised by unusual architectures. Big-endian machines, ARM machines, Windows ARM64, old consoles, tiny systems, and weird Unix-like systems are excellent at finding assumptions.
Along the way, we fixed a lot of little hidden bugs just to pass fbctests properly.
*External libraries*
One thing this work made obvious is that FreeBASIC's external library story has always been a little optimistic.
Some libraries are easy on Windows and annoying elsewhere. Some work on Linux but not on smaller or stranger targets. Some examples compile everywhere. Some are really only honest on one platform/processor combination (usually just ms-dos or windows on x86).
I tried to improve the documentation around that so people have a better sense of what is realistic instead of being handed a list of headers and sent into the woods. The windows installer is so big because I also tried to keep as many library promises as I could, and that means carting around a boatload of library files. It's been a while since I've run the win32 exampleageddon and we've had a lot of work after that, but I believe every non-MSDOS library compiles on win32 at this point, and we've greatly improved the library example situation on windows x86_64 and linux.
*Why I did it*
I did this because I wanted this specific FreeBASIC to be a thing -- easy to install anywhere, easy to run, easy to use, and holding onto a basic set of APIs you can rely on.
FreeBASIC was set up brilliantly to have a lot of secret cross-compatibility. It has a base, then it has code specific to certain OS platforms, then different CPU architectures, and we just get that for free. I wanted to leverage that to keep that promise.
If we can keep that promise, then it becomes easier for the next generation of programmers to get started. Just install and go, whether you're on arm or x86 or for some reason an IBM z-series mainframe (who are you and what are you doing?)
I do not know how much more I will be poking at FreeBASIC after this. This took a lot. I was up late night after night, it's been months of continuous effort. But I am glad it exists now.
Hopefully it'll be useful to someone else as well.
- replies
- 0
- announces
- 0
- likes
- 0