如何获取正在运行的进程的命令行参数
在我的程序中,当我使用 mxmlc 的命令行编译命令。 该错误与 嵌入的字体名称未被 Flex 正确识别 系统字体列表。
然而,一时兴起,我决定将代码复制到 Flex Builder 中并 在那里编译它。 令我惊讶的是,它成功了,并且找到了合适的 字体使用与我给出的相同系统名称(PMingLiU)。
我怀疑我的问题可能是区域设置问题,并且我的系统无法 出于区域设置的考虑,正确识别字体名称。
我尝试将编译代码的区域设置设置为 en_US,设置为 no 有用。 所以我想请问这里有没有人知道Flex Builder到底是如何调用MXML编译器的以及与直接运行mxmlc相比有什么区别? 我们知道它没有直接使用 mxmlc.exe,因为我们尝试用我们自己的可执行文件替换 mxmlc 以捕获命令行参数。
如果重要的话,使用的操作系统是 Windows XP。
In my program, I have been receiving an error when I use a
command-line compile command for mxmlc. The error is related to an
embedded font name not being correctly identified by flex in the
system fonts list.
However, on a whim, I decided to copy the code to Flex Builder and
compile it there. To my surprise, it worked, and it found the proper
font using the same system name I had given (PMingLiU).
I suspected my problem may be a locale one, and that my system cannot
correctly identify the font name because of locale considerations.
I've tried setting the locale of the compile code to en_US, to no
avail. So I would like to ask if anyone here knows how exactly Flex Builder invokes the MXML compiler and what differences there are compared to running mxmlc directly? We know it's not using the mxmlc.exe directly, since we tried replacing mxmlc with our own executable to capture the command line parameters.
If it matters, the OS used is Windows XP.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
虽然我没有您的问题的确切答案(Flex Builder 将哪些命令行参数传递给 mxmlc.exe),但我确实为您提供了元答案。 您可以使用两种方法之一找到命令行。
第一个与平台无关,但需要您编译一个小型 C++ 程序。 我以前在解决类似问题时也使用过这种方法。 您可以做的是创建一个包装应用程序,它将命令行简单地输出到文件中。 构建此应用程序并将其作为 mxmlc.exe 的临时替代品放入其中,当 Flex Builder 执行它时,您将能够访问生成的文件“cmdline.txt”以获取调用它的完整命令行:
如果您觉得在 Flex Builder 上玩这个肮脏的把戏不合适,那么假设您在 Windows 上运行,还有另一种选择。 您可以使用 WMI 迭代所有正在运行的进程并获取其命令行信息。 Ruby 是我选择的语言,这需要您安装适用于 Windows 的 Ruby 解释器,您可以使用 One- 轻松完成此操作单击适用于 Windows 的 Ruby 安装程序。
安装后,只需在 Flex Builder 启动构建后立即运行此脚本:
我添加了一个正则表达式,仅打印在命令行中以“mxmlc”启动的进程的命令行(这应该适用于您的需求)。 对于迭代每个进程的更通用的解决方案,只需删除包含以下内容的行末尾的 if 子句:
这将为您省去使用 StartRemoteThread 执行任何低级魔法并浏览 PEB 结构的麻烦。
考虑到您问题的性质,并且没有有关您的开发操作系统的更多信息,这就是我能做的最好的事情。 如果这解决了您的问题,我可能建议您编辑您的帖子,以便面临类似问题的人可以找到此解决方案。 像“如何获取正在运行的进程的命令行参数”这样的标题可能更合适。
Although I don't have the exact answer to your question (what command line arguments Flex Builder passes to mxmlc.exe), I do have a meta-answer for you. You can find the command line by using one of two methods.
The first is platform-agnostic but will require you to compile a small C++ program. I've used this approach before when solving similar problems. What you can do is create a wrapper application which simply outputs the command line to a file. Build this application and drop it in as a temporary replacement for your mxmlc.exe, and when Flex Builder executes it you'll be able to access the resulting file "cmdline.txt" to get the full command line that it was called with:
If you don't feel right about playing this dirty trick on Flex Builder, there is an alternative assuming you're running on Windows. You can use WMI to iterate over all of the running processes and grab their command line information. Ruby being my language of choice, this would require you to install the Ruby interpreter for Windows which you can do easily with the One-Click Ruby Installer for Windows.
After installing, just run this script as soon as Flex Builder kicks off your build:
I've added in a regular expression to print out the command line only for processes which were started with "mxmlc" in the command line (which should work for your needs). For a more general solution of iterating over each process, just remove the if clause at the end of the line containing:
This will save you the headache of doing any low-level magic with StartRemoteThread and navigating through the PEB structures.
That's about the best I could do considering the nature of your question and without more information regarding your development OS. If this solves your problem I might suggest that you edit your post so that people facing similar issues can find this solution. A title like "How to get command line arguments for a running process" might be more apt.