greenn

With the current model kernel level access is required. Real security products have to be able to operate above userland. Ideally in the future there can be a layer in between userland and kernel for this sort of thing. Maybe we use some of those extra protection rings?

Oh you're totally right about the driver APIs. A fair amount has been added, but that stuff gets a new export to avoid breaking anything. For example, there's a dozen different `ExAllocate`s now. I wouldn't call myself a driver-writing expert but I'm sure that same driver for Vista could be made to target Windows 10 with little effort.

I'm talking about the kernel space itself, not the APIs exposed to userland to interface with the kernel from your application. Internal APIs and behaviors are mostly identical over the past ~20 years, and any changes are usually moved to a new export. I don't think this should be taken for granted.

A fair amount has been changed or added, I'd say. I recommend the Windows Internals book if you're interested in learning about the Windows kernel. The 7th edition just came out.

Until I started working at a SaaS company shipping to Windows enterprise customers I thought PowerShell wasn't used by anyone. Now I see it all the time. It's not fantastic, but if you're in the Windows world it beats writing CMD scripts.

As an end user though I imagine most people use bash or some other unix-world shell, especially post WSL. The "Git Bash" distribution is surprisingly useful as an everyday Windows shell.

I haven't profiled our Windows kernel driver across different kernel versions (maybe I should!) but I'd like to offer this perspective: the kernel is incredibly stable from my driver development point of view. The biggest reason we ship different drivers for Windows 7/8/10 is just that newer WDKs don't support anything older than 10. The kernel has remained remarkably consistent while still offering new features we can take advantage of on non-legacy systems.

I'm not sure emacs modes offer this level of extensibility, but I'll check them out.

As a baseline solution "language" could be substituted for "unicode range".

Re "use a better font": fonts are something I enjoy and I try new ones frequently.

Alignment could definitely be a challenge. Perhaps a better personal solution would be to write something to combine two fonts in a way that also solves alignment. Not a very "accessible" solution but definitely easier.

This is applying a font for an entire window/frame/buffer, right? Not applying two fonts for different characters within the same buffer.

Linux desktop users specifically don't have to worry about malware or ransomware until it gets significant usage. Just like people used to say Macs don't get viruses until enough people used them.

Last time I checked (could be very out of date) Linux doesn't have any way to enforce code signing requirements, even in the kernel.

The difference might be that workers have an interest in maintaining the business so they still have well paid jobs while CEOs do not necessarily have an interest in unions' well-being.