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.

Getting the best out of the IDE when using Modules

Since the last beta version (5.20 beta8) the IDE finally has support for Modules as well (AutoComplete, QuickHelp, ProcedureBrowser etc). Please test these features well, as it was quite a change in the IDE to implement this. Now, to get the best experience when using the IDE and Modules together, there are some simple rules that have to be followed. I will explain them below. But first, let me explain why these limitations exist.

As the AutoComplete feature became smarter and more helpful in past versions, it had to grow from a simple scanning of the source for strings into a full grown analysis of the source code. This is especially required for modules, because the IDE needs to know what procedures/constants/structures are exposed from each module in order to present the correct choices in AutoComplete. So the IDE in essence needs to understand your code. The best way to fully understand code is to compile it. The IDE does not actually compile the code for the following reasons:

  • Speed: The AutoComplete feature cannot introduce delays because that would make it unusable. So compiling the entire code from beginning to end is not an option.
  • The code is usually not compilable anyway: Remember, the purpose of the IDE is to edit code. While you edit a line, it will be in a state that cannot be compiled most of the time. In fact, if you look at all characters typed in a source code, the instances in which that typed character puts the source in a compilable state are rather rare compared to those that put it in a state with errors (from a compiler perspective).
  • There are IDEs that actually have a builtin compiler that can tolerate this and still compile the code. Eclipse is such an example. However, writing something like that is quite complex and is actually harder for PB because of features such as macros and compiler directives.

Instead, the IDE tries its best to (quickly) understand the code without a full compilation. For that, it parses the code and extracts all information that can be understood without context (from a single line of code) into an indexed form for fast search. This organization has the benefit that if a line of code is changed, only this line needs to be parsed again and not the rest of the code which is quite fast. Then when the type of a variable is needed or something like that, the IDE searches through this indexed data to put it in the proper context to answer the question. So it is not a full compilation, but rather a “fuzzy” analysis of the code. In essence, the IDE collects the information it can understand, and stuff that only a compiler would know (like what an expanded macro would look like) is ignored.

So how does this affect Modules? One thing that the IDE does not do is resolve which source file is included where in the final program. It only looks at each source file individually. This was no big limitation before modules existed, but with modules it means you have to follow some rules so the IDE understands where a module begins and ends and what it contains.

These are the rules:

  1. The entire DeclareModule/EndDeclareModule block should be in the same source file.
  2. The entire Module/EndModule is best also written in a single file, but it does not have to be the same one as the one that contains the DeclareModule
  3. At least the file containing the DeclareModule block should be included in the Project and scanned for AutoComplete. You don’t have to include the actual module implementation since the stuff in there is not visible on the outside anyway.
  4. If you use UseModule, all modules that are open within a source file should be opened within that source file. The best was is simply to have the UseModule calls right at the top.
  5. Don’t hide the essential module commands behind macros. The IDE does not expand macros so it will not know that the keywords are in there.

The explanation is rather simple. Consider this code:

DeclareModule Foo
  XIncludeFile "FooDeclaration.pb"
EndDeclareModule

Since the IDE only looks at each source file individually, it does not know that the contents of FooDeclaration.pb are part of the module declaration. So the IDE sees an empty Foo module, plus a file FooDeclaration.pb with stuff that is outside of any module.

In the same way, if you have a UseModule call outside of the current source file, the IDE does not know that stuff from the opened module is available while you edit your file and therefore cannot help you with AutoComplete in this case.

Other languages enforce such rules on the compiler level (one class per file etc). We chose to not limit the compiler in this way so you can organize your code as you like. And you don’t have to follow these rules to use the IDE. It just cannot be as helpful as it could be if you don’t. Anyway, in my opinion these rules also make sense from a code organization standpoint so i don’t think it is that hard to follow them.

 

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 !

Back in business !

