Category Archives: Uncategorized

Upgrading the Windows build chain

Since the very first Windows version of PureBasic (23 years ago), we decided to stick with the built-in MSVCRT.dll to avoid to ship others DLLs along the created PureBasic executables. It allowed to have very small executables (as small as 10 KB) without any dependencies (PureBasic programs never had to enjoy the famous DLL hell which plagued many other programming language at time). Unfortunately, overtime the MSVCRT.dll was becoming older and older because it wasn’t updated by Microsoft which was pushing for using specific DLL from VisualStudio. The side effect of sticking to the old MSVCRT.dll is the added complexity to integrate new third party libraries (like libcurl, sqlite, scintilla and so on) into PureBasic because we can’t access new C functions, or new C++ features. So we had to patch the libs to have them linking properly, was very time consuming to try to emulate new functions with a mix of old functions. We still did this (painful) extra work while we were supporting Windows XP but it’s now going to an end with the PureBasic 6.10 version.

Once XP support was dropped, we could use Visual C++ 2022 (which doesn’t support XP anymore) and started to update the whole build chain. It took a lot of time to update the libraries and to be able to link the MS runtime statically, but it’s finally working ! The good news is we can now use an up-to-date C++ compiler which make our work much more easier and faster (the first new library we are integrating for 6.10 is the WebView one, which requires C++17). The drawback to link statically the MSVC runtime is bigger executables, so smaller one starts in the 150 KB range (still very small anyway by nowadays standards). But there is no DLL dependency, and we could even reduce one DLL dependency by statically linking Scintilla (which wasn’t possible with the old MSVCRT.dll).

So far, so good, we’re all set for the future on Windows and you should enjoy soon faster PureBasic executables (the whole command-set is now recompiled with a better C compiler) and more modern commands, like WebView, coming up faster !

The IDE is finally working with the C back-end !

This is the milestone we waited to validate the C back-end. It tooks quite a lot of iteration with the alpha testers (and thanks to all of you all btw) to iron major issues, but here we are: the IDE is mostly working when compiled with the C back-end. This is a big deal: the IDE is a very large software of about 130 000 lines of PureBasic code and using a lot of different features of the language. So what’s the functional changes ? Well, nothing. And that’s on purpose. The plan is to be able to switch seemlessly from ASM to C back-end and be able to compile the IDE on new platform, like Raspberry or OS X M1.

The only noticeable change is the compilation time, which jumps from 5 secs on the ASM back-end to a whooping 24 secs on the C back-end (based on GCC) with the debugger on and optimisation disabled. Keep in mind I got a very old CPU (Core i7 860 from 2009) and as discussed previously, just swapping the C compiler could lead to dramatic improvements.

All in all, it’s very good news, and we are looking forward to fix the last remaining showstoppers and creating a beta version for all the OS, including may be some new like Raspberry !

The Future of the Desktop & PureBasic

Another year has gone by, an its another guest post by Syed Ibrahim (@TI-994A) that saves us from going post-less in 2018. Thanks 🙂


Another year has swooshed by, and 2019 will see PureBasic turning 21, and still going strong.

New Technologies & Platforms

As we all know, the current eco-system is choc-full of APIs, SDKs, new languages, and even more RAD tools and frameworks, all struggling to stay ahead of the curve, and remain relevant. An industry once dominated by the desktop has now splintered into an array of platforms, from the web, to the mobile phone, to smart devices and wearables, and soon on IOT everywhere.

The technologies vying to be the development tool of choice are also ever-growing, with Microsoft jumping into the Mac & iPhone arena with their acquisition of Xamarin, Apple and Google introducing BASIC-like languages with Swift & Kotlin to lure more developers onto their platforms, and Google introducing their very own cross-platform mobile SDK called Flutter, for reasons still quite unclear (for Fuchsia, perhaps?).

The Mighty Desktop

Despite all these shake-ups, the desktop platform will continue to be the indispensable backbone of the consumer, business, and educational sectors. They will also be the cornerstone of every new emerging platform, as integral hosts and back-end servers.

