The xIUA code is designed to help users interface to ICU. Because of this it is dependent on ICU and its headers. You can for example use portions of the code without ICU but if you do all the definitions that are included for ICU will have to be changed to make the code work without ICU. One of the advantage of ICU it that it will tailor headers like platform.h for each flavor of Unix to provide a consistent development environment.

Be sure to use ICU 1.8.1 or later. xIUA 3.0 depends on features that are not in previous releases of ICU. xIUA 3.2 also supports ICU 2.0. We have been able to remove substantial amounts of code that was in prior versions of this product because of code that is now integrated into ICU.

To compile xIUA you must include the ICU headers. The easiest way is to add icu/include to the include path. Even though the actual headers are in the unicode subdirectory, you must point to this path because the headers are included with the subdirectory name such as: #include "unicode/utypes.h"

ICU uses the unicode subdirectory to put all of the headers that can be used by application programs. Do not use any of the other ICU headers. Also do not use any of the internal ICU functions even if they are defined in these headers. The private functions start with uprv_

xIUA expands some of the ICU definitions. ICU defines UChar and UChar32. xIUA adds UChar16, which is the same as UChar and UChar8, which is defined as unsigned char. XIUA_DateFormat expands on ICU's UDateFormatStyle by adding XDTANY. This is used by the xIUA date parsing function to indicate that all four formats should be tried until the parsing succeeds. The remaining values are identical so that they may be used directly by ICU.

xIUA uses ICU error codes. You should check these error codes. The xiua_CurrentStatus function will set an ICU error code pointer to point to the error code field used by xIUA. xIUA uses these error codes differently from ICU. The ICU code is designed so that once an error is detected, the entire sequence of operations is flushed because each function first tests the error status field and functions as a non-operation if it has an error condition. Because xIUA emulates many common C library functions and these functions may set an error code but never test for previous errors it does not implement any function flush based on previous errors. This technique was used because it is more compatible with many existing applications. This is easy to change in your version of xIUA by adding an error status test to each function if you want to take advantage of the ICU programming style. This is one of the reasons why xIUA provides a pointer to the error status field and does not just return the status code.

One client minimized the application coding changes to a multi-byte enabled application by using the same APIs as their old interface module and used a call back system to report and log errors.