Thanks for the update - it's good to get the full story on pricing that their Website fails to provide :-)
Oh I totally understand where this boxed app makes sense. In Enterprises and for legacy applications this can make a lot of sense. FWIW you can do most of that yourself today - Microsoft provides tools to port Win32 applications to run as 'Windows store app` that can be deployed to Windows store or a corporate local store.
As a side note, I've gone down this path at some point with a comerrical product I sell -
Markdown Monster - which is a specialized Markdown editor with focus on typical developer scenarios. As such it requires integration with a bunch of related technologies on the desktop which was one of the main reasons this is a desktop application in the first place rather than an online tools. Turns out for the Windows Store a bunch of things I've been doing (shelling out to command line, opening other applications, allowing for addins) is not allowed in the Windows Store. So basically most of the things that made a desktop application the right choice weren't actually allowed in the store. So I ended up nixing that idea no less due to the snotty Microsoft enforcers trying their best to be unhelpful through the validation process. The ironic thing is I was able to package my app (as an APPX) and it runs and works perfectly that way, but all the constraints were around what you were allowed or not allowed to do with a Store app.
I suspect BoxedApp isn't meant for the Windows Store but it probably uses the same technology to wrap applications up (APPX) which basically packages the whole app into a single install package that installs into a private area of the system with its own registry and user files section separated from the main Windows system.
I also don't foresee the Windows Store being the only way to get Windows applications installed.There are too many things still that require more control over the system and as I siad if you really have to live by all the limitations of the Windows Store (that MSs own apps often violate) then you're usually better off building a online Web application and skip desktop altogether. There's a lot of resistance to UWP (Windows Store) apps and even to wrapped apps.
Desktop development is a pain these days - plain and simple. No easy solutions. Microsoft has great complete frameworks (WinForms, WPF) that have been mostly abandoned. Still supported and updated but no major new features. MS pushes UWP but few are willing to build them because the models are inferior to WPF and the lack of control makes it much less useful. Plus the whole requirement to go through some sort of publishing and authorization process with the MS police everytime you want to publish.
Electron with JavaScript is an alternative that a lot of people have chosen, but to me that is also a fools errant because there are no decent desktop like UI frameworks that provide you a rich UI experience fit for desktop applications.
We were having discussions about desktop development options a few weeks ago and there were a lot of good points of view raised from all angles. Dig through the history to find that thread if you want some interesting reading...
+++ Rick ---
>Hi Rick,
>
>Thanks for dropping in. I appreciate a lot what write on system-wide implications of application development technology. From what you wrote on oldish COM-based application à la VB or VFP, of course, to #C development, I have always learned a lot from your carefully crafted posts on the matter.
>
>By the way I am an VFP-dev-transitionning-to-Cpython kind of dev and I admin to having no experience with #C. But I'd be really glad to hear your point about #C desktop app deployment. What is the situation to-day? Do people rely on some sort of default recommended Redmond-originated practices. Or are they alternatives? I do mean traditional ones à la C++ or VB classic ones?
>
>>You gotta love companies that don't list their prices on their Web site.
>
>I certainly do not as well. But, sure, I found NO real alternative to BoxedApp when it comes to "virtualizing VFP applications". And Artem is supportive (I never really had a need for support but that's important).
>
>What I found really pleasant, are the size and performance issue. The website experience is really not matters here when it comes to "buying" solutions. I even use some oldish and unsupported VFP source code with zero web-site left:-)
>
>The cost for BoxedApp last year was € 361.16 for a Packer Single Developer License + 1-year free upgrades. In view of the costs associated with the deployment of an application at our customers (hq premises), this is worth every penny... Meant centime or cent:-)
>
>>Looks very interesting though I have to admit, although for most apps that I'd use to build a desktop app rather than a Web app for, sandboxing wouldn't be the appropriate.
>
>I can understand that very well. You and your customers have full control of their machines. Ours are not techies and have haven't. Although we have MSI-based installers for those who care, it just help to run a virtualized application in our business case (no admin rights on the workstation).
>
>In some cases this copy-install even help A LOT. Say a company where the HQ staff - a hand of persons - is in say Paris, Torino or Geneva and needs to rely on some Stuttgart-or-Tunisia based IT support teams (mind you that's really cases just changed the city names...) for installation and admin control on workstations. We currently save a lot of frustrating time (phone, mails and more...).
>
>Of course I understand that once WIN32 applications, even more so unsigned ones, will be considered "bad citizens"under windows and all applications will be downloadable from THE MS-windows store, this will not work anymore...
>
>One caveat here: the memory usage is a bit higher because of the monolithic nature of the "stand-alone" executable. But in view of the current generations of GUI desktop applications, the memory consumption of these "monoliths" remains indeed "minuscule" anyway. Thanking our oldish VFP memory handling for this:-)
>
>Daniel
