As @RohitGupta mentions, installing the 32-bit DLLs in SysWow64 is standard procedure, but for your app to be using the ones in System32 is wrong. Normally Windows will make a local directory substitution when it finds that it is running a 32-bit application, but in this case apparently it is failing to do that. The most common reason in my experience for that to happen is if the base application is CPU-agnostic, running as managed code in the .Net environment for instance. Because the application does not have a bit width requirement, it is run with the 64-bit version of the framework for efficiency, and so will try to link with the 64-bit DLLs. You need to contact the manufacturer of the application and confirm whether it is using the .Net framework, or some similar virtualization scheme, and get a version of the application that is set to use the 32-bit DLLs - the .Net framework has a bit flag that can be set in the application header to restrict it to using 32-bit DLLs and COM objects.
Edit: For the .Net framework, the tool that sets the necessary flag bit is called corflags.exe
and should be available with any of the Windows .Net developer packages from Microsoft. Syntax is corflags <executablename> /32bit+