Sadly however, this foundational platform has been neglected, seeing almost little to no progress in development tools or technologies. While all the players have been busy in the cross-platform race, they offer only clumsy and bloated solutions for desktop development as part of so-called single code-base suites. Needless to say, the results have been dismal.

While there have been many champions in the desktop development platforms over the decades, many have fallen behind, and even more have simply thrown in the towel. Loyal users have been left frustrated and in the lurch, having to migrate their skills and code bases to other development platforms and languages.

The Stable & Solid Tool of Choice

The one (yes, ONE!) exception to this is PureBasic, which has strongly been forging ahead on all three of the major desktop platforms (Windows, MacOS, and Linux), growing and evolving year after year, staying relevant and on top of all the current technologies, always offering its loyal user-base the best development experience. PureBasic has continuously remained on the cutting-edge for the past twenty years, diligently incorporating new features and functions as they become available on the respective platforms, all the while keeping close to the core, to deliver the most optimized and native results. And all this under a single and fully portable code base!

Today, no other development tool offers the same native feature-set on as many platforms, with the speed, size, and performance that PureBasic does. Its binaries remain highly competitive even with the likes of platform-specific compilers, but with the ease and simplicity of the BASIC language. Even among the most formidable players, stability has been a major issue. Google has been developing and touting multiple languages, from Go, to Kotlin, and now Dart. And Microsoft axed the original Visual Basic DOS/Windows suite hardly a decade from its inception.

The Future of PureBasic

Our collective hats off to TEAM PureBasic as we look forward to the new and exciting magic that they hold for us all. At 21, PureBasic is the oldest actively-developed cross-platform tool on the market today. At this pace, we can be sure of many, many Merry Christmases to come!

20th Anniversary

It’s already the end of 2017 and no post has appeared this year on the blog. Syed Ibrahim (@TI-994A) brings up the idea and the post to fill the gap ! Have a nice reading and see you in 2018, the 20th year of PureBasic existance (I can’t really believe it) !

A BRIEF HISTORY
1998 to 2018

The coming new year is a very special one for PureBasic, as it marks twenty years since the language first appeared, in 1998. So, it seems fitting that the last blog entry of 2017 be dedicated to this glorious history, and its advancements to date.

PureBasic was first commercially available in 1998, for the Commodore Amiga, and shortly after that, in 2000, for the PC. It uses a predominantly BASIC-like syntax, with some similarities to C and other mainstream languages. Built upon of an assembly language compiler, it has the unique ability to include inline assembly code right alongside its own PureBasic code. Needless to say, this also results in very small compiled binaries, and blazing-fast execution of the compiled executables.

PLATFORM EXPANSIONS
From Amiga, to Windows, to Linux, to MacOS, and Beyond

In 2001, a Linux version was added to the line, and a few years after that, in 2005, a version for Apple’s PowerPC. The PureBasic Suite, as it stands today, was completed in 2008, when another version for Apple’s x86 operating system was added, making it the only non-RAD independent programming language in the world to support all the major desktop platforms.

The language has no real parallel as it is not a rapid application development tool (RAD). It is a true platform-native compiler that produces independent, standalone applications that do not require any additional supporting libraries, frameworks, or virtual machines. The compiled binaries remain very small and tight as no such dependencies are bundled within the final packages either. PureBasic compiled programs would run on the intended platforms right out of the box. Simply copy the compiled executable and drop it into any Windows, MacOS, or Linux PC, and it will run, and run fast.

UNPARALLELED PERFORMANCE
A true, native, multi-platform compiler

Besides old-school powerhouses like Assembly and C, all other popular programming languages today fall victim to burdensome dependencies. Java applications will not run on machines that do not have their corresponding JVMs (Java virtual machines) pre-installed, and .NET programs require compatible versions of the framework in order for their applications to work. Ruby and Python are interpreted scripting languages, and Swift and Objective-C are purpose-built for the MacOS. RAD tools like Xamarin and Xojo have no place in this arena as they tend to bundle massive libraries within the final binaries, resulting in bloated and sometimes slow executables.

