{"id":91661,"date":"2015-09-04T07:00:00","date_gmt":"2015-09-04T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/20150904-00\/?p=91661\/"},"modified":"2019-03-13T12:19:12","modified_gmt":"2019-03-13T19:19:12","slug":"20150904-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20150904-00\/?p=91661","title":{"rendered":"Using an intermediate library to make the main library retargetable"},"content":{"rendered":"

A customer was developing a static library targetting both Windows XP Win32 applications and universal Windows apps. (This was before Windows XP reached end-of-life.) <\/p>\n

\n

Our library uses critical sections, but unfortunately there is no version Initialize­Critical­Section<\/code> that is available to both Windows XP Win32 applications and universal Windows apps. Universal Windows apps must use Initialize­Critical­Section­Ex<\/code>, but that function is not available to Windows XP Win32 applications. Is there a way to dynamically target both Windows XP Win32 applications and universal Windows apps, pass WACK validation, and still have one library? <\/p>\n

We thought we could use Get­Module­Handle<\/code> and Get­Proc­Address<\/code> to detect which platform we are one, but Get­Module­Handle<\/code> is not allowed in universal Windows apps, so we’re back where we started. <\/p>\n

Are we stuck having two versions of our library, one for Windows XP Win32 applications and one for universal Windows apps? <\/p>\n<\/blockquote>\n

Runtime dynamic linking (Load­Library<\/code>, Get­Proc­Address<\/code>) is not permitted in universal Windows apps, which means that for universal Windows apps, you must have an entry for Initialize­Critical­Section­Ex<\/code> in your import table. But if that function is in your input table, then it won’t load on Windows XP. <\/p>\n

(You might think that you could have a second library to be used by Windows XP clients that implements the Initialize­Critical­Section­Ex<\/code> function. Unfortunately, you will run afoul of dllimport<\/a>.) <\/p>\n

You are going to have to have separate libraries at some point, but you don’t have to have two versions of your library. You could build your library to call, say, Contoso­Initialize­Critical­Section<\/code>, and have two helper libraries, one for Windows XP Win32 applications and one for universal Windows apps, each of which implement the Contoso­Initialize­Critical­Section<\/code> function in a manner appropriate to the target. <\/p>\n

In other words, people targeting Windows XP would link to ContosoCore.dll<\/code> and ContosoXPSupport.dll<\/code>. People writing universal Windows apps would link to ContosoCore.dll<\/code> and ContosoStoreSupport.dll<\/code>. <\/p>\n

This approach has a few advantages: <\/p>\n