# User Changes 2.2.2

Below you can find a list of intentional changes between the the 2.2.0 release and the 2.2.2 release which can change the behaviour of previously working code, along with why these changes were performed and how you can adapt your code if you are affected by them.

## All systems

### Char to WideChar conversions and vice versa

• Old behaviour: Type conversions between chars and widechars did not cause any translations of the data.
• New behaviour: A char to a widechar conversion or vice versa now triggers the widestring manager, and converts the data from ansichar to widechar or the other way around. If a converted widechar is not representable in a single char, the result of the conversion is always '?'
• Example: char_var:=char(widechar_var); used to put the lower 8 bits of widechar_var into char_var, while now the widestring manager is called to translate widechar_var from UTF-16 to the active code page.
• Reason: Bug report 7758, and consistency with conversions between shortstrings/ansistrings and widestrings.
• Effect: If you previously typecasted chars to widechars or the other way around (possibly via parameter passing or assignments), these type conversions will now cause the data to be translated.
• Remedy: If you do not want any translation to be performed, add an additional type conversion to an integer type in between, e.g. char_var:=char(word(widechar_var));

### Typecasting ordinal constants to complex types (records, arrays, sets)

• Old behaviour: It was possible to typecast ordinal constants into records/sets/arrays at compile time.
• New behaviour: Such type casts now always give a compile time error.

### Unhandled exceptions on Mac OS X/Intel (run time error 207)

• Old behaviour: Previous FPC versions did not enable arithmetic exceptions for the SSE unit of Intel Macs. This SSE unit is used by most of the system libraries to perform floating point calculations. This means that floating point errors in the system libraries were silently ignored (just like they are for C programs, as these exceptions are disabled there by default as well).
• New behaviour: FPC now enables all SSE floating point exceptions at startup. The result is that some (mostly GUI) applications now terminate with a "run time error 207".
• Reason: The FPC programming model includes reporting all floating point exceptions as they happen. Many existing programs expect this, since this is also the behaviour on other platforms.
• Remedy: Add the math unit to your uses clause and add the following statement at the beginning of your program: SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, exUnderflow, exPrecision]). Note that this will disable floating point exceptions in all code, not just in the system libraries. The reason this is not necessary on PowerPC is that the macpas unit, which is automatically included in any program using one of the Common Pascal Interfaces units such as MacOSAll, already contains code to disable the exceptions for PowerPC. Similar code for Intel will be added to that unit in a future release, so you will not have to add it yourself anymore (see http://bugs.freepascal.org/view.php?id=11516).

## WinCE

### Windows unit

• Old behaviour: All WinCE API interfaces were contained in the Windows unit.
• New behaviour: The Windows unit contains only the basic API interfaces. Other API interfaces are contained in separate units like aygshell, commctrl, shellapi, etc.
• Reason: Make the WinCE unit names consistent with the Win32/64 unit names.
• Remedy: Add additional units to uses clause to fix compile time errors. You can protect this change with {\$ifndef VER2_2_0} for backwards compatibility purposes.