This leaves PureBasic as the sole forerunner in its class, as a truly multi-platform compiler, that produces native executable binaries which are small and fast, without requiring any additional resources whatsoever.
Over the years, the language has undergone many modifications, as the developers attempt to keep it updated and relevant with the latest trends and technologies. It has introduced a plethora of tools and libraries to aid the programmer in simplifying development tasks, without sacrificing performance. While some upgrades have come at the price of legacy-compatibility, the end-product leaves nothing to be desired. PureBasic gets better with every new iteration, and the diligence and dedication of the development team to bug-fixes and feature implementations are highly commendable.

PureBasic also conforms to the industry’s strictest policies, with its dual-release model. The compilers are released in beta and stable LTS (long-term support) versions, which allow for legacy developments to continue unabated. Furthermore, every version of PureBasic, from publication year 2000, is still available for download from the site’s unique “museum” page. That’s pure dedication.

The team has recently started development on a web-platform tool, known as SpiderBasic, which is syntax-compatible with PureBasic, and also as easy to use. That will definitely hold many new promises for the future as well.

FEATURE CHART
Platforms, Syntax, Toolkits, Designers, and true 64-bit

– simple, readable, terse syntax
– purely procedural paradigm with true multithreading
– supports both 32-bit and true 64-bit environments
– true cross-platform compilation of unmodified code on Windows, MacOS, Linux
– includes comprehensive libraries usable on all platforms
– includes 2D & 3D game and multimedia engines for all platforms
– implements native UI of each OS without any external libraries
– includes visual form designer that automatically generates UI code
– OS API functions, constants, structures accessible without import
– able to import and utilise external third-party libraries
– able to utilise inline assembly for speed-critical code
– compiles to very small, very fast binary executables
– executables require absolutely no dependencies, frameworks, or VMs
– executables can be run out of the box without any installation
– lifetime license on single purchase that includes all three platforms

LOYALTY LICENSING
A Lifetime of Power Performance

Last, but not least, is the unbelievable cherry on this cake. The entire PureBasic Suite, which includes the compilers for Windows, MacOS, and Linux, costs just €79.00, and comes with LIFETIME upgrades! That’s right. Even the first licensee of the very first PureBasic version in 1998 is still eligible for upgrades to the latest current versions today, absolutely free-of-charge.

Now, that’s one feature that no other commercially licensed language has ever offered.

Thank you, TEAM PureBasic, and specifically its commander-in-chief, Mr Frédéric Laboureur, for your diligence and generosity through the years.

PureBasic 5.30 is out !

That’s it, PureBasic 5.30 final version is out ! The beta phase was longer than usual and even if it’s holiday and summer time, it’s not a valid excuse ;). So let’s jump a bit in PureBasic development internals, so you can better understand why.

First of all, the IDE is now fully unicode. It looks like a no brainer as in PureBasic it’s more or less a checkbox to enable to have your program working in unicode, right ? Well, not this time. The (new) IDE is around for almost 10 years now (09/21/2005) and it grew out of proportion by including tons of features. We heavily use raw pointers to process string buffers quickly, and when switching to unicode, all the strings went to UCS-2 (16-bit character). The stuff here is Scintilla is working internally in UTF-8, so all our comparisons between PB strings and Scintilla internal
didn’t work anymore as one side was UTF-8 and the other UCS-2. Also, all the Scintilla commands which needed a buffer as parameter needed to be changed as we mostly used a pointer to a PB string for this. We also had API calls here and here which required some adaptation work, and there was no compiling error or runtime warning, so usually a nice crash was awaiting us when missing one and reaching this code section. To be honest, it was quite a bit depressing to see a solid IDE get back to a shacky shape. This looks brighter now, and the unicode switch allowed us to fix long standing IDE issues which is cool. It was a needed update, especially for the internal debugger which can now handle unicode programs. There is will be probably some quicks left but it should be ironed out in future versions.

