Coloring not working on Windows

[HipyCas]

Describe the bug
On v0.4.2, in a Windows 10 machine, printing and listing works perfectly, but it does not get the colors out, instead, it shows �[0m at the end of each item. When switching to the WSL, the color show properly. Therefore, it is to conclude that the Windows DOS shell does not understand the Unix colour codes.
During the edition of the screenshots, I realized that in some files, at the beginning appeared �[1m�[38;2;176;114;25mA in a couple of files.

To Reproduce
Steps to reproduce the erroneous behaviour on Windows:

1. Get on a Windows 10 Command Prompt
2. Execute the .exe file (in my case, executed directly from the downloads folder)
3. It takes long to start and to print each (with --no-color everything goes faster), but you will see that with the first element, it shows �[0m at the end of it.

Steps to reproduce proper behaviour on WSL (Debian):

1. Start up the WSL (Debian in my case) in a Windows 10 Command Prompt
2. Execute the downloaded binary for the Linux platform
3. Takes less to start, and the characters shown in Windows do not appear, while color does.

Expected behaviour
As it is intended to do, and as it does on the WSL, it should colourize the items properly.

Screenshots
Screenshot of the first execution on Windows:

Screenshot of execution with the --no-color flag on Windows:

Screenshot of execution in Debian WSL (sh shorthand for debian run):

[The-Noah]

Can you run colortool -c and send a screenshot of the output?

If you don't have ColorTool downloaded, you can get it here.

[HipyCas]

Here goes the screenshot:

[The-Noah]

That's very strange. I was thinking colortool would output strange characters as well but it's working fine.

I'm going to assign this to @MattPlays since he wrote a lot of the color code.

[MattPlays]

I took a stab at it and came up with absolutely nothing, it works for @The-Noah but not for me or you @HipyCas which is the confusing part.

[HipyCas]

Maybe it is due to some configuration on the Windows prompt? @The-Noah have you applied any configuration to the prompt or console?

[The-Noah]

I have no clue if I've configured cmd.

[MattPlays]

Maybe it is due to some configuration on the Windows prompt? @The-Noah have you applied any configuration to the prompt or console?

It is, Some versions of Windows don't have ENABLE_VIRTUAL_TERMINAL_PROCESSING on by default. The only way to enable it is through Regedit
[HKEY_LOCAL_USER\Console]
"VirtualTerminalLevel"=dword:00000001
or by calling the Window's API directly which as far as i could look is not currently support in Rust without using crates(Which we want to stay far away from)

[The-Noah]

The only way to enable it is through Regedit

[HKEY_LOCAL_USER\Console]
"VirtualTerminalLevel"=dword:00000001

I found that VirtualTerminalLevel was set to 1 and changing it to 0 breaks it, just like how y'all's is.

or by calling the Window's API directly which as far as i could look is not currently support in Rust without using crates(Which we want to stay far away from)

I think we can use an extern function to directly call the Win32 API.

[The-Noah]

This has been fixed in dbbe3e0. Thank you both for your help!