考虑一下:
class Foo{
void func1(){
/*func1 code*/
}
void func2(){
/*func2 code*/
}
};
Run Code Online (Sandbox Code Playgroud)
案例 1:Foo.h 中的 Foo 类
案例 2:Foo 类很好地分离在 Foo.h 和 Foo.cpp 中
其他各种 cpp 文件包括 Foo.h
我的问题是...案例 1 会导致更大的二进制文件吗?
我不确定在 Windows 7 下使用 Cygwin 将 C 文件编译为可执行文件。
谁能告诉我该怎么做吗?
我读过一些教程但仍然不明白。我知道我需要一个Makefile,但是我应该在其中写入什么才能在编译过程后获得可执行文件呢?
我知道这个问题的任何答案都可能非常棘手。我完全支持这一点,我喜欢突破一些界限,看看有什么可能,并一路学习。
我想编写一个程序来操纵已知的 exe 来更改其中的字符串。我目前有一个非常简单的 C# 程序,即已知的 exe:
using System;
namespace Target {
class Program {
public static String str = "TESTSTRING";
static void Main(string[] args) {
Console.WriteLine(str);
}
}
}
Run Code Online (Sandbox Code Playgroud)
编译后,在十六进制编辑器中,我看到字符串的第一个字母位于字节 1898 处。它似乎是从那里存储在 Unicode 中的。

一些编译器优化将字符串直接放入调用中Console.WriteLine,并且似乎正在调用一些构造函数(至少我认为是这样.cctor)。我尝试过其他相同长度的字符串,以确保我知道所有的东西是什么。我编写了一个应用程序,可以成功替换TESTSTRING为XXXXXXXXXX(请注意,它们的长度相同)并运行修改后的exe。效果很好。
但是,如果我尝试用不同长度的字符串替换该字符串,则输出 exe 将无法运行。我发现字符串之前的字节似乎包含长度。它似乎是unicode字符串的字节数+1(我不知道+1是做什么用的,也许是一个空终止符?)。但是,如果我用适当的更新值替换该长度,它仍然无法运行。字符串末尾后似乎有几个字节对于不同长度的字符串是不同的。我的猜测是,构造函数类似于,new String(...)并且那些其他字节是构造函数的其他参数(第一个参数是 achar[]或byte[]前面带有它的长度),但我无法解释其他参数是什么具体是。
我知道我正在破坏通常不会发生的事情,但我很好奇这种可能性。关于 .Net exe 的结构,我有什么不知道的地方,而知道了它就可以让我做到这一点?将已编译的 EXE 中的一个字符串替换为另一个不同长度的字符串?另外,如何解释长度超过 127 的字符串?任何超过此长度的值都会影响存储字符串长度所需的字节数。
我希望能够使用任意替换字符串来完成此操作。因此,预编译特定字符串,然后仅使用该预编译字符串及其元数据修补 exe 是不可行的。我应该能够在没有反编译器/编译器的情况下做到这一点。我绝对想以编程方式执行此操作,因此 Reflector 不是一个选项。这可以可靠地完成吗?
我正在编写一个 NodeJS 应用程序,主要做两件事:
我希望能够异步运行这些外部程序,因为它们可能需要几分钟才能完成。当他们返回时,我想更新 Web GUI 以显示结果。这是非常基本的概念:

应该注意的是,用户可以同时运行多个具有不同参数的外部程序。
当外部程序完成时,我应该如何更新客户端(Web GUI):是否必须是客户端轮询更新(例如,如果结果在这里,则通过在数据库中查找)?或者有没有办法从服务器“推送”到客户端?
我还在研究实现此目的的设计示例,因此请随时提供有关此架构的建议和资源。
我编译了一个 C++ 程序,使其在发布模式下有一个 EXE 文件。当我在编辑器中打开 EXE 文件时,我看到一些文本块,其中大部分是程序中使用的低级函数的名称。
人们总是说计算机只能理解二进制机器代码。那么,可执行程序文件中这些人类可读的文本存在的目的是什么呢?为什么计算机需要函数名来运行程序?

