NET is becoming (or rather it has already become) a mainstream application development platform for developing both Windows Forms applications and Web applications, and more and more companies have adopted the .NET technology. Sybase anticipated this trend two years ago and developed a PowerBuilder .NET strategy. In that strategy, we decided to support .NET in four major steps. In the first step, we released with PowerBuilder 9 a PBNI extension called the WebServiceClient that enables PowerBuilder to consume .NET Web services.

In the second step, we released a new product - DataWindow.NET - that makes the patented DataWindow technology available to .NET developers. The PowerBuilder .NET compiler is the next step in the strategy. In this article, I'll give a brief introduction to the PowerBuilder .NET compiler we are working on. (Please note that the PowerBuilder .NET compiler is still in an early stage of development, so details are subject to change.)

Overview
The goal of the PowerBuilder .NET transformer is to be able to compile PowerBuilder applications into .NET applications (which could be a Windows Forms application, an ASP.NET application, or a smart client application) and to compile PowerBuilder non-visual objects (PowerBuilder NVOs) to .NET Web services. Compiling PowerBuilder applications to Smart Client applications and compiling PowerBuilder NVOs to .NET Web services might not be available in time for the next major release of PowerBuilder.

Briefly the PowerBuilder .NET compiler consists of two main modules as shown in Figure 1: the PowerBuilder system library for .NET and the MSIL emitter. The MSIL emitter compiles PowerBuilder code into MSIL code that references the PowerBuilder system library for .NET.

The MSIL emitter will be built into the PowerBuilder IDE in the next major release, which will be virtually transparent to PowerBuilder developers. What PowerBuilder developers will need to work with are two wizards and two project painters. The wizards are the .NET application wizard and the .NET Web services wizard, and the project painters are the .NET application project painter and the .NET Web services project painter. The wizards guide PowerBuilder developers to specific .NET projects, and the project painters are used to build .NET projects. The painters might be able to create an .msi file (Microsoft Installer file) that consists of the generated .NET application for installing or deploying the generated .NET application or Web services directly to the specified Web server. With these new wizards and painters, the PowerBuilder developers will be able to easily create and deploy .NET WinForm and WebForm applications, and Web services as well.

PowerBuilder System Library for .NET
The PowerBuilder system library for .NET, also transparent to developers, implements all PowerBuilder system classes, enumerations, and functions in .NET languages. The system library is basically managed, but not 100% managed, because the system library for .NET still relies on the DataWindow engine and the PBSHR.DLL library to communicate with database drivers.

Since the goal of the PowerBuilder .NET transformer is to be able to compile PowerBuilder applications to both Windows Forms and Web Forms applications, the system library needs to make PowerBuilder controls (e.g., CommandButton) available for both Windows Forms and Web Forms. To achieve this, we implement two sets of PowerBuilder controls: one for Windows Forms and one for Web Forms.

Figure 2 shows the assemblies of the system library and the related components. The system library consists of five assemblies and relies on DataWindow.NET, some third-party Web controls, and the PBSHR.DLL.

• The Sybase.PowerBuilder.Core.Dll defines the fundamental components of PowerBuilder, including data types, arrays, enumerations, and some base classes such as PowerObject and Transaction.
• The Sybase.PowerBuilder.Interop.Dll defines the PBSQL class for handling embedded SQL statements.
• The Sybase.PowerBuilder.Common.Dll defines the PowerBuilder system classes that are common for both Windows Forms and Web Forms (e.g., the Connection class).
• The Sybase.PowerBuilder.Win.Dll and Sybase.PowerBuilder.Web.Dll each define all PowerBuilder controls, such as Window, CommandButton, ListBox, and DataWindow.

PowerBuilder provides many features: data types, arrays, function/event invocation, event handling, operators and expressions, statements, DataWindow, embedded SQL, external functions, PBNI, and EAServer integration, to name a few. You may be curious about how all those features are mapped to .NET. Here are some details.

Mapping PowerBuilder Features to .NET
Data Types
PowerBuilder provides 15 standard data types: blob, boolean, char, date, datetime, decimal, double, integer, long, real, string, time, unsignedinteger, unsignedlong, and longlong, and a special data type (any) that can be used to represent any kind of data. One unique feature of PowerBuilder is that it allows you to get/set the nullness of a value or a variable by calling the IsNull/SetNull system function.

To support the data types and nullness, we defined a .NET interface IPBValue that has a property Null, which is both gettable and settable. For each PowerBuilder data type, we defined a .NET structure that implements the IPBValue interface. That way, it becomes possible to get/set the nullness of a value or a variable.

Table 1 shows the mapping between PowerBuilder data types and .NET data types. You may be worried about whether defining a .NET structure for each PowerBuilder data type will affect the performance of the emitted .NET assemblies. In fact, the impact is not significant because .NET structures are value types that can be allocated from a stack, which is far more efficient than the heap.

Event Handling
PowerBuilder was one of the pioneers in development tools that explicitly defined an event model. It should come as no surprise that .NET also defines an event model.

PowerBuilder defines about 600 events, most of which are associated with an event ID. For instance, the clicked event of the CommandButton control is associated with the event ID pbm_bnclicked. An event ID basically defines a method prototype, which is very similar to a .NET delegate. We map PowerBuilder event IDs to .NET delegates, PowerBuilder events to .NET events, and PowerBuilder event handlers to .NET methods. For example, the clicked event of the CommandButton-derived class cb_1 shown below is conceptually translated into the following C# code:

// PowerScript code
type cb_1 from commandbutton within w_main
...
end

event clicked
messagebox("PowerBuilder", "Hello world")
end


// C# code
public class cb_1 : PBCommandButton {
public PBM_EventHandler ClickEvent;
public cb_1() {
this.ClickedEvent += PBM_EventHandler(this.clicked);
}
public PBLong clicked() /*pbm_bnclicked*/ {
PBSystemFunctions.MessageBox(new PBString("PowerBuilder"),
new PBString("Hello world"));
return new PBLong(1);
}
...
}

PowerBuilder System-Defined Enumerations
PowerBuilder defines about 100 system-defined enumerations (e.g., Alignment, BorderStyle). For each of them, we defined a .NET enumeration that has exactly the same items as its PowerBuilder counterpart. The name of the .NET enumeration is the name of the PowerBuilder enumeration prefixed with "PB". For instance, the PowerBuilder BorderStyle enumeration is mapped to the .NET PBBorderStyle enumeration.