Tuesday, December 20, 2011

What got you interested in programming?

When I was a kid, I would race home after school to watch M*A*S*H reruns on TV. One of my older brothers watched Star Trek reruns so I would sit through Star Trek waiting for M*A*S*H to start. It didn't take long before I became a Star Trek fan. Star Trek provided me with a view of the future. In that future all things were better. No one was poor, getting around was easy and just about any sickness seemed curable all in a 60 minute episode. Computers were an important element in Star Trek so for me, they became a way to touch the future.

I grew up near the University of California at Irvine. I would ride my bike there and hang out in the computer science lab. I bought punch cards, put them in a punch card machine and typed on them. I had no idea how to write programming code. I just mimicked what I saw others doing. I was probably 13 at the time and why no one chased me out of there still surprises me to this day.

My father spent his career as an electrical engineer mostly creating communications equipment for the military. One day he brought home a Texas Instruments portable terminal. It had no screen, just acoustic couplers that held the telephone handset for communication with the VAX mainframe at his work. A thermal printer was the only output device and of course when we would run out of the special thermal paper, that was a problem. My dad taught me to program in the original BASIC and we played the original text adventure game (called "Adventure") as well.

When the Apple II came along I wanted one but being in high school at the time, I certainly couldn't afford it. My dad was unwilling to pay extra for the Apple brand so instead purchased a Franklin ACE 1000, which was an Apple II Clone. The Franklin's motherboard failed several times, and I'll bet my dad ended up paying far more for it than he would have paid for an Apple II to begin with!  He bought me a book that taught Applesoft BASIC and 6502 assembler. One look at the pages about assembler and I knew right away that I was going to stick with BASIC.

Programming for me became a terrific outlet where I could create anything I could imagine. That's what got me interested in programming.

What got you interested in programming? Share your story.

Monday, December 12, 2011

How to create a Dylib on Mac OS X and create declares in Realbasic to use it.

This tutorial explains how to use Xcode to create a dylib, and then use Realbasic to declare into it. Dylib is short for Dynamic Library, which is a file that contains code that can be linked against at runtime. This means that it isn't built directly into your application, like a static library is, but you can still load it up and call methods in it.

This is mainly useful for C/C++ or Objective-C programmers to create a library that may do something not possible from Realbasic.

