Porting VB Applications to Linux and Mac OS X

A how-to guide for Visual Basic developers by Hank Marquis

Hank Marquis has been using Visual Basic since version 1.0. He is author of A Visual Basic Programmer's Toolkit (APress), The Visual Basic 6.0 Bible (IDG) and over 35 articles published in CTO/BackOffice, Visual Basic Programmer's Journal (VBPJ), Visual Studio Magazine (VSM) and Microsoft MSDN. He is currently CTO of SlayFire Software Co., creating optimization and performance tools for REALbasic. Reach him at [email protected] or www.slayfiresoftware.com.

Table of Contents Porting Options Beginning Assumptions Porting Considerations Language Keywords Code Syntax Data Types Language Structure User Interface Project Structure Platform APIs Other Considerations Visual Basic Project Converter Additional Resources

Table 1. Porting Considerations Table 2. Visual Basic and REALbasic Datatypes Table 3. Getting Ready: The Step by Step Process Preparing Your Code to Use VB Project Converter

A how-to guide for Visual Basic developers

In this white paper, I'll show how you can preserve your investment in Visual Basic by porting your code to Linux and/or Macintosh using REAL Software's REALbasic. I'll provide some examples, share some experience and give you a roadmap for how to port—and how not to port—your Visual Basic apps cross- platform. My intent is to save you some time and pain.

For porting our VB projects, we will use REALbasic 5.5.3 for Windows, a modern software development environment that is quite similar to Microsoft Visual Basic® in terms of the GUI and syntax. I also don't intend to provide a full comparison of Visual Basic and REALbasic but rather to show you where they are different in ways that will impact porting your project.

Porting Options

With the release of Visual Basic.Net, many Visual Basic developers felt abandoned. For the first time, a Visual Basic implementation could not open and run a previous version's source code.

Visual Basic.Net requires Visual Basic developers to modify their code because .Net cannot run Visual Basic code. So, like it or not, if you are a Visual Basic developer who wants to take your Visual Basic code forward into new projects, you will be porting.

Porting means learning and using new keywords, and keywords that don't work the same way they used to; in general, it's a fair amount of work. So, when I was faced with this dilemma, I asked myself what benefit I would get from porting to .Net. After learning a new language (.Net), significantly changing my source code, and struggling to create programs with a massive "framework" underneath them, I would have a program that ran under Windows. I then started to look into alternatives. If I had to go through the process of learning a new language and IDE, what else could I get?

I then found REAL Software and REALbasic. REALbasic 5.5.3 for Windows is a modern, fully object-oriented software development environment (IDE), quite similar to Visual Basic. It could use much of my Visual Basic code unchanged, and it could read most of my Visual Basic forms.

I could port my Visual Basic code to REALbasic, and at the end, my application would work under Windows—just like .Net. More importantly however, my ported application would also run under all 32-bit Windows (98/NT/ME/2000/XP) without the .Net framework; Linux (any Intel-based Linux running GTK2.0+ like

© 2004 REAL Software, Inc. and Hank Marquis. All rights reserved. Page 2 of 17 SuSE or RedHat) and Mac (Mac OS X and Mac Classic). As an added benefit, there are no runtimes or "frameworks" required for an REALbasic application. In addition, my ported application would include the native interface widgets required to look great. In Windows XP for example, I was surprised that my REALbasic app takes on XP themes automatically!

To demonstrate this, see following screenshots of applications compiled with REALbasic:

Windows XP, Linux and Mac OS X Screenshots

The decision was actually an easy one, as I had to port either way, either to .Net or REALbasic. At the end of the port I would have either a Windows app with huge runtime requirements, or an app that ran under Windows, Linux and Mac. The choice was clear. If I had to learn a new language and port, then I wanted a much bigger bang for the buck than was available with .Net.

Beginning Assumptions

I'll start with a few assumptions to make sure we're talking from the same frame of reference. I assume you want to move applications from Visual Basic to REALbasic for the reasons I gave above, that you want to create cross-platform applications from your Visual Basic projects, and that you are using Visual Basic 5 or Visual Basic 6 and REALbasic 5.5. I also assume you know something about Visual Basic and/or REALbasic.

Porting Considerations

To begin, the topics listed in Table 1 need to be taken into consideration as you think about porting your application. I will take these important considerations one by one. Remember, before you port to REALbasic, you should consider the work and re-work that might be required. After all, Linux and Mac operating systems are very different from Windows, and, just like .Net, not all your code or controls will port. Unlike .Net, at the end of your journey with REALbasic you will have a supported, truly cross-platform application! Let's go!

