4 ms·

Not a well-written article, but some good points. Concerns of mine: * We /still/ don't know the contents of the telemetry Microsoft sends back; hubbub seems t

Not a well-written article, but some good points. Concerns of mine: * We /still/ don't know the contents of the telemetry Microsoft sends back; hubbub seems to have died down. Do we just not care? * Undocumented APIs. Remember when MS had hidden or secret APIs used by, eg, Office, they were forced to document? Those days are back. Consider the APIs for the Acrylic UI, which is implemented in the WinAPI (not .Net) but is only accessible from .Net applications. That's tie-in making it attractive for devs to use only MS products for development, too. * Incomplete. There are still settings not in the new Settings app that are found in the Control Panel. Counting from Windows 8 in 2012, that's over five years of incomplete settings. * Buggy. Creator's Update introduced a bug loading DLLs that made thousands of apps slower to start, and made debugging them close to impossible - all because they changed the module loading code. It looks like they only tested with modules built by Visual Studio, not third party dev tools, and so broke debugging for those developers for... how long? Six months. It wasn't fixed until the Fall Update. I could go on. The first two are the most important to me, and I believe should be to other developers too.

ThrowawayR2 9y ago
> We /still/ don't know the contents of the telemetry Microsoft sends back; hubbub seems to have died down. Do we just not care? Don't you think there are large numbers of security researchers out there just dying to make a name for themselves and to give "M$" a black eye? Unless you believe they're all asleep at the wheel, the only reasonable conclusion is that they've pored all over the Windows telemetry and found nothing worth remarking about. (... just like the telemetry in every web site, mobile phone, and other apps that we consumers now have to put up with. Telemetry is the rule of the day now.)
- Silhouette 9y ago
  It doesn't matter. If you have an OS that can update itself arbitrarily without your permission and you have a culture and legal agreements that allow uploading ambiguous amounts of data through telemetry systems, that OS is not a viable choice for anyone who takes security and privacy seriously and deals with potentially sensitive data. It's really as simple as that. My businesses have legal obligations under things like data protection legislation (for handling personal data) and our contracts with clients, suppliers, etc. (for handling trade secrets and other commercially sensitive information, as well as compliance with industry rules in areas like payment processing). Hand-wavy arguments about how everyone is using telemetry now do not relieve us of those obligations.
WorldMaker 9y ago
> We /still/ don't know the contents of the telemetry Microsoft sends back Documentation site: https://docs.microsoft.com/en-us/windows/configuration/windows-diagnostic-data https://docs.microsoft.com/en-us/windows/configuration/windo... > Consider the APIs for the Acrylic UI, which is implemented in the WinAPI (not .Net) but is only accessible from .Net applications. The Acrylic controls are XAML controls built on System.Composition [1] and Windows.UI.Composition [2] APIs. C++ (and any language that can compile to it) has access XAML and System.Composition just like .NET, it just needs to speak WinRT. C++/WinRT was just released in the Windows SDK which just uses "real" C++ headers and no language extensions to interface with WinRT. [3] That should make it even easier for other languages to explore how to support WinRT applications, which for the most part if a language can support COM it can figure out how to support WinRT. Complaining that you need WinRT to access modern UI effects seems a bit like complaining you need DirectX to access modern GPUs and can't just brute force VGA bit buffer your games anymore. (My only complaint with the Fluent UI APIs is there doesn't seem to be access from the HTML/JS side of the fence, given that's the important "third platform" after C++ and .NET. I'd like to see PWAs have the ability to use at least some of the Fluent and/or Acrylic effects, but I haven't seen a useful sample of that yet.) [1] https://msdn.microsoft.com/en-us/library/jj126278.aspx https://msdn.microsoft.com/en-us/library/jj126278.aspx [2] https://docs.microsoft.com/en-us/uwp/api/Windows.UI.Composition https://docs.microsoft.com/en-us/uwp/api/Windows.UI.Composit... [3] https://msdn.microsoft.com/en-us/magazine/mt745094.aspx https://msdn.microsoft.com/en-us/magazine/mt745094.aspx
- vintagedave 9y ago
  Unfortunately, that reply reflects many of the problems I highlighted in my comment. You have missed the point. I'm aware that Acrylic controls are XAML only. I'm referring, though, to the UI support itself: glass, blending, the small amount of noise added, etc. In Windows 10, glass is not supported any more - except it is, because it is used in Acrylic. How? Well, using the same APIs as glass in Win7, but with small tweaks that are undocumented. Some people including myself have attempted to reverse engineer some of the new flags that are required. It looks likely that Acrylica can be completed done in a plain old WinAPI app using glass and a Direct2D canvas - except that some of that is undocumented. If I'm wrong here, and you can point me at non-.Net API documentation, please do. > Complaining that you need WinRT to access modern UI effects seems a bit like complaining you need DirectX to access modern GPUs That's not what I said. You do not need WinRT to access modern UI effects, but Microsoft seem to be requiring to you to use WinRT to access modern UI effects. That is, requiring you to use their libraries, their development tools, and so forth. It is not open, and it is anti-competitive.

