Xojo Web is an excellent way to expose the features of your electronics projects without having to attach any screen to them. It’s never been easier to build a Web GUI for your smart clocks, drones, POS, domotics, robots or just some automation services. Thinking about building a solar powered server to automate your tweets? Why not!

If you prefer, you can just expose a Web API instead that can be remotely consumed from another device.

What Raspberry Pi boards support ARM 64-bit Linux OS?

• Raspberry Pi Zero 2
• Raspberry Pi 3
• Raspberry Pi 4
• Raspberry Pi 400

Preparing your Raspberry Pi

The easiest way to get your operating system ready is by using the Raspberry Pi Imager.

At the moment of writing this article, it selects the 32-bit flavor by default. If you have one of the supported boards, go ahead and try Raspberry Pi OS (64-bit) or Raspberry Pi OS Lite (64-bit). The later won’t include any desktop environment, you’ll have to access by SSH.

Select your SD Card storage and press on Write. Optionally, if you want to set a hostname for your board, enable SSH, or even configure your Wifi, press on the gears icon.

In just a few minutes you will have a ready to boot SD card for your Raspberry Pi.

Remotely debugging your projects

This is one of my favorite features of Xojo.

In your Xojo installation Extras folder, you will find a “Remote Debugger Console” and “Remote Debugger Desktop”, that also works for your Linux 64-bit OS.

Depending on which flavor of Linux you’ve selected in the previous step, send the Console or Desktop ZIP to your board, run it and configure the settings.

Inside Xojo, go to Preferences and press on the Debugging tab.

That’s it. Now you will be able to remotely run and debug your applications. Add a few breakpoints and the execution will stop as soon as it reaches it, allowing you to explore the current state.

Deploying the final version

Once you’re ready to build the final version of your application, all the wires attached and components soldered, the last step is to “Deploy” your application.

There is a tutorial covering this step in detail: Deploying Web Apps on Linux.

If you create a Raspberry Pi project, please make sure you open a Forum thread. The Xojo community loves seeing this kind of projects!

What will you build?

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

While our debugger is a powerful tool in helping you track down bugs in your program, there are times when tricky problems arise that go beyond the scope of what our debugger can handle. It’s times like these that PDBs can potentially come to the rescue.

So what is a PDB file? In short, PDBs are a file format developed by Microsoft for storing debugging information about a program. The most important part is how it maps each function address to its equivalent function name. Let’s take a simple example to see how this looks when we don’t have a PDB to help us.

The Offending Code

Var mb As New MemoryBlock(8)
mb.Int64Value(0) = 1
mb = mb.Ptr(0)

// At this point the MemoryBlock is pointing to memory location
// 0x1 which should not be accessible.
mb.StringValue(0, 4) = "Test"

In this example, we’re purposely causing a hard crash here by accessing memory that is not ours to access. Add the offending code somewhere in your program, i.e. in the Opening event or in the Pressed event of a PushButton. If you run this in the debugger you’ll notice that the app just quits, along with our debugger. Since our debugger has failed us here, let’s try Microsoft’s WinDbg and see if we can get any more information from it.

WinDbg

If you don’t already have WinDbg installed, you can now download this from the Microsoft Store:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
For many Windows developers this is a great (and free) addition to help you track down those annoying crashes. To use this, build the Xojo app with the offending code. Run WinDbg and point it to the executable to launch. Once the process is loaded in WinDbg, hit their Go button to cause the crash.

With the app crashed, you can see the most recent stack trace where some of the last functions that were called before it crashed. This is what the stack trace looks like when no PDB exists.

Since the debugger doesn’t have the information it needs to map the address to a particular function, it’ll just report this random address which isn’t very helpful.

Generate the PDB File

Now build the app again but this time generate the PDB file. This option can be found in the Advanced build settings in Xojo 2022r2 and later.

Run the app again under WinDbg. When you cause the app to crash again, WinDbg will look for a PDB file (note: it can be tuned to look in several different places, but by default it will look at the same directory as the executable). This time when the app crashes, you should get a more readable stack trace.

PDBs in the Real World

While the scenario that we just went through isn’t the most common one in the real world, it should provide you an idea of how a PDB file can help with debugging. In a real world scenario, you as the developer, will likely store PDBs internally, maybe on a server somewhere. Each time you build your app for deployment (i.e. when your app is released to the public) you would keep this PDB somewhere. Whenever your clients/users experience crashes in your app, you can ask them to send over a minidump. The same principle applies to executables and minidumps, just load it up and run it. However, the only difference is that the minidump may need more help in locating the right PDB file.

For more information on this topic please refer to: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/symbol-path

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

If you have a 32-bit app on Catalina, it now looks like this in the Finder:

And if you try to run it you get this message:

As previously noted last year, Xojo will only support building 64-bit Mac apps in a future release.

So if you haven’t done it already, time is running out for you to get your own projects and apps updated to 64-bit. Fortunately this can be pretty easy with Xojo. First you’ll have to change the build architecture from “x86 32-bit” to “x86 64-bit” and then test and build your app. You may need to upgrade any 3rd party plugins you use and if you are using any Declares then you should also review them for possible updates.

To learn more about getting your projects ready for 64-bit, check out the 64-bit Guidelines topic in the User Guide.

After a brief introduction welcoming attendees from 11 different countries, Geoff began the keynote by sharing some graphs showing how the Xojo community has been changing.

Along with a growing interest in Xojo, account creation is up 200%, we’ve seen a change in the demographics of our users. In 2017 only 22% of Xojo users were women. This year, that number has nearly doubled to 41%!

A few years ago, just under half of Xojo users were under 35. Now in 2019, 61% of our users are under 35.

This broader change is partially the result of current Xojo community members who evangelize Xojo on social media, blogs or simply in speaking with friends and colleagues. We know that word of mouth recommendations always carry more weight than any advertisement. Geoff took some time to recognize a few members of the Xojo community that have gone the extra mile to build this community. Hal Gumbert and Tim Dietrich, both Xojo developers from the FileMaker community, regularly blog and share on social media their experiences with Xojo. Also thanks is due to Thomas Templemann whose rally cry on the forum encouraged users to review Xojo on slant.co. What may appear to be small single actions all add up to make a difference. The stronger our community is, the better Xojo will be.

Next Geoff announced the winners of the Xojo Design Awards 2019, learn more more about these stellar examples of what has been done with Xojo!

Our team has been very busy over the last 12 months. Xojo has introduced 48 new features, made 75 changes and fixed 465 bugs. To name a few: we added Dark Mode for macOS, native labels in Windows, iOS Table pull to refresh and variable row heights, better text rendering on Windows, URLConnection in API 2.0, incremental compilation for 64-bit and ARM and significantly sped up the layout editor.

But we’ve also spent a lot of time working on some big, multiyear features so let’s take a look at where Xojo is going.

Xojo Cloud

Xojo Cloud is moving to 64-bit because the modern Linux distros are all 64-bit. Going forward, Named Hosts will allow you to point a domain at a specific app. We will be switching from CGIs to stand-alone apps to utilize modern web protocols and we are putting a load balancer in front of each app so you can easily handle more concurrent users.

Interops

If you don’t already know, Interops are basically a better way to make calls into OS APIs than declares. Interops require less code, remove the need to convert data between OS and Xojo types and are far easier to write. A quick example:

These four lines of declares connect to the EventStore database on your iOS device:

Just to connect to the eventstore, you’re dealing with a lot of very unfriendly stuff. However, with Interops this is reduced to one simple line that is friendly Xojo code:

Interops are already a real thing. We are using them internally in the iOS XDC app for both for calendar events and local notifications as well. We are also using them to build the Android framework.

IDE Update

We’ve been doing a lot of work behind the scenes on IDE improvements. You’ve seen some of this in 2019r1 with the layout editor.

With that completed, we’ve now reached the point where the new Home screen and improved workflow are coming soon.

API 2.0

API 2.0, is a set of APIs that will replace many of the existing ones, they will provide better consistency in naming, offsets and error handling. In some cases, we are taking the opportunity to modernize the implementation as well. You already saw this with URLConnection introduced in 2018r4. URLConnection replaced the old HTTPSocket that used a library that had to be updated. URLConnnection uses the underlying OSs’ library, so as those OSs get updated in order to provide better HTTP connections, your apps will automatically benefit. To name a couple more, API 2.0 supports Bezier Curves for all platforms, not just iOS. And the Date class has all the features we added to xojo.core.date, including: Locale support, DateInterval support and TimeZone support.

In most cases the APIs have not changed and not everything will be replaced. Those that are replaced will remain for many years so you don’t need to worry about rewriting your code right away. This change has gone faster than expected (yay, it does happen!) and we plan to be in beta after just a few more updates are made.

Web Framework 2.0

Last year we talked a lot about the design of Web 2.0, this year Geoff focused on implementation and the great progress made so far. As a way of testing out Web Framework 2.0, we decided to port something to the web using it. Since so many have asked for it over the years, we’re working on a web version of Feedback. It’s in the early stages and Greg will be demonstrating the web version in his XDC session. While there’s still more implementation to do, the fact that we are using it for internally tells you how far we have come. Once the implementation is complete, we will begin beta testing.

Android

As you may remember we showed you a Hello World on Android back in 2018. Since then we’ve got IDE integration, apps running on simulator and apps running on actual hardware. We’re also building Android apps internally. In fact, we have put together an Android version of the XDC app! You can go to the Play Store and download it right now. This is a simple app, basically the HTMLViewer. However, the app is native and was built the same way you will be building native apps in Xojo. Travis will show you more controls and have lots of details and demos in his XDC session.

So what’s left before Android is in your hands? In this as well, a lot of the “heavy lifting” has been done, we need to finish implementing the framework and port the debugger and then we will begin pre-release testing Xojo Android.

As you can see, Xojo has made significant progress towards these many large, multiyear projects. An additional note, currently work on Plugins in Xojo is paused to allow us to focus on Android. We’ll do our best to keep you updated via Twitter and Facebook throughout the conference. Please use hashtag #XDC2019 online to search or share your own thoughts. Even if you aren’t here, we’ll do our best to reduce the Xojo FOMO! The XDC Video set is now available for sale.

Speaking of great conferences, the MBS Software conference will be in Cologne, Germany on October 24th and 25th of this year. There are already 40 people coming from 10 different countries, including Geoff Perlman!

Ignoring Encoding

When working with Strings that come from (or are sent) outside your app, you always need to consider the encoding of the text. These days, UTF8 is the most common encoding for text and probably the one you should use most of the time. But if you’re getting text from a database or a web service or just another file that you don’t control, then you’ll want to use the DefineEncoding method to set the correct encoding of the incoming text or use ConvertEncoding to cover the encoding to something you’d rather be using, such as UTF8.

Kem Tekinay is doing a session on called Decoding Text Encodings at XDC 2019 that you won’t want to miss.

Avoiding Exception Handling

Some classes raise exceptions when something unexpected happens. If your code ignores these exceptions then this causes your app to display an error message to the user which forces them to quit the app. That’s not the best experience.

At the very least you should have some code in the App.UnhandledException event for your desktop/web/iOS app so that you will know when these occur. The code do something as simple as log the error to the system log or a file so that you’ll have it to investigate.

Then you can pinpoint the part of the code where it occurred and add the appropriate Try…Catch code to deal with it appropriately and gracefully.

As an example, if you call XMLDocument.LoadXML and supply invalid XML, then an XMLException is raised. By catching this exception you can display a message to the user telling them the XML file they selected is invalid and asking them to choose another.

Skipping Database Error Checking

Whenever you run a database command it is possible that there was a database error that happened. But you won’t know about it unless you check the if Database.Error is True. Always do this and then display or log the Database.ErrorCode and Database.ErrorMessage.

This can really help with catching subtle problems, such as a typo in a SELECT statement.

Ignoring Memory Leaks

A memory leak in your app is when it keeps reserving memory but never gives it back. Oftentimes this is not noticeable as the increased memory usage is minimal and does not typically affect 64-bit apps. In addition the memory is released when your app quits. But if you have a significant memory leak you should look into figuring out how to eliminate it.

You can determine if your app has a memory leak by checking (using the OS Task Manager or Activity Monitor) if its memory usage increases significantly as the app is used even while you are closing windows or documents that are no longer used.