Creating the dylib

  1. Launch Xcode
    This tutorial assumes that you are using Xcode 3.1.4 from Apple.
  2. Choose "File->New Project", or type Command-Shift-N.
  3. Select BSD Dynamic Library, and click "Choose".
  4. Choose a project name. For this example, we'll call it "SampleDylib".
  5. Choose "File->New File..."
  6. Choose "C File", from within the "Mac OS" section
  7. Name the file. For this example, we'll call it "SampleDylib.c". The default settings are generally correct, but if you have multiple projects open with multiple targets, make sure the proper project and target is selected. When done, click "Finish".
  8. Open the SampleDylib.c source file.
  9. Add the code below:
    #include <string.h>
    int addFunction( int a, int b ) {
     return a + b;
    int stringLength( char *str ) {
     return strlen(str);
  10. Save the file, then click the Build button, or press Command-B.
  11. If there were build errors, ensure that the code you entered looks exactly like it does above. Once the build is successful, continue to step 12.
  12. Find where the build was saved. If the builds folder location hasn't been changed, it will be located in a "build" folder, next to your project file. It will be named libSampleDylib.dylib. (This is bceuase we've not altered the default install name in the build target.)
    Another way to locate the file is to locate the target by going to the project window, expanding libSampleDylib, then expanding Products. Select libSampleDylib.dylib, and control-click (or right-click, for those with two-button mice), and choose Reveal in Finder
    You will need to access this location later.

Creating the Realbasic project

  1. Launch Real Studio. Create a new project, and choose "Desktop"
  2. Save the project to your Documents folder (so that it is next to the dylib file). For this example, we'll name it, "Test Dylib.rb"
  3. Double click on "App" in the project window.
  4. Expand the "Events" section, and select "Open"
  5. Add the code below:
    CONST dylibLocation = "@executable_path/../Frameworks/libSampleDylib.dylib"
    Declare Function addFunction lib dylibLocation (a as integer, b as Integer) as Integer
    Declare Function stringLength lib dylibLocation (s as CString) as Integer
    msgBox "5 + 2 = " + str(AddFunction(5,2))
    msgBox "The length of ""asdf"" is " + str(stringLength("asdf"))
  6. Run your application using the "Run Paused" feature of the IDE.
  7. Copy the dylib from the Xcode build into the application bundle. You can do this by right clicking on the debug app & selecting "Show Package Contents".
    Navigate to Contents > Mac OS & copy the dynamic library created by Xcode into the Frameworks directory in the bundle. (If the edition of Real Studio you use supports this you could use a Build Automation Step to do this for you on every compile)
  8. Now launch the debug application by double clicking it in the Finder. It should then connect to the debugger in the IDE.
  9. Notice that it correctly adds, and also correctly computes the length of the string.

What is it doing?

The loader (aka Dynamic Linker) doesn't search for a dynamic library very well. It relies on either having a full path to the library, or having it relative to the executable path. Since we want the dylib to be installed in the bundle, we use "@executable_path/../Frameworks/libSampleDylib.dylib" as the path for non-debug builds. This means that when you build your application you will need to copy the SampleDylib.dylib file into your Contents/Frameworks directory next to your actual executable file.
However, since the application is regenerated every time Realbasic builds it, the same path won't work for debug builds. (Suggestions about how to deal with this are included later)

What about the native types in Realbasic?

Using Realbasic, you can do almost anything through declares. Here are a few tips on how to handle different types in Realbasic:

  • Passing a float into your dylib, or returning a float: In Realbasic, use "Single" as the data type. Singles are the exact same as a float -- a single precision floating point, to be specific.
  • Passing a double into your dylib, or returning a double: Doubles are the exact same in both languages.
  • Passing a c-string (null-terminated string) into your dylib: In Realbasic, declare the type for the parameter as CString.
  • Passing a pascal-string (one byte length specifier) into your dylib: In Realbasic declare the type for the parameter as PString.
  • Passing a void* (arbitrary data) into your dylib, or returning it: In Realbasic, declare the type for the parameter as Ptr, and pass in a MemoryBlock. Also declare the return type as Ptr, and it will automatically be converted to a MemoryBlock on return.
  • Passing a pointer to a struct into your dylib: The same as above. Set up the memoryblock to contain the different fields, and pass it in as a Ptr.
  • Limitation: It isn't currently possible to pass in a struct inline.

Known issues

  • By default all symbols (functions & subroutines in C) are exported. This is usually what you want.
    If you happen to preface one with the C keyword "static" then it won't be exported & so it will not be usable directly in Real Studio code like we've shown.
  • If you name your file with a ".cpp" extension then Xcode assumes that it is a C++ file & names will get mangled by the Xcode compiler. This means they would not be directly usable in Real Studio.
    You will need to preface them with an "extern "C"" declaration to make sure the names get exported unmangled.
Because Real Studio recompiles your application every time you run it under the debugger you can't use the same path for the dylib while debugging as you can in the final build. You can deal with this by using an absolute path to the dylib when debugging. In my case this would be:

CONST dylibLocation = "/Users/npalardy/Documents/libSampleDylib.dylib"

Another way to deal with this is to put the dylib next to the application bundle where Real Studio builds the application (right next to the project file on OS X). Then you can use a relative path like:

CONST dylibLocation = "@executable_path/../../../libSampleDylib.dylib"

And you could make the code in your Real Studio project look like:

#if debugBuild
   CONST dylibLocation = "@executable_path/../../../libSampleDylib.dylib" // next to the app bundle
   CONST dylibLocation = "@executable_path/../Frameworks/libSampleDylib.dylib" // inside the app frameworks in the bundle

Declare Function addFunction lib dylibLocation (a as integer, b as Integer) as Integer
Declare Function stringLength lib dylibLocation (s as CString) as Integer

Document Updated by:
Norman Palardy norman@realsoftware.com
Real Software, Inc.
based on a previous article by Jonathan Johnson
Real Software, Inc.

Friday, December 9, 2011

Search Engine Indexing of Web Edition Apps

We've been getting some questions about how the search engines treat Web Edition apps and what, if anything, you can do about it.

First of all, it's worth noting that most search engine "bots" do not support Javascript. This means that neither the Web Edition framework nor the initial WebPage of your app will ever be delivered. You can't even use a Javascript command to redirect to another page.

In fact, there are some good arguments for why you wouldn't want a search engine to index your application content. Think of a membership list, or a company calendar or an email client. Having that content indexed by a search engine could be catastrophic, and probably part of the reason that most search engines don't index dynamic content like that, unless specifically told to do so.

We're investigating ways to make this a little easier to do, but there is something you can do about this now... META Tags. There are two HTML header tags that you can add that help a search engine to figure out what your site/app is all about. They are:
  • Description: A brief description of that your page or product is about. It is not uncommon for search engines to display this text as is when showing a listing for your page.
  • Keywords: A list of key words and phrases under which a search engine should index your page.
To use these tags, add code that looks like this to the app.HTMLHeader property in the IDE:

<meta name="description" content="My software is the greatest piece of software ever made" />

<meta name="keywords" content="best software, greatest software, awesome software, most-likeable software" />

Wednesday, December 7, 2011

How much is too much?

This week, Microsoft provided more information about the app marketplace being built into Windows 8. They are doing some things differently than Apple which is a good because healthy competition is always a good thing for consumers.

In one of the videos, Microsoft Web Services VP Antoine Leblond says that prices for apps can be between $1.49 and $999.99. He went on to say that "a thousand bucks is too much for an app." Who exactly is he to say how much is too much for an app? Microsoft's store currently sells two editions of Visual Studio for over $1000 each. Will these not be offered in the app marketplace? 

The price a developer charges for their product should not be dictated by any online store. That's a decision the developer should make.

Static Variables in Web Edition

Static variables can be a valuable thing, but there is a downside that you should be aware of when using them in Web Edition.

The Real Studio documentation for Static says:

"A variable declared with the Static statement and assigned a value retains its value from one invocation of the method to the next." (Click Here)

Static variables persist across subclasses as well, so if you have a method in a class that uses a Static variable, all of the subclasses will share that variable's value.

So what's so special about Real Studio Web Edition? Well, each end-user session is technically a subclass of the individual Webpages and other items you created in the IDE. Using Static variables may have unintended results.

For example: If you use a variable as Static in the WebPage1.Resized() event like this:

Event Resized()
  //Initialize the Static Variables
  Static LastWidth as Integer = Self.Width
  Static LastHeight as Integer = Self.Height
  //Show a message if the window got smaller
  If Self.Width < LastWidth and Self.Height < LastHeight then
    MsgBox "The browser window just got smaller!"
  End If
  //Update the Static Variables
  LastWidth = Self.Width
  LastHeight = Self.Height
End Event

This will work fine as long as there's only one Session (like if you're testing in debug mode). Once there's more than one, they will all share the LastWidth and LastHeight properties and every time a one user's browser window is resized, LastWidth and LastHeight will be updated for all connected users.

