AIR 2 includes, among other new APIs, the ability to launch and communicate with sub-processes via the NativeProcess API. The API can launch executables bundled with your application or installed separately. On Windows, it turns out that the latter can be trickier than expected when running on a 64-bit system.
64-bit versions of Windows can run both 32-bit and 64-bit processes. This makes it possible for users to transition to 64-bit over time, keeping their 32-bit applications with them until 64-bit versions are available. This is why AIR applications, which for now remain 32-bit applications, can run on 64-bit versions of Windows. Most of the time, this works seamlessly.
In order to ease porting 32-bit applications to 64-bit Windows, 64-bit applications continue to use the %windir%\system32 directory for 64-bit libraries. This is great for 64-bit applications, which continue to work, even with explicit references to this directory. However, it would break all 32-bit applications, as they can’t load the 64-bit libraries.
To work around this, Windows automatically redirects most accesses to this directory from 32-bit applications running on 64-bit Windows to a different location: %windir%\SysWOW64. (WOW64, despite its name, is the subsystem that runs 32-bit applications on 64-bit Windows.) Again, most of the time this works seamlessly.
This approach will if you’re trying to launch an executable from %windir%\system32 if there is no 32-bit version of the same executable in %windir%\SysWOW64. In this situation, you can see in Explorer that the executable exists in %windir%\system32, but when you check the same location via your 32-bit application, the file, due to redirection, will not be present. If this happens to you when using the AIR NativeProcess API, you’ll get an error (3214) that the executable you’re trying to use is invalid.
The workaround to the workaround? Starting with Windows Vista, you can force direct access to the 64-bit directory by using %windir%\sysnative. It’s not a real directory, but it is recognized by the redirection logic and pointed to the real %windir%\system32 directory. For Windows XP, you’ll have to resort to system calls to turn off redirection. For a complete description, see the MSDN File System Redirector documentation.