Welcome!

PowerBuilder Authors: Yeshim Deniz, Chris Pollach, Jayaram Krishnaswamy, Kevin Benedict, Avi Rosenthal

Related Topics: PowerBuilder, .NET

PowerBuilder: Article

Whither Windows?

In the longer term, we need to rethink some other features of the PowerBuilder IDE

One of the questions that I've been pondering lately is what will become of Windows. Based on the buzz about BYOD (bring your own device), tablets and the like, and the less-than-stellar reception of Windows 8 and Surface (Microsoft's Windows 8 tablet), you'd think that Windows was on its last legs. Combine this with the "death of the PC" hype, and things look bleak.

They would look particularly bleak for PowerBuilder developers for two reasons. First, the PowerBuilder IDE is only available for the Windows platform. There were versions available for the Mac and UNIX at one point, and I used both, but they never generated enough sales to warrant the amount of support required to maintain them. Second, PowerBuilder essentially generates targets that - for the most part - only run on Windows devices. The Win32, .NET Windows Forms, .NET Assembly targets in PowerBuilder Classic and the WPF, PB Assembly, .NET Assembly targets in PowerBuilder.NET are all designed to run on Windows clients. The .NET Web Service in PowerBuilder Classic and the WCF Service in PowerBuilder.NET can be called from any client, but have to be deployed to a server running Windows. The .NET Web Forms Application target in PowerBuilder Classic not only has to be deployed to a server running Windows, but it's dependence on Internet Explorer on the client restricts it to use from Windows clients as well. The Application Server Component target in PowerBuilder Classic deploys to a Java Application Server, but requires that the PowerBuilder Application Server Plug-in be installed on that app server. The most recent release of that product (version 1.1 released in Sept of 2008) is only available for the Windows platform. And finally, the EAServer Component target in PowerBuilder Classic deploys to EAServer, which does run on non-Windows platforms (i.e., Linux, Sun Solaris, IBM AIX and HP-UX Itanium). However, the most recent version of that product (version 6.3.1 released in November of 2010) only provides support through the PowerBuilder 12.0 VM. Not sure what that means for PowerBuilder Classic 12.5 users.

However, I believe the future for Windows is brighter than all of the buzz might lead you to believe. While the Windows 8 adoption rate to date is rather slow, it has managed to surpass the market share of the latest version of Apple's desktop OS (http://www.winbeta.org/news/windows-8-finally-surpasses-osx-mountain-lion-market-share). Windows 7's adoption rate at this same point in time after its launch was higher, but then people had a reason to upgrade. Windows Vista had serious issues, and people needed to move off of XP. Currently a lot of people feel that Windows 7 meets their needs and don't see a reason to upgrade to Windows 8. In addition, that same article shows that 38% of desktops are still running Windows XP. Really? If those people haven't upgraded to Windows 7 yet, somehow I don't think they're the type of people who are suddenly going to rush out and buy Macs. Apparently they've found Windows XP meets their needs and don't see any reason to move off it anytime soon.

I'm convinced the BYOD (where D means tablet) hype is a bit overblown. I was an early adopter for the iPad. I had the original version shipped to my house FedEx directly from Apple the day it was released. I do use it considerably. And I do use it for a lot of tasks that I used to use my desktop for. However, what I'm using it for is short-term, non-highly interactive tasks such as reading email (including sending short replies), social networking, limited web surfing, and, of course, games. What I don't use it for are the long-term, highly interactive tasks that we write PowerBuilder apps for. It's not because there aren't apps available that would help me do long-term highly interactive tasks. There may be. It's because a tablet isn't well suited to doing such tasks. A touchscreen isn't sensitive enough to handle highly precise operations, and the software-based keyboard isn't sufficient for large quantities of writing. That's why I have an external keyboard in the case for my iPad, but even that isn't sufficient for anything more than doing blog entries. I'm not writing this article on my iPad, and I can't imagine trying to do it. So I don't see the desktop going away entirely. There may be a lot of home users who only used a desktop for such short-term non-highly interactive tasks, and they may end up moving to tablets (Windows or otherwise). But there will still be a significant demand for hardware that can support long-term highly interactive tasks, and that platform remains the desktop. For now it appears that Windows is going to rule the desktop for some time.

Does that mean that PowerBuilder is well positioned for the future? I don't think so. There are some gaps, and I would like to see PowerBuilder grow in order to address those gaps. While mobile devices aren't appropriate for long-term highly interactive tasks, they are appropriate for short-term limited interactive and highly specialized apps. For example, a mobile device is perfect for field staff who need to collect data such as insurance claim information, census data, gas and electric meter reads, package deliveries, orders and restaurants and stores, etc. That's the niche that PocketBuilder filled for a while, but it was discontinued in April of 2011 and, when available, only deployed apps for Windows clients. The first gap I'd like to see PowerBuilder fill is the ability to write such highly specialized data entry applications for mobile devices across a spectrum of operating systems. This may be something that the upcoming Appeon Mobile may address. The second gap is the ability to generate reports that can be consumed both through the web on desktops and mobile devices without relying on a particular browser or custom plug-in. It sounds like the HTML5 DataWindow that SAP has been demonstrating recently might help address that gap, but we won't know for sure until we see what is finally delivered. The third gap is the ability to deploy long-term, highly interactive task-based applications on desktops via the web so that a client runtime install is not required. Here again, the newest version of Appeon, currently in the works, may address that gap as well. It won't do that if it requires a custom plug-in as the current version does though. I don't want a custom plug-in available for other browsers; I want the product to work without custom a plug-in at all. Finally, the fourth gap would be in the support for the middle tier for operating systems other than Windows. It may be that the promises that SAP is making to allow PowerBuilder components as servlets in NetWeaver as well as the upcoming version of Appeon may address that gap.