© 2004 REAL Software, Inc. and Hank Marquis. All rights reserved. Page 3 of 17 Table 1. Porting Considerations Language Keywords Code Syntax Data Types Language Structure User Interface Project Structure Platform APIs Other considerations

Language Keywords

You will be pleasantly surprised by how many REALbasic and Visual Basic keywords work identically, including

Left, Right, Asc, Str to name just a few. Almost all of your Visual Basic knowledge translates directly into REALbasic. Of course, there are some keywords that do not work the same. For example, in REALbasic, Mid cannot assign a string as the Mid statement in Visual Basic does:

Mid(x,2,1) = "!" 'fails in REALbasic 'but is OK in Visual Basic

Mid is a function (returns a substring) and a statement (modifies a string) in Visual Basic, but not in REALbasic. In REALBasic, Mid operates only as the function, so you need a replacement statement for Mid in REALbasic. [Note: REALbasic provides a module with such replacements.] Luckily, in REALbasic, unlike Visual Basic, you can have methods and functions with the same names, which makes sense since they are not equivalent in functionality. For example:

Sub Mid(ByRef As String, StartPos As Integer, StopPos As Integer Assigns SubString As string) Text = left(text,StartPos-1) + SubString + Right(text,StopPos+1) End Sub creates a "replacement" for Mid, giving REALbasic a Mid statement in addition to the existing Mid function. Once written, you can then use Mid just like you do in Visual Basic. It's easy.

Visual Basic makes it easy to write sloppy code, as we all know. Dynamic variable declarations, variants, Goto's, all add flexibility, but, if not used with care, can result in ugly and hard-to-maintain code. REALbasic is object-oriented, and is therefore stricter. For example, in REALbasic, you cannot use a variable without an explicit Dim.

© 2004 REAL Software, Inc. and Hank Marquis. All rights reserved. Page 4 of 17 Visual Basic, on the other hand, allows explicit/dynamic variable creation and type casting with explicit variable casts such as $, %, #, @ etc., while REALbasic does not, as shown below:

Left$ 'not portable Left 'portable

