Introducing PowerBuilder 12 .NET

Introducing PowerBuilder 12 .NET

s the Microsoft .NET platform has matured, desktop application technologies have reached a new plateau. Decades-old client/server applications built for Win32 using the PowerBuilder platform are reaching the end of their useful life cycle, consequently IT managers and application developers are seeking the most cost-effective, lowest-risk method to move these applications into a next-generation format. The upcoming release of PowerBuilder 12, which is compliant with the .NET Common Language Runtime (CLR) promises to be the most effective method to migrate valuable PowerScript-based code assets to a standards-compliant, interoperable format with minimum risk and exposure.

This article explores some of the new PowerBuilder platform’s potential to accomplish that goal. It also offers suggestions on how to approach a PowerBuilder legacy application migration effort while leveraging available developer skills and knowledge.

Author’s Note: All opinions expressed in this article are those of the author and do not reflect the views of Sybase Inc. or any of its subsidiaries.

After its introduction in 1991, PowerBuilder (PB) quickly grew to dominate the client/server application development marketplace. In 1994 PowerBuilder had a 40% market share and was recognized as the COBOL of client/server development. The number of PB developers and the applications they produced continued to grow until around 1997, when—according to Sybase—PB had nearly a million development licenses worldwide. At that point however, things began to change. Y2K concerns, scalability issues inherent in the Client/Server architecture, and a shift to internet-based application deployment drew focus and resources away from new client/server based development.

Key factors in PB’s rise to fame and longevity include:

  • Its patented, highly productive DataWindow Technology; a richly functional mechanism for presenting and interacting with relational data.
  • Its productive object-oriented programming language called PowerScript.
  • Its open standards database interface that supports all relational DBMS vendor products.
  • Its highly productive integrated developer environment (IDE) that supports both rapid prototyping and rapid application development methodologies.
  • Its stable runtime environment, which is based on MS Win32 technology.
  • Sybase’s commitment to timely update releases, which help keep the platform current with ongoing technology advances.

From my unique perspective as a longstanding PB trainer and independent developer, I can personally testify to the broad use of the PB platform across the entire enterprise spectrum. Of late, however, interest in PB and its market recognition has waned—due in no small part to the staggering number of new technologies and paradigms that garner the attention of IT academics, industry pundits, and the developer community. Next-generation development is partially driven by available developer skills. Many software professionals now entering the work force have never even heard of PB and its capabilities. Currently, universities churn out software engineers and developers who are highly trained in Java, PHP, and C, and are conversant with the latest web-based presentation techniques. Technical schools and community colleges produce application development specialists who are well versed in .NET technologies and C#. Add to this the fact that many PB experts were forced to move on to greener pastures to remain employed, and you can understand why shops with existing PB-based mission-critical applications are concerned about using PB to develop the next generation of their mission critical applications.

Sybase has remained loyal to its developer base, releasing regular incremental enhancements to its core platform and tools. PowerBuilder also extended its reach in the enterprise with the addition of standards-based extensions to support multi-tiered computing, such as adding the ability to build server-based business logic and data-access components as well as client-side interfaces based on CORBA, Java EJB, and web services standards.

See also  Integrating Artificial Intelligence into Software Development Practices

But before committing to a revolutionary overhaul to the base platform, language support, and code generation capabilities, Sybase patiently waited out the battle for desktop language dominance between Sun’s Java and Microsoft’s .NET. Finally though, for corporate desktop application development, .NET has emerged as the dominant force. With the release of version 11, PB threw its hat on the side of Microsoft .NET and began its long march toward full .NET compliance. PB version 11.x gained the ability to deploy Win32 applications as .NET 2.0 WinForms or WebForms applications, and let developers embed .NET Framework calls into their code inside special compiler directive blocks. The .NET compatibility trend will culminate later this year with the release of PB 12, a major overhaul that will once again position the platform in the sweet spot of application development.

What has Sybase accomplished?

There is much new functionality to embrace in PB 12, including:

  • A brand new MS Visual Studio 2010-based IDE
  • .NET 3.5 CLR compliance
  • A completely new UI windowing system based on Windows Presentation Foundation (WPF)
  • Windows Communication Foundation (WCF) support for integrating applications into a service oriented architecture (SOA) design.

The good news for the community is that it’s easy to master the features in PB 12 whether you approach it from the perspective of a seasoned classic PB developer or from the perspective of a veteran Visual Studio .NET developer. From the perspective of someone who has worked with the Community Technology Preview and early Beta releases to produce learning modules to support rapid migration, here’s a brief description of what I found, what I did, what I think and what I project will be your initial experiences.


The PB UI engineers inventively merged classic PB IDE elements into an innovative design, packaged inside the modern industry-standard MS Visual Studio Shell. I became productive in the new IDE within an hour of installing it. I went over to YouTube, watched a couple of videos on the IDE produced by the product evangelist team, and then jumped right in. I made the decision to delegate mastering all the new IDE features to a background process so I could simulate how long it would take for a classic PB developer to do something useful and productive. I quickly found all my old PB IDE friends in new forms, understood many of the new developer aids, and got right into coding. I discovered that most of the IDE features are intuitive and approachable on an as-needed basis. Figure 1 shows the new IDE.

Figure 1. New PowerBuilder GUI: The new PowerBuilder GUI is based on the Visual Studio shell.

Building GUIs with WPF

Figure 2. WPF Painter: The new IDE includes a “screen painter” where you can drag-and-drop and configure elements visually. Behind the scenes, the painter generates XAML code that you can edit manually (if necessary) in a special XAML-code pane.

