缺少命令行参数，调用Win32 API GetCommandLine [英] Missing command line arguments with call to Win32 API GetCommandLine

问题描述

有一种情况我无法解释为什么当
GetCommandLine 被调用时，我们的软件会演示丢失命令行argumnets的行为。我们的软件提供了2个不同的DLL（调用
GetCommandLine ），由2个独立且不同的基于MFC的EXE调用，但在这两个实例中返回的字符串不包含任何参数。例如，如果启动我们软件的快捷方式是： 

Have a situation that I cannot explain why our software demonstrates the behavior of losing command line argumnets when GetCommandLine is called. Our software ships 2 different DLLs (that make the call to GetCommandLine) that called by 2 separate and different MFC based EXEs, but in both instances the string returned does not include any arguments. So for example, if the shortcut to start our software is:  

问：\INSYTE \Inwin.exe" -iC：\INSYTE \INWIN.INI"

Q:\INSYTE\Inwin.exe "-iC:\INSYTE\INWIN.INI"

当 GetCommandLine 被调用（来自DLL）时，返回的字符串只包含：Q：\INSYTE \ Inwin 。可执行程序。

when GetCommandLine is called (from the DLLs) the string returned only contains: Q:\INSYTE\Inwin.exe.

现在这种行为发生在最近升级到我们软件最新版本的2个客户端网站上，但是有问题的2个DLL都没有被修改为超过2年。但是，另一个客户端也升级到同一版本
并没有遇到此问题。

Now this behavior is happening at 2 client sites which just recently upgraded to the lastest release of our software, but the 2 DLLs in question neither one has been up modified for more than 2 years. However another client also upgrade to same release and did not experience this problem.

我怀疑问题是系统配置，安全/权限，防病毒，网络，未修补的


计算机或者其他可能完全在客户的网站。我需要解决这个问题才能有效地打破我们的软件。

I suspect that the problem is system configuration, security/permissions, anti-virus, network, unpatched
computers or possibly something else entirely at the client's site. I need a resolution for this problem effectively breaks our software.

我正在寻求帮助，以提供进一步调查解决问题的建议。

Am looking for assistance to offer suggestions as to where to investigate further to resolve the matter.

推荐答案

我建议的第一件事就是查看代码本身。

The first thing I would suggest is to look at the code itself.

如果你注意到，该函数不需要你清理任何内存。所以这意味着函数本身没有分配任何东西。这意味着GetCommandLine返回一个静态分配的字符串，Windows本身放在那里。因此，如果
调用GetCommandLine两次，它返回的指针将是相同的。

If you notice, the function doesn't require you to clean up any memory. So it means that the function itself isn't allocating any. This would mean that GetCommandLine is returning a statically allocated string that Windows itself places in there. So if you call GetCommandLine two times, the pointer it returns will be the same.

命令行问题不正确的最常见原因之一是应用程序调用GetCommandLine，或者只使用WinMain的命令行参数并使用strtok / wcstok。 WindMain中的命令行参数由GetCommandLine获得
，然后初始化代码只是递增指针，直到它超过应用程序名称。无论如何，strtok / wcstok在空格所在的位置放置空字符，并基本上截断字符串。第二次调用GetCommandLine将
然后得到与你刚刚使用strtok / wcstok相同的字符串，它将被截断。

One of the most common causes of problems with the command line not being correct is that an application calls GetCommandLine, or just uses the command line parameter of WinMain as it is and uses strtok/wcstok. The command line parameter in WindMain is obtained by GetCommandLine and then the initialisation code just increments the pointer until it is past the application name. Anyway, strtok/wcstok puts null characters where the spaces are, and essentially truncates the string. A second call to GetCommandLine will then get the same string as you just used strtok/wcstok on and it will be truncated.

有一个
博客文章。所以这两个建议是，1尝试立即在WinMain中检查命令行。 2，尝试使用您当前使用的相反版本的GetCommandLine。例如，如果您将应用程序
设置为使用Unicode字符集，请尝试显式调用GetCommandLineA并查看它为您提供的内容。

There was a blog post about this by Raymond Chen 8 years ago. So the two suggestions are, 1 try to check the command line immediately in WinMain. 2, try to use the opposite version of GetCommandLine that you are currently using. For example, if you have your application set to use the Unicode character set, try explicitly calling GetCommandLineA and see what this gives you.

这篇关于缺少命令行参数，调用Win32 API GetCommandLine的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！