ThrowawayR2 9y ago

> We /still/ don't know the contents of the telemetry Microsoft sends back; hubbub seems to have died down. Do we just not care? Don't you think there are large numbers of security researchers out there just dying to make a name for themselves and to give "M$" a black eye? Unless you believe they're all asleep at the wheel, the only reasonable conclusion is that they've pored all over the Windows telemetry and found nothing worth remarking about. (... just like the telemetry in every web site, mobile phone, and other apps that we consumers now have to put up with. Telemetry is the rule of the day now.)

Silhouette 9y ago
It doesn't matter. If you have an OS that can update itself arbitrarily without your permission and you have a culture and legal agreements that allow uploading ambiguous amounts of data through telemetry systems, that OS is not a viable choice for anyone who takes security and privacy seriously and deals with potentially sensitive data. It's really as simple as that. My businesses have legal obligations under things like data protection legislation (for handling personal data) and our contracts with clients, suppliers, etc. (for handling trade secrets and other commercially sensitive information, as well as compliance with industry rules in areas like payment processing). Hand-wavy arguments about how everyone is using telemetry now do not relieve us of those obligations.

WorldMaker 9y ago

> We /still/ don't know the contents of the telemetry Microsoft sends back Documentation site: https://docs.microsoft.com/en-us/windows/configuration/windows-diagnostic-data https://docs.microsoft.com/en-us/windows/configuration/windo... > Consider the APIs for the Acrylic UI, which is implemented in the WinAPI (not .Net) but is only accessible from .Net applications. The Acrylic controls are XAML controls built on System.Composition [1] and Windows.UI.Composition [2] APIs. C++ (and any language that can compile to it) has access XAML and System.Composition just like .NET, it just needs to speak WinRT. C++/WinRT was just released in the Windows SDK which just uses "real" C++ headers and no language extensions to interface with WinRT. [3] That should make it even easier for other languages to explore how to support WinRT applications, which for the most part if a language can support COM it can figure out how to support WinRT. Complaining that you need WinRT to access modern UI effects seems a bit like complaining you need DirectX to access modern GPUs and can't just brute force VGA bit buffer your games anymore. (My only complaint with the Fluent UI APIs is there doesn't seem to be access from the HTML/JS side of the fence, given that's the important "third platform" after C++ and .NET. I'd like to see PWAs have the ability to use at least some of the Fluent and/or Acrylic effects, but I haven't seen a useful sample of that yet.) [1] https://msdn.microsoft.com/en-us/library/jj126278.aspx https://msdn.microsoft.com/en-us/library/jj126278.aspx [2] https://docs.microsoft.com/en-us/uwp/api/Windows.UI.Composition https://docs.microsoft.com/en-us/uwp/api/Windows.UI.Composit... [3] https://msdn.microsoft.com/en-us/magazine/mt745094.aspx https://msdn.microsoft.com/en-us/magazine/mt745094.aspx

vintagedave 9y ago
Unfortunately, that reply reflects many of the problems I highlighted in my comment. You have missed the point. I'm aware that Acrylic controls are XAML only. I'm referring, though, to the UI support itself: glass, blending, the small amount of noise added, etc. In Windows 10, glass is not supported any more - except it is, because it is used in Acrylic. How? Well, using the same APIs as glass in Win7, but with small tweaks that are undocumented. Some people including myself have attempted to reverse engineer some of the new flags that are required. It looks likely that Acrylica can be completed done in a plain old WinAPI app using glass and a Direct2D canvas - except that some of that is undocumented. If I'm wrong here, and you can point me at non-.Net API documentation, please do. > Complaining that you need WinRT to access modern UI effects seems a bit like complaining you need DirectX to access modern GPUs That's not what I said. You do not need WinRT to access modern UI effects, but Microsoft seem to be requiring to you to use WinRT to access modern UI effects. That is, requiring you to use their libraries, their development tools, and so forth. It is not open, and it is anti-competitive.