17 Mar 2017 @ 9:59 PM 

There has been some concern and even repudiation about Microsoft’s decision to not provide updates to Windows 7, 8, and 8.1 when run on hardware using a newer processor, such as the Intel Kaby Lake processors. This has been claimed by some as a marketing move to try to “force” users to use Windows 10.

Now, I’m not the greatest fan of some of the things introduced with Windows 10. At the same time, I have no modern systems- other than Virtual Machines- not running either Linux or Windows 10. So it’s more an annoyance at how much one has to do to appropriately assert one’s desired options with Windows 10.

Windows 7 and 8/8.1 have continued to be supported as per the Windows lifecycle; the change is for hardware that was literally introduced after the end of mainstream support for both operating systems. Extended support only applies to Security updates; however, supporting security updates on Windows 7 and 8/8.1 with those Processors would mean supporting the processor. The issue there is that while the newer chips likely run the same way as older chips did with the same code, there is no guarantee of that, and it would still require the software to be tested and bugfixed specifically for those newer chips, which means effectively, supporting the new processors.

The Updates cannot go out on an “as is” basis to systems with the new processors because hten any problems will incur support costs and bugfixes to those updates that will also effectively mean supporting the new processors on the older software.

Worth noting is that this doesn’t lock out enterprising users who are willing to take the risk that their entire Win7/Win8/8.1 system will stop functioning due to said updates. One can still workaround this, it just requires you to step off the beaten path even further, making it much more clear and far “safer” for Microsoft to tell you to basically piss off if you try to get support.

It’s likely this approach may have been adopted to try to prevent another repeat of the Windows XP diehards. Mind you, it hasn’t worked so far; Many people are now Windows 7 diehards to much the same capacity. But at least- from Microsoft’s perspective- they won’t be financing it.

Posted By: BC_Programming
Last Edit: 17 Mar 2017 @ 09:59 PM

EmailPermalinkComments (0)
Tags
 24 Nov 2016 @ 10:03 PM 

There is a seemingly common affliction affecting some users of Windows where they find that their desktop icons receive old-style focus rectangles. This seems to affect Windows Vista and later.

Dotted Focus Rectangle.

After some investigation, I found the cause to be an Accessibility setting. inside Ease of Access in Control Panel, There is a “Change how the keyboard works” option. This option takes you to another page with “Underline keyboard shortcuts and access keys”. When this option is checked, Keyboard cues are enabled. This includes the underlined text of menus and buttons- but it also includes ListView Focus Rectangles, which means with the option enabled there is a Focus rectangle shown on the desktop rather frequently.

To change this setting, toggle it and reboot.

Posted By: BC_Programming
Last Edit: 24 Nov 2016 @ 10:03 PM

EmailPermalinkComments (0)
Tags
 09 Nov 2016 @ 8:30 AM 

I’ve previously written about making adjustments to the Windows Master Volume control programmatically. I alluded to the addition of possible other features such as being able to view the volume levels of other applications. I’ve gone ahead and made those changes.

The first thing to reiterate is that this makes use of a low-level .NET Wrapper for the Windows Core Audio API. This can be found here.

The first thing I decided to define was an object to represent a single Applications Volume Session info/properties. In addition, it will be provided a reference to the IAudioSessionControl interface representing that application’s Audio session, so it can be directly manipulated by adjusting the properties of the class.

Next, we need to declare a COM import, the Multimedia Device enumerator. Specifically, we need to import the class, as the Vannatech Library only provides interfaces, which we cannot instantiate:

Now that we have a starting point, we can create an enumerator method that retrieves all active audio sessions as “ApplicationVolumeInformation” instances:

A github repository with a more… complete… implementation of a working Console program can be found here.

Posted By: BC_Programming
Last Edit: 11 Nov 2016 @ 12:29 PM

EmailPermalinkComments (0)
Tags
Categories: .NET, C#, Programming, Windows
 24 Aug 2016 @ 10:32 PM 

