
Win32 and .NET desktop apps can now be published in the Windows Store - BogdanMitrache
https://blogs.windows.com/buildingapps/2016/09/14/apps-built-using-the-desktop-bridge-now-available-in-the-windows-store/#zpxPJYYbMKrUf3vL.97
======
flohofwoe
So if I understand it right, this is basically running apps in a
Win32-emulator/sandbox where all 'unsafe' Win32 file and registry accesses are
redirected into sandboxed locations.

I wonder why MS didn't go this way from the beginning instead of pushing that
Frankensteinian half-desktop/half-mobile monstrosity called WinRT^H^H^H UWP on
us.

The UWP application model has been modelled after the (now 10 years old)
iOS/Android app model, created in a time when mobile devices had a lot less
memory and performance than notebooks. Win32 is a pretty bad desktop API, but
UWP somehow managed to be even worse because it is an outdated mobile OS
ported back into the traditional desktop environment, and everything that is
not 'mobile' (mouse, keyboard, window management, ...) has been implemented as
an afterthought. For games (which I guess are the main usage for old-school
desktop computers now), UWP is an especially bad fit.

I'm all for increasing security by running applications in a sandbox with
granular permissions. However I am against 'walled gardens' curated by
platform owners, this closed-platform model kills innovation. Unfortunately
these two different things got thrown into the same pot by Apple, Google, and
now MS. UWP somehow manages to combine the worst aspects of a dead app shop, a
dead mobile platform, and walled-garden power phantasies.

All of these problems aren't fixed with the Win32 sandbox though, I'm pretty
sure this is just an emulation layer on top of UWP, so all UWP limitations
would still apply.

~~~
youdontknowtho
Wow.

UWP isn't a mobile OS ported to Windows. The whole WinRT is an OS and WinRT is
an API set confused things. Forget that there was an ARM tablet. WinRT means
the Windows Run Time. It's a set of API's that are built with the Windows OS.
The "they made it mobile" part was really a side effect of trying to move to a
more managed execution model where the OS took a more aggressive approach to
managing the execution of an app over it's lifetime.

That has certainly needed improvement since it has been released. The WinRT
API set was and is limited to a set of API's that are governed by a security
broker. Applications are intended to have an identity, that is a SID, and
execute in a very tight sandbox ala Chrome or Edge. It's a good model that
makes some of the traditional malware vectors very hard to exploit. (You can't
call LoadLibrary, for instance.)

OK. Set that aside for a moment. The desktop bridge uses technology called
App-V that has been available to enterprise customers for a long time. It lets
you run an installer and it watches all of the things it does to a clean
system. It then bundles all of those things into a single file. It provides
shims to your code that, for instance, will intercept your attempt to write to
a global part of the registry and directs it to a registry hive kept in the
file.

What they did in the anniversary edition was include parts of AppV in Win10,
and they built a set of technologies that help with the process of
"sequencing" a Win32/.Net app. Your application still runs just like it used
to. There is no emulation. If you want to use API's that are available in UWP
you need to follow some guidance on adopting them. Some are less invasive than
others. Its a tradeoff, but it's one that you get to control as a dev and you
can share a bulk of your code between Win7 and Win10 builds that use the
strengths of both platforms.

So, its a sandbox, but not an emulator. The AppX installation method is more
like the ".app" model in desktop OS X where you have a bundle of things for
your app. There are also new security model things that you can adopt over
time to gain access to new functionality.

You DO NOT have to install AppX packages from the store. You can download them
from the Web and double click on them or use powershell to install them. The
store is separate from the app packaging tech and API set.

Your comment reads like someone who doesn't use Windows enjoying some
schadenfreude at the trouble they have had over the last couple of years.
You're going to need to get over that. They are getting their shit together in
a big way. Yes their mobile platform failed. They have admitted that and moved
on. They produce a lot of software for Android and IOS. You can develop native
Linux software with Visual Studio now. They contribute to Linux, Mesos, and
Docker. .Net is open source. They contribute to FeeBSD. What more do you want?
No one is making you use their stuff. You have never had more options. Why do
you feel like that for you to be doing better other people have to be doing
worse?

