The search continues for the perfect cross-platform client/server application development environment. The challenge that faces most cross-platform tools is in being able to provide native features and functions, as well as robust database connectivity, all wrapped up in an easy-to-use development environment. Oh yeah, their source code still has to remain completely portable from platform to platform. This month, let's take a look at another contender: Galaxy 2.5 from Visix Software Inc.
Galaxy is a complex but powerful cross-platform development tool. It supports SunOS, Solaris, HP/UX, Ultrix, Windows NT, Irix, Windows 3.1, Windows 95, OS/2, and Macintosh System 7. Galaxy provides a comprehensive framework for application construction i n both C and C++ flavors. A Visual Resource Editor lets you lay out the user interface graphically. To help you build your application, Galaxy has 3500 powerful but complicated functions, which are organized into more than 50 groups known as managers.
To actually generate an application, Galaxy needs to wrap itself around a native ANSI C or C++ compiler. I took Galaxy for a drive on my Windows-based PC, using my trusty Borland C++ compiler, and here's what I found.
Another aspect of the Galaxy architecture is the Galaxy "ideal system" model. This model defines a uniform superset of application services, enabling you to deliver the same functionality on multiple platforms without having to "tune" the application to accommodate each platform's approach to managing colors, files, memory, images, events, strings, and other native system services.
Galaxy's command model, another aspect of the Galaxy architecture, abstracts the relationship between application logic and the user interface. Using the command model, the Galaxy application responds at runtime to a series of commands from user interfac e objects that are located anywhere on the network. Galaxy has the performance advantages of compiled code, as well as the flexibility of dynamic binding. In the Galaxy development environment, the user interface and the application logic are two distinc t, independent entities, which means that you can change Galaxy resources without recompiling the application.
Because C is not an object-oriented language, you must use the Galaxy class manager to implement the tool's object- oriented features. If you use C++, Galaxy classes are implemented as native C++ classes. Galaxy also supports dynamic inheritance, which lets developers enhance objects dynamically (such as changing colors, fonts, or other object properties).
Galaxy applications are built on top of a set of libraries that provide any function your application may require. There are 3500 entry points (or function calls) to the API, found in 50 class managers. The 3500 Galaxy API calls let you create applicatio ns as if you were using a native API (Win32, Win16, Xlib, and so on). However, the Galaxy API is portable across several platforms. A class manager is simply a framework designed around applications. If you think 3500 calls is too much to learn, you'll b e happy to know that the APIs are consistent within managers.
Galaxy groups the class managers into four categories: structural foundation, window system/graphical user interface, operating system abstractions, and distributed computing abstractions. The structural foundation manager helps build and connect the oth er Galaxy class managers.
Distributed Application Services (DAS) provide additional functionality. DAS is a collection of objects, tools, and runtime services that use native networks to build peer-to-peer distributed applications. The DAS Service Broker can locate and match serv er requests with available services on the network. DAS services register themselves with the Service Broker (using the Service Broker Manager). DAS is also Galaxy's gateway to relational database servers; I talk more about this later.
The Visual Resource Builder provides an interface construction tool for Galaxy applications. Once you create an interface with the Visual Resource Builder, the resources are stored in a portable binary format. Using the Visual Resource Builder, you can c reate windows, dialogs, strings, graphical images, error messages, and menus. The Visual Resource Builder was itself developed using the Galaxy APIs. Therefore, anything you can do in the Visual Resource Builder, you can do using the Galaxy APIs.
After creating the interface, you use the API to extend or change Visual Resource Builder-generated resources. The managers are set up as hierarchies that allow inheritance and extensibility for components. This means that you can alter resource files wi thout affecting application source code, and vice versa.
Many cross-platform tools cannot provide a native look and feel across platforms because they try to be all things to all GUIs and operating systems. Galaxy does not take this approach. The abstractions provide you with a standard view of system services across platforms using a layered API. Figures 1, 2, and 3 show the Visual Resource Builder windows in PC, Motif, and Mac environments, respectively.
If the native implementation lacks particular features, Galaxy can compensate. If Galaxy does not support a native feature, you can use platform-specific calls (that is, Win32, ODBC, native database API, and so on), or third-party class libraries (such a s Rogue Wave's DBTools.h++). This feature, however, compromises portability.
You must compile and link a Galaxy application using a native ANSI C or C++ compiler. Galaxy supports most major C and C++ compilers such as Sun Microsystems Inc.'s acc, GNU's gcc (a public-domain C++ compiler), and Symantec Corp.'s Think C 6.0 for Macin tosh, as well as Watcom International Corp. and Borland International Inc. C++ compilers for Windows. The Galaxy application executable is made up of the combined binary file, the resource file (created by the Visual Resource Builder), and the global Gal axy resource file. There are no runtime fees required to distribute applications.
If you do encounter a bug, you can utilize your compiler's native debugger to work through the problem. For application debugging, Galaxy offers both a debug and non-debug version of its libraries. The debug versions seek out memory leaks as well as trac e output for debugging.
Your second option is to use the relational database access add-on product (as the company brochure calls it) from Visix. This product includes a set of libraries, user interface objects, and visual tools that enable you to create applications that acces s relational databases. These database connections are built on top of the DAS facility and allow database-independent API abstraction.
There are a few things that you should know before you look at Galaxy. First, this is not a tool for those who want an easy-to-use 4GL. Galaxy applications are built with a complex API that has thousands of entry points. It will take time to get up to sp eed with the tool. What's more, the entire tool is layered on top of a 3GL (ANSI C and C++), and you need to know those tools as well. Also know that you will not find a repository. Galaxy's database connectivity is more of an afterthought, and there are few database-aware controls and other client/server development features like bundled report writers.
I would place Galaxy in the same category as other portable C++ libraries, such as XVT Development Solution for C++ from XVT Software Inc., C++ Views from Intersolv Inc., and zApp Developer's Suite from Rogue Wave Software Inc. All of these tools provide portable but proprietary API layers for C++. I see Galaxy as a niche player. Development organizations that want to give up simplicity to obtain power and portability will make a good home for Galaxy.
