你使用DLL是走上了正确道路。听起来，真正的难点将在于决定你想要使用什么类型的进程间通信（IPC）。选项有：套接字，管道，共享内存，同步对象（事件等），文件，注册表等。

一旦你决定了，那么就在你的可执行文件中实现一个监听器，以等待来自使用你的 DLL 的任何软件的传入 IPC 消息。

就 API 而言，您可以像您所期望的那样保持简单。让 DLL 暴露您的 4 或 5 个功能（确保只使用本地数据类型，如 char* 和 long，以避免模块边界问题），然后这些功能将使用您的 IPC 机制与正在执行的应用程序进行通信。

像这样简单的事情有一个随着时间增长的习惯，因此您最好提前多做一些工作，并使用一种能与您一起成长的技术。

实现一个COM接口到你的程序中会让客户在如何与它互动方面获得很多自由度，而你也不必担心IPC等机制的问题，因为COM被设计成可以将这些都隐藏起来。

在未来，如果您需要的话，COM已经有了对于诸如事件之类的事物有很好的定义，这些定义在脚本语言中得到了很好的支持。

更新：有许多实现COM的方法。您可以从好的COM书籍指导下进行首要构建，也可以使用像ATL这样的框架来节省一些模板代码。有很多好的示例，例如请参见MSDN。

COM的最大优点是不需要DLL！您说您的应用程序始终在运行。这意味着它可以充当COM对象的创建者（“本地服务器”）。

如果有人想要一个"stdcall" DLL，您可以给他们一个把所有调用转发到COM接口的DLL。编写它非常简单。您只有5个函数，是吗？这表明您有一个COM接口，其中有这5种方法。当包装DLL加载时，它会要求您的EXE创建其COM对象。然后DLL公开5个stdcall方法，每个方法调用COM对象中的一个方法。

你可以使用 DLL。我会考虑一下。但我也会考虑编写一个简单的基于 HTTP 的 API，最好是 RESTful。

优势：易于移植。可以很容易地从任何语言编写客户端应用程序。可以在网络上工作。测试变得更加容易（使用脚本语言或浏览器）。

缺点：性能会变慢。在C++中建立它需要更多的管路。我不确定LabView是否可以进行http调用。

某种程度上：

http://xxx/data【GET，也许可以用POST进行测试】

将此翻译为中文：http://xxx/data/start [POST] http：// xxx / data / start [POST]

http://xxx/data/stop [POST] 的中文翻译是：提交（POST）至http://xxx/data/stop。

http://xxx/data/parameters [POST] 的翻译为：将此翻译为中文： http://xxx/data/parameters [POST]

根据您的要求，这可能有些过头，但也可能不是。我所做的许多应用程序都必须进行移植，如果我们能够使用更快的开发语言进行测试和扩展，这将会更快。

LabVIEW支持进行DLL调用，但这是LabVIEW开发中较为薄弱的部分。如果不正确地完成，这可能导致应用程序更容易崩溃。作为一个LabVIEW开发者，我喜欢MattyT的建议，即创建一个HTTP服务。每个平台上的每种语言都可以访问可以进行TCP/IP端口访问的HTTP服务。我认为你可以使用自己的自定义TCP/IP协议，而不是完全的HTTP，但无论哪种方式，兼容性问题都得到了解决。

如果您使用DLL，请遵循以下几点建议。不要在函数调用参数列表中使用结构体或结构体指针。不要在DLL中分配内存以传递回LabVIEW。LabVIEW具有内置的内存管理，与其他语言（如Java）不兼容。如果LabVIEW分配内存并将指针传递给DLL，则其效果更好。尽可能避免使用指针，数组和字符串。LabVIEW可以将它们传递给DLL，但这是一个高级话题，最好是LabVIEW开发人员也懂得C语言，但这并非总是如此。

这里有一个相关的问题。我不想最终得到一个只能在LabView中使用的东西，而且似乎LabView可以访问使用stdcall的dll。这样的dll也可以从VB或其他Windows软件中调用，这就是我想要的。

我不确定它是否能够访问COM接口，但希望获得更多关于这在我的应用程序中看起来像什么的详细信息。