IDE:Visual Studio 2015 RC
平台:Windows 8.1 x64
编译器命令行选项:
/GS /GL /W3 /Gy /Zc:wchar_t /Zi /Gm- /Ox /Ob2 /sdl
/Fd"x64\Release\vc140.pdb" /Zc:inline /fp:precise /D "_MBCS"
/errorReport:prompt /GT /WX- /Zc:forScope /Gd /Oy /Oi /MD
/Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /Ot
/Fp"x64\Release\<ProjectName>.pch"
Run Code Online (Sandbox Code Playgroud)
链接器命令行选项:
/OUT:"<SolutionPath>\x64\Release\<ProjectName>.exe"
/MANIFEST /LTCG /NXCOMPAT
/PDB:"<SolutionPath>\x64\Release\<ProjectName>.pdb"
/DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib"
"comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib"
"uuid.lib" "odbc32.lib" "odbccp32.lib"
/MACHINE:X64 /OPT:REF /PGD:"<SolutionPath>\x64\Release\<ProjectName>.pgd"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"x64\Release\<ProjectName>.exe.intermediate.manifest"
/OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1
Run Code Online (Sandbox Code Playgroud)
我对rcgldr 的答案进行了更改。我进行了项目设置更改,将命令行开关更改\MD为 …
当引用目标文件/可执行文件时,我对“段”和“节”之间是否存在差异感到困惑。
根据https://en.wikipedia.org/wiki/Object_file:
大多数目标文件格式被构造为单独的数据部分,每个部分包含某种类型的数据。
不过,本文稍后会继续讨论段(例如代码段、数据段等)。
此外,PE 文件格式(Windows 中的 .exe/.dll/.coff)将这些不同部分称为节(https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v= vs.85).aspx )。
所以我的问题是:两者之间有区别还是实际上是同义词?
我编写了一个 C++ 软件,该软件需要从其所在的文件夹中读取文件,然后在同一文件夹中写入其他文件。
目前,我通过 shell 导航到复制了可执行文件的文件夹,然后使用./executable_name.
我想通过双击来执行它。如果我这样做,软件告诉我它找不到输入文件,那么就好像它没有在正确的文件夹中执行。
我认为有两种方法:
无论如何,我不知道该怎么做。
有人可以帮帮我吗?
我使用 macOS 和 Anaconda 3 来管理我的库和编写脚本。
我想为我的脚本创建一个可执行文件。
我在终端中使用 Pyinstaller 来运行命令:
pyinstaller --onefile /Directory/file.py
但是,终端返回此错误:
File "/anaconda3/lib/python3.6/site-packages/PyInstaller/hooks/hook-sysconfig.py", line 42, in <module>
hiddenimports = [sysconfig._get_sysconfigdata_name()]
TypeError: _get_sysconfigdata_name() missing 1 required positional argument: 'check_exists'
我怎么解决这个问题; 谢谢您的帮助。
我需要在本地存储用户输入到我的 exe 中的一些基本数据。该程序是使用 pyinstaller 编译的,之前使用 os open 方法将数据保存到 txt 文件。据我了解,macOS(我的操作系统,尽管与 Windows 的交叉兼容性很好)会锁定可执行文件,这样它们就不会进行任何文件更改。该程序当前确实保存了数据,但是当再次运行可执行文件时,旧数据将不再可访问。
很明显,应用程序始终在本地存储内容,如何在 python/pyinstaller 组合中专门保存数据?
抱歉,如果这是一个简单的问题,它看起来确实很简单,但我在任何地方都找不到这方面的文档。
executable ×10
c++ ×3
exe ×3
linux ×2
pyinstaller ×2
python ×2
.net ×1
architecture ×1
asynchronous ×1
bash ×1
binary ×1
c ×1
directory ×1
external ×1
git ×1
macos ×1
makefile ×1
node.js ×1
object-files ×1
terminal ×1