For much of my childhood, there was no concept of another operating system - Windows 95 was replaced with Windows 98, a friend at a LAN party got me to install Windows 2000 on my own computer. A neighbour’s dad tinkered around with Linux variants like Red Hat, but that only ever seemed like some abstract adventure and never a practical option - especially to a teenager who loved playing games on their computer.

As the years passed, so did the versions of Windows I’d used - Windows 2000 was replaced with Windows XP, which was surrendered to Windows Vista, then 7, 8.1, and 10.

Expanding World Views

I was pretty content with Windows 10, touted as “The Last Version of Windows”. It did what I needed it to, and I had no real reason to look elsewhere. Over the years, I had tried a few Debian/Ubuntu distros, but had usually given up after various issues with window managers and incompatibility with games.

I have had some variant of an Ubuntu server running, first as a VPS and later as a home server. But this has been entirely through terminal / SSH.

My job for the last 15 years has focused on building products targeting Windows, using mainly C#, so both at work and at home I’ve been a consistent Windows user. But with Windows 11, I’ve been continuously less impressed with Windows (and Microsoft at large). At work, I had a week of not being able to open the start menu as it crashed, due to some incompatible Group Policy combined with a Windows update, and many similar small issues.

I also switched teams/products at work and was issued a MacBook (but I still need my Windows laptop for certain product work), which has somewhat triggered a re-evaluation of Windows in my eyes. I will say that while the MacBook Pro (M4) hardware is very impressive - I’m having a hard time getting into the software side of the Apple world.

The Big Shift

As Microsoft moved deeper into its LLM/Copilot frenzy, I finally had enough and took a serious look around - and found that gaming under Linux really has shifted over the last few years. I found myself looking at either Bazzite or CachyOS, and ended up choosing CachyOS for my first serious foray into the Linux desktop in many years.

I went with a dual-boot setup to be able to return to Windows 11 if it turned out the Linux experience left me unable to do something - but nearly two months in I’ve not booted into Windows once. I’m very close to making a clean install of CachyOS on my bigger SSD (where Windows currently lies, waiting and nearly forgotten).

I’ve now played through Resident Evil 9 and am halfway through Death Stranding 2 on CachyOS, and I’ve had very few issues (some nVidia driver issues with RE9, and I had to find some custom launch arguments for DS2) - but they’ve been very minor IMHO.

Due to my work, I’ll still be touching Windows almost daily - but it’s a strangely freeing feeling to know that I’m in no way bound to Windows anymore.

As we produce MedTech devices, they have various requirements on documentation and validation before a release is approved, this affects hardware more severely than software - but we handled development of both essentially as one.

This meant that many of our (Windows Desktop) software products saw updates released every 12 to 18 months, unless there was a critical bug that needed to be fixed - which prompted a hotfix.

Fast-forwarding a few years, in 2019 we got the opportunity to do a fresh start for a project to replace an existing product. Of course this project was named Phoenix (as required by law). This coincided with a new Engineering Manager who had big plans for our software process, which meant assembling a cross-functional agile team that worked in shorter sprints and produced regular releases.

New Times

The team decided on two week long sprints, moved from on-premise systems running TeamCity with self-hosted agents and a big common library of MSBuild tasks to Azure DevOps and Cake. This allowed us several improvmements to our workflow - one of which being we could ensure our builds ran the same when developing locally, as well as when being built by our CI system.

But the greatest gain was the ambition (and support, at least from our nearest manager) to push a release with every sprint. This meant going from 0.75 - 1.0 releases per year to a little over 20 releases per year.

This shortened our feedback loops with our users (and the people who set up and sold systems to our users), giving good focus to the R in R&D. It also meant that we could react much quicker to fix bugs, even when they were not critical.

We released our MVP version to Beta users after a (for us) short 11 sprints, and then version 1.0 to general availability after 17 sprints - and very quickly our users got used to the quick release cadence. We frequently got feedback on new features being tested, and issues that were found were quickly fixed.

The Biggest Changes

The big things we made in order to enable fast and frequent releases were:

Local and CI Builds

As previously mentioned, we leveraged Cake to orchestrate our builds: compiling binaries and installers, running unit tests and code coverage, static code analysis, collecting content and packaging for release, etc. We set this up in a way that when you run the build locally it will do the same operations as when run on CI. This allowed us to be more confident that when we push something to the server, it’s going to build in the same way.

Of course there are some differences we cannot escape, like the CI builds will be signed with a live code signing certificate, while the local builds are signed with a local dummy certificate, etc. We also block any deployments to cloud resources except for when the build runs in CI. But the main part of the build process will behave exactly the same in both environments.

Version Control Discipline

We agreed that any merge into the main branch needed to be “releasable”, meaning first the obvious things like it had to compile, the unit tests needed to pass, etc. But it also meant that there shouldn’t be any half-finished features or known (critical) bugs in the merge.

This was partly handled by having automated checks on all Pull Requests, but also by the team enforcing this belief in discussions and code reviews.

Having a main branch that is always releasable means that if something bad is deployed, it’s easy to go back (or forward) to a good state again.

Feature Toggles

Something we’d never used within our department before, was the concept of Feature Toggles/Switches. Using these allowed us to work on large features that would not necessarily be ready for release, and still merge the code to our main branch without actually affecting users. Our first implementation had a fairly complex setup of sending out feature configs dynamically to clients (along with bundling configs with updates), but after some time we realized that we spent a lot of time maintaining this system and rarely used it.

In the end, we removed the ability to change enabled features remotely, and are just defining the features at compile time (but typically different features are enabled for different installation “tracks”).

Synchronizing With the Others

Probably the biggest pain point was to synchronize this effort with other parts of the organization, which was used to / built around very infrequent releases.

We had to find new contracts with our localization partners, as we now were requesting translations several times a month, rather than 1-3 times per year.

We had to produce regression test reports every sprint, and we had to distil our (manual) regression tests to be more efficient, as they needed to be executed by someone on the team every two weeks.

We tried finding ways around other things to avoid causing overloads on other departments, like Tech Writing who did not appreciate having to update our user manual every two weeks (in the end, they didn’t, and today we update the manuals at most every quarter if something significant has changed or been added).

Post-Mortem, 5 years later

After over 80 releases to Production, the product which was Phoenix has entered into a temporary (?) state of “maintenance” - meaning we don’t work actively on it right now, and only do releases for reported bug fixes. My team was instead assigned to another product in the same “suite” of products, and ended up rewriting it almost entirely from scratch.

We’ve followed essentially the same strategy as we did 5 years earlier, with some tweaks picked up along the way. Over the last year there have been several initiatives across several departments to coordinate better around releases. It has meant that we’ve more frequently needed to use feature toggles to hold back features from General Availability, which is working OK for us - but sometimes it feels odd holding back complete features for several months.

As of late we’ve had parts of the company pushing for essentially a more waterfall-like approach of long-term planning and doing only a few releases per year. We’re trying to reach some compromise which will let us keep up our frequent release schedule, as we believe it’s the best way to deliver continuous value to our users.

I don’t know why I know this, but at some point I became aware and this knowledge haunts me. There are several approaches to localization when it comes to foreign media: original audio and subtitles, dubbing the dialogue in your language, keeping text and signage in the original language or drawing localized text on top of the orginal video, etc.

For Sailor Moon, originally a japanese animated TV-series (based on a manga series) there are many approaches. I’ll focus on the first opening sequence of the show, which has been localized in several different ways.

The original Japanese opening

As a baseline for this comparison, below is a YouTube video showing the original opening sequence:

More reasonable localizations

The Swedish version has a fairly faithful translation of the Japanese song, and keeps the original video as well - but gets a little creative by hiding the japanese text with some credits and then displays the title afterwards.

The (US?) english localization has a more action-oriented feel to its visuals, and actually changes the song - but still keeps “the feeling” of the original opening.

The German localization

Then there’s the German approach…

Here we also have much of the original video, but the Japanese title cards are hidden by showing some other “B footage” instead, afterwards returning to essentially the original video again.

But the song has been entirely replaced with a very upbeat techno-esque song. Don’t get me wrong, it’s a bop, but it sure changes the experience from the original.

Back in May of 2018 I made a fork of a fork of SevenZipSharp (originally found at https://sevenzipsharp.codeplex.com/ ) - a library which exposed 7zip within C#/.NET. I did so because another project I was contributing to was using this library to handle archived files, and needed to add support for RAR5 archives - but the maintainer of the fork we used (essentially the most popular fork at the time) had little interest in maintaining his fork.

When he suggested I create a fork of his repo and start comitting to it, and then he would reference to my fork from his repo before he archived it, I agreed.

Over the years I made several improvements of my own, and got a fair bit of contributions from other GitHub users as well. It’s mildly used across various projects, at the time of writing the NuGet has nearly 475k downloads (which still surprises me).

“Active” work

From converting the unit tests to something that can be run in CI, to actually setting up CI/CD, to fixing bugs and extending format support - I’ve done a lot of things, and even if I’ve technically learned quite a bit about file compression, archives, and formats - I’ve essentially just poked at a system I didn’t quite understand until it did what I thought was right.

Overall it’s been a very pleasant experience, most people have been courteous when reporting issues - responding to my questions and testing my attempted fixes. And especially the incoming contributions from others have been a fun experience - even if the experience of code reviewing someone elses changes into a system I don’t fully grasp has proven stressful at times. I’ve included almost all work suggested/requested, with few exceptions where I’ve not gotten good enough reasoning around changes made.

Decline

Once the novelty of a new (pre-owned?) project had worn off, and the features required by the other project I was contributing to were implemented - it became harder to motivate myself to work on the project. Over the 6 years I’ve taken care of this fork I’ve had several hiatuses, some stretching a full year, where I didn’t do any work on the project. Sometimes I’d look through the reported issues on GitHub, reply to some I knew the answers to - and in some instances actually sit down to try and reproduce reported issues in order to find a fix to the problem.

At some point the project became a source of stress (or shame?), where I felt like I should work on it but couldn’t find the motivation to. A year ago I decided pretty firmly that I would make some final changes and then archive the project - but … that never happened. 🤷‍♂️

As of writing this post I’ve just pushed the last version I intend to create, 1.6.2, to NuGet.org and archived the project on GitHub.

While the action of archiving a project is in no way final or destructive, it does feel like packing it up and putting it away in the attic.

The Problem

The product I am mainly working on is a Windows Desktop application, which consists of two components, installed as separate products: the application itself, and a system service used to provide updates to the application. The system service runs in the background, polling a server for new updates. When the user starts the application, if there is an available update, the system service will update the application and then launch the new version.

The updates of the application come in two variants:

1. Simple file replacement update, to reduce update file size and update time.
2. Full MSI installer upgrade, used when necessary.

In the first case the update is applied while the application is partly running and can launch the application once done.

The second case is trickier, as the application needs to be fully shut down before applying the MSI upgrade. The MSI does have logic for starting the application once the installation completes, but since it’s launched by the system service it runs in Session 0 and is unable to launch the application in the active user session.

The Solution

As with all tricky problems, there is an equally tricky solution - in this case using P/Invoke to leverage low-level Windows functionality is the right tool for the job.

I am going to be referencing various functions here, most of which have good documentation and examples at PInvoke.net.

The solution is to copy a token from a running process in the active session and use it to launch our own process in that same session.

Acquiring a user access token

The first thing we need to do is to find which session is the currently active one, for this we use WTSGetActiveConsoleSessionId to find the session ID. Using this session ID, we look for a process running in that session. We then duplicate the user access token of this process.

var knownProcessId = 0;
var userAccessToken = IntPtr.Zero;
var processTokenHandle = IntPtr.Zero;

// We first need to find the active user session ID.
var activeConsoleSessionId = WTSGetActiveConsoleSessionId();

// Then we need to find the a process running in that session, explorer is typically safe.
foreach (var process in Process.GetProcessesByName("explorer"))
{
    if ((uint)process.SessionId == activeConsoleSessionId)
    {
        knownProcessId = process.Id;
    }
}

// Obtain a handle to the known process.
var processHandle = OpenProcess(ProcessAccessFlagsMaximumAllowed, false, knownProcessId);

// Obtain a handle to the access token of the known process.
if (!OpenProcessToken(processHandle, (uint)TokenAccessLevels.Duplicate, ref processTokenHandle))
{
    Console.WriteLine($"Unable to obtain handle for known process, error code: {Marshal.GetLastWin32Error()}");

    CloseHandle(processHandle);
    return false;
}

// Copy the access token of the known executable process. The newly created token will be a primary token.
var securityAttributes = default(SECURITY_ATTRIBUTES);
securityAttributes.Length = Marshal.SizeOf(securityAttributes);

var duplicationResults = DuplicateTokenEx(processTokenHandle, (uint)TokenAccessLevels.MaximumAllowed, ref securityAttributes, SecurityIdentification, TokenTypeTokenPrimary, ref userAccessToken);

CloseHandle(processHandle);
CloseHandle(processTokenHandle);

if (!duplicationResults)
{
    Console.WriteLine($"Unable to duplicate process token, error code: {Marshal.GetLastWin32Error()}");
    return false;
}

Modifying the duplicated user access token

As icing on the cake, the application I need to start also requires UIAccess, so we need to set that flag as well on the token using SetTokenInformation:

var tokenInformation = 1;
SetTokenInformation(userAccessToken, TokenUiAccess, ref tokenInformation, Marshal.SizeOf(tokenInformation));

var setTokenResult = Marshal.GetLastWin32Error();

if (setTokenResult != 0)
{
    Console.WriteLine($"Unable to set UI access, error code: {setTokenResult}");

    CloseHandle(userAccessToken);
    return false;
}

Note that for this to work, the application you are duplicating a token from also needs to have UIAccess permissions or this won’t work (meaning that explorer used above will not suffice. Luckily for me I had another process I could depend on for this.

Duplicating the user environment

Depending on what process you’re trying to start, you might want to ensure that you have access to the same environment variables as the process you’re copying a token from, e.g., if you’re using %APPDATA%.

if (!CreateEnvironmentBlock(out var environmentBlock, userAccessToken, true))
{
    Console.WriteLine($"Unable to duplicate environment block, error code: {Marshal.GetLastWin32Error()}");

    CloseHandle(userAccessToken);
    return false;
}

Once you have launched your process, you also need to ensure you’re disposing of this duplicated environment:

DestroyEnvironmentBlock(environmentBlock);

Starting the application in the active session

Then we just need to set up the final parts and we can launch the process

var startupInfo = default(STARTUP_INFO);
startupInfo.cb = Marshal.SizeOf(startupInfo);

// This indicates that the process created can display a GUI on the desktop.
startupInfo.lpDesktop = @"winsta0\default";

const uint creationFlags = (uint)ProcessPriorityClass.NORMAL_PRIORITY_CLASS | (uint)ProcessCreationFlags.CREATE_NEW_CONSOLE;

// Create a new process in the current user's active session.
var result = CreateProcessWithTokenW(userAccessToken, LogonFlagWithProfile, null!, executablePathAndArgs, (CreationFlagNewConsole | CreationFlagUnicodeEnvironment), environmentBlock, workingDirectory, ref startupInfo, out _);

if (!result)
{
    Console.WriteLine($"CreateProcessWithTokenW returned {Marshal.GetLastWin32Error()}");
}

CloseHandle(userAccessToken);

Thoughts

This was not the only explored solution to this problem and did not end up being the solution we went with - but I still thought it was interesting enough that I wanted to document it here.

While I often try to avoid resorting to P/Invokes, this solution is fairly robust (but make sure to destroy and release everything) - it makes no crazy assumptions and should work on any Windows version since Vista.

Final result

Here is the full snippet of code to be able to launch a process in another user session:

#region P/Invokes

[DllImport("kernel32.dll")]
public static extern uint WTSGetActiveConsoleSessionId();

[DllImport("kernel32.dll")]
public static extern IntPtr OpenProcess(uint dwDesiredAccess, bool bInheritHandle, int dwProcessId);

[DllImport("advapi32.dll", SetLastError = true), SuppressUnmanagedCodeSecurity]
public static extern bool OpenProcessToken(IntPtr ProcessHandle, uint DesiredAccess, ref IntPtr TokenHandle);

[DllImport("kernel32.dll", SetLastError = true)]
public static extern bool CloseHandle(IntPtr hHandle);

[DllImport("advapi32.dll", EntryPoint = "DuplicateTokenEx")]
public static extern bool DuplicateTokenEx(
    IntPtr hExistingToken,
    uint dwDesiredAccess,
    ref SECURITY_ATTRIBUTES lpTokenAttributes,
    int ImpersonationLevel,
    int TokenType,
    ref IntPtr phNewToken);

[DllImport("advapi32.dll", SetLastError = true)]
public static extern bool SetTokenInformation(IntPtr TokenHandle, int TokenInformationClass, ref int TokenInformation, int TokenInformationLength);

[DllImport("advapi32", SetLastError = true, CharSet = CharSet.Unicode)]
public static extern bool CreateProcessWithTokenW(
    IntPtr hToken, 
    int dwLogonFlags, 
    string lpApplicationName, 
    string lpCommandLine, 
    int dwCreationFlags, 
    IntPtr lpEnvironment, 
    string lpCurrentDirectory, 
    [In] ref STARTUP_INFO lpStartupInfo, 
    out PROCESS_INFORMATION lpProcessInformation);

[DllImport("userenv.dll", SetLastError = true)]
public static extern bool CreateEnvironmentBlock(out IntPtr lpEnvironment, IntPtr hToken, bool bInherit);

[DllImport("userenv.dll", SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool DestroyEnvironmentBlock(IntPtr lpEnvironment);

#region Structs

[StructLayout(LayoutKind.Sequential)]
public struct SECURITY_ATTRIBUTES
{
    public int Length;
    public IntPtr lpSecurityDescriptor;
    public bool bInheritHandle;
}

[StructLayout(LayoutKind.Sequential)]
public struct STARTUP_INFO
{
    public int cb;
    public string lpReserved;
    public string lpDesktop;
    public string lpTitle;
    public uint dwX;
    public uint dwY;
    public uint dwXSize;
    public uint dwYSize;
    public uint dwXCountChars;
    public uint dwYCountChars;
    public uint dwFillAttribute;
    public uint dwFlags;
    public short wShowWindow;
    public short cbReserved2;
    public IntPtr lpReserved2;
    public IntPtr hStdInput;
    public IntPtr hStdOutput;
    public IntPtr hStdError;
}

[StructLayout(LayoutKind.Sequential)]
public struct PROCESS_INFORMATION
{
    public IntPtr hProcess;
    public IntPtr hThread;
    public uint dwProcessId;
    public uint dwThreadId;
}

#endregion

#region Constants

private const uint ProcessAccessFlagsMaximumAllowed = 0x2000000;
private const int SecurityIdentification = 1;
private const int TokenTypeTokenPrimary = 1;
private const int TokenUiAccess = 26;
private const int LogonFlagWithProfile = 1;
private const int CreationFlagNewConsole = 0x00000010;
private const int CreationFlagUnicodeEnvironment = 0x00000400;

#endregion

#endregion

public static bool LaunchProcessInUserSession(string executablePathAndArgs, string workingDirectory, bool requireUiAccess)
{
    var knownProcessId = 0;
    var userAccessToken = IntPtr.Zero;
    var processTokenHandle = IntPtr.Zero;

    // We first need to find the active user session ID.
    var activeConsoleSessionId = WTSGetActiveConsoleSessionId();

    // Then we need to find the a process running in that session, explorer is typically safe.
    foreach (var process in Process.GetProcessesByName("explorer"))
    {
        if ((uint)process.SessionId == activeConsoleSessionId)
        {
            knownProcessId = process.Id;
        }
    }

    // Obtain a handle to the known process.
    var processHandle = OpenProcess(ProcessAccessFlagsMaximumAllowed, false, knownProcessId);

    // Obtain a handle to the access token of the known process.
    if (!OpenProcessToken(processHandle, (uint)TokenAccessLevels.Duplicate, ref processTokenHandle))
    {
        Console.WriteLine($"Unable to obtain handle for known process, error code: {Marshal.GetLastWin32Error()}");

        CloseHandle(processHandle);
        return false;
    }

    // Copy the access token of the known executable process. The newly created token will be a primary token.
    var securityAttributes = default(SECURITY_ATTRIBUTES);
    securityAttributes.Length = Marshal.SizeOf(securityAttributes);

    var duplicationResults = DuplicateTokenEx(processTokenHandle, (uint)TokenAccessLevels.MaximumAllowed, ref securityAttributes, SecurityIdentification, TokenTypeTokenPrimary, ref userAccessToken);

    CloseHandle(processHandle);
    CloseHandle(processTokenHandle);

    if (!duplicationResults)
    {
        Console.WriteLine($"Unable to duplicate process token, error code: {Marshal.GetLastWin32Error()}");
        return false;
    }

    var startupInfo = default(STARTUP_INFO);
    startupInfo.cb = Marshal.SizeOf(startupInfo);

    // This indicates that the process created can display a GUI on the desktop.
    startupInfo.lpDesktop = @"winsta0\default";

    if (requireUiAccess)
    {
        var tokenInformation = 1;
        SetTokenInformation(userAccessToken, TokenUiAccess, ref tokenInformation, Marshal.SizeOf(tokenInformation));

        var setTokenResult = Marshal.GetLastWin32Error();

        if (setTokenResult != 0)
        {
            Console.WriteLine($"Unable to set UI access, error code: {setTokenResult}");

            CloseHandle(userAccessToken);
            return false;
        }
    }

    if (!CreateEnvironmentBlock(out var environmentBlock, userAccessToken, true))
    {
        Console.WriteLine($"Unable to duplicate environment block, error code: {Marshal.GetLastWin32Error()}");

        CloseHandle(userAccessToken);
        return false;
    }

    var result = CreateProcessWithTokenW(userAccessToken, LogonFlagWithProfile, null!, executablePathAndArgs, (CreationFlagNewConsole | CreationFlagUnicodeEnvironment), environmentBlock, workingDirectory, ref startupInfo, out _);

    if (!result)
    {
        Console.WriteLine($"CreateProcessWithTokenW returned {Marshal.GetLastWin32Error()}");
    }

    DestroyEnvironmentBlock(environmentBlock);
    CloseHandle(userAccessToken);

    return result;
}

This first post will be a short outline of how I set up the website. The site is generated with Hugo using the Hello Friend NG theme, hosted compiled on my own GitLab instance and uploaded automatically to my own nginx webserver.

Using GitLab’s CI/CD system, the site is built and deployed on each commit pushed to the main branch. I’m impressed that it takes about 10 seconds from pushing a commit until the site is updated.