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
 28 Aug 2016 @ 1:08 AM 

As anybody knows, there can be a lot of incorrect information on the internet. Internet “Just so” stories can spread like wildfire if they are believable and explain something neatly. One of those “just so” stories involves older game consoles and computers; over time, we find that our once-white and gray plastics on old systems like Apple II’s, NES consoles, SNES consoles, and so on change colour; they change from white or gray to yellow, and over time that yellow darkens, sometimes even turning brown.

This phenomena is “explained” here. Or is it? Does what is stated there about the process reflect reality? Does it make chemical sense? To the layman or casual observer- hey, it makes sense. Bromine IS brown, after all, it’s added to the plastic. But is there a chemical basis and support for it? What reactions actually take place?

“RetroBright”- which is basically just Hydrogen peroxide – is commonly recommended to “reverse” the effects. The reason I care about the actual chemical properties is because the yellowing itself goin g away isn’t an indication that everything is back to how it was. Colour changes can be the result of all sorts of things. More importantly, if we learn the actual chemical processes involved, perhaps we can come up with alternative approaches.

Basically, the story put forth in the article is a rather commonly repeated myth- a Chemical “just-so” story of sorts- “Bromine is brown so that must be it” Is the extent of the intellectual discussion regarding chemistry, more or less. Generally though there isn’t much drive to look further into it- it all makes sense to the layman on the surface, or even one with rather standard chemistry knowledge. But when you look deeper than the surface of the concept- you see that the commonly held belief that Brominated Flame Retardants are responsible doesn’t seem to hold up.

First we can start with the first inaccuracy in that link- Bromine is not added as a flame retardant- that is flat out, categorically and completely wrong, and trivially easy to refute. Bromine compounds are added as flame retardants, But as they are compounds, the colour of elemental Bromine (brown) is irrelevant, because elemental Bromine is not added to the plastic. Specifically, chemicals like Tetrabromobisphenol A. (C15H12Br4O2).

The article also says that “The problem is that bromine undergoes a reaction when exposed to ultraviolet (UV) radiation” But Bromine doesn’t photo-oxidize. It doesn’t even react with anything in the air on it’s own; creating Bromine dioxide either involves exposing it to Ozone at very low temperatures alongside trichlorofluoromethane, alternatively, gaseous bromine can be made to react with oxygen by passing a current through it. Neither of these seem like they take place in a Super Nintendo. Not to mention elemental bromine is brown, so if it was in the plastic, oxidization would change it from the brown of elemental bromine to the yellow of bromine dioxide.

Back to what IS in the plastic, though- Tetrabromobisphenol A is not photosensitive; it won’t react with oxygen in the air due to UV light exposure, and the bromine cannot be “freed” from the compound and made elemental through some coincidence in a typical environment. It is simply not the cause of the yellowing; (it will yellow without BFR’s as well, which sort of indicates it’s probably not involved).

The Yellowing is inherent to ABS plastics, because it is the ABS plastic itself that is photo-oxidative. On exposure to UV light (or heat, which is why it can happen with systems stored in attics for example), the butadiene portion of the polymer chain will react with oxygen and form carbonyl-b. That compound is brown. There’s your culprit right there. Retrobright works because thsoe carbonyls react with hydrogen peroxide, and create another compound which is colourless. but the butadiene portion of the polymer remains weak- oxalic acid is thought to be one possible way to reverse the original reaction.

So why does it sometimes not affect certain parts of the plastic or certain systems? here the “just so” story is a bit closer to reality- the “story” is that the plastic formulae has different amounts of brominated flame retardants, This is probably true, but as that compound isn’t photo-reactive or involved in the chemical process, it’s not what matters here. What causes the difference is a variance in a different part of the formulae- the UV stabiliser.

UV Stabilisers are added to pretty much All ABS plastic intentionally to try to offset the butadiene reaction and the yellowing effect the resulting carbonyl has. They absorb UV light and dissipate it as infrared wavelength energy which doesn’t catalyze a reaction in the butadiene. Less UV Stabilizer means more UV gets to the Butadiene and causes a reaction and the plastic yellows more quickly. more UV stabilizer means less UV catalyzes reactions and the plastic takes longer to change colour.

As with anything related to this- the best way is to experiment. I’ve decided to pick up some supplies and test both approaches on a single piece of plastic. some standard “retrobright” mixture using hydrogen peroxide, and a variation using oxalic acid. I can apply both to the same piece of yellowed plastic, and observe the results. Are both effective at removing the yellowing color? what happens longer term? It should be an interesting experiment.

Posted By: BC_Programming
Last Edit: 28 Aug 2016 @ 01:08 AM

EmailPermalinkComments (0)
Tags
 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
 13 Jul 2016 @ 5:02 AM 

