I'm working on a project where JUCE would be a perfect candidate, but Windows Store support is crucial. Is it possible to use a subset of JUCE while maintaining Windows Store compatibility? I've seen the Direct2D related files in the native folder, but didn't delve into the code. What's the state of this code? I guess switching to Direct2D would be the main obstacle to overcome? Since the Win32 file API is allowed (using CreateFile2) although sandboxed, I suppose file IO would be a minor problem and WASAPI is already in there.
Thanks, Julian. We'll have to look for another solution, then. Hopefully, we'll see Window Store support in JUCE one day... :) I don't think it's really that much work if you get the Direct2D back-end working. That would probably give an additional performance boost as well (e.g. quicker path rasterization).
Understood. I’ve done some outline experiments myself with UWP apps, with C++/CLI front-end and C++/CLI audio adaptors, using a large compiled-in C++ library, and it wasn’t insurmountable.
Anyhow, I’m planning a major product development cycle that will need to go live in 6-9 months. I’m considering various platforms for this.
Windows 10 store deployment is critical for me.
So, if you were able to tell me that you were aiming to have this “live” within say 6 months, and had good confidence in that sort of timescale, that’d be OK I think.
I’m sure I won’t be the only developer affected by this
Is there any public statement that the Juce team can make, even if broad-brush, as to when this might get resolved?
We’ve been using Juce for many years now, and have used Juce to create several apps and plug-ins for both macOS and Windows. The macOS apps are sold through the Apple Mac Store, as you’d expect.
It’d be great to use Juce for a major new development, but deployment of the Windows version through the Windows 10 store is critical for us.
Being able to distribute our apps through the official App Stores is essential to our business!
Thanks for letting us know of your interest for UWP support. It’s unfortunately not on our immediate roadmap but we’re making progress towards a starting date. It looks unlikely that we’ll support it in 2017, but perhaps 2018.
Bump. Paying customer here. Unfortunately, Microsoft is pushing us down the UWP road for future Win32 applications. It’s not possible to sell on Windows Store without a UWP app, and JUCE is currently a bottleneck to getting stuff to work on UWP. My hope is that once you dig into the compiler options, then it won’t be as painful as it seems to port over to UWP.
I’m afraid it’s much more than a few compiler options!
Most of the conventional Win32 APIs are unavailable. Things like
All filesystem interactions
Networking
Threading (this one isn’t too drastic)
Named pipes, sockets (might not be possible at all)
Windowing and events (drastic)
The embedded browser
Graphics (the partially completed Direct2D renderer will help here)
need to be completely rewritten, and it’s not just a case of changing function names - the UWP equivalents (where they exist!) are all asynchronous, so require additional infrastructure to support that. The above list is also not exhaustive, I’ve just picked out some important bits.
It’s many months of full time work to achieve even basic compatibility.
I’ve written a couple of UWP apps. The biggest pain-point was that many common APIs are now forbidden and actions like accessing the filesystem and displaying dialog boxes must now be done asynchronously, so you have to rewrite those parts. If your c++ chops are not up to date on topics such as concurrent tasks, continuations and lambdas, it can be heavy-going at first.
So you’re actually forced to make the switch to C++/Cx for the filesystem stuff? That seems contradictory to the links I provided…
Now I’m really curious about how porting can be achieved. I’ll have to give it a go in small pieces some day for the helluvit - I’ve been wanting to deploy and tinker with UWP apps on my XboxOne, basically revisit the platform from when I was a console dev!
Regarding the file system, you can read and write using the CreateFile2 and it’s related calls only within the app sandbox. Otherwise, you need to call the native file chooser which creates a StorageFile object with the right access tokens. As far as I know, there’s no way to pass over a security token so that you can use it to open a file outside the sandbox environment with CreateFile2 (IMHO a silly decision by Microsoft). It would be possible to create interop code to stream from and to a StorageFile using the input / output stream classes in JUCE. I just did something similar for a project (not the JUCE streaming classes, though).
I thought it was possible to sell any win32 app on the windows store nowadays using the Microsoft Desktop Bridge. That certainly should work with Juce apps as well.