It is possible you have some objects that are never going Nil and thus not releasing their memory. Normally you don’t have to worry about setting objects to Nil manually as Xojo uses automatic reference counting (ARC) to clean up memory. But there is a situation, called a circular reference, that can lead to objects not being set to Nil.

A circular reference means that ObjectA refers to ObjectB and ObjectB refers to ObjectA. Since neither ever has its reference count get to zero, then they cannot be released from memory.

You can either manually set things to Nil to ensure that memory is released or you can make use of the WeakRef class to help manage it.

Fuzzy Graphics in HiDPI

If you used pictures in older projects then they’ll only have a single size. When you enabled HiDPI for your project (Shared Build Settings -> Supports HiDPI) then this picture is treated as a 1x size and is scaled in HiDPI screens. This can result in a fuzzy or blurry picture.

Instead you want to start using Image Sets. When you create an Image Set you have three “slots” for 1x, 2x and 3x image sizes. Supplying at least 1x and 2x images will limit unnecessary scaling and cause your images to appear much sharper and clearer. Image Sets are created by default in current versions of Xojo when you add a picture or image to your project. Right click on existing pictures in the project and choose “Convert to Image” to convert them to an image so you can add additional sizes.

Not Updating to 64-bit

For macOS, you should definitely be updating your projects so they build 64-bit apps. It’s likely that the version of macOS that is released later this year will no longer support 32-bit apps at all and you’ll want to be prepared. For many projects you just have to change the Build Architecture setting for the OS from “x86 32-bit” to “x86 64-bit”. Some projects may require updates to Declares that call OS libraries to ensure they can call the 64-bit version of the library.

It’s less of a rush on Windows as 64-bit versions of Windows still fully support 32-bit apps. However, on a 64-bit version of Windows, which are becoming increasingly common, you will get better overall performance as the OS does not have to load 32-bit compatibility layers which use up memory and CPU.

On Linux, 64-bit distributions are becoming more and more common and many do not include any built-in support for 32-bit apps. So you’ll want to be able to distribute a 64-bit app if at all possible.

Not Checking the Docs

We are working to consolidate all the documentation into one place and that place is: https://documentation.xojo.com

As part of this process, the docs have been cleaned up, updated and we’ve improved the categorization to make it easier to find things. This is an ongoing process, of course. But sometimes it will be faster to look up something in the docs than it is to post a question in the forum and wait for replies.

I hope you find some of these tips helpful. At XDC 2019, I’ll be covering additional tips in my two sessions: Avoid Troubleshooting Troubles: Effective Debugging Techniques and Virtuous Code Optimization.

1. Launch Terminal
2. Execute the following command: sudo nvram boot-args=”-no32exec”
3. Restart macOS

64-bit test mode prevents 32-bit processes from launching. Launching an app that depends on 32-bit software results in a notification that the application can’t be opened. Other types of software may fail silently, such as 32-bit versions of Dashboard and WebKit plugins, preference panes, and background processes. Disable the test mode once the software is updated to work in 64-bit.

To disable the test mode:

1. Launch Terminal
2. Execute the following command: sudo nvram boot-args=“”
3. Restart the machine

Remember that macOS High Sierra 10.13 is the last version to run “32-bit software without compromises”. Although macOS Mojave 10.14 still runs 32-bit software, subsequent versions are expected to be 64-bit only.

In January 2018 Apple stopped accepting 32-bit app submissions to the Mac App Store.

In February 2018, starting with macOS 10.13.4, Apple added a warning that displays the first time you launch a 32-bit app.

In June 2018 Apple stopped accepting updates to 32-bit apps in the Mac App Store. All new apps and app updates must now be 64-bit.

At WWDC 2018 Apple announced that macOS 10.14 will be the final version that support 32-bit apps. Although they did not announce a release date, based on the timing from the past few years macOS 10.14 will probably be released around the end of September 2018.

In addition, Apple also released the Xcode 10 beta at WWDC 2018. Although not widely publicized, this version of Xcode no longer supports building 32-bit macOS apps.

So this is now the situation for macOS apps:

• All versions of macOS currently supported by Xojo can run 64-bit apps.
• Xcode will soon only support 64-bit Mac apps.
• Apple now requires 64-bit apps on the Mac App Store.
• Apple does not spend time fixing bugs related to their 32-bit APIs.

Here at Xojo, there are new features we’d like to support, either directly in the framework or via Declares, but they require that we update to newer macOS SDKs and 64-bit.

Due to all these factors, Xojo will only support building 64-bit Mac apps in a future release. Before this happens we are working on some improvements, such as 64-bit incremental compilation, to continue to make this transition as smooth as possible.

Note that this does not affect the ability to build 32-bit apps for Windows and Linux, something that remains necessary as those operating systems still have 32-bit versions that are in wide, supported use today.

We recommend that all users who create Mac apps move them to 64-bit soon so that your apps remain compatible with Apple’s App Store rules (if you use that) and future macOS versions.

For those that continue to need to build 32-bit Mac apps, we will (as we have always done) keep available older versions of Xojo that you can use to build 32-bit macOS apps, accessible using the Archives section of the web site when you are logged in with your Xojo account.

Transitions often bring some headaches which are sometimes necessary for progress to continue.

With the move to LLVM as the backend of our compiler, the format of our Windows executables changed somewhat. LLVM puts the executable code in a different location that doesn’t set off those same flags for anti-virus software. If you’re having problems with such false positives, recompiling your apps for 64-bit may solve the problem. Doing this is not a 100% guarantee but it can reduce the chances of a false-positive occurring.

This is even more true if you are using console-based helper apps especially if you’re launching multiple instances of them. Despite this being a known and often-used technique for taking advantage of multiple cores (and one we wrote about recently), it can make anti-virus software more suspicious. If your helper app has code that the anti-virus software thinks is in the wrong place, recompiling it for 64-bit may help.

Having said all of this, false is still false. If your apps (compiled for 32-bit or 64-bit) are falsely identified as having a virus, contact the anti-virus software company so they can update their software. Many have established protocols for reporting false positives.

This is the fifth in our compiler series and the first on the back end. We covered the parts of the compiler that are called the front end in these posts:

