none
[UWP] [Desktop Bridge] Virtualization issues RRS feed

  • Question

  • Hi,

    I'm in the process of converting Zoom Player (zoomplayer.com) to a univeral windows app.  Zoom Player is a Win32 app that relies heavily on the DirectShow API.

    I have managed to successfully convert and run Zoom Player as an "AppX" application under Windows 10 aniv. edition.

    However, I have encountered several issues:

    1. When using the previously preferable folder structure ("C:\Program Files\Zoom Player" for static files and "C:\ProgramData\Zoom Player" for files that can be modified), I would expect the content of the virtualized "C:\ProgramData\Zoom Player" to always be virtualized, but if I try to write from within the app to "C:\ProgramData\Zoom Player", it tries (and fails) to write to the real folder and not the virtualized folder.
    2. When I try and list the content of the "C:\ProgramData\Zoom Player" folder it does seem to list and load the content of the virtualized folder, but if I try to delete a folder within this virtualized folder, for example "C:\ProgramData\Zoom Player\Skin\AlbaHD\", it fails.
    3. As I wrote in the introduction, Zoom Player relies heavily on the DirectShow API.  DirectShow filters get installed (correctly virtualized) as part of the initial installation, but these filters occasionally need to be updated and the user has a choice of optional components to install on top of that (7-zip for example).  This is done through an "Install Center" application that is part of the AppX package.  The problem is, any component the install center application installs on the system is not virtualized.  How can I get the "Install Center" application to run & install everything virtualized?
    4. Calling "ShellExecute" to run an EXE file (Zoom Player's install center app) fails (nothing happens).

    I would appreciate any insights into how to solve these issues.

    Sunday, September 4, 2016 8:26 AM

All replies

  • Hello Inmatrix,

    Based on here Supported UWP APIs for converted desktop apps

    The converted app does not need UWP picker, which seems means that the folder that you are trying to acess is not the virtualized folder. And as far as I know delete file in C:\ fodler is also restricted for desktop app. Can you give me a reason about why you need to do this in this folder? Maybe I can think about an alternative solution or maybe you can consider use a different folder. I will try to see if I can build a environment and test it tomorrow.

    Best regards,

    Barry


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, September 5, 2016 2:49 PM
  • Hi Barry,

    I'm not sure my issues were addressed.

    I was under the impression that a UWP app's disk access to certain folders is virtualized to maintain backward compatibility.  What I'm saying is that the virtualization process fails on disk writing for my application, the data is written to the real folder instead of the virtual folder.

    For example, when my app tries to write to "C:\ProgramData\Zoom Player" ("CSIDL_COMMON_APPDATA\Zoom Player"), I expect that under virtualization the saved data would be saved under "C:\Program Files\WindowsApps\ZoomPlayer_x86__63ghcm0aqanjp\Vfs\Common AppData\Zoom Player", but in reality, the data is still saved under the real path at "C:\ProgramData\Zoom Player", which breaks sand-boxing and backward compatibility for my App.

    I'm using WinAPI's "CreateFileW" function, which doesn't seem to be virtualized in my case.

    My other and more important issue is with DirectShow filters, how can I get them to install virtualized AFTER my App is already installed?

    Tuesday, September 6, 2016 8:11 AM
  • @Inmatrix,

    For the folder problem it seems it is reasonable, the document says after conversion file library will have the permission. So I think maybe you can give WinRT Storage library a try.(But please notice installed folder is readonly) For the DirectShow filter, I'm not so sure whether it is just a desktop software. If it is not installed when conversion then sounds like it's hard to update it to the virtualized container. I will keep on check it later to see if I can find any more details.

    Best regards,

    Barry


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, September 6, 2016 2:29 PM
  • Hi Barry,

    I used the 'Desktop Bridge' software to convert our Win32 installer to the AppX model.

    I'm not sure my issues are understood.

    I'm saying there's a problem with the 'Desktop Bridge' module, paths are either not being reported correctly to my application or they are not virtualized correctly (my application is allowed to create files in the real programdata path and not the virtualized path). I believe this is a bug, if it's not, I'm interested to know why this is happening and it can be fixed.

    My other issue is the ability to install additional components into the same virtualized container after the initial install. If this is not a possibility at the moment, I would like to recommend it as an important feature for future versions.

    Tuesday, September 6, 2016 2:43 PM
  • @Inmatrix,

    Yep I can understand your problem and I have some understanding here. Sorry for confustion and I will try to make our discussion clear.

    First of all, per my understanding, your problem is about the following and please correct me if I'm wrong:

    1. After conversion if you are trying to use classic desktop API you expect to load the virtualized folder but when you navigate to the folder "C:\Program Files\Zoom Player", it goes directly to the system's folder, not the virtualized folder, which in your mind is not the right behavior so you want to get the virtualized path.

    2. You want to install components to virtualized container when you've already converted your msi.

    I will try to describe my understanding here:

    See the following document:

    https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root

    "As a UWP app, your app is able to do the things it could do as a Windows desktop application. It interacts with a virtualized view of the registry and file system that's indistinguishable from the actual registry and file system."

    Maybe based on the above article, you are thinking that it is a converter problem.

    And I have checked some articles, like this blog:

    https://blogs.windows.com/buildingapps/2016/07/14/choosing-the-path-forward-for-existing-desktop-apps-4/#Voz3jv8XBTlso6O8.97

    See the following:

    "Once your app is deployed, the files that are part of the app package are laid down on disk in a locked down location. Only the system has access to write to the files in this directory. If your app needs to make changes to any of the files that it originally deployed, you will need to adjust the code to copy those files out to either the %appdata% or %localappdata% directory, and make changes to/read from the copy.

    Read more at https://blogs.windows.com/buildingapps/2016/07/14/choosing-the-path-forward-for-existing-desktop-apps-4/#ZZGCMSdhvACXBXtH.99"

    My understanding is that any desktop API to access File system will still go to your original system. Which means if you use desktop API to access C:\Program Files\Zoom Player you will go to this folder from your system. Not the virtualized directory. And we don't have the permission to access it. And the suggestion is to use %appdata% or %localappdata%

    Best regards,

    Barry


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.




    • Edited by Barry Wang Thursday, September 8, 2016 1:48 AM
    Tuesday, September 6, 2016 3:29 PM
  • Hi Barry,

    Once again, no.  This is not what I'm trying to do. I am trying to write under the %appdata% folder, not the 'program files' folder.

    I am trying to write to the virtualized "C:\ProgramData\Zoom Player", NOT "C:\Program Files\Zoom Player".

    I call the WinAPI function "GetWindowsSystemPath(CSIDL_COMMON_APPDATA) expecting to get the virtualized path of "C:\ProgramData\Zoom Player" but instead get the real path.  And when later trying to write to that path, any data written is written to the real path and not the virtualized path.

    So either calls to WinAPI's "GetWindowsSystemPath(CSIDL_COMMON_APPDATA)" are not virtualized or calls to the WinAPI's "CreateFile" function are not virtualized.

    In either case, I would call it as bug in the virtualization process as the AppX model should virtualize all writes to the %AppData% folder.

    Thursday, September 8, 2016 7:28 AM
  • @Inmatrix,

    I need to track this case, does Rob's description from the following post:

    https://social.msdn.microsoft.com/Forums/en-US/284bfaec-392a-4775-864f-225543ca9b86/uwp-desktop-bridge-local-app-data?forum=wpdevelop

    "The call to SHGetFolderPath in the installer runs in the installer context when being converted, so it gets captured into the package the same as any other file written by the installer during conversion. SHGetFolderPath(CSIDL_LOCAL_APPDATA) gets mapped to the ApplicationData.LocalFolder only when the converted app is already installed and running."

    Also helps for you to understand the scenario on this post?

    Best regards,

    Barry


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, September 23, 2016 1:27 AM