![[Company Logo Image]](../images/logos.gif)
Software UNO Ltd. Software UNO Ltd.WM_MOTIF White Paper |
|
No patents are given for Reinventing the Wheel
Planning ahead requires vision of your customers present and future needs. Some software companies do not realize that they are over-committed to a single operating platform until their market forces them to provide a solution. But by then, it might be too late.
The first possibility that some companies consider is a complete re-coding of their software on the native API. The advantage of this approach is that it allows you to take advantage of features specific to that platform and could lead to higher performance in some cases. The disadvantage is that the costs of the development effort might make it unattractive considering the expected revenues.
A much more cost effective possibility is to use your existing code with a Windows API implementation under other platforms. Products like WM_MOTIF allow you to use popular frameworks available for the Windows API under UNIX. For OS/2 there is a library of conversion utilities called SMART that takes Windows API code and “ports” it under OS/2. If you are interested in the Mac, Microsoft released its Cross-platform Visual C++ product for the Macintosh that will allow portability for code that uses the Windows API. The popularity of the Windows API has made it an industry standard, even for platforms outside MS Windows.
Among the available C++ frameworks, MFC and OWL are very popular frameworks. You can get extensive support for them on CompuServe. There are also many books written about them. Getting information about implementing special features or training new developers is feasible without a large investment. In addition there is an extensive library of third party add-ons that could help you implement special features at a low cost. In many cases, you even get full source for the add-ons, a requirement for many software shops.
Windows API or Portable Framework ?
Another way of achieving portability between different operating systems is by using a portable framework. These frameworks generally offer a common proprietary API on multiple operating systems and can be optimized to handle a particular API. Yet since none of these APIs are as widely used as the Windows API, third party support is significantly lower.
Once you are past the initial development stage and you have learned how to do screens visually, you will be working with functionality issues specific to your project that go beyond what the frameworks offer. If you use MFC or OWL, which are based on the Windows API, you will have a very large number of add-ons to complement your framework, besides having many forums to receive support. The MSMFC and BCPPWIN forums in CompuServe receive more traffic in a day than the BBS or forums of most third party frameworks receive in a month. There are many books written on MFC and OWL and many programmers trained on it. Part of this is due to the compiler vendors including these frameworks at no additional cost with their compilers more than to pure technical merits. Yet the end result is that if you use these frameworks there's a very large industry following that you can take advantage of. And a large industry following is what made Windows programming popular in the first place.
Component technology is allowing even small companies develop high quality, feature packed code as required in today's competitive market. None of the portable frameworks have such an extensive library of add-ons and technical support or documentation as MFC and OWL, making it more expensive to implement features that are commonplace on the Windows market. Many special features of these frameworks call the Windows API directly and therefore are either not available or available much later on some of the portable frameworks.
A disadvantage of third party frameworks is the small number of third party add-ons that are available for them (with cross platform capabilities). As an example, one popular framework had requests for tabbed dialogs and hierarchical listboxes for over a year and a half. Well, if you go to the MSMFC forum you can download free MFC classes to do that. Waiting a year and a half for a feature might hurt the competitiveness of many products.
The concept behind our WM_MOTIF product is that by extending the Windows API to another platform we allow developers to take advantage of a huge number of add-ons and tools that exist for Windows at a very low cost. Write code once, port it to Windows NT, DOS (with Magma's MEWEL), OS/2 (with IBM's SMART), the Mac (with Microsoft's VC++ Add-on for the Mac) and to the leading UNIX platforms (with WM_MOTIF). With the large number of books, technical conferences, electronic forums and newsgroups, etc., the information you need to develop applications is literally at your fingertips !
Portability by Design, not by Accident
Even with cross-platform API implementations like WM_MOTIF, writing portable code does not occur by accident. Proper care and planning are required to achieve this goal. For example, in some applications even trivial issues like the DOS filenaming standards are a requirement for the application to work. These applications can't handle using filenames that don't follow 8.3 constraints (many UNIX systems now allow 255 character filenames), can't handle using "/" instead of "\" for directories and can't handle not having drive letters (C:, F: ... are not common on UNIX filenames). Products like WM_MOTIF will not magically make this code portable. Applications coded this way might need major recoding to work under other platforms because portability was not one of the original goals or because the designers were not aware of the issues involved.
Fortunately, the market does reward developers that plan ahead with handsome sales of their products on platforms ignored by their competitors.
|