~~~
flohofwoe
I'm using Windows (and OSX, and Linux) everyday and recently started (but
didn't finish because of UWP's weirdness) porting my 3D coding framework over
to UWP. The same framework is also running on Win32, OSX, Linux (incl RaspPI),
iOS, Android, HTML5 and PNaCl, so I do have some multi-platform experience. Of
these platforms, and with the exception of Android NDK, UWP is the most
painful to port to (if you're interested in the details:
[http://floooh.github.io/2016/08/20/uwp.html](http://floooh.github.io/2016/08/20/uwp.html)).

I want Windows to remain the dominant gaming platform. But for this, UWP is
completely heading into the wrong direction.

~~~
benaadams
How does a conversion of one of your Win32 exes run with the new system?

Can do a manual convert ([https://msdn.microsoft.com/en-
us/windows/uwp/porting/desktop...](https://msdn.microsoft.com/en-
us/windows/uwp/porting/desktop-to-uwp-manual-conversion)) or use the tool to
create the appx then double click to install, I believe...

~~~
flohofwoe
I'll try that as soon as I'm back on my Win10 laptop. If this works well it
will be highly preferable over an UWP port, because too many compromises have
to be made to run games on top of UWP.

What I'd actually like to see is a new application model and set of APIs 100%
focuses on games, in the original spirit of DirectX. The required API
footprint for games is minimal and should be easy to sandbox.

None of the existing desktop or mobile operating systems are particularly well
suited for games, writing window system glue code and input event handling is
terrible everywhere outside of the game console world.

Only Microsoft cared about that in the early days of DirectX and before it's
gaming focus shifted to the Xbox and Xbox360. We need a new DirectX initiative
which fixes the flaws of UWP for games. We don't need one generic solution
which is supposed to work for all application types, we need a couple of
highly specialised APIs and specialised application models. As Windows8 has
shown, one-size-fits-all doesn't work.

~~~
youdontknowtho
I think that's the direction things are heading. If you look at the compositor
API's they are trying to make the whole XAML layer easier to interop with DX
because DX is where the perf and flexibility are.

~~~
WorldMaker
Right, a big push to the XAML stack with the Anniversary Update was a lot of
beefy pushes to what's called the "Visual Layer" [1]. A lot of the focus seems
to be on making sure that you use high level XAML components and low level
DirectX code side-by-side in the same windows.

[1] [https://msdn.microsoft.com/en-
us/windows/uwp/graphics/visual...](https://msdn.microsoft.com/en-
us/windows/uwp/graphics/visual-layer)

~~~
youdontknowtho
There is a guy named Kenny Kerr that produced a library called "Modern
Windows" or something like that. He has a PluralSight course...I think at
least part of it is on youtube...where he demonstrate using it.

His stuff is just worth watching anyway. Awesome Windows dev and ISO C++
content.

------
flukus
And all you have to do is convert it into a UWP app:

>A few months ago, during Build 2016, we announced the Desktop Bridge,
enabling developers to bring their existing desktop apps and games over to the
Universal Windows Platform (UWP) by converting their app or game with the
Desktop App Converter and then enhancing and extending it with UWP
functionality. This then enables the path to gradually migrate the app or game
to reach all Windows 10 devices over time, including phones, Xbox One and
HoloLens.

~~~
benaadams
You run the converter on your complied exe installer, not your applications
code. That a fairly low barrier.

Seems to make the Store very backwards compatible, it can even convert VB6
apps:
[http://www.hanselman.com/blog/PuttingMyVB6WindowsAppsInTheWi...](http://www.hanselman.com/blog/PuttingMyVB6WindowsAppsInTheWindows10StoreProjectCentennial.aspx)

Also if you want to go from exe rather than installer you can use makeappx
directly [https://msdn.microsoft.com/en-
us/windows/uwp/porting/desktop...](https://msdn.microsoft.com/en-
us/windows/uwp/porting/desktop-to-uwp-manual-conversion)

~~~
mschuster91
VB6? That's... the awesome kind of crazy. How does the converter deal with the
VB6 runtime that had to be distributed?

Oh dude, this brings back some memories... but I have to admit, for long time
there was nothing except VB6 if you wanted to put together GUI apps with very
little code and a WYSIWYG GUI designer.

~~~
Washuu
When I was about 12 my father gave me a copy of VB6.

I used form and image controls to made a pixel based tiled fighting game. Not
an actual game engine. Just a horrible hack that actually worked and I was
proud of it. It was one of those things that helped me get into programming.

(I still have a copy of it.)

~~~
majewsky
I remember implementing a Conway's Game of Life in VB6 with a grid view's cell
background colors. Good times.

------
oridecon
Too bad you still need a Microsoft account to use the store, besides
sideloading. That's a deal breaker for me, at least on the desktop (I know you
can login separately on each app).

1) How good is the sandbox? I followed the links but how battle-tested is it?
What if you put an already sandboxed Chrome inside UWP, does it basically use
almost the same calls or there are some extra benefits? Besides FS isolation.

2) Can I browse the "sandboxed disk" (including registry files) and export
everything? So I can make backups or restore it later.