As you probably have noticed, the pace of PureBasic development has slowed down these last months due to full time job for Timo and myself. I’m very aware of the situation and I decided to get back at fulltime on PureBasic early in april ! As always after taking some distance from a project, we have many new ideas to tests and implement and I’m quite excited to get back on core development. We will probably ship one or two bug fix versions and then a new major with a priority for the 64 bit Cocoaified OS X version (which is already running here, but not yet finished/tested). After that, may be some big surprises 😉

Have fun !

PureBasic development

Some questions raised on the forums about the current pace of PureBasic development. The update are less frequent and some users are wondering if it’s not the end of PureBasic. No, it’s definitively not. We want to explain here, why it took longer than usual to release a new version (we had a very fast release cycle for this kind of software): first the current version to release, 4.60, is a big one: it has a lot of new commands, especially on the 3D side, and all these commands needs to have a proper documentation. And I write this documentation. You guess it, it’s boring, and i’m not really enjoying that part. Now, that’s not an excuse to have 2 months between two beta version right ? It should have something else. And you are right. We have since the beginning of the year a daily job, which means less time for PureBasic. We have nothing to hide here. Like most of you, we need to have a real job for a living. And it’s not the first time it happens: during the 10 years of PureBasic development, I have worked 5 years on a daily job, without big impact on PureBasic. So no need to panic, PureBasic is here and will continue to grow. We are also confident that its now a mature and very capable product. To finish on the ‘PureBasic end’ things: if we decide to stop PureBasic (which is very unlikely), we will release it to the community, either in Open Source form, or to a small group which could take over the development.

Some asked for our future plans. Here we go: we plan to release the 4.60 version early on september and a 4.61 bug fix version somewhen in november. In between, we will continue to work on the new features for the next version, we have quite some projet to make it better. So stay tuned !

PureBasic 4.60 Beta1 released!

Its been quiet around here for a while, but now there is big news: The first public beta of the upcoming 4.60 release is out!

This release is mostly about the 3D side of things, but there are new features for application programmers as well. The OGRE engine was updated to version 1.7.0 and we switched the physics engine from ODE to Bullet. Furthermore, there are a ton of new 3D libraries and commands. You can see the full list below. The 3D commands are not documented yet, but we will put up some examples to demonstrate them.

A special thanks to G-Rom and TMyke from the french forum for their help on the new 3D commands!

On the application side of things, the most notable addition is the CanvasGadget() command. It is a simple drawing surface that provides detailed mouse and keyboard events to easily implement custom data views or controls (all cross-platform of course). You can see this new gadget in action in the IDE already: The new file panel and the new color picker tool both make use of it. Other than that, there are some smaller new commands like additions to the LinkedList library for example. All new non-3D commands are already documented in the manual.

The IDE got some additions as well, like the ability to build projects directly from the command-line, or the option to be warned when a file is changed on disk while open in the IDE. Unfortunately, the automation framework that I talked about here on the forum did not make it into this release. It wasn’t finished in time, and its not a big enough priority to justify delaying this release any longer.

Finally, we are in the process of changing the PureBasic documentation to be more precise and readable when it comes to function parameters and return values. This is still a work in progress which should be finished for the final release. Comments on the new structure are welcome.

These are the changes:

Libraries:
– added CanvasGadget(), CanvasOutput()
– added SetGadgetItemData() for PanelGadget
– added MoveElement(), MergeLists(), SplitList() commands
– added RandomizeList(), RandomizeArray()
– added PushListPosition(), PopListPosition(), PushMapPosition(), PopMapPosition()
– added ImageID parameter to OpenSubMenu()
– added #PB_ListIcon_ThreeState and #PB_ListIcon_Inbetween
– added #PB_Tree_ThreeState and #PB_Tree_Inbetween
– added crossplatform ComboBox events
– added ‘Joint’ library
– added ‘SpecialEffect’ library
– added ‘StaticGeometry’ library
– added CameraPitch(), CameraRoll(), CameraYaw(), SwitchCamera()
– added ApplyEntityForce(), ApplyEntityImpulse(), EntityPitch(), EntityRoll(), EntityYaw(), GetEntityAttribute(),
GetEntityMaterial(), SetEntityAttribute(), SetEntityMaterial()
– added LightDiffuseColor(), SpotLightRange(), LightLookAt(), LightPower(), DisableLightShadows()
– added MaterialDepthWrite(), MaterialSelfIlluminationColor(), MaterialShininess(), GetScriptMaterial()
– added BuildMeshShadowVolume(), CreateLine3D(), CreateCube(), CreateSphere(), CreateCylinder(), CreatePlane(), AddSubMesh()
MeshVertexCount(), UpdateMeshBoundingBox(), MeshRadius(), AddMeshVertex(), MeshVertexNormal(), MeshVertexColor()
MeshVertexTextureCoordinate(), AddMeshFace(), FinishMesh(), NormalizeMesh(), SaveMesh(), SetMeshMaterial(), SubMeshCount()
TransformMesh()
– added NodePitch(), NodeRoll(), NodeYaw()