We also made important internal compiler changes to enable runtime serialization trough the XML and new JSON lib. It doesn’t seem like a big deal from the user point of view, but actually it is. What is runtime serialization ? In a nutshell: you have your nice linked list of complex structured elements (which can contain dynamic map, array etc.) and you want to save it, so when you quit your program, you wont loose these data. To do that, you had mostly only one way until now: walk the list, write all the fields of your structure to either a file or a database. It can be time consumming to write this, and if you add a new field in your structure, you have to update both your load and save routines. With 5.30 serialization functions, you can do that with only one command. The compiler will flag your structure as a runtime one so it gets all needed information (like fieldname, fieldtype etc.) and build special information table to allow full recursive analysing and dumping of the structure data. We made this change generic in the compiler, so any command (even user libs) can use this feature. To allow this, we needed to support ‘shadow parameters’ in PB function call. Basically, when we declare a command parameter as “Runtime Structure” like in InsertJSONStructure(), one hidden parameter is added to the function call to add more information to the structure. The same is done to when a runtime list, map or array is need like in InsertJSONList/Map/Array(). Adding such a core feature in the compiler is always tricky and can creates new hard to track issues (like stack mis-aligment), and that’s why the IDE didn’t started anymore on some Windows x64 computers.

And finally, a word about LTS (Long Time Support). The 5.30 is the first version which is released in parallel than an LTS version. That means than we had to update our build servers and deployment tools to handle 2 concurrents versions (when building and when releasing). The website also needed some update to handle this properly. It’s small things but it does add-up and it in the end, it takes time to get everything right and properly working.

As a side note, all the doc are now updated to the new format in every languages and I would like to thank Andre and Mesa for the huge work done on this. A programming langage without a good doc is not a good programming langage.

I hope you didn’t fell asleep when reading this, enjoy the new version !

LTS

Since PureBasic 5.20, we introduced a new LTS suffix after the version name. Some of you wondered what it means, and what was the purpose of it. Basically, a LTS (Long Term Support) version will be supported for 2 years trough bug fixes release without any command or compiler modification. If you need stability in your development, you can choose to stick to an LTS version and then when the support is over go to the next one. We will provide clear migration path when going from one LTS version to another one. The advantage here is you don’t have to worry about code adpation when developping and still have stabilisation releases to have a rock solid development enviromnent. The disadvantage is you don’t get the new features of new major release until the next LTS version is out. That’s a balance to find and a decision to make, but now the choice is yours !

Following API changes

PureBasic uses a commandset built on top of the OS API, using generic commands to abstract it from you, the developer. One of the most daunting (and boring) task for us is to follow underlying API changes. A famous example was Cocoa support replacing old Carbon API on PureBasic for OS X. Another one is the DirectX11 support for the Sprite/Screen library on Windows. Linux isn’t left behind, with the recent GTK3 support for the whole commandset. All this requiers a lot of work, new knownledge to learn, and tons of testing, just to provide functionnalities which already work in the current API. From the PureBasic developer point of view, there is nothing fancy as the commands works as usual, only the implementation under the hood has been completely reworked. That’s one of the great strength of PureBasic: you can upgrade your program without worrying it about the technology used behind by just using a new version. OK, you will probably have some adjustements to do here and here, but it’s really nothing compared to migrate a whole program from one API to another.

Which brings us to a somewhat recurrent issue with PureBasic upgrade: commands are sometimes renamed, changed, or even removed. It often makes the developer angry as a working code needs to be modified to run again with the new version, and we don’t like to change working code. Agreed. But I would like to explain why it happens, and why it is important for PureBasic future. One important thing to understand: we don’t change the commandset unless it’s really necessary. It’s not our goal to mixup the whole stuff only to bother you. That said, the technology is always evolving and an high level programming language like PureBasic needs to follow the evolution as well. If not, it will be left behind, and a new language, using more modern API will take over. Let me use the sprite library as an example to illustrate my thoughs:

