Previously published
This article was previously published on len-learns-rust.com. A full index of these articles can be found here.
I’m a long term C++ programmer who is coming to Rust with lots of baggage. I’d like to write Rust in an idiomatic style but I may end up writing bad Rust in a C++ style. Hopefully people will help me avoid that.
I’ve read the Rust Book1, or at least some of it.
I’ve had a client ask if it’s possible to rename his server log file whilst the server is running but not allow deletion. This is harder than you’d expect to achieve. The established view of “the internet” is that NTFS doesn’t support permissions to allow file renaming and still prevent file deletion. This is true. If you want to allow renaming you need to create or open the file with FILE_SHARE_DELETE access and this allows rename AND delete.
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.
Back in 2009 I mused on the idea of ‘breakpoint sequences’, where a breakpoint was only hit if a series of previous breakpoints have been hit.
This functionality now exists in Visual Studio 2022, and it’s wonderful. It’s useful enough for me to immediately switch from VS2017 to VS2022 as my “day to day” IDE for Windows. Normally I take forever to make the move as I have tools that manage projects and solutions across all the compilers that I support, I just develop in the one that works best for me.
As I mentioned in May last year, I’d was having trouble with a client’s system where a UDP DDOS was causing Windows Server machines to use all available non-paged pool and then blue screen.
The issue could be reproduced with, what I thought at the time was, a minimal test program that simply created a UDP socket, bound it to a port and then didn’t do anything with it. If something sent a stream of datagrams to that port then non-paged pool usage would grow in an uncontrolled manner until the box became unusable and eventually died.
Back in October 2019 I pointed out that I didn’t normally do roadmaps of where the framework was going but did one anyway. Looking at how long it has taken to get from there to here I think I’m generally correct not to do roadmaps… I’ve been very busy with client work and the pandemic has caused us some disruption, but thankfully not too much. However, I think the main reason that it has taken so long to get the 7.
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.
UPDATED: 23 August 2021 see here
One of my clients runs game servers on the cloud. They have an AWFUL lot of them and have run them for a long time. Every so often they have problems with DDOS attacks on their servers. They have upstream DDOS protection from their hosting providers but these take a while to recognise the attacks and so there’s usually a period when the servers are vulnerable.
Previously on “Practical Testing”… The last time I updated the code was in 2016, things have changed quite a lot since then with several new compilers and several compilers that I no longer support. There are very few actual code changes, but the code now builds with Visual Studio 2019 (16.6 preview 3.0) and Visual Studio 2017. I’ve removed support for anything before Visual Studio 2015.
The code is here on GitHub and new rules apply.
I’m in the process of putting together a series of releases for The Server Framework. It’s a little more complex than usual so I thought I’d explain why that is.For the past year we’ve been working on a Linux/Mac version of The Server Framework with several clients. This has involved adjusting a lot of the code and moving some stuff around; for example there was code in our “Win32Tools” library that isn’t Win32 or even Windows specific and so that now lives in a new tools library, “CoreTools”, that contains code that can build on all platforms.