• LLVM Everywhere
• Compilers 101 – Overview and Lexer
• Compilers 102 – Parser
• Compilers 103 – Semantic Analyzer
• Compilers 104 – IR Generation

Back End

The components of the back end take the IR that was generated by the last step of the front end and emit executable code, which is machine language in the case of Xojo.

To recap a bit from the LLVM post, for 32-bit x86 apps, Xojo uses its own in-house, proprietary compiler first created in 2004/2005. This powerful and fast compiler handles the front end and back end, but it does have a couple limitations: it can only target 32-bit x86 and it does not do any optimizations.

Today when you build an iOS app, a 64-bit app for Windows, MacOS or Linux, or an ARM app for Raspberry Pi you are using LLVM as the back end to generate your native, binary code.

The rest of these posts will cover the back end as it pertains to LLVM. Specifically, the components are:

• Optimizer, Loop Unrolling
• Code Generation
• Linker

• Growing? Read how one Xojo user took his app from in-house to commercial,
• Transitioning Windows Graphics: Direct2D/DirectWrite,
• Remote Debugger for Raspberry Pi and the Programming with Raspberry Pi Book,
• Check out our highly popular JSON Feed blog post series for iOS, web and Desktop,
• We updated Xojo’s Linux Desktop framework to GTK3 and HiDPI,
• Whatever happens, Xojo has your back if Mac goes ARM, and
• Jump into our ongoing Compiler blog post series: LLVM Everywhere, Compiler 101 – Overview and Lexer, and Compilers 102 – Parser.

A special mention on the topic of Net Neutrality in the US. Geoff has shared his point of view and we hope you make your voice heard to the FCC before December 14th. This is an issue that effects us all.

The Xojo community continues to grow with developers switching from VB, emerging citizen developers and small businesses all discovering what they can with Xojo. In the last 12 months the Xojo Forum has welcomed 1,688 new forum members and 60,772 forum posts.

Our blog post from back in June, Daring to Defy Software Extinction sums up Xojo and Dev Tool history with some perspective. We’re proud of what we, along with the Xojo Community, have built over the past 21 years and we look forward to 2018 – Android support, I’m looking at you!

From everyone at Xojo, thank you for your continued support. This community is truly one-of-a-kind and we look forward to all that 2018 has in store!

For users with large projects (and the Xojo IDE itself is a very large project as well), even 4GB of RAM isn’t enough. For these users, Xojo sometimes runs out of memory. That’s why I’m pleased to announce that today we are shipping a Beta of Xojo 2017 r3 as a 64-bit application. Xojo has provided the ability to build 64-bit applications since earlier this year but now the Xojo IDE itself is a 64-bit application which is a first after 19 years of being 32-bit.

Starting with 2017r3 the Xojo IDE will be able to use all the memory you could possibly have in your computer which means out of memory problems are now going to be a thing of the past. Modernizing Xojo, as we do year after year, keeps it in good shape so that you can depend on it for the foreseeable future.

For those of you have that been Xojo users for many, many years (and there are many of you that were here from the beginning), I thank you for your continued support.

64-bit support, for example, has been a major focus and continues to be. At one time, 64-bit was a nice-to-have. Then it became important and now it’s critical. There are Linux distributions that no longer provide 32-bit support. iOS now requires apps to be compiled to 64-bit in order to be in the App Store. You might have noticed that the 2017r2 cycle was longer than usual. This was due to the fact that we were doing some major refactoring of how strings are handled under 64-bit. Some of the string functions you depend on were not always behaving themselves and were much slower than they were in 32-bit applications. That refactoring took twice as long as we’d originally planned. That’s just the way things go sometimes. Even companies such as Microsoft and Apple have announced features that were later delayed. We’ve all been there.

We are also working to provide a 64-bit version of the Xojo IDE. This is important for those you of with large projects because the current 32-bit IDE can only address so much memory. Once your project gets big enough, the IDE can run out of memory even though your computer has plenty to spare. We need this ourselves because the Xojo IDE is written in Xojo and as you can probably imagine, is a very big project. 64-bit applications can address all of the memory your computer (or any future computer you own) will ever have. A 64-bit version of the IDE will permanently resolve this issue.

Sometimes the platform vendors make changes that require us to rearrange things a bit in the short term. For example, our first 64-bit platform was going to be Linux until Apple announced the 64-bit requirement for iOS apps to be in the iOS App Store far earlier than expected. Recently, Apple made it clear that under iOS 11 the Xcode 9 version of the iOS Simulator would not support 32-bit apps or debugging. We had originally planned to support 64-bit iOS Simulator debugging in 2018. Instead we are working hard and fast on that right now.

As a result of all this, some of our plans have been pushed out a bit. We had originally aimed to have Android, interops and plugins made with Xojo available for beta testing by the end of this calendar year. Now that’s not going to happen. We are still working quite hard on all these things (and more) but the 64-bit work has just waylaid us a bit. It is our intention, barring any additional unforeseen circumstances, to ship these features in the first half of 2018.

Fortunately, not all things have been delayed. We are working on a big update to the Windows framework that will dramatically reduce the flicker you sometimes see. This will not just improve the user experience of your apps but the Windows version of the Xojo IDE as well. Those of you that deploy to Windows or use Xojo itself on Windows will be quite pleased. I’m confident we will have these improvements available by year end.

If you want to help us with testing 64-bit Xojo or the updated Windows framework this year, please join our Pre-Release Testing Program.

For those of you that have been participating in pre-release testing, thank you so much. You are providing a valuable service to us and the Xojo community at large.

The best-laid plans of mice and men oft go astray…

As Burns so eloquently stated, no matter how carefully you plan sometimes things just don’t work out. Anyone who has done software development for long knows this all too well.

While Xojo already has 64-bit debugging for macOS and Linux, we had planned to include 64-bit debugging for Windows in 2017 Release 2 which will be shipping next month. As you may know, we rely on the open source LLVM compiler and toolchain for our 64-bit support. This provides huge advantages for us and you with features like 64-bit, ARM and performance optimizing, all with a lot less work compared to providing the entire compiler toolchain ourselves. The downside is that we are now dependent upon the LLVM project. While the LLVM team has been making fast progress, Windows debugging is not quite ready. We are confident it will be ready soon but there’s so much great stuff in Xojo 2017r2, we don’t want to delay it any longer.