Let me be more specific. One issue with making general statements like "deploy long-term highly interactive tasked based applications to the web" is that you end up with .NET WebForms. The fact that it only deploys to Windows servers and that it only works with Internet Explorer were only part of the issues with the product, and from my perspective not the most significant. What it didn't do was:

  • Make any attempt to make the application behave like a web application. Instead, standard desktop behaviors such as MDI were forced into the web-based application.
  • Require any re-architecting of the client application in order to separate UI logic from business logic. A great deal of the UI logic ended up getting compiled into the middle tier, requiring much more traffic between the client and the middle tier than was absolutely necessary.

The emphasis was on being able to take the existing client/server code and generate a web application from it with few if any changes. My concern is that much of the ongoing work to support web and mobile clients is headed down the same path.

Let me be even more specific. To reiterate, when I see PowerBuilder address these gaps, what I'm looking for is for something that will let me take my PowerBuilder skills and use the PowerBuilder IDE to create:

  • Small, highly specialized applications for a variety of mobile platforms.
  • Reports that can be run in a variety of platforms and form factors.
  • Larger, highly complex applications that can be run on a desktop through any browser without a custom plug-in
  • Deployment of business logic to a middle tier application server that supports a number of operating systems.
  • Applications that display appropriate behavior on the intended target. Web applications behave like web applications. Mobile applications behave like other native applications for that platform, including using native controls.

What I'm not looking for is the ability to create such applications without needing to make significant modifications to the existing code base. Instead, I want PowerBuilder to help me get started modifying the original client/server code so that it is properly partitioned into a middle tier and client application, the middle tier of which is now suitable for calling from other clients (e.g., the separate web client I'm going to create). I might still end up being able to use the client portion of the app to support multiple targets, but I also want some ability to have the application reconfigure itself when deployed to different targets.

How do we get there from here? I don't think current web-based technologies (i.e., HTML5) are adequate to developer the web applications I want to write. If we can't do it with such technologies, then we'll need to use some industry standard plug-in based technology in the short term until the newer web technologies mature to the point where we can use them.

I'm with Anatole Tartakovsky in thinking that the best choice today for creating web-based enterprise applications today is Flex (http://www.sys-con.com/node/2519967). The thing that Flex does well is it allows you to create an application that can respond to the environment that it's deployed to. It also creates applications that behave appropriately for the platform it's running on. If it wasn't for the somewhat unknown future of the product, I'd suggest that SAP might consider leveraging it for the creation of apps for the web and mobile devices in the short term. Its future is uncertain because it requires an industry standard plug-in for browsers (which are losing support). It also runs within the Air runtime on mobile devices, but that is less of a concern.

The other concern is that Adobe decided that they no longer wanted to support the product directly, and so donated it as an Apache open source project. The jury is out on how well that will work. To be clear though, what Flex does, and does well, is build clients. You've got to develop the middle tier on your own.

Of course, it would probably take considerable SAP resources to get PowerBuilder to generate Flex. Another near-term solution might be available though. Another product whose future is in question, but provides the capability I'm looking for, is Silverlight. It also requires an industry standard plug-in (though one that is not as widely adopted as the one Flex uses) and is available for a number of browsers. What it doesn't do (and Flex does) is allow you to deploy code to non-Windows mobile devices. Its future is also in question as Microsoft re-evaluates what technologies it supports for doing web applications, and it looks like that, unlike Flex, it's destined to die from neglect. It's also quite likely that given that PowerBuilder already generates WPF applications, it wouldn't be quite as hard to modify that capability so that it generates Silverlight as well. That doesn't give us options for mobile device deployment though.

Am I crazy thinking that we should adopt technologies that the vendors themselves are no longer supporting, either by releasing it to open source or allowing it to die of neglect? In the near term, I don't think so. I don't think Adobe was thinking about Line of Business application development when it decided to release Flex (or it decided it was a market niche they didn't want to support). Microsoft is probably focusing on the longer term, which explains why they haven't de-supported the technology yet, but are no longer actively promoting it. They need it as a stop gap until they get their next technology in widespread use.

In the longer term though, we need to rethink some other features of the PowerBuilder IDE. In particular, we may need to take a lead from Microsoft and add support for other scripting languages in the IDE. I've previously suggested that C# should be supported because of PowerBuilder's .NET capability, particularly in PowerBuilder.NET. Microsoft has added support for JavaScript as a "first class" language in Visual Studio 2012 (http://msdn.microsoft.com/en-us/library/hh334522.aspx). I'm thinking that support for JavaScript will be needed in the longer term as a scripting language that is supported on all of the platforms we will eventually need to support.

More Stories By Bruce Armstrong

Bruce Armstrong is a development lead with Integrated Data Services (www.get-integrated.com). A charter member of TeamSybase, he has been using PowerBuilder since version 1.0.B. He was a contributing author to SYS-CON's PowerBuilder 4.0 Secrets of the Masters and the editor of SAMs' PowerBuilder 9: Advanced Client/Server Development.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.