User Account Control, or UAC, was a feature introduced to Windows in Windows Vista. With earlier versions of Windows, the default user accounts had full administrative privileges, which meant that any program you launched also had full administrator privileges. The introduction of UAC was an attempt to solve the various issues with running Windows under a Limited User Account to make the more advanced security features of Windows far more accessible to the average user. The effective idea was that when you logged in your security token, which was effectively “given” to any software you launched, would be stripped of admin privileges. In order for a process to get the full token, it would require consent, this consent was implemented via the UAC dialog, allowing users to decide whether or not to give or deny that full security token.

It was a feature that was not well received; users complained that Vista was restricting them, and making them ask for permission for everything- something of a misinterpretation of the feature and how it works, but an understandable one somewhat. Nowadays, it is practically a staple of Windows, being present in the default user accounts through 7, 8, and now 10. Even so, it has had some design changes over the years.

One interesting aspect of the UAC consent dialog is that it will differentiate between a “Verified”, or signed, executable, and an unsigned one, displaying slightly different designs based on the evaluation of the executable. A signed executable effectively includes a digital signature which is able to verify that the program has not been altered by a third party- so if you trust the certificate authority as well as the publisher, it should be safe.

Windows Vista

We start our tour, perhaps unsurprisingly, with Vista.

Vista_Verified

Vista UAC Dialog, shown for an executable with a verified signature.

Vista_Verified_expanded

Vista UAC Dialog, shown for an executable with a verified signature, after expanding the Details option.

When the executable is verified, we see a relatively straightforward request. Expanding the dialog, as shown in the second image, provides access to the application path; There is no way, within the UAC dialog, to inspect the publisher’s certificate- that needs to be checked via other means.

Interestingly, once we start looking at unverified executables, however, we see quite a different presentation:

Vista_Unverified

Windows Vista UAC Dialog displayed for a Unverified executable.

Vista_Unverified_expanded

Windows Vista UAC Dialog shown for an unverified executable, after expanding the details option.

Rather than the more subdued appearance as seen when the application is verified, the dialog displayed for an unverified application is more bold; the options are presented as TaskDialog buttons, and the entire dialog has a very “Task Dialog” feel; additionally, the colour scheme uses a more bold yellow. Interestingly, Expanding the “Details” really only adds in the file location to the upper information region. Kind of an odd choice, particularly since the UAC dialog will usually be on it’s own secure desktop and thus screen real-estate is not as valuable as it might otherwise be.

Windows 7

On Vista, elevation tended to be required more frequently and thus UAC dialogs were rather common for standard Windows operations. Users needed to give consent for many standard Windows tasks such as adjusting Windows settings. Windows 7 adjusted some of the default behaviour and it does not by default present consent dialogs for many built-in Windows operations. The design of the UAC dialog also was adjusted slightly:

Win7_Verified

Windows 7 UAC dialog on a verified/signed executable.

Win7_Verified_Expanded

Windows 7 UAC dialog on a verified executable, expanded.

For verified executables, the dialog is rather unchanged; The biggest changes we see are in the title copy “Windows needs your permission to continue” changes to an ask regarding whether the user gives permission to a particular program. The dialog now includes a hyperlink in the lower-right that takes you right to the UAC settings, and publisher certificate information is now available when the details are expanded.

Win7_Unverified

Windows 7 UAC Dialog for an unverified Program.

Win7_unverified_expanded

Windows 7 UAC dialog for an unverified program, expanded

The Unverified dialog is quite a departure from the Vista version. It takes it’s design largely from the “Signed” version of the same dialog; perhaps for consistency. It dumps the “TaskDialog” style presentation of the options, instead using standard Dialog buttons, as with the “Signed” Appearance.

 

Windows 8

Win8_Unverified

UAC dialog on Windows 8 for an unverified executable.

Win8_Unverified_expanded

UAC Dialog on Windows 8 for an unverified executable, expanded.

Win8_Verified

UAC Dialog on Windows 8 for a Verified executable.

Win8_Verified_Expanded

UAC Dialog on Windows 8 for a Verified executable, Expanded.

 

 

For the sake of completeness, I’ve presented the same dialogs as seen on Windows 8. There have been no changes that I can see since Windows 7, excepting of course that the Win8 Windows Decorator is different.

Windows 10