Here's what happens: If User1 makes their browser smaller and gets the MsgBox and then User2 makes their browser window smaller they will only get the MsgBox if the window is smaller than that of User1. Whichever user resized last, the dimensions of their browser is what is left in LastWidth and LastHeight.

While this could lead to a hard to track down bug, imagine what would happen if you used a Static variable for a Password!

To avoid this problem, you should use properties of the class you are using (in this case WebPage1.LastWidth) or as a property of the Session itself.

When writing code for Web Edition, always remember that all of the Sessions are technically running the same exact program. Properties on Modules and the App class, Shared Class Properties and Static Variables will all be available to all Sessions.

Tuesday, December 6, 2011

Linux & Cairo

In Real Studio 2011 Release 4 we upgraded our Graphics drawing on Linux to use Cairo instead of the antiquated GDK drawing system. For those unfamiliar with Linux, Cairo is akin to GDI+ on Windows, or CoreGraphics on OS X.

The main benefits to switching to Cairo include: smoother drawing because of anti-aliasing, translucency support and hardware accelerated drawing. See figure below for a comparison of Cairo drawing (top) and GDK drawing (bottom)

Another important reason for switching to Cairo is because 2011 Release 4 introduces alpha channel support for Pictures. This would have been excruciatingly painful to do in GDK (and GDI on Windows for that matter), so the upgrade to Cairo was a necessity.

