主要问题似乎在于，不可能仅在使用标准C库且没有平台相关或第三方扩展的Windows上使用Unicode。您提到的语言源自Unix平台，该平台的Unicode实现方法与C很好地融合在一起（它们使用普通的char*字符串，C语言环境功能和UTF-8）。如果要在C语言中执行Unicode，则或多或少必须编写两次所有内容：一次使用非标准的Microsoft扩展，一次使用所有其他操作系统的标准C
API函数。尽管可以做到这一点，但它通常没有很高的优先级，因为它很麻烦，而且大多数脚本语言开发人员还是讨厌或忽略Windows。

从更高的技术层面来看，我认为大多数标准库设计人员所做的基本假设是，所有I /
O流本质上都基于操作系统级别的字节，这适用于所有操作系统上的文件以及Unix上的所有流。类系统，唯一例外是Windows控制台。因此，如果要合并Windows控制台I
/ O，则必须在很大程度上修改许多类库和编程语言标准的体系结构。

另一个比较主观的观点是，微软只是不足以促进Unicode的使用。第一个具有不错的（当时）的Unicode支持的Windows操作系统是Windows NT
3.1，该版本于1993年发布，远远早于Linux和OS
X增强了对Unicode的支持。尽管如此，在这些操作系统中向Unicode的过渡更加无缝和毫无问题。微软再次听取了销售人员的意见，而不是工程师的意见，直到2001年，技术上已经过时的Windows
9x一直保留到现在。他们并没有强迫开发人员使用干净的Unicode接口，而是提供了已损坏的，现在不需要的8位API接口，并邀请程序员使用它（请参阅有关Stack
Overflow的一些近期Windows API问题，大多数新手 仍然 使用可怕的旧版API！）。

Unicode发行时，许多人意识到它是有用的。Unicode开始时是纯16位编码，因此使用16位代码单元是很自然的。微软然后显然说：“好，我们有16位编码，所以我们必须创建16位API”，但没有意识到没有人会使用它。但是，Unix专家认为：“我们如何以一种高效且向后兼容的方式将其集成到当前系统中，以便人们真正使用它？”
随后发明了UTF-8，这是一项出色的工程。就像创建Unix时一样，Unix人们认为更多，需要更长的时间，财务上的成功较少，但最终做到了。

我无法评论Perl（但我认为Perl社区中的Windows仇恨者多于Python社区），但是关于Python，我知道BDFL（也不太喜欢Windows）已经声明了足够的Unicode支持在所有平台上都是一个主要目标。