Win10_Nov_Unverified

UAC Dialog from the Windows 10 November Update, running an Unverified executable.

Win10_Nov_Unverified_Expanded

UAC Dialog from the Windows 10 November Update, running an unverified executable, showing details.

Win10_Nov_Verified

UAC Dialog running a Verified executable on the Windows 10 November Update.

Win10_Nov_Verified_Expanded

UAC Dialog from the Windows 10 November Update, running a Verified executable, showing Details.

 

Yet again, included for completeness, the UAC dialogs shown by Windows 10 in the November Update. These are again identical to the Windows 8 and Windows 7 version of the same, providing the same information.

 

This all leads into the reason I made this post- the Anniversary Update to Windows 10 modified the appearance of the User Account Control dialogs to better fit with UWP standards:

 

Win10_Anniversary_Unverified

Windows 10 Anniversary Update UAC dialog for an Unverified Executable.

Win10_Anniversary_Unverified_expanded

Windows 10 Anniversary Update UAC dialog for an unverified Executable, after pressing “Show Details”.

Win10_Anniversary_Verified

Windows 10 Anniversary Update UAC Dialog for a Verified application.

Win10_Anniversary_Verified_Expanded

Windows 10 Anniversary Update UAC Dialog for a Verified Application, after pressing Show Details.

 

As we can see, the Windows 10 Anniversary Update significantly revised the UAC dialog. It appears that the intent was to better integrate the “Modern” User Interface aesthetic present in Windows 10. However, as we can see, the result is a bit of a mess; the hyperlink to display certificate information appears for unverified executables, but in that case, clicking it literally does nothing. The information is presented as a jumble of information with no text alignment, whereas previously the fields were well defined and laid out. I’m of the mind that updating the dialog to UWP should have brought forward more elements from the original, particularly the information layout; The “Details” hyperlink in particular should be more clearly designated as an expander, since as it is it violates both Win32 and UWP Platform UI guidelines regarding Link Label controls. I find it unfortunate that parsing the information presented in the dialog has been made more difficult than it was previously, and hope that future updates can iterate on this design to not only meet the usability of the previous version, but exceed it.

 

 

 

 

Posted By: BC_Programming
Last Edit: 24 Aug 2016 @ 10:35 PM

EmailPermalinkComments (0)
Tags
 01 Aug 2016 @ 12:40 PM 

I like to have control over when and if my system(s) perform Update tasks. As a result, I’ve configured Windows 10 Pro via Group Policy to the option to notify that updates are available, but wait for me to install them.

For the most part, this works exactly as it did with Windows 7 and 8.1. With Win10 I sometimes get a only mildly intrusive notification which doesn’t prevent anything and just tells me  there are updates. That’s fine by me.

However, it would appear Microsoft is not in any way fine with this. At intervals, My entire screen darkens, and a single, small dialog appears stating that “Important Updates are Available”. This dialog presents one option- “Get Updates”. Pressing the button or escape has the same effect; it opens the “Windows Update” options in settings. I can only presume it tries to force the update to take place but cannot proceed because of the Group Policy settings.

This notification angers me unreasonably for some reason, though after mentally telling it off I’ve usually forgotten about it. What spurred me to look into it and try to do something about it was that I had the sheer audacity this evening to watch a movie. Right in the middle of the movie, suddenly I get the “Important updates are available” notification. It’s crossed the line and now it must die permanently.

One “rebuttal” of sorts I’ve seen to resistance to run Windows Update is that this problem can be avoided by just running it as soon as it wants to run. Aside from not wanting to wait a good 30 minutes to use my PC again, none of the updates it deems so are even important. There’s a flash player update (I’ll address this later) There’s a Windows Update which addresses a problem when a Windows 8 PC is upgraded to Windows 10, where Manufacturer bloatware is disappointingly removed, and an update to the servicing stack which applies to the creation of ISO media for Win10. “Important”? Hardly. And even if they were “important”- important to whom? If I am in the middle of, say, a work skype meeting, or I’m currently remoted in to fix a database issue on a customer server, why are the updates for my local system somehow more  important than me being productive? Fact is they are not. The FUD surrounding Windows Updates and how we should just lay down and let Microsoft handle everything for us, how we should be Happy- not annoyed- when we find our systems rebooted overnight and thus we have to re-open all our work in progress again and find out what we were doing.