– changed FindString() ‘StartPosition’ parameter to be optional
– changed WebGadget to use WebKitGtk on Linux
– changed ContainerGadget with #PB_Container_Borderless to no longer add a 2px invisible border on Linux
– changed EntityPhysicBody(), CreateLight(), RenderWorld(), ShowGUI, WorldShadows()

– removed: Get/SetEntityMass(), Get/SetEntityFriction()
– removed: SetMeshData() (temporary, needs to be updated)

IDE:
– added IDE options for commandline project building
– added monitoring of files for changes on disk while they are open in the IDE
– added FilePanel custom implementation with Drag & Drop, Dropdown menu, scrolling also on OSX
– added Diff tool for directories/files
– added Html help viewer for Linux/OSX
– added Help viewer in toolspanel
– new Color Picker tool
– enabled font selection in IDE for OSX
– ProjectPanel now remembers node expanded states

Debugger:
– added maximize button to all debugger windows
– added all IsXxx() and XxxID() functions to the expression parser (for data breakpoints)

Manual:
– The manual is being updated to a new format which more clearly describes
individual function parameters and return values. This is not yet complete,
but will be finished for the final release.

Visit the announcement on the PureBasic forums here.

Coding standards

I’m currently working on a C++ project and the coding standard problem raised again. And again, nobody in the team agree about the style/naming format to adapt. C++ sounds somewhat cursed on this topic. After so much years of existence, no precise coding rules has emerged and everyone is almost authorized to code as he wants to, making the whole project source code quite very heterogeneous and obviously hard to maintain. Java has a clean coding rules and almost everybody is following it without arguing. C# seems to have also a common coding standard, but it doesn’t seems to be that followed. That could be my very small experience in C#, I stand to be corrected. Back to C++. You may think: ‘what a big deal, just pick some rules and stick to it’. That’s the ultimate goal, thanks for your input ! But then, you have to please everyone habit and it’s not that easy. So you’re going to compromize on many thing and at the end, nobody is really happy with the result.

But wait, it’s a PureBasic blog, no ? That’s right and I wondered if we needed strict PureBasic coding standard, but after some thoughts it doesn’t seem to be needed and i will explain why:

– PureBasic comes with a big command set, which implicitly set the the name rules for the function/procedure naming: CamelCase. One down. In C++ you have to choose how to name your functions, your methods and your class. Candidate are numberous: myMethod(), MyMethod(), my_method(), mymethod() and so on.

– The constants are prefixed by a ‘#’ in PB, so it can’t clash with variables or anything else. PureBasic comes with a lot of predefined constants, all in CamelCase as well, setting a de facto standard. Again in C++ you have many way to name them: MyConstant, MY_CONSTANT, kMyConstant etc.

– PureBasic help and demo examples are very consistent and always share the same syntax rules which helps to guide the newcomers to format the code the same way.

– There is no “{}” in PureBasic, so the flamewar between K&R and GNU style is avoided, thanks !

When looking at the code snippet pasted on the forums.purebasic.com, I feel there is a common style and it’s very cool to see that. It doesn’t take long to get a grip on someone else code, and that’s a very important part of a programming tool.

Merry Christmas !