If you have an active Xojo Pro license, you can test all the great new stuff coming in 2017r2 now (64-bit XojoScript, Windows Resource Compiler, and more). If you don’t have Xojo Pro but would still like to contribute to testing Xojo releases before they ship, go here to find out more.

Saying all this is one thing, however, and delivering it is quite another. We’ve been through some significant technological hurdles over the years. Over the past 12 months we’ve had two big transitions. The first was support for HiDPI (called Retina on macOS and iOS) which made it possible for apps created with Xojo to support high definition screens. For Xojo users, adding HiDPI support was mostly a matter of recompiling their app. If they had pictures or icons, higher resolution versions needed to be supplied but aside from that, it was effortless.

The second big feature we’ve been working on is support for 64-bit. Integers are the issue here and are almost certainly the most common data type used in apps built with Xojo. If you have used the generic Integer type, in theory, building a 64-bit version of your app should be a simple matter of recompiling. That’s the theory. What’s the reality?

Tom Catchesides of Light Blue Software found himself pondering this very question recently. Apple has recently announced that 32-bit applications would no longer be supported in the Mac App Store beginning next year. Light Blue is an app for managing the business side of a professional photographer’s work. It’s a feature-rich application with thousands and thousands of lines of code. Not knowing how long it might take to get a 64-bit version working, he decided to start on that process now. Tom said:

I wasn’t too sure what to expect from the 64-bit transition, but knowing that Apple are planning to cut off 32-bit support next year made me want to try and move our macOS app over as part of the major update that we’re working on at the moment.

Tom selected 64-bit, crossed his fingers and pressed the Xojo’s Build button. Despite the size of his app, it compiled without error for 64-bit and works fine. More than fine in fact. He said:

I’ve yet to run any benchmarks myself yet, but the 64-bit debug build certainly feels snappy and responsive.

Light Blue Software plans to make a 64-bit beta version available to their customers for testing soon.

Situations like Tom’s are really where the rubber meets the road as they say. This is what we strive for. When there are significant shifts in technology whether it’s new versions of a particular OS, changes to display technology, new processors, etc., our job at Xojo is to shield you as much as possible from work that developers using other tools face. It’s really gratifying to us when we hear how simple we have made these transitions:

All the work that your team have been putting into making this transition seamless for developers is deeply appreciated!

Thanks Tom. We’re just doing our job and we appreciate your continued support.

Xojo 2017 Release 1 adds support debugging 64-bit apps. Why do you need to be able to build and debug 64-bit applications? The short answer is 2 reasons: Memory and Progress. The long answer is, well, long so keep reading. Before I get into the nitty-gritty, you should know that for the vast majority of Xojo users, the only thing you have to do to build 64-bit versions of your apps is select 64-bit from a menu and click the Build button. Now for the details.

Most things an app does consume memory. Open a window, display a webpage, use a file, create a variable to store a value for a moment and you are using some memory. When you close the window, the page, or when the variable goes out of scope, that memory is released. Behind the scenes, the Xojo framework keeps track of all this memory your app is using. It makes sure it sticks around while you need it and goes away when you are done. When a value it stored in memory, it’s stored at a particular location. That location has an address which is basically the starting point of the first byte of memory in which the data is stored.

In a 32-bit application, the addresses themselves are stored in integers that are 32 bits in size. Since there are only so many combinations of values you can store in 32 bits, the total number of address values is 4,294,967,294. As a result, the maximum amount of memory a 32-bit application theoretically can use is about 4GB. The real number is closer to 3.7GB and that varies from one operating system to another. For most applications that much memory is more than enough. However, for some applications, it’s not even close. Imagine you are creating an application that will deal with lots of large photos or video, you can easily reach the point where you need more memory to display more pictures or video but you’ve hit your 32-bit app’s memory ceiling.

As you have probably already guessed, 64-bit applications store memory addresses in integers that are 64 bits in size. You might think that 64 bits means twice as many addresses and thus double the amount of memory that an app can use. It’s safe to say that nothing could be further from the truth. A 64-bit integer is itself twice the size of a 32-bit integer. However, with all those extra bits, the number of values goes up by several orders of magnitude. The largest 64-bit number is 18,446,744,073,709,551,615. If you’re not sure how to even say such a number, it’s eighteen quintillion four hundred forty-six quadrillion seven hundred forty-four trillion seventy-three billion seven hundred nine million five hundred fifty-one thousand six hundred and fifteen. That’s a big, big number. It’s so big in fact that if I turn my iPhone sideways so I can use the scientific calculator, I can’t even enter a number this big. It stops when I get to 16th digit.

I think I’m on solid ground when I say that it’s not really practical to build a computer with that much memory in it but let’s throw caution to the wind and see what would be involved.

I went to Crucial.com and found that the biggest single-stick memory module they sell is 32GB for $352.

We are going to need a lot of them. In fact, we are going to need 575,000,000 of them at a cost of $200 billion dollars. That’s 50% more than the United States spends every year to pay the salaries of all 2.2 million military personnel. Of course, I’m sure if I placed such an order I could get a really terrific discount but still, we are talking about billions of dollars here. Next, we need to create a something with enough space in it to hold 575,000,000 of these memory modules. They are 5.25 inches long and 1.1 inches tall. Put them end to end and you’d have a line of 32GB memory modules 47,644 miles long, almost enough to reach completely around the circumference of the Earth twice. Of course we aren’t going to put them end to end but how big of a box would we need to hold all this memory? I did the math. Let’s start with something really big. How about a box the size of a tractor trailer? Nope, too small. OK, what about a box the size of a typical two-story house? Nope.

In fact, you’d need a box 100 feet long by 100 feet deep and 130 feet tall (about the size of a typical office building) to hold 575,000,000 of our 32GB memory modules. That’s one big computer! You won’t have a smartphone with that much memory anytime soon. The cost of the box itself would of course be trivial compared to the cost of the memory. Power would also be a problem. At 1.5 volts per module, you’d need to generate about 862,000,000 volts.  Something like the Hoover Dam ought to do it. For the truly geeky out there, yes there’s almost certainly a more efficient way to create this ridiculous amount of memory, but you get the idea.

