IT工程師數位筆記本

最近一直被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上運行時，奇跡竟然出現了——運行正常，并且得到了正確的結果。

這時你也許又要問——不是自找麻煩嗎，為什么不一開始就用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要小心！