Anyway enough ranting! Thankfully as noted the Group Policy generally works as intended, just with that one annoying caveat. Can we eliminate that full-screen Prompt telling us there are important updates and instructing us that we must install them like we are some sort of child?

The first obvious place was Group Policy Editor. For example, is there a setting “Present full-screen dialog to interrupt user and tell them about important updates”? No, nothing similar either. Well, so much for that approach. After some investigation,l I found that the notification itself is basically just Windows launching “MusNotification.exe” and/or “musnotificationUI.exe”, presumably at times of it’s own choosing for wholly undocumented reasons and triggers. Whenever it feels like it I guess, or Maybe once a day. Who knows. Anyway, This suggested to me that replacing those files with a do-nothing stub program might solve the problem. However, I’m sure the issue would be “fixed” in a later update- in that those files would return. So I decided to take a batch file approach. If I update later and Win10 reverts the behaviour- such as with the anniversary update- I’ll be able to run the batch file to hopefully get it back to the way I want.

I created a do-nothing stub program by basically compiling the Visual Studio default template. (And removing the window creation of course) The files in C:\Windows\System32 are set as owned by TrustedInstaller, so it was necessary to take ownership of the files, then give full control on the files to administrators. I then renamed the originals and copied the stub into their place. The  batch file I ended up creating to do this looks like this.

 

I went ahead and put this in the same directory alongside the stub program. It appears to work as intended,  though given how sporadic the original “full screen takeover” behaviour was it will be some time before I’m sufficiently convinced it has worked as intended. I’ve put this on a flash drive so I can run it on my various Windows 10 systems (excepting the one system I have running preview builds).

I mentioned  I’d talk about Flash as well. As it happens, Windows 10 apparently includes Adobe Flash Player, which was news to me. Aside from the updates failing to install anyway, I really do NOT want Adobe Flash on my system(s) in any, way, shape, or form. I was able to do something similar with it- in this case, Adobe Flash installs to the directory “C:\Windows\Syswow64\Macromed”. So I adjusted my batch file to take ownership of that folder, set security to full control on the folder, and delete it, adding these to the end of said file:

After doing that, I hid the Flash Player update using this troubleshooter. Unfortunately I suspect future updates will attempt to reinstall Flash. Best case scenario is to create the folder and deny TrustedInstaller access to it, so it cannot install the updates, but of course this will cause the update to fail all the time and may cause problems with Windows Update until it’s hidden anyway.

Posted By: BC_Programming
Last Edit: 08 Aug 2016 @ 06:47 PM

EmailPermalinkComments (0)
Tags
Tags: ,
Categories: Windows
 27 May 2016 @ 8:04 PM 

Edit: 06/17/2016: I’ve gotten a few comments that for some reason mention “Long Path Tool”. I’m not clear why that is the case. Any posts mentioning Long Path tool as an “Alternative” or because you were “encountering the same problem” will be treated as spam. In the meantime, I’ll continue to use the Search Program I wrote almost a decade ago in Visual Basic 6 to delete files that are beyond the MAX_PATH limit (it uses my BCFile library which has the ability to support long path names).

 

Starting in Windows 10 Build 14352, a new Group Policy has appeared, “Enable NTFS Long Paths”. This setting is found under Administrative Templates\System\File System\NTFS:
NTFS Long Paths gpedit setting

This setting relates to the somewhat ubiquitous 260 character path limit. But what exact is the limit, how did it come about, and how has it persisted to this day in such a way that, as the setting itself requires, programs need to explicitly declare that they can handle them?

First, the initial origin. This limitation actually dates to MS-DOS, and originates with Interrupt 21h with 47h in the high byte of the accumulator register. This function was defined as “returns the path description without the drive letter and the initial backslash”. the 256 byte path excluded the drive letter and backslash (as noted) and didn’t use a null terminator. Adding the path and appropriate null terminator brings the maximum buffersize for a full directory path specification to 260 bytes.

