07 Aug 2017 @ 6:24 PM 

A while ago, it came out that Microsoft Paint would be deprecated going forward on Windows 10, replaced, instead, with Paint 3D. There have been loads of articles, forum threads, and general griping about this across the Internet. Nonetheless, Paint is hardly the first “casualty” of Windows as it moved forward; nor is it’s loss, realistically, a big one.

A History

“Paint” existed in some form or another dating back to the original Windows release. Like many parts of Windows, it was based on an existing product, but stripped down. In this case Windows Paintbrush was effectively PC Paintbrush 1.05 for Windows but stripped down so as to not compete with the full product.

Windows 1.04

Paint on Windows 1.04

Aside from a smaller set of tools, it appears that another limitation of the included program is that it can only work with monochrome bitmaps. For the time period, that isn’t a surprising limitation though- The Apple Macintosh’s MacDraw program had a similar color limitation.

Windows /286

PAINT running on Windows /286

Windows/286 didn’t change the included PAINT program very much- I wasn’t able to find any significant differences myself, at least. it seems to have the same limitations. I wasn’t able to get Windows /386 to work however I presume PAINT is the same program between them, being that the major difference is enhancements for the 386.

Windows 3.0

Paintbrush running on Windows 3.0

It was with Windows 3.0 that PBRUSH was effectively created. While still seeming to be based largely on PC Paintbrush, the Windows 3.0 version, aside from changing the program title to “Windows Paintbrush” from “PAINT” as well as the executable, also redesigned part of the User Interface. Interestingly, this interface is more similar to the more complete PC Paintbrush product as provided on Windows /286, but of course it did not provide the full toolset of the commercial product either.

Windows 3.1

Paintbrush on Windows 3.1

PBRUSH didn’t see any significant changes from Windows 3.0. It still had a number of annoying limitations that plagued previous releases; in particular, tools couldn’t work with data outside the visible canvas. This meant you couldn’t even paste a screenshot into the program- It would be cropped. You can see this below- this is after performing a floodfill on the outer area of the above, then scrolling down- the exposed canvas was not affected by the operation.

Win 3.1 Paint floodfill failure

Windows 95

MSPaint on Windows 95

Windows 95 saw PBRUSH deprecated in favour of MSPAINT; Not just deprecated, mind you- but altogether removed; however, you could still invoke PBRUSH, due to a new “App paths” feature of Windows. This capability exists to today- Like Win95 there is no PBRUSH.EXE in Windows 10, but running PBRUSH will start MSPaint, as it has since Windows 95. The new Windows 95 version of Paint is now “Microsoft Paint” rather than “Windows Paintbrush” and sports a new executable as well. It also redesigns the interface to adhere to the new “3D” style that Windows 95 introduced, as well as making use of other Windows features that had been enhanced; for example, while you could edit colors in the older Windows Paintbrush, the program used a set of three sliders for that customization. Windows 95 added a new Custom Color dialog, which Microsoft Paint made use of for customizing the palette entries. Thanks to how that dialog worked it meant you could save several custom colors outside of the normal palette and swap between them, too. It also adds a Status bar, which was coming into it’s own with Windows 95 as a convention; This included “tip” text appearing on the left as well as other information appearing in additional panes on the status bar.

Windows 98

MSPaint on Windows 98SE

Windows 98’s release of Microsoft Paint seems to have removed the ability to load and save Custom Colour Palettes. Additionally, it also dropped the ability to save to the .PCX format, while gaining the ability to use certain installed image filters, allowing it to save to .PNG for example, if certain other software is installed.

Windows ME

MSPaint on Windows ME

The Windows ME version of MSPaint appears to be identical to the Windows 98SE Version, however, the executables are not identical- I’m not sure what difference there might be beyond the header indicating it is for a different Windows Version, though. It’s here for completeness.

Windows 2000

MSPaint on Windows 2000

Another entry for completeness as, like Windows ME, I cannot find any differences between it and the Windows 98SE release of MSPaint.

Windows XP

MSPaint on Windows XP

Windows XP introduced a few major revisions to MSPaint. First, it could acquire information from a Scanner or any TWAIN device (Such as a digital Camera). Moreover, it now had native support for JPEG, GIF, TIFF and PNG File formats, without any additional software installs.

