4 ms·

The replacement of icons is a smaller challenge than eliminating Win32 though. Perhaps such a small start would be beneficial to exude a feeling of quality and

The replacement of icons is a smaller challenge than eliminating Win32 though. Perhaps such a small start would be beneficial to exude a feeling of quality and not "more stuff has been taped on!". As it turns out, I don't think they will ever do away with Win32 as UWP uptake is very small (it's just a COM subset after all, just not IUnknown), and 90% of all other apps use Win32 (including every single "desktop" Windows app like Explorer, Notepad etc. etc...)

WorldMaker 10y ago
Smaller challenge, perhaps, but still a challenge and returning to my original point: these are icons in Win32 DLLs that they may have no other reason to touch. If their goal is to leave them alone until such time as they can remove them, them why spend time updating icon resources they can better use elsewhere? Supposedly any touch to Win32 requires testing multiple decades worth of software for backward compatibility breaks. Even something as seemingly innocuous as updating icon resources could break things. (Don't believe me? Spend some time reading the archives of Raymond Chen's Old New Thing blog and see some of how crazy backward compatibility in Win32 gets...) I don't expect we'll see the end of Win32 anytime soon, but I'm willing to bet we might see it shuffled into a virtual machine/container eventually. UWP uptake is not as small as you imagine, it's more like a COM superset, and many "built-in" Windows "desktop" apps have converted to UWP already (Edge and Calculator for two examples) or seem to be well along in the process (Settings has replaced a majority of the Control Panel now and on track to replace all of it, except for backward compatibility with million year old plugins). (Explorer might never, again for backward compatibility reasons, but it's already a hybrid and likely to continue to be hybridized or it may even be replaced instead, like Edge replaced IE.) Again, the Carbon/Cocoa analogy seems the most apt one I can make here. It's a process that will take time, and even Apple didn't do the equivalent changes overnight.
- 72deluxe 10y ago
  I am aware of Calculator and Edge being UWP, which explains Calculator's poor startup time and needless splash icon on loading. Settings really hasn't replaced Control Panel in the slightest - each item you open in Settings typically opens the items from Control Panel if you go beyond the entry level stuff (all just COM components anyway). Settings happens to be a needless frontend to the same items, but with reduced functionality and a titlebar that ignores the system colour settings (it's always grey despite your settings). For example, try this: 1. Settings let you choose desktop colours. It does not let you choose a custom colour. Open Settings > Personalisation > Background and choose "Solid Color". You have a limited choice of a few colours. 2. Open Control Panel > Personalisation > Desktop Background. This now opens the Settings app, annoyingly. 3. Run control.exe /name Microsoft.Personalization /page pageWallpaper This will bring up the magical missing dialog (not accessible from any GUI) where you can actually set a custom colour by clicking the "More..." button at the bottom. Setting a custom colour makes the Settings window show the wrong colour for your desktop background, as it isn't in its feebly small selection of colours. So the settings app has reduced functionality that the other existing items in the system that they haven't properly removed or tidied up. Why add another settings app that has less functionality? Is this the future? I would stand by my original point that instead of writing new things, why not make the existing items consistent? Icons would be a good start, let alone behaviour like I have detailed above. Why not make the Start menu search use the NTFS index instead of being dog-slow etc? Why do we have 3 different right-click menus? Did we need 2 new ones in Edge and on the Start menu? They can write 2 new menus and an entire Settings frontend but not new icons? Also, they can successfully change icons in DLLs with no side effects - look at Shell32.dll and observe the new jaunty angled "My Computer" / "PC" icon compared to Windows 7, and stuff didn't break when they changed it. See also the new Recycle Bin (whilst they have also kept the old Recycle Bin icon which isn't used anywhere). It's a mess. EDIT: BTW, the Cocoa analogy is a good one. It will take time for these things to change in Windows, if they actually bother making the changes. I am not convinced they will. I wonder if they'll just leave it all as it is (like they have done) whilst adding new stuff to duplicate the existing functionality of old stuff. And what are we meant to do with this 2 million+ lines of MFC codebase we have? What future does MFC have? There is silence on the matter. All in all it doesn't instill confidence at all. I feel that that small simple changes (like icons) would lead to a better feel of the OS, particularly to the non-techy user who doesn't care about Win32/UWP. And to us end-users who are more techy, it would feel less like a giant rolling ball of 25 years of different technologies, covered in mud.
  - WorldMaker 10y ago
    «And what are we meant to do with this 2 million+ lines of MFC codebase we have? What future does MFC have? There is silence on the matter. All in all it doesn't instill confidence at all.» Wasn't MFC deprecated in favor of ATL a long time ago, and that in turn deprecated in favor of WTL? All three of which now seem deprecated in favor of C++/Cx. I haven't kept up with C++ that well, but I don't think MFC has had a future for a long time. I don't think Microsoft has been that silent on it either, albeit the communication has shifted and evolved over the years as Microsoft settled their COM/.NET/UWP approaches... What you could do with that codebase today is use the Desktop App Converter to wrap it in a UWP package (.appx). Once converted you could also slowly start to migrate to C++/Cx and UWP APIs and XAML screens. There are a bunch of Microsoft blogs about that if you wanted to read more.
    - 72deluxe 10y ago
      As it turns out, this problem is really my employer's problem. I suspect many other software vendors have the same problem with these festering codebases. Hopefully my employer will being making moves to other frameworks some time soon (and first things first off C++2003)...
  - 72deluxe 10y ago
    Just replying to myself to say that this is all obviously a bit of a "first world" problem, and these annoyances are small problems in the grand scheme of things. I realise I appear to come across as frothing at the mouth regarding the state of these issues as they are irritating, but they aren't the biggest problems in my life, or anyone's lives for that matter, nor should they be!

WorldMaker 10y ago

Smaller challenge, perhaps, but still a challenge and returning to my original point: these are icons in Win32 DLLs that they may have no other reason to touch. If their goal is to leave them alone until such time as they can remove them, them why spend time updating icon resources they can better use elsewhere? Supposedly any touch to Win32 requires testing multiple decades worth of software for backward compatibility breaks. Even something as seemingly innocuous as updating icon resources could break things. (Don't believe me? Spend some time reading the archives of Raymond Chen's Old New Thing blog and see some of how crazy backward compatibility in Win32 gets...) I don't expect we'll see the end of Win32 anytime soon, but I'm willing to bet we might see it shuffled into a virtual machine/container eventually. UWP uptake is not as small as you imagine, it's more like a COM superset, and many "built-in" Windows "desktop" apps have converted to UWP already (Edge and Calculator for two examples) or seem to be well along in the process (Settings has replaced a majority of the Control Panel now and on track to replace all of it, except for backward compatibility with million year old plugins). (Explorer might never, again for backward compatibility reasons, but it's already a hybrid and likely to continue to be hybridized or it may even be replaced instead, like Edge replaced IE.) Again, the Carbon/Cocoa analogy seems the most apt one I can make here. It's a process that will take time, and even Apple didn't do the equivalent changes overnight.

72deluxe 10y ago
I am aware of Calculator and Edge being UWP, which explains Calculator's poor startup time and needless splash icon on loading. Settings really hasn't replaced Control Panel in the slightest - each item you open in Settings typically opens the items from Control Panel if you go beyond the entry level stuff (all just COM components anyway). Settings happens to be a needless frontend to the same items, but with reduced functionality and a titlebar that ignores the system colour settings (it's always grey despite your settings). For example, try this: 1. Settings let you choose desktop colours. It does not let you choose a custom colour. Open Settings > Personalisation > Background and choose "Solid Color". You have a limited choice of a few colours. 2. Open Control Panel > Personalisation > Desktop Background. This now opens the Settings app, annoyingly. 3. Run control.exe /name Microsoft.Personalization /page pageWallpaper This will bring up the magical missing dialog (not accessible from any GUI) where you can actually set a custom colour by clicking the "More..." button at the bottom. Setting a custom colour makes the Settings window show the wrong colour for your desktop background, as it isn't in its feebly small selection of colours. So the settings app has reduced functionality that the other existing items in the system that they haven't properly removed or tidied up. Why add another settings app that has less functionality? Is this the future? I would stand by my original point that instead of writing new things, why not make the existing items consistent? Icons would be a good start, let alone behaviour like I have detailed above. Why not make the Start menu search use the NTFS index instead of being dog-slow etc? Why do we have 3 different right-click menus? Did we need 2 new ones in Edge and on the Start menu? They can write 2 new menus and an entire Settings frontend but not new icons? Also, they can successfully change icons in DLLs with no side effects - look at Shell32.dll and observe the new jaunty angled "My Computer" / "PC" icon compared to Windows 7, and stuff didn't break when they changed it. See also the new Recycle Bin (whilst they have also kept the old Recycle Bin icon which isn't used anywhere). It's a mess. EDIT: BTW, the Cocoa analogy is a good one. It will take time for these things to change in Windows, if they actually bother making the changes. I am not convinced they will. I wonder if they'll just leave it all as it is (like they have done) whilst adding new stuff to duplicate the existing functionality of old stuff. And what are we meant to do with this 2 million+ lines of MFC codebase we have? What future does MFC have? There is silence on the matter. All in all it doesn't instill confidence at all. I feel that that small simple changes (like icons) would lead to a better feel of the OS, particularly to the non-techy user who doesn't care about Win32/UWP. And to us end-users who are more techy, it would feel less like a giant rolling ball of 25 years of different technologies, covered in mud.
- WorldMaker 10y ago
  «And what are we meant to do with this 2 million+ lines of MFC codebase we have? What future does MFC have? There is silence on the matter. All in all it doesn't instill confidence at all.» Wasn't MFC deprecated in favor of ATL a long time ago, and that in turn deprecated in favor of WTL? All three of which now seem deprecated in favor of C++/Cx. I haven't kept up with C++ that well, but I don't think MFC has had a future for a long time. I don't think Microsoft has been that silent on it either, albeit the communication has shifted and evolved over the years as Microsoft settled their COM/.NET/UWP approaches... What you could do with that codebase today is use the Desktop App Converter to wrap it in a UWP package (.appx). Once converted you could also slowly start to migrate to C++/Cx and UWP APIs and XAML screens. There are a bunch of Microsoft blogs about that if you wanted to read more.
  - 72deluxe 10y ago
    As it turns out, this problem is really my employer's problem. I suspect many other software vendors have the same problem with these festering codebases. Hopefully my employer will being making moves to other frameworks some time soon (and first things first off C++2003)...
- 72deluxe 10y ago
  Just replying to myself to say that this is all obviously a bit of a "first world" problem, and these annoyances are small problems in the grand scheme of things. I realise I appear to come across as frothing at the mouth regarding the state of these issues as they are irritating, but they aren't the biggest problems in my life, or anyone's lives for that matter, nor should they be!