– API designed on Amiga in 1998 with no 3D acceleration. Was quite simple: sprite only, no zoom, no rotation, and many software only routines.
– Later, with DirectX7 on Windows, we got some 3D accelerated functions for some cards, so we added the ‘sprite3d’ library to support it. It was optional, as it didn’t work everywhere. That made the sprite lib a bit more hard to use, as you had to create 3D sprite using a real sprite with texture mode. DirectX7 mainly worked with 2D acceleration using DirectDraw, so we couldn’t switch to full 3D
– Nowaday DirectX9/DirectX11/OpenGL offers much better support for 3D only sprites, and 2D acceleration is not supported anymore. So all the sprites are now natively in 3D, even if we use it in 2D mode. What the purpose of having a ‘sprite3d’ lib as regular sprites are 3d anyway ? This one was obsolete, so we had to remove it to cleanup the library and have easier sprite handling, for you and for newcomers.

A new language won’t even think about separating sprite in 2 libs as it makes no sens: all is 3D now, even cheap phones handle its GUI in 3D mode. That was legacy and if we want to have PureBasic around in the future, we have to think ‘new’, and adapt the current commandset to new technology, even if it slightly breaks code. If we stick with older functionalities/design for compatibility sake, we will be slowing dying. Indeed, old PureBasic versions are available in the museum section of your online account, if you just need to do maintainance on a software.

Anti-virus plague

Ironic isn’t it ? Nowaday, anti-virus are becoming more and more intrusives, and ‘thanks’ to heuristic approaches, the false positives raise a lot, while eradication or real virus are less and less common. When was your last real virus detection ? Mine was may be 5-6 years ago. Since then, i got many alerts, but all were just dumbs. Microsoft has made giant progress to counter virus spreading and execution with modern iterations of Windows (see ASLR, DEP, user mode, etc.).

My concern about anti-viruses is the famous heuristic approach which often flag legit PureBasic programs as contamined. I don’t know exactly how works an anti-virus, but I bet it builds a database with some code patterns found in real virus, and if this code pattern is found in an executable it will raise an alert. And here is really the problem: if PureBasic is used to make a trojan or a virus, then chances are high than the code pattern will be actually a purelibrary command, meaning than every other PureBasic program using this command will be flaged as well. It’s really a poor detection mechanism and I can’t understand why anti-virus maker don’t try to find other methods to detect threats. Since several years now, PureBasic programs (and even the official IDE) are regulary flagged as virus with no reasons, and such threads often popup on officials forums. I can imagine the face of a potential customer wanting install the demo version of PureBasic when a big alert saying ‘Warning Trojan.bigvirus.1337’ popup.

So what to do ? Actually a very few things can be done:
– always send false positives to the your anti-virus maker. The more they get, bigger are the chances they will improve their detection routines.
– change your anti-virus. well, some are better than other. If it doesn’t work with PureBasic, you can consider it as a bad one 🙂

I hope it will change, somewhen. Ha, dreams…

Big Christmas Interview with Fred…

“Surprise!” – yes, after a long time I have done a new interview with Fred. And this has become really huge (around 80 Q & A!), in which Fred tell us more about himself, but above all about the history, current situation and future development of PureBasic. I was able to elicit some things from him, which will be included in the forthcoming (as beta) version 5.10…

Read more in the News on PureArea.net

Cocoa, Apple and PureBasic

PureBasic on Apple computers is now a long history but was not always a love story. Back in october 2005, the first version of PureBasic for OS X was released. We spent almost a year to write the PowerPC support for the compiler, which was a real challenge. Believe it or not, 4 months later, the first x86 mac was out with Apple touting all the benefits of the new new x86 processors and letting down the good old PowerPC. That’s was quite a shock for us and it was obvious than all the hard work put in the PowerPC version was lost, as no major mainstream OS run on these processors. So far so good, as x86 was already support on Windows and Linux version of PureBasic, we thought it would be a peace a cake to support OS X. Not really. It was a nightmare to make it work, as Apple forced all API call to have the x86 stack 16 bytes aligned ! PureBasic indeed wasn’t designed for such stack alignment on function calls, as Windows and Linux don’t need such strict rules (btw, it was never mentioned in the Intel doc as well). So we overhauled all the calling code in the compiler to add exception when calling a function or procedure in PureBasic OS X x86. It definitely took some time, as the first public version to support it was released in http://www.purebasic.com/news55.php”>december 2008 (granted, we did some other thing in between but it gives an idea).

