问题标签 [windows-nt]

I need to create an executable for Windows NT ( yes, Windows NT still exists ). The problem that I have is that VS2005 uses CRT/MFC 8.0, therefore after running the application using the CRT 8.0 libraries I will get an error complaining that GetlongpathnameW doesn't exist on the target environment, which should be fixed by going back to MFC 7.1 CRT libraries.

I have the libraries that I acquired from somewhere else (mfc71.dll, msvcp71.dll, msvcr71.dll....) but how do I get VS to use those instead of the default ones (MFC80.dll....)?

Here is the link of a person with the similar problem: https://social.msdn.microsoft.com/Forums/vstudio/en-US/b6027b6d-7e30-4b76-b92b-b19982a33dfc/the-procedure-entry-point-getlongpathnamew-could-not-be-located-in-the-dynamic-link-library?forum=vcgeneral

Thanks!

我只是在调试一个崩溃的 Windows 应用程序。启动应用程序后，使用 WinDbg 附加到它，然后让它崩溃，WinDbg 命令窗口中出现以下内容：

(119c.1794): Unknown exception - code 0000071a (first chance)

我一直在网上搜索，但没有找到任何关于如何解释这些异常代码的解释。

如果有什么不同的话，那就是在 64 位 Windows 8 上运行的 32 位 .NET 应用程序（通过 WoW64）。

分类选项

实际上，我正在构建一个内核 dll。

该mio.cpp文件在我的系统上不存在，所以我认为这是 cl.exe 源代码的一部分。使用 gcc，有一个选项可以让您知道代码的哪一行触发了编译器错误。
我试图禁用已编译的标头；所有优化将目标更改为 R10000，但错误仍然附加在同一位置。

微软肯定不会纠正错误。我找不到另一个支持这个平台的编译器。

另外我真的需要使用包含文件，因为导出是结构结构的结构。

根据Raymond Chen 的这篇博客文章，Windows NT 通过将它们移动到坐标（-32000，-32000）来“最小化”窗口，而且，我从阅读中得到的印象是早期版本的 Windows NT就是这种情况(3.x, 4...)。

在 Windows NT 的现代版本（例如 7、8 和 10）中，情况仍然如此吗？

是否有可以编写的程序来演示现代 Windows 操作系统上此功能的存在/不存在？

我正在尝试开发 PE 文件的唯一 ID（或某些魔术属性）。借助它，我们可以计算（或跟踪）该文件的任何信息（而不干扰该文件），例如文件大小或入口点的地址或机器代码，或者是文件 32 位或 64 位或 PE 标头中的任何字段。

我曾尝试通过计算 PE 文件的 MD5 并将日志与该文件的所有信息（如文件路径、大小）一起存储（如上）。但这是沉重或昂贵的。

如何找到这样的 ID 或者是否有任何 ID 可以跟踪文件信息？

Windows NT 使用 Unicode（两个字节宽的 UTF-16）作为整个 Windows NT API 的默认编码方法。如果您选择使用 ASCII 或多字节字符集作为默认字符集，它们会将 ASCII 转换为 Unicode。而且使用 ASCII 字符集会比 Unicode 慢。这种转变意味着什么？他们只将 ASCII API 转换为 Unicode API 还是转换所有字符串？例如：如果您使用const char* text = "Hello, world!". 在 Windows NT 上编译它时，编译后的二进制文件是否存储“Hello, world!”？作为 Unicode（26 字节）还是 ASCII（13 字节）？

我正在尝试在 Windows 操作系统中安装 appium。我将工具和平台工具文件夹路径添加到系统路径中。但是系统仍然无法识别adb！！！！

CMD 输出图像：

文件夹视图：

我正在尝试为可以运行 node.js 的操作系统的命名约定提供一个结论性的规则列表。

到目前为止，我没有在互联网上阅读许多资源和类似问题，这就是我发现的：
名称中任何地方的非法字符：

1. windows_nt - /?<>\,:*|"
2. Linux - /
3. 达尔文-/也许：？（有人说它在 OS X 上是允许的，但有人说不是，我不太清楚）

非法名称：

4. windows_nt - CON、PRN、AUX、CLOCK$、NUL、COM1-9、LPT1-9（不包括其他一些设备名称，因为它们仅在旧的 dos 发行版上是非法的，并且 node.js 对它们不可用）

5. Linux -

6. 达尔文——

非法尾随字符：

7. windows_nt - . （点）和（空格）

8. Linux -

9. 达尔文——

非法的前导字符：

10. windows_nt -

11. Linux -

12. 达尔文——

最大文件/目录名称长度：

13. windows_nt -

14. Linux -

15. 达尔文——

最大路径长度：

16. windows_nt -

17. Linux -

18. 达尔文——

如果您能帮助我填补规则集的空白，我将很高兴。此外，只应考虑能够运行 node.js 的操作系统。

我将端口号 8001 用于码头，但是当我运行它时出现以下错误。

我在网上查了一下，发现如何查看我的端口是否被其他服务使用。通过 netstat -a -n -o | find "8001" 命令找到端口号后，我发现端口“8001”正被PID 4 的系统进程使用。我试图在服务菜单中禁用系统服务，但它不允许我为此进程更改任何内容. 如何找出哪个应用程序正在使用我的端口？有什么方法可以找出哪个特定应用程序正在使用我的端口号？

在工作中，我们在 Jenkins 的帮助下定期在几台构建机器上运行我们的单元测试。其中一个单元测试打开一个带有 的文件，并对该文件FILE_FLAG_WRITE_THROUGH进行数万次调用。WriteFile为什么这样做与这个问题无关。仅在其中一台构建机器上，此测试不断超时。经过一番调查，结果发现其根本原因是每次调用都WriteFile被阻塞（线程被切换出去，然后又被切换进来），使得测试运行速度大大降低。奇怪的是，当在这台机器上手动启动测试时，WriteFile并没有阻塞，因此测试没有超时。

经过数小时的反复试验，我找到了一个“解决方法”：在受影响的机器上，如果 Jenkins 是使用任务计划程序启动的，WriteFile被阻止，如果它是手动启动的，或者通过将 BAT 文件放在 Startup 文件夹中，它没有。我认为我需要进行更多调查，所以我创建了一个最小的 repro，一个用 . 打开文件的小程序，FILE_FLAG_WRITE_THROUGH并使用随机数据调用WriteFile它 10000 次。有了这个最小的复制，WriteFile无论我如何启动它，都会不断地阻塞。我真的很困惑，所以在这里我要求对这种行为进行任何解释。我进行测试的所有机器都有 SATA 驱动器，默认设置（写入缓存和 Windows 写入缓存刷新已启用）。

首先对我来说，它甚至不是 100% 清楚FILE_FLAG_WRITE_THROUGH应该做什么。互联网上的信息表明，一个特殊的标志被传递给设备，要求它在写入后刷新其缓存。根据Raymond Chen（和其他一些人）的说法，现在这几乎无关紧要，因为大多数 SATA 驱动器由于性能原因默默地忽略了这个标志。在“应该或不应该阻止”方面，此页面明确指出 withFILE_FLAG_WRITE_THROUGH WriteFile 应该阻止：

在将数据写入文件之前，write 调用不会返回。

你知道为什么我会看到这种奇怪的行为（不一致）吗？我该如何进一步调查？