SGI Windows NT Toolbox

From Developer News, July/August 1997:

Porting Windows NT Code to IRIX

by Allen Bourgoyne, Manager, Western Applications


The following discussion will deal with the issue of porting code developed under the Microsoft Windows NT (NT) environment to the SGI IRIX operating system. Two distinct approaches will be examined. With each approach, we will explore some of the implementation details and review the inherent benefits and difficulties that may be encountered.

Why Port?

The decision to support multiple hardware platforms is strictly a business decision, and beyond the scope of this discussion. In general, most software products enjoy a variety of users with different levels of expertise and a wide range of demands. Therefore, it makes sense for software developers to offer their customers the widest possible choice in features and functionality. Naturally, these choices should include a choice in hardware as well.

Strategy #1: Native Port

In short, this strategy involves directly porting the NT derived code base over to IRIX. Depending on the application, the majority of this task may be spent porting the user interface (UI). NT UI code is based on the Windows 32bit, WIN32, application program interface (API). There is no native implementation of this API on IRIX. A native port of this code would involve porting all the WIN32 code to X/Motif. If the application has a large UI component, this may not be a trivial task. There are tools that can help here, such as the SGI RapidAppTM application builder tool. This tool can facilitate the rapid construction of UI components, alleviating much of the burden of writing large amounts of X/Motif code.

UI components are only one of several potential problem areas. Others could include any networking code, interclient communication codes, or process threading codes, to name a few. In each case, it will be necessary to use the corresponding IRIX API. In most cases, there may not be a direct correlation between NT and IRIX APIs. With threading for example, the Microsoft threads in NT have roughly the same functionality as UNIX pthreads, though there are some noticeable differences. Where the APIs diverge, it will be necessary to write some code to handle the differences. It is strongly advised that graphics code use OpenGL for both NT and IRIX ports. OpenGL is the graphics standard for graphics programming and is widely supported on NT supported graphics cards. Even if direct hardware support is not available, Microsoft does support a software version of OpenGL, so OpenGL codes can run, perhaps not optimally, but they can still execute.

The main advantage doing a native port is that of performance. Natively ported codes use IRIX APIs, APIs supported natively on the machine. These APIs have the advantage of being used in thousands of applications and benefit from long-term testing and tuning. In addition, Silicon Graphics can support new hardware through the standard system APIs, giving native applications access to any new hardware performance gains through those APIs, in most cases, without touching the application.

Native Porting Recap

So looking at both sides of the Native Porting effort, we can summarize as follows:

Pro: Optimal performance; applications can take advantage of new SGI hardware/software features not available on NT.

Con: Potential rewrite of large amounts of UI code; may not be direct NT to IRIX translation of every API, that is, threads, networking, and so on; two streams of source to maintain.

Strategy #2: Toolkit Port

An alternative to a native port, and all the code rewriting that goes along with it, is to use a toolkit. A toolkit can provide at least some of the required NT APIs on IRIX. The following discussion will concentrate on such a toolkit, MainWin from Mainsoft Corporation. Other toolkits are available. Selecting a toolkit is a complex issue. We will touch on this briefly below, but a full discussion on this topic is beyond the scope of this article.

The Mainsoft Corporation MainWin product provides for most of the required NT APIs, including WIN32, MFC, Active/X, COM, and Help. In addition, the most recent release of MainWin 2.1 fully supports the WGL interface, providing access to OpenGL through the standard Microsoft WIN32 mechanisms. By using MainWin, most stand-alone NT source codes can be recompiled without any source code modifications. If your code requires third-party NT libraries, you will either have to obtain IRIX versions of those libraries or find/write IRIX code that can perform the required functions. MainWin also supports creation of X11 child windows and the ability to do X11 rendering into MainWin Windows. Consequently, any legacy X11 code that may be difficult or undesirable to port can be leveraged by MainWin applications. As with most toolkits, run-time licensing involves a modest fee.

Toolkit Porting Recap

Looking at both sides of the Toolkit Porting effort, we can summarize as follows:

Pro: Toolkits such as the MainWin product can greatly reduce the amount of code rewrite necessary to port from NT to IRIX; single source code base reduces maintenance and potentially QA costs.

Con: Performance may not be optimal; additional software layers; run-time costs add to product cost for customer; port may be unable to take advantage of latest technology giving up a technological edge.

Choosing a Toolkit Vendor

A brief discussion on choosing a toolkit vendor is probably warranted here. Regardless of the type of toolkit you are looking to use (NT porting toolkit, GUI builder toolkit, and so on), here are some important issues to consider:

  • Does the toolkit provide the desired features?

  • Is the vendor going to be around for the long term?

    Your product may have a life-span of many years; support by the toolkit vendor may be required throughout this time.

  • Can you establish a good working relationship with the toolkit vendor?

    Bugs in the toolkit can impact your product schedules if not corrected promptly.

  • What are the run-time costs?

As mentioned earlier, a full discussion on toolkit vendor selection could be the basis of an entire novel. The point here is that it is important to make the most informed decision possible when selecting a toolkit and toolkit vendor. The issues listed above form the basis for starting this process.

Summary

Choosing to port an NT-instantiated product to IRIX is, for the most part, a business decision. If the business climate is favorable and you do decide to port, then it is time to make the decision between a native port and a toolkit-assisted port. With either approach, there are both positive and negative aspects to consider. In either case, you should be doing all 2D and 3D graphics work in OpenGL, for NT coding as well as on IRIX/UNIX. OpenGL has the greatest acceptance of any graphics API and will assist you in creating vendor-neutral, portable code. If you do decide to use a toolkit to aid in the porting effort, do your best to determine which toolkit and which toolkit vendor will best help you to do the job. And finally, as always, look to the many resources provided to you from the SGI Developer's Program. The CD-ROMs and printed materials that the Developer's Program sends out on a regular basis are a storehouse of valuable tips, source code, and technology information and can aid you during your porting efforts. Good porting!

References

For more information about Mainsoft Corporation, send an e-mail to sgi_sales@mainsoft.com, or visit the company's Web page:

http://www.mainsoft.com/

Comments


Copyright © 1997, Silicon Graphics, Inc.