“18,446,744,073,709,551K ought to be enough for anybody.” – Geoff Perlman

Needless to say, the biggest advantage to building 64-bit apps is that your apps will only run out of memory when there’s no more memory left to access in your computer no matter how much memory it has in it. This will likely continue to be true even for your grandchildren’s grandchildren but don’t quote me on that.

By now you have probably forgotten the second benefit of building 64-bit applications – Progress. As operating systems continue to improve, more and more of the system calls the Xojo framework must use to do the voodoo it does so well will be 64-bit only. When we start using these, your projects that use the Xojo functions that use these calls behind the scenes will need to be built as 64-bit applications. Fortunately, as I said earlier, we have done most of the heavy lifting for you. Only a small portion of you will need to update some of your code before you can compile for 64 bit and you know who you are.

Updating Xojo to support building 64-bit applications has taken reviewing hundreds of thousands of lines of code and several man years. The good news for you is that with a mouse click your apps will be able to use all the memory available and be ready for the future. No office building-sized computer required.

In 2016 we took many big steps forward with Xojo including HiDPI support for macOS (Retina), Windows and the web, hardware-acellerated graphics for Windows, tons of new iOS features, IDE improvements and compiler optimization for 64-bit builds. Check out the 2016 Release Highlights. The Xojo Forum has grown to over 16,000 members. We published our 100th video in the Xojo YouTube Channel and added new playlists for Raspberry Pi and Web Services and more new videos in our Spanish, Italian and German language playlists.

We hosted another highly successful Xojo Developer Conference in Houston, Texas and we’ll have an announcement soon about the next XDC. 2016 was another great year for Xojo and 2017 is looking even better! One of my favorite things is hearing about all the cool projects our users create and I have no doubt that there will be many more this year.

From everyone here at Xojo, Happy New Year!

The week started in earnest on the evening of Tuesday, October 4th as attendees joined us for early registration. After people registered and got their cool XDC shirts and Xojo water bottles, everyone migrated to the Revolve Bar at Hotel Derek for conversation and Xojo discussions.

The Keynote Starts

On Wednesday morning, the keynote started at 9 and Geoff opened with an overview of the conference and Xojo (see what we live tweeted). Highlights include:

• XDC 2016 had attendees from 12 countries, with about 45% of the attendees from outside the US. About 25% were first-time XDC attendees.
• There are now over 15,000 forum members, a 36% increase over last year, with over 276,000 posts.
• And yes, XDC sessions were recorded again this year! They’ll be made available for free to all attendees and for sale to non-attendees later this year.

To finish the overview, Geoff talked a bit about Xojo Cloud security. Web servers are constantly scanned for vulnerabilities at an alarming rate. Xojo Cloud is no exception; it is scanned about every 10 seconds with zero known breaches to date. Xojo Cloud remains a safe, easy and secure way to host your Xojo web apps.

Xojo Design Awards

After the conference overview, Geoff announced the winners of the 2016 Xojo Design Awards, which honor excellence in software design. Awards were given in five different categories and Best Overall, which was awarded to EverWeb. EverWeb is a website builder that allows you to build a website with no code at all.

The winners are:

• Best Developer Tool and Best Overall: EverWeb
• Best Business App: Light Blue
• Best Consumer App: Alinof Timer Pro
• Best Cross-Platform App: PubCoder
• Best iOS App: Studiometry Touch

Congratulations to the 2016 Xojo Design Award Winners! It is an inspiration to us all to see such powerful and amazing apps made with Xojo.

Xojo Recent Changes

Geoff next talked some of the changes to Xojo since XDC 2015. There were many, including:

• 949 bugs fixed
• 187 new features implemented
• HiDPI support added for macOS, Windows and web
• Raspberry Pi apps
• 64-bit apps using the LLVM compiler
• Addressed the top iOS requests

By the way, be sure to give Xojo 2016r3 a try as it dramatically decreases 64-bit compilation times.

Xojo Roadmap

Geoff then presented a roadmap for Xojo for the coming year. First up was Xojo 2016 Release 4, which is expected to ship in December. Notable new features include:

• Better Xojo Cloud upload speeds
• Windows HiDPI will be out of beta
• The Windows IDE will be HiDPI
• The Windows graphics framework is getting an update to switch to Direct2D and DirectWrite for smoother graphics and hardware acceleration

For early 2017, Xojo is expecting 64-bit to be out of beta, enabling things such as debugging, XojoScript, Windows manifest and other features.

Later in the year, we expect 64-bit to become the default build target. But don’t worry, 32-bit is not going away! We are also working on the 64-bit version of the IDE itself. The new Xojo framework will be expanded to have feature parity with the classic framework to make it easier for you to start using it in your projects. Lastly, we are also expecting the ability to write plugins for Xojo in Xojo (first announced at XDC 2015) to be made available.

Towards the end of the year, Xojo is working towards shipping an updated IDE with simplified project layout and management. We are also working on a new SDK Interoperability feature (Interops) that will make it much easier use your Xojo apps with standard app frameworks for iOS and macOS. And this new feature will be leveraged to provide an all-new Xojo project type: native Android mobile apps!

Geoff closed the keynote by talking about the history of Xojo, the team and how everyone can help spread the word about Xojo. Telling friends and coworkers about Xojo is a great way to help others enjoy its benefits and grow the Xojo community. Lastly, since Xojo turned 20 this year, Geoff talked a bit about what has changed in the development world since REALbasic 1.0 (the precursor to Xojo) was first released.

We also introduced limited-edition 20th Anniversary t-shirts, if you are interested email hello@xojo.com to order.

General Sessions

Following the keynote, Susan Fennema did a talk on Managing Your Projects. Susan did a podcast with Paul back in August and this session had even more useful tips to help anyone become more productive at just about anything. Her Smarties giveaway proved quite smart, indeed!

After Susan’s talk, Travis and Joe tag-teamed a presentation on the new Xojo framework and then it was time for lunch!

Sessions, So Many Sessions

After lunch the breakout sessions started. At this point there were always two sessions going on simultaneously and attendees often said they wanted to be able to attend both so it’s a great thing they were all recorded. There were sessions on a wide variety of topics, including iOS development, testing, databases, reporting, REST and so much more. With 36 sessions altogether, XDC truly is a “firehose of knowledge”!

