[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 6.23 Portability hints

GPC offers you the possibility to make your code fully portable to each of the many platforms supported by GPC. It would be a pity not to make use of this.

This section lists some known pitfalls that often hinder otherwise well-written programs to take full advantage of GPC. If you have never used any compiler but Borland Pascal and similar compilers, some of the advices might look strange to you. But this is just the same level of strangeness that your old programs will have for you once you have understood the principles of cross-platform portability. Remember that many tricks you have always been applying almost automatically in Borland Pascal were necessary to overcome certain limitations of the Dos platform and to compensate for the compiler's missing optimization. Programming with an optimizing compiler like GPC for platforms without a 64 kB limit is a completely new experience -- and perhaps it is among the reasons why you are now working with GPC in the first place?

### Portability -- why?

Okay -- but why should I bother and make my program portable? I know that all who want to use my program are running WXYZ-OS anyway.

Yes, but that's the result of a self-fulfilling prophecy. It depends on you whether it will always remain like this or not. Consider a program ABC written for a single platform, WXYZ-OS. Naturally, only WXYZ-OS-users get interested in ABC. The author gets feedback only from WXYZ-OS users and does not see any reason to make the program cross-platform. Then people realize that if they want to run ABC they must move to WXYZ-OS. The author concludes that people only want WXYZ-OS programs, and so on.

To break out, just create a portable version of your program now. Then all OSes have equal chances to show their abilities when running your program, and your customers can choose their OS. Then, maybe, they decide to use your program just for the reason that they can be sure that it will run on all present and future platforms and not only on a specific one -- who knows?

My program is a tool specifically designed to make the best of the STUV feature of WXYZ-OS. There is no point in making it portable.

How much do you know about non-WXYZ-OSes? Just ask an expert how the STUV feature is named elsewhere. Be sure, if it is of value, it exists almost everywhere.

### Low-level features

I am using a lot of low-level stuff in my programs, so they cannot be portable.

You do not use those low-level routines directly in your high-level routines, do you? There should always be a layer "in-between" that encapsulates the low-level routines and present an API to your program that exactly reflects the needs of your application. This "API in between" is the point where you can exchange the low-level routines by portable calls to GPC's Run Time System.

If you do not have such a layer in-between, then the API of the low-level routines you call are your first approximation for such a layer. If you have ever thought "it would be great if that API function had that additional parameter", then your own extended version of that API function that has that parameter can become part of your "API in between". But then don't stop here: Certainly the API of the OS is not ideal for your program's needs. Just create more routines that encapsulate all OS-specific stuff ...

When the low-level stuff in question consists of interrupts, assembler and similar things, then the first thing you need is a portable replacement of the functionality. Fortunately, GPC covers many things already in Pascal that require assembler in Borland Pascal:

- GPC's libraries come with source. You do not need to learn assembler and to write a complete replacement for the CRT unit if you only want to adapt some tiny detail in the behavior of CRT to your personal needs.

- GPC's Run Time System is fairly complete. For example, to extract the assigned name of a ``File'` variable, you do not need to mess around with the internal representation of those variables, but you can type ``uses GPC'` and then use the ``FileName'` function. In the same unit, you will find a ``FileExists'` function and much more.

- Manually "constructing" an object is covered by the ``SetType'` procedure in GPC. This is where Turbo Vision uses assembler to load an object from a stream.

- Calling local procedures and functions via pointers simply works in GPC. This is another place where, for instance, Turbo Vision's ``ForEach'` method uses assembler, while GPC lets you do the same thing in Pascal.

- Interfacing with the OS can be done through library calls. GPC's built-in functions and the GPC unit offer a rather complete set of routines. And again: You have the source of all this.

- Using ``FillChar'` and ``Move'` does not necessarily speed up your programs. Using them to circumvent restrictions of the language (e.g. for direct assignments between variables of object or file type) is asking for trouble. ``FillChar'` was created in UCSD Pascal to set consecutive chars in a string to the same value, and ``Move'` was created to move the chars within the same string. Better do not use them for other purposes.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

This document was generated by Frank Heckenbach on May, 10 2002 using texi2html