17 Dec 2016 @ 7:20 PM 

I’ve complained before about Windows 10’s rather odd VPN and even wireless connection interface, in that it has excessive levels of redirection. I went ahead and wrote a small program that appears as a notification icon which attempts to make it a bit more straightforward. It’s not fancy, but it seems to get the job done.

I’ve put it up on github, it can be found here.

Posted By: BC_Programming
Last Edit: 17 Dec 2016 @ 07:20 PM

EmailPermalinkComments Off on BASeCamp Net Menu on Github
Tags
Categories: .NET, C#
 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 Off on Retrieving and Setting individual Program Volume
Tags
Categories: .NET, C#, Programming, Windows
 27 Oct 2016 @ 12:39 PM 

This is part of a series of posts covering new C# 6 features. Currently there are posts covering the following:
String Interpolation
Expression-bodied Members
Improved Overload resolution
The Null Conditional operator
Auto-Property Initializers

Yet another new feature introduced into C# 6 are a feature called Dictionary Initializers. These are another “syntax sugar” feature that shortens code and makes it more readable- or, arguably, less readable if you aren’t familiar with the feature.

Let’s say we have a Dictionary of countries, indexed by an abbreviation. We might create it like so:

This is the standard approach to initializing dictionaries as used in previous versions, at least, when you want to initialize them at compile time. C#6 adds “dictionary initializers” which attempt to simplify this:

Here we see what is effectively a series of assignments to the standard this[] operator. It’s usually called a Dictionary Initializer, but realistically it can be used to initialize any class that has a indexed property like this. For example, it can be used to construct “sparse” lists which have many empty entries without a bunch of commas:

The “Dictionary Initializer” which seems more aptly referred to as the Indexing initializer, is a very useful and delicious syntax sugar that can help make code easier to understand and read.

Posted By: BC_Programming
Last Edit: 27 Oct 2016 @ 12:40 PM

EmailPermalinkComments Off on C# 6 Features: Dictionary Initializers
Tags
Tags: , ,
Categories: .NET, C#, Programming
 08 Oct 2016 @ 4:38 PM 

One of the old standby’s of software development is manipulating bits within bytes. While it used to be that this was necessary- when you only have 8K of RAM, you have to make the most of it, which often meant packing information. Nowadays, it’s not quite as necessary, since there is so much more RAM on a typical system and it’s generally not worth the loss of performance that would come from packing unpacking bits for the tiny memory savings that would be afforded.

There are, of course, exceptions. Sometimes, trying to use conventional data types together with functions or other operations that work with compact data representations (For example, generating a Product Key) can be as awkward as Hitler at a Bar Mitzvah. In those cases, it can be quite useful to be able to pack several Boolean true/false values into a single byte. But in order to do so, we need to do some bit bashing.

Bit Bashing

“Bit Bashing” is the rather crude term for Bit manipulation, which is effectively what it says on the tin- the manipulation of the bits making up the bytes. Even the oldest Microcomputer CPUs- the Intel 4004, for example- worked with more than one bit at a time, in the case of the 4004, it worked with 4-bits at a time. The original IBM PC worked with a full byte. This means that operations work at a higher level even then the bit, so it takes some trickery to work at that level.

The core concepts are easy- you can use bitwise operators on a byte in order to set or retrieve individual bits of the byte.

Setting a Bit

Setting a bit is a different operation depending on whether the bit is being cleared or set (0 or 1). If the bit is being set, one can do so by using a bitwise “or” operation with a shifted value based on the desired bit to change:

Straightforward- create a byte based on the specified bit index (0 through 7) the bitwise or that against the original to force that bit to be set in the result.

The converse is similar, though a teensy bit more complicate. to forcibly set a bit to 0, we need to perform a bitwise “and” operation not against the shifted value, but against the bitwise complement of the shifted value:

Retrieving a bit

Retrieving a bit is as simple as seeing if the bitwise and between the value and the shifted byte is non-zero:

Being able to encode and decode bits from a byte can be a useful capability for certain tasks even if it’s necessity due to memory constraints may have long since passed.

Posted By: BC_Programming
Last Edit: 08 Oct 2016 @ 04:38 PM

EmailPermalinkComments Off on Bashing Bits About
Tags
Categories: .NET, C#, Programming
 17 Sep 2016 @ 3:42 PM 

Previously I wrote about implementing a Alpha-blended form with VB.NET. In that implementation, I had an abstract class derive from Form and then the actual forms derive from that. This causes issues with using the Form in the designer.

In order to workaround that issue I’ve redone parts of the implementation a bit to get it working as it’s own separate class. Rather than rely on the CreateParams() to adjust the GWL_EXSTYLE when the form is initially created, it merely uses SetWindowLong() to change it at runtime. Otherwise, the core of what it does is largely the same- just refactored into a package that doesn’t break the designer.

It should be noted, however, that adding controls to the form will not function as intended, though- this is inherent in the Alpha Blending feature, as it effectively just draws the bitmap. This is why it works well for Splash Screens. Controls will still respond to events and clicks however they will be invisible; making them visible would require drawing them onto the Bitmap and then setting it as the new Layered Window bitmap each time controls change.

Here is the changed code:

In usage it is no more complex than before, really:

The end result is largely the same:

alpha_example

Posted By: BC_Programming
Last Edit: 15 Oct 2016 @ 01:51 PM

EmailPermalinkComments Off on Alpha-Blended Forms revisited
Tags
 03 Aug 2016 @ 4:37 PM 

I wrote previously, where I found that the Group Policy added to the insider build of Windows 10 did not have any observable effect.

