'At Build 2020 [1] today, Microsoft unveiled Project Reunion [2], its latest attempt to unify the Windows developer platform by reducing fragmentation between Win32 APIs and Universal Windows Platform (UWP) APIs. Microsoft also promises Project Reunion can modernize existing apps with the latest functionality, whether they’re built using C++, .NET (including WPF, Windows Forms, and UWP), or React Native. Additionally, it can decouple the APIs from Windows via tools like NuGet, and it brings new WinUI 3 and WebView2 releases.'[3]
16 points, 16 minutes, and OP posted that 16 minutes ago? Sure seems like a reasonable question to ask, but OP's profile seems to point at a negative answer. That said, a single-sentence copy/paste from the article isn't very substantial
When I commented, the comment in question had a very generic market-speech, and as a moderator of other internet communities, my "spider-sense tingled" so to speak. As it stands now the comment is much more productive.
I have re-read the readme about 5 times now, and I'm still not really sure what it is.
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?
Basically, this is about ensuring all of the different Windows, .NET, etc. APIs that Microsoft announces work and are available on any of the different flavors of Windows app development you can do. The main thing is that a large category of APIs are available to UWP apps (think Windows 8/10 Modern apps) that aren't available to desktop apps, and Microsoft has been trying to close that gap, since developers have basically said no to rebuilding their apps from scratch for Microsoft's newer app platforms.
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.
I think this is similar to how when they started adding features to angular 1 which resemble concepts from angular 2 so that people could start considering upgrading
I agree it's confusing. But here's the intention as far as I can tell:
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.
That's on current WinUI/UWP XAML, the new version in preview (WinUI 3) pulls out components deeper into the stack so it can run a couple more Windows versions back (to 1803 I think)
Having actually tried to use XAML Islands to get some UWP UI controls into a WPF application, I can say that the experience was absolutely horrible and I ended up giving up and not using the UWP control after all. Truly, truly horrible.
'At Build 2020 [1] today, Microsoft unveiled Project Reunion [2], its latest attempt to unify the Windows developer platform by reducing fragmentation between Win32 APIs and Universal Windows Platform (UWP) APIs. Microsoft also promises Project Reunion can modernize existing apps with the latest functionality, whether they’re built using C++, .NET (including WPF, Windows Forms, and UWP), or React Native. Additionally, it can decouple the APIs from Windows via tools like NuGet, and it brings new WinUI 3 and WebView2 releases.'[3]
> Project Reunion is our vision for unifying and evolving the Windows developer platform to make it easier to build great apps that work across all the Windows 10 versions and devices* people use.*
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?
The Windows platform is extremely fragmented since Win10: not only there is different API and execution models (Win32, UPW) but also each new Win10 build brought new API that were not available on previous versions. Even as someone who program mainly in C# (on Mac/Linux) and some knowledge about the UWP disaster^W situation this is a mess cery hard to understand and not appealing to develop for.
why is it a problem that they release new api's? they couldn't bring them all out before they're written, so the alternative is to batch them up and release them all at once.
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.)
I as a developer asked for it. Always tried to develop UWP but Microsoft has made it the hardest possible to. SDKs for UWPs are many and each of them is someway incompatible with their other revision. There used to be at least 3/4 competing different "versions" of "Universal" windows platform SDKs at the same time, each of them with different features and device support (including the latest which is like Windows 10 but only from certain major updates).
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.
I did Google the number (and sure enough I've seen that strip enough times that I could have memorized everything about it, including the number), I was just curious if that's what Hamcha did before posting. If so, it would have been easier to paste the link, unless everyone has it memorized but me. If not, great nerdy feat (in the good sense)!
'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.'
Microsoft seems to have tried to unify their developer story in many incarnations now. So my biggest question is, why will this one succeed where others have failed? I see absolutely no evidence to suggest this is better than previous attempts.
Microsoft wanted to unify their developer story around UWP (in all it's incarnations) and that never took hold. This is a realization of that and re-focus on bringing all their development frameworks up to modern standards (even Winforms!)
Supporting developers were they are is likely to be much more successful than supporting developers were they wanted them to go.
The consumer Windows ecosystem (excluding games) feels moribund. When is the last time that anybody was excited about some new or improved Windows program? Everything interesting seems to be happening either on mobile or on MacOS.
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.
Anyone that wants to access any new Windows API introduced since Vista, where they re-focused on COM to deliver the ideas that failed with .NET on Longhorn.
So if you are using pure old style Win32, you will be using a view of the computing world stuck in Windows XP.
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.
Anybody who has been targeting Windows for a while will have recognised this pattern recurring every couple of years. A nice new shiny framework that within a couple of years is stuck in the twilight zone, neither dead nor pushing forward.
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.
This is all about fixing a mistake that never should have been made. They did the UWP split around the time of Windows 8 and since then have tried to prop up the Windows Store with Windows Mobile ports, XBox games, and other ventures. It’s good to see them finally recognize that the Microsoft Store wasn’t going to go anywhere.
Yep, and this fiasco was easy to predict: of course nobody (enterprises and hobbyists) would rewrite decades of legacy code to a platform that 1. wasn’t supported on the most deployed Windows version at the time 2. didn’t provide feature parity with Win32 3. imposed an ugly toolkit not adapted to desktop apps (i.e. 100% of Windows device at the time, and probably still >90% nowadays) and 4. imposed a distribution model with a very significant "store tax".
The UWP project was all about Windows Phone -- it was a platform for running more constrained and less battery-heavy applications on a phone while also allowing those apps to run on the desktop.
When their phone platform imploded, UWP suddenly didn't have a real market.
This seems more like codifying some principles/guidelines between a couple of new APIs (and hopefully everything going forward), rather than anything actually new:
* can be used in UWP and Win32 apps (with no package required for Win32)
* supported on Windows 10 versions going back several years
The list of supported languages is pretty interesting. Looks like Microsoft is pretty serious about making Rust a first class citizens for it's Windows APIs:
Would definitely be nice to see Microsoft put more resources into supporting Rust. Go has Google’s backing and Swift has Apple’s. Would be interesting if Microsoft fully embraces Rust, but hopefully without the “extend and extinguish” part.
> Project Reunion is our vision for unifying and evolving the Windows developer platform to make it easier to build great apps that work across all the Windows 10 versions and devices people use.
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.
He did, didn't he? Programming Windows 6th edition is Win8+, and I believe in this one (or another one) he delves into additional APIs like DirectWrite and whatnot.
> 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.
That's unfortunate, Petzold had a knack for summarizing the essentials succinctly and explaining necessary context.
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 :)
>>> 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 make my living with it. It's pretty much the opposite of "code free", and its problem domain is entirely orthogonal to that of "traiditional" programming in that you can't do what deep learning systems do using the traditional means, at all. Try recognizing a hotdog reliably with just some for loops and if statements. Code-wise, frameworks themselves are millions of lines of code, and then there are tens of thousands of lines of your own, often extremely gnarly stuff on top of that. And I don't expect anything that can "write itself" in my, or my children's lifetime.
> Goal is to eliminate the possibility of introducing human error into complex systems.
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.
Yeah exactly, read it as "Purchase our service and layoff your devs/dbas". Maybe actually it IS good for the business, but for ordinary workforce, meh. Also meh for people who do enjoy programming.
Same here. Choice can be good but choice between various mediocre and short lived solutions is not fun. I wish Microsoft would commit to something on the desktop and keep developing it.
Microsoft has been continuously developing the same XAML UI framework since Windows 8, and now with the WinUI 3 preview [1], the latest version of that framework is available for both UWP and desktop apps, in both native code and .NET, on Windows 10 versions back to 1803 (the April 2018 update).
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.)
They have done incompatible variations of the same thing. Whatever framework you bet on since Windows 8 would be obsolete within a few years without a straightforward upgrade path. I still don’t understand why they couldn’t stick to WPF and make it better step by step but instead chose to crank out new frameworks that did almost the same.
> Microsoft has been continuously developing the same XAML UI framework since Windows 8, and now with the WinUI 3 preview [1], the latest version of that framework is available for both UWP and desktop apps, in both native code and .NET, on Windows 10 versions back to 1803 (the April 2018 update).
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...
Sure, but they also launched Microsoft Teams as an Electron app, and rebuilt Skype in Electron. Not to mention, the famous VS Code is Electron—you could argue Microsoft bought that one, but they've had ample time to transition it, and have not.
Teams and Skype both have web versions. The Skype team even said [1] that this is why they chose React over Xamarin. Given Microsoft's recent work on React Native for Windows and Mac, I wonder if the desktop versions of Skype will transition to it and away from Electron. (I work at Microsoft, but I have no inside knowledge about this.)
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).
As a user, I want all the apps on my computer to behave in a consistent way. In theory, this should be possible regardless of how apps are programmed, but in practice, using a consistent UI framework appears to be a prerequisite. On my Mac, it is very obvious when an app hasn't been built with either Carbon or Cocoa. And on Windows, the overall lack of consistency across everything is equally obvious.
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.)
I assumed this was party planning for the original team who wrote Microsoft Project and clicked just to see if there was a Gantt chart to show who was going to buy beer and the estimated lead time.
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.
Polyfills are a problem since you have to bundle them even if your version supports the new features... unlike the web where you can use the user's browser info to send them the correct polyfill these new applications will get larger and larger.
Unlike the web, Microsoft can distribute "polyfills" efficiently and without silly bundling: either preemptively as Windows updates and/or by downloading them and making them permanently available the first time the user installs or runs an application that needs them.
Parsed that as "Microsoft Project" Reunion. Like a dinner where the devs and pms from the Project planning application reminisce about old times, before daily standups and stories and sprints and...scrum masters.
WebView2 isn't a replacement for Electron; it's a replacement for the Internet Explorer powered WebView component that's been a part of Windows 10 since the beginning. WebView2 doesn't have the same level of platform APIs that Electron provides. While you totally could build a similar app using WebView2 as you could with Electron, you're going to have to build all the non-web bits yourself.
sounds like they are serious about making an interoperability layer between older programming constructs so you can run .net core code on older frameworks
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
95 comments
[ 5.4 ms ] story [ 133 ms ] threadPossibly 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!
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?
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.
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.
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.
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
Supporting developers were they are is likely to be much more successful than supporting developers were they wanted them to go.
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.
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.
When their phone platform imploded, UWP suddenly didn't have a real market.
* 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
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.
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."
https://www.charlespetzold.com/about/
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 :)
[1] https://news.ycombinator.com/item?id=23237086
With the exact same choice of languages available in 1998?
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.)
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 beleive in latter. Are you?
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