Windows 3.1, and Windows 3.x more or less stuck with these same limitations, being mostly built over top of MS-DOS. With the introduction of the Unicode API, it was decided that Windows ought to allow for longer paths, particularly as File Systems such as NTFS were being developed that did away with many of those DOS-Derived limitations. So with those NT functions, the Unicode version of file functions could accept a \\?\ prefix at the front of the path string. This specified to the function to enable support for longer path names, up to the NTFS maximum of 32768. The requirement for \\?\ was added to allow older programs that weren’t compatible to continue to function; since they would not send the \\?\ prefix, they would continue to work as before.

However, as it happened, it turned out that this hasn’t been a particularly good solution. It wasn’t well popularized that File API calls should include such prefixes, and furthermore Microsoft’s own, built-in software didn’t even use it properly. Programs such as Windows Explorer don’t send the prefix string; and the .NET File API doesn’t support Unicode long path names either.

To demonstrate this difference, I’ve constructed a crude example in C#. It builds a long path that is 500+ characters long, then attempts to create it using the .NET API, and then using CreateDirectoryW:

This gives output similar to the following. Note that this is the case on earlier Windows versions as well, going back to XP:

What happened? the .NET Function failed when it saw the path would be too long and gave up. CreateDirectoryW however was able to create the full path length. I was able to verify it’s length because neither Command Prompt nor Windows Explorer are able to enter it. Interestingly, on Windows 10, this is the case regardless of if the Group Policy is Enabled or not.

Now, my current suspicion is that the feature will enable the functionality of \\?\ from those unicode functions without \\?\ being specified. In this case, this likely means that the internal .NET functions will still not function with longer path names, as the .NET File API is currently stopping it from going any further; it is checking the path length and going “Nope, won’t work, I give up” and throwing an exception. If my assertion is correct, however, it means that CreateDirectoryW will work as it does now if I remove the \\?\ prefix text if I add the appropriate manifest declaration to the program.

Which, naturally, led me to the next question- what exactly needs to be added to the manifest? First, I dumped the manifest from explorer.exe, hoping it perhaps declared support (which I was skeptical of given that I wasn’t able to browse the folders that were created as part of the test code). The Windows 10 Explorer.exe from build 14352 current has the following information from SysInternals sigcheck:

Well, no clues there. Dang. I tried paving my own roadway here, but can’t identify what xml namespace the app manifest would refer to nor the actual setting; I tried <longPaths> “ntfsLongPaths” and a few other permutations; however it may be the case that the xml namespace has not been published and this feature simply hasn’t been documented. The group policy setting may even be a placeholder in this build, given built-in Windows applications currently possess no support for it’s manifested capabilities. (Note that with the setting enabled, without a manifest, using CreateDirectoryW without the prefix results in an error once it goes beyond 260 characters).

This is a topic I will certainly revisit once more information on how we can utilize this feature comes to light. However, as it is, it doesn’t seem terribly useful. The big use here will be if Windows’ built-in software is written to support the policy setting. At any rate, I intend to update this posting when new information is available about this feature and how it can be used by developers. as well as it’s effect on the software.

Update 1:

Windows 10 does NOT display a correct error message when deleting a folder created in the manner above; When I attempted to delete the folder created above that is longer than MAX_PATH, I receive the following error dialog:

Incorrect Error

It claims that the source file names are larger than is supported by the file system. There are a few issues with that sort of error. I’m not copying files, so there is no “Source” or “Destination”; more importantly, the file system is NTFS and the fact that it currently contains the files I’m trying to delete seems to be presentable as evidence that the file system does, in fact, fully support the file path length.

These are the sorts of misleading error messages that have plagued Windows because of this MAX_PATH limitation for decades. Whether  this group policy- which isn’t enabled by default to begin with- is some sort of lead-in to a wider solution to this problem and to solve misleading and straight-up incorrect error messages like the above will be interesting to see.

Update 2

Allegedly, the setting in the manifest is “longPathAware”. However, I’ve yet to identify different behaviour when adding such a node to a manifest. The example program above is unable to use CreateDirectoryW and construct the 600+ Character path; it still requires the special prefix string. I’m looking through “Strings” output to verify that longPathAware is likely the manifest name.

