Microsoft Project Reunion: an evolution of the Windows developer platform
github.com
github.com
I just want it to be like it was in 1998. Want to learn how to program for Windows 95, 98, or NT back then? Buy Programming Windows 5th edition by Charles Petzold, read it, and you are most of the way there. Add Advanced Windows by Jeffrey Richter if you need more lower level knowledge.
If you needed to support Win 3.1, you had Petzold's Programming Windows 3.1 for that. (...and Petzold's Programming the OS/2 Presentation Manager if you wanted to branch out a bit).
Just get Petzold to write one of these for Windows 10 and I'll be happy.
If you are tuned into MS Build Live right now, you can get a feel for where not just Windows, but the entire ecosystem is headed. Low code developer studios. Heavy cloud integration. HTTP / API REPLs. Build actions instantly targeting a mind boggling array of devices and platforms.
I've seen it across environments. Goal is to eliminate the possibility of introducing human error into complex systems. As well as onboard recent hires quickly. Era of developing software as visual metaphor is upon us. Possessing actual bare metal skill will become more rare (and counter-intuitively more valued) than ever ;)
I've been hearing this for about 25 years. Yet none of the software I actually use is developed that way.
Low-code and API integrations are unfortunately as much error-prone, and make debugging harder. I mean, it's always good when you can avoid playing with raw pointers, but there's a large valley between that and drag&drop flowsheeting, and in that valley, there lie the most productive of tools.
Honestly, I'm worried where this is all headed. When I see "heavy cloud integration, HTTP/API REPLs", I don't read it as "making it easier to develop powerful and robust software", I read it as "software is now a graph of relationships between third party business entities", something I desperately do not want to happen.
Edit: My main point is that this framework isn't short-lived. Whether it's mediocre is naturally a matter of opinion.
Disclosure: I work at Microsoft, but not in the Windows dev platform group. (I'm on the Windows accessibility team.)
[1]: https://blogs.windows.com/windowsdeveloper/2020/05/19/introd...
Strange that they don't use it in all of their own projects—it seems as though most new software from Microsoft now uses Electron.
Can you imagine Apple doing this? Actually, scratch that, because Catalyst has complicated the question too much—can you imagine the Apple of five years ago doing this?
And that's why Mac software (of five years ago) is so visually and behaviorally consistent, and why Windows apps are not...
As for VS Code, IIRC, Microsoft also uses the editor component of VS Code in some web applications.
Microsoft is not a single monolithic entity. It's reasonable for product teams to do what they believe is best for their products, even if those decisions don't align with the strategy of another product (Windows).
[1]: https://microsoft.github.io/reactxp/blog/2017/04/06/introduc...
Now, Microsoft is not all app developers—but they could set an example for how developers should be approaching the Windows platform. And from where I sit, they're setting a bad example at the moment.
If it's really necessary for Microsoft Teams to be using Electron while Office uses UWP, those teams should be making a huge push for consistency in terms of what's user visible. They either (A) are not trying (B) are doing a bad job or (C) it's just nearly impossible to use completely different libraries and have the UX match.
(If anyone knows of a counterexample, where apps using different frontend technologies achieved visual and UX unity, please let me know! It's possible my underlying thesis is wrong.)
It's still remarkably useful for a book that was published in 2013, but we are probably overdue for a "version 6.5".
That reminds me of a site I wish existed. It would mainly just present a table listing tools and technologies in column 1, and a year in column 2.
The year is the earliest year that books written for that tool or technology will still be mostly applicable to the current version.
For example, suppose you would like a book about Postfix (the SMTP server).
There are a few books on it, still available new. Hildebrandt and Koetter's "The Book of Postfix" (2005). Dent's "Postfix The Definitive Guide" (2003). Blum's "Postfix" (2001).
Does Postfix change slowly enough that some of those are still worth reading? That's what the site I want would tell you.
Of course it would be fine if the site had more detail. It might say things like for technology Foo books after 2016 should be fine, books from 2012 to 2016 should be fine except they will be missing major feature X and Y, books from 2008 to 2012 will be using an older, very different configuration system, and books older than that will be pretty much useless.
> "In September 2018 I retired from my 34-year career of writing, speaking, and thinking about application programming interfaces."
I've been trying to get up to speed with modern Windows application development recently, and the official Microsoft documentation isn't good enough. The modern Windows app model has a really messy history, but the official docs mostly sweep that under the rug.
I've been heavily relying on Petzold's book and comments by HN's very own contextfree[1], maybe he can write a book :)
With the exact same choice of languages available in 1998?
Microsoft has been on a years-long journey to unify the APIs in Win32 and UWP, adding more common APIs and interoperable code between the two. Still, every time Microsoft tries to improve the situation, developers have to wait for the latest version of Windows.
This time, Microsoft is borrowing an idea from the web — polyfill — with the introduction of packages. A polyfill is a piece of code that provides modern functionality on older browsers that do not natively support it. As Microsoft introduces new APIs, developers link against a package, and if you’re on an older version, Microsoft will polyfill the functionality as best it can to use in the new version. The best part is that these packages will work from a Win32 or UWP app. The collection of packages thus becomes a common API service between Win32 and UWP. Best of all, Microsoft can do this across its 1 billion devices, immediately. Microsoft EVP Rajesh Jha explained the result in a briefing ahead of Build 2020.
From this article: https://venturebeat.com/2020/05/19/microsofts-project-reunio...
I _think_ its an API wrapper to make functionality available in older versions of windows, is is only in newer versions of windows? Or maybe other platforms that support UWP? It feels like the readme is written in startup-speak, where I was expecting it to be a little more... developer-y?
UWP was originally "monolithic" and "closed" in several respects: your app had to either adopt all UWP facets (be a "UWP app") or none (be a "Win32 app"), new APIs only shipped with new Windows releases, the implementations were entirely closed source, etc.
In the past few years they've started to take pieces of what used to be UWP and pull them out into separate components. Unlike the monolithic UWP platform, these components can be adopted independently by Win32 apps without having to adopt all the other components at once, their runtimes can be distributed with your app outside of Windows and run at least a few versions back, their implementations are partly or wholly open source, they do planning and design reviews in the open on github, etc.
So far, the components they've done this with have been
* WinUI (a decoupling of the UWP UI framework)
* MSIX (a decoupling of the UWP packaging system)
* C++/WinRT, C#/WinRT and Rust/WinRT (a decoupling of the UWP object system and language bindings)
The "new" Project Reunion is basically an umbrella name for these decoupled UWP components, a declaration of their intent to decouple the rest of UWP in similar fashion, and a new github repository for planning this and designing the future evolution of the Windows developer platform in general. So the repository has issues posted by Microsoft developers about how the UWP app lifecycle and resource formats can be decoupled, for example.
https://docs.microsoft.com/en-us/windows/apps/desktop/modern...
Desktop C++ users should use: "UWP XAML hosting API provided by the Windows 10 SDK (version 1903 and later)."
This was about a month ago.
I hope they do better this time.
Fascinatingly, it seems that Microsoft for their own purposes prefers to use Electron-based applications.
I'm curious if they will manage to reduce that strange state to something more reasonable.
The original goal was to force people to move to UWP, which is mobile friendly, processor architecture independent, etc. But the shift was too hard so nobody did it. If all of the APIs are available everywhere, legacy Win32 apps can continue to evolve, and at the same time, Win32 and UWP apps coming closer together makes an eventual shift over to UWP more practical because it won't require starting from scratch.
Possibly related:
Windows Package Manager Preview
https://devblogs.microsoft.com/commandline/windows-package-m...
https://github.com/microsoft/winget-cli
[1] https://mybuild.microsoft.com
[2] https://github.com/microsoft/ProjectReunion
[3] https://venturebeat.com/2020/05/19/microsofts-project-reunio...
I'm always a bit skeptical of projects that seek to harmonize or standardize APIs across different kinds of hardware devices, not for the benefit of users, but for the benefit of software developers.
The visions behind such projects often seem to produce elegantly designed software platforms, like Windows 10 Mobile[a] and Ubuntu Touch[b], for which there is actually no user demand.
Did end-users, i.e., regular people, ask for Project Reunion?
--
[a] https://en.wikipedia.org/wiki/Windows_10_Mobile
[b] https://en.wikipedia.org/wiki/Ubuntu_Touch#Ubuntu_Mobile
but then don't you still have a common install base, because the change will be too much for some users who will hold off, a la windows 7/8.
as someone doing a little windows dev on the side, the issue for me has been that i don't know whether uwp or win32 is the better (future proof) choice. i guess when one of the main distinctive features of your os is that it is backwards compatible, it is hard to change. (i noticed BN_UNPUSHED is documented as being included for compatibility with 16-bit versions of Windows before 3.0.)
Sadly, even this just looks like XKCD #927 all over again.
It's honestly so ironic how little universal any of it is, in the end.
When their phone platform imploded, UWP suddenly didn't have a real market.
Possibly related:
Windows Package Manager Preview
https://devblogs.microsoft.com/commandline/windows-package-m...
https://github.com/microsoft/winget-cli
[1] https://mybuild.microsoft.com
[2] https://github.com/microsoft/ProjectReunion
[3] https://venturebeat.com/2020/05/19/microsofts-project-reunio...
Sorry for the annoyance!
* can be used in UWP and Win32 apps (with no package required for Win32)
* supported on Windows 10 versions going back several years
> C++, Rust, C#, and JavaScript
There's still lots going on in the commercial / enterprise space, but that stuff is either old and Win32 or new and in the browser.
Who is using UWP?
So if you are using pure old style Win32, you will be using a view of the computing world stuck in Windows XP.
That's kind of what I was getting at when I said the Windows ecosystem (excluding games) is moribund.
For the record, I'm a Windows desktop developer. It's a great place to make a living, I just wish there was a little more vitality here on the consumer side.
On MacOS an independent developer (or small shop) making great software can still sell it at $50-$100 to enough people to make a living. For some reason it's harder to do on Windows even though the market is far bigger. I'm thinking of software like Things or Fantastical. High quality, polished, reasonably priced with an enthusiastic user base.
I have been in plenty of countries where there isn't any Mac to be found.
Supporting developers were they are is likely to be much more successful than supporting developers were they wanted them to go.
Personally I got burnt out on it a long time ago and won't be migrating to this or any other new MS UI technology.
am i missing something other than the politics?
admittedly this is pure speculation (TLDR... i mean... it's a corporate github repo with an unfathomable number of enormous minds contributing to it), but i would think something like .net core 1.1 would be the initial target
also... to head of the parenthisized joke above... i was also too lazy to research it more. i told my boss about it, though. he's smart... and in charge of how things like this impact my life
I beleive in latter. Are you?
Announcement support page
https://support.microsoft.com/en-us/office/get-started-with-...
In the news
https://www.theverge.com/2020/5/19/21260005/microsoft-office...
'Microsoft is creating a new kind of Office document. Instead of Word, Excel, or PowerPoint, the company has created Lego blocks of Office content that live on the web. The tables, graphs, and lists that you typically find in Office documents are transforming into living, collaborative modules that exist outside of traditional documents.
'Microsoft calls its Lego blocks Fluid components, and they can be edited in real time by anyone in any app. The idea is that you could create things like a table without having to switch to multiple apps to get it done, and the table will persist on the web like a Lego block, free for anyone to use and edit.
'“Imagine you could take those Lego pieces and put them in any place you wanted: in emails, in chats, in other apps,” explains Jared Spataro, head of Microsoft 365, in an interview with The Verge. “As people work on them, they will always be updated and contain the latest information.”
'Microsoft’s Fluid Framework sounds a lot like Google Docs, but it’s actually Google Docs on steroids. Microsoft is so confident it has built the future of productivity, it’s now open-sourcing its Fluid Framework so the rest of the world can help shape what it has created. Some Office.com users will even be able to start getting a taste of this Fluid future in the coming months.'
Edit: you were right I was wrong apologies