It would have been nice...
... if Windows 10 could run Windows 7 applications natively. You know, backwards-compatibility. Microsoft used to have heard of it.
UK startup Cloudhouse has taken on the Windows migration crowd with a product to take Windows 7 era applications, wrap them inside an operating system interface code layer, and make them Windows 10-compliant. It calls this interface code a "container", but this is not Docker-style, micro-services containerisation. Instead, the …
> I do run Win10 and it runs old apps just fine
I don't disagree with you; but why does the article talk about "all organisations with Windows 7/XP-era applications without the resources or wish to rewrite their legacy apps for the Windows 10 age" ?
In other words, what exactly is the problem it is solving?
I work at Cloudhouse, we typically find this applies to Enterprises whose line of business application are either heavily customised off-the-shelf application, vendor that has gone out of business, or a bespoke application developed inhouse or by consulting firm. It is more likely that they cant get their applications updated, challenges include no easy migration path to next version, budget to do so, no inhouse dev expertise or access to source code. The applications wont install, and or run on Win 10 so if business needs to rollout Win 10 then the rollout is blocked until the issue is resolved.
I think this referring to making Windows 7 programs run on non-x86 systems or in systems where you do not have permission to install programs but do have permission to use an app store. The article is not clear, but I think it is the latter.
And it a program, not an app. Yes, technically an application and a program are the same thing. But before Microsoft went "mobile first (and customer last)" they were called programs. Apple and Google used the word apps. And, of course, apps are bought from an app store where conveniently Apple and Google make money, a lot of money. Microsoft being the great copiers that they are decided they too wanted to make money this way and so started to call programs "apps". I believe one day Microsoft will ban any program not installed through their app store "for your protection", but in reality so that Microsoft can make a percentage profit off every sale. Now, when I think of a program today, I think of software that does not require an app store to use. I have been resisting calling everything apps because I don't want Microsoft to succeed in forcing everything to go through their app store, and thus succeed in controlling what I can and cannot do with my purchase.
You can already repackage existing applications to make it available on the store. It's called "Desktop Bridge" (https://developer.microsoft.com/en-us/windows/bridges/desktop), at no cost.
Unless your application does something weird it shouldn't do at least since Windows 2000, it will work once repackaged. Of course, low-level system utilities can't work repackaged - but why you would use an outdated low-level utility on a newer system where it could screw-up royally?
It is true some people may have to run application written by developers who never learnt to code past Windows 3.0, and in such cases some containers may be helpful, instead of running a full VM. But they are more and more a security liability also, and I'd be very careful keeping on using them.
Correct the Desktop App Converter (DAC) repackages apps for the Store or the Store for Business, it requires apps to be able to install and run on Win 10 and to conform to UWPs rules listed here https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-prepare.
MS DAC tool is really intended for software developers at ISVs who can change the code and fix the incompatibilities. Cloudhouse's solution is aimed at Enterprises who use customized off-the-shelf software, in-house developed apps or bespoke line of business application and don’t have access to source code/ or can’t change it for other reasons and want to deploy their incompatible application to their users through their private Store for Business.
By packaging the app in Cloudhouse first, the XP or Win 7 application can then install and run on Win 10, and can overcome some of the restrictions of UWP - our Container can then be packaged into an Appx using the DAC tool. MS have kindly referenced our solution on https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root.
Stu
Head of Product @ Cloudhouse
"Windows 10 could run Windows 7 applications natively"
There have been very few program I havent been able to get to run on Windows 7/10, mainly programs which relied on something 16 bit related or had a 16 bit installer. Programs relying on VB6 runtime still worked the last time I checked on 7 however I do admit havent tried them on 10.
These programs were designed for Windows 9x, sorry but I still rate backwards compatibility of Windows NT and Linux based OS's such as CentOS (Dependencies can be sorted easily) as workable.
Windows 64 bit - any version -. can't support 16 bit applications (including installers), simply because when the CPU is in in 64 bit mode, the CPU no longer supports the Virtual 86 mode required by the NTVDM subsystem to run 16 bit applications. It has been this way since XP64/Windows 2003.
It was an AMD decision when it designed the x86-64 mode. It was not a Microsoft decision. I guess Linux would have the same issues, if it had legacy 16 bit applications to run.
If you need to run 16 bit applications, you need a Windows 32 bit OS. In Windows 10 32 bit you also have to enable the "NTVDM" component in "Windows features" -> "Legacy components".
Microsoft is keeping 32 bit version alive both for resource-strapped machines, and to support old legacy applications.
with a sensible GUI, logical access to settings, customisable GUI and legacy compatibility. There is no point at all to windows if it can't run legacy applications and be designed for desktop, not phone/tablet, might as well migrate to Linux, Apple MacOS or whatever.
Also if you want to be totally dependant on Cloud (which is bonkers) then the local OS hardly matters.
I can run multiple VMs for older Windows applications on nearly any OS. Some legacy applications will run on 32bit Win7 (and the 32 bit Win10 for crippled Atom tablets), but not on 64bit windows. Yet they work via WINE (which isn't an emulator, container or VM) on 64 bit Linux. Esp some VB6 applications (anything using the VB serial ocx, even mapping RS232 to USB on 32 bit Win 10 or 64bit Linux).
MS seem to have lost the plot. What, designing for 0.1% of the phone market when business desktop used to be a captive market. They went "off" when they added Ribbon and GUI over candy of Vista, at least you could turn that off. Now gone to other extreme of monochrome paper with almost no cues as to what is clickable and icons so simple you can't tell what they are for. We are not using Hercules or 1 bit CGA monochrome!
well, there's NO reason any longer to write a UWP [CR]app for Win-10-nic.
I planned on NEVER doing that anyway. If I must write an application for windows, it'll be compatible with Windows 7. *PERIOD*
And if I'm in a particularly good mood, it will re-draw all of the non-client areas to *LOOK* like it's running on Windows 7!!! Because the 2D FLATSO FLUGLY nauseates me.