This is merely a quick note as I re-tested on the recently released Anniversary Update, and with the group policy set in addition to the new “longPathAware” manifest setting, Functions like CreateDirectoryW do in fact allow access to long path names beyond MAX_PATH without the special prefix. Basically, the group policy is now active.

Of course, with the standard .NET File API, This has no effect, as the .NET File API does it’s own checks that restrict the path length.

Posted By: BC_Programming
Last Edit: 03 Aug 2016 @ 04:37 PM

EmailPermalinkComments Off on Windows 10 Anniversary Update: Long Path Names
Tags
Categories: .NET, C#
 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 Off on The Long Saga of Long Path Names
Tags
Categories: .NET, API, C#, Programming, Windows
 16 May 2016 @ 11:59 AM 

Occasionally, I like to fire up gzDoom and play through some of the old Doom and Doom II Games and megawads. I use a Random Level generator, Obhack, which I also hacked further to increase enemy and ammo. However, one alteration I like to make is to have higher Ammunition limits. As it happens, the way I had it set up, this information was in a DEHacked patch file within the WAD. As a result, to make changes, I had to use a tool called “Doom Wad Editor”.

Doom WAD Editor, or DWE for short, is about the most up to date tool I could find, and it is rather messy internally. It performs a lot of up-front processing to load the file and show previews and it doesn’t support a lot of modern capabilities. I recently came to a realization that the WAD Format is not some major secret- I could create my own tool.

So far, I’ve been able to construct the Format handler that is able to open and save the internal LUMP files. I’ll likely expand things to also use the KGROUP format (which is used by sole Build Engine games like Duke Nukem 3D) and create a Modern Application for current Windows versions for modifying those older file formats.

The WAD File Format

The WAD (For “Where’s All the Data?”) Format is a format used for Doom and Doom II as well as games using the same engine as well as modern source ports for those games to store game data; this includes maps, levels, textures, sprites, sounds, etc.

The Format itself is rather straightforward. As with most files, we have a Header. At the very start of the file, we find the characters IWAD or PWAD. These characters determine the “type” of the WAD file; a PWAD is a “Patch” Wad, which means it patches another WAD file’s data by replacing it’s contents. For example, a mod that changes all the sounds to be silly animal noises would be a PWAD which uses the same names for different data. an IWAD can be thought of as an “Initial” WAD. These are the “core” WAD files that are needed to play the games in question. The Header data is followed by a signed 32-bit integer indicating the number of Lumps in the file. (A Lump being effectively a piece of data). After that, is another 32-bit integer which is a file offset, from the beginning of the file, where the Lump Directory begins. The Lump Directory is a sequence of Lump Positions in the file, their size, and their 8-character name.

This is all, so far, relatively straightforward. So let’s get to it!. Now, this is just a code example of the basic implementation- my plan going forward with this tool is to flesh it out into a WPF Application that provides full editing and manipulation capabilities to WAD files. There is still an active Doom community creating Megawads and it may prove useful to somebody, and it’s unique enough that creating such an application should be interesting. I’ve been able to load and then resave the standard DOOM.WAD and have the newly saved version function correctly, so it would seem I did something correctly so far:

Posted By: BC_Programming
Last Edit: 16 May 2016 @ 11:59 AM

EmailPermalinkComments Off on Finding All the Data (Doom “WAD” File Format)
Tags
Categories: .NET, C#, Games
 24 Mar 2016 @ 7:32 PM 

I recently stumbled upon an interesting quirk related to handling classes implementing IDisposable within Enumerator methods. In my particular case, I had a function that could accept an SQL Connection, but optionally could default to using the application “standard” connection available via other static methods.

In order to accomplish this, I used an overload pattern, with the base case function accepting a NpgsqlConnection as shown:

and with the overload using the application available connection information. (GetConnection() here opens the connection):

I was finding that I was receiving an Connection exception stating that the connection was not open. After puzzling over it, I found the issue to be a result of how Enumerators work. In particular, it was a result of the use of the overload class to return an IEnumerable from the other function dependent on a Disposable wrapped in a using. The problem is that the IEnumerable is returned to the caller and it is only when that Enumerator is used that the Actual Enumerator function starts executing; at which point the original routine will have already disposed the connection (closing it) leaving the enumerator to throw a exception.

There are a number of workarounds; the one I decided on was to change the base case to a private method that has an additional argument to indicate whether to dispose of the passed in connection. This allows the removal of the using block, and let’s that overload instead simply pass true for that argument to call the private overload. This moves the actual dispose logic to the end of the enumerator block, allowing it to function properly. Additionally, by making it private it means it isn’t visible outside the class, which leaves the API as desired- one which takes a connection, and one which doesn’t but assumes the use of a default connection- and disposes of it properly afterwards.

By way of example, let’s assume a simple Disposable class. This implementation doesn’t actually have unmanaged resources, either itself or within aggregates- so realistically it wouldn’t use IDisposable at all, but I’m sure we can all just pretend it does for the sake of the example:

And now, a small Console program which demonstrates the issue as well as the workaround:

As we can see, the Broken implementation clearly has the Dispose() method called before the first character is even retrieved. I found this to be a very interesting quirk. One could even call it a sort of code diabetes, on account of it being so inexorably linked to the use of syntax sugar.

Posted By: BC_Programming
Last Edit: 24 Mar 2016 @ 07:32 PM

EmailPermalinkComments Off on A Gotcha with IDisposable and Enumerator methods
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 Off on GDI+ DrawImage Performance
Tags
Categories: .NET, Windows

 Last 50 Posts
 Back
Change Theme...
  • Users » 47469
  • Posts/Pages » 385
  • Comments » 105

PP



    No Child Pages.

Windows optimization tips



    No Child Pages.

Soft. Picks



    No Child Pages.

VS Fixes



    No Child Pages.