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.
The introductory phrase of UWP explains why they pushed it: "A Universal Windows Platform (UWP) app can run on any Windows-based device, from your phone to your tablet or PC". The point was getting more applications for their mobile platform by coaxing developers who might have otherwise built a desktop-only application. I'd say this new development is essentially an admission of defeat on mobile.
The problem is that it may take their desktop with it. The industry doesn't want to invest in a desktop windows app because there is no clear direction. WPF/Win32 etc seem to be getting deprecated, but UWP is too limited.
People who actually make money on windows development know that WPF and Win32 are not deprecated.
In fact, they don't really deprecate things. They may stop pushing something as the new hotness...but VB6 apps still run on windows. Those data access technologies that no one uses anymore...those still work on windows. If you are worried about your investment in time not being the new hotness, well that's one thing. If you are worried about your investment in effort being abandoned...they have done more to support backwards compatibility that I think is even reasonable.
Silverlight may be the one glaring exception to that rule that I can think of. I don't think even IE or Edge support that anymore, which makes it dead.
I had an ex-girlfriend whose employer made a big bet on Silverlight for their web app platform... in 2012. Having to rewrite it all in HTML5 and JS a year later almost put them under.
Actually, this is really weird, but yeah, you can still use Silverlight. Until very recently the inTune portal still used Silverlight.
I dig what you are saying though. They had some very confused messaging about the web as a platform for a long time. They finally stopped the BS, though, and have gone whole hog on the web.
Do what now? Does that mean that I can't build apps in C++ anymore? Because it looks like I can and it also looks like I have more options than I ever have. In fact, I can finally use standard ISO c++ to do more than ever. Do you just mean one UI toolkit over another?
I wonder how Adobe has "kept talent" without rebuilding photoshop?
If you are worried about keeping your personal skills up to date and focused on an area that will earn you personally a living then you should know that some of the most highly paid people I've met in technology code for some of the most niche platforms. I mean serious f*ck off money. Say it with me...AS400. (Or ISeries or whatever the hell it's called now.)
UWP is limited as it is relatively new. The new (capabilities based) security model is clearly better than the old "if you are admin, you can do whatever you want" model. The old model was inadequate even at the start of the multimedia age, but it was not recognized until recently. The new sandboxed operation creates more portable and reproduceably operating apps.
The limitations will show, as more and more usecases will be attempted, and surely many will be addressed.
Personally I hope once the global filesystem concept will be gone, and apps will use isolated or shared storages where shared storage will get explicit access rights for each app/user it is shared with.
The old system had defaults originating from the single user non-multimedia usecases left over as a legacy, but currently we have so many things going on our computers, that privacy/security needs a rethinking of old concepts to cope with new challenges.
Personally I hope once the global filesystem concept will be gone, and apps will use isolated or shared storages where shared storage will get explicit access rights for each app/user it is shared with
I very much hope not, since default and easy global sharing is what makes desktop OSs so very useful, and a lot of this sharing is spontaneous, creative, and ad-hoc. Besides, we already have things like filesystem permissions. By all means have a sandbox for "the untrusteds", but I don't want the equivalent of being forced into the "everything which is not explicitly allowed is forbidden" bureaucracy.
Filesystem permissions cannot be controlled on a per app level. I do not like the fact, that an installation of for example a game needs admin rights, and has every chance to access data it should not be able to do.
I see your point, that the current solution offers a simple (and vulnurable solution). This is why I have said that these challenges need to be addressed. The current solutions may not be the best, but for an evolution to start we need to make changes, and try different approaches.
* No app closure callbacks. You don't know if it's suspending or exiting.
* No "are you sure you want to exit? Save/Don't save" dialogs. If you close or crash pray your data was saved, and if it takes a long time to flush to disk...really pray.
* No minimizing/backgrounding to tray icons allowed.
* I guess You can create a background worker handling persistence, which runs until completion even if the UI has been closed. (I have not used UWP yet)
* IMHO save/don't save dialogs are an usability antipattern.
* Tray icons are also something of a remedy of the past. They are now replaced by background operations and live tiles.
I can see why those can be problems, I can imagine the usecases you would solve using those tools, but the new app model is build around a slightly different workflow.
But if you do not like the way to solve it as it is intended in the new app model, the solution is: report it/upvote it. If you tell your problems here, then some members of HN community will know it and understand it, but it is unlikely that it will be acted upon by Microsoft. For that you need to have your voice heard on their forums. (eg. feedback app, uservoice...)
> No "are you sure you want to exit? Save/Don't save" dialogs. If you close or crash pray your data was saved, and if it takes a long time to flush to disk...really pray.
Of course not, because it's supposed to also work on mobile. Does your iPad let applications prevent you from going back to the home screen?
I really disagree with UWP being a better model than limited UAC. Apps being able to talk to each other and the filesystem and interacting is what makes them useful. The linux/sudo approach is the best comrpomise between security and utility I'm yet to come across.
> The old system had defaults originating from the single user non-multimedia usecases left over as a legacy, but currently we have so many things going on our computers, that privacy/security needs a rethinking of old concepts to cope with new challenges.
I android has proven anything it's that sandboxed applications don't solve this problem.
Generally the way I've seen sudo implemented in all desktop linuxes is that after providing a password the process gets all access.
This to me isn't a great trade off as it relies on the user invoking the process understanding the security risks they're taking, which is a tricky one.
Sure you can do more with sudo, but unless it's the default, most people won't
The global filesystem is only a problem if you run lots of closed source/untrustworthy apps. Many of us don't and use the global filesystem very heavily and very much hope it does not go away.
I guess you also only then need a firewall, if you use closed source software. When using OpenSource software you can always be sure that nothing will do unauthorized access to your network, willingly or accidentally...
Desktop Windows is clearly the technology of the past, and I say that as someone who develops on it every day.
People starting in a green field will build a web or a mobile app if at all possible. The cases where it isn't are basically games and what used to be called "workstation" apps: big chunky tools like SolidWorks.
Even Adobe have retreated to the cloud, although the tools still run locally.
It is not in the least. There are millions of gamers, creative professionals, developers, engineers, etc.. that use desktop applications on Windows every single day and that will not change any time soon.
My understanding is that the 'Universal Windows Platform' is comprised of disparate multiple non-universal platforms such as desktops, mobile devices, servers, clouds, and IOT things. In practice this means that a UWP application targets one or more platforms and not all of them, e.g. Microsoft's UWP Camera app doesn't target the Azure or Server platforms.
My take is that Microsoft is in mobile for the long term and that its strategy has been to gradually migrate the target uses first addressed with Windows CE into the mainline of Windows and that Windows 10 is the realization of that strategy...we're back running Excel on mobile devices.
Windows Phone 7 was the first step in that direction. Windows Phone 8 and Windows RT were intermediate steps toward hardware agnosticism and away from Wintel strategies. I call it an intermediate step because apps for those platforms were [at least largely] forward compatible to Windows 10 and Windows 10 Mobile.
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?
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).
I want Windows to remain the dominant gaming platform. But for this, UWP is completely heading into the wrong direction.
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.
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.
They've built up an enourmous reserve of ill-will that will take years to diminish. It wasn't all that many years ago that they were tangentially involved in SCO's last-ditch attempt to destroy Linux. The Win10 telemetry and forced-updates controversies are ongoing.
Everyone can see a possible future in which all the doors for shipping software to users' computers without paying 30% to the platform holder and submitting to their arbitary rules are closed. (The justification will be malware, of course). That day has not yet come, and it's not necessarily implied by WinRT, but it's a step in that direction.
It actually was a long time ago that they were "tangentially involved in SCO". That was a very long time ago. My children were babies when that happened. THEY ARE IN COLLEGE NOW.
BTW. That was mainly IBM and Novell that you want to be mad at. Microsoft made a licensing deal with SCO to license Unix. Wow. You really have to reach back on that one. You could have more reasonably chosen how they treated Netscape.
No one ever seems to mention that they invested in Apple at a time when that investment KEPT APPLE ALIVE. But what ever.
The telemetry. It bother you. It doesn't bother me.
The "Get Windows 10" app that people were complaining about? Fair play. That was crap.
I don't know what to say about the last statement. Ask anyone in computer security and they will say, yes it would be great if walled gardens weren't the best idea for getting trustworthy software onto customer systems, but right now it is. They all think that Android is worse than IOS. Platforms that are used by a billion people where you can do anything you want produce malware. There isn't a way around that right now.
Solve that one and you too can be a billionaire.
My feeling is that the "ill will" is more emotional than it is reasonable. I know lots of admins who made up their mind about Windows in the Windows 2000 and 2003 era. It's vastly different in 2016 and far better. It's hardly recognizable.
EDIT: OK OK. Babies may have been hyperbole. Toddlers. They were toddlers.
2004-2012 I built apps of significant size/$$ for clients employing poorly recommended microsoft tech including silverlight, infopath, webforms, datasets, windows phone 7 and 8, WCF. Hindisght is 2020 and shame partially on me but when you try to be sensible and follow the official recommendations you develop this instinctive flinch over time that happens when microsoft comes out with re-inventions that converts your codebase into legacy overnight.
Yes youre right the 'new' microsoft under nadella is much more accommodating, however I was forced into a place where I couldnt afford the problems the 'old' microsoft bought and it was more logical to adopt open standards. Since I switched to open platforms microsoft has really improved but pardon me if I stick with my open tool stack for the foreseeable future until i see any compelling reason to switch back. In other words, microsoft is now 'as good' as many open platforms, but there isnt really a compelling reason to switch back.
It's funny you mention InfoPath. I know of at least two multi-billion dollar companies that have significant amounts of development time tied up in InfoPath. All of its still running, with the plan being to replace it over time.
Still just sitting there running.
No need for pardon's. Use what you like that gets the work done. My instinctive flinch is different. We all have them. That's the thing, I don't want you to switch. I don't care. I love open source software. What I am saying is that they have a lot of effort built into backwards compatibility. And those solutions may not be the latest hotness, but you can still run them.
I want Stallman to give more care to the defense industrial base that produces computers than to making sure that the same defense industrial base has a free f*cking compiler to use on the computers it makes.
It's Visual Studio Code...not core. And it's not a skin it's an actively developed fork of Atom.
no windows is not MIT. nor is system center. PowerShell is. PowerShell DSC is. Their OMI broker for Linux is. .Net is. Asp.net is. Their Python tools are. The C# language is developed on video streams with the product team and the community. F# has been open source for a long time. They contribute to Linux, Mesos, docker, Hadoop, and other projects.
I wish that my side projects were as widely used as the C# compiler.
Why don't you just admit that there really isn't anything that they could do. If they did open source Windows you would read some comments written by other people about the code and "pronounce" it the worst code ever written. I can safely say that because here's the thing...YOU'VE ALREADY WON and it's still not enough. Open Source won. They were forced by the sheer awesomeness of it and the energy that people like you brought to open source development to adopt it and push it where ever they possibly can. TAKE YES FOR AN ANSWER. Is Windows OSS yet? Not yet, but that is coming. And when it happens you will still have something negative to say about it because this isn't about anything other than your emotional ties to this Microsoft in your mind that has been your favorite boogeyman for years. Guess what? There are actual boogeymen in the world, but focusing on a software vendor keeps you from having to face that. Every computer you buy validates and enforces the defense industrial base of the west. You capitalist infidel, you. All electronics, really, but computers in particular.
You want Visual Studio to be GPL'd? I want to stop flooding the third world with cheap weapons. They need water, not a text editor. Linux doesn't make them more free and Windows doesn't make you less free. It's a stupid privileged argument. Play with your toys and try to be nice, but don't tell me that your toys are more "right" than mine. That's just fucking stupid.
I have had entirely too much coffee, and it's probably time for a new HN account anyway. Cheers.
I'm not saying there's a better desktop API, just that Win32 is 'pretty bad' (IMHO). It's a collection of many small annoyances that have been stacked on top of each other over the decades. My favourite mis-feature is probably everything around UNICODE, such as hiding the xxxA() and xxxU() function names under global preprocessor defines, which in turn renames all your own functions which happen to have the same name. It's many little things like that. It's not that the OSX or Linux window system APIs are any better though.
IMHO a modern OS should only come with a low-level window-compositor which just composes canvases, and leaves rendering (including UI) to the user code through a thin 3D API. Other than that: file system, sockets, input, audio, and a very simple main-loop application model, all as C APIs which don't try to be object-oriented, leave all the different language bindings to the user-side.
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.
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.
> How does the converter deal with the VB6 runtime that had to be distributed?
I've just checked on Windows 10, and yup, MSVBVM60.dll is still part of the OS install - the mind boggles. This is classic MS - providing support for as long as they can, where they can.
Of course I'm not sure how the UWP Bridge would work if your VB6 app referenced a bunch of old school .OCXs though, as typically even the self registering ones need to write to HKEY_LOCAL_MACHINE part of the Registry, which the Bridge docs say is a complete no-no.
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.
My WiX installer prepares the program folder location and installs exactly one downloader executable which pulls the rest of the desktop app from a location in the internet. Is this setup compatible with App Store via Desktop Bridge in principle or should I get problems with sandbox etc.? (No need to elaborate, if the answer is yes I'll work through the details on my own).
Nano server (variant of Server 2016) which has no UI component at all has adopted the appx for Windows Server apps (WSA) so I'd imagine the tooling will improve there.
The kind of tried it years ago by not including setup projects in visual studio (MS Developers think publishing directly from VS is a good idea), the problem was there wasn't a better alternative.
I didn't mind NSIS (nullsoft of winamp fame), but it was weird to say the least. Install scripts were a high level, domain specefic variant of assembly...
Wouldn't this make it easy for people to convert other peoples applications and upload them to the store? Especially if you don't need access to the code.
I wonder what barriers MS has in place to prevent that sort of piracy?
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
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.
Almost every "store" requires an account. Try to use the Play Store without a Google account. That being said, since UWP itself isn't tied to the Store, as UWP expands, there will hopefully be third party sites to get UWP apps. (Eventually even Steam I presume will offer UWP apps.)
If you know where to look, pretty much everything in a UWP app can be opened via file explorer. Check out the C:\Users\yourusername\AppData\Local\Packages folder
The sandbox here seems somewhat battle-hardened, as it is based on App-V (and some other container systems in Windows), which Enterprises have used for a while and Office has used for every desktop install for several major releases (since 2013 or 2010?).
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?
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.
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.
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.
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.
> 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.
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.
> 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)?
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
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.
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.
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)
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.
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.
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.
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.
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.
Doesn't App-V / Desktop Bridge provide exactly this sandbox?
If the resulting file can be distributed outside the Windows app store, the developer can avoid the appstore tax and retain access to a direct customer billing relationship. If signing of the sandboxed-app-installer is required, $100/year (or other tolerable fixed cost) is still better than a 30% tax on every sale.
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.