Delphi DLL(在XE中)必须处理TStringList(D2007，Ansi)

Question

DLL最初是在D2007中编写的，需要一个快速、恐慌的TStringList调用（是的，这是"我肯定会后悔"的调用之一；尽管由几个模块对DLL进行的所有调用都是由Delphi代码进行的，当XE出现时，我错误地认为/希望向后兼容）。

因此，现在我要将DLL移到XE5（以及Unicode），并且必须维护兼容性调用。最糟糕的情况是，我只是为XE编写了一个新的DLL，同时保留了旧的DLL用于遗留，但我觉得XE没有理由不能解构/重写｛ANSI｝TStringList参数。但我的Delphi幕后知识并不丰富，几次尝试都没有成功。

这是DLL调用——它接受一个文件路径列表，在这个精简的代码中，只需将每个字符串添加到一个内部列表中（这就是DLL对参数所做的所有操作，一个只读引用）：

function ViewFileList ( lstPaths: TStringList): Integer; Export; Stdcall;
begin
      for iCount := 0 to lstPaths.Count - 1 do
         lstInternal.Add(lstPaths.strings[iCount]);
end;

我发现，当我在XE5中编译它时，lstPaths.Count是正确的，所以基本结构是对齐的。但是这些字符串是垃圾。这种不匹配似乎有两个方面：（a）字符串内容自然被解释为每个字符两个字节；（b） 没有元素大小（在位置-10）和代码页（在位置-12；所以是的，是垃圾字符串）。我也隐约知道幕后的内存管理，尽管我只做只读访问。但是实际的字符串指针本身应该是正确的（？？），因此有没有办法强迫我通过？

那么，不管我是否有这种权利，有什么解决方案吗？提前谢谢。

Answer 1

您可能还没有意识到您的代码总是错误的。通常，不支持跨模块边界传递Delphi对象。只要你很好地理解实现，只要你不调用虚拟方法，只要你没有进行内存分配，只要你在两边都使用相同的编译器，可能还有很多其他原因，你就可以让它工作。要么使用运行时包（双方也需要相同的编译器），要么使用互操作安全类型（整数、浮点、以null结尾的字符数组、指针、记录和互操作安全型的数组等）

这里真的没有简单的解决方案。它本来就不应该起作用，如果真的起作用了，那你就太倒霉了。不幸的是，一个更好的结果是一个失败，它会让你做得很好。

也许你能做的最好的事情就是制作一个适配器DLL。体系结构是这样的，从下到上：

• 原始的Delphi 2007 DLL在底部，带有需要提供D2007字符串列表的伪导出
• 新的适配器Delphi 2007 DLL在中间。它调用伪导出，并能够提供D2007字符串列表。适配器DLL公开了一个正确的接口，该接口不需要跨模块边界传递Delphi对象
• 顶部的新XE5可执行文件。这与适配器进行对话，但使用有效的互操作类型进行对话

Answer 2

David和Jerry已经告诉您应该做什么-重写DLL以使在跨模块边界传递互操作安全数据时做正确的事情。然而，要回答您的实际问题：

实际的字符串指针本身应该是正确的（？？），因此有没有办法强迫我通过？

那么，不管我是否有这种权利，有什么解决方案吗？

您可以尝试以下操作。这是危险的，但应该工作，如果此时不能选择重写：

// the ASSUMPTION here is that the caller has been compiled in D2007 or earlier,
// and thus is passing an AnsiString-based TStringList object.  When this DLL is
// compiled in Delphi 2009 or later, TStringList is UnicodeString-based instead,
// so we have to re-interpret the data a little.
//
// The basic structure of TStringList itself should be the same, just the string
// content is different.  For backwards compatibility, the refcnt and length
// fields of the StrRec record found in every AnsiString/UnicodeString payload
// are still at the same offsets. Delphi 2009 added some new fields, but we can
// ignore those here.
//
// Of course, XE is the version that removed the RTL support code for the {$STRINGCHECKS}
// compiler directive, which handled all of these details in Delphi 2009 and 2010
// when users were first migrating to Unicode.  But in XE, we'll have to deal with
// it manually.
//
// These assumptions may change in future versions, but lets deal with that if/when
// the time comes...
function ViewFileList ( lstPaths: TStringList): Integer; Export; Stdcall;
{$IFDEF UNICODE}
var
  tmp: AnsiString;
{$ENDIF}
begin
  for iCount := 0 to lstPaths.Count - 1 do
  begin
    {$IFDEF UNICODE}
    // the DLL is being compiled in Delphi 2009 or later...
    //
    // the Length(String) function simply returns the value of the string's
    // StrRec.length field, which fortunately is in the same location in
    // both pre-2009 AnsiString and 2009+ AnsiString/UnicodeString, and in
    // this case will reflect the number of AnsiChar elements in the source
    // AnsiString.  We cannot simply typecast a "UnicodeString" directly to
    // a PAnsiChar, nor can we typecast a PWideChar to a PAnsiChar, but we
    // can typecast a string to a Pointer first and then cast that to a
    // PAnsiChar.  This code is assuming that it can safely get a pointer to
    // the source AnsiString's underlying character data to make a local
    // copy of it that can then be added to the internal list normally.
    //
    // Where this MIGHT fail is if the source AnsiString contains a reference
    // to a string literal (StrRec.refcnt=-1) for its character data, in
    // which case the RTL will try to copy the character data when assigning
    // the source string to a variable, such as the one the compiler is
    // likely to generate for itself to receive the TStringList.Strings[]
    // property value before it can be casted to a Pointer.  If that happens,
    // this is likely to crash when the RTL tries to copy too many bytes from
    // the source AnsiString!  You can use the StringRefCount() function to
    // detect that condition and do something else, if needed.
    //
    // But, if the source AnsiString is a normal allocated string (the usual
    // case), then this should work OK.  Even with the compiler-generated
    // variable in play, the compiler should simply bump the reference count
    // of the source AnsiString, without affecting the underlying character
    // data, just long enough for this code to copy the data and release the
    // reference count...
    //
    SetString(tmp, PAnsiChar(Pointer(lstPaths.strings[iCount])), Length(lstPaths.strings[iCount]) * SizeOf(AnsiChar));
    lstInternal.Add(tmp);
    {$ELSE}
    // the DLL is being compiled in Delphi 2007 or earlier, so just add the
    // source AnsiString as-is and let the RTL do its work normally...
    //
    lstInternal.Add(lstPaths.strings[iCount]);
    {$ENDIF}
  end;
end;