An additional gain from this upgrade is improved printing support on Linux. Although we resolved the issue with only being able to print at 72 DPI in a previous release, the fact that we created an offscreen picture and scaled the text was a show stopper for many. Now that our printing API uses Cairo and our Graphics drawing is also using Cairo, this transitory picture we had to keep around before is essentially out of the picture now, pardon the pun.

Friday, December 2, 2011

The demise of HyperCard

John Gruber, the blogger behind Daring Fireball, has a podcast called The Talk Show. Right at the end of this week's episode, he and his co-host Dan Benjamin discussed the demise of HyperCard.

If you're not a Mac user or are too young to remember it, let me give you a little background. HyperCard was a simple development tool provided with the Mac prior to Mac OS X. It had a drag and drop interface builder and a simple programming language similar to AppleScript. I saw the appeal of an English-like programming language but also quickly discovered the concept's Achilles' heal. In English, you can say the same thing many different ways. In HyperTalk (the programming language of HyperCard) there was usually just one way to write the code for a particular function. AppleScript suffers from this same problem which can make it quite frustrating at times. One of our engineers once called AppleScript "a read-only language" which is a great description. It's easy to read AppleScript code, but very frustrating to write. HyperCard also suffered in that it did not support color and could not be used to build standalone applications. If you sent a HyperCard file (called a "stack") to another person, they needed to have HyperCard installed to run it.

Despite these limitations, there was an attractive simplicity to HyperCard.

So, despite its simplicity and popularity why did HyperCard die? On the show, the hosts suggested that Steve Jobs killed it. One of the things that Jobs did when he returned to Apple was simplify. He very correctly and intuitively understood that Apple needed to focus on a smaller number of projects if they were going to produce great stuff. Also, one of the features of NeXT that Jobs was most proud of was its advanced (at the time) visual development tools and object-oriented language. He believed (correctly as it turned out) that object-oriented programming was the future. So if you consider how important Jobs felt it was to focus and how he felt about the development tools brought to Apple with the acquisition of NeXT, it's easy to see how Jobs would feel that two development tools was one too many.

But I think the real reason is far simpler. Bill Atkinson was the main developer behind HyperCard. He left Apple in 1990. Without Atkinson pushing HyperCard, it was quickly abandoned inside of Apple. There were probably few who knew the code or who had anything like the passion that Atkinson had for it. As a result, updates were released with decreasing frequency and in 2004 Apple finally killed it.

In their podcast, John Gruber and Dan Benjamin discussed what development tools exist today that fill HyperCard's void. I was quite happy to hear John mention Realbasic. It won't shock you to hear that I think Realbasic/Real Studio fills this gap nicely. One of the big problems John felt HyperCard had was that it couldn't build stand alone apps. Even if it could, Hypercard didn't use native controls so the apps would not have felt like true, native applications. Real Studio of course builds native apps and uses over 40 native interface controls.

It has always been my vision for Real Studio to be an easy-to-learn and easy-to-use development tool that is powerful enough to build almost any kind of app while supporting all the important platforms. The only platform Real Studio is missing at this point is mobile and that's something we are working towards. It's just never made sense to me that a developer should have to learn lots of different languages and development tools to build different types of applications. 

HyperCard was one of the first visual, integrated development tools. That was a significant innovation. While HyperCard and Real Studio are very different in many ways, they have the same goal: to make programming accessible. I think that Real Studio has done a good job of taking over where HyperCard left off.