为什么MAC和Window版本之间存在Silverlight实现中的以下差异

Question

我正在阅读Windows的Silverlight实现与MAC实现之间的差异列表.哪个可以在这里找到.

虽然一些差异显然与平台差异等有关.有些我只是想知道为什么它们会有所不同.如果有人对此有一些想法或实际的具体信息,我很想听听你的意见.

以下是一些看似奇怪的事情,特别是我列表中的最后一点,这实际上是促使我发布这个问题.

1. Char.ToLower(Char,CultureInfo) - 在MAC上使用当前的文化而不是指定的文化.很奇怪,因为MAC可能支持多种文化(我没有MAC或者对它了解很多,所以这是我的假设)
2. Decimal/Single/UInt16/UInt32/UInt64 - 该文档声明不支持所提到的类型,操作系统不支持它们,因此它们被"模拟"(我使用术语'模拟'松散,因为底层CPU肯定支持他们当然不包括十进制).
3. 双/单*无限属性 - 为什么这些属性在不同平台上返回不同的字符串.现在我并不是说人们应该使用字符串表示进行比较,这将是愚蠢的,但为什么要使它们不同,是不是只是在寻找不需要存在的可移植性问题？或者这更像是一个特定于平台的用户体验问题,MAC用户希望看到无穷大符号而不是单词？
4. CultureInfo构造函数 - 在Windows上,如果将无效的区域性字符串传递给构造函数,则抛出ArgumentException,在MAC上,CultureInfo将初始化为当前区域性,并且不会引发异常.

现在,鉴于您的代码是根据通常理解的最佳实践编写的,因此这些都不是严重的差异.但是,我想知道为什么我认为可能不正确的事情是行为合同的一部分,虽然在.NET中不明确,就像我将无效的文化字符串传递给构造函数时所期望的那样,并不能提供一致的行为平台,这似乎是相当随意的,只是在没有充分理由的情况下寻找可移植性问题,或者在那里？