Operating Systems 32-bit vs 64-bit

A question that gets asked around recent releases, is there a 32-bit version available?   This question is typically answered by those who have missed a release or two or more.

One of the criteria for us to support a particular operating system is that the operating system vendor must support it.  The number one reason we no longer support a 32-bit version on a particular operating system is because the vendor no longer supports it.

Another criteria for us to support a particular operating system is that we have it in our labs.  We then know we can build packages and run our QA tests and provide that assurance.  It is a reasonable assumption that the potential revenue we derive from supporting a particular operating system is greater than the cost of having it in our labs.

So for a system to appear in  the Supported Systems documentation (see an earlier Ask-Reuben on how to navigate the supported system documentation), the vendor supports it and we have access to it in our labs.

Sometimes on finding out that there is no longer a 32-bit version supported, this generates some unnecessary panic.

The three key things in my mind to remember is that

• operating systems require that libraries used by a program are the same number of bits.
• programs can still communicate with each other, even if they have a different number of bits.
• programs can launch programs that have a different number of bits, but you will need to ensure that the correct libraries are found.

To illustrate this…

• a 64-bit fglrun requires that the database client libraries and the c-extension libraries it links to are also 64-bit.   The 64-bit fglrun can’t link to 32-bit database libraries or c-extensions.  Similarly the 64-bit GDC requires that any custom front-calls to be compiled as 64-bit.
• A 64-bit fglrun can communicate with both a 64-bit GDC and a 32-bit GDC.  There is no requirement that a 64-bit fglrun has to use a 64-bit GDC.  The fglrun and GDC are seperate programs communicating with each other.
• A 64-bit fglrun can launch a 32-bit program but see this comment here about how on “On a system where a 32-bit and a 64-bit environment coexist, you may need to set LD_LIBRARY_PATH_64 to execute the 64-bit programs”.  This may necessitate setting an environment variable as part of the RUN command to make sure that any library found is the correct number of bits.

Sometimes we find that the c-extension libraries you think you have to link to, were written back in the past when Informix-4gl did not have file handling routines.  You can typically replace these with Genero code using the os Package and base.Channel class

If you find you are using a third party 32-bit library for which there is no 64-bit version available, in this day and age that is normally pretty telling for the ongoing support and viability of such a library.  Why has the vendor not updated it?

If you do feel like you have a requirement to use a 32-bit Genero package where there is only  a 64-bit Genero package available, examine closely why you think you have this requirement.   Are you using an operating system that the operating system vendor still supports?, are you using an operating system for which there is little commercial appeal?, are you using a library that the vendor has abandoned and not made available for 64-bits?.