A REAL Porting Exercise
Novell Cool Solutions: Feature
By Richard Smith
Digg This -
Posted: 11 Oct 2004
You no doubt have been following the efforts here on Cool Solutions for Developers to help assist you in your efforts to migrate your application base to Linux. Everything from scripting to full-blown Windows C++ application migrations have been covered, with much more to come.
The topic of porting an application to Linux hit very close to home for me recently. With the migration to Linux as the desktop of choice, I was forced to make considerations of how to handle some personal applications that I had written and use frequently. Since I would be using the Linux desktop as my work platform, I also decided to migrate my desktop systems at home to Linux. This presented me with a problem running some Visual Basic applications I had written to support one of my hobbies, an on-line horse racing simulation. Having played this game for four years and after investing a significant amount of time in creating some tools to make the game more enjoyable and less time consuming, I needed a solution for the change of operating systems. The exercise I went through to find a solution is not unlike what a business using Visual Basic based applications would also go through planning a migration. I'll go though the process I used to determine a migration strategy and the process, including problems and some ideas for solutions.
As part of this simulation, players are allowed to breed simulated horses using cyber-counterparts for many real life thoroughbred horses. The manager of the simulation provides players with access to information needed to accomplish these cyber ?breedings?, but restricts the number of times a given horse may be used during a week. As you might expect, demand for some of the more popular horses is great. The tool I chose to pilot this process was a fairly simple one, but one that had a number of functions that represented my Visual Basic applications and would provide a roadmap for planning future ports of my tools. This tool allows the user to create a list of the horses he/she wishes to track for use in breeding and to automate the process of tracking the availability and cost to use the horses. The list is read into the application, entries made in a grid and a call to a Web page containing the data as each individual horse is made. The HTML returned is then parsed and the needed data extracted and displayed on the grid (See Figure 1-1.) The program can also update the data on a timed interval, every 15 minutes in this case. This basic process could also be used to gather virtually any type of data presented in HTML tables on a web page where you don't have direct access to the data itself.
Figure 1-1. The existing Visual Basic application.
What are the Options
I examined what options I had in order to make my tools available on Linux and came up with the following choices:
- Use Wine/CrossOver Office
- Update the Windows VB applications to .NET and then use Mono on Linux to run them
- Re-write the applications in another language (Java, C++, Python, ???) that is available on Linux
- Use REALBasic and its tools to build a Linux application from my existing source code
Using Wine/CrossOver Office was an attractive option, but in a lot of ways it didn't solve the problem for the long term. Yes, I could get the application as it was compiled to run on Linux, most likely. But I had concerns about how to handle any fixes that might be required in the future. I would still need to have a Windows desktop to run the Visual Basic development environment.
I've already tried updating VB applications to VB.NET and have found it to be a very difficult option. VB.NET was not designed with backward compatibility in mind and in many ways migrating applications forward involves what amounts to a re-write. This seemed to present many of the same concerns as the next option.
Re-writing in another language was a definite option and one that I considered seriously. My first thought was to port the application to C#, which would require roughly the same amount of work as updating the Visual Basic code to VB.NET, with the advantage of learning C# for the future. This is the option that I will likely use in the future, using it as an opportunity to learn and use C#. But, it wasn't the right solution at the time, so I looked to option four.
REAL Software provides a Visual Basic compatible programming language called REALBasic that allows developers to build applications that will run on Windows, Macintosh and Linux. There is also a tool available that will do a lot of the code migration from VB code to REALBasic code for you. Another consideration for this option for me was that a number of other players of this game use this tool and still require a Windows version. Currently the only drawback of the REALBasic solution is the lack of an IDE that runs on Linux, but that is in the works and will be available from REAL Software early next year.
Since there are thousands of applications written in Visual Basic in use in many small- and medium-sized businesses, I decided to use the last option and see first hand what it would take to port my tool to REALBasic, and thus make it available on Linux.
REALBasic pros and cons
Before deciding to port my tools to REALBasic, I took stock of what REALBasic had to offer as benefits and what the drawbacks to the migration would be.
- Multi-platform support (and even on Win32, easier support for older versions of Windows going back to Win98 and forward)
- Migration Tool available
- Extremely similar language and features
- Easy-to-use IDE with many features similar to VB
- More advanced BASIC language, more structured and object-oriented
- Feature-rich built-in capabilities and controls
- No native Linux development environment
- Lack of support for some features in cross-platform applications
- New syntax and language features to learn
- Only Windows, Mac and Linux as targets (not much of a con)
- Additional coding required even after Converter is run
In my case the most important pros were the first two. These two features would enable me to most quickly port my tools to run on Linux, with the least effort involved. The other three pros helped to add to my confidence that the application would be ported and provide roughly the same functionality as the original Windows version.
On the negative side for the REALBasic port, again the first two listed had the most impact. If it weren't for the upcoming availability of a Linux development environment, my decision might have been different. The other concerns, while important, would have been even more critical had one of the other options for porting been selected.
REAL Software provides an excellent guide to help Visual Basic developers understand some of the ins and outs of porting applications. You can download a copy at http://www.realsoftware.com/realbasic/guides/portingvisualbasic/.
After evaluating these pros and cons, I determined that at least as an interim step to migration of my applications to Linux, REALBasic was a solid choice. So I set out to do the port.
Use the Tool!!
Visual Basic and REALBasic share a lot in many areas. In areas like language structure, keywords and data type they are very much alike, although there are differences. Many of the difference that REALBasic has from VB can be handled due to REALBasic's extensive built-in features and controls that allow a developer to replace the missing VB feature with coded replacements.
The VB Project Converter is available as a download on REAL Software's Web site (http://highspeed.realsoftware.com/REALbasic553/VBPC.zip). It is a REALBasic application that takes your Visual Basic project file as input (See Figure 1-2) and converts it to an XML Project file that then can be loaded into the REALBasic development environment. It also creates a report of what cannot be converted and anything that needs attention during the porting process. Using this report a developer can pinpoint within the ported Visual Basic code changes that need to be made in order for the code function properly.
Figure 1-2. VB Project Converter.
The XML output from the converter can then be read directly into REALBasic and the conversion process can continue. One area where I ran into a problem was with the use of Visual Basic ActiveX controls (OCXs). My original application used the Microsoft FlexGrid OCX as the visual component to display the data captured by the application. The FlexGrid allowed the data to be organized and sorted within the program.
Because of its multi-platform support, REALBasic does not support ActiveX controls on targets other than Windows, and references to those controls within the program code are ignored by the converter program. This would prove to be the most time-consuming aspect of the migration. If your VB program makes use of ActiveX controls, be prepared to find a REALBasic counterpart to replace the original component. In my case, I found the REALBasic ListBox control to be a viable alternative to the FlexGrid control used originally. In fact, in many ways the ListBox provided more built-in functionality that I used than did the OCX used in VB. After an hour or so of coding and testing, the ListBox control was up and running, providing the functionality needed to display the captured data.
A number of other methods used within my original VB applications were either supported differently by REALBasic or not supported at all. In many cases the converter program offered alternate options, but in nearly all cases, it, at a minimum, flagged these methods for further consideration. Here is an example of the original code for one function and the converted code.
Original VB code
Function getSire(hName As String, caller As Integer) On Error GoTo err_handler get_it: getSire = frmGetBreedInfo.Inet3.OpenURL ("http://thoroughbredracing.net/hr/runtime/sirelook.asp?lg=&idno=9400&hossname=" & hName & " ") Exit Function err_handler: Select Case Err.Number Case Is = 35761, 5 Resume get_it Case Else getSire = 0 MsgBox "An un-trapped error has occured! The error is: " & Err.Number & " Desc: " & Err.Description, vbOKOnly End Select End Function
Function getSire(hName as String, caller as Integer) as variant DIM vargetSire as variant //MsgBox syntax not supported. //On ERROR GOTO err_handler get_it: //Invalid Function assigment syntax [function name getSire = return value] //You may use: Return frmGetBreedInfo.Inet3.OpenURL ("http://thoroughbredracing.net/hr/runtime/sirelook.asp?lg=&idno=9400&hossname=" + hName + " ") vargetSire=frmGetBreedInfo.Inet3.OpenURL ("http://thoroughbredracing.net/hr/runtime/sirelook.asp?lg=&idno=9400&hossname=" + hName + " ") Return vargetSire Exception err //Error handler for err_handler Select Case Err.Number CASE 35761 Resume get_it CASE 5 Resume get_it Else //Invalid Function assigment syntax [function name getSire = return value] //You may use: Return 0 vargetSire=0 Msgbox "An un-trapped error has occured! The error is: "&Err.Number&" Desc: "&Err.Description //[Note] You may also use this function: //i = DialogBox("An un-trapped error has occured! The error is: "&Err.Number&" Desc: "&Err.Description,vbOKOnly) End Select Return vargetSire End Function
As you can see a significant portion of the code has been converted to the proper REALBasic syntax and added comments explain the difference and changes. Along with this, as mentioned, the Visual Basic converter also builds an HTML page that contains information on what requires attention (See Figure 1-3.)
Figure 1-3. Example report generated by Visual Basic converter
Using this report you can quickly find problem areas and make corrections. In many cases the converter has actually made the correction, and the report provides you with information to help you understand the changes.
Now for what I had expected to be the biggest task I'd tackle in the port, replacing the MS FlexGrid control. I went about exploring REALBasic to find a way to make this work without having to write my own grid control. I found what proved to be a very good replacement for the FlexGrid in REALBasic's ListBox control. When I first discovered it and determined that it could be made to substitute for the FlexGrid I thought it would still be some work, more than the FlexGrid had taken. I was pleased to find out that using the ListBox was as easy, if not easier, than the FlexGrid. Here are two examples of the code required to fill the display grid with the data for each data record created.
First, the Visual Basic code snippet.
Grd1.row = Index Grd1.col = 1 Grd1.Text = txtID1 Grd1.col = 2 Grd1.Text = txtCost1 Grd1.col = 3 Grd1.Text = txt6hrs1 Grd1.col = 4 Grd1.Text = txt12hrs1 Grd1.col = 5 Grd1.Text = txt24hrs1 Grd1.col = 6 Grd1.Text = txt2yr1 Grd1.col = 7 Grd1.Text = txt3yr1 Grd1.col = 8 Grd1.Text = txtDS1 Grd1.col = 9 Grd1.Text = txtDDS1 Grd1.col = 10 Grd1.Text = txtST1 Grd1.col = 11 Grd1.Text = txtCR1
Now the code to do the same process for the ListBox in REALBasic.
listbox1.cell(Indx,1) = txtID1 listbox1.cell(Indx,2) = txtCost1 listbox1.cell(Indx,3) = txt6hrs1 listbox1.cell(Indx,4) = txt12hrs1 listbox1.cell(Indx,5) = txt24hrs1 listbox1.cell(Indx,6) = txt2yr1 listbox1.cell(Indx,7) = txt3yr1 listbox1.cell(Indx,8) = txtDS1 listbox1.cell(Indx,9) = txtDDS1 listbox1.cell(Indx,10) = txtST1 listbox1.cell(Indx,11) = txtCR1
Not more complicated or involved at all.
Most of the 6 or so hours it took me to port the application, to compile it and then to run it on Linux involved learning the REALBasic IDE and configuration options. I read a bit of the REALBasic User's Guide and then referred to the Language Reference occasionally during this time, but most of what I needed was within the environment itself.
Here is what the finished product looks like when run on Linux.
Figure 1-4. Ported VB application running on Linux.
You'll notice that the application takes on the appearance of a native GTK-based Linux application. REALBasic applications on Linux require GTK2.0+ and thus utilize this to provide the look and feel of a Linux application. I did nothing special to make this happen. Although REALBasic does allow target specific code to be used, the developer must be aware that the application may not exhibit the expected results when run on a different platform.
So I now have one of my tools running on Linux, with more to follow. Going the REALBasic route for migration has the added benefit of also opening up my tools to users who might be using a Mac.
Some things to think about
While this solution might not be exactly right for you, especially if you are not currently using Visual Basic applications, it does illustrate that there are solutions to porting and migration problems available. And even if you don't currently use VB, REALBasic offers a great entry-level opportunity to deliver applications across multiple platforms, using a single code base. In my case, I picked up Visual Basic specifically for building the tools mentioned in this article. Previous tools for the online simulation had been written in VB and the resources were available. At the time, I also wasn't thinking about multiple platform support. A great number of developers have followed this same path and are finding the need to deliver across more than one platform.
There are also times when a tool like REALBasic provides a very solid transition strategy for moving to a new platform. The reality today is that no business can afford down time for critical applications, so to make a migration to another platform requires a way to do that without impacting productivity.
Sometimes as a developer it's easy to lose sight of the ultimate goal, to deliver applications that solve problems for users. Most users don't care how it is done or what it takes to make it work, they just care that it does. Platforms, operating systems, kernels, etc. are not important to most computer users. What matters to them is that they can turn on their computer and that the applications are available to do what they want to do. Tools like REALBasic enable developers to meet that need.
If you are one of the millions of Visual Basic programmers and you find yourself faced with the requirement to deliver your applications on Linux, REALBasic is a good choice to solve your problem. Once you start using REALBasic you'll find that it exceeds Visual Basic in many areas and can help you move you programming skills to a new level, while still maintaining your existing user base.
Real Software Home Page
Get a 10 day free trial of REALBasic
Porting VB Applications to Linux and Mac OS X by Hank Marquis
Check out what other developers have created using REALBasic http://www.realsoftware.com/realbasic/showcase/
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com