Hacker News Reader

Comment by tzs | Hacker News Reader

> 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.

View on HN

>>> 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 ;)

> Era of developing software as visual metaphor is upon us.

I've been hearing this for about 25 years. Yet none of the software I actually use is developed that way.

Yes, but now we have DeepLearning or something... I'm sure it will be different this time.

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.

I think the poster you are replying forgot to add the '/s'

Adding /s is almost always pointless. People who understand sarcasm don't need it, and everyone else doesn't know what /s means.

> 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.

Low code + Heavy cloud is good for MS and business but not sure if it's good for programmers...

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.)

[1]: https://blogs.windows.com/windowsdeveloper/2020/05/19/introd...

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...

Office uses it. React Native for Windows bindings are made on top of UWP/WinUI.

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).

[1]: https://microsoft.github.io/reactxp/blog/2017/04/06/introduc...

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.)

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.

Yep! I've been using the 6th edition recently, it's great for understanding the principles of UWP development.

It's still remarkably useful for a book that was published in 2013, but we are probably overdue for a "version 6.5".

> 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.

If there's another edition, it won't be from him, sad to say.

> "In September 2018 I retired from my 34-year career of writing, speaking, and thinking about application programming interfaces."

https://www.charlespetzold.com/about/

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 :)

[1] https://news.ycombinator.com/item?id=23237086

> I just want it to be like it was in 1998.

With the exact same choice of languages available in 1998?

Visual C++ 6 and Visual Basic 6. I remember them fondly but there were plenty of warts.

And Delphi

Reply on news.ycombinator.com