Done Optional ANSI(32|64).dll for Win 10 >= Creators Update

[Alpengreis]

Some have really problems with the Win 10 Creators Update and ANSI support ("already" in pure Win Console). For me, If I use the Win 10 built-in support (with disabled ANSI in TCC/TCMD) I have much problems with display in TCMD (additionally spaces in desired font (-size) or something like that).

Please add an option to using ANSI32.dll respective ANSI64.dll for Win 10 Creators Update or later too (as is possible in System before Win 10 Creators Update, for ex. in Win 7).

Then it would be possible to switch to Win Legacy Console Prompt without losing ANSI support within TCMD/TCC ...

Greetings

 

[forbin]

My laptop just finished updating to "Crater" edition a couple of days ago, and it is now interfering with my fancy prompt and some of my "dressier" batch files.

Rex, please do add a switch that causes TCmd / TCC to stop using the new built-in Windows ANSI support, and override it with the custom JPSoft ANSI.

 

[forbin]

PS: as I mentioned on another thread, I've found a workaround, at least for pre-v21 versions of TakeCommand.
This reduces the urgency of the requested feature. I still think it would be a good feature to have, because the user might not want to disable ALL of Windows 10's ANSI support, which happens with the workaround.

The workaround is to run RegEdit and set the "ForceV2" value (a REG_DWORD) to zero (0) in HKEY_CURRENT_USER\Console.
A reboot is required to see the change reliably. After that, Windows 10 ANSI support is disabled, and if you enable /ANSI in TCmd or TCC, it uses the built-in support. (Versions before 21; someone needs to test this with the current version.)

 

[Charles G]

if %_winver GE 10 echo Setting value was @iff[@regset[HKCU\Console\ForceV2,REG_DWORD,0] eq 0,, not] successful.

would work - assuming that TCMD would return 10+ for windows 10. the CHM doesn't list the results for various windows versions.....

 

[forbin]

Here is the list from Microsoft regarding the internal version numbers:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724832(v=vs.85).aspx​

Notice, however, what they said about manifests, which has to do with how an application is built. I would assume that later versions of TakeCommand are manifested for Windows 10 [Rex, please correct me if I'm wrong there!], but earlier versions would not have been. For example, TakeCommand 17 running on my laptop on Win 10 Home reports:

_WINVER = 6.3
_OSBUILD = 15063​

(i.e. v6.3.15063, so it thinks it's running on Windows 8.1)

* * *

If you do a lot of online research (or have a lot of old machines with various builds on them), you should be able to work around this by using the build number. Build numbers in Windows are always ascending numerically. Here's a minimal starting point: the first public release build # of Win XP was 2600, Vista was 6000, Win7 was 7600, Win8 was 9200, Win8.1 was 9600 (I think), It looks like Win9/10 previews were in the high 9800's and 9900's, and Win10 release builds seem to all be upwards of 14000.

* * *

It gets worse...

It turns out, if you work in a corporate environment where many people might be running an older mission critical application (either built internally or else no longer supported), Microsoft may have supplied your sysadmins with special patch programs that enable Windows to lie about it's version number and build number! I didn't read all the details, so I'm not sure if this is using the same mechanism as "Compatibility Mode" or not. (i.e. the patch could be forcing everything in 32-bit-land to run in compatibility mode... or it could be doing something entirely different that would still keep legacy programs happily running. Who knows?)

 

[rconn]

Already done in 21.01.