对WinAPI有良好体验的人可以使用行为如下的应用程序指导我正确的方向：
用户启动应用程序（带入口点winmain的win32）。应用程序连接到数据库，选择数据，进行一些内部计算，如果一切正常，则启动一个新的应用程序并退出。阻止，可能是长时间的行动，但服务就像成功，没有GUI。
如果出现问题（连接字符串错误，数据无效等），应用程序会创建一个包含多个控件的窗口，并允许用户修复所需的内容。
如果连接字符串和数据有效，但无法启动应用程序，则不会显示上一个窗口，而是使用其他控件创建另一个窗口，用户必须先执行其他操作才能继续。
那么，处理这些要求的最简洁方法是什么。
到目前为止，我可以想象以下方法：
1）创建一个消息循环，并发布WM_CUSTOM_INIT，这会导致初始数据检索尝试，然后回发不同状态的线程消息。
2）在控制台应用程序中执行所有操作，首先调用数据库，然后，如果出现问题，请创建消息循环和窗口。退出窗口，退出消息循环，如果无效，则创建另一个窗口和另一个消息循环。
由于CoInitialize（NULL），我错误的是数据库应用程序将创建的隐藏消息循环。和PostThreadMessage，如果某些dll决定抛出一个表示某事的MessageBox，它可能会失败。此外，在第一种方法中，我会阻止更长的调用，如果它决定使用SendMessage / SendMessageTimeout（WM_GETTITLEORSOMETHING）来枚举窗口或其他东西，可能会锁定其他应用程序。此外，焦点可能是第二种情况下的问题，因为应用程序将在开始时松开前台权限，然后它将无法再次作为前景唤醒。
总的来说，这看起来有点乱，我想的越多，我就越觉得我错过了什么，或做了一些完全错误的事情。
答案 0 :(得分：1)
我推荐CreateProcess：
http://msdn.microsoft.com/en-us/library/ms682425%28v=vs.85%29.aspx
您可以运行您的程序：
在被叫程序运行时，无需保持程序运行。
有问题吗？ - ＆GT;请评论。
答案 1 :(得分：0)
这应该是一个评论，但它太长了：
为什么成功没有GUI？我并不是故意放弃，但我不是在追求为什么希望你的程序以这种方式行事。
如果你的程序不是控制台程序，那么它的第一个工作应该是向用户展示一些内容，因此他们知道它正在运行。从那里，如果你有一个长期阻塞调用的工作，它应该被分成一个单独的线程。通过消息传递更新消息循环线程，使用进度条或日志窗口，并保持消息循环运行，以便您打开的窗口可以响应移动/最小化/等。
然后如果出现问题，您的窗口就已经可以使用了。如果没有，请弹出一条消息，稍等一下，以便凡人可以阅读（或让他们点击“确定”），然后关闭。
在我的观点中，使用WinMain作为其入口点的程序没有打开“成功”执行的窗口是一个糟糕的设计选择。没有任何迹象表明用户程序甚至已经开始，一直没有完成，也没有任何迹象表明程序完成了多长时间。你只需双击图标，然后......没有。
我见过的唯一一个显示零用户界面的Windows应用程序是服务，你提到了“类似服务”，但服务是为了在服务启动后继续运行并提供服务。它们不是一劳永逸的事情。他们有自己的消息循环。
“不显示任何成功”是一种控制台范例。这可以在这里工作。只需使用main（）（或unicode的wmain（））作为入口点，然后就问题启动控制台交互。