我有一个复杂而成熟的科学数据处理项目，它由一个纠缠在一起的COM服务器网络组成，主要用VB6编写，只使用很少的UI（没有表单或控件），因为到目前为止大多数普通用户都用它编写了简短的VBA程序。
我们有两个未来目标：
-
通过存在于 Linux 上的 Web 服务组件创建 Web UI。
-
逐步将项目迁移到 D/Python 并远离 Windows 和 VB6。
我们正处于设计消息传递框架的阶段，该框架将作为这两个目标的最佳共同提名者。
这些项目执行繁重的数字处理任务，包括运行自定义R脚本和LaTeX/MS Word/Excel报告。我们需要向广泛的客户公开一些功能，而Web UI似乎是最佳选择。另一方面，随着Windows在我们环境中的使用逐渐下降，我们希望最终将我们的项目移植到Linux上，或者至少保持该选项开放，而不是将自己锁定在Windows特定的技术中。
-
从这个角度来看，自然.基于NET的解决方案是某种东西我们首先要避免的。
-
从VB6的角度来看，DCOM/MSRPC似乎是很自然的，但这项技术是贬值和不安全的。此外，我们希望将项目的Web服务部分保留在Linux上。
-
所以最好的选择是在Linux上编写Web服务部分（使用例如Python或D）。问题仍然存在：如何有效地在VB6和Python（或D）之间进行通信。很明显，这将是某种网络协议。我们需要的是高效且易于使用的协议，它允许在两方之间传递事件和消息。传输的数据量很小，高延迟并不重要。
- DCOM/MSRPC似乎可以进行本地通信，但是在Linux部分真的很容易做到吗？到目前为止，我们对Python的经验很少，在D中也没有支持它。
- 自定义 IP 协议。由于我们的需求很小，这可能只是可行的。但这不是重新发明轮子吗？ 我们
- 喜欢JSON-RPC的想法，作为我们项目的一部分，已经使用了JSON，并且具有Python和VB6的公开客户端。
我想，我们的任务还有更多可行的解决方案。我们将雇用人员提供帮助，但在此之前，我们需要知道有哪些可用的技术以及在哪里（谁）寻求帮助。
首先想到的是序列化协议，如Google Protocol Buffers，Thrift，MessagePack，Avro等。这些非常受欢迎，以至于其中一个必须已经在 VB6 中实现。据我所知，除了 Avro 之外，所有内容都是用 D 实现的，因此根据 VB6 世界中的情况，您可能几乎没有选择。我的建议是选择其中之一并使用它，或者如果有对VB6的REST支持，那么Linux端的VibeD也许可以为您完成这项工作。
以下是我在11月12日至16日期间与Adam D. Ruppe就这个话题进行的私人谈话，经许可粘贴：
Windows XP TLS错误再次袭来...它实际上可能成为一个表演者，取决于你对避免分配的感觉。
我可以破解它，但这意味着 druntime 永远不会加载。如果您使用-version=skip_rt_init进行编译，此处的代码会执行此操作
所以任何调用它的东西都不起作用 - 没有字符串附加，数组调整大小，大部分火卫一都出来了，等等。这更像是写作C比写D。
顺便说一句，问题是Windows XP dll加载程序无法处理本地线程静态变量。这里详细解释：http://www.nynaeve.net/?p=180
如果 dll 加载了 exe，它可以工作，但由于 VB 和 JScript 调用 LoadLibrary已经在运行的过程中，我们遇到了这个问题。
默认情况下，D 使用隐式 TLS。我们可以在自己的代码中避免它，但事实并非如此在运行时很容易。在 D 中分配内存等调用会覆盖父级EXE的内存，导致其不可预测地崩溃。
该问题已在Windows Vista中修复，但这对XP用户没有帮助...
但是，我得到的这段代码或多或少与-version=skip_rt_init一起工作。尽你所能在 com 助手中看到，我跳过了一些箍以避免大多数分配 - 一些druntime和phobos可以工作，只是大部分都不起作用。
好的方面来说，看看dclient.d，chello.d和ihello.d。相当漂亮法典！ dserver.d不再需要，我能够使所有这些都通用。
大多数混乱都在comhelpers.d.顺便说一句，向脚本返回值仍然不是完成，我只是花了一整天的时间与这个线程的东西作斗争。
底线，如果可以避免任何需要初始化 D 运行时的内容，或者可以使用Win Vista +，这会很漂亮。否则，tls 错误可能是为您表演。
这是指向zip文件的链接
http://arsdnet.net/dcode/com.zip
检查我使用的命令行的build.txt文件;我不使用Visual D，但它不能有比这更不同的了。
由于该错误，此解决方案在Win XP上并不完美，但可能运行良好供您使用。
Adam Ryczkowski写道： 这是一个非常可怕的消息。我直觉地认为，既然D允许 C/C++的许多低级黑客功能，都可以制作 与任何平台上的COM兼容...
是的，问题是TLS的事情。你可以让它工作，但是由于 druntime 使用默认线程本地存储，因此会出现问题。
A.R.： 有没有简单的方法来判断火卫一和druns的哪个部分 除了检查内存分配的来源之外，还会起作用吗？
我不这么认为。对线程局部变量的任何访问（主要是模块级别）未标记为共享或共享的全局）可能是一个问题。
A.R.： 离开处理器服务器怎么样？应该没有太大问题 内存了，以牺牲执行速度为代价，但我可能会活下去 有了这个。
好主意。我不知道如何做一个进程外的服务器，但是它不能有太大的不同，做自己的 exe 可以避免麻烦。
我可能再也没有机会自己玩这个了不过天。
A.R.： 非常感谢您的解决方案。如果我发布 你给我的信息进入了StackExchange？我想给它尽可能多的 尽我所能旋转。
继续，我转移到电子邮件，因为堆栈溢出不利于扩展谈话，但请随时在此处发布任何内容。
编辑：Adam D. Ruppe刚才给我发了另一封电子邮件：
我只是偶然发现了一些可能有助于解决Windows XP问题的东西：模块核心.sys.Windows.dll有一个功能：
if( !dll_fixTLS( hInstance, tlsstart, tlsend, tls_callbacks_a ....
从这里使用它：
http://dlang.org/dll.html
在dll_process_attach函数中。这可能也适用于我们的问题。我现在正在做其他事情，但如果你的话，我可以稍后尝试不要先做。