locked
Universal DLL for Windows Store and Desktop applications

    Question

  • Hi

    I would like to create a DLL which provides communication API with a driver. The DLL will be used only on Windows 8. I would like to support both Windows Store and Desktop applications. The best case is a single DLL, supporting both, but as far as I know there are restrictions regarding the subset of Win32 functions that could be used in DLLs for Windows Store apps. 

    For communication with the driver I need: 
    - CreateDeviceAccessInstance (use of CreateFile will not pass MS verification)
    - something like SetupDiGetClassDevs/SetupDiEnumDeviceInterfaces - could that be used in Windows Store app? If not am I able to use in my DLL Windows::Enumeration:Devices functions (which is a part of Windows RunTime)?
    - IDeviceIoControl (use of DeviceIoControl will not pass MS verification)

    Could this be done in a single DLL or do I have to make some sort of wrapper for Windows Store app?
    Another question is what is the difference between Win32 DLL and DLL (Windows Store apps) template in Visual Studio 2012?

    Thanks,
    Tomasz


    • Edited by Tomasz N Friday, December 7, 2012 5:13 PM
    Friday, December 7, 2012 5:11 PM

Answers

  • In general it is possible to write a DLL that is consumable by both Win32 desktop applications and Windows Store applications. The main challenges are that

    (a) the DLL cannot use any import that is not considered safe for Windows Store apps or the entire package that tries to use it will fail the WACK verification test

    (b) Not all new Windows 8 APIs available to Windows Store apps are also available for use by Win32 desktop apps. Many do, but you need to check on a case-by-case basis.

    (c) Making a DLL that both passes WACK and works 'down-level' can be particularly challenging. You seem to be fine with a Windows 8 only Win32 desktop and Windows Store version.

    While it doesn't speak directly to the APIs you mention, there are some general recommendations here in this Dual-use Coding Techniques for Games article.

    • Marked as answer by Jesse Jiang Thursday, December 20, 2012 6:32 AM
    Friday, December 7, 2012 7:19 PM

All replies

  • In general it is possible to write a DLL that is consumable by both Win32 desktop applications and Windows Store applications. The main challenges are that

    (a) the DLL cannot use any import that is not considered safe for Windows Store apps or the entire package that tries to use it will fail the WACK verification test

    (b) Not all new Windows 8 APIs available to Windows Store apps are also available for use by Win32 desktop apps. Many do, but you need to check on a case-by-case basis.

    (c) Making a DLL that both passes WACK and works 'down-level' can be particularly challenging. You seem to be fine with a Windows 8 only Win32 desktop and Windows Store version.

    While it doesn't speak directly to the APIs you mention, there are some general recommendations here in this Dual-use Coding Techniques for Games article.

    • Marked as answer by Jesse Jiang Thursday, December 20, 2012 6:32 AM
    Friday, December 7, 2012 7:19 PM
  • Now that Windows Universal Apps have been released, how does this work?  Are there any resources for helping us develop component dlls for Windows Universal?  How can I convert WinRT DLL and WinRT Runtime Component projects to the new Universal projects?
    Wednesday, May 14, 2014 2:02 AM
  • universal apps don't affect this.

    They allow the same runtime source to be used for store and phone. They still cannot call Win32 API which aren't valid for Windows Store apps.

    What can help are brokered runtime components which can allow a side loaded Windows Store app to communicate with a desktop app.

    Wednesday, May 14, 2014 2:26 AM
    Owner
  • > They allow the same runtime source to be used for store and phone

    I was already doing that, using #ifdef.

    In fact, I build dlls for Windows desktop, WinRT, and Windows Phone from basically the same source code, using #if def.  How does Universal change that / help me?  Can I now build one dll for all platforms?

    > brokered runtime components

    I don't think that is at all what I want.  I am in no way trying to communicate with a desktop application from a Windows Store application.

    I have close to 100 Windows Runtime Component DLLs (mostly written in C++/CX, but some in C#).  Currently I build all of them twice, once for WinRT and once for Windows Phone.  The source code is 90% the same, using some #ifdef in places where the WinRT and Windows Phone SDKs are different.  My question is, how does Windows Universal affect this?  Am I going to be able to build one dll that works for both?

    Wednesday, May 14, 2014 1:45 PM
  • No, Universal apps allow sharing source more easily than you were doing, but you'll still need separate binaries. There is more overlap in the code so you'll need fewer #ifdefs and there are organizational improvements by using the shared project.

    They allow more sharing of code between Windows Phone and Windows Store apps since the new Windows Phone Runtime apps run almost the same code as Windows Store apps. There are still a few features which are Phone or Store only and so need separate projects, and it is likely that the apps will use different UI for the different form factors.

    --Rob

    Thursday, May 15, 2014 4:16 PM
    Owner