Activities

Coming to XDC is not all about work and learning – you also get to have fun! This year’s evening activities started with a rockin’ night of live music with Skyrocket, a fabulous 70/80’s cover band. Our fearless CEO, Geoff Perlman, even joined the band on stage to play drums in a rousing cover of American Girl by Tom Petty.

The next night everyone headed across the street to Grotto Ristorante for conversation, drink and a fabulous Italian dinner.

What Attendees Are Saying About XDC:

“This was my first XDC. Almost overwhelmed with information! I definitely enjoyed meeting everyone and I now have real faces (and accents) to attach to the forum posts.” – John Knight, Jr.

 

“2016 was my first time attending XDC, and it was amazing. I learned a lot, and met so many incredibly nice, interesting, and brilliant people. I want thank everyone for their kindness, generosity, and for the laughs. I feel like I’ve found my “tribe.” – Tim Dietrich

 

“I felt the same way at my first XDC 4 years ago, and still feel that way every year. It’s a great event, with amazing people, and I’m already looking forward to next year!” – John McKernon

 

“It was filled with useful information, of course, but more importantly, the people from Xojo and the other attendees were passionate about the platform and willing to dive in to help a newcomer learn.  I even had the opportunity to spend a couple hours with the CEO and some others and have a great discussion!  That says a lot about a twenty-year-old tech organization.  We will be converting our systems to Xojo-designed apps and I’ll be going again next year.” – Bill Kapeles

 

“I was another first timer at XDC. In my 30+ years of involvement in the software industry, this was one of the best development conferences I have attended. Professionalism and willingness to engage with new attendees was evident at every level. Wonderful experience!” – Karen Bintz

 

“The presentations covered such a wide range of topics. It was really cool to see all the incredibly different ways people use Xojo and to hear the depth of knowledge each one has in their particular areas. I learned a ton, and it was a privilege to present as well….. plus it was fun! It was particularly great to meet everyone in person. The whole event ran smoothly, the food was great, the entertainment was great.” – John Joyce

 

“This. This is why I go every year. Renewing friendships, meeting with clients (both old and prospective), learning new things, and talking Xojo non-stop makes for an awesome experience.” – Bob Keeney

Thanks!

The Xojo Team wants to thank all the attendees of XDC 2016. We could not do XDC without you. And a special thanks to all the presenters helping to make XDC so valuable by providing wonderful, varied content. We can’t wait to see you next time!

From left to right: William Yu, Paul Lefebvre, Stéphane Pinel, Alyssa Foley, Greg O’Lone, Dana Brown, Norman Palardy (seated), Travis Hill (standing), Geoff Perlman, Joe Ranieri, Robin Lauryssen-Mitchell, and Jason Parsley

Xojo 2015 Release 3 added the ability to create 64-bit apps for OS X, Windows and Linux. This is still considered a “beta” feature because there are a few things that still need to be added. One of those things is the ability to specify the app icon for 64-bit Windows apps.

Until that is available, you can work around it by setting the app icon at run-time (so it shows correctly in the Task Bar) and by having the installer set the icon for the app shortcut so it appears in the Start menu or on the desktop.

Thanks to Jim Cramer and Michele Bujardet for putting together the Declare code to set the app icon at run-time. To use this, you need to have your app icon in ICO format. Then use a Copy Files Build Script to copy it to the Resources folder. Your app then gets a FolderItem to the app icon and call the SetApplicationIcon method to set it.

This code gets the icon file and calls the SetApplicationIcon method to set it to your icon file (replace “XojoLogo.ico” with your own file of course):

#If TargetWin32 Then
  // The Icon is copied to the Resoures folder
  // in a Copy Files Build Step.
  // Get a Reference to it.
  // The file must be an ICO file, not PNG or JPG.

  Dim resourceFolderName As String
  resourceFolderName = App.ExecutableFile.Name + " Resources"
  resourceFolderName = resourceFolderName.Replace(".exe", "")

  Dim f As FolderItem = App.ExecutableFile.Parent.Child(resourceFolderName).Child("XojoLogo.ico")

  Self.SetApplicationIcon(f)
#Endif

This is the code for SetApplicationIcon, which you would add to a module since it is implemented as an extension method for the Window class:

Sub SetApplicationIcon(Extends w As Window, iconFile As FolderItem)
#If TargetWin32 Then
  Const WM_SETICON = &h80
  Const ICON_BIG = 1
  Const ICON_SMALL = 0
  Const GW_OWNER = 4

  Soft Declare Function LoadImage Lib "User32" _
    Alias "LoadImageW" (hinst As Int32, lpszName As WString, _
    uType As Int32, cxDesired As Int32, cyDesired As Int32, _
    fuLoad As Int32) As Int32
  Soft Declare Sub SendMessage Lib "User32" _
    Alias "SendMessageW" (hwnd As Integer, msg As Integer, _
    wParam As Integer, lParam As Integer)
  Soft Declare Function GetWindow Lib "User32" _
    (HWND As Int32, uCmd As UInt32) As Int32

  // Get handle to the Icon Image on Disk
  // Default size and load from file. 
  Dim Flags As Integer = Bitwise.BitOr(&h40, &h10)
  Dim hIcon As Integer = LoadImage(0, IconFile.NativePath, _
    1, 0, 0, Flags)

  // Reset the Icon For This Window
  SendMessage(w.Handle, WM_SETICON, ICON_BIG, hIcon)
  SendMessage(w.handle, WM_SETICON, ICON_SMALL, hIcon)

  // Ensure the application Icon gets changed as well
  Dim ownerHandle As Integer = GetWindow(w.Handle, GW_OWNER)
  SendMessage(ownerHandle, WM_SETICON, ICON_BIG, hIcon)
  SendMessage(ownerHandle, WM_SETICON, ICON_SMALL, hIcon)
#Endif
End Sub

This Declare works for both 32-bit and 64-bit apps, so you can test that everything is working properly before you build as 64-bit.

The next step is to create your installer so that it uses the app icon for the Start menu and Desktop shortcuts that it creates. With InnoSetup, you just have to add this command to the items in the [Icons] section:

IconFilename: "{app}AppIconTest ResourcesXojoLogo.ico"

