Longtime Mac developers who've opted to come out with Windows versions of their products can usually count on howls of protest from users who accuse the company of abandoning the Mac platform. That hasn't happened to Real Software after its October announcement that the next version of its RealBasic development software, due out in early 2003, would run on both Mac and Windows platforms. The lack of outcry doesn't surprise Lorin Rivers, Real Software's vice president of marketing, who believes that a Windows version of RealBasic will make the Mac edition even stronger. Rivers gave a sneak preview of what to expect in RealBasic 5 when it makes its debut early next year.
Q: Why are you adding Windows compatibility in the next version of RealBasic?
The primary reason is because our customers asked us to do so, and they've been asking us to do that since we first released a version of RealBasic that compiled for Windows.
Q: That was in 1999?
That's right, version 2. One of the challenges of doing cross-platform development is the debugging stage. Not having the debugger on the other platform, which would require that the whole [development environment] be over there, made it quite a bit more difficult to debug Windows apps. So that's a big motivation right there--we want to make the quality of Windows apps better, and we want to make it easier to do them well. Another reason our customers want RealBasic on Windows is because a lot of people use a Mac at home and they use a PC at work. It makes it a lot easier for them to use RealBasic in their jobs [if they] have a Windows version. We've been having a lot of success with a curriculum that we had developed, a computer-science curriculum for older elementary kids up through high school... I get e-mail from kids from time to time saying, "I really like RealBasic, I really like using it at school. I just can't do my homework." Because they use a Mac at school, and at home, they have a PC.
We also hear from people who buy the $1,000 version of RealBasic that comes with a free iMac--they buy an iMac to get RealBasic, essentially, because they want to port something over from Windows to the Mac. That's actually been a really successful story for us, because one of the things that happens is people discover that they love the Mac. A lot of people who all they've ever done is hear about [the Mac], they don't know how much better Macs really are, until they've been exposed to them. One of our customers has been developing [VisualBasic] forever, and VB guys tend to be the ones who are most dismissive of the Mac, in my experience. And this guy, he had customers asking him to port this 3270 software that he'd written in VB over to Mac, and he just became a Mac fanatic in about two weeks. First, it was, "Oh well, I had to buy an iMac to test this," and then [he] switched, which is, of course, the kind of story Apple likes to hear.
What it all boils down to is, it's very hard for us to be the premiere cross-platform development tool if we're only really on one platform. That's where we see ourselves--as the best tool for developing software that runs on multiple platforms. Of course, you can say, "There's Java." And Java is great, but I think you'll find, for the most part, Java apps tend to be server apps. There's a number of cross-platform Java apps, but the fact is, except for on Mac OS X, they tend to be very much least-common-denominator-type applications. It's sort of a Windowsy, not very Mac-like user experience, as a general rule. We think that RealBasic is the way to go, but we're biased.
Q: You mentioned better-quality Windows apps developed through RealBasic. Could the same be said on the Mac side? Will this move result in better Mac apps?
I really think it will, because the Mac is so forgiving. Things that are technically incorrect, the Mac will just kind of deal with those and keep on going, even if it's technically a bug or bad code or what have you. Windows, on the other hand, tends to be much less forgiving. As we're going along, doing the development in parallel, the alphas are coming out within minutes of each other on Windows and on Mac. And the work that we're doing on the Windows [development environment] is making the Mac [version] better because we're having to fix things we didn't even know were broken. They were fine on the Mac but not fine on Windows.
Q: Obviously RealBasic is a major tool for programming and software development. What about the individual users who use RealBasic to whip something up on their own? How are they going to be impacted?
If they don't fall into one of the categories where, say, they have a Mac at home and a PC at work, there's no impact, essentially.
Q: What else can we expect in RealBasic 5?
I think RealBasic 5 is going to be really fantastic. We have an open alpha in beta, and anyone who wants to can download the current version of RealBasic. For the first time, we're requiring people to be customers already to download these early alphas because... we're implementing a new compiler in RealBasic 5. Typically, our alphas and betas are fantastic in terms of quality. Sometimes if you get access to an early release of something, it can be pretty wobbly. I beta test other software... and sometimes it's like launch, click, crash. With Real Software, that's been absolutely not the case. Well, with the new compiler and the Windows [development environment], there is some [instability]. We try to come out with a new alpha every couple of weeks. [RealBasic] 4.5 shipped in July. It didn't take us that long to get the [version 5] alphas up and running. We spend a lot of the in-between time planning and doing research. We try to do the most dramatic stuff as early as possible. It's hard to turn a battleship, and so the earlier you can get the move going on something big, the better. You don't want to make huge changes at the end.
Q: And this is available, as you said, to registered users only.
Yeah. If you're a current customer of RealBasic 4.5, there's a special page on our Web site that allows you to request a [version] 5-alpha serial number, as well as a Windows one. And we'll work with people who are strictly evaluating, especially from the Windows side. Soon, I think, it'll be in a state where we're more comfortable with people who aren't really familiar with RealBasic already to start messing around with it.
Sometimes the changes that need to be made are a huge amount of work with no obvious benefit to customers. Sometimes these things take a really long time for the payoff to occur. With the new compiler, the payoff is coming in the form of a Windows IDE, which a new compiler was essentially a requirement for us doing that. The old compiler for Windows wasn't designed for debugging, so this new compiler is going to get us new features in the language. That's a little bit esoteric, but there's definitely people who appreciate... the sort of disparaging term for it is a syntactic sugar. In old school Basic, you could do a one-line If statement. If "i" is greater than 3, then beep--all in one line. You could never do that in RealBasic before. You can do it in VB as well. One of the things that the new compiler gives you is one-line If statements. Is that going to make someone's day? No, but over time those things add up.
The guy who is writing the compiler has been working on it for us for a really long time. If you haven't followed the RealBasic feature progression over the last 18 months or so, first we introduced this technology called RB Script, which was essentially RealBasic inside of RealBasic. RealBasic's [a development environment] and a language. So when you're typing code in RealBasic, you're typing RealBasic code. It's not Basic, it's not C, it's not Java. It's got aspects of all those things. Say that you wanted to do a spreadsheet like Excel, you could do that in RealBasic before RB Script came around. But once RB Script was there, having the person who's using the compiled result in the RealBasic application that you create from your project, having them being able to write formulas is much, much easier using RB Script because it's dynamic. If they start throwing in a bunch of other mathematical symbols, it can still be evaluated without the programmer having to have thought of every possible kind of mathematical operation somebody would want to do. With RB Script, the program didn't have to do that much work to enable anything like that to occur. At first, it was interpreted. Then, it was on Windows. Then, it was compiled on Mac. Then it was compiled on Windows. And now, that technology --that RB Script technology--is what we're using for our compiler. It's called a two-pass compiler. What that means is essentially the compiler takes RealBasic code and all the other stuff and writes it out in an intermediate format, and then, the backend takes that intermediate format and compiles it to machine code for the specifics of the process. The intermediate--the byte code, if you will--is a known quantity... When we're ready to add a third platform, that process will be much easier. We had to do a bunch of work ahead of time, but going forward, new platforms and enhancements...
Q: Say, Linux or...?
Linux or Palm or something like that. We're as open as we can be. Our customers are so passionate. They're like Mac fanatics to the next level. They are very involved in what we're doing, and when we say, "Gosh, it would be swell if... we could do that at some point"--whatever that might be--they hear that as a promise, and they get all excited and they want us to do that. So we just don't disclose that stuff until it appears. Now that said, we do try to give people some broad direction about where we're headed with this stuff.
Q: What other additions are coming to RealBasic?
Already RealBasic 5 creates much smaller Carbon apps than 4.5 does, like 700K smaller than 4.5 does. Basically, RealBasic compiles an app around 2MBs in Carbon on 4.5, and it's pretty hard to get it much bigger than that. It's also not possible to get it smaller than that. There's a lot of overhead. One thing that people do when they first get RealBasic is they create an empty window and they compile it and they say, "Geez, this thing's already 2MBs." But the fact is, that empty window supports everything the Mac supports--drag and drop and all that other stuff--even if there's nothing exposed that you can see. Now if you put an edit field and a push-button then you've got drag-and-drop text, you've got copy and paste. All that stuff is just handled for you automatically. That has to go somewhere. But going forward, our app sizes are going to be getting smaller, and we'll be able to do more optimizations for performance or what have you. So it's something we absolutely had to do, but it's not the kind of thing you go, "Oh, I'm going to upgrade because you've got a new compiler." It's like cars have wheels, and they always have wheels, and it's not going to get anyone excited that "Hey look, now with wheels!"
Q: Anything else in version 5 you can tell us about?
We're going to be adding as much of the new [interface] stuff that's in Jaguar as we possibly can. Apple has been doing a pretty good job of living up to the promises they've been making about the parity between Carbon and Cocoa. At first you could only get drawers and sheets and services and all that stuff in Cocoa apps. Well with each release of the OS, they make more and more of that stuff available to Carbon apps. We're going to be adding as much of that Jaguar stuff as we possibly can fit in the schedule. I talked earlier about the least-common denominator. One of the things we are very strongly opposed to, something we are not going to make the mistake of doing is making RealBasic the least-common denominator. For example, we've had Windows compiling since version 2. We didn't say, "Well, we had AppleScript in RealBasic before we had Windows compiling, but since Windows can't support it, we're going to have to take that out." That would be crazy. AppleScript will never be implemented on Windows, and there's nothing we can do about that, but we're not going to take AppleScript away from our Mac customers because it's not supported on Windows. By the same token, ActiveX kind of exists on the Mac, but it's only really used by Microsoft and less and less so, from what I understand. I don't think that ActiveX is really supported in Mac OS X. I think, in Mac OS 9, older versions of Internet Explorer would install some ActiveX stuff, but it never really went anywhere on the Mac. Well, we're going to support ActiveX on Windows, because it's a really important technology on Windows, but it doesn't exist on the Mac. We're not going to say, "Since it doesn't exist on the Mac, we're not going to support in on Windows." At the same time, that does not imply the two products are going to start diverging dramatically because the fact is, most of the technologies that exist either exist in a totally parallel form or... we make it transparently the same. For example, the way you do TCP/IP connection stuff on the Mac, Mac OS X, and on Windows are completely different. Yeah, there's an IP address, there's a packet, but as far as how that is expressed at the system level, there's no overlap. You drop a socket into your window, and you tell it, "I want you to connect to this IP address on this port and start sucking data," we don't make our RealBasic customers learn all the differences between how sockets work on Mac OS X, on Mac OS 9, and on Windows. We remove the unnecessary complication, in our mind--there's no need to differentiate that. You want a socket? We're going to handle all the rest of it for you. We're going to focus our energy on solving those kinds of problems because that's the part, when people think programming's hard, that's what they're thinking about. It's like, "I tried to learn programming way back when and there were all these toolbox calls or Win32 declares" or whatever it was that's just a barrier to them being creative and creating their own software. That's what kept me from ever learning how to program.
We haven't really talked a lot about what else we're planning on doing. Some stuff that's appeared already--again, this is Mac OS X 10.2 that's appearing in RealBasic 5, but we've added the Quartz anti-aliasing to a bunch of stuff that didn't have it before. We introduced in 4.5 a new vector-based drawing capability in RealBasic, and in 5, that stuff on Mac OS X is rendered using Quartz. Your vector lines will be anti-aliased, and all the stuff you create there will be anti-aliased and look gorgeous. That's already starting to trickle in. We've got a lot more stuff on our plate that we're going to be implementing, and I think it's going to be the best release ever.
Q: Are we talking a separate CD for either platform, or is it a single product?
It looks like we're going to be able to do a hybrid CD. We knew we were going to be doing this a long time ago. We didn't talk about it because why talk about it until you've got something to show? But we designed the file format in RealBasic 3 to be a flat, binary-compatible file format. We're probably going to have a slightly different box because we're in retail now. We're in the Apple Store and we're on Amazon and shortly, we'll be appearing at a major retailer near you, which is really exciting. We've always relied on word-of-mouth. We advertise, but it's the kind of thing where we really believe almost anyone can use RealBasic, and there's a lot of people who would like to write their own software. We have not disclosed pricing, but if you look at other tools that are more or less cross-platform, they tend to not really discount the cross-platform capability.
Q: You typically release updates at Macworld Expo. Is that the plan for RealBasic 5?
We're saying first quarter of 2003. It may not actually ship at Macworld [Expo San Francisco]. Some things depend on other things. No matter how many programmers you have, if an eight-week task has to be completed before the next eight-week task can begin, you've got 16 weeks. Some of this stuff is just huge architecturally. I'm very disappointed we can't [ship at Expo], but there's just time compression.
Q: But you'll be demoing at the show?
Oh absolutely. We'll be in beta. The nice thing having about an Internet focused company, which we absolutely are--we have a retail strategy, we've got a box, but really most of our sales are download sales. But we like to have everything ready to go when we announce we're now available. We like to have the CDs available. In theory, we could probably be doing download only sales two weeks ahead of time, but we don't really like to do that.