3) Does it stop apps from installing intrusive things? Some bank plugins use
like 30% of my CPU on idle, run a lot of services on startup, so I have no
option but to use a VM.

I'm really curious about all of this and there's almost no hype around it. All
I see is people talking about walled gardens, privacy concerns (that I have
too), how they screwed in the past with GFWL, Windows 8. But downloading
software from 3rd party sources in 2016 is just awful. I want the Linux
package manager experience. I don't trust any 3rd party like Ninite,
Chocolatey, and they have like 10% of all the software I need anyways.

 _Let 's see if the third time I make this comment gets a reply_

~~~
skuzins
It's not a proper sandbox. Converted apps run with full trust. There's file
system and registry redirection but a malicious app can get around it. See
this discussion:
[https://arstechnica.com/civis/viewtopic.php?f=15&t=1312055](https://arstechnica.com/civis/viewtopic.php?f=15&t=1312055)

Also full trust vs app container here: [https://msdn.microsoft.com/en-
us/windows/uwp/porting/desktop...](https://msdn.microsoft.com/en-
us/windows/uwp/porting/desktop-to-uwp-root)

~~~
oridecon
That's worse than Win32 since it gives you a false sense of security and you
have no way, AFAIK, to see what the app is doing (or to check if it's a true
"native" UWP app). Some app uploading my personal stuff without my permission
(no extra privileges required) is worse than a cryptolocker.

------
nickpp
OK. So I converted our app from MSI to AppX (using Advanced Installer so it
was just another output from the same project). Publishing to Store is
underway.

What next? What are the UWP APIs/functionality worth adding to an existing
Win32 app?

~~~
garganzol
30% cut from your revenue.

~~~
the_trapper
That's kind of a narrow view. There's nothing preventing you from continuing
to sell your software directly, and just about any other retailer/publisher
will take a similar share of your revenue.

The upshot is that by putting your software in the Windows store, there is a
chance that you will gain new users that would have never found your product
otherwise. It also removes some of your overhead considering that Microsoft
hosts the software themselves, handling payment, storage, and bandwidth for
you.

~~~
abz10
Hosting an installer is trivial, basically free, and likely less effort than
dealing with the MS store. Their search is terrible (I work in search) and
their reach is poor - people have been trained not to trust the store and most
ignore it completely.

The biggest benefit would have to be copy protection. Copy protection is hard
to do because MS has made it hard intentionally for both technical and privacy
reasons. Also the people making these decisions at MS are also on the payroll
of the installer companies who benefit from not having a workable and freely
available alternative. And there was no insentive internally at MS to fix it
because bonuses are tied to the new metro stuff.

If you're doing something mass market then 30% might be worth it. But if
you're niche, which is MSs bread and butter, and stickiness, then it will not
be worth it. Which is an idiotic position for MS to be putting people in.

I predict continued failure of the App Store which will erode Microsoft's
dominance in the long tail. The only thing keeping me on Windows is WPF and
legacy customers.

~~~
the_trapper
I agree with you that right now, Microsoft's implementation of an app store is
definitely quite a bit worse than Apple and Google's versions. However, there
are people making money there or else people wouldn't continue to put their
apps in it.

Personally for me as a developer, I think one of the biggest benefits to app
stores is payment handling and updates.

The latter in particular is such a pain to get right traditionally on Windows
in particular. You can either ping your server and nag the user to download an
installer at startup or run a background process that periodically checks and
installs updates silently. Neither is ideal.

As a user I also prefer the Windows store to the status quo because I can
cleanly uninstall store apps. Traditional uninstallers almost always leave
vomit all over my computer that doesn't completely wash away until I
inevitably reinstall Windows.

------
forgotAgain
So then UWP is basically dead for 99+% of it's use cases.

For mobile: use Xamarin.

For desktop: use win32/.net so you can support pre August 2016 versions of
Windows.

For Xbox and ARM where you also need support for desktop and mobile devices:
use UWP.

~~~
WorldMaker
There is no "Xamarin for Windows" there is only UWP. Xamarin spreads in the
other direction giving Android and iOS a more UWP-like .NET development stack.

For Desktop, probably still a better idea for new development to be in UWP
directly instead of converting a Win32 app.

This isn't the "death" of UWP, this is a stopgap bridge to take the long
legacy of old Windows apps and give them a new life in the UWP era, including
making it much easier to migrate out of classic Win32/.NET for newer UWP APIs,
one screen at a time instead of porting the whole thing at once.

------
MayeulC
> converting their app or game with the Desktop App Converter and then
> enhancing and extending it with UWP functionality

The keyword here is probably "extending". I am not aware of what it really
means, but I wouldn't be surprised if MS tried everything it could to get more
developers on its UWP. And keep them.

~~~
youdontknowtho
It just means using some API's that aren't available unless your app is well
behaved. No admin access is the big one. Don't write to \Windows or Program
Files. That kind of thing.

It doesn't mean...whatever paranoid thing you think it means. Also, its a
developer related thing. If you don't have a desktop app that you want to move
to the store or bundle in an Appx package for distribution on the web, it
doesn't mean anything to you.

~~~
wolfgke
> It just means using some API's that aren't available unless your app is well
> behaved. No admin access is the big one. Don't write to \Windows or Program
> Files. That kind of thing.

Does this also include "allocate executable memory" (you need this if you
write a JIT compiler)?

~~~
benaadams
Use the "Code generation" permission?
[https://msdn.microsoft.com/windows/uwp/packaging/app-
capabil...](https://msdn.microsoft.com/windows/uwp/packaging/app-capability-
declarations)

------
zspitzer
The Store app is still half baked, I was looking at the Microsoft Remote
Desktop Preview and I noticed there are a couple of urls in the description.
Can you click a url in the description? No. Can you select text from the
description? No

------
mhd
How's the current quality? When I used a Windows Phone for a while, the store
was horribly swamped by featureless spamware, esp. compared to Apple's store
or even Play.

~~~
garganzol
A few of them are decent: MS apps like Weather and Remote Desktop, some
products from Abby. But in general, Windows Store is still loaded with
featureless poor quality pieces. And yes, even the good apps scream for being
"not the right thing" for desktop. A screen real estate seems hugely wasted.
It is annoyingly hard to point to giant controls with the mouse on the big
screen.

------
CommanderData
Do I need to sign my code which means having to purchase a signing cert? The
costs for code signing are prohibitive for some small devs.

~~~
benaadams
You don't need to buy a signing cert; the Store signs the appx for you for
installation. (Though you sign or self-sign the package
[https://msdn.microsoft.com/en-
us/library/windows/desktop/hh4...](https://msdn.microsoft.com/en-
us/library/windows/desktop/hh446592.aspx))

You may need to buy one if you distribute the appx outside the store and you
want it to be automatically trusted? (As you don't need to distribute the appx
via the Store or install via the Store)

------
CyberDildonics
So does this mean that there is a sandbox/jail that can be used arbitrarily?
One of the biggest problems on windows is that you never know what an
installer is going to do. Most average people's computers are bogged down with
20 things running all the time. Even without malware most people's computers
slow down until they buy a new one.

~~~
WorldMaker
Yes, these converted apps are containerized (sandboxed) and their arbitrary
requests are redirected to an app-only location.

------
garganzol
Are those UWP packaged apps could be downloaded and installed from a website
in a few mouse clicks?

If not then thank you, I would not bother to participate in a walled garden.

~~~
ctolkien
Yes, the store is just one distribution model. The web, or whatever is also
fine.

~~~
garganzol
That's interesting.

Is there any practical step-by-step guide on how to achieve this? Or at least
any sample website that offers installable downloads in APPX/UWP format?

The last time I tried it wasn't possible at all without some PowerShell black
voodoo scripts with some temporary certificates and other royal pain points
rendering the whole technology totally useless. I could not even run my own
appx apps because they should only be run "in container context".

UPDATE: Just tried to create a blank app, packaged it into .APPX and run it on
my machine by double-clicking the resulting APPX file. Here is what I've got:

"Either you need a new certificate installed for this app package, or you need
a new app package with trusted certificates. Your system administrator or the
app developer can help. A certificate chain processed, but terminated in a
root certificate which isn't trusted (0x800B0109)"

What? Totally useless. I've just compiled MY application on MY machine and I
even cannot run it.

Why not replicate the UAC known/unknown publisher model? And those MS people
are then curious why their latest greatest UWP/Store platforms aren't getting
enough traction.

UPDATE 2: tried to run my compiled .EXE file without APPX packaging.

Here is what I've got:

"This application can only run in the context of an app container."

Duh. Universal Windows Platform they say? Conquer the world? Nope. It all
stops at "the context of an app container".

UPDATE 3:

Settings -> Update and Security -> "For Developers" -> Developer mode
("Install any signed app")

Of course I did this. Does not work as described above. All I want is to run
MY just-compiled app without the hoops in loops, for starters. Yep, installing
a temp certificate probably would solve this but its a PITA because it expires
and requires ceremony. Won't waste my time, sorry. See ya at the next MS Conf.
Hope .exe files will be launchable again till that time.

P.S.: Sometimes I miss Sir William Gates

~~~
benaadams
Settings -> Update and Security -> "For Developers" -> Developer mode
("Install any signed app")

Or install your certificate in Trusted Root Certification Authorities

Or buy an application signing certificate from a Certification Authority

Or distribute via the Store which signs for installation for you.

------
jbb555
Can be. Won't be. And if they are nobody will notice.

------
Animats
The day will come when you won't be able to install an "app" from anywhere
other than the Windows Store. Microsoft will want a big cut of the sale price.

Bad security is a feature. If platforms were secure against hostile
applications, we wouldn't need app stores.

~~~
CyberDildonics
I don't know why this is buried, it is absolutely true. What windows users
need are some sort of sandbox / container / jail where registry / file system
/ system calls are isolated. Then you could package up a program into one file
and delete it to uninstall it like one file. This could have been done decades
ago and now microsoft is banking off of the fact that they never did.

~~~
diego_moita
> I don't know why this is buried

Because it is the typical anti-M$ conspiracy theory. It blames on "evil" what
it can't understand.

Win32 is not insecure because they wanted to sell security. It is what it is
because that's what made sense at the time, before Internet and viruses
appeared, memory was restrained and virtualization and sandboxing were obscure
techniques and processing power and memory were severely constrained.

The "could have been done decades ago" is not that simple. One way or the
other it should imply in limiting direct access to resources by programmers.
And, giving how big the Win32 ecosystem became, that's more political than
technical.

~~~
emodendroket
Well, yeah, a lot of the decisions that people question have to do with not
breaking existing software.