Of course, you’ll need to specify the appropriate path and filename in your own InnoSetup script. Lastly, to ensure your app gets installed as a 64-bit app and placed into “Program Files” (instead of “Program Files (x86)”), then also add this setting to the [Setup] section:

ArchitecturesInstallIn64BitMode=x64

• Download the sample project, icon and InnoSetup script

Remember, you’ll need to modify the InnoSetup script to use the appropriate paths on your system.

With these two tricks, for all intents and purposes your 64-bit app will appear to have an app icon.

After years of work by everyone on the team, we have simplified the process of creating 64-bit versions of your apps down to this:

That’s right. For most of your apps, you’ll just have to change this Architecture setting from “x86 32-bit” to “x86 64-bit” and then Build.

Why do you need 64-bit?

You may not need it right away, but you are probably going to want it right away. Here are some reasons why:

Memory: A 64-bit app has access to much more memory than a 32-bit app (which tops out between 3 or 4 GB depending on the OS). 64 bit apps can address so much memory that they can now access all the memory you have available.

Speed: 64-bit apps are built using the LLVM optimizing compiler. Users with lots of math-specific code are reporting that there apps run up to 9 times faster! 9 times! Not all apps will see this significant speed improvement, but any speed improvement is a good thing.

OS support: The OS X versions supported by Xojo (10.7 and later) are already all 64-bit. By having your app also be 64-bit you put less strain on the OS as it does not have to load a 32-bit compatibility layer. Similarly, many Linux distributions are no longer even available in 32-bit versions. It is much easier to deploy a 64-bit Linux app to a 64-bit Linux distribution than it is to configure a 64-bit Linux distribution with the necessary 32-bit libraries (that are not installed by default). Windows also has separate 64-bit versions that benefit from running 64-bit apps rather than 32-bit apps with a compatibility layer.

To learn more about 64-bit using the current Xojo release, refer to the Dev Center:

• 64-bit Guidelines

UPDATE October 2015: Xojo Builds 64-bit Apps Now

At Xojo, we like to keep things simple. For many people, creating a 64-bit version of their app will involve going to the Inspector for the target OS and selecting “x86 64-bit” instead of “x86 32-bit” in the build settings and then clicking the Build button.

In all cases, this creates a separate 64-bit build of your app.

Some of your projects may use plugins. If so, you won’t be able to build that project as a 64-bit app until all the plugins it uses are first updated to 64-bit. We are working to update our plugin SDK so that plugin authors can get their plugins updated and available for testing.

Lastly, if your app uses Declares, you may find you have to update some of the data types. For example, for Cocoa apps the CGFloat type maps to Single on 32-bit systems, but Double on 64-bit systems. You may need to update Structures or Declares to account for that. You may also have to update parameters from Int32 to Integer or Ptr so that the parameter sizes change as expected when run on 32-bit and 64-bit systems.

Your app distribution is also affected a bit (pun intended) by the operating systems that you support. For OS X, you only need to make the 64-bit version available. All OS X releases currently supported by Xojo are already 64-bit only, so there is no reason to maintain a separate 32-bit app unless it has some feature that is not yet available for 32-bit apps.

For Windows, Microsoft still ships both 32-bit and 64-bit versions. So you’ll have to also have both 32-bit and 64-bit versions of your app available. Customers that are running a 64-bit version of Windows can run either the 32-bit or 64-bit versions of your app. But customers on a 32-bit version of Windows can only run a 32-bit version of your app.

On Linux, the situation is similar as both 32-bit and 64-bit versions of most distributions are commonly available. A difference is that most 64-bit distributions do not include the necessary libraries to run 32-bit apps. So your users will want to use the 32-bit version of your app on 32-bit Linux distributions and the 64-bit version of your app on 64-bit Linux distributions.

And remember, those of you with current Xojo Pro licenses get access to the Beta when it is available. If you’d like Beta access to test your apps early (and help us test as well), upgrade to Xojo Pro.

As you probably heard by now, all iOS apps submitted to the App Store now must include 64-bit support. As we announced back in October (and provided an update in December), apps you create with Xojo 2015 Release 1 now meet this requirement.

Specifically, this means that apps you build for devices and for the App Store are created as “Universal Binary” bundles that contain both the 32-bit and 64-bit builds of your app. The 64-bit build is used on 64-bit devices such as iPhone 5S, iPhone 6, 6+, iPad Air, iPad Air 2, iPad mini 2 and mini 3. Older devices, such as iPhone 5, iPhone 4S, iPad 2-4, iPad mini use the 32-bit build.

The best thing is that you don’t actually have to do anything! Just build your iOS app using Xojo 2015 Release 1 and you’ll automatically get the Universal Binary. There are no settings to tweak or code to change. Xojo handles it automatically!

If you have an iOS app that was made with Xojo in the App Store, share it in this Xojo forum conversation for fame and glory!

Many computing devices now have 64-bit processors allowing them to access very large amounts of RAM. That means the apps must be 64-bit apps. If the device has 32-bit compatibility libraries installed, they can run 32-bit apps as well and most do. Some Linux servers, however, don’t have these libraries installed and thus require a 64 bit app. As time goes on, more devices will require apps to be 64 bit.

We continue to make progress towards making Xojo capable of producing 64 bit apps. We currently estimate that we will be ready in the first quarter of next year. We had a more aggressive goal in the past but we have made some bigger, more long term plans for Xojo that include 64 bit. That pushed our timeline out further but in the long run, Xojo will be a better tool. And we all know how difficult it is to estimate software projects. The closer you get to shipping, the more accurate the estimates become. Everyone’s shipping estimate is 100% accurate the day the software ships.

What do you need to do to make sure your apps will compile for 64 bit? Most of you will have to do little or nothing because Xojo abstracts you from these details. For example, if you use the Integer data type, that will automatically convert from 32 bit to 64 bit. If your application uses plugins, those plugins will need to be updated to support 64 bit. When we are ready with 64 bit, many plugins will have been updated. For most of you though, the conversion from 32 bit to 64 bit will require little, if any, effort.

Do you have an app that will benefit from 64 bit? Post a comment and tell me about it.

UPDATE: 64-bit Apps with Xojo, The 64-bit IDE