困扰多日的C#调用Haskell问题竟然是Windows的一个坑_.NET_编程开发_程序员俱乐部

最近一直被C#调用Haskell时的“尝试读取或写入受保护的内存”问题所困扰（详见C#调用haskell遭遇Attempted to read or write protected memory，C#调用haskell时的“尝试读取或写入受保护的内存”问题），而且困在其中，越陷超深，无法自拔，差点弃用C#解决我们面临的问题。

问题是这样的，只要在Haskell代码中对字符串进行操作，在C#调用时就会引发异常：

An unhandled exception of type 'System.AccessViolationException' occurred in Unknown Module.

Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

示例Haskell代码如下：

如果直接返回字符串，则一切正常，示例Haskell代码如下：

C#调用示例代码：

class Native
{
    [DllImport("libpandoc", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Unicode)]
    public static extern IntPtr markdownToHtml(byte[] markdown);
}

public class Processor 
{
    public string Process(string text)
    {
        var intPtr = Native.markdownToHtml(System.Text.Encoding.UTF8.GetBytes(text));
        var html =  Marshal.PtrToStringAnsi(intPtr);
        return html;
    } 
}

你也许会问——吃饱撑着了，为什么要用C#调用Haskell？

没撑着！因为史上最强大的Markdown引擎pandoc就是用Haskell开发的，不是C#，不是Java，不是PHP，不是Python，也不是C/C++，更不是Objective-C。真正要比的不是语言，而且是用语言开发出来的东西。

你也许要问——很多人看不起的微软家的C#能调用高上大的Haskell？

当然能！而且经过了实际验证，详见经过实际验证的C#调用Haskell的方法。虽然是通过FFI(ForeignFunctionInterface)，借助C编译成非托管的dll，但不管怎么样，C#做到了。

但当我们用C#调用Haskell解决实际问题时，遭遇了“Attempted to read or write protected memory. ”问题，反复折腾找不到解决之道，处于绝望中，以为“C#可以调用Hakell"是一个“骗局”。

。。。

今天上午，当我们把编译好的程序从Windows Server 2008 R2复制到Windows Server 2012上运行时，奇迹竟然出现了——运行正常，并且得到了正确的结果。

解析成功" width="480" height="19" />

这时你也许又要问——不是自找麻烦吗，为什么不一开始就用Windows Server 2012？

不是自找麻烦，是麻烦自己找上门的。因为编译Haskell代码需要安装Haskell Platform（集成了ghc），而Haskell Platform不能在Windows Server 2012正常安装，只能被迫在Windows Server 2008上安装（当时也被折腾了）。

万万没有想到的是，Windows Server 2008上编译出来的程序不能在Windows Server 2008上正常运行，却奇迹般地能在Windows Server 2012上能正常运行。这是不是Windows的一个坑呢？

由此想到我们在阿里云上曾经遭遇的“黑色10秒”问题，是因为Windows Server 2008在WAS（Windows Process Activation Service）中使用了spinlock，而虚拟化技术对spinlock支持不好，最终也是通过换用Windows Server 2012解决了问题。这虽然不能说是Windows Server 2008的一个坑，但说明了一点——使用Windows Server，2008要小心！