Windows Vista

MSPaint running on Windows Vista

The WIndows Vista release of paint changes the default colour palette, has a set of new tool icons, And Reorganizes some of the UI (the Color palette is moved, for example). It changes the undo stack to 10 deep rather than 3, and saves to JPEG by default- which suggests that it was intended or expected largely to be used for acquiring and saving photos.

Windows 7

MSPaint as included in Windows 7.

Windows 7 is another major overhaul of the program, on the same level as the change from the PaintBrush program in Windows 3.1 to MSPaint in Windows 95. This redesigns the interface around the “Ribbon” concept, and adds a number of capabilities, brushes, and a few tools. It also now has anti-aliasing.

Windows 8

This version is pretty much identical to the Windows 7 release; though there are some minor adjustments to the Ribbon.

Future

Microsoft Paint is now deprecated, but this doesn’t prevent you from using it; even when it is removed from the default installation, it will still be made available as a free download from the store. You can also copy/paste a version of paint from a previous Windows 10 install to avoid dealing with an appx container file or any tracking that comes with using the Windows Store, if desired. I think the fuss over this change is a bit of an overreaction. There are plenty of other free programs that can accomplish the same tasks and while it is a bit annoying to have to download them, Windows will still include Paint 3D which should be capable of the same standard tasks people want the older Paint program for, such as screenshots.

The old PBRUSH application running on Windows 10. It’s a Miracle.

What is this witchcraft? Windows NT 3.51 was 32-bit, but was based around Windows 3.1, so it got a 32-bit version of the same old PBRUSH program from Windows 3.1. That can be copied from an NT 3.51 install and run directly on Windows 10. Pretty interesting- Though of arguably limited usefulness, beyond putting it at the end of blog posts to pad out the length for no reason.

Posted By: BC_Programming
Last Edit: 07 Aug 2017 @ 06:24 PM

EmailPermalinkComments (0)
Tags
 05 Apr 2017 @ 11:31 AM 

For a while now Windows 10 has had a “Game Mode” feature. I’m rather mixed on the feature myself, but generally find it strange.

I’ve never been a fan of the “Game Booster” software phenotype; it seems like it is largely snake oil fakery, and where it does have an effect, it is really just a result of the same sort of adjustments that can be made manually via services or other configuration options. Game Mode does have an advantage, here; the first is that it sort of puts those applications “out of business”, and, being built into the OS, it is a much safer implementation, and it’s  goals are less extreme. On the other hand, it does sort of legitimize the concept, which I’ve always found crazy, that such applications are in any way worth using.

I tend not to use the feature, however I can see it having benefits for some users and some systems. To me, overlay features such as the Game Bar that are used in this case feel like a sort of “chaff”; It is better than older approaches like the “Games for Windows Live” featureset, and better implemented as well, but I’ve found that- at least for now- it’s not really for me. This may be partly because I’m not a particularly heavy gamer, though- I seldom play games on my PC- nowhere near what I expected.

I also tend to enjoy older titles. Interestingly, I’ve found many older games- even going back to Win98 Games, run surprisingly well on Windows 10, most issues I’ve encountered with older titles tend to be a result of either lack of 16-bit compatibility (with much older titles) or are a result of the hardware being far in excess of what the game ever expected. A lot of older titles don’t have support for 2560×1440 for example because it is such a high resolution, requiring minor patches. Windows 10 is surprisingly backwards compatible in this regard. Even better than previous Post-Vista Windows releases, including Windows 7 which had an interesting explorer palette realization issue. that tended to cause problems with games that used 256-color modes.

Posted By: BC_Programming
Last Edit: 05 Apr 2017 @ 11:31 AM

EmailPermalinkComments (0)
Tags
Categories: Games, Windows
 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

 Last 50 Posts
 Back
Change Theme...
  • Users » 43711
  • Posts/Pages » 364
  • Comments » 106
Change Theme...
  • VoidVoid « Default
  • LifeLife
  • EarthEarth
  • WindWind
  • WaterWater
  • FireFire
  • LightLight

PP



    No Child Pages.

Windows optimization tips



    No Child Pages.

Software Picks



    No Child Pages.

BC’s Todo List



    No Child Pages.