WPF is a vector graphics based way of rendering rich, dynamic, adaptable user interfaces. For Win32 app developers, WPF is an entirely new paradigm of UI design, and I confess that I’m still a “babe in the woods” with the technology. But I was able to leverage all I already knew about PB window layout and design when migrating an existing PB WinForms application into version 12 .NET and laying out a new basic WPF GUI (see Figure 2). It was easy to figure out enough about the PB WPF “Painter” to get my business logic coding job done. Of course, I anticipate needing to know lots more about WPF in the future, but not knowing much about it to begin with didn’t get in the way of migrating my application or of my .NET language coding activities. Truly mastering WPF will take some time, but because PB has integrated its classic UI elements and can migrate classic code forward, you can delegate WPF mastery to a background mid-priority learning task and get on with your pressing application maintenance needs.

WPF uses a XML-based layout language called XAML, which is standards-based, so you can import WPF XAML code into the PB IDE. The ramification of this for a PB project is that a graphic design specialist can create the GUI code (ala J2EE roles) and programming specialists can then integrate the pre-built GUI code into an application containing business rules and logic.

CLS Language Compatibility

On the language compatibility front, Sybase has transformed PB’s platform, integrated toolset and built-in PowerScript language into a .NET-compliant release that offers near complete backward and forward compatibility with existing classic PowerScript code. To understand the importance of this transformation, it’s worth including a brief examination of what being “.NET compliant” means. One main goal of the .NET platform is to facilitate seamless language interoperability, which is defined as the ability of code to interact directly with other code written in one or more different programming languages. The goal of interoperability is to maximize code reuse and improve the overall efficiency of the development process.

The .NET common language runtime (CLR) has built-in support for language interoperability. All .NET compliant languages compile to a common format known as Common Intermediate Language (CIL). This has the distinct advantage of allowing data types to be consistent across all languages, because all languages follow common type system rules for defining and using types. Types are discoverable at runtime or at design time, because metadata about types provides a uniform mechanism for storing and retrieving information about them. So the runtime can manage the execution of multi-language applications because all type information is stored and retrieved in the same way, regardless of the language the code was written in.

Figure 3. IDE Code Editor: This screenshot shows some PowerScript code in the code editor window that includes some .NET framework method calls.

Interoperability provides two key application design and coding benefits. First, regardless of the implementation language, types can inherit from other types, pass objects to another type’s methods, and call methods defined on other types. Second, exception handling is consistent across languages. Code can throw an exception in one language and that exception can be caught and understood by an object written in another language.

PB 12 lets you deploy existing PowerScript code (see Figure 3) as well as develop new code that can interoperate with code written in any other CLS-compliant language. Here’s how it works.

First and foremost, the PowerScript compiler emits native .NET assemblies—the compiler transforms native classic PowerScript code into its .NET equivalent as part of the compilation process. You don’t need to do anything special in your code for this to occur. Just press the Build button on the IDE toolbar. PB actually provides for three levels of .NET compliance. On the first level, your PB application functions as a .NET consumer because it can:

  • Call any CLS-compliant method on any assembly
  • Create an instance of any CLS-compliant type
  • Read and modify any CLS-compliant variable and
  • Access any CLS-compliant property and event.

On the next level, your application can become a .NET extender. A PB application has the ability to:

  • Define new non-generic CLS compliant types that extend CLS compliant base types (Inherit from CLS types)
  • Implement any CLS-compliant interface on a PowerScript class
  • Place CLS-compliant custom attributes on appropriate elements

At the third level, your PB code becomes part of the .NET framework and is accessible to other code. To make your code accessible, you must make sure that any functionality your code exposes is CLS-compliant and then deploy it as a .NET assembly. The process includes:

  • Defining all public and protected members of Custom Class User Objects (CCUOs are the PB equivalent of the vanilla Class type) so that any class that inherits from or interfaces to them can access any of their members.
  • Making sure that parameter and return types of public methods of your CCUOs are CLS-compliant. The good news is that you can use any non-CLS compliant PowerScript language features inside your implementation and still have a CLS-compliant assembly.

Climbing the Learning Curve

For classic PowerScript developers, the real learning curve involves expanding one’s language knowledge by becoming aware of and building applications using existing or extended .NET framework elements. The good news is that this knowledge is not necessary until you need to take advantage of the richness of the .NET framework. I’d suggest purchasing a quality .NET reference book and working your way through the sections and examples. The beautiful thing is that you can code and test most of the examples inside PB. One thing you will have to get used to is the hybrid form of the language, in which the core construct set and syntax are PowerScript, while the method calls and exception types are .NET.

From the other perspective—what it would be like for a professional Visual Studio .NET application developer new to PB to be productive as a developer in PB 12 .NET—I would conjecture they would need to learn these basic PB skills and concepts:

  1. How to organize PB code into PBLs
  2. The basic elements of the PowerScript language
  3. A bit about classic PB-specific IDE elements
  4. A basic knowledge of the classes in the PowerScript system class hierarchy and their members.

Overall, PB 12 .NET has the potential to give new a lease on life to existing PB mission-critical Win32-based business applications. It allows organizations to expand and integrate both legacy and new PB applications with current and future enterprise computing initiatives. The main challenge for Sybase going forward will not be one of technology, but rather of growing its PB market share in the face of the current competition and a lackluster global economy.

See also  How to Migrate From Microsoft 365 to Google Workspace

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist