DEV Community: Peter Repukat

Supporting ancient browsers using modern Web-Tooling

Peter Repukat — Tue, 20 Aug 2024 13:32:51 +0000

In recent years, IE has become deprecated and Web-Developers often don't need to worry about backward-compatibility much anymore.

However, there are still scenarios where supporting older browsers is required, especially in industrial settings.

I recently encountered this challenge while developing a web-based Human-Machine Interface (HMI) for a client.

The requirement? Make it work with an old Qt-Embedded Browser based on Chromium 56, a browser-engine released in January 2017.

Yes, you read that right – that's over seven years old!

This presented unique challenges, as the baseline for modern tooling doesn't account for browsers that old anymore.

However, with just a tiny amount of work, it's surprisingly manageable to support these ancient platforms with modern tools.

TL;DR

For those who want to skip the details, here are the key tools:

Vite-Plugin-Legacy - For ES5 conversion and polyfilling
PostCSS Preset Env - For using modern CSS features - (For Ancient Browsers) Avoid using CSS-Grid, opt for Flexbox instead
(If needed) Patch dependencies with PNPM-Patch (or similar tools)

The Challenges of Supporting Chromium 56

Before we dive into solutions, let's outline the main hurdles:

ES5-only JavaScript: No support for ES6+ features
No ES Modules: The baseline for modern JavaScript tooling is not available.
Limited CSS Support: Many modern CSS features are not supported
No BigInt: The DataType, needed by a dependecy of MQTT.js, is not available.

Solution 1: Converting to ES5 and Polyfilling with Vite

Vite has become pretty much the norm for modern web development, but did you know it can also help support older browsers? Enter vite-plugin-legacy.

This plugin automatically converts modern JavaScript and adds necessary polyfills based on Browserlist-targets using Babel.

It's extremely easy to set up:

import { defineConfig } from 'vite';
import legacy from '@vitejs/plugin-legacy';

export default defineConfig({
    plugins: [
        // ... your other plugins,
        legacy({
            targets: ['defaults', 'chrome 56'],
        }),
    ]
});

With this configuration, Vite will generate two bundles: a modern one for newer browsers and a legacy one for older browsers like Chromium 56.

It also includes a runtime script that loads the appropriate bundle based on the user's browser.

Solution 2: Enhancing CSS Support with PostCSS Preset Env

To bring modern CSS features to older browsers, we can use postcss-preset-env. PostCSS allows you to use modern and or future CSS features and automatically adds prefixes and, most importantly, polyfills as needed.

If you don't know PostCSS, you probably already heard of Tailwind, right? It's just another PostCSS-Plugin ;)

As Vite has support for PostCSS included, all one has to do is to install the preset-env plugin and create a postcss.config.js-file

/** @type {import('postcss-load-config').Config} */
import presetEnv from 'postcss-preset-env';

const config = {
    plugins: [
        presetEnv({
            autoprefixer: true,
            stage: 3,
            features: {
                'nesting-rules': true,
                'has-pseudo-class': true,
            },
            browserslist: ['defaults and chrome >= 56'],
        }),
    ],
};

export default config;

This setup allows you to use many modern CSS features while ensuring compatibility with your Browserlist-targets, like Chromium 56.

Gotchas and Workarounds

While the above solutions solve many issues, there are still some gotchas to be aware of:

CSS Grid: Polyfills for CSS Grid and gap properties exist, but are not very performant or well maintained...

For ancient browsers, it's often better to fall back to Flexbox with margins.

It might not be as elegant, but it gets the job done without significant performance hits.

BigInt Issues: Some libraries (like MQTT.js in my case) have dependencies that use BigInt, which isn't available in older browsers. Babel doesn't provide a BigInt polyfill, so we need to get creative.

Solution 3: Patching Dependencies

When all else fails, you might need to patch your dependencies. I encountered this with MQTT.js, where a dependency was using BigInt (in my case unnecessarily). Here's how I solved it using pnpm's patch feature:

Run pnpm patch <package-name> to create a temporary folder with the package's source code.
Edit the files in this temporary folder, replacing or removing all occurrences of BigInt.
Apply the patch with pnpm patch-commit <temporary-folder>.

This creates a .pnpm-patches folder in your project, and the patch will be automatically applied whenever you run pnpm install.

You could provide a BigInt polyfill and replace the native BigInt with it.

In most cases, this is probably the better solution - In my specific case however, that wasn't necessary, so I just opted to remove it.

Conclusion

Supporting ancient browsers doesn't mean you have to give up on modern development tools and frameworks.

With tools like Vite, PostCSS, and clever use of dependency patching, you can very easily develop without too much thought of platforms from yesteryear.

Why Svelte is a game changer for IIoT development

Peter Repukat — Wed, 07 Aug 2024 08:42:40 +0000

Disclaimer: This was originally posted on my own blog

If you've done any development on IIoT HMIs, you've probably spent countless hours wrestling with bulky frameworks, trying to make them play nice with old and outdated IIoT systems. Well, grab a coffee (or your beverage of choice), and let me tell you about how Svelte might just make your life a whole lot easier.

TL;DR:

Tiny bundles for resource-constrained devices
Lightning-fast performance with minimal overhead
Sveltes small ecosystem is not a problem
DX Matters: Intuitive syntax for rapid development
UI-polish with "no-code"-animations

The Svelte Advantage

In recent years, I have mainly done development and consulting work on IIoT (or adjacent) projects. Modern solutions often use web-technologies for their HMIs and dashboards.
I've used the big three Frameworks (React, Vue, Angular) with great success in that area, however, when I discovered Svelte, I was immediately impressed by its potential.
After a few years of working with Svelte on the side, I'm, certain that Svelte could be a game-change for HMI development.
Let's explore why:

1. Bundle Size

Let's face it, when you're working with IIoT devices that have less processing power than your toaster, the size of your application matters significantly. Svelte shines in this area with its remarkably small bundle size. Unlike traditional frameworks that ship the entire library to the browser, Svelte does most of its work at compile-time, resulting in minimal runtime code.

2. Low Runtime Overhead

Svelte's approach to reactivity sets it apart from other frameworks. Instead of using a virtual DOM, Svelte compiles your code to efficient vanilla JavaScript that updates the DOM directly. This results in lower runtime overhead, making Svelte applications incredibly fast and responsive.

For IIoT HMIs, where real-time data updates and immediate user feedback are often critical, this efficiency can make or break a whole project.

3. The Ecosystem Myth

Okay, I hear you. "But what about all those shiny React components and wrappers?"
While it's true that Svelte's ecosystem is significantly smaller than those of the big three frameworks, it actually isn't a problem at all.

Svelte's simplicity allows for easy integration with vanilla JavaScript libraries, which can be a game-changer.
How often have you wrestled with a specific library that has a wrapper for your chosen framework, but doesn't quite have the feature set your client needs? Only to choose another framework down the line and end up writing your own wrapper anyway?

By leveraging vanilla JavaScript libraries directly, you not only ditch the reliance on often times questionably maintained wrappers, you're also expanding your toolkit beyond the limitations of framework-specifics.

4. Developer-Friendly Experience

One of Svelte's standout features is its intuitive, easy-to-learn syntax. As someone who has worked extensively with Svelte as well as other frameworks, I can attest that its learning curve is notably gentler than other frameworks. This translates to:

Faster development cycles
Easier onboarding of new team members
More maintainable code in the long run

In my experience, projects that would take weeks with other frameworks can often be completed in days with Svelte, allowing for more rapid prototyping and iteration.

5. Built-in Transitions and Animations

While industrial interfaces prioritize functionality, user experience remains important.
Well crafted animations and transitions can enhance the overall UX greatly, but are often time-consuming and hard to implement well.
Svelte provides built-in, efficient and well crafted transitions and animations, that don't require more code than specifying what elements should have them applied to.
This makes it trivial to create smooth and intuitive interfaces.

Conclusion

While my direct experience with Svelte has been primarily outside the IIoT domain, the framework's characteristics align well with the unique challenges of industrial interface development. Its small footprint, high performance, and developer-friendly nature make it a promising candidate for building modern and efficient HMIs.

If you're considering upgrading your IIoT interfaces or starting a new project, Svelte is certainly worth exploring. Its potential to streamline development, enhance performance, and improve maintainability could provide significant benefits in the industrial context.

As we continue to push the boundaries of what's possible in IIoT, tools like Svelte offer exciting opportunities to create more responsive, efficient, and user-friendly industrial interfaces. I'm looking forward to seeing how this technology can be leveraged to drive innovation in the IIoT space.

If you're interested in discussing Svelte or IIoT development, feel free to reach out.
If you need any of my expertise in a professional setting, you can hire me or my colleagues via my employer, CmdScale.

Customizing the godawul MS Teams

Peter Repukat — Sun, 10 Apr 2022 17:45:40 +0000

So, I recently got a new job, and we use Teams for communication. Instead of the way better alternatives like Slack, for example.

I got fed up with how much "M$ Teams" sucks and decided to look into customizing it.

The result of one weekend of hacking is a proof of concept tool which allows you to enable debugging of the Teams app and even inject Javascript/CSS (this functionality is pretty limited ATM).

The whole project needs a lot of help, currently.

So, fellow developers, that suffer from having to use the super shitty Teams, please take a look at and hack at it.

Source: https://github.com/Alia5/MS-Teams-Customize
NPM: https://www.npmjs.com/package/msteams-customizer

If you want to help and have any questions, feel free to reach out via twitter

Advanced Typescript Types, explanations and Cheatsheet

Peter Repukat — Wed, 12 Jan 2022 19:23:12 +0000

Disclaimer: This was originally posted on my own blog

This post might get updated from time to time.

TL;DR: GitHub-Gist
Skip all the explanations and just see types

I've grown pretty fond of Typescript in recent years.
In particular I very much like its Turing-complete type system.

Typescript provides a fair share of built-in Utility-Types, however, I always come back copy-pasta-ing from my old code when requiring more complex util-types.

So here's kind of a cheat-sheet, with examples and explanations, for some of the advanced types I've built and used within the last years.

Also, check out SimplyTyped or TypeFest. They contain some truly mind-boggling, but extremely useful stuff.

I try not to include it in every one of my projects, so there might be some duplicates.

As I find it pretty hard to explain more in-depth types, let me know where you would like to see clarification.
Also let me know if you know any other cool, usefull or mindbending stuff!

So, without further ado, Let's dive in

Await Type

This one is pretty straightforward.
We use the built-in PromiseLike type to check if the input really is a promise.
If it is, use the infer keyword to deduce its type-argument and recursively 'call' Await again.
If not, just return the input.

type Await<T> = T extends PromiseLike<infer U> ? Await<U> : T;

const asyncFn = async (): Promise<number> => new Promise((res) => res(1337));

type ResolvedReturnType = Await<ReturnType<typeof asyncFn>>; // = number

Playground

Length Type

Another simple one is the Length type.

You can use this for example to infer the number of parameters to a given function or (readonly) array-lengths
There is, however, another clever use, to which we will come back later.

export type Length<T> = T extends { length: infer L } ? L : never;

type MyFnType = (a: number, b: string, c: number) => unknown;

type NumParams = Length<Parameters<MyFnType>>; // = 3

Playground

KeysOfType

I find this one particularly useful from time to time.
It returns the keys of a given interface O, but only if they are of type T

export type KeysOfType<O, T> = {
    [K in keyof O]: O[K] extends T ? K : never;
}[keyof O];


// example 

interface MyInterface {
    keyA: number,
    keyB: string,
    keyC: Record<string, MyInterface>,
    keyD: 1337
};

type KeysOfTypeNumber = KeysOfType<MyInterface, number>; // 'keyA' | 'keyD'

This one is not as easy to unserstand, so how does it work?
First, we create a new type that contains all of the keys of O,
then we get the valueType of O by its key O[K] and then check if it is of type T
If so, we just use the key K as our value, otherwise, we use never.
This would result in something like { keyA: 'keyA'; keyB: never }
The last step now is to look up this intermediate type, by all the keys of our interface O.
The never type gets discarded when looking up a type like this.
But because of this, if we wanted to filter our interface, we cannot just leave out the lookup.

Bonus: PickByType

// ConvertLiterals would convert literal types like `1337` to their base type like `number` if set to true 
export type PickByType<O, T, ConvertLiterals extends boolean = false> = {
    [K in KeysOfType<O, T>]: ConvertLiterals extends true ? T : O[K]
};

type PickedByNumber = PickByType<MyInterface, number>; // { keyA: number; keyD: 1337 }

Playground

OneOf

Suppose you have an Interface (or intersecting Interfaces) and you want to create a (strict) Union type from it.
In the aforementioned SimplyTyped library, there exist types with which you can do the same thing.
I personally like this version better, though, as it's a single 'one-liner' (cough) type that one can even parameterize.

Let's start with just the type

export type OneOf<T, Strict extends boolean = true> = {
    [OuterKey in keyof T]: Strict extends false
        ? { [K in OuterKey]: T[K] }
        : { [InnerKey in OuterKey|keyof T]?: InnerKey extends OuterKey ? T[OuterKey] : never } & { [TheKey in OuterKey]: T[OuterKey] } 
}[keyof T];

Now break this down somewhat.
First, we omit the second type parameter Strict and only use the then false-case and just look at a simpler Unionize type

export type Unionize<T> = {
    [OuterKey in keyof T]: { [K in OuterKey]: T[K] }
}[keyof T];

This creates a type with the keys of the input type T as key and a new dictionary type containing a single key-of T and the corresponding value type of T as value.
Afterward, we use the look-up trick we already used above to get a union type of the inner dictionary types (hence the unionize name)

interface MyIface {
    keyA: number;
    keyB: string;
}

type Demo = Unionize<MyIface>; // = { keyA: number } | { keyB: string }

However...

const a: Unionize<MyIface> = { keyA: 1337 }; // ok
const b: Unionize<MyIface> = { keyA: 1337, keyB: 'foo' }; // also okay

This is because union dictionary types are not exclusive.
In some cases, it can be okay, other times you'd want it to be strict.
So let's look at that

export type OneOf<T> = {
    [OuterKey in keyof T]: {
            [InnerKey in OuterKey|keyof T]?: InnerKey extends OuterKey ? T[OuterKey] : never
        } & {
            [TheKey in OuterKey]: T[TheKey] 
        } 
}[keyof T];

Now, this is a bit more complex.
If we look closely, however, it is the same as the Unionize type shown above except for an intersecting type: { [InnerKey in OuterKey|keyof T]?: InnerKey extends OuterKey ? T[OuterKey] : never }.
Let's break this down some more.

OuterKey is a single key of our input-type T. Create a union with that and with all keys of T as keys for the inner dictionary ([InnerKey in OuterKey|keyof T]: ...).
For the value of the inner dictionary, we check if the current InnerKey is the OuterKey (InnerKey extends OuterKey ...).
If it is, we use the value-type of our original type T, otherwise never.
The last part is to make every key for this dictionary optional (the ? after the key declaration).

Now this gives us a type which, has all keys of the input-type, but only a single key is allowed to be assigned with a value-type other than undefined.
That means we can still use undefined, though.
We can still use undefined, though.
To mitigate this, we add an intersection to an inner dictionary, that being the one we've seen in the Unionize type, as it doesn't allow undefined.

The result is the something like this

export type OneOf<T, Strict extends boolean = true> = {
    [OuterKey in keyof T]: Strict extends false
    ? { [K in OuterKey]: T[K] }
    :   {
            [InnerKey in OuterKey|keyof T]?: InnerKey extends OuterKey ? T[OuterKey] : never
        } & {
            [TheKey in OuterKey]: T[TheKey] 
        } 
}[keyof T];


// example
interface MyInterface {
    keyA: number,
    keyB: string,
    keyC: Record<string, unknown>,
    keyD: 1337
};

type OnlyOne = OneOf<MyInterface>; // ^= more or less strict version of { keyA: number } | { keyB: string } | { keyC: Record<string, MyInterface> } | { keyD: 1337 }
type NonStrictVersion = OneOf<MyInterface, false>; // { keyA: number } | { keyB: string } | { keyC: Record<string, MyInterface> } | { keyD: 1337 }

Playground

Tuple Manipulation

Tuples, combined with the ability to spread them and infer single or even rest-types, are an incredibly useful tool when dealing with more complex types.
So here are a few basic manipulation types starting with:

Push, PushFront, Pop, PopFront, Shift, ShiftRight

type Push<T extends unknown[], U> = T extends [...infer R] ? [...T, U] : never;
type PushFront<T extends unknown[], U> = T extends [...infer R] ? [U, ...T] : never;
type Pop<T extends unknown[]> = T extends [...infer R, infer U] ? U : never;
type PopFront<T extends unknown[]> = T extends [infer U, ...infer R] ? U : never;
type Shift<T extends unknown[]> = T extends [infer U, ...infer R] ? R : never;
type ShiftRight<T extends unknown[]> = T extends [...infer R, infer U] ? R : never;

These should all be pretty straightforward.
Note: You could just as well use any instead of infer X where X isn't used.

Reverse

Since there are no loop-functions for TypeScripts type-system, and we somehow need to iterate over the input tuple, we have to use recursion.
To check when the recursion needs to end, we can use the aforementioned Length-type. Afterward, just Pop from one tuple, and Push to another.

type Reverse<T extends unknown[], U extends unknown[] = []> = Length<T> extends 1 ? Push<U, Pop<T>> : Reverse<ShiftRight<T>, Push<U, Pop<T>>>;

A little bit special here is the second type-parameter, which is default initialized to an empty tuple.
We basically use that as our return value, after recursively filling it from the input T.
If you wanted to restrict any other devs in your codebase to do nasty things with the second type parameter, you can just wrap the above implementation.

Filter, TupleIncludes

Next, let's look at a filter-type. This one's also pretty simple.
First, check if our tuple is empty. If it's not, infer the first Element F and the rest of the tuple as another type R.
Then we check if F is equal to, or extends, the type we want to filter out.
If it is, return Filter again, but this time on the rest R without F.
Otherwise, we return a new tuple, with F at the front and a spread (...) of the filtered-rest.

Combining the Filter type with our handy-dandy Length-type, we can also build an Includes-type by simply comparing the lengths of the filtered and unfiltered tuple!

type Filter<T extends unknown[], U> = T extends [] ? [] : T extends [infer F, ...infer R] ? F extends U ? Filter<R, U> : [F, ...Filter<R, U>] : never
type TupleIncludes<T extends unknown[], U> = Length<Filter<T, U>> extends Length<T> ? false : true

Playground

You may have noticed that I didn't actually call the Includes-type like that, but rather TupleIncludes.
We'll come back to that just below...

Template Literal Types

My favorite "subtype" of Types.
Introduced in TypeScript 4.1, they really filled a gap for me.
With them, you can do so much fancy and mindblowing stuff
Someone even wrote a full-blown CSS-Parser 🤯!

Fancyness aside, I also want to share a few types I've found useful to me.

StringIncludes

The nice part about template literals is that you can infer literal types from them.
Even nicer: You can infer empty strings!
Which makes a type that can check if any string includes another pretty trivial.

type StringIncludes<S extends string, D extends string> = S extends `${infer T}${D}${infer U}` ? true : false;

type Demo1 = StringIncludes<'a.b', '.'>; // = true
type Demo2 = StringIncludes<'ab', '.'>; // = false
type Demo3 = StringIncludes<'a.', '.'>; // = true
type Demo4 = StringIncludes<'.', '.'>; // = true

As we now also have a StringIncludes type, we can now combine that with the TupleIncludes from above, to get a completely generic Includes type

type Includes<T extends unknown[]|string, U> = T extends unknown[] ? TupleIncludes<T, U> : T extends string ? U extends string ? StringIncludes<T, U> : never : never;

Template literal types are (or were, at the time of initially writing most of this), however, for some reason, more restricted than tuples, so we need to build a few types to help with that.

Split

type Split<S extends string, D extends string> =
    string extends S ? string[] :
        S extends '' ? [] :
            S extends `${infer T}${D}${infer U}` ?  [T, ...Split<U, D>] : [S];

You may wonder why the first conditional is string extends S.
If you haven't guessed, it's the check if string itself is passed as a type argument, instead of any literal.
Any literal string extends string - but string doesn't extend any literal string

Here's some code to better explain:

type Demo<S extends string> = string extends S ? 'used string' : `used literal: ${S}`;

type D1 = Demo<'str'>; // = 'used literal: str'
type D2 = Demo<string>; // = 'used string'

Join

type Join<T extends unknown[], D extends string> = string[] extends T ? string : T extends string[]
  ? PopFront<T> extends string ? Length<T> extends 1 ? `${PopFront<T>}` : `${PopFront<T>}${D}${Join<Shift<T>, D>}` : never
  : never;

Using what we've learned so far and some of the tuple manipulation types above, we can now join any string tuple back to a string.

Playground

Example using all of this

A cool and really useful example, using most of the above util-types, is dealing with "Paths" and nested-types of dictionaries.

(Explanations for those are left as an excersice for the reader)

Let's start with valid Paths

ValidPaths, ValidPathTuples

At the time of initially writing this, the Tuple version was the only one working.In most recent TS versions both work, however, the string literal version has got some gotchas and so the tuple version is somewhat preferred.

const dictionary = {
  someProp: 123,
  nested: {
    moreProps: 333,
    deeper: {
      evenDeeper: {
        deepest: 'string'
      }
    },
    alsoDeeper: {
      randomProp: {
        anotherProp: 'wtf'
      }
    }
  }
} as const;

type MyDict = typeof dictionary;

// If you look at type "Debug" below, this surprisingly works.
// You may get a `Type instantiation is excessively deep and possibly infinite.`-error if you're using an older TS version, though
type ValidPaths<T> = keyof T extends never ? never : ({
     [K in keyof T]: T[K] extends never ? never : T[K] extends Record<string|number|symbol, unknown>
       ? K extends string ? `${K}.${ValidPaths<T[K]>}` | K : never
       : K
   })[keyof T] & string;

type Debug = ValidPaths<MyDict>;

// With Tuples.
type ValidPathTuples<T> = keyof T extends never ? never : ({
     [K in keyof T]: T[K] extends never ? never : T[K] extends Record<string|number|symbol, unknown>
       ? [K, ...ValidPathTuples<T[K]>] | [K]
       : [K]
   })[keyof T];

type DebugTuples = ValidPathTuples<MyDict>;

// on recent TS versions you can even join the tuples back to "PathStrings"
type DebugTuples1 = Join<ValidPathTuples<MyDict>, '.'>;

typescript
Playground

NestedType, NestedTypeByTuple

We can also craft a type that gets us the nested-type of a dictionary for any valid path, or throw an error if an invalid path is passed.
And of course we can put it all together in a beautiful function where only valid Paths are allowed as parameter and the return type is automagically deduced for us.

// string version
type NestedType<T, P extends string> = (
  Includes<P, '.'> extends true
    ? PopFront<Split<P, '.'>> extends keyof T
      ? NestedType<T[PopFront<Split<P, '.'>>], Join<Shift<Split<P, '.'>>, '.'>>
      : never
    : P extends keyof T ? T[P] : never
);

type DemoNested1 = NestedType<MyDict, "nested.moreProps">; // 333
type DemoNested2 = NestedType<MyDict, "nested.deeper.evenDeeper">; // { readonly deepest: "string" }
type DemoNestedNever = NestedType<MyDict, "nested.randomProp">; // never

// tuple version
type NestedTypeByTuple<T, P extends string[]> = (
  Length<P> extends 1
    ? Pop<P> extends keyof T ? T[Pop<P>] : never
    : PopFront<P> extends keyof T ? Shift<P> extends string[] 
      ? NestedTypeByTuple<T[PopFront<P>], Shift<P>>
      : never : never
);

type DemoNestedTuple1 = NestedTypeByTuple<MyDict, ["nested" ,"moreProps"]>; // 333
type DemoNestedTuple2 = NestedTypeByTuple<MyDict, ["nested" , "deeper", "evenDeeper"]>; // { readonly deepest: "string" }
type DemoNestedTupleNever = NestedTypeByTuple<MyDict, ["nested", "sillyProp"]>; // never

// String version internally using tuples
// Bonus: Also errors now
type NestedTypeUsingTuplesAgain<T, P extends ValidPaths<T>> = NestedTypeByTuple<T, Split<P, '.'>>;

type Convoluted = NestedTypeUsingTuplesAgain<MyDict, 'nested.alsoDeeper'>;
type ConvolutedError = NestedTypeUsingTuplesAgain<MyDict, 'nested.nonExistant'>;

// And now we can finally give lodash's `get` function a run for it's money
function GetByPath<T, P extends ValidPaths<T>>(dict: T, path: P): NestedType<T, P> {
 // internal impl. must be different. only demoing types here!
 return (dict as any)[path];
}

Playground

Overlay WindowsStore-Apps (UWP) without code-signing

Peter Repukat — Thu, 06 Jan 2022 19:31:05 +0000

Disclaimer: This post was originally posted on my own blog

Introduction

I came to discover that, you cannot simply overlay Metro/UWP/Windows-Store Apps (or whatever they are called these days) using always on top windows.

I learned while it is possible, for that to work the program has to have the uiAccess=True-flag set in the manifest, and it must be signed.
That, of course, isn't good news for any hobby or small open-source project, as code-signing certificates cost money.
There is another way, however...

But first, let's see what happens if you try to focus any old “always on top”-window while running a fullscreen store app.
If that happens, it causes the Windows Store app in “fullscreen”-mode to instantly minimize.
Even though store apps never really run in exclusive fullscreen!

Some programs however are perfectly capable of doing this, like the Windows Taskbar itself or DisplayFusions intermediate loading window...

I asked the developers of DisplayFusion how they are doing it, and they shared the secret with me: The aforementioned uiAccess=True-flag along with a signed executable.

For my endless quest in getting Steam Input to work with stuff it normally doesn't, an overlay for Windows Store apps would be a real boon.
But spending ~100 bucks per year for a free project, that I have way too little time to properly maintain and support, doesn't seem all too appealing.

Luckily, with a bit of hacking, using undocumented Windows APIs, I managed to get it to work.
I think the whole process is rather interesting, and so I wanted to share it with you.

Window z-order

Z-ordering in Windows 10 (up from Win8) works in so-called “WindowBands”
The order of (some) bands, from lowest to highest, is as follows:

ZBID_DESKTOP
ZBID_IMMERSIVE_BACKGROUND
ZBID_IMMERSIVE_APPCHROME
ZBID_IMMERSIVE_MOGO
ZBID_IMMERSIVE_INACTIVEMOBODY
ZBID_IMMERSIVE_NOTIFICATION
ZBID_IMMERSIVE_EDGY
ZBID_SYSTEM_TOOLS
ZBID_LOCK (Win10)
ZBID_ABOVELOCK_UX (Win10)
ZBID_IMMERSIVE_IHM
ZBID_GENUINE_WINDOWS
ZBID_UIACCESS

If you're wondering why you never heard of “WindowBands” before, it is because you normally won't get to use them (explicitly).
All the APIs are undocumented and not made publicly available by Microsoft.
But we will get to that.

Any regular old window gets created with ZBID_DESKTOP and will remain there.
Setting a window to be always-on-top using SetWindowPos(...) will just change the ordering inside the ZBID_DESKTOP-band.
An expectation to that is, for example, the previously mentioned uiAccess=True-flag
with a signed executable. Then the window will get created in the ZBID_UIACCESS
-band.

If any ZBID_DESKTOP-window gets “touched” while running a store app in “fullscreen”-mode, the store app gets minimized.
Other bands don't necessarily cause that behavior.

Using other WindowBands

Code

Enum

enum ZBID
{
    ZBID_DEFAULT = 0,
    ZBID_DESKTOP = 1,
    ZBID_UIACCESS = 2,
    ZBID_IMMERSIVE_IHM = 3,
    ZBID_IMMERSIVE_NOTIFICATION = 4,
    ZBID_IMMERSIVE_APPCHROME = 5,
    ZBID_IMMERSIVE_MOGO = 6,
    ZBID_IMMERSIVE_EDGY = 7,
    ZBID_IMMERSIVE_INACTIVEMOBODY = 8,
    ZBID_IMMERSIVE_INACTIVEDOCK = 9,
    ZBID_IMMERSIVE_ACTIVEMOBODY = 10,
    ZBID_IMMERSIVE_ACTIVEDOCK = 11,
    ZBID_IMMERSIVE_BACKGROUND = 12,
    ZBID_IMMERSIVE_SEARCH = 13,
    ZBID_GENUINE_WINDOWS = 14,
    ZBID_IMMERSIVE_RESTRICTED = 15,
    ZBID_SYSTEM_TOOLS = 16,
        // Win10
    ZBID_LOCK = 17,
    ZBID_ABOVELOCK_UX = 18,
};

CreateWindowInBand

Same as CreateWindowEx except with 1 more parameter dwBand where you specify the band the window should stay.

HWND WINAPI CreateWindowInBand(
     DWORD dwExStyle,
     LPCWSTR lpClassName,
     LPCWSTR lpWindowName,
     DWORD dwStyle,
     int x,
     int y,
     int nWidth,
     int nHeight,
     HWND hWndParent,
     HMENU hMenu,
     HINSTANCE hInstance,
     LPVOID lpParam,
     DWORD dwBand);

SetWindowBand

Same as SetWindowPos except with 1 more parameter dwBand

BOOL WINAPI SetWindowBand(
     HWND hWnd, 
     HWND hwndInsertAfter, 
     DWORD dwBand);

GetWindowBand

BOOL WINAPI GetWindowBand(
     HWND hWnd, 
     PDWORD pdwBand);

Calling the APIs?

All those functions are private APIs found in user32.dll, so you have to use GetProcAdress to get to them.
But Microsoft implemented some checks to prevent their usage.

GetWindowBand always works.
CreateWindowInBand/Ex only works if you pass ZBID_DEFAULT or ZBID_DESKTOP ZBID_UIACCESS works only with the uiAccess=True-flag set and code-signing.
SetWindowBand will never work.

Calling them anyway...

CreateWindowInBand

To use CreateWindowInBand with any ZBID, you need to inject a .dll into an immersive process (bright blue in ProcessExplorer) and call it from there.

SetWindowInBand

SetWindowBand gets a little more interesting. In order to use that, you have to inject a .dll into explorer.exe and hook SetWindowBand with a trampoline.
As soon as the StartMenu opens, or a new window gets created, the function will be called.
Now you can call the original function twice.
Once with a different HWND and ZBID and then with the original parameters.
A full example of this can be found here

Conclusion

With the introduction of Windows Store apps, Microsoft also introduced the concept of WindowBands, to more offer more granular control over window z-ordering.
Many Bands are available, but they don't allow you to use them explicitly.

With a bit of hacking, however, it's completely possible to freely take advantage of any WindowBand.

And so GloSC/GlosSI (My cobbled together tool for SteamInput) users can enjoy stuff like this:

Credits/Sources: adltax

The ultimate WSL2 setup (updated 2024)

Peter Repukat — Wed, 08 Dec 2021 23:27:13 +0000

This is a crosspost originally from my own blog

Last Update: 10/23/2024

Ever wondered how to seamlessly blend Windows and Linux in your daily workflow?

My friends and colleagues frequently ask about my WSL setup - both for personal projects and professional work.

I used to direct them to an old blog post of mine, but that always required a massive wall of explanatory text, since things have evolved significantly.

So here is my personal "Ultimate WSL2 Setup"

TL;DR

for everyone that doesn't feel like reading my gibberish:

Win 11 (wslg pre-setup)
Windows Terminal
usbipd-win (usb passthrough)
ArchWSL
zsh (with some plugins)
gsudo (sudo for windows)
wsl-hello-sudo (using windows hello/fingerpint with wsl-sudo)
wsl-open (open any file/link with native windows executable)
my dotfiles
Custom Kernel for car-hacking stuff

Setup

Terminal: Your Gateway to Command Line Bliss

Before diving into WSL and shell configurations, let's get you set up with a proper terminal emulator. The landscape has evolved significantly, and your options are much better than they were a few years ago.

The Windows Terminal has matured into a fantastic choice with an impressive feature set. The best part? It's blazing fast! They've even added a sweet quake-mode feature recently, making it a worthy replacement for the old "conhost.exe".

While Windows Terminal has become my daily driver, it does have a few limitations. If you need advanced features like auto-start in hidden-quake mode or separate always-on-top settings for quake-mode and normal-mode instances, ConEmu remains the most feature-rich alternative - just be prepared for slightly slower performance.

Fonts

Next up, let's talk typography. You'll want fonts with extensive glyph support (icons) - I recommend checking out nerd-fonts. While Windows lacks an official all-in-one installer, you can either use your preferred Windows package manager or cherry-pick specific fonts as I did

Windows Sudo: Trust Me, You'll Want This

Here's a game-changer: gsudo, essentially bringing sudo to Windows.

On Windows 11, it's as simple as running winget install gsudo in an elevated PowerShell.

Once installed, you can elevate any Windows process/command with a simple gsudo prefix.

WSL

I've fallen in love with Arch Linux's minimalist approach, which fits perfectly within WSL's ecosystem. While Arch isn't officially supported, several excellent distro launchers make it possible. I've had great success with ArchWSL, which has proven reliable even in professional settings.

For a basic installation, you can refer to their excellent guide here

If you've never used WSL before or start with a fresh Windows install, use Microsoft's guide to install WSL, but install ArchWSL from their GitHub page, instead of any other distro from the Microsoft store.

Systemd

Recent WSL2 versions finally support Systemd, enabling things like docker without the pesky "Docker for Windows"-App.

Although it's not enabled by default...

To activate it, add this to /etc/wsl.conf:

[boot]
systemd=true

File system gotchas

While recent Windows versions provide built-in access to Linux files, some compatibility quirks remain. I prefer mapping WSL files as a network drive using \\wsl.localhost\ - simple and effective.

From the Linux side, you can project file permissions and metadata to NTFS, though it requires configuration.

This enables neat tricks like symlinking your Windows-generated SSH folder, eliminating redundant key and config management.

Here's my battle-tested /etc/wsl.conf configuration:

# Includes enabling Systemd from above
[boot]
systemd=true

# Enable extra metadata options by default
[automount]
enabled = true
root = /mnt/
options = "metadata,rw,umask=22,fmask=11"
mountFsTab = false

# Enable DNS  even though these are turned on by default, we’ll specify here just to be explicit.
[network]
generateHosts = true
generateResolvConf = true

[interop]
enabled=true
appendWindowsPath=true

USB Support: Connecting the Physical World

Another feature that is missing from WSL out of the box is support for USB devices.

However, recently (at time of writing) M$ did put some work into it, and posted about a way to make it happen.