I’ve found a RtlIsLongPathAwareProcessByManifest function as well as a direct reference to the string longPathAware which seems to indicate that is the correct manifest element. I found it references the schema http://schemas.microsoft.com/SMI/2016/WindowsSettings, which I wasn’t using. However adding that xmlns didn’t seem to work. So The manifest element is correct and the xmlns seems to be correct but I cannot make the feature do anything.

Posted By: BC_Programming
Last Edit: 08 Oct 2016 @ 05:03 AM

EmailPermalinkComments (0)
Tags
Categories: .NET, API, C#, Programming, Windows
 06 Mar 2016 @ 8:57 PM 

Just thought I would make a quick post on this. I’ve been tweaking BASeBlock a bit to try to get it to allow for a larger window size, since it’s pretty ridiculously small. Thankfully, it was already using a backbuffered approach, so I simply made the window resizable. But I found in doing so that performance dropped substantially as I increased the size of the image.

I used the Performance and Diagnostics feature to try to diagnose the cause. most of the added time was in the GDI+ DrawImage function when it drew the backbuffer to the visible control.

After some experimentation, I was able to increase performance by a fairly good margin. This can be done by adjusting the CompositingMode, CompositingQuality, and InterpolationMode properties of the Graphics context in use and using SourceCopy, HighSpeed, and NearestNeighbor, respectively.

 

Looking into it it seems that GDI+ just has poor performance for image scaling.

Posted By: BC_Programming
Last Edit: 06 Mar 2016 @ 08:57 PM

EmailPermalinkComments (0)
Tags
Categories: .NET, Windows
 13 Nov 2015 @ 8:27 PM 

A few days ago, Microsoft released an update for Windows 10, the “Windows 10 Threshold 2” update. In some ways, this update is practically a new OS version; in others, it is, well, an update. This is definitely Microsoft’s approach moving forward- more frequent releases of new versions, mirroring in some ways Android and iOS updates. How well that applies to desktop PCs, however, is arguably another question. I’m certainly no fan of the approach myself. It is in fact this new approach which leads to the telemetry and diagnostics tracking, which cannot be shut off, that has been so ill-received by Windows users considering upgrading their systems, including myself.

Threshold 2 does address some of my own “holdbacks” on upgrading my primary systems.

Colored Title bars are back

One of my cosmetic issues with Windows 10 was that customization options were removed. To be fair, the trend of removing options arguably started with Vista- the move from the Luna interface and scrapping of the Classic theme in particular eventually phased out some of the more powerful customization options. Windows 10, rather curiously, took it a step further, and effectively forced all Titlebars to be white. I’m not certain of the logic or design considerations behind that decision. It was possible to override this and use your own color but I found the solutions- which involved hacking a theme file- to be less-than-stellar solutions which had their own side effects. With Threshold 2, we are given this ability to customize the colour again.

Windows 10 Threshold 2 now provides the capability to customize titlebar colours.

Windows 10 Threshold 2 now provides the capability to customize titlebar colours.

This “New” feature (which is actually an old feature present in earlier Windows 10 builds) is accessed by adjusting the Accent color.

Perhaps even more interesting, is that one can directly access the colour selection options from Windows 8, which allowed customizing the color, rather than choosing a pre-selected palette. This can be accessed by using Start->Run and running “control color” (without the quotes). Quite an interesting if oddly hidden capability.

A lot of the other features are far more meh. I wasn’t really able to find much concrete. I expect quite a few internals may have been revised and other things may have been adjusted based on feedback, though. (oh, and, of course, I’m sure a lot of changes were made based on the wonderful telemetry they received?)

Posted By: BC_Programming
Last Edit: 13 Nov 2015 @ 08:27 PM

EmailPermalinkComments (0)
Tags
Categories: Microsoft, Windows
 07 Nov 2015 @ 9:27 PM 

Windows 8 introduced the concept of a Windows “App”. This has moved forward through Windows 8.1 and Windows 10.