Previously, I wrote about my Unicomp Ultra Classic keyboard and my experiences with it. As it happens, that keyboard no longer works; The issues I mention there ended up resulting in the keyboard failing outright; it would no longer connect to the system and my attempts to repair the keyboard resulted in it getting worse. I ended up replacing it with a new one (going for a Black case this time around). Unfortunately, that keyboard eventually started to see the same symptoms, and it appears that it is the result of the same design failure. I couldn’t really expect much else. It may be the case that other models than the Ultra Classic itself did not suffer from these design issues, however I couldn’t justifying buying a third keyboard from them given my experiences, and particularly given the lack of user-servicability to the keyboards, with rather consumer-hostile properties such as using melted plastic to hold together parts of the keyboard as well as double-sided tape.

This left me in a bit of a spot, though. Unicomp is, after all, the only way to get a buckling spring keyboard, and I had grown rather fond of the Typing experience afforded by such a keyboard. Alternative keyboards didn’t use Buckling Spring, with most of them instead opting for something like a Cherry MX switch.

After a bit of hemming and hawwing about the decision, I ended up deciding on a Corsair K70 keyboard with Cherry MX Brown keyswitches. I’m typing on it right now and it works well enough. I still prefer the typing experience of the buckling spring, but a keyboard that actually works reliably comes out on top regardless of any other differences, as far as I’m concerned. It’s also nice to have Media keys again, as that is one capability I actually missed going from my Microsoft Wired 500 to the Unicomp Keyboard.

The backlighting feature is interesting, and the backlight programmability is, well, actually it’s kind of funny, to be honest. Kind of a bit overboard arguably. I have it configured to change the Color when I press a key and fade back to the original colour, with different sections set to different colours, for no particular reason.

I have found the software slightly lacking, in particular, I find that when it is running for some time, it has a serious resource or memory leak that exhibits itself in the program being rather unusable. Restarting the program fixes this, but it’s still a rather odd issue given the program has to run in the background for the custom backlighting setup to work.

I haven’t taken it apart, of course, however it doesn’t appear that doing so is particularly difficult; unlike the Unicomp keyboard it would probably be possible to actually put it back together, that’s a plus, and not having to take it aparet to fix a design flaw related to lacking any strain relief is a nice bonus too.

Posted By: BC_Programming
Last Edit: 13 Jul 2016 @ 05:02 AM

EmailPermalinkComments (0)
Tags
Categories: General Computing
 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
 01 Apr 2016 @ 11:03 AM 

For quite some time now the idea of planned obsolescence has been somewhat commonplace. Computers in particular are often quickly considered out of date or “obsolete” only a few years after they have been used. Operating System versions that are older are met with a certain scorn from some people. I’m convinced, however, that there is a strong trend where the advantages of the latest and greatest hardware and software makes a dramatic falloff and furthermore that the speed with which a system actually becomes difficult or impossible to use for current-day tasks is falling dramatically.

for technology, it is a not uncommon mindset that it becomes useless very quickly, relative to other industries. And there is certainly some prior art for that; for example, an original IBM PC wouldn’t be able to do nearly the level of things that a PC 10 years newer would be able to do. However, I don’t think that applies quite as well to today and PCs from 10 years ago.

Consider the typical usage scenario. What everyday tasks, software, or other components does somebody use that they simply cannot use with Windows 7? Which ones require a system from the past few years to do so? Windows 8 and Windows 10 are fine; but can anybody itemize a list of what those business people had to give up by using Windows 7? I can’t even contrive anything.

whereas a system from 1984 was not very useful for the common tasks of a user in 1994, or required that the user tolerate it’s slowness, nowadays older systems can pretty much always be utilized for a modern task.

A prime example is the IBM Thinkpad T41 laptop I picked up for cheap off eBay. This laptop was released in 2003 and is 13 years old. The time difference is equivalent to using an original IBM PC in 1996. And yet here I am, writing a blog post on that system with absolutely no problems whatsoever, in a modern, up to date browser and a modern up-to-date Operating System (Linux Mint 17.3 XFCE).

This is why statements like the example I give seem so strange. It is as if the release of new OS versions suddenly make those older versions unable to perform the same tasks they did previously. We don’t see mind-bending amazing new features like VFAT in new Windows versions today, so the previous versions work just fine, and for the security conscious after it’s lifecycle expired, there is always Linux.

I wrote this Blog post on a Laptop that is 13 years old. old PCs are old- but they are no longer obsolete in the modern day, particularly as gains in CPU technologies have started to level off. I don’t need a Quad core with hyperthreading to write a text document.

Posted By: BC_Programming
Last Edit: 01 Apr 2016 @ 11:03 AM

EmailPermalinkComments (0)
Tags
 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

 Last 50 Posts
 Back
Change Theme...
  • Users » 41491
  • Posts/Pages » 347
  • 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.