- ILP32 - A 32-bit application source. In this model, the size of int, long, and pointer for C and C++ is 32-bit.
- LP64 - A 64-bit application source. In this model, the size of int for C and C++ is 32 bit, while the size of long, and pointer is 64-bit.
- AIX 5L - Version 5 of the AIX operating system that runs on PowerPC and Itanium based systems
- Little Endian (LE) - The right to left assignment of addresses to bytes in a data word.
- Big Endian (BE) - The left to right assignment of addresses to bytes in a data word.
- Endian-Sensitive Application - An application source that depends on the byte ordering
- Endian-Neutral Application - An application source that has no dependency on byte ordering
Most applications are written in one or more high-level languages. Since applications written in assembly or macro assembly will need complete rewrites, we will discuss porting issues in terms of mostly C and C++. Variations of the problems occur with other languages.
Most well-written C and C++ programs will compile and run on AIX without change, where "well-written" means the use of good programming practices, including:
- Conformance to the ANSI/ISO C standard
- Portability considerations high in the design, implementation, and maintenance phases of the software cycle
- Use of prototyped functions declarations throughout
Migrating applications from one platform to the other involves recompiling, relinking, debugging, and, if necessary, performance tuning. Programs that adhere to standard language conventions and that are not overly dependent on the platform architecture often port easily with few code changes.
AIX is IBM's strategic UNIX; operating system for mission-critical, core business applications. The two currently available versions of AIX are version 4.3.3 and 5.1.
The industrial-strength features and functions of AIX have been well proven over the years in a wide variety of server environments, from relatively small single-processor systems through IBM's massively parallel Scalable POWERParallel (SP) servers. These features from the latest version, AIX 5L version 5.1 include:
- State-of-the-art 32-bit and 64-bit kernels
- 32-bit and 64-bit application programming interfaces (APIs) support
- Linux affinity that allows customers to realize a smooth technology transition between AIX and Linux.
- Workload Manager to balance the most complex workloads.
- Simplified system management - System Management Interface Tool (SMIT) and Web-based System Management
Tru64 has a 64-bit kernel architecture, based on components from the Berkeley Software Distribution (BSD) 4.3 and 4.4, UNIX System V, and other sources.
General Differences Between AIX and Tru64
All defines for numeric values can be found in /usr/include/sys/limits.h and /usr/include/float.h on AIX, and /usr/include/limits.h and /usr/include/alpha/machlimits.h on Tru64.
Some differences between the maximum and minimum values of standard defines exist between the two operating systems due to differences in the system architecture.
Double on AIX (32 and 64 bit) has a size of 8 bytes, but is aligned at 4 byte boundary. See the table below:
Many RISC systems are sensitive to the alignment of data within memory and give best performance when data is aligned on particular boundaries. However, there is no silver bullet. Aligning data on certain boundaries may be an excellent choice when dealing with one data structure, but not so good when dealing with an array of thousands of data structures. This is because memory space may be used less efficiently, or there may be more frequent cache misses.
Four alignment options are supported by the compiler, as detailed in Table 1.2.
AIX provides full support for the ANSI specifications of the C and C++ languages. The latest version of the native compiler for AIX, VisualAge for C and C++ V5.0 (VAC 5.0), adheres to the latest approved definitions of these languages.
The compiler binaries are installed in /usr/bin/vac for C and /usr/bin/vacpp for C++. The default location of the documentation is in /usr/vachtml/en-US/doc/index.htm for C and /usr/vacpp/bin/vacpphelp for C++. The Version 5 compiler product includes a number of default configurations in the /etc/vac.cfg, which are activated depending on the exact driver program called. As an example, to compile an ANSI C program using the UNIX98 threads libraries, use /usr/vac/bin/xlc_r command. To compile an ANSI C program using the POSIX Draft 7 threads library use /usr/vac/bin/xlc_r7 command. For threaded C++ applications use /usr/vacpp/bin/xlC_r command.
By default the compiler creates 32-bit object code. The option to enable compiling an application in 64-bit mode on AIX is -q64. Another way to obtain 64-bit object code is by setting the environment variable OBJECT_MODE=64. -qwarn64 will warn of potential 64-bit related migration problems.
Please note that any third party library being linked into a 64-bit application will have to be 64-bit also. To determine the object mode of any module or library on AIX, run the command:
> dump -X32 -ov <file name>
Where file_name is the name of any object module, such as libxyz.a. In the output, search for the string "XCOFF". This will work for 32-bit modules only. For 64-bit modules, use:
> dump -X64 -ov <file name>
On AIX, an archive may contain different types of objects. For example, libc.a contains both 32- and 64-bit .o files, 32-bit shared libraries and 64-bit shared libraries. Applications (both 32-bit and 64-bit) can link dynamically and/or statically against this single archive (libc.a). Tru64 provides archive libraries in addition to the shared libraries also. However the linker and loader on AIX functions somewhat differently.
On AIX, symbol resolution is performed at link time. If a symbol is defined in a shared object (or module) referenced on the command line, the linker records the symbol name and defining module in the loader section of the program. When a program is executed, imported symbols must be resolved by finding them in the defining module, as recorded at link time.
The inability to associate a symbol to a specific library on platforms other than AIX makes the order in which the libraries are specified very important. For instance, with respect to rpc, if the streams behavior is required the library order must be libnsl, then libc. If sockets behavior is required, it must be libc followed by libnsl. For example:
- Module A contains a definition for function X
- Library foo also has a definition for a different function X
- Library foo has a function Y which calls function X
If an application using both of these is linked such that A is specified on the command line before foo, then the following symbol references occur:
- On AIX, function Y will get the X present in library foo.
- On Tru64, function Y will get the X present in Module A.
If the application is linked with foo listed before A on the command line, then the AIX behavior remains the same, while on Tru64, function Y will now call the instance of X found in foo.
An additional feature on AIX is the ability to re-link executables. The output of the ld command can be used as an input to it also. This means that it is possible to relink new object files (.o's) with an existing application and replace code within the application without having to completely rebuild the application. This capability can save a considerable amount of time during the application build cycle.
For more detailed information, a complete description of the AIX linker and loader mechanisms, various linker options, examples and FAQ are available.
Tru64 applications that use mixed languages, such as those calling Fortran routines from C, require the Fortran Run Time environment to be initialized by calling the for_rtl_init routine. An example of this is illustrated below:
/* Do fortran initialization... */
printf ("Initializing DEC F77 RTL Environment\n");
for_rtl_init_ (&argc, argv);
|
On AIX, even in mixed-language applications there are no specific calls required for initializing libraries. All system libraries are self-initializing. This is also true for applications that incorporate C++. There are no problems calling Fortran functions from C, or vice versa, as long as the standard calling conventions are followed (e.g. call by reference vs. call by value.)
Some Tru64 FORTRAN applications may be using VMS features such as shcom_connect(). This function allows applications to place common block data into a read-write region that is accessible to multiple processes (i.e. shared images). The way to implement this on AIX (or other UNIX systems) is to use shared memory. This involves building an application such that common blocks are located in shared memory regions, and creating and attaching the shared memory segment, then populating them with the data.
The PowerPC architecture is bi-endian. However, AIX boots big-endian on PowerPC. Alpha architecture is little-endian. Endianness refers to how a data element and its individual bytes are stored (or addressed in memory). For big-endian (BE), the lowest address is associated with the most significant (or left-most) byte of a multibyte value, while a little-endian gives the lowest address to the least significant (or right-most) byte of a multibyte value. In general, bit zero is associated with the most significant bit (MSB) for BE; but with the least significant bit for LE.
A 4-byte word with LE and BE representations are shown to illustrate that the data itself in a word are the same in both cases (see Figure 1); while the byte address associated with each data byte is different. Bytes are addressed in an opposite direction and the rest remains the same.
Figure 1.1 shows the layout in the case of a more complicated 64-bit double-word with multiple data elements. Variables a, b, and c all are located at the same addresses: 00, 04, and 06 in both cases. Data elements and the individual bytes within a data element are stored in a consistent left-to-right order for BE. For LE, on the other hand, data elements are stored in a right-to-left order; while data bytes within a data element remain in a left-to-right order. This can be confusing, particularly in reading the memory dump on a little-endian machine.
Byte ordering is not an issue if a program that writes a word to memory then reads the same location as a word-it sees the same value if a variable is referenced consistently. If a program tries to read the same value one byte at a time (when a word is written), it may get different results depending on whether the processor is BE or LE.
In AIX, the hardware provides a continuous range of virtual memory addresses, from 0x00000000000000000000 to 0xFFFFFFFFFFFFFFFFFFFF, for accessing data. The total addressable space is more than 1 trillion terabytes. Memory access instructions generate an address of 64 bits: 36 bits to select a segment register and 28 bits to give an offset within the segment. This addressing scheme provides access to more than 64 million segments of up to 256M bytes each. Each segment register contains a 52-bit segment ID that becomes a prefix to the 28-bit offset, which together form the virtual memory address. The resulting 80-bit virtual address refers to a single, large, system-wide virtual memory space. The process space is a 64-bit address space; that is, programs use 64-bit pointers. However, each process or interrupt handler can address only the systemwide virtual memory space (segment) whose segment IDs are in the segment register.
A 64-bit application program running on the system has an address space that is divided into segments, as follows:
On AIX, a 64-bit application is always loaded at 0x0000000100000000. Note that the kernel is mapped into low memory, starting at address 0x0. Therefore, while 32-bit pointers cannot be used to access any portion of the 64-bit application address space, it is possible to read regions of the kernel segment (in low memory) using a 32-bit pointer.
For more information on the AIX memory model, please refer to the on-line documentation.
Key in the search string "Program Address Space Overview", or "Understanding Memory Mapping".
AIX 4.3.3 needs the bos.64bit fileset installed to run 64-bit applications. (Command lslpp -L|grep bos.64bit can be executed to see if that fileset is already installed. If it isn't, then it can be installed from the AIX installation CDs.)
AIX 5L can be booted up with either the 32-bit or the 64-bit kernel. Beginning with AIX 5L, all 64-bit applications will run on either kernel, as will all 32-bit applications. However, if the most critical applications running on the system are 64-bit, it is advisable to boot the server with the 64-bit kernel in order to take full advantage of the hardware capabilities. The 64-bit kernel is packed with the bos.mp64 fileset. Installation of this fileset is automatic if the option Enable 64-bit Kernel and JFS2 is selected under 'Advanced Options' on the 'Installation' and 'Settings' screen. This will also cause the 64-bit kernel to boot by default.
During the normal installation process, the 32-bit kernel is enabled by default. The system can be changed to boot-up in 64-bit kernel mode by using the following commands:
> ln -sf /usr/lib/boot/unix_xx /unix > ln -sf /usr/lib/boot/unix_xx /usr/lib/boot/unix > bosboot -ad /dev/ipldevice > shutdown -r where unix_xx is: unix_up - 32 bit uni kernel unix_mp - 32 bit mp kernel unix_64 - 64 bit mp kernel |
One of the most significant performance differences will result from the byte addressibility of AIX, which provides the capability of loading individual bytes, half-words, words, or, on 64-bit machines, double words (8 bytes) via atomic operations. This completely obviates the need for the compiler to generate additional instructions to manage these smaller datum, resulting in an overall improvement in memory access throughput. [Note the nomenclature differences between the two platforms: the native word size on AIX is 32-bits, which would be considered 2 words on Tru64.]
A significant difference between AIX and Tru64 (as well as other UNIX systems) is that the end user or system adminitrator does not modify kernel configuration files and therefore does not need to rebuild the kernel. All tunable parameters in AIX can be adjusted through the smit command ("smitty chgsys"), as well as the >vmtune and >schedtune commands found in >/usr/samples/kernel.
A large body of on-line documentation is available on the topic of performance tuning. Please refer to this site for more information on application and system tuning parameters available on AIX.
There are a number of small differences between the pthreads libraries on Tru64 and AIX. AIX provides support for building applications written to both the Draft 10 and Draft 7 specifications of POSIX 1003.1c threads, as well as providing a number of non-portable extensions. Refer to the AIX documentation for detailed information on specific programming interfaces
AIX fixes, updates etc. can be downloaded from this site.
In general, a program module is endian-neutral-the compilation will resolve the differences in byte ordering between LE and BE, if multibyte data elements are not referenced as individual bytes (or its proper subset) or vice versa. On the other hand, using a union data structure, casting a data element, or manipulating bit fields can reference individual bytes in a multibyte data element in a reversed byte order. This can be problematic when porting code between LE and BE machines. Another source of endian dependencies comes from sharing data across platforms. Typically, data is converted to a canonical data format for sharing to avoid endian dependency. Similarly, endianness problems result when interfacing with external devices (these can typically be solved by hardware and/or software solutions).
Running lint or other programming aids can point out dubious uses of C construct. Other than that, there is no real magic in identifying and changing code automatically to correct endianness problems. In this section, several code examples are illustrated to show how to look for code patterns that can have potential endianness problems. In some cases, changes for making the code endian-neutral or endian-aware are suggested.
Data type mismatch is a major source for endian dependency. A data should be treated at runtime as defined by its data type to avoid endian dependency problems. These can be discovered by inspection or lint. Using lint can indicate potential castings that are hiding endian dependency problems.
For example, a 4-byte integer should be treated by the processor as an indivisible data element of integer data type. The individual bits and bytes in the integer are viewed in opposite orders by LE and BE. Accessing the integer as a smaller unit can produce different results by LE and BE processors, as shown in the next code example.
int a = 0x11121314; char b, *ptr; ... ptr = (char *) &a; // pointer ptr points to a b = ptr[1] // b is 0x13 in LE and 0x12 in BE ... |
The code is changed as follows to make it endian-aware for porting.
#define BIG_ENDIAN 0
#define LITTLE_ENDIAN 1
int a = 0x11121314;
char b, *ptr;
...
char endian() {
short t = '0x0001;
return *((char *) &t); //return 00 for BE and 01 for LE
}
...
ptr = (char *) &a; // pointer ptr points to a
if (endian() == BIG_ENDIAN) b = ptr[1]; else b=prt[2]; // b is 0x12 in BE and LE
...
|
In this case, the endian() routine is used to detect endianness at run time. This is necessary for a bi-endian machine which supports both LE and BE data storage models dynamically. However, a price in performance is paid for the flexibility in performing runtime checking. It is desirable in porting to AIX, that conditional compilation, by predefining data storage model of LE or BE, be used to avoid performance penalties at runtime.
A better solution to the above problem would be to use an endian-neutral solution.
/* * Macro to get bits 16-23 (in terms of the significance of bit positions) from * an integer value done by shifting the bits down to the zero bit position * and then anding the most significant 24 bits off. */ #define INTB16TO23(a) ((a >> 16) & 0xff) ... b = INTB16TO23(a); // b is 0x12 in BE and LE ... |
In this case, since the code wanted bits 16-23 to be stored in b, using the shift operation lets the processor handle the multibyte data as a unit and perform the appropriate operations.
Another case of endian dependency comes from referencing multiple data elements as a single, large data element, as illustrated in the next code example.
short a[2]; int b; ... a[0] = 0x1112; ... a[1] = 0x1314; ... b = *((int*) &a[0]); // b is 0x11121314 in BE and 0x13141112 in LE ... |
Data type mismatch can also occur when using a union data structure. Union allows variables with multiple data elements having different types to share a common storage area to save memory. But LE and BE can see different data values if the same storage area is used as one data type for writing and the other for reading or vice versa.
union short_or_int {
short a[2];
int b;
};
short c;
...
short_or_int.b = 0x11121314;
c = short_or_int.a[0]; // c is 0x1112 in BE and 0x1314 in LE
...
|
At issue, again, is that LE and BE address the short data short_or_int.a[] in the union in opposite orders, although the integer short_or_int.b remains the same in the two storage models.
Overlaid Data (with Bit Fields)
In some code, overlaid data, which has more than one data type in a data element, may be used to encode multiple pieces of information within a data element to save memory.
For example, it is typical that a descriptor data structure (in device drivers) uses a single word for both flags and a pointer. One possibility is that a descriptor word contains flags in the most significant byte and a 16-bit or 24-bit pointer (address) in the least significant bytes.
Another example is that a word, e.g., int, can be used to encode data for efficient use of memory space. The next code example shows a 4-byte word used for encoding personal data.
struct personal_data{
unsigned age:7; // age from 0 to 128
unsigned height:7; // height from 0 to 128
unsigned gender:1; // male / female
unsigned pad:17; // aligned to a word boundary
};
|
No changes are required if this structure is not used as an interface between entities that are different in endianness and if the data is referenced by the appropriate tags. If the data is not referenced by the appropriate tag, but is instead referenced by overlaying another type, then problems similar to the previous section can occur. These are easily handled by using the real tag for the structure element or using a more generic method of referencing the data.
The problem with using the bit-field structure as an interface between entities with different endianness is that not only do the bit-fields need to be reversed, but the data units subdivided by bit-fields may need to be byte swapped to get a successful conversion.
To refer to the same encoded data in our example, the data structure needs to be changed, as follows, in porting from a BE to a LE machine.
struct personal_data{
unsigned pad:17; // aligned to a word boundary
unsigned gender:1; // male / female
unsigned height:7; // height from 0 to 128
unsigned age:7; // age from 0 to 128
};
|
After swapping the positions of the bit-fields within the structure, the whole integer would have to be byte swapped to get a value that could be used on the BE systems. The reversals are required due to the way our compilers generate the bit packed structure. The gcc compiler on a LE platform packs from LSb to MSb. The gcc compiler on a BE platform and the AIX compiler generate from MSb to LSb. So, in this example, we reverse all the fields so that the LE compiler while packing from LSb to MSb generates a structure that is packed from MSb to LSb like the BE compiler.
When looking closer at this code example, however, you'll note that the reason for the code change in porting is for sharing data in between LE machine and BE machines-data stored by a machine is shared by an opposite endian machine. Though bit fields are stored and referenced in opposite orders on a LE and a BE machine, they should not care if each bit field is addressed as defined. Note that one exception is when a bit field is used to map data for interface purposes and that interface requires a certain data format.
Another class of endian problems is code that is used as an interface between systems of varying endianness; for example, device drivers that use BE data that is byte swapped to LE data for use with a LE device/adapter. Also, the TCP/IP/UDP/RPC protocols require that data be sent in network byte order or BE. These are examples of canonicalizing data. The idea is that an interface exists that has defined byte ordering for the data used by that interface. In the device driver case, the PCI device defines LE as the canonical form in most cases. The networking code has chosen BE as its canonical form.
In general, this is a problem for communicating between devices (device driver to device/adapter interactions), network communications, or applications that share data that is granulized in chunks bigger than a byte.
These problems are typically handled by the application or data sender canonicalizing the data. The data sender usually performs some operations on the data to convert the data to the canonical form and then sends the data. The data receiver reads the data and performs some operations to convert the data from canonical form to a usable form. In the case of the networking code, the data receiver may be either LE or BE.
For example, IPv4 addresses and TCP port values in the TCP/IP header are manipulated as 32-bit unsigned integers and 16-bit unsigned integers, respectively. These need to be in host endianness (meaning the endianness that the system is running under) because math operations are performed on them. These need to be converted to BE before sending and must be converted from BE when receiving. To do this conversion, the code defines a set of routines that take a value and convert from host endianness to BE form or vice versa. In fact, these are POSIX defined. They are the htonl, ntohl, htons, and ntohs routines (s refers to short and l refers to a 32-bit quantity).
The application programs must choose their own canonical form, decide that data will not be shared, or provide utilities to convert between the forms. XDR (eXternal Data Representation) is one of the protocols that provide a canonical data format for sharing data across heterogeneous systems. At this time, there is no plan for sharing system data between an AIX BE system an AIX LE system.
Endianness issues in interfacing to an external I/O device can be resolved by various hardware and software solutions-which complicates the solutions in porting device drivers from a PowerPC to an IA [Intel architecture]or Alpha system. Though PowerPC supports the BE data storage model, its I/O busses, whether IBM's own MicroChannel or the latest PCI, are LE-based. In RS/6000 systems, the I/O controller, which is the bridge between system bus and its I/O buses, provides a data steering function to convert data from LE to BE (and vice versa) in reading from or writing to a device. This data steering function is applied to both DMA (Direct Memory Access) and PIO (Program I/O) or MMIO (Memory-Mapped I/O) data. In essence, the I/O controller treats data as byte streams such that byte 0 in the system goes to byte 0 in I/O, byte 1 to byte 1, and so forth. This brings up an interesting scenario-bytes in multiple-byte data need to be swapped before being passed to the I/O.
In AIX, several PIO macros are provided to reverse the byte order of the data used when interfacing with a BE device. (Most of the I/O devices are LE based; while there are BE based devices, the bus is LE.)
Most of the endian dependencies in code result from referencing data differently from its natural, defined data type. For example, addressing internal bytes of a multibyte data element, referencing multiple data elements as a single, large data element, packing multiple bit field in a data element, casting data, and using union data structure can potentially produce erroneous results and/or crash the system when the code is ported to an opposite-endian platform.
Another source of endian dependency is in assuming the endianness of the runtime platform. For example, AIX assumes that its processor supports the BE storage model. In interfacing with its PCI devices, which support the LE data storage model, AIX may call endian conversion routines to reverse the byte order in a data structure.
When porting to an opposite-endian platform, recompilation typically generates code with correct byte ordering. However, it is likely that some code with endian dependency will need to be identified (by inspection or using programming aids such as lint) and changed manually before all endian related issues can be resolved. In porting AIX code, the machine-independent code should be changed to avoid endian dependency; while the machine-dependent portion of the code may be rewritten to support LE if the endian dependency can not be resolved easily.
You can choose between changing the data structure and changing the code referencing the data structure in making code endian-neutral or endian-aware. It is generally a good practice to keep the data structure and change the code referencing the data.
The attributes of the LE and BE storage models are summarized as follows:
- The BE addresses individual bytes in a multibyte data element from Most Significant Byte to Least Significant Byte (from left to right), similarly to how data elements are referenced (from left to right).
- For LE, data elements and individual data bytes within a data element are referenced in opposite directions.
- The starting address of a data element in both LE and BE storage models remains the same across the two data storage models.
- Individual bytes within a multibyte data element are addressed in a reversed order between a BE and a LE data storage model.
- For single-byte data types, endianness is of no consequence-characters (or other single-byte data) are at the same (starting) addresses in LE or BE mode.
- Endianness is of no consequence if a data element is referenced consistently using the same data type as defined.
- The endian dependency becomes a potential problem if internal bytes and/or a proper subset of a data element are referenced individually and/or multiple data elements are referenced as an aggregated, single data element.
- Packing bit fields into a single data element can be problematic if the data needs to be stored to a persistent storage device shared by an opposite-endian machine. But it is not an issue if the data is not shared between BE and LE machines. The internal locations of bit fields in a data element are of no consequence between the two data storage models if the bit fields are referenced as defined. Though code will work correctly (in its endianness), comments associated with code may need to be changed to present the internal bit patterns in a reversed order.
The AIX architecture provides a well-defined set of conventions for parameter passing and function calls. Register usage is consistent for both 32-bit and 64-bit applications. The table below illustrates this standard usage:
If more than 8 parameters are required, the additional values are stored on the stack. The first 8 parameters which are passed in the general purpose registers are not stored on the stack.
Note that if a floating point parameter is passed to a function, it is also stored in a floating point register as well as in a general purpose regsister. The first FP parameter is stored in FP1, the second in FP2, etc. As an example, consider the fragment of C code below:
float fvar = 2.3;
printf( "x = %f", fvar );
In this case, the value of fvar would be stored in floating point register 1. In a 64-bit application the contents of general purpose register 4 will also contain fvar. (Register 3 contains the pointer to the format string.) The called function then has the option of accessing the parameter via either the float or general purpose register. Upon return from a called function, the value returned to the caller is passed in register 3.
AIX provides full enablement of 64-bit source code analysis in the version of lint shipped with the base operating system. Additionally , a version of the standard UNIX system lint tool, along with a complete set of supporting header files and libraries is available at http://www.sco.com/developer. A companion document that will help you to resolve 64-bit porting issues uncovered by the tool is also provided.
- C and C++ Application Development on AIX
- AIX Version 4.3 Migration Guide
- AIX Base Documentation
- Steven Zucker, Endianness in Solaris, SunSoft Report, Feb. 1998
- James R. Gillig, Endian-Neutral Software, Part 1, Dr. Dobb's Journal, Oct. 1994
- James R. Gillig, Endian-Neutral Software, Part 2, Dr. Dobb's Journal, Nov. 1994
- IBM Corp., AIX Kernel Extensions and Device Support Programming Concepts
- IBM Corp., POWERstation and POWERserver: Hardware Technical Information General Architecture
Gary R. Hook is a Senior Technical Consultant at IBM, providing application development, porting, and technical assistance to independent software vendors. Mr. Hook's professional experience focuses on Unix-based application development. Upon joining IBM in 1990, he worked with the AIX Technical Support center in Southlake, Texas, providing consulting and technical support services to customers, with an emphasis upon AIX application architecture. Residing in Austin since 1995, Mr. Hook recently transitioned from AIX Kernel Development, specializing in the AIX linker, loader, and general application development tools.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
