Comment by criddell
8 years ago
In Microsoft's defense, they also tend to support their stuff for a long time. I work with MFC every day. It's 20+ years old and still being developed.
8 years ago
In Microsoft's defense, they also tend to support their stuff for a long time. I work with MFC every day. It's 20+ years old and still being developed.
I stumbled over a few bugs in WPF (worked in WPF3.5, would hang in WPF4), which were, for at least 4 years, documented and "WONTFIX" with no acceptable workaround (workaround provided slows things down by a factor of 10 under some circumstances).
Maybe it's fixed with the reinvigorated WPF on Win10. I don't care anymore, but I do caution anyone to ever use any MS Technology younger than 15 years.
I'd say .Net Core is worth considering, but no real UI story as of yet... pretty nice for services though.
OMG. MFC ? You mean Microsoft Foundation Classes ? mmh. that stuff is still supported ? eventhough there was/is all the .NET crazyness. That's actually pretty good of MS. I guess the main question is: how do you in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ?
Maybe there's a cautionary tale about being an early adopter here. I don't know if I would start a new project with MFC, but it was a fantastic decision in 1996.
In a way, I think it's harder to pick technologies today for large projects. It seems like if something isn't new and growing steadily, it's stale and fading fast. What are the tools and frameworks with a long, healthy middle age ahead of them? I'm learning Go right now because there are a couple of web services I need, but I'm not that confident that I'll be able to run the same code for the next 20 years.
Kind of, OWL and VCL were much better technology but Borland's management...
1 reply →
Erlang, for instance? Picking up a new shiny thing and complaining that it's not something with a proven track of backward compatibility is not a rational thing to do.
As someone that worked on migrations to Silverlight and then to UWP, I still don't understand why these are seen as such big deals. The APIs were more similar than they were different and XAML is still XAML. (The only big loss from Silverlight was being able to browser-host it, but even then that was probably worth losing for the greater good to avoid terrible plugin websites.) The only thing they really dropped was Silverlight as (an unnecessary) brand name.
If they had semvered the whole thing: Avalon => UWP 0.x, WPF => UWP 1.x, Silverlight => UWP 2.x, Windows 8.1 UAP => UWP 3.x, today's UWP ~=> UWP 4.x, I don't think any developer would have blinked, I feel like we'd have a lot fewer people feeling they dropped support for things... Then again, developers like to complain when their cheese is moved, it could be just like Python 2 versus Python 3 or VB6 versus VB7.
At the mean time we are celebrating 10 years with the same UI engine: https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-o...
The only major thing: added Direct2D H/W accelerated backend to support high-DPI and multi-DPI systems. Yet incremental addition of CSS features.
You couldn't just port from WPF to Silverlight. They took away tons of features. WinRT was even worse. No idea about UWP but I don't care anymore.
12 replies →
These frameworks are by no way equivalent. Silverlight was running on multiple versions of Windows and Mac OS. It should have being kept just for that awesome feature.
On the other hand Win8/10 apps don’t run on anything than the OS they were released on. Which is totally laughable because it means choosing the MS stack allow one to target less Windows OSes than third party tools. So these SDK were doomed from the beginning as thay couldn’t leverage the existing Windows userbase.
> how do you [know] in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ?
If it is old, it will be supported for a long time. If it is new, the odds are mostly on it not surviving. Ever wondered why so many people insist on using outdated stuff?
You get a better deal from open source. But even there you may not like the possible consequences of using non-mainstream things.
They support the stuff they can't kill for a long time.
You can still run VB6 apps but try running a .net framework 1.0 app!
Easy, just get the runtime from here.
https://www.microsoft.com/de-de/download/details.aspx?id=162...