Easy Window Switcher, our Windows “power toy” that brings macOS-like switching between open windows of the same application with Alt+` to Microsoft Windows, has just been updated to version 1.3.0. This new release brings some much requested fixes for keyboard layouts used by our friends in Denmark and Sweden and some more compatibility fixes for everyone else.
NeoSmart Technologies is pleased to announce the immediate availability of the latest additions to its Easy Recovery Essentials™ for Windows line of bootable repair and recovery tools for Microsoft Windows: EasyRE for Windows 11 and EasyRE Pro for Windows 11. Continuing a tradition that started with Windows 10, our Windows 11 boot recovery USB is currently available as a completely free download for anyone that needs to fix their Windows 11 installation after a virus infection or a Windows Update gone wrong.
EasyRE is fully compatible with the latest generation of EFI PCs and fixes everything from the original Windows 11 release to problems with the latest Windows 11 22H2 release and beyond.
EasyRE for Windows 11 is probably the easiest and most reliable way to fix BCD boot errors, blue screens during Windows boot, startup errors, EFI bootloader problems, MBR issues and more. You can download EasyRE for Windows 11 for free today, and use it to create a bootable Windows repair USB with the free Easy USB Creator or create a free Windows recovery CD if you prefer that route instead. You just download EasyRE on any working PC, convert the ISO image download to a USB or CD with one of our free tools, then place it in the computer that needs repair and restart it, choosing to boot from the EasyRE CD or USB, and wait for it to load the main menu:
NeoSmart Technologies is pleased to announce the immediate availability of its open source NeoSmart.Collections library/package of specialized containers and collections designed to eke out performance beyond that which is available in typical libraries and frameworks, by purposely optimizing for specific (common!) use cases at the cost of pretty much everything else.
In many regards, the data structures/containers/collections that ship with pretty much any given framework or standard library are a study in compromise. Language and framework developers have no idea what sort of data users will throw at their collections, or in what order. They have no clue whether or not a malicious third party would ultimately be at liberty to insert carefully crafted values into a container, or even what the general ratio of reads to writes would look like. The shipped code must be resilient, fairly performant, free of any obvious pathological cases with catastrophic memory or computation complexities, and above all, dependable.
It isn’t just language and framework developers that are forced to make choices that don’t necessarily align with your own use case. Even when attempting to identify what alternative data structure you could write up and use for your needs, you’ll often be presented with theoretical 𝒪 numbers that don’t necessarily apply or even have any relevance at all in the real world. An algorithm thrown out the window for having a horrible 𝒪 in Algorithms and Data Structures 101 may very well be your best friend if you can reasonably confine it to a certain subset of conditions or input values – and that’s without delving into processor instruction pipelines, execution units, spatial and temporal data locality, branch prediction, or SIMD processing.
Security-conscious Windows users attempting to protect themselves against Meltdown and Spectre attacks in the wild are being met with a deceptive “Your device is up to date” message — but they’re not yet protected.
In the days following the disclosure of CPU cache attacks Meltdown and Spectre, hardware, kernel, and software developers have rushed to provide security updates for their respective devices and platforms in an (ongoing) effort to secure their users against the wide-ranging (and not yet fully understood/internalized) side-channel vulnerabilities disclosed a few days ago on the 3rd of January, 2018.
For those that aren’t up to date on these attacks – stop now, and read this excellent LWN article on Meltdown and Spectre; if you’re so inclined, you can even have a look at the original Google Project Zero article where it all started.1
While the latter is more technical in nature, programming-inclined readers in the audience may find it to actually be easier to grok with its more definite and concrete approach, vs the somewhat abstract nature of pretty much all the other coverage out there. ↩
Have you ever wanted to quickly find out how long your system has been up and running for? Did you come back to a suspiciously empty desktop when you could have sworn you left some apps open and suspect your PC automatically installed some updates and rebooted while you were gone, but couldn’t be sure? Our latest application, uptime, is the answer you’ve been looking for.
Continuing our promise to open source parts of our libraries and applications where possible, we’ve just released PrettySize, a C# and .NET library for representing file sizes in a human-readable (pretty) format. PrettySize is available for free (MIT-licensed) on GitHub and via NuGet for those that are interested, and forks, contributions, and pull-requests are actively encouraged.1
One of the best benefits of open-sourcing code is that it requires you to take a critical eye to what your code does and how it’s structured. Haphazard code interspersed throughout a dozen different files is cleaned up and re-organized in a way that can only bring benefits all around, from performance to ease-of-use, security, and future maintenance.
If anyone wants to try their hand at implementing IFormattable, consider this an open invitation. It’s not a functionality we ever needed, but some might find it useful. ↩
1Password and LastPass are probably the two best known names in the password storage business, both having been around from 2006 and 2008, respectively. Back in 2008, the internet was a very different place than it is today, especially when it comes to security. Since then, a lot has changed and the world has (hopefully) become a more security-conscious place – and security experts have come to a consensus on a lot of practices and approaches when it comes to encryption and the proper handling of sensitive data.
Both of these password managers are heavily vetted and constantly under scrutiny from security researchers, crackers, state security agencies, white hat hackers, and more with open bug bounty programs [1] [2] (though some considerably more generous than others), and are probably “safe” choices for the average computer user.. to an extent.
One of the biggest improvements to C# and the .NET ecosystem in recent years has been the introduction of the async/await programming paradigm and the improvements it brings to both performance (no need to create thousands of threads if they spend most of their time blocking on IO) and productivity (no need to muck around with synchronization primitives or marshal exceptions between threads). While it takes a bit of getting used to, once you’ve gone async/await, you (literally) can’t go back.
We are proud to present the latest addition to our open source portfolio, the Unicode.net library! We’ve extracted a number of encoding- and emoji-related namespaces and functions from a few of our projects going back many years and split them off to create Unicode.net: an open source library that can be used to aid in the safe processing and manipulation of (possibly) internationalized strings and non-ASCII characters (and then some).
Unicode.net is designed from the ground-up as a modern approach to text processing and text encoding, with only support for the most popular Unicode encodings: UTF-8, UTF-16, and UTF-32. Additionally, Unicode.net is designed to complement .NET’s existing (albeit extremely limited) Unicode support, instead of supplanting it, which primarily translates to embracing rather than shunning the System.String type wherever possible. Unlike many other text-processing libraries, Unicode.net does not want you to stop using the system types for string representation and to switch over to custom datatypes 😁.
This post is chiefly directed at .NET developers and others involved in the various stages of .NET deployment, in particular, anyone that’s been keeping tabs on the situation with the new cross-platform, open-source .NET Core initiative or .NET Standard, which came about as Microsoft’s response to the increased fragmentation of the .NET Platform as a result of the myriad of different deployment targets now available. If you’re not into that kind of stuff, feel free to skip this post, or read on and we’ll try to explain things sufficiently as we go through.
When a new Microsoft, with Satya Nadella at the helm, first open sourced the .NET Platform on November 12, 2014 it became clear that they fully intended to put everything they had into the initiative and that great things and big changes were coming to the .NET Framework and its languages. But what it also signaled was the inevitable beginning of a new level of fragmentation for the Framework, which had thus far – by and large – resisted any major fragmentation for the past 12 years of its existence.1 But taking a framework that was cobbled together from parts old and new, built atop of WIN32, GDI, and various Windows-specific anachronisms meant that porting the .NET Framework as-is to other platforms was nigh-impossible — and that major changes would have to be made to support this gargantuan effort.
There are notable exceptions to this, namely the .NET Micro Framework, the .NET Compact Framework, and Mono; however, these “members” of the .NET ecosystem – one not even by Microsoft – were never considered to be first-class .NET Targets within or without Microsoft. ↩