Effectively, these “Apps” are what was formerly referred to as “Metro” and is now called the Modern UI. They use something of a different interface paradigm, with different controls and with elements typically sized for easier touch-screen use. That’s all well and good.

With Windows 8, 8.1, and 10, using these Apps tends to be optional. For the most part, there are equivalents you can use. A good example is Control panel; there is a “Settings” App which has some options, but for the most part there is a overlap with the “old style” Control Panel.

Recently, however, I needed to open an App for whatever reason. Or maybe I opened it by accident. Rather than the app opening, me being annoyed, and then closing the App, it instead said “This app can’t open” and suggested that I perform a Refresh to fix it. This sent me down something of a rabbit hole- Searching online for fixes, trying them, getting weird results, etc.

Actually, I’ve jumped in the ring to wrestle these issues a few times- I’ve had it on at least one my systems for ages and it recently appeared on another. Being unable to make some changes to the system was annoying enough that I decided to fix the issue- which, again, sent me down the rabbit hole. Try this command. Try this other one. Didn’t work? use this Troubleshooter that doesn’t do anything useful. Didn’t work? I don’t know. maybe try refreshing your PC after all?

Eventually, I stumbled, almost by accident, on the solution. Many of the attempts were encountering an error about “The package repository is corrupted”. I found nothing addressing that except some statements about registry key permissions, which I checked and were fine. So I decided to find where this package repository was- C:\ProgramData\Microsoft\Windows\AppRepository- and nuke it completely. I deleted the entire contents of the folder, then ran the command again. I expected a different error or something, but that seems to have done the trick, and now those Apps all work again.

Effectively, the Windows Store/App stuff is something of a “Package Manager” and stores the package information in that folder. However it also has an index of the package information in a smaller repository file, and it seems that file can get corrupted. I tried deleting that as well but it never fixed it. I ended up going with the nuke-it-from-orbit option.

My full list of steps was:

  1. Delete contents of C:\ProgramData\Microsoft\Windows\AppRepository
    Deleted all the files inside this folder. Quite satisfying.

  2. Ran an arbitrary non-obvious command from an administrator command prompt

    This effectively “re-registers” the Windows Store itself.

  3. Ran an arbitrary non-obvious command from an administrator command prompt

    Like the above, but this re-registers the “Settings” App.

  4. Ran a final non-obvious program from the command prompt
    After all this, other apps were still causing problems, like the useless Music app or the useless mail app or the various other useless apps that are provided and available. I’m not one to leave a hippo in vinegar, so I ran one more thing- I opened Windows Search and typed “wsreset” which brought up wsreset, then I right-clicked it and selected to run as administrator. After doing so, all the apps I had started working properly again.

I’d like to pause for a moment, however- to really admire how poorly engineered something has to be for almost any problem with it to declare that the user should try nuking everything and starting over. Microsoft calls it a “Windows Refresh” but it is a reinstall, and suggesting users reinstall an OS to fix these issues is absolutely ridiculous. Another very comical aspect to this is that in the “Windows versus Linux” argument, Windows diehards will complain that Linux requires arcane terminal commands to fix issues. Now, it’s hard to argue that- some issues in Linux distributions could require dropping to the terminal to fix issues with particular commands. But given the above- it doesn’t look like Windows is any stranger to that anymore.

Posted By: BC_Programming
Last Edit: 07 Nov 2015 @ 09:39 PM

EmailPermalinkComments (0)
Tags
 12 Oct 2015 @ 1:34 PM 

I’ve been putting writing about this off for a while, but I think it is time that I wrote about it. I wrote previously about Windows 10. It’s not a bad OS, it’s not a great OS, and it seems to take away a lot of power from the user which I strongly disagree with. Windows Update being made mandatory is, In my opinion, completely and wholly unacceptable, and the fact that anybody is willing to accept Microsoft effectively controlling what software we run on our PCs is mind-boggling.

Stop being pushy

