I’ve just had to deal with a situation where Windows 11 Explorer crashes and restarts every time I browse to a particular directory. The directory contained the source to my AFD code and I somehow managed to guess at the cause and fix the offending file…
The problem was that I had some Visual Studio sln files checked in to a git repository and at some point git had changed the line ends from windows \r\n to unix \n.
There’s a lot of noise about how “Joe Biden’s government wants you to move away from using C++”. This is as a result of the US government releasing a report, Back to the building blocks: A path toward secure and measurable software which suggests:
Uncle Sam says "no!" “Memory safety vulnerabilities are a class of vulnerability affecting how memory can be accessed, written, allocated, or deallocated in unintended ways. Experts have identified a few programming languages that both lack traits associated with memory safety and also have high proliferation across critical systems, such as C and C++.
I just broken my .htaccess file for about an hour and this resulting in /blog/ 301 redirecting to / which wasn’t intended… Fixed now.
I’ve been using the MiniDumpWriteDump() API from DbgHelp.dll for 20 years or so. It has proven to be a useful diagnostic tool, and I use it in all manner of places, including many where others may simply use an assert(). It’s a heavy-weight debugging tool, but it has proved useful over the years; rather than just throwing an exception because things that shouldn’t happen have happened, I often also generate a dump file so that I can get far more data than you could ever log or report in another way.
Back in 2004 I wrote this, I wonder why I used to make some people unhappy…
I’m starting to believe that, at 37, I must now be old and cranky because to be quite honest with you; if you’re not writing code in such a way that you define concepts and abstractions in such a way that the actual main line business logic code that you write is clear and easy to understand then you’re just not doing it right.
I had an internet outage this morning. This shouldn’t have been much of a problem for me as all of the code that I needed to be working on is on my local git server and all of the dependencies are local. Or so I thought. The client has a c# shim layer that builds as part of the C++ server build. They rely on NuGet to grab some components from somewhere for some reason.
When your machine has multiple NUMA nodes it’s often useful to restrict a process to using just one for performance reasons. It’s sometimes hard to fully utilize multiple NUMA nodes and, if you get it wrong, it can cost in performance as the nodes need to keep their caches consistent and potentially access memory over a slower link than the memory that is closer to the node, these things can be relatively expensive.
So, this morning I’m back from my Easter break and working on some code for a client and the first thing I do is kick off my CI build and things start failing. It seems that my “cunning plan” to have my CI build use the preview version of Visual Studio 2022 whilst the client uses earlier versions has paid off again…
We build with all warnings enabled and treat warnings as errors.
As of the latest Chrome, Edge, Opera, and FireFox updates all of my ‘obsolete’ hardware (routers, NAS drives, network switches, etc) are inaccessible as they don’t use TLS 1.2. I’m unlikely to be alone in this. I can understand the technical decision but IMHO it’s wrong and, actually pretty stupid. To make it more than a click through warning to access these obsolete devices on my local subnet. Sure ban connections to other subnets (that would cause me pain too as I manage some stuff via a VPN) but 90% of users would be fine.
UPDATED: 23 August 2021 see here
As I mentioned a while ago, it seems there’s a strangely fatal bug in the Windows networking stack at present. This manifests as massive non-paged pool memory usage if a process creates a UDP socket, binds it to an address and fails to read from it faster than other people are writing to it. The issue appears to be present on all current Windows operating systems but is NOT present on Windows Server 2012 R2 if recent patches have NOT been applied but IS present as soon as the box is patched up to date… My test box was patched up until March 2020 and ran fine, as soon as it was patched to June 2020 it started to behave badly.