That's great news for anyone who's into Arduino or similar stuff or even car-hacking, as I personally find that that kinda stuff is just easier to set up on Linux than on Windows.

Basically, just install usbipd-win...

winget install --interactive --exact dorssel.usbipd-win

For Arch users, that's all you need!

From any elevated command prompt, you can manage USB devices with usbipd wsl list and usbipd wsl attach --busid XX.

With gsudo, you can run these commands directly from WSL:

cmd.exe /c gsudo usbipd wsl list
cmd.exe /c gsudo usbipd wsl attach --busid 4-4

WSL-Open: Seamless integration

Want to make your WSL experience even smoother?

wsl-open is a must-have tool. It lets you use Linux's standard xdg-open command to open files and links with native Windows applications. Installation is a breeze via npm:

sudo npm install -g wsl-open

But there is also a non-npm installation described on their GitHub page, if you're not into node.

Port Fowards: Reaching the Outside World

While WSL normally forwards network ports to Windows automatically (though it occasionally hiccups 🤷‍♂️), external access remains challenging.

This can be frustrating when you need SSH access or want to quickly share files via a temporary web server.

Here's a PowerShell script that solves this limitation, allowing direct port forwarding to WSL (also available on GitHub):

# WSL2 network port forwarding script v1
#   for enable script, 'Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope CurrentUser' in Powershell,
#   for delete exist rules and ports use 'delete' as parameter, for show ports use 'list' as parameter.
#   written by Daehyuk Ahn, Aug-1-2020

# Display all portproxy information
If ($Args[0] -eq "list") {
    netsh interface portproxy show v4tov4;
    exit;
}

# If elevation needed, start new process
If (-NOT ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))
{
  # Relaunch as an elevated process:
  Start-Process powershell.exe "-File",('"{0}"' -f $MyInvocation.MyCommand.Path),"$Args runas" -Verb RunAs
  exit
}

# You should modify '$Ports' for your applications
$Ports = (667)

# Check WSL ip address
#wsl /bin/sh -c "ip route get 1 | grep 1. | awk '{print \`$3}'" | Set-Variable -Name "WSL"
#wsl hostname -i | Set-Variable -Name "WSL"
$WSL = wsl bash -c "ifconfig eth0 | grep 'inet ' | awk '{print \`$2}'"
echo $WSL
$found = $WSL -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';
if (-not $found) {
  echo "WSL2 cannot be found. Terminate script.";
  exit;
}

# Remove and Create NetFireWallRule
Remove-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock';
if ($Args[0] -ne "delete") {
  New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Outbound -LocalPort $Ports -Action Allow -Protocol TCP;
  New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Inbound -LocalPort $Ports -Action Allow -Protocol TCP;
}

# Add each port into portproxy
$Addr = "0.0.0.0"
Foreach ($Port in $Ports) {
    iex "netsh interface portproxy delete v4tov4 listenaddress=$Addr listenport=$Port | Out-Null";
    if ($Args[0] -ne "delete") {
        iex "netsh interface portproxy add v4tov4 listenaddress=$Addr listenport=$Port connectaddress=$WSL connectport=$Port | Out-Null";
    }
}

# Display all portproxy information
netsh interface portproxy show v4tov4;

# Give user to chance to see above list when relaunched start
If ($Args[0] -eq "runas" -Or $Args[1] -eq "runas") {
  Write-Host -NoNewLine 'Press any key to close! ';
  $null = $Host.UI.RawUI.ReadKey('NoEcho,IncludeKeyDown');
}

Pro tip: Avoid using port 22 for your SSH server, as the native Windows SSH server will intercept these connections.

[Optional] Custom Kernel: For the Power Users

While most users won't need a custom kernel, it's essential for specific use cases like running SocketCAN for car hacking. Here's how to build and install your own kernel:

#get kernel version
uname -r
  5.10.60.1-microsoft-standard-WSL2

# get matching version, this is mine
wget https://github.com/microsoft/WSL2-Linux-Kernel/archive/refs/tags/linux-msft-wsl-5.10.60.1.tar.gz

#extract it (change to your kernel version)
tar -xf linux-msft-wsl-5.10.60.1.tar.gz

# build linux/modules

# change to the folder tar extracted too, yours might be different
cd  WSL2-Linux-Kernel-linux-msft-wsl-5.10.60.1/
cat /proc/config.gz | gunzip > .config
make prepare modules_prepare -j $(expr $(nproc) - 1)

# select your drivers/modules here
make menuconfig -j $(expr $(nproc) - 1)
make modules -j $(expr $(nproc) - 1)
sudo make modules_install
make -j $(expr $(nproc) - 1)
sudo make install

# copy it to windows drive, change <yourwindowsloginname> to your windows users 
cp vmlinux /mnt/c/Users/<yourwindowsloginname>/

#create this file
vim /mnt/c/Users/<yourwindowsloginname>/.wslconfig

#with these contents
[wsl2]
kernel=C:\\Users\\<yourwindowsloginname>\\vmlinux

# exit wsl
wsl.exe --shutdown

Missing something?

Am I missing something?
Let me know!