Before Windows 10 was made available, Microsoft pushed an update- KB303583, which installed the “Get Windows 10” Program. This allowed users who wanted to upgrade to reserve their Windows 10 copy and prepare to upgrade when Windows 10 released. Fair enough. This does have a few issues. The first issue is that it never goes away, and cannot be disabled through it’s User Interface. There is no “I don’t want Windows 10, go away and don’t show me this again” option where it will actually not show it again. It will appear every boot, it will stay in the notification tray, and it won’t go away. It can be uninstalled and hidden via the Update applet, and the notification icon can be simply hidden from the notification area as well. However, this is not enough. Once Windows 10 actually dropped, this GWX application would stage, on every single system it was installed on, a Windows 10 install media set. This was done regardless of if the user said yes or no to the upgrade. If you said “No thanks” it would still download 6GB of data onto your hard drive- because clearly your decision not to upgrade was done under some delirium. Worse still, this update was marked as “Important”. it’s not Important. it doesn’t provide any importance. It is an advertising tool. It can be hidden and uninstalled though. Shady, but not unmanagable.

Microsoft has, however, crossed the line more recently. Recent updates made available to Windows 7 and 8 not only will re-install the same “Get Windows 10” content, but it will also forcibly add new telemetry tracking software to track user activity and collect data on Windows 7 and Windows 8.1. These are ‘disguised’ as “Compatibility Updates”; for example, KB2952664 is the update for Windows 7 which adds telemetry tracking to Windows 7. This collects information about and tracks how you use your system, and carts it off to Microsoft. No dialog is presented asking for permission. These are marked as “Important” updates despite not fixing or adding anything to the OS that any reasonable person outside of Microsoft could possibly tag as Important. Other updates include KB2977759, which adds “diagnostics” to the Windows Customer Experience program (whatever that means), KB2976978 which does the same for Windows 8.1.

Let me put it to you straight here- This is unethical in every possible sense of the word. Microsoft is forcing this software onto users under the false pretense of being an important update to the Operating System, when it is really nothing more than an advertising and data collection platform. It is a “marketing” update, not a technical one. It get’s worse, however. Considering the sort of Updates Microsoft is willing to push onto Windows 7 and 8 systems where users have the ability to adjust update options, imagine what they’ll be able to push to us on Windows 10, when we have severely restricted control over that update process. The most optimistic perspective would require us to assume Microsoft would only ever deploy Operating System Updates we need. But that has clearly gone out the Window with these updates they’ve released to Windows 7 and 8, making it absolutely clear that the user is not a priority- getting people to use the software Microsoft wants them to use is more important than facilitating the deployment of software that users actually want or improving the security of the product in general.

We could make an even more dramatic comparison. With the “Get Windows 10” App, A user can say “I don’t want Windows 10” effectively. Microsoft has completely disregarded “No”. They refuse to take no for an answer. They have forcibly penetrated systems with their software without user consent. You can see what analogy I am making here. It is a violent analogy and I abhor making it because it trivializes actual victims but the same mechanics are involved so I think it fits.

It is difficult to know if it is Microsoft that has changed, or maybe I’ve changed and now identify the issues that were always there. Previously, my reasoning that might explain forced auto updates might be “well, Microsoft would get bad publicity if they deployed things in bad faith”. But now- with Windows 10 getting critical acclaim – that is no longer clear. They appear to be being rewarded for unethical behaviour and I don’t know if they always have or if I’m only just noticing that now.

On the bright side, so far this only seems to affect Windows itself. Visual Studio 2015 is pretty amazing and while I’m not a huge fan of the Universal App Framework and the direction Windows-based development is trying to go, there is nothing even nearly approaching the ethical qualms involved in these Windows 7 and Windows 8 updates.

Posted By: BC_Programming
Last Edit: 12 Oct 2015 @ 01:35 PM

EmailPermalinkComments (0)
Tags
Categories: General Computing, Windows

 Last 50 Posts
 Back
Change Theme...
  • Users » 41946
  • Posts/Pages » 350
  • Comments » 104
Change Theme...
  • VoidVoid « Default
  • LifeLife
  • EarthEarth
  • WindWind
  • WaterWater
  • FireFire
  • LightLight

PP



    No Child Pages.

Windows optimization tips



    No Child Pages.

BC’s Todo List



    No Child Pages.