0

I'm trying to build a UWP app. I need to include a number of existing (non-managed code) C++ libraries in the app. My understanding of the best way to do this is to wrap all these in a Windows Runtime Component.

After some difficulty, I managed to get an app to build, linking to all the existing C++ code through the Windows Runtime Component. Some of these libraries have dependencies on pre-compiled Win32 .dlls. So I also recompiled these from source with Visual Studio 2015, for ARM architecture.

When deployed on an windows mobile platform, I get the following exception:

'System.IO.FileNotFoundException' in System.Private.Interop.dll; Unhandled exception at 0x77A3DF95 (combase.dll)

This doesn't help very much. But based on this SO question: System.IO.FileNotFoundException: Could not load file or assembly 'X' or one of its dependencies when deploying the application, my hypothesis is that despite building the dlls for ARM, one of these still has a dependency somewhere to a Win32 dll that, predictably, cannot be found (hence FileNotFoundException).

When I load each of the dlls built for ARM in Dependency Walker, I don't see any dependencies on Win32, with the exception of one of the dlls I built for ARM from source, icuuc56.dll, which I can see it has has kernel32 (advapi32) as a dependency. My understanding is that windows mobile would not provide these OS dependencies (hence the FileNotFoundException?). And that the dynamic loading of this particular Win32 dependency is causing the app to crash.

I want to build the ARM version of icuuc56.dll without it linking to Win32 libraries. At least so I can identify which parts of ICU4C rely on Win32 function calls. But maddeningly, when building for ARM, I cannot prevent the linker from linking to %(AdditionalDependencies), which includes the Win32 libs.

Have I interpreted the problem correctly? If so, my questions are:

  1. Why does ICU4C when targeting ARM build in the first place, if it depends on Win32 dlls?

  2. How can I prevent linking to Kernel32 at build time, so that I can identify what parts of ICU4C make function calls that cannot be done on ARM.

  3. Is there an OS-provided equivalent to ICU4C that can be used on UWP instead?

UPDATE: As #ifdef WIN32 resolves to true, platform.h of ICU4C set's the following

#define     U_PLATFORM_USES_ONLY_WIN32_API   1
#define     U_PLATFORM_HAS_WIN32_API   1

If I try and fiddle with the platform preprocessor definitions, the best I can get is for it to use for example tzset instead of _tzset. Which is not going to be available either (I presume).

Is there any way ICU4C can be built for UWP without completely rewriting it? It can be compiled for iOS and Android, after all. I'll take a deeper look at https://sourceforge.net/p/icu/mailman/icu-support/thread/4FEDF14C.3050404@icu-project.org/ but this looks to be a slightly different issue.

Community
  • 1
  • 1
rod
  • 3,403
  • 4
  • 19
  • 25
  • In the preprocessor definitiions add WINAPI_FAMILY=WINAPI_FAMILY_APP. You'll now automatically get a compile error for any winapi function that is not available. I suspect [this is relevant](https://sourceforge.net/p/icu/mailman/icu-support/thread/4FEDF14C.3050404@icu-project.org/). – Hans Passant Mar 15 '16 at 15:12
  • Aha! That was very useful. I have found that the issue is around a small number of function calls around timezones and system time (```_tzset```, ```getenv```, ```GetThreadLocale```, ```GetACP```). The specific version of these function calls that gets used is defined as those because WIN32 and _WIN32 is set to true. I need to find an alternative to making these calls. I'm not sure how. – rod Mar 15 '16 at 15:51

0 Answers0