Microsoft has been working to bring win32 desktop apps and its Universal Windows Platform (UWP) apps closer together in recent years. That work has an official name now: Project Reunion. It’s the latest twist in Microsoft’s promise of universal apps that run across multiple Windows 10 devices, and Microsoft is now referring to traditional desktop apps and UWP ones as simply “Windows apps.”
“The idea behind Project Reunion is that it allows developers to build one Windows application and target all 1 billion Windows devices,” explains Rajesh Jha, executive vice president of Microsoft’s Experiences and Devices Group. “We’re bringing together the combined power of win32 and UWP so developers no longer have to choose because we’re unifying these existing APIs and in some way decoupling them from the OS.”
Microsoft has tried to kill Win32 so many times, but it just refuses to die. The company seems to be throwing its hands in the air saying fine, if you nerds want Win32, you get Win32. I hope this will make it easier for older, more monolithic Win32 applications to be modernised.
Thom Holwerda,
Yeah, microsoft has a dual edged sword, time and time again win32 keeps getting in the way of microsoft’s new framework projects. Yet microsoft’s monopoly remains strong mostly because of win32 apps. If microsoft killed win32 support completely (and I think they might like to), they’d actually drive away huge swaths of their own customers. It would be very bad for microsoft if linux ended up being more compatible with win32s software (via wine) than microsoft windows itself. So as much as microsoft might want the industry to embrace its new frameworks, I think they’re kind of stuck supporting win32 if they want to keep their monopoly intact.
It would be very bad for microsoft if linux ended up being more compatible with win32s software (via wine) than microsoft windows itself.
It would be ironic if this happened, since almost 30 years ago MS did this with OS/2 2.0 (Windows 3.x applications ran so well on OS/2 that developers targeted the former rather than the latter).
It would be similar to the days when FreeBSD ran Linux binaries faster/better than Linux distros. Several movies had special effects done using Linux binaries on FreeBSD systems for this very reason, back in the early 2000s-ish.
Or, as you mentioned, when OS/2 ran Windows 3.x applications better/faster than Windows 3.x itself.
History does seem to be cyclical… 🙂
One framework, across multiple hardware/UI platforms.
Who did this? Apple.
Who is still struggling to do the same? Microsoft.
Sorry, BillG, but it’s true.
This is only possible due to the fairly brainwashed nature of Apple users. If Microsoft said they were going to abandon all compatibility with existing software every few years, they would also have a small market share. Plus those users are willing to pay the Apple tax for the rewritten software (currently happening again with gpgpu computing and Apple making sure only their Metal API can be used for it.)
But Apple didn’t abandon all compatibility with existing software.
When Apple made the big jump from the aging M68k platform to PowerPC in the 1990’s, they incorporated a software layer that translated the old M68k code to PPC, allowing the swathes of older software written for Mac OS on 68k machine to run on PPC machines.
They did a similar thing with Rosetta when they moved from PPC to Intel x86 in the 00’s. At the same time, developers were cross-compiling their apps into “universal binary”, which contained executable code for either platform.
Apple has shifted their platforms TWICE, successfully, whilst keeping application compatibility.
Microsoft has only really done it once, with the x86 emulation layer that ships with certain ARM versions of Windows (I think, i read it here sometime)
Oh come on, lots of softwares from the 90’s still runs on today Windows 10’s. Even some DOS games.
In macOS land you can’t run any 32 bits application on Catalina. And very macOS version broke compatibilities; all you have to do is pay for software updates (if exists).
Don’t say it’s succesfull as each transitions killed softwares.
ultrabill,
I agree, of all the things to criticize microsoft for, legacy support is really one of microsoft’s strong suits. It’s by no means perfect, and there are breakages now and then, but on average we’re talking about multiple decades of backwards compatibility, which is better than most other competitors.
There are users&devs who like to hop onto the latest bandwagon every couple of years, in which case good for them, but a big part of microsoft’s customer base expect long term stability over constant transitions to the latest and greatest frameworks. It’s not microsoft’s inability to create new frameworks, if anything microsoft has been trying to push consumers away from legacy APIs and they’d probably love to “pull an apple” and drop support however it’s the consumers themselves who keep demanding backwards compatibility.
@Alfman
Much of MS’s backwards compatibility has been largely down to the backwards compatible hardware (the IBM PC), which easily allows an OS running on top of it to keep compatibility with programs written 20 years ago. Windows is’t the only example of a modern OS running legacy programs, Haiku does a good job too. FreeDOS also achieves this aim and runs on modern hardware.
The reason that MS can keep backwards compatibility so long is prely down to AMD and Intel, and the backwards compatability of the IBM PC platform, not inherently by Microsoft.
The123king,
Sure, but it doesn’t really diminish the merit in ultrabill’s point. Also I’d point out that projects like freedos are non-moving targets with the express purpose of supporting old software. Like em or not, microsoft deserves credit for providing very long win32 support for customers. It doesn’t necessarily mean apple users have the same needs. Different users, different use cases, different expectations, etc. To each their own.
Ha ha ha ha ha…oh wait, you’re serious? Allow me to laugh even harder HA HA HA HA! Dude I still run games over 20 years old on Windows 10 latest build WITHOUT EMULATION, games like the original Diablo, Divine Divinity, hell come to think about it I honestly cannot remember the last time I ran into a game or program that wouldn’t run fine on Windows 10 no matter the age, I even have an ancient VB based disk catalog program that I use to find where I put things on my backup discs going back to the late 90s…still works just fine, didn’t have to change anything or tweak.
So hows running those M68k apps working for ya on Catalina? How about PPC? Hell how about about 32bit? There is a good reason why MSFT keeps Win32, because there is literally billions of programs, everything from games to billing and transcription to super niche programs like CNC controller programs all written for Win32 and hey wadda ya know, it all just works.
“One framework, across multiple hardware/UI platforms.
Who did this? Apple.”
Are you talking about UIKit, SwiftUI, TVUIKit, WatchKit or AppKit ?
“Who is still struggling to do the same? Microsoft.”
Are you talking about UWP witch runs on Windows 10/Mobile/IoT (x86/x64/ARM), XBox One, Hololens and Surface Hub ?
All correct, but the main issue with UWP is that it was confusing, it confused the community and failed to gain traction because of confused marketing *and* lack of backwards compatibility. For example, we can’t use it because we need to support Windows 7 still.
@henderson101
I totally agree with that. UWP only work on Windows 10 but that’s not the worst part. Its lack of API compared to win32 or the unability to run multiple instance was, I guess, what really killed it. UWP was launched too early.
He could have been referring to OpenStep. Ran on PC, NeXT, PA-RISC, SPARC & Amiga (m58k) as Mach+BSD+OpenStep or ran under Solaris & Win32.
One framework, across multiple hardware and software platforms.
The premise of this article is incorrect. Microsoft themselves have ditched both Win32 and UWP in favour of Web applications and technologies. It doesn’t matter whether you run your Electron project under UWP or Win32 or Chrome.
How? Please give examples. UWP, WPF and Windows Forms are all still supported – and have been ported to .NetCore so will *continue* to be supported. No major Microsoft apps have been replaced by Progressive web with Electron. The only thing I can think of is VSCode, and that is an alternative to VS, which is absolutely still a full framework based app. Teams maybe? I dunno… a few apps doesn’t make “abandon”.
Yet another post that fails to understand how Win32 and UWP relate to each other.
UWP is a COM improvement that traces back to Longhorn being rebooted as Vista, and rewriting Longhorn .NET APIs as COM components. A few years later, when Windows 8 came out, UWP was born as WinRT, later marketing changed it to UAP and finally UWP.
UWP is basically COM with an additionally interface IInspectable, COM type libraries replaced with .NET metadata files and support for generics, structures, events and arrays.
So far UWP was tied to the OS version due to kernel dependencies, what Microsoft has been doing since a couple of years and will continue as part of Project Reunion is to decouple the UWP runtime from the OS, allowing any kind of application to make use of those APIs all the way back to Windows 10 Fall Creators. Similar to how Google has introduced Android X to work around lack of OS updates.
Anyone using old style Win32 APIs is doing cryogenic programming, stuck in the Windows XP view of the computing world.
“The company seems to be throwing its hands in the air saying fine, if you nerds want Win32, you get Win32. ”
And what OS-provided alternative exists, beyond making your app a UWP app which will be bound to a silly Store or a .NET app that runs butt-slow?
This is why I find UWP hilarious. Microsoft essentially tells developers (aka those “nerds”) they should go through the massive effort of rewriting their applications just so Microsoft can use their Store to better censor their apps and stick their hands in the developers’ pockets to take a 30% of the sales. Yeah, I can’t imagine Adobe and Mathworks or even the makers of TurboTax to be lining up for such an asinine proposition.
Packaged Win32 apps is the best Microsoft can hope for, were releasing a plain win32 setup.exe would be a click away, so the developer can target both customers inside and outside the Store walled garden. But still then, how would you explain the price difference at the Microsoft Store (due to the 30% cut that has to be incorporated in the price).
And then there is the fact that lots of source code exists as calls to all kinds of third-party libraries such as Qt which may not have drop-in replacement libraries for UWP for existing win32 projects.
.Net is not “butt-slow”. .Net is slow if you try to do things with a large memory footprint that allocate a lot of memory and process a lot of data. But that is obvious. But UWP apps basically use COM under the hood and can compile to native code, so… yeah.
Anyone who has been developing Windows app not in .Net for the last 10 years has been pretty niche or determined. If you embraced WPF, UWP is so similar that it is pretty trivial to learn the difference – weeks, not months. If you are stuck on WinForms, it’s possible to integrate both WPF and UWP in to those app and migrate your code in iterations away from WinForms. I worked on a codebase like that – it’s all possible. UWP will run outside of the Store. Otherwise you would not be able to do any of the above integrations.
What is terrible is trying to do anything modern with Win32 these days. God forbid you want to maintain an MFC app.
Qt – this is their issue. It’s a third party toolkit. They built their business using a Vendor’s API, they have to deal with change. Also – most of Qt is custom rendered so I believe it would probably be fairly easy for their developers to port it to a new API target – it’s more expense of doing so that probably inhibits that.
How does UWP run outside the store? In non-developer environments of course. What is the file extension I download?
By packing your applications as MSIX, available since two years now.
The file extension is appx.