 I know this isn't how I usually wind up starting videos on Windows, but I want to show something off since there are a lot of people who make some claims about the Windows console host that isn't quite accurate. The common thing to wind up hearing is that it does not support Unicode properly. Well, that's embarrassing. Oh my god. There we go, though. If you didn't realize this, that's Cyrillic, specifically Privyat or Hai in Russian. This would be in the Angolan futrak, but let's face it, most fonts don't have the runes in them, but this printed out correctly and not as Mojibache, so this is good. I'm not going to need this anymore because I'm going to explain how this actually works and, very importantly, that this works in Aida, sort of. You'll see what I mean in a bit. Actually I can run it in here as well, oh I already did, forgot it saves that. But yeah, you can see, running inside of something that actually supports font substitution, you can see something like that, hello, just really old, old, old, Angolan stuff. I did this because this is not, this is like way outside of the typical range that thing supports. If it would print this correctly, then I'm golden. Basically I've extended the console interface to do some stuff that Windows needs to do when directly outputting to the console, and I'll explain a little bit. Because the interface I had already implemented, like if we go into here, because it's so much similar to just the normal file IO, it made sense to implement the little back end stuff as just a specific Windows package. The spec, this is one reason I really like that Aida has different specs and bodies. The spec can be shared between the two, and then just a different body is implemented for the relevant system. Now I kept the old one under just sort of like Unix, because it should work without modification on any of the Unix systems and Linux. This is just specifically for Windows. But the spec, the interface, the thing that you bind to is exactly the same regardless. So this winds up being portable between the two. How this actually works, right now a lot of these are just stubs until I figure out exactly how to do it. There's some initialization that actually needs to be done that people aren't aware of. Now, if you're a C or C++ programmer, you should actually recognize all of this. Maybe you'll recognize a few of the functions and macros and stuff, just not some of it's rather Windows specific. See, on Unix systems, you don't really need to worry about this. Basically everything is just UTF-8 anyways. As long as you're working with UTF-8, you're golden. Windows largely because of its market share and some other things winds up having to accommodate for a lot, including a lot of old legacy code. So you still see code pages exist in Windows. They just also implemented UTF-8 and UTF-16 and UTF-32 as code pages. It's kind of ridiculous. Unfortunately, I agree from a business standpoint why they do it. It's horribly complicated from a technological one, but anyways, take advantage of a package initializer. So these are automatically run the moment the package is initialized. Nobody needs to call these. These are just done when the program is loaded and this package is initialized behind the scenes. You don't need to do any setup. It just works, which is always really nice. The other thing that's done, where does it start? Where's the first put? Oh yeah, here. The character is converted. It's the other important thing. And then just called, actually placed there through the standard F put WC in the Windows, what is it, the CRT, CRL, the C runtime library. I use so many NAT-specific features anyways that I'm not really worried about using the inMREP attribute, which is NAT-specific anyways, because so many of the packages here are not going to build on any of the other compilers anyways. It's like, I'm already in deep. Let's just keep using the NAT-specific stuff, but this little thing basically just winds up converting the character to just the code point for use with F put WC. And yeah, the rest of the behavior is synthesized on top of this, but that's basically it. Now that the Windows console host actually supports some of the escape sequences, it would be possible to do some of the things like, you can see down here, the cursor stuff is completely stubbed out. It would be possible to implement at least the move cursors. I'm not sure about save and restore. And it would be possible to implement a foreground, at least for the standard 16 colors. I'm not sure exactly how much console host supports yet. And I'm not sure what modifiers they've implemented either, but yeah, it's rather funny because this is something that a lot of developers had said is actually a deficiency within the Windows console host, and you could clearly see the text is written out properly. It should actually, yeah, it's clearly UTF-8 going out. What am I looking for? You could further confirm this by the wide character encoding UTF-8 flag that's set there. That's scattered through all of my stuff. The whole thing is just entirely UTF-8, the whole way through, and it works. Like you can see I'm not changing the code pages and then any trickery like that. This whole thing is just ordinary UTF-8 like you would want to see anywhere else, and it just works. It's not that the Windows console host was deficient, it's that people were going at it, expecting it to behave the standard in, standard out, and standard error as if they were files like they are in Unix, but they're not. They still haven't been lent the stream as they have to, but they're an object in Windows that has some stuff that needs to be set up, makes it a bit more powerful but also really awkward to use, and unfortunately it's not documented as well as it should be. If you've ever tried to interact with a console using the standard Text.io facilities, you would have noticed Mojibake or other issues like I know there's an exception that can be raised through certain combinations and it won't print out anything at all. They blame that on the console host, obviously it is not the console host that is the problem. I basically wound up discovering all of this trying to solve the issue because I had quite a bit of experience with C sharp and never wound up into it with issues like I was running into with IDA and UTF, or any Unicode text. I was adamant it was a problem with NAT, that the deficiency was in NAT, and through this whole process I actually found it. I'm going to be filing a bug report and see where we go from there. Knowing the way the GCC development process is, it's probably going to be blamed again on the Windows console host, so then I'll implement a patch and see if they accept that, but just knowing them, even despite this proof right here that it's not the console host's fault, it's unfortunately probably going to be blaming the console host. Throughout this whole process I've already filed five bug reports related to this, and they all just get say, nope it's the console host that don't know what they're doing. Clearly it's fine. If you're doing normal file stuff on Windows, you don't need to worry about it. The Text.io stuff is going to work fine. This was implemented specifically in the console package just because it deals with setup of console host. That's it. You really only need to use this for interacting with the command proper PowerShell under Windows. Hopefully this serves as a reference for anybody who's trying to implement this kind of stuff properly in other languages as well.