So, before you port to REALbasic, one of the most important things you can do is to clean up your Visual Basic code! Remove variable casts ($, #, %, etc.) from your code. Use Option Explicit to help locate all un-declared dynamic variables in use, and declare them.

As with any language, reserved keywords may conflict. REALbasic has a built-in String class, and the name String is reserved in REALbasic, making the Visual Basic String keyword incompatible. In this case, you'll need to change your Visual Basic code after opening it in REALbasic. Then, you'll need to write a replacement function for String, then find and replace all Visual Basic String keywords with the replacement.

REALbasic and Visual Basic each have some unique keywords as well. For example, Visual Basic has Space and Int. While REALbasic does not have these, they are easily created in REALbasic, like this:

Function Int (Value As Integer) As Integer Return Value \ 1 End Function

On the other hand, REALbasic has Min, Max & CountFields; where Visual Basic does not. REALbasic and Visual Basic also have different keywords for the same function. For example, REALbasic has UpperCase, while Visual Basic has Ucase. These work the same way, they just have different names. It is easy to write a wrapper around the REALbasic implementation so you don't have to change your code. However, performance will be faster if you replace Ucase (or Lcase) with UpperCase and LowerCase.

As you can see, similar keywords means stepping through a few hoops for experienced Visual Basic developers. To make it even easier, be sure to spend time with the REALbasic user guide and language reference beforehand. Another tip is to play with REALbasic to get the feel for it.

In summary, to port your keywords like Mid that work differently, you will need to create replacement functions. For missing keywords, like Space or Int, you will need to create them in REALbasic. For incompatible keywords like String, you'll need a substitution. Carefully read the REALbasic manual to make sure the keywords you use work the same in REALbasic as they do in Visual Basic.

In comparing REALbasic and Visual Basic syntax, the use of keywords is sometimes different. For example, the following is fine in both Visual Basic and REALbasic:

Dim X, Y As String

But because of the Visual Basic Def XXX statement (which does not exist in REALbasic), the above declaration X might not be a string! In REALbasic, this syntax would declare both X and Y as Strings. This is yet another benefit of REALbasic vs. Visual Basic: REALbasic makes it easier to understand and maintain code. If you clean up your Visual Basic code before you begin importing into REALbasic, these problems simply won't occur.

However, there are some interesting language changes that do require you to re-work your Visual Basic code a bit. For example, For works differently in REALbasic. The following Visual Basic code imports and runs, it just does not actually modify j!

For I = 10 To 1 Step -1 J = j + I Next

Instead, in REALbasic, use DownTo for negative For...Next loops

For i = 10 DownTo 1 j = j + I Next

Knowing about these requirements in advance makes porting much faster. Simply find all the Visual Basic For statements with a negative Step (e.g., For I = n to 1 step - 1) and change them after you import into REALbasic.

Visual Basic has some mixed metaphors that have always been quirky for Visual Basic developers. One example is handling logical operations. While both Visual Basic and REALbasic offer logical operands (Or, And, Not) that may be used as follows,

If A or B and Not C Then Beep

Visual Basic allows logical operands (Or, And, Xor, Not) to be used as statements as well. For example, in Visual Basic you can use:

A = 2 Or B If A Or B Then A = A And B

© 2004 REAL Software, Inc. and Hank Marquis. All rights reserved. Page 6 of 17 One note: In REALbasic the last two lines will work just fine, assuming that A and B are both Booleans. What isn't allowed in REALbasic is treating integers as Booleans.

This is not logical, and often confuses new Visual Basic developers. In addition, it is often very difficult to perform bit-wise manipulations in Visual Basic without significant contortions of And, and Or.

REALbasic, the other hand, provides complete logic support and full bit-wise logical operations using the intrinsic BitWise Class. This is another benefit of porting to REALbasic. For example: i = BitWise.bitAnd(A, B) i = BitWise.bitOr(A, B) i = BitWise.bitXor(A, B) i = BitWise.bitOnesCompliment(A, B) i = BitWise.ShiftLeft(A, B) i = BitWise.ShiftRight(A, B)

In summary, code syntax differences between REALbasic and Visual Basic do not impose too great of a burden. My recommendation is to remove all Visual Basic DefXXX statements and use explicit variable and function naming everywhere, before you start to port. Remove Visual Basic type casts, and cast each variable explicitly using Dim. Remove $, %, #, @ etc. from all declarations, variables, functions and constants. Check for and identify conditional loops. You will be able to repair these AFTER the port to REALbasic.

Data Types

Visual Basic programs run under Windows, period. REALbasic programs run under Linux, Mac AND Windows. It might not be obvious here, but these operating systems do not all use the same computing hardware. That is, these are not all Intel CPU based machines! As you might expect, REALbasic has a much richer set of data types than Visual Basic, since REALbasic applications run across many platforms. As such, there are compatible, incompatible and unique data types between Visual Basic and REALbasic, with REALbasic offering a much wider array of data types.

There is also a difference between how data is related into structures between the two languages. They both offer modules, Windows (Visual Basic Forms) and classes. One difference is in creating data structures. Visual Basic has User Defined Types, while REALbasic provides the MemoryBlock. Also, the REALbasic MemoryBlock has much wider data type support, including shorts, pointers, and built-in bit manipulations. You will love these if you do any type of Windows API work in your Visual Basic applications.

© 2004 REAL Software, Inc. and Hank Marquis. All rights reserved. Page 7 of 17 To provide cross-platform support, REALbasic requires data types that Windows alone might not. For example, Visual Basic does not require Endian-awareness nor conversion of end-of-line character sequences based on operating system.

In addition, REALbasic has 2D and 3D object types (for rotated text, native 2-D and 3-D graphics support built into the language).

The following table shows a comparison of data types between Visual Basic and REALbasic.

Table 2. Visual Basic and REALbasic Datatypes

Item Visual Basic REALbasic

16-bit Integer Integer N/A (use 32-bit Integer or MemoryBlock)

32-bit Integer Long Integer

Single Single Single

Double Double Double

String String String

Currency Currency MemoryBlock

8-bit Byte MemoryBlock

Boolean Boolean Boolean

Colors N/A Color

Variant Variant Variant

Object Object Object

As I've mentioned, REALbasic is a modern, fully object-oriented and structured language. As such, REALbasic data typing is more stringent than Visual Basic. This is a real benefit, especially for shops that have more than one developer writing code. REALbasic syntax is easier to read, understand and maintain because of this structure. Of course, this means certain "sloppy" Visual Basic code will not import and run. For example, the following Visual Basic code "runs fine":

In REALbasic, the above code will fail since 0 is a numeric data type and not a Boolean!

Unlike Visual Basic, in REALbasic False ≠ 0 and True ≠ -1.

Again, Visual Basic makes it too easy to write "bad code," so cleaning up your Visual Basic code before importing into REALbasic is a must.

So, in conclusion, data type flexibility means portability is possible. Remember that Visual Basic Long data type is a REALbasic Integer. Currency and Byte data types do not exist in REALbasic. REALbasic Boolean is not 0 or 1, it is True or False. In addition, you may have to create your own "data types" using the more flexible REALbasic MemoryBlock. You will need to use MemoryBlocks instead of User Defined Types (UDTs).

Language Structure

The language structure of REALbasic and Visual Basic are similar, but not quite the same. This is due again to the richer REALbasic deployment environment and the elegant means of writing one line of code that works in multiple operating systems—with wildly different hardware and software architectures.

Some examples include File I/O, Method structure, Constructs, Error handling, and Object instantiation. Most of these issues arise from the Windows-centric nature of Visual Basic versus the portable object-orientation and object design approach taken by REALbasic. In general this object orientation is good in that you don't learn "bad habits." If Visual Basic didn't have a history to bring forward, it would have been easier to drop a lot of things Visual Basic does that are not quite correct. However, history aside, some things are quite different in REALbasic until you get familiar with it.

Case in point: File I/O

In order to have cross platform file I/O, you cannot use Windows-centric file structures and conventions. For example, Windows filename and paths use characters like \ that are not used, for example, on the Mac. If your goal is to write a more compatible Windows program than you can with Visual Basic, then you can use OS-specific structures in REALbasic. But if your goal is portability, then you need to use object-oriented methods, also possible in REALbasic.

Visual Basic File/IO is therefore different than REALbasic. Visual Basic uses distinct keywords for file I/O, often using UDTs. REALbasic uses object-oriented folder-and-object stream schema. (In fairness, I need to mention that a

© 2004 REAL Software, Inc. and Hank Marquis. All rights reserved. Page 9 of 17 REALbasic application might find itself compiled to Windows, Linux, or Mac—and the file systems of all these operating systems are different. They don't all use the same disk, directory, file and path implementation. Thus, REALbasic has one schema that can work for all operating systems.)

For example, in Visual Basic, to open a file and read in its contents:

Dim file As Long Dim x As String Open "vb2linuxrocks" For Binary As file x = String(Len(file), " ") Get #file, , x

Whereas in REALbasic:

Dim file As BinaryStream Dim x As String file = DesktopFolder.Child("REALbasic Rocks").OpenAsBinaryFile(false) x = file.ReadAll

Similar, but different. Once you get the hang of the REALbasic folder/object- oriented approach, you will see how much easier it is to use than the rigid Visual Basic path structured approach.

With regard to the structure of Methods (Subs, Functions, Events), Visual Basic and REALbasic are mostly compatible, with a few exceptions. REALbasic uses the Return keyword to define the return value of a function; Visual Basic uses method name. REALbasic uses the Exit keyword to exit any sub, function or event code; Visual Basic uses Exit Sub|Function|Property.

In REALbasic, pair of Setter/Getter methods are slightly different than in Visual Basic. Visual Basic calls these properties. Both Visual Basic and REALbasic require two methods and a property. REALbasic uses a Function/Sub pair for Properties; Visual Basic has the Property declaration. The result is exactly the same, but the code looks different. The following example shows the two implementations. In Visual Basic:

Property Let Caption (Text As String) lsText = Text End Property

Property Get Caption As String Caption = lsText End Property

In REALbasic:

Sub Caption (Assigns Text As String) lsText = Text

Function Caption As String Return lsText End Function

Both REALbasic and Visual Basic support custom Events. However, Events and raising events are handled differently. ByVal is default for both, and both offer ByRef. So in Visual Basic:

Public Event UpdateTime(ByVal dblJump As Double)

Public Sub TimerTask(Duration As Double) RaiseEvent UpdateTime(Timer - dblStart) End Sub

Where in REALbasic:

Event UpdateTime(dblJump As Double)

Public Sub TimerTask(ByRef Duration As Double) UpdateTime(Timer - dblStart) End Sub

Enums are not available in REALbasic. There is no workaround, other than to use constants. This could be a consideration if you use Enums.

As often is the case, REALbasic does what Visual Basic did, and then some. In the case of Visual Basic Enums, you have to make them REALbasic constants. REALbasic constants offer platform awareness and localization awareness that Visual Basic constants do not. This itself is a major benefit over Visual Basic.

Error handling is more robust in REALbasic than Visual Basic. REALbasic offers two error-handling methods: Exception blocks, which apply to an entire method, and Try-Catch blocks, which apply to specific sections of code. Visual Basic's On Error mechanism is not supported. There are no line numbers in REALbasic, but there is error information in an error object. In Visual Basic, you use the familiar:

On Error Goto|Resume|Resume Next

REALbasic offers the more modern

Exception x As [EXCEPTIONTYPE] Try ... Catch ... Finally

Both Visual Basic and REALbasic use Raise to raise an error, but the syntax is very different. In Visual Basic to raise an error you simply use:

Err.Raise

© 2004 REAL Software, Inc. and Hank Marquis. All rights reserved. Page 11 of 17 In REALbasic, you have to create an instance of RuntimeException or one of its subclasses, then raise it using the Raise statement:

Dim myErr As New RunTimeException Raise myErr

Another major benefit of REALbasic over Visual Basic error handling is the REALbasic UnhandledException event. If an unhandled error occurs anywhere in your application, it can be caught by this event, where you can handle it and exit gracefully. Application hard crashes are a thing of the past with a single line of REALbasic code!

For Object Instantiation, Both Visual Basic and REALbasic use Dim, New and =. Visual Basic uses Set, Let and Nothing; while REALbasic uses Nil. The major differences here are Set (Visual Basic only) vs. New; Nothing (Visual Basic only) vs. Nil, and no Let in REALbasic.

Equivalent implementations are not that difficult. In Visual Basic, as shown in the next example that raises a custom event, note how Visual Basic requires the "Set mText" line; while REALbasic simply uses "=" :

Private WithEvents mText As TimerState

'Visual Basic has Form_Load; REALbasic has Open Private Sub Form_Load() Set mText = New TimerState End Sub

And in REALbasic: mText As TimerState

'Visual Basic has Form_Load; REALbasic has Open Sub Open() mText = New TimerState End Sub

In conclusion, for Language Structure, there is no way around it, you'll need to do some manual tweaking. This may be the most difficult challenge for porting. However, there are enough similarities between Visual Basic and REALbasic to make porting possible, and the rewards are great. In addition, the areas of incompatibility are easy to identify, and again, your best bet is to play with REALbasic to get the hang of it before porting your application.

The graphical elements of REALbasic and Visual Basic are mostly the same, with a few exceptions. First of all, as you might expect given its Mac heritage, REALbasic has much richer graphical capabilities. The diagram below shows you the wealth of controls you have in REALbasic (REALbasic is on the left!).

There are identical and compatible interface controls, for example, the Visual Basic Picturebox matches up nicely with either REALbasic's PictureWell control or Canvas control.

Both support ActiveX controls or OLE (Windows only!), but REALbasic also supports cross-platform "Plug-ins." Since Mac and Linux do not support ActiveX, ActiveX controls will not port to other operating systems, even though they will port to REALbasic Windows builds.

You'll also find it really interesting that REALbasic actually handles Windows user interfaces better than Visual Basic!

Because REALbasic supports native UI widgets, REALbasic apps support the common characteristics of Windows 98NT/ME/2000 and XP. So, for example, your Visual Basic apps, once ported and recompiled, automatically assume XP themes.

In conclusion, the application user interface is better under REALbasic in most cases, and this is a major benefit of porting. However, not all common Visual Basic controls are supported, and this can be a show-stopper for some projects. Both REALbasic and Visual Basic support ActiveX, but ActiveX is not portable to other platforms, so your best bet is not to use them. In addition, REALbasic does not have TreeView, ListView, etc., so you may need to "roll your own" using intrinsic REALbasic controls and stick to stock Visual Basic-intrinsic control types.

Project Structure

REALbasic has a unique App module, it is similar in some ways to the Visual Basic startup object, but also different. So it would benefit you to become very familiar with it before porting, otherwise you might miss out on some neat cross-platform capabilities. For example, menus. Menus under Mac and Linux are not exactly the same as under Windows. Under the Mac, there is only one menu bar at any point it time, and there are certain menu locations that are specific and should hold specific items. For example, the Apple menu, Quit menu and others.

While Visual Basic and REALbasic both support MDI, for cross-platform, you need to move onto SDI interfaces with dialogs. Even Microsoft has started moving away from MDI interfaces, you should consider it as well.

API usage is different in REALbasic than in Visual Basic. REALbasic is richer due to its support for Windows, Linux, Mac OS X and Mac Classic. While Visual Basic can use UDTs, memory blocks must be used in REALbasic. In short, APIs are harder to port...but they can port. However, you will need to do some homework to ensure there is a replacement for your target OS. I suggest carefully thinking about why you are using an API call. If REALbasic has a method for doing what you need, I suggest dropping the API call.

However, you should feel comfortable that you can mix and match platform- specific code using REALbasic as shown below.

#If TargetMacOS Then //Mac specific code here. #ElseIf TargetWin32 Then //Windows code goes here. #ElseIf TargetLinux Then //Linux code goes right here. #EndIf

Other Considerations

You'll need to consider platform-specific usability and platform-specific guidelines. For example, if you are porting to Mac, you may want to become familiar with Mac User Interface Guidelines to help your app be more Mac-like. For Linux, you'll want to study up on SuSE or RedHat's UI.

There are many tools that are helpful for making your programs more robust. You'll need to take external tools and controls under consideration as you port your code, including ActiveX, Plug-ins, Debugging Tools, Performance Analysis Tools and Databases.

REALbasic can create Windows, Linux and Mac desktop (graphical UI), console ("DOS-box" UI) or service (or daemon) applications (no UI) from your Visual Basic code. As you can see from this analysis, an experienced Visual Basic developer can port a project cross-platform to Mac and Linux using REALbasic.

The port will require some manual tweaking, so you, the developer, must determine if it's easier to port or re-write your software.

In most cases, the Visual Basic User Interface (Forms) and almost all code can be imported, and of course, once you've written a program, porting and re- writing is easier because you've already thought through the logic of the program. The biggest problem will be in the use of Windows-specific custom controls (like TreeView, etc.).

By now, you may be thinking, "Hey, I can do this! It might just take some time..." So, to save you some time, let me introduce you to a nifty tool. REAL Software provides the VB Project Converter.

VB Project Converter includes a drag and drop interface and attempts to convert Visual Basic projects to REALbasic via XML. As such, it can help you port more quickly and successfully. See Table 3 for a step-by-step outline of preparing your code before you use VB Project Converter. See the Additional Resources section for information on how to download VB Project Converter.

In a nutshell, my suggestion is to use VB Project Converter to convert one file at a time. Here's the process to follow:

Drop file Export or "make external" Debug/port that code, save your changes Do it again and again 'Til you're done!

Summary

If you are Visual Basic developer or are responsible for Visual Basic applications, you may feel left behind. .Net requires massive frameworks and significant investment in new controls and tools, in addition to making you learn a new language. You may even be surprised to find you have to treat .Net as a new language—it's so different. Then, when you are done porting to .Net, you will have, drum roll please, a Windows application with huge system requirements. This is good for some, but not so good for you nor for those who may use your software.

Choosing instead to port to REALbasic gives you full Windows support, no huge runtime, minimal system requirements, and portability to Windows, Mac and Linux.

At a minimum, before starting with .Net, you should evaluate REALbasic. You might come away as I did, with a cross-platform version of your application and a clear path to the future.

1. Replace any & used for concatenation (bad programming practice anyway!); use + instead. Left("Honk", 1) & "ank" becomes Left("Honk", 1) + "ank"

2. Dim all variables on a single line to ensure YOU understand what they are supposed to do. 3. Use As Integer, not %, etc., in your code. 4. Be sure to remove DefXXX in each Form and Module to detect your data types. 5. Visual Basic Integers will become Longs in REALbasic, so check the logic of your code. 6. Do not use Visual Basic currency or byte data types unless you really need them. 7. Use Visual Basic Chr/Asc as Byte replacement. 8. Use Double as Currency replacement. 9. Visual Basic Error Handling will get Rem'd out, but you can locate it and fix it. 10. Remove line numbers as they are not supported in REALbasic. 11. Goto supported, but only with string label (no numbers). 12. Move as much code as possible from forms into modules. (In general, VB Project Converter does a better job with modules, and you can actually open a module directly using REALbasic without using VB Project Converter at all, if you wish.) 13. GoSub not supported, so replace with functions/methods as required. 14. Database will require some re-work, but SQL logic is largely compatible.

All of the resources mentioned in this document can be downloaded from:

REAL Software's download page

Get a free 10-day trial of REALbasic

Get the free Visual Basic Project Converter

< http://highspeed.realsoftware.com/REALbasic55/VBPC.zip>

Additional sites with information to help you port:

Please give us feedback: If you find errors or omissions in this document, please send feedback to: mailto: [email protected]

©2004 REAL Software, Incorporated and Hank Marquis. All rights reserved. REAL Software, REALbasic and the REAL Software cube logo are registered trademarks of REAL Software, Inc. All other names mentioned are trademarks or registered trademarks of their respective holders in the United States and other countries.