Improve Windows Logo Detection

[lzlrd]

This also adds support for (the upcoming) Windows 11.

[lzlrd]

The force-pushes were to add Windows 8/8.1 support, alongside fixing the edgecase of a possible "Windows 110" being recognised as "Windows 11".

[lzlrd]

Here's an example of how the Windows 11 ASCII art looks:

[rashil2000]

I was starting to think our logo detection logic might be getting a little stale after the recent leaks xD

The switchlogo parameter is now useless, so it needs to be removed completely (it's still present in your PR).

Also, a more robust way of detecting Windows major version names would be through build numbers - it allows more flexibility and less hard-coded comparisons. So I don't think we should be comparing strings for that. What do you think @jcwillox?

I was about to add Windows 11 logo myself, but it is still not confirmed what build numbers they'll start with (rumor is 22000).

[lzlrd]

I was starting to think our logo detection logic might be getting a little stale after the recent leaks xD

The switchlogo parameter is now useless, so it needs to be removed completely (it's still present in your PR).

Also, a more robust way of detecting Windows major version names would be through build numbers - it allows more flexibility and less hard-coded comparisons. So I don't think we should be comparing strings for that. What do you think @jcwillox?

I was about to add Windows 11 logo myself, but it is still not confirmed what build numbers they'll start with (rumor is 22000).

I've removed the switchlogo parameter in a follow-up commit (as shown above).

With regards to using build numbers, we'd then have to keep track (via an array or dictionary) the list of minimum build numbers for each version of Windows (therefore still hard-coding) as opposed to just matching the version string. It isn't much different functionally, but is cleaner to utilise version string matching. At the end of the day, there are less Windows versions than Winodws builds.

An alternative may be to use the kernel version, however the problem with that is that both the "leaked" Windows 11 build and the first set of Windows 10 builds all used kernel versions of their predecessor and, as such, would be detected incorrectly.

[jcwillox]

Haha, might be a little early to be adding Windows 11 support but I'm all for it XD.

I have to agree while build number would seem to be the better method of detection, but matching the version string is probably going to be the easiest and most reliable. Plus any performance difference shouldn't be noticeable.

As for the -switchlogo parameter, we should create a new -logo parameter to set the logo e.g. -logo "Windows 11".

[lzlrd]

Haha, might be a little early to be adding Windows 11 support but I'm all for it XD.

I have to agree while build number would seem to be the better method of detection, but matching the version string is probably going to be the easiest and most reliable. Plus any performance difference shouldn't be noticeable.

As for the -switchlogo parameter, we should create a new -logo parameter to set the logo e.g. -logo "Windows 11".

I've added the logo paramater you requested and corrected the previous commits so that they aren't broken if ever ungrouped (hence the force-pushes). Hopefully this meets your criteria.

[jcwillox]

Looks pretty good to me

[rashil2000]

Great! Thanks for the contribution @lazerl0rd !