But that’s not the end of the story. When we started the port of PureBasic on OS X in 2003, we decided to use the Carbon framework as it was the advised framework for C programmer. All PureBasic functions are done in C on other platforms so it was the right choice at the time. Doing all the GUI commands (Window, Gadget, Menu, ToolBar, StatusBar, 2DDrawing, Drag’n’Drop etc.) for Carbon requiered a lot of efforts, as these libraries are big and fully featured. The Carbon API isn’t very well designed, old school, and morever plagged with redraw and clipping bugs. We added tons of fix only to have something almost working. But if you look in the PureBasic bug forums for OS X, you will find a lot of small remaining issues. Ok, it wasn’t perfect and hard to achieve, but it was working. And Apple ditched it once again. In 2007, Apple announced than the Carbon based application won’t be supported in 64 bit mode. Adobe, Microsoft and several other major companies complained about this fact but the decision was made and here again we knew we would one day rewrite the whole PureBasic command set using the Cocoa alternative. We don’t have that many user on OS X, as it still have nowaday a small user base compared to Windows, but the work put to support OS X outweigh the other OS by a great factor. That’s interesting to understand how companies handle their user base. Apple, which both do hardware and software always push the software forward quickly, and deprecate its hardware in the same time. You want the new OS ? Buy a new mac. The developers are advised to follow as well, and if they don’t want to, that’s not Apple problem. Microsoft on the other side don’t do hardware, so they want their OS to run on any possible PC. Very old PC can still run Windows 7, granted you get enough memory. Microsoft takes care of their developers and of backward compatibility. Here is a small quote from Joel’s blog which resumes the thing:

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

Microsoft don’t deprecate an API, they still support it, side by side with the new one. That’s more work for them, but million of developers don’t have to rewrite they code from scratch at every major Windows version. And more important, binary executable still work, without a change. That’s two way of handling progress, and none are really bad. Indeed from the PureBasic point of view, we prefer to focus on new features than rewriting our working toolkit in another technology.

That said, we do care about our community and we promized a Cocoa support for OS X some time (years) ago. As Apple is pushing even more with the MacOS X AppStore which will soon banish Carbon applications, it was the right time to dive into Objective-C and the new framework. Timo (Fr34k) did the base framework for the Gadget and Window library in Cocoa and run prelimary test between regular C libraries and Objective-C one. The results were concluding, and I take back his work and continued it. After one full week and half on the Cocoa framework, I have to admit that’s it’s much superior to Carbon, and I would like to share this experience with you. Once you get used to the very strange bracket based Objective-C syntax, you can achieve the same work in much less coding lines:

ScrollAreaGadget
Carbon: 487 lines
Cocoa: 163 lines

SpinGadget
Carbon: 379 lines
Cocoa: 254 lines

ButtonImageGadget
Carbon: 290 lines
Cocoa: 110 lines

We got similar result in other gadget files. Ok, but the Carbon API is known to be verbose due to callback and old design. How does it compare with other OS ?

ScrollAreaGadget
Cocoa: 163 lines
GTK: 323 lines
Win32: 570 lines

SpinGadget
Cocoa: 254 lines
GTK: 487 lines
Win32: 331 lines

ButtonImageGadget
Cocoa: 110 lines
GTK: 284 lines
Win32: 480 lines

All in all, Cocoa wins hands down. Why is that ? To be honest, Win32/GTK PureBasic implementation are for now more mature and tested, so it includes many little fix here and here. That said, Cocoa is a modern API compared to Win32 and GTK, and is object oriented, which means you can chain the calls. For example:

[[[NSTabView alloc] initWithFrame:NSMakeRect(x, y, Width, Height)] autorelease]

In traditional C, you will have 3 lines:

alloc()
initWithFrame()
setAuroRelease()

Which brings us to another nice feature: the autorelease pool. Objective-C use reference counting to automatically free the objects when no-one is using it. So you don’t have to track every free, and in the end it does save some code.

Ok, that’s all for now, Cocoa is on the track and we are making great progress. That means than the next major release of PureBasic will probably brings it as default toolkit and, as a bonus, introduce 64 bit support !