Friday, December 24, 2010

Cocoa Progress Report

The road from Carbon to Cocoa for us has been a long and winding one but the fruits of our labor are beginning to really show themselves. Yesterday, we made available a beta of the new version of our Feedback application that you use to submit bug reports and feature requests. There are a few new features in Feedback 2011r1 but what is most interesting is that this version of Feedback is built with our Cocoa-based Mac framework!

Feedback is not a simple app. The fact that our Cocoa support has come far enough that we can take our Feedback app and rebuild it using our Cocoa framework says a lot about just how far the Cocoa framework has come. While there are couple of minor issues with this first beta, on the whole it works very well and we have been using it internally for several weeks now.

This version of Feedback is built with REAL Studio 2011r1 which is not yet available to beta testers but will be soon after the holidays. We have made a lot of improvements to our Cocoa support for 2011r1 and I'm confident many of you will find that your apps can be deployed when built with it. This really is a milestone and while it's taken quite a while to get here, it will be worth the wait. Cocoa is a big step in terms of modernizing our Mac OS X support.

Your patience is appreciated. We are almost there.

Thursday, December 23, 2010

Another year...

2010 is coming to an end. It's been quite a year! We've been working hard on the Cocoa framework and I think many of you will be able to deploy your apps using the Cocoa framework starting with REAL Studio 2010 R1.

The Web Edition is another big new feature we worked on throughout 2010. It's great to see so many of you as excited about Web Edition as we are bringing it to you.

We've got lots of cool stuff planned for 2011 as well. So stay tuned for that.

Finally, I would like to thank all of you that have supported us in 2010. We appreciate it. We love being able to bring REAL Studio to you and hearing about the cool stuff you do with it.

Happy Holidays and Happy New Year,

Geoff Perlman
Founder and CEO
Real Software, Inc.

Wednesday, December 22, 2010

REAL Studio Web Edition Status

Since the release of REAL Studio 2010r5, we've been receiving lots of questions regarding deploying Web applications. They have come from the forums, our mailing lists, sent to our customer service and tech support contacts, as well as directly to my inbox. So here is a kind of status update regarding Web Edition, as well as some background information, and possibly assistance with getting your application deployed once we have made r5.1 available.
I see two main deployment issues:
  1. Some/many shared hosts are not able to support this yet. Some do though, and we expect more to over time. Currently, the most cost-effective way to deploy is using a VPS, unless you've found a shared hosting package that works for you.
  2. FastCGI has a few bugs.
A few days before we shipped, it was discovered that apps deployed as FastCGIs could take up 100% of the CPU. Obviously, that's not going to work.
From past experiences with Cocoa, delaying the release was not an option. If we delayed, users would be upset anyway. A "damned if you do, damned if you don't situation." We decided to get this into our users hands and do a r5.1 release.
The good news is that FastCGI is much improved in r5.1. We ran an internal test of the Chat example last night on a CentOS 5 + Apache server using Dynamic FastCGI. Aside from a couple minor issues that need looking into, it performed wonderfully. Average CPU was 0%, RAM at 8MB. The app did not crash, it handled all requests perfectly. We were very pleased.
This test also revealed another configuration requirement though. By default, the FastCGI process manager will spawn additional instances of your application at its will. This is a problem for our applications, as state information is stored in memory. When this happened, although the apps were functioning, the client-side experience fell apart terribly. To prevent this, here's what I added to our Apache config file:
FastCgiConfig -minProcesses 0 -maxClassProcesses 1
Basically, this line tells the process manager that it is allowed to have no app running (for when no users are connected and the app is not needed) and is allowed to run only one instance of each app.
We intend to have a r5.1 beta available to the beta program in time for the holidays. We'll be collecting feedback over the holiday break, and intend to have a r5.1 release in January. As with all point releases, r5.1 will be available to anybody eligible for r5.
The new config options will be added to the wiki at some point, and we intend to setup demo apps on our website. However, these things may not happen until after the holidays. In the mean time, here's everything I did to get an app deployed.
  1. Purchased a new dedicated server from InMotion Hosting. A VPS would work just as well once this is stable, but for our testing, we want a dedicated box where we can control every variable, and not cause problems for other users on the same server should our app eat up all resources or something. It is a CentOS server with cPanel installed, very similar if not identical to the average hosting package.
  2. Downloaded and installed mod_fastcgi. This requires root access, so either get root access or ask Tech Support for assistance. For me, it was very easy, but not everybody is as comfortable with the command line.
  3. I modified /usr/local/apache/conf/includes/pre_main_global.conf. This can be done via command line, or through WHM. I added two lines:
    LoadModule fastcgi_module modules/
    FastCgiConfig -minProcesses 0 -maxClassProcesses 1
  4. Restarted Apache
  5. Uploaded an app using FTP as if it were any other file.
  6. Set the app as executable. This can be done with any good FTP client.
  7. Added an .htaccess file to the directory containing my app:
    Options +ExecCGI
    AddHandler fastcgi-script .fcgi
  8. Visited the URL for my app to test. The URL will be dictated by the directory structure you uploaded your app to.
One last bit of information this test unveiled is that default installations of cPanel will relaunch Apache every 2 hours. When this happens, your application will be stopped as well, and your users disconnected. We are investigating a solution to this issue, but that solution will NOT make it into r5.1. In the mean time, the only solution we can offer is to disable log processing, or at least slow down the rate at which logs are processed. This can be done using WHM, under the "Server Configuration" section, look for the "Statics Software Configuration" option. There is a thread on the cPanel forums about this issue at for those interested.

Tuesday, December 14, 2010

Fixing an issue with FastCGI

Last week, just as we were preparing our final candidate build of Web Edition, it was discovered that there is an issue with FastCGI. FastCGI apps, especially under Linux, can get into states where they are using 100% of the CPU. Clearly that's not going to work if you have anything else running on the same machine.

The solution requires us to make some fairly significant changes under the hood which will need to be well-tested before they can be released. So I made the decision that we would go ahead and ship R5 so that you can start developing and testing your apps. We will ship an update (5.1) that will include this fix once it has been well tested. These updates will always work with any license key that worked with the major release (R5 in this case) so you don't need to worry about missing the fix.

This issue ONLY affects deployment as FastCGI. It does NOT affect building your app as a standalone HTTP Server.

We apologize in advance for this last minute issue. We will get you the update as soon as we can.

Announcing REAL Studio Web Edition

Today we are announcing the general availability of REAL Studio Web Edition, the first web application development tool designed for both ordinary people and traditional software programmers. REAL Studio Web Edition allows users to easily create rich, web 3.0 applications up to 50 times faster than traditional web development tools by using a single programming language rather than several web technologies.

The complexity of coding web applications has prevented many developers as well as hobbyists from attempting to create innovative new web-based applications. REAL Studio Web Edition uses a single, high-level, object-oriented language that is tightly integrated with the REAL Studio web framework. This allows developers to focus on what makes their application unique. Because of its unique interface, almost any app built for the desktop can now be created for the web with ease, without the need to learn five different web technologies.

Web Edition’s visual interface builder allows the user to create an interface via “drag and drop” rather than hand-coding it in HTML. Behind-the-scenes, the web framework translates the user interface on the fly into the appropriate web technologies required by the browser, thus eliminating the need for the user to know the above mentioned web languages and technologies. The integrated debugger makes tracking down bugs far easier than traditional web development tools. Additionally, the interface controls are supported on all browsers, which eliminates testing on each browser which is required with other techniques.

REAL Software applications are uniquely compiled to machine code for fast execution, allowing developers to sell their software with the knowledge that their intellectual property is safe and secure

“More and more users want applications delivered via their browser, but the complexity of doing so made it out of the reach of most people. Now ordinary people and software programmers alike, who once thought the learning curve was too steep, can build web applications easily and quickly,” said Geoff Perlman, REAL Software founder and CEO. “We currently have a seven-year-old creating an application using this new tool and if a child can learn REAL Studio, anyone can.”

REAL Studio Web Edition is available today for $599. It is included in REAL Studio Enterprise Edition, which also allows developers to create high quality applications for Mac OS X, Windows and Linux. REAL Studio Enterprise Edition is priced at $995. REAL Studio is available in a 30-day trial and also includes a 90-day money back guarantee.

Tuesday, December 7, 2010

REAL Studio and the Mac App Store

When Apple announced the Mac App Store, some in our community began asking if applications created with REAL Studio would be accepted. Having looked over the requirements, there was no reason I could see why they wouldn't be but the ultimate test would be an app made with REAL Studio being accepted into the Mac App Store.

Christian Miller of Pariahware, Inc., a long-time REAL Studio developer, announced yesterday on the REAL Software forums that his Doc Merge app (which was created with REAL Studio) has been accepted by the Mac App Store. Congratulations Christian!

There are several other developers with apps that are awaiting review by Apple but the fact that Christian's was accepted suggests that Apple is following its requirements and apps made with REAL Studio that meet those requirements will be accepted. Of course the more apps that are accepted the better but for those of you curious about the Mac App Store, this is certainly a very good sign.

Monday, November 22, 2010

Black Friday Sale 30% off all New REAL Studio License Keys

New REAL Studio licenses will be on sale for “Black Friday”, November 26, 2010, the biggest shopping day of the year, from 12:00 AM to 11:59 PM CST. All new licenses will be discounted to 30% off of their original price.

If you are interested in getting REAL Studio Enterprise edition in anticipation of REAL Studio Web Edition, this is a great opportunity to get 30% off!

REAL Studio is a desktop, console and web development tool. Using REAL Studio developers can create powerful cross-platform applications for Mac OS X, Windows and Linux ranging from utilities to full-featured enterprise applications and everything in between. Creating web applications for REAL Studio will be available soon as a feature of the Enterprise Edition. REAL Studio is great for both those who are new or want to learn programming and professional, full-time developers.

REAL Studio is available in three editions: Personal, Professional and Enterprise. REAL Studio Personal Edition, priced at $99, is ideal for students and hobbyists and those making software for themselves. REAL Studio Professional Edition for $299 is geared for the more advanced user and includes the ability to compile for all three platforms (Mac, Windows and Linux). REAL Studio Enterprise Edition is fully-charged for the professional, full-time software developer and allows developers to develop and deploy on all three platforms. The upcoming Web Edition will be included in Enterprise Edition. REAL Studio Enterprise Edition is priced at $995.

REAL Software offers a 90-day money back guarantee on new licenses, so developers can purchase their license at the discounted price during this one-day Black Friday sale and get a full refund within 90 days if they are not fully satisfied.

To take advantage of this sale visit on Friday, November 26th and the discount will be applied in the store.

REAL Software is currently shipping REAL Studio 2010 Release 4.1 and all versions are available for download now at REAL Studio is available in 30-day free trial editions.

Friday, November 5, 2010

8 Digit Authorization Code Solution

In direct response to your feedback we have added a way for users to generate 8 digit codes as needed from within your account at the REAL Software website. If you are prompted for an 8 digit code while registering your REAL Studio license key you no longer need to contact REAL Software directly. To generate this code on your own just log into your account and go to your Account page. In the menu on the right select "Get Authorization Code" and follow along with the directions on the website in REAL Studio.

If you are wondering why you are being prompted for this code you can read more about it here. If you have not registered your account or don't see your keys in your account when you log in, you can find tips here or you can contact Customer Service.

We appreciate your patience with this process. We have plans to make this easier for our users in the future and look forward to implementing those changes. In the meantime, if you have questions or comments please contact Customer Service.

Friday, October 29, 2010

Faster compiling

Fabrice Garcia, a REAL Studio user, pointed out that if you can compile to a memory-based storage device, compilation is much, much faster. For Windows 7 users, you need an SD card and use the Windows "ready boost" feature in Windows 7.

For Mac users, there may be SD card options but the new MacBook Air uses only memory-based storage. So if you are thinking about a Mac laptop, that might be a consideration.

Monday, October 4, 2010

Can a web application use a single user database?

There have been some questions about whether or not a web application could use the single user database engine, REALSQLDatabase. In theory, the app is a server of sorts (managing all the users that are connected) and it would be the only application communicating with the database file which is how many database servers work.

One big difference between REALSQLDatabase and a database server is that database servers handle record locking. When one user wants to edit a record, the record can be locked by the database server so that others users can't edit it. REALSQLDatabase has no facility for that. You could create your own system by storing an array of objects either globally on the app class (or in a module) or as a property of each session where each session would keep track of which record or records it is editing.

REALSQLDatabase is based on SQLite. SQLite allows for any number of users to read the database at the same time but allows only one user to write to the database at a time. If a user attempts to write to the database at the same time another user is doing so, an error will be generated. You can determine this by checking the Error property of your REALSQLDatabase object immediately after doing anything that updates the database. Because of SQLite, REALSQLDatabase is very fast at updating records and in our limited testing, we could not get it to do two updates at the same time and produce an error.

Currently, when you add a database connection to your web project the connection is handled globally rather than by session. If your app's database access is user-driven, as in a case where the user initiates a query for example, then you should connect to your database via code so that you can store the database reference on the session class. With this technique, each session will make a separate connection to the database and SQLite can manage things properly (as best it can). Before we ship our web framework, we will likely change this internally so that database connections added to the project will automatically be session-based.

So depending on the nature of your application and the number of users that would need to write to the database at the same time, REALSQLDatabase very well may work for you. Just keep in mind that you will want to test for an error after any update to the database (which you should be doing anyway) and that if you need some kind of record locking, you'll have to implement your own system for that.

If you have a traditional database-oriented application, you will be better served (no pun intended) by using a traditional database server.

Wednesday, September 29, 2010

Upgrades and Renewals and Updates and Bears, Oh my!

With the recent introduction of the upcoming REAL Studio Web Edition I've received a lot of questions about how to upgrade/update/renew existing license keys. I want to clarify how REAL uses the terms Renewal, Upgrade and Update.

Renewal - A 12 month Renewal gives you access to the current REAL Studio release and all releases for the following 12 months. You can Renew any "Modern" REALbasic/REAL Studio license key anytime, before or after its expiration date. Pre-2005 license keys must be Upgraded to the "Modern" edition before they can be Renewed.

Upgrade - You can Upgrade any existing REAL Studio license key to any edition up the line. For example, you can Upgrade your Personal license key to Professional or Upgrade your Professional license key to Enterprise. You can even Upgrade your Personal license key to an Enterprise license key, it will always save you money to Upgrade an existing license key. Upgrading a license key adds 6 months to the existing expiration date.

Update - You can "update" your license key by purchasing a Renewal. This will give you access to the current REAL Studio Release and all releases for the following 12 months.

Bears - We don't sell bears.

Your REAL Studio license key belongs to you and you are never required to Renew or Upgrade. I hope this answered your questions about REAL Studio license keys and subscription plans. We try and keep it simple here. Have you seen the REAL Studio License Terms? You can read the whole thing in under 5 minutes!

Remember, if you are developing professional applications it will always benefit you to keep your license key current. REAL Studio code maintenance should be an ongoing process not a quantum leap!

As always, if you have any questions about Upgrades, Renewals or REAL Studio please email Customer Service.

Tuesday, September 28, 2010

Where on the web does your app run?

There has been a lot of discussion about our upcoming Web Edition on our beta list which is really great. One thing that some people seem to not be clear about is exactly where your code executes. Allow me to explain.

For those of you that haven't look into our Web Edition, you build web applications in a way that is pretty much identical to how you build a desktop application. You drag and drop, you double-click and create your application logic using the same language you use for the desktop. The difference is where code executes. In a desktop application, all code is executing on your computer as an application. For web applications, your application is on a server so it executes there and sends all the necessary stuff behind the scenes to the user's browser to provide them with your UI so they can use your application.

So from your perspective as the developer, you will develop basically the way you always have using REAL Studio. From the end user's perspective, the app will act very similar to how a desktop app works. Think of a page as a window and it's all the same. We handle the rest of the magic to make it work like that. If that's all you needed to know, stop reading here. If you want more nitty-gritty details, read on.

Let's take a simple app with a single page, a textfield and a button. The button is coded to set the Text property of the Textfield to "Hello World!". You created the app by dragging a Textfield and a Button onto a page. You added TextField1.text="Hello World!" to the Action event of the Button. You built the app and installed it on a server. That's everything you had to do. Now what happens when a user comes along?

When the user enters the appropriate URL to get to your app, our framework (inside your app) goes to work. It turns your page into HTML, CSS and JavaScript on the fly and sends it to the user's browser. The user can type all they want in the TextField, resize the window, etc., but that will not matter because the only thing your app cares about is the Button's Action event. Any other event that occurs will not create any communication with your app on the server because you didn't implement any other event. When the user clicks the button, the JavaScript that was generated to react to that event fires and sends a message to the your app on the server. Your app executes the Action event. And since this updates the TextField, the HTML and CSS needed to update the page are generated by the web framework and sent to the browser where the browser shows the updated page. This all happens really fast. And for each page a user has open, there is an equivalent object in memory on the server that represents that page. This allows us to save the state of that page as the user moves from one page to the next (even though the browser is only showing one page at at time to the user).

The thing that does not happen is any kind of translation of your code into JavaScript. Your code executes on the server and it's fast because unlike most web technologies, your code is compiled to machine code rather than interpreted at runtime.

Over time, we will add more ways to automatically generate JavaScript that takes care of more things in the browser to make communication between the browser and your app more and more efficient. And you will be abstracted from these details so you can focus on what makes your application unique.

If you still have questions, fire away.

Update on Cocoa

There has been a lot of excitement around our announcement regarding the new Web Edition and it's made some people wonder what is going on with Cocoa. So let me give you an update on that.

First of all, Cocoa progress is not in any way affected by our Web Edition. Different engineers have different sets of skills so we can't productively put engineers working on the Web Edition to work on the Cocoa framework. It would be great to have that kind of flexibility but it's not realistic.

For REAL Studio 2010 R4, there are over 30 bug fixes related to Cocoa specifically and a few new features as well. But we are not just fixing bugs. We are also refactoring code to make it more efficient and easier for us to maintain so that there will be fewer bugs in the future.

At this point, all Cocoa work now has shifted to R5 which will likely ship in early December. By that time, we believe the Cocoa framework will be in good enough shape that you should be able to run your apps under Cocoa with some bugs but your apps may not be shippable. For 2011 R1, most applications should run with few if any bugs and be shippable to your end users. The IDE itself will be in a similar shape. For R5 we will have it running but buggy and for R1 it should be shippable.

The journey from Carbon to Cocoa has been a long one but we are seeing the light at the end of the tunnel.

Thursday, September 23, 2010

Porting a desktop app to the web

With the ability to build web applications coming to REAL Studio soon, I'm sure many of you are thinking about creating a web version of some of your desktop projects. Whether you are going to continue to have both a desktop and a web version and wish to share code between them, or you plan to move your project entirely to the web, there are some changes you may have to make to do so.

Primarily, these changes are in three areas: communication with user interface controls, reporting and graphics.

Communicating with User Interface Controls
Although the user interface controls in our web framework are for the most part very close to their desktop equivalents, they don't share any code with those desktop equivalents. As a result, they are not the same classes under the hood so you can't have code that directly talks to both a desktop pushbutton and a web button. So the first thing you have to do (if you haven't done this already) is separate this code from the UI.

I have started porting a desktop project to the web recently. The project is a very fancy calculator of sorts. The user fills in 10 or so fields, chooses some options and the app calculates the advantages of doing one thing instead of another. The window is filled with methods, each of which is essentially a formula. Anytime the user changes a value in a field, a bunch of these methods run and update StaticText controls that show the results. Since these methods can be directly accessing controls (even via parameters unless I only pass in values), I have to change the way the methods get their data.

To port this to the web, I created a class (which I called "scenario" since one set of data and results is a scenario in this case). I moved all the methods to that class and then created properties for each of the fields on the window. I added a property to the window that holds a reference to a Scenario object and I create that object in the open event of the window. The fields now just update the properties and the methods use those properties rather than the fields themselves. Once I was sure that worked and produced the same results as before, I made the class an external file so I could share it with the web project.

Once I had made this change, I imported the Scenario class into my web project and added code to the controls on the page to update the same properties. So if you have your code and UI closely tied together (as I did), you will need to separate them first. You can do that today in preparation for building your web version. Incidentally, this kind of separation is just good design as well. And by using the class as an external item in both the desktop and web projects, I can fix or enhance the code in this class from either project.

If your desktop project prints, then you'll need to take a different approach for the web. Printing for a desktop project means drawing into a graphics object or using the Report Editor. Using a graphics object isn't a great solution for the web because you can't send it right to the printer. You would have to display it on a page. Sending page-sized graphics over the internet is not a great idea regardless of what tool you use to build your web app. And the Report Editor is not supported for web applications right now. The best solution is to create a page which you lay out for printing. Then you just fill in values, most likely into labels (the statictext control of the web framework) and present the page to the user. They can then print the page directly from their browser.

There's not much in the way of overhead when it comes to using graphics in a desktop application. In a web app however, the varying speeds of the Internet between your app and the user's browser, will impact the responsiveness of your app so you need to be thinking about how to optimize when it comes to sending large amounts of data from the app to the browser. Large pictures will be time-consuming. You can make them smaller by using JPEGs. But if possible try to avoid using pictures. There are other ways, in some (certainly not all) cases, to use controls such as rectangles combined with styles to create graphics that are smaller and can be cached automatically by the browser. For example, to create a monthly calendar, use rectangles and labels rather than drawing the whole thing in a big picture.

In summary, there are some things you can do now to start preparing your desktop project to become a web project. There are also things you can start thinking about in terms of how you will approach printing and graphics in your web application. It's going to take some trial and error to find the techniques that make the most sense for you.

Saturday, September 11, 2010

The stigma of BASIC

Back in 1998, we chose the name "REALbasic" for two reasons. First, it would suggest that this might be similar to Visual Basic and second, it suggested that the language would be easy to learn and use. But over the years we discovered that some people would make a lot of assumptions about the language because it included the word "basic" in it. The biggest assumption has been that it must be BASIC as in the language invented at Dartmouth College in the 1960's. Nothing could be further from the truth.

The original BASIC was procedural, under-powered and interpreted. BASIC is an acronym that means Beginners All-Purpose Symbolic Instruction Code. It was designed primarily to teach people programming and not to write large applications.

The language of REAL Studio, REALbasic, is as object-oriented as Java, very powerful and compiled. If you doubt this, consider that REALbasic is strongly-typed and supports inheritance, interfaces, polymorphism, operator overloading, introspection, delegates, RTTI (runtime type information), exceptions and the list goes on. And if you're new to programming, you can ignore almost all of this until you are ready. That's what makes REALbasic approachable. There are only a few keywords (such as Dim, Left, Right and Mid) that REALbasic and the original BASIC share in common. But they they do share one important thing in common. The goal of both languages is to make it easier to learn and write code. In BASIC as in REALbasic, there's one line of code per line. No need to remember to end each line with a semi-colon and no creating crazy lines of code that can't be read. Such as this in C:

v(c,j ,K){ char*P=E[c][j];
The point is to focus your attention on solving the problem and to avoid getting distracted by the semantics of the language itself. REALbasic, as a language, is every bit as powerful and object-oriented as C#, Objective-C, Java or C++. But it was designed to be much more approachable than these languages especially when combined with the REAL Studio IDE. I've had many users tell me that they tried for a long time to get a friend or co-worker to look at REALbasic but they wouldn't because of the word "basic" in the name. But in all cases, when they finally agreed to look at it, they found they really, really liked it. They were converted.
Now you could say that I'm just making an argument for changing the name or perhaps ust dropping the word "basic". Perhaps we just called the language "RB". PHP for example, is an acronym but it no longer means that anymore. It's just PHP. This is a discussion for another blog post.
So the next time you meet someone that looks down on REALbasic because of the word "basic", tell them that it's a misnomer and that REALbasic is a very powerful, object-oriented language that compiles to machine code and shares only the few good parts of the original BASIC. Convince them that they really should look deeper. You'll be doing them a favor. And you'll be doing the community a favor by growing it by yet another member.

Thursday, September 9, 2010

iOS Development in REAL Studio

Today Apple announced that they have loosened the restrictions on the iOS Developer Program License Agreement. I think "loosened" is an understatement. They have removed all restrictions that would prohibit us from bringing iOS support to REAL Studio. Apple said that they have been listening to developers and as a result, have made changes that allow for third party tools but at the same time, allow Apple to keep the level of security they need.

Apple really does listen to developers. We have been having discussions about iOS support with Apple for some time now. Based on today's announcement, it's clear they really have been listening to us and others.

iOS support is the number one feature request in Feedback, our bug and feature request tracking system. But it's not just number one. It's way number one. We calculate a score for each case and the score for iOS support is almost 3 times (300%) higher than that of the case in the number two spot. Whereas the case in the number two spot is only 10% higher than number 3. So we hear you loud and clear regarding iOS.

iOS devices (as well as most other mobile devices) use an ARM processor. Before we can support iOS, we need to have an ARM backend for our compiler. And as many of you already know, we are in the process of moving the backend of our compiler to LLVM (the same compiler that Apple is moving to) and LLVM has ARM support. In fact, the ability for us to support mobile devices was a significant factor in the decision to move to LLVM. RBScript now compiles using LLVM. The next step is to get applications compiling with it. That is no small step but it's also not as big as it might first seem. Getting RBScript working was the biggest step and that's done. We still have a lot of work to do but we are certainly over the hump.

What does all this mean? Well, I'm not here today to announce iOS support. But I can say that the path has now been cleared of any obstacles that might stand in our way.

Thank you Apple, for listening to us and other developers and finding a solution that provides the security you need while giving us the option to support iOS in REAL Studio.

Friday, September 3, 2010

REAL Studio Web Edition App on iOS

Check out the latest sneak peek of REAL Studio Web Edition to see an unaltered Web Edition application running on the iPhone and iPad.

Wednesday, September 1, 2010

REAL Studio Web Edition Beta Program

A lot of people have been asking me about getting into the REAL Studio Beta Program. It's easy to join - just log into your account on the website and go to Beta Program, or visit You must have a current REAL Studio key to join the program, and you can join with any edition of REAL Studio.

Additionally, we have set up a forum for REAL Studio Web Edition. Bring your questions, share your excitement (we are!) or just talk about what kind of web apps you want to start on!

Don't forget to tell your friends about REAL Studio Web Edition. Tweet it! Facebook it! Digg it! Help get the word out there! If any of you are writing articles or blog posts about REAL Studio Web Edition please let me know so I can link to you and help you with promotion.

Tuesday, August 31, 2010

Web 3.0

When my dad first started programming, he programmed in binary by flipping 8 switches on the front of a computer then pressing a button to enter that single byte. He was quite literally flipping bits. This was considered first generation programming. Then assembler came along which was a lot easier than binary machine code. This was second generation programming. Finally, someone realized that for real productivity, languages needed to be English-like (since almost all programming at that time was happening in English-speaking countries). Languages like BASIC, Pascal and C appeared. This made programming far easier and more accessible because it was not only English-like but programs were finally abstracted from the details of the computer processor itself.

When the web came along we first had HTML, JavaScript and PHP. What you could do with these languages was so primitive, they weren't even called web applications. You could create forms and when a submit button was pressed, all the data was sent to the server where a program written in an entirely different language would process the results, recreate the page (or a new page) and send the entire thing back to the browser. This was web 1.0. AJAX brought an incremental improvement to this process where pages could be updated rather than replaced. Web applications became more responsive. This was called Web 2.0.

But web 2.0 applications are just a mishmash of files and languages. Because there are so many technologies, learning all of them is difficult and building applications with them is time-consuming and expensive. A web developer told me yesterday that it's very difficult for them to find developers. Candidates might know two of these five languages/technologies needed but rarely do they know all five (HTML, CSS, JavaScript, PHP or Java and AJAX).

Web 3.0 is supposed to bring real applications to the web. REAL Studio Web Edition provides a level of abstraction that allows developers to build apps quickly and easily, concentrating their efforts on what makes their applications unique. REAL Studio Web Edition really is web 3.0. It is finally here.

You can learn more about our new web platform here.

Announcing REAL Studio Web Edition

Monday, August 30, 2010

Adding private information to Feedback cases

Did you know that you can add private information (including attachments) to public cases in Feedback? There are times when you want to provide us with information and perhaps even projects that show off a particular bug but don't want that information shared publicly. If you create a new case and mark it as private by clicking the "Keep This Information Private" checkbox, only REAL Software can see it. However, there are times when you want to share the bug itself with the rest of the community but you might also need to keep some of the information private. You can do this by creating a public case, saving it, then going back and adding additional information afterwards and clicking the "Keep This Information Private" checkbox when making those additional entries. And of course, this same technique works with public cases created by others as well.

Reporting cases via Feedback is the best way to get information about bugs and feature requests to us. For bug reports, including a simple project that does nothing more than demonstrate the bug will help get your bug fixed faster.

Wednesday, August 18, 2010

Just a couple of quick reminders...

Do you follow us on Twitter? If not... you should! @realsoftware

If you are on Facebook, join our Facebook group!


Tuesday, August 17, 2010

Future support for PowerPC

Apple's switch from the 68000 series processor to the PowerPC was a bold move. The fact that they made that transition so smoothly is nearly miraculous. The switch to using the Intel processor was another bold move though having gone through a processor switch already, it was certainly easier.

It's been four years since Apple announced the transition from PowerPC to Intel. With such a small percentage (about 5% to 7%) of Mac users using PowerPC, we have decided to phase out our support for PowerPC.

Beginning with REAL Studio 2010 Release 4, PowerPC support will no longer be actively supported. This means that it will still be a build option but we will no longer be testing or adding features to our PowerPC-based Mac framework. We will fix bugs but only the most problematic. Having said that, we rarely get bugs that are PowerPC-specific. Our Cocoa-based framework will be supported for Intel only. We will continue to provide PowerPC as a build option for another year or two.

Phasing out support for PowerPC allows us to focus our efforts on the platforms that the vast majority of our users care most about. Ending support for a computing platform is rarely an easy thing for anyone but to best serve the majority of you, our customers, we need to put our resources to the best possible use.

Tuesday, August 10, 2010

Documentation ch-ch-changes

Last year we began a process of changing the way we manage our documentation. Since 1998 we had used Adobe Framemaker to produce the documentation. This was limiting because it basically only allowed one person to make changes. After evaluating many possible solutions we decided that using a wiki made the most sense.

One advantage to using a wiki is that it tracks every change we make. If you'd like to keep up with those changes, you can do so by visiting the Recent Changes page on the wiki. On that page you can also get the RSS and Atom links if you want to subscribe to a feed of the changes.

Should you find anything that you believe is an error or omission in the documentation, the best way to let us know is to file a case using Feedback.

Tuesday, July 27, 2010

Important Information Regarding Cocoa Build Option

A Beta version of our Cocoa-based framework is included in REAL Studio 2010 Release 3, which is now available. While it is feature complete, it is not bug free or even close to that. Beta is defined as being feature complete but still needing usability testing. For more information about what beta means view the Wikipedia article,

We decided to release a beta version so that we can maximize feedback about what doesn't work. While we have plenty of bugs left to fix, we want your feedback on as many issues as possible to make sure that Cocoa is of sufficient quality before we release it. Some of your projects will work and some will not. The more complex your projects are, the more likely they will not work. For example, a project that would otherwise work perfectly can be stopped by a single bug in a single control. If your project depends on a plug-in that provides any user interface, it will probably not work. Check with the author of the plug-in to see what their plans are for Cocoa support. When you find an issue, search using the Feedback application to see if this issue has been reported. If you have some additional information to add, please do so. If you have a simple project that reproduces the bug, please add it. And of course if the case has not been reported, please report it. Steps to reproduce a bug or a simple project really help gets bugs fixed faster. You can include screenshots as well, which can help when describing cosmetic bugs.

It is also important to us that you see we are making progress. Many of you are waiting as anxiously as we are for this transition to happen. Try each of the controls. Experiment. You will see that many things do work. The most important elements to try out are user interface controls. If your application builds but crashes on launch or at some particular point, create a report and include a crash log. Those details will help us track down crashing bugs. There are new pushbutton types, drag and drop provides ghosting now, your TextField controls support the Mac OS X spell checker and if you are into making OS API calls, check out the CocoaObject examples in the Examples folder.

Based on the speed at which we are fixing Cocoa bugs, we believe we can be ready to ship by the end of this year. Your help with trying out your projects and reporting bugs will help us to reach that goal.

There is a Cocoa Beta Information document included in the product download where you can find more information about the availability of the Cocoa beta.

REAL Studio 2010 Release 3 Now Available

AUSTIN, Texas, USA (July 27, 2010) — Software development tools company REAL Software today announced the availability of REAL Studio 2010 Release 3. REAL Studio is a cross-platform software development tool that enables developers to create high-quality, native applications for Windows, Mac OS X and Linux. Along with increased productivity, developers who use REAL Studio also report an increase in revenue for commercial applications, since they are able to get their product to market faster and expand their offering to multiple platforms. REAL Studio has a low learning curve, making it the perfect development tool for both those who are new to programming and professional software developers.

REAL Studio 2010 Release 3 includes 81 improvements and 25 new features. The new functionality includes:

  • LLVM for RBScript: RBScripts now run up to 17 times faster than in previous releases. Using LLVM for RBScript is the first step towards the adoption of LLVM for building applications in REAL Studio.
  • Cocoa (Beta): The option to build for Cocoa is now available, but is at the beta stage. There are some new features for Cocoa builds, such as Pushbutton now has a ButtonStyle property that gives access to nine new styles of pushbuttons.
  • Documentation: The REAL Studio documentation is now locally stored and the user can choose between viewing the local version or the online documentation,
  • Reporting Improvements: To make reporting easier, reports can now take a RecordSet directly to report upon.
  • Database Improvements: ODBC and REALSQLDatabase queries and updates no longer block the other threads while they are executing. This allows users to make their user interface more responsive.
  • Graphics Improvements: All of the graphics classes are now supported in Console applications. Also, pictures can now be copied to and from MemoryBlocks using a variety of picture file formats. Since memoryblocks can be transformed into strings, this allows the user to store pictures without having to write them to the disk first.

“Over the next few releases of REAL Studio we will be transitioning to LLVM. LLVM for RBScript is the first step in this transition,” commented Geoff Perlman. “In this release developers will see a marked increase in their RBScripts and will see an up to 10x speed improvement once we move the main compiler to LLVM.”

The complete list of improvements and new features in REAL Studio 2010 Release 3 can be found in the release notes in the product download section,

Thursday, July 22, 2010

What's up with this 8 digit code?

I've talked with a lot of users lately about our validation process and subsequent prompts for 8 digit codes. Validation of your REAL Studio license will happen whenever you enter a key into the registration dialog, revalidation happens every 90 days. If you are online and using REAL Studio 2010r2 or later validation and revalidation will happen quickly and automatically.

If you are not there are a few different reasons you may be prompted for an 8 digit code when validating your REAL Studio license key.

1. You are working offline.

2. You are working behind a proxy server or firewall. In most cases this happens to users trying to validate from schools, universities and secure work environments and your REAL Studio is unable to communicate fast enough with our system.

3. You are using a version released prior to REAL Studio 2010r2. For more details on this visit Geoff's earlier post.

So how to do you get an 8 digit code?

Email Customer Service. Make sure to include the license key you are validating.

You have an 8 digit code but get an error when you try and use it.

As a security measure we have implemented a 2 minute wait time between when REAL Studio prompts you for the 8 digit code and when you click Continue. You must wait at least 2 minutes at the screen requesting the 8 digit code or you will receive an error message when you click Continue. If you do receive this error message simply click Back, wait the 2 minutes and click Continue again.

Once you have validated with the 8 digit code your usage should not be interrupted again on that machine. Revalidation will not prevent usage if you do not have an internet connection or are using an older release, it will simply be delayed until later.

We appreciate your patience with this process. We have plans to make this easier to our users in the future and look forward to implementing those changes. In the meantime, if you have questions or comments please contact Customer Service.

Sunday, July 18, 2010

Exceptional Exceptions

If you're like me there's a good chance you learned programming using a language that didn't have the concept of exceptions. Instead, you probably had some error parameter to check to see if the call you just made succeeded. And if you're like me, you've probably heard that the REALbasic language has a feature called "exceptions" but you don't know much about them. You may know that they happen and that when they do it means something has gone wrong, but that's about it. Until quite recently, that was me. I didn't mess with exceptions because I didn't fully understand them and using an IF statement to check for an error was somehow more familiar and comforting.

In an effort to make the REALbasic framework more self-consistent, we are deprecating a few functions which are going to require you and me to get familiar and comfortable with exceptions. If the word "deprecation" is unfamiliar to you, it means we are not longer going to support a particular feature and will, one day far in the future, remove the feature. However, we do remove the deprecated feature from the documentation immediately to discourage its use. Why would we do this? Because if we don't, the REALbasic framework will age and be filled with "cruft" as we call it. Cruft is extra, unnecessary stuff that we have to maintain and thus adds to the expense of bringing REAL Studio to you. It also confuses new users as they aren't sure whether method A or B is the right one. If we don't deprecate things in favor of a better way of doing something, one day we could be in real trouble when some technology we have all grown to depend on suddenly doesn't work anymore and we require you to make massive changes to your code to move it forward. So think of deprecation as being like the pain of regular exercise. It's necessary, not always fun but better than the consequences of a lifetime of neglect.

So back to why you need to learn about exceptions and why they can actually be fun and rewarding. In REAL Studio 2010 Release 3 (the next release of REAL Studio) we are deprecating the NewPicture function along with NewMemoryBlock and NewAppleEvent. There are two reasons for this. First, these functions are not consistent with the regular way you create objects. For example, to create a new date object, you use this syntax:

Dim Today as New Date

Wheras with the NewPicture function, for example, your syntax would be:

Dim p as Picture = NewPicture(100, 100, 32) //the parameters are width, height and depth

The difference here appears to be nothing more than the space between "New" and "Picture". After all, this syntax is also valid:

Dim p as New Picture(100, 100, 32)

But in this case, you will need to use an exception. More on that in a moment.

The second reason we are deprecating these functions is because of how you deal with them when things go wrong. NewPicture (along with NewMemoryBlock and NewAppleEvent) creates something and returns the object if the object was created successfully or nil if it was not. When these functions return an object, life is good. When they return false however, the reason for that failure is unknown. Your guess is as good as mine.

Not with exceptions however. Exceptions give you a way to know exactly why an object was not created and they don't require any more code than an IF statement. In fact, they can sometimes require LESS code. Let's consider the following Canvas Paint event example where we create two pictures using NewPicture and then draw one into the other , then draw the result into the canvas:

This example has 14 lines of actual code. The two IF statements that check to see if the object was created or not make the code more complex and harder to read. Here is the same code rewritten using an exception:

Using exceptions, this code is only 10 lines and it a lot cleaner and easier to read. The catch statement at the end makes it quite clear why the pictures could not be created so your code is more self-documenting and readable. And of course, you could trap for other possible reasons as well.

Now, in the exceptions example I'm only dealing with the fact that either picture could not be created. But in this example, if I can't create one of them, then there's no need to continue. The reason exceptions are called "exceptions" is that they are not likely to happen. If they do, that case is an exception. Hence the name. In the first example, I have to have an IF statement after each attempt to create a picture. If I don't my app will crash with a NilObjectException. Yes, an exception. So you are dealing with them anyway. But in the second example, using an exception, I don't need to do this. If one of the pictures cannot be created, the code will immediately move down to the Catch statement.

Finally, if you have some code that should execute even if an exception has occurred, you can add the Finally statement after Catch but before End Try. You can see an example of this here.

Now you may think you've got a better way to write my examples above and you probably do if you think that. After all, I'm the CEO and that "E" doesn't mean Engineer. But the point is, exceptions are either the same amount of code or less than using IF statements and make your code easier to read and more self-documenting. They are a good thing. Do you have a choice to use them or not? For now, yes. But some day, a long time from now, NewPicture, NewMemoryBlock and NewAppleEvent will be removed entirely and then you will have to use the New keyword and exceptions so why not start today?

Think of this as an opportunity to learn something new and sharpen your skills. If you need some extra, added incentive, many other object-oriented programming languages support exceptions as well. Not that you will ever need to use any other language of course.

Friday, July 16, 2010

Tip: Pushbutton Height and Backdrops on Mac OS X

With the Mac's market share approaching 10%, more Windows developers are wanting to cross-compile their projects to support Mac OS X. If you are coming from Windows, this tip will help you understand a few issues you may face and how to deal with them.

It may surprise you to find that there is a restriction on the height of a pushbutton on Mac OS X. If you make a button more than 22 pixels high, the button will change from being rounded to rectangular. This is not a feature of REAL Studio. It's a feature of Mac OS X:

Bonus Tip: If you add a background picture using the Window's BackDrop property, on Mac OS X your controls will have rectangles around them with a background that matches the window. As a result, they will look like this:

However, if you set the Window's Composite property to true, the rectangle will disappear:

You will continue to see the rectangle in the Window Editor on Mac OS X, but not in your running application. The rectangle in the Window Editor will likely disappear once we are compiling the IDE itself as a Cocoa application. Depending on the complexity of your window, you may or may not have some issues with using the Composite property as it has some problems on Carbon. However, these issues should disappear once you can build using the Cocoa option as all windows in Cocoa are composite and are handled quite well.

Thursday, July 15, 2010

REAL Studio to Include Cocoa Framework Beta in Upcoming Release

AUSTIN, Texas, USA (July 15, 2010) — Software development tools company REAL Software announced today that their rapid application development tool, REAL Studio, will include the option to compile a Cocoa application in the upcoming 2010 Release 3. REAL Software has been working on the development of the Cocoa framework for a long time and though it is not yet complete, it is far enough along that it will be made available as a beta to all REAL Studio users.

On Mac OS X there are two ways for applications to communicate with the operating system: Carbon and Cocoa. Carbon was designed to allow applications from Classic Mac OS, like REAL Studio, to run natively on Mac OS X. Cocoa is the method that has been part of Mac OS X since its introduction and all applications must move to Cocoa to continue to be modern.

Unlike when other companies have gone through the conversion, REAL Software is trying to minimize the impact on their users. One of the many benefits of using REAL Studio is that developers are mostly abstracted from having to deal specifically with platform details. REAL Software has developed this new Cocoa framework in such a way that REAL Studio users will only have to recompile their applications to get a Cocoa version. When recompiled most applications should simply work. In some cases minor changes might need to be made such as if users want to take advantage of new features, like additional button types.

“Our primary goal with the transition to Cocoa is compatibility for people’s projects; we want them to just work,” commented Geoff Perlman, REAL Software Founder and CEO. “Had our users been developing their apps in C or C++, they would have had to go through the enormous task of transitioning from Carbon to Cocoa themselves, but we’ve saved them the trouble since they are using REAL Studio.”

“Even some of the biggest software companies on the Mac have struggled to make the conversion and many have had false starts," added Perlman. "We are excited to be nearly complete with the transition.”

For more information about REAL Studio or to download the latest version, visit

Friday, June 25, 2010

Getting Rich (text) with Cocoa

In the next REAL Studio 2010 r3 build that beta testers will soon receive, we've added support for RTF (Rich Text Format) to the TextArea control in Cocoa. The Carbon TextArea control of course already supports RTF so this is really just for compatibility.

I tested the RTF support and what I found interesting was how the text rendering differed from Carbon to Cocoa. Consider the following two examples:

This is RTF rendered in Carbon:

This is RTF rendered in Cocoa:

You can see they are very different. The Cocoa rendered text is more condensed and harder to read. At first, I thought this was a bug. I opened the RTF file using TextEdit (which is a Cocoa application) and discovered that it's not a Cocoa bug, but a Carbon bug! Or to put it another way, the Carbon framework on Mac OS X appears to simply render RTF differently. In my case, I just chose a different font and now it looks great when I run my app under Cocoa.

By the way, the app I'm testing with is the same app I mentioned in the newsletter this month. With RTF now working, there is only one bug that would keep the app from shipping and two minor bugs that would be nice to see fixed before I ship it as a Cocoa app:

  1. The app prints a report and while it does print, the Print dialog doesn't close when it should.

  2. The about box doesn't display. Instead you get a generic Cocoa-created about box. (minor)

  3. The StaticText control renders its text 1 pixel too high (minor - for this app anyway).
It's good to see RTF working. We are making progress. There are still lots of annoying Cocoa bugs to fix but there's also a lot of stuff working well.

Wednesday, June 16, 2010

The mysterious relationship between credit cards and your REAL Studio license key

This past April I wrote about how companies accepting payment via credit card are being required to use a higher level of security (SSLv3). This is better known as PCI compliance. Most of you don't have to deal with this at all and will simply benefit from having your credit card number stolen less often. Actually, while I applaud the increased security, most credit card numbers are not stolen this by sniffing packets on a network, especially one using SSL. They are often stolen the old-fashioned ways (dumpster diving, for example, is a very common method).

But one way this could affect you (as I mentioned in the April blog post) would be if you have developed an application that connects via SSL to a web server that is also processing credit card payments. When that server is updated to SSLv3, your app may need to be updated as well. See my April post for more details on that.

One such application is any version of REAL Studio/REALbasic prior to 2010 release 2. We will be updating our web server to SSLv3 soon (we are required to by July 1st) and when we do, these older releases will no longer be able to connect to our server to verify your license key should you need to re-install it. But never fear. We have a solution. Should you need to reinstall your license key for REAL Studio/REALbasic 2010 r1 or earlier, please contact customer service and they will provide you with instructions. It's a very quick process. And we will reply back to your requests promptly.

I apologize in advance for the inconvenience. We, like all other companies that accept payment via credit card, are required to do this. REAL Studio 2010 Release 2 is already set up to handle SSLv3 so once you are up to date to this version or later, you will no longer have to deal with this problem.

Tuesday, June 15, 2010

Cocoa Update

Is Cocoa ever going to ship? I'm sure that is the question that many of you are asking.

This is really getting old. Every few months I write to you with an update on our progress moving our Mac OS X framework to Cocoa. I'm always conflicted when I write these updates because I'm sure you are interested in hearing about our progress but at the same time, I'm also sure that waiting for us to ship Cocoa support is as frustrating for you as it is for us.

There is a rule that is often true in software development that the last 20% takes 80% of the time. It sure feels like that's the case here. We do continue to work on it every day. For the most part, we are only fixing bugs at this point. Many of our beta testers tell us that their projects work now with few or no problems at all. For example, here's a screenshot from a project I personally wrote for a friend of mine. The Carbon version is on the left and the Cocoa version is on the right. They are nearly identical.

Of course the Cocoa version of this app has a few issues you can't see from the screenshots. The about box isn't working and there is an issue with the Print dialog (but it does print). Aside from that, this app works perfectly in Cocoa and gets a few benefits from Cocoa as well. For example, spell and grammar checking just works. I don't have to do anything to get that benefit. You will likely find that your projects, once recompiled for Cocoa, use less CPU time as well.

We are also hard at work on the Cocoa version of the REAL Studio IDE because of course the REAL Studio IDE is written in REAL Studio. It's coming along and we are seeing improvements in it each day.

And while our primary focus is on making sure that your existing projects will work with few if any changes when recompiled for Cocoa, we occasionally find opportunities to introduce some new Cocoa-specific features. For example, the Pushbutton class now has a ButtonStyle property that allows you to choose from nine additional types of pushbuttons:

When using drag and drop, you now get a ghosted image rather than a simple rectangle. View Carbon example movie. View Cocoa example movie.

For those of you that need to access Cocoa APIs for things that are not built-in to our framework, we have also added a new CocoaObject class to make it easier to use Cocoa APIs.

So progress continues. We know how important Cocoa support is for you and want it to be in great shape before we ship it. As always, if you want to follow our progress more closely and check your projects, please join the
beta program.

Your patience is greatly appreciated,

Geoff Perlman
Founder and CEO
REAL Software, Inc.

Tuesday, May 4, 2010

REAL Studio 2010r2 Now Shipping!

REAL Studio 2010 Release 2 introduces 17 new features and 68 improvements. Improved database connectivity, reporting, ActiveX and IDE printing can be found in this release. Also flickering in Windows applications that occurred when several different types of controls were moved or resized, has been greatly reduced. Finally, this release adds more DLL placement options and a new TextEncoding feature that determines if a string is correctly encoded or not.

The complete list of improvements and new features in REAL Studio 2010 Release 2 can be found in the release notes in the product download section,

Wednesday, April 21, 2010

Moving up through the ranks

As I hope you all know, you can rank your cases in our Feedback system. You can tell us your top 5 most important cases and that affects the ranking the case has. We use this rank to help us determine what we should be working on.

Today I came across a bug that had been reported six separate times. The rankings of the cases varied from in the hundreds to the thousands. Needless to say, not a case that was likely to get any attention anytime soon. I went ahead and merged the six cases. Now the merged case has a ranking in the top 20.

This is an important reminder to make sure you search for cases before entering a new one because as the saying goes, "United we stand, divided we fall."

Thursday, April 15, 2010

REAL Studio Discounts for 1-Day Sale Tomorrow!

Need some relief after Tax Day? We've got you covered with a special 1-day sale, tomorrow only (12AM - 11:59 PM CDT)! All new REAL Studio and REAL Server licenses will be 30% off! Are you, or possibly a friend or colleague, interested in checking out REAL Studio? Buy tomorrow at the discounted price and you have 90-days to return it if you are not fully satisfied. A new REAL Studio license is a great way to enjoy your tax refund!

New licenses. 30% off. Tomorrow. Be there!

Friday, April 9, 2010

The new iPhone 4.0 SDK Developer License agreement

Many of you have heard by now that Apple has changed their license agreement for the iPhone 4.0 SDK. The change would appear to prohibit creating native iPhone applications with anything except Objective-C, C or C++. What Apple did NOT say is why they are making this change. There has been a lot of speculation but what we need is to know Apple's true motivation.

We at REAL Software remain interested in possibly supporting iPhone. I say "possibly" because we have never officially announced support for iPhone and I don't want this to be misconstrued as an announcement. We are contacting Apple to find out what the story is. Once we know that, we will let you know if our plans have changed.

Wednesday, April 7, 2010

The wonderful world of credit card processing

Every year, more and more credit card purchases are done online. In an effort to make transactions more secure, credit card companies are requiring higher levels of security for web servers that process credit card payments. PCI (Payment Card Industry) compliance requires that a server processing credit card payments use SSLv3. If you are not in compliance, your merchant bank may fine you and/or shut off your merchant account as one of our customers recently found out.

This may all be very interesting (or not so interesting) and you're probably wondering what this has to do with you. If you are writing applications that talk to servers via SSL, you might find those applications suddenly failing on you when the servers are upgraded to SSLv3. The default value of REAL Studio's SSLSocket.ConnectType property is documented as being 1, which would be SSLv2 or SSLv3. However, as it turns out, the actual default value is 0 which is for SSLv2 only. If you are using the SSLSocket, you should explicitly set the ConnectionType to 2 (which is for SSLv3 only). Better yet, use the built-in constant, "SSLSocket.SSLv3" to make your code more clear. We will be changing the default value to 2 for REAL Studio 2010 r2 but you should make sure your code is explicit so you don't have to worry about this.

If you are in charge of your web server and you process credit card charges with it, you should investigate PCI compliance before your credit card merchant company turns off your account at an inconvenient moment. You can check your web server for PCI compliance using this web site:

Wednesday, March 17, 2010

Improving Press Releases

A lot of press releases cross my inbox. Some good. Some bad. Some with major errors, some with improper formatting, even some with no mention of the company of origin. Though writing a press release may not seem important to you, or something that you should spend a lot of time on, it's a very effective way to announce what's going on with your company and products.

Based upon what I've seen recently, I've put together a list of how to improve your press releases.

1. Avoid jargon. If you are talking about something really technical it might make sense to explain it because not everyone will know what you are talking about. This is especially important for the members of the press since they might not be well versed in your product.

2. Use full and complete sentences.

3. Don't use abbreviations (i.e. RB or RS instead of REAL Studio). Some people might not be familiar with the abbreviation, so better play it safe and use the full word.

4. Make sure that somewhere in your press release you explain why the reader should care. In other words, what is the significance of your announcement. For example, if you are talking about a new feature don't just list it - elaborate.

5. Don't ask a question and then answer it in the same paragraph or start a sentence with "and." This is a place for more formal writing.

6. Make sure the date on your press release is correct. I've seen some recently that have the wrong year. You want your readers to know your press release is current.

7. Avoid puns and double meanings.

8. Stick to the facts. This is not the time to try to make a joke or tell a personal story.

9. Always remember to have someone proofread your press release. Sometimes you are too close to the draft to catch errors, so it's always best to have someone review it once just for good measure.

10. Avoid using the passive voice, use active voice. For example, don't say "An email was sent by me." Say "I sent an email."

One final recommendation is to not be shy about soliciting reviews. Reach out to bloggers and various media publications, give them free copies of your application and encourage them to write a review. Make sure to add them and anyone you want to write about you to your announcements list so they receive your press release.

If you have any questions about press releases feel free to ask. If you want to have your press release posted to the Announcements section of the REAL Software Forum, send it to me at

Sunday, March 14, 2010

Supporting multiple cores

With today's multi-core CPU's it seems that an application made with REAL Studio running on a single core is somewhat restricting. If you have a lot of data to process, large images to manipulate or other things that could happen in the background, it would seem that with a multi-core machine you could do this faster "if only REAL would make threads preemptive". We get a lot of requests for preemptive threads so that people can take advantage of multiple cores. In fact, this request is number 4 on the Top 20 list in our Feedback system.

It's been suggested that this should be "easy" to do. Just make threads preemptive (so that they will then run on any available core) and voila! Unfortunately, it's not that simple. Let's look at why the current threads are not preemptive. It's hard for you, the developer, to work with preemptive threads. Some languages, like Java, have language features built in to them to try and help make this less work, but it is still hard to get right and very hard to debug when you don't. Much of the framework would need updating to be thread safe and your application's user interface is not thread safe on any platform because the operating systems themselves don't have thread-safe user interface code. If you access something from a pre-emptive thread and that something is not thread-safe, there's a very good chance your application is going to crash. We have had to go to a lot of extra work just to make the threads you have today work without causing problems.

The REALbasic language already has functions like mutex and semaphores that help you make a multi-threaded program. But you have to protect every place you might set a value that could be shared by many threads. This would mean protecting any globals and pretty much anything that is not local to the method or the thread being executed. That's very different than what you have to do today and a lot more work. It's just not "simple" or "easy to use" the way most of REAL Studio is designed to be.

The end goal is to use all cores and thereby make your software more responsive, faster, or able to handle more data, do more things all at the same time. There's been a way to do this for as long as REAL Studio has supported building console applications. The design is to create a main application (GUI or not) and use other helper applications to run separate tasks. The main application and the helpers can communicate in any one of several ways: IPCSockets, TCPSockets, UDPSockets, XML, files, or just about any other way you can dream of. The upside to this way of solving the problem is you can design and implement the main application and the helpers independently and use the debugger to debug each independently. You can use any data in either program in the same way you always have. You don't have to worry about the framework being thread safe as the helper and main application run as completely separate processes with their own memory space. Most importantly, you can do this today.

In fact, some REAL Studio users are using this technique today. John Balestrieri used this technique for a large data processing application. You can read about it here:

and here:

I'm not going to say it's simple.You have to think about what portion of your application can be segmented out into a helper console application. You have to design the communications between the main and helper applications. You have to write, test and debug them. But you don't have to worry about variables changing mysteriously because some other thread changed the value. You don't have to use lots of mutex's or sempahores to block other threads from altering things when you least expect them. And you can use the entire framework that is available to console applications. If you need pictures and graphics that are not available in console applications, you can write faceless GUI applications. Last but not least, you can run as many instances of these helper applications as your computer (or all the computers available to you) can run.

If you think you need preemptive threads today, try the helper application approach and I think you'll be pleasantly surprised at how well it works.

Monday, March 1, 2010

The Compiler: Better, Stronger, Faster

In the 1970's there was a TV show called the Six Million Dollar Man. It was about a test pilot named Steve Austin who crashed in an experimental aircraft and lost an eye, an arm and both legs in the crash. When he wakes up in the hospital he discovers that he's become an test subject for a government experiment to replace body parts with electronic equivalents. But these replacement parts are better, stronger and faster than the biological parts they have replaced. In fact in the opening of the show, the voice-over says that they have made Steve Austin better, stronger and faster.

Like Steve's legs, the compiler is what makes your apps go. And like Steve, we are working on making the compiler better, strong and faster.

While you don't see REAL Studio's compiler or even interact with it much (except when there are errors in your code), it's at the core of REAL Studio. It's what turns your REALbasic code into code your computer can execute. The compiler has two parts: a front end and a back end. The front end parses your code and transforms it into a sort of meta assembly language. Think of this as processor-independent assembly (even though regular assembly is actually highly processor dependent). For each processor type we support there is a different back end to the compiler. The back ends take the meta assembly language from the front end and translates it to the assembly for the processor for which you are building your app. That means PowerPC or x86 today.

We are working on a big change to the back end of our compiler. We are going to be replacing it with an open-source compiler back end called LLVM. It's becoming increasingly popular. If you really want to geek-out, check out We are moving to LLVM because there is a team of people working on LLVM and by switching to it, we get the benefit of their work. For example, it supports all the processors we support or would likely want to support including the ARM processor which is used by most smartphones including the iPhone. Unlike the current REAL Studio compiler, LLVM is an optimizing compiler which means it will make code optimizations that will make your code run faster. How much faster depends on what your code is doing but we have seen speed improvements of up to 10 times faster. LLVM does something called "dead-code stripping" which means that it will strip out the portions of the REAL Studio framework that your application is not using. This will result in smaller applications that use less memory. And for those that deploy on Windows and Linux, LLVM will eventually bring about the return of the single-file executable. And of course the more improvements that are made to LLVM in the future, the more we will benefit.

Today, we are working on getting LLVM supported for RBScript. That is nearly complete. Beta testers have been testing it for several weeks now. Once done, we will then move on to supporting LLVM for the main compiler. Considering how important the compiler is to REAL Studio, you may be wondering what sort of transition will be required to move from a version of REAL Studio that uses our current compiler to a future release that uses LLVM. If you were around for the last major compiler transition, you are probably especially curious. The good news is that because we are changing the back end and not the front end, the transition should be extremely smooth. We expect the vast majority of you to recompile and only notice that yours apps are smaller and faster. There won't be anything new you need to do. That's the beauty of the compiler. It does a lot without requiring much attention.

The move to LLVM is going to be an important step forward for us. And even if you don't use RBScript, you will be able to start experimenting with it via RBScript in the coming months. Eventually, your applications will get better, stronger and faster as well as the REAL Studio IDE since it is created with itself.