Coming over the summer, Microsoft is going to add integrated call recording (something that previously required third-party applications and a deprecated API), read receipts to show when a message recipient has read a message, and end-to-end encryption of text and audio chat using the Signal protocol.
Microsoft is also making Skype audio and video calls easier to integrate into streams such as those used on Mixer and Twitch. Support for the NDI API means that streaming applications such as Xsplit and OBS can use a Skype call as an audio/video source. That means they can be overlaid on games or other content, just as is already done with webcam input.
[…]
There is, however, a price to pay for this: the traditional Win32 Skype client is being end-of-lifed and will not be supported beyond the end of August this year. Users of the Win32 client will have to upgrade to Skype 8.0 (the desktop version of the new unified app) in order to be able to continue to use the network.
Another staple Win32 application bites the dust. Don’t read anything into it though, since people still seem convinced Win32 has a future.
We have achieved “usable” status for plenty of Win32 applications on the Linux kernel via Wine, and ReactOS was actually stable (in a VM, though). However I don’t know about any effort to bring UWP to these platforms. In fact, I think there might be some serious DRM to slow down such an efoort.
On the other hand the situation is reversing wrt cross-platform support. Windows kernel can run entire Linux distributions natively (thanks to being a semi-micro-kernel), and people can easily migrate docker setups to them.
Linux is still my primary development platform. However if this trend continue, now Linux might lose another important category of users.
Given gaming and design required either Windows (or to a limited extend Mac), and servers are so-so it might not be a good outcome for Linux at least in the medium run.
Edited 2018-07-17 23:47 UTC
I am starting to wonder if the acceleration of depreciation of Win32 is related to how good ReactOS and Wine are becoming at running Windows applications.
Some people are advocating for the disappearance of Win32 from the Windows code base for many valid technical reasons.
There is likely a commercial motive in burning this legacy bridge as fast as possible.
That seems like a bit of a non-sequitur. Microsoft can do whatever they want with their own applications and spend however much money they want on rewriting them. The question is whether they’ll be successful in getting the rest of the ecosystem to abandon the Win32 API.
This is sort of like saying that, because Microsoft poured so much effort into creating Windows Phone, Android’s days must surely be numbered.
(Remember, throughout their history, the competitive edge for Microsoft Operating Systems has been their excellent compatibility with users’ old software, and progress has been accomplished by giving companies good reason to upgrade to newer APIs. I’m skeptical that UWP provides sufficient incentive.)
Edited 2018-07-18 00:49 UTC
Indeed – Thom is not a professional software developer and therefore hasn’t experienced the discussions that happen on any team with a large codebase.
If I told my boss that we have to rewrite our program to make it an UWP app he’ll say we won’t be doing that. In fact, most management aren’t technical people and tend to think everything should be done in a web browser nowadays. The only reason they haven’t forced us to rewrite the win32 app already are the costs. A rewrite solution from Microsoft would result in us leaving the (desktop) platform.
So either Microsoft effectively lets us recompile our app as UWP or it won’t happen. Now, they have made some attempts at allowing this, but even now there is basically no benefits whatsoever in making it UWP. We won’t sell more copies. And so it will always be pushed to the next milestone.
Thom likes to mock people for being fans of corporations, pointing out they are only always self-serving. But he constantly seems to make the mistake thinking smaller corporations will put massive amounts of resources into changing frameworks for some minor improvement. I wouldn’t call him out directly if it wasn’t for the constant statements as “facts” he likes to do at the end of each posted story.
UWP is a shitty proposition for anyone else but Microsoft. There’s a reason virtually nobody outside Microsoft creates apps for this ecosystem aside from a few Microsoft fans here and there. If you think we are all wrong, please explain to us exactly what is so great about this deal and why it will turn out differently. Don’t forget, every change request to software begins with -100 points multiplied with how long time it will take to implement.
Sure, because you are going to write them in Gtk+ or Qt instead.
Sure, because we have seen how everyone has migrated to Linux when they made some APIs Vista only.
.NET is on the path to have all former .NET Framework applications UWP compatible by the time .NET Core 3.0 with Forms, WPF and EF6 support comes out alongside .NET Framework 8 next year.
As for legacy C and C++ Win32, they will be dragged into this new shinny world.
https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-…
C++/WinRT framework which replaces the C++/CX dialect with a framework written C++17 and modernized IDL compiler is already here as well.
Edited 2018-07-18 07:25 UTC
You’ve misspelled “shitty” there.
I have yet to see a single UWP app that has all the features of the apps they’re supposed to be replacing. Several of the ones I’ve tried to use (Mail, To-Do, Wunderlist) just stop accessing the Internet after a while if you leave them running. Groove Music can’t seem to see all of my MP3s, let alone the FLAC stuff. OneNote is half-assed compared to the Win32 version… it’s missing a huge amount of features.
Actually, I’ve just realized I’m slightly wrong; UWP Enpass has the same feature set as the Win32 version. I’m pretty sure it’s just one of those recompiles (the version in beta right now is a redesign).
I guess the UWP Weather app works pretty well, although I only run it when I want to see weather details; I’ve got a Win32 app (Rainmeter) on-screen for weather-at-a-glance. Photos seems pretty OK for what I do with that sort of thing (hardly anything), but again, I don’t leave it running.
I honestly gave UWP a fair try, but it’s constantly disappointing, at least for me.
Bloom berg had an interesting artcle about skype’s falling from grace back in may.
https://www.bloomberg.com/news/articles/2018-05-10/don-t-skype-me-ho…
…toward win32 ?
It’s perfectly functional for decades now, not very secure, sure, but works like intended. That you add new functionalities by new means ‘UWP’, if you want, but removing win32 won’t make Windows’ update any less heavy.
Rusty C API, holding back modern OS design.
Well, nothing has
otherwise .Net and other toys wouldn’t be there.
Edited 2018-07-18 12:09 UTC
Win32 is past its due date.
In case you haven’t been paying attention, the Longhorn ideas based on .NET were redone as COM APIs in Vista.
Since Vista, the majority of new APIs are all COM based, which evolved to what is now UWP.
The majority of my .NET code runs perfectly fine across .NET Framework, .NET Core and UWP.
My other Windows toy, DirectX, also runs perfectly fine in UWP.
Good to you that you embraced .NET and now despise win32. Fun that win32 was good enough for decades and .NET haven’t brought much revolution beside clogging the hard drive with many versions.
I don’t despise Win32.
In fact I consider it much better than anything that derived from UNIX, with exception NeXTSTEP and OS X.
I have been coding for Microsoft platforms since MS-DOS 3.3, and it has served me well all these years.
Win32 has served its dues, just like those that came before it.
Those that don’t embrace the future get stuck in the past.
I embrace the future, but not just a dumb alternative to win32 because it is marketed as a “revolution”.
BeOS was a revolution with a true object oriented API and journaling FS, but where is it now ?
Don’t paint me old fashioned, I’m for a real advancement in operating system, not just half cooked evolution.
.NET has not brought much of a revolution over Win32? Wow.
Are you a developer?
You think that programming in C# or F# against the .NET Base Class Library is basically the same as programming in C against Win32 or even C++ with MFC ( a wrapper around Win32 )? Even just the shift to managed languages over a VM is a massive change without even talking about the API. And Win32 is just an API by the way. It is not “desktop” Windows vs UWP.
From a GUI stand-point, I think you could argue that the earliest .NET GUIs like Windows Forms were just wrappers around Win32. Windows Presentation Foundation ( WPF ) certainly is not though and again is a revolution compared to Win32 even though it still only applies to Windows-only “desktop” applications.
The fact that I can create a .NET assembly ( DLL ) that works unmodified on the Windows desktop, other desktops ( eg. OS X ), on the web, or on a mobile phone is not a revolution? I guess you must do that all the time with Win32.
As far as I can tell, UWP applications are all dumbed-down nanoapps that would look at home in Android Go. Giant click targets, sparse layouts, feeble functionality, and making a point of patronising the user. Then maybe I have used a serious UWP app without noticing… Is Visual Studio a UWP? I guess not.
I don’t need apps to treat my desktop screen as a giant smartphone. I’ve already got a smartphone, and it fits in my pocket (only just!)
Microsoft should take their own applications seriously if they want the world to follow their lead: Mail, Code Writer, Paint 3D, Calendar, Calculator, Photos… every applet in Windows is a completely useless toy. I’d like to try Office UWP, but I ain’t paying when LibreOffice gives me for free mostly all I need.
MS, who creates and pushes UWP, has ported one of their apps to it. I’m sure everyone else will follow right along!
“Fluent Design System inside of Microsoft: Office”
https://channel9.msdn.com/Events/Build/2018/THR2426
I believe a lot of the comments here are assuming a false dichotomy. The conversation was started as Win32 vs UWP and has devolved into Win32 vs .NET. These are not the same thing.
Universal Windows Platform ( UWP ) and Win32 are competing Application Programming Interfaces ( APIs ). Win32 is a C API. UWP is a C++ API. These really are alternatives for each other. Microsoft has put some work into making them interoperate but I believe that UWP is intended to be a replacement for Win32. UWP is designed to be cross-platform. Win32 is basically Windows only.
So what about Win32 vs .NET?
First of all, .NET is not required for UWP. UWP itself is written in C++ ( not a .NET language ). You can write UWP programs using C++, C#, F#, VB.NET, or JavaScript. A UWP application does not have to be a .NET application.
Second, you can target Win32 with .NET and most “desktop” .NET applications are doing just that ( although probably indirectly ). A Win32 application may be a .NET application too.
Most “desktop” Windows applications are not written in Win32 directly ( eg. using C to directly call the Win32 API ). C++ programmers would probably use something like MFC or Qt for example. Under the hood though, Win32 libraries are doing all the work. The same is really true of most .NET Windows applications as well.
Windows Forms, the first .NET GUI, is just a thin layer over Win32 that allows Win32 applications to be written using managed languages like C#. Windows Forms is really just a newer version of MFC. Windows Presentation Foundation ( WPF ) is a major departure from the Windows Forms model but, deep down, WPF is really just running on Win32 as well. It is why Microsoft cannot make WPF portable ( even though it is a .NET only framework ).
.NET was invented to unlock developer productivity. The primary motivation was to move to managed languages like C# instead of systems languages like C++(1).
UWP was invented to address the challenge of portability. As a UI framework, it was also meant to encourage human interfaces that work not only on the desktop but on mobile devices and game consoles. Again, this is really a portability goal.
In my view, all the hate comes from not liking the re-imagined portable user interface when working on the desktop. To be honest, I do not like it either. I still pull up the classic Control Panel when working with Windows 10. This really has nothing to do with .NET per se though. The only link is that both .NET and UWP are both “current” together.
I have no idea what the “Win32” ( desktop ) Skype client was written in but it could easily have been C# ( .NET ). In other words, it could be the .NET version that is being retired.
I have no idea what the UWP Skype client is written in but it could be C++. In other words, it may not be .NET at all.
There is pretty good chance the UWP version of Skype is written in a .NET language ( like C# ). That is what I would have written it in. All that means though is that C# is nicer to work with than C++ ( in my opinion ). All it says is that the promise of .NET has delivered regardless of what you think about the promise of UWP.
(1) .NET was also intended to make writing web application more like writing desktop applications but that is a tangent to this discussion. That is where the name Web Forms came from in ASP.NET though ( Web Forms as the web version of Windows Forms — an alternative to classic ASP ). .NET was also designed to make applications portable in that they were not tied to specific hardware. The important point above though is that .NET was not created as a way to make Windows applications portable off Windows. In that way, the goals of UWP and of .NET overall are pretty different. With the introduction of .NET Core, Microsoft is bringing the idea of portability away from Windows part of .NET as well but .NET Core is an even newer idea than UWP.
I don’t know if Microsoft took it through any intermediate forms, but it was Qt-based when Microsoft bought Skype.
Cool. That makes sense. Qt is probably the most popular GUI toolkit on Windows ( outside Microsoft at least ). The move to UWP for Skype might have been a bit of Not Invented Here as Qt is foreign tech ( cynical speculation ). Qt and Microsoft have a history though as Qt was previously owned by Nokia and a good chunk of Nokia was absorbed into Microsoft.
Given that Skype was written in C++, I expect that the UWP version is probably C++ too. Not only is C++ a good fit for the low-level performance requirements of Skype but it would mean being able to reuse most of the existing engine / communications code when moving to UWP.
To echo my other comments, if the UWP version of Skype is C++ based, it is not a .NET application.
Sky was initially written in Qt for other platforms and Delphi for Windows.
The rebooted version makes use of React Native for the UI.
https://www.windowscentral.com/microsoft-updating-its-skype-app-wind…
https://github.com/Microsoft/react-native-windows
The first class UWP languages are JavaScript, C++, VB.NET and C#.
I also thought back then that it would make sense, but AFAIK it’s not true
( http://www.osnews.com/permalink?660263 )
No, only the UI of Linux version was Qt-based, the UI of Windows version was, back then, made in Delphi; and of Mac, in Objective-C/Cocoa – essentially, each in at least sort of ~native toolkit of given platform.
Bit of an odd choice, really, given how much Delphi costs and that you’d have to maintain multiple codebases.
Edited 2018-07-21 02:56 UTC
Qt cost Skype too, it isn’t all free after all, they needed commercial license to develop a closed-source app… But yeah, kinda odd, I thought back then that multiplatform Qt Skype would make more sense; oh well, it’s not what they did… (maybe they liked large pool of Delphi-knowing devs, back then it was still quite popular at programming ~schools in parts of Europe, probably also in Estonia where Skype is based; or perhaps they simply didn’t thought much about multiplatform when they started Skype)