如何使用Native Api构建文件路径，并使用NtOpenFile api打开？ [英] How build a path to file using Native Api and open with NtOpenFile api?

问题描述

我需要使用Native api以下列方式构建特定文件的路径：

I need build a path to a specific file using Native api of following way:

     uses
       ntdll_.pas //http://pastebin.com/zJuaJzBB

    procedure strPathFile;
     const
      FILE_SHARE_VALID_FLAGS = $00000007;
    var
     iosb: TIoStatusBlock;
     oa:   TNtObjectAttributes;
     hFile: THandle;
     UniPhysicalMemory : TNtUnicodeString;
     AnsiPhysicalMemory :TNtAnsiString ;
     Status: NTSTATUS;

    begin

      RtlInitAnsiString(@AnsiPhysicalMemory, 'C:\test.txt');
      RtlAnsiStringToUnicodeString(@UniPhysicalMemory, @AnsiPhysicalMemory, true); // here buffer value of @UniPhysicalMemory is only first character of path eg: 'C'
      InitializeObjectAttributes(@oa, @UniPhysicalMemory, OBJ_CASE_INSENSITIVE, 0, nil);

      Status := NtOpenFile(hFile, FILE_GENERIC_READ, oa, iosb,
      FILE_SHARE_VALID_FLAGS, FILE_SYNCHRONOUS_IO_NONALERT);

      ShowMessage(Format('0x%.8x', [Status])); // STATUS_OBJECT_PATH_SYNTAX_BAD

    end;

但是当我调试此代码时，缓冲区的值为 @UniPhysicalMemory 始终是路径文件的第一个字符，并且 NtOpenFile（）返回 STATUS_OBJECT_PATH_SYNTAX_BAD 。请参阅：

but when i debug this code, the value of buffer to @UniPhysicalMemory is always the first character to path file and NtOpenFile() returns STATUS_OBJECT_PATH_SYNTAX_BAD. See:

为什么我有这个问题？

Why i having this problem?

谢谢。

推荐答案

调试器可视化有证据这可能会解释发生了什么。

There is evidence in the debugger visualization that might explain what is going on.

AnsiPhysicalMemory 似乎表示内容为 C：\ test.txt ，但我怀疑字符串的显示只是显示空端接的缓冲区（因为调试器可视化值得注意的不在于我们还可以看到的数据结构中记录的缓冲区的长度是 1 （一））。

AnsiPhysicalMemory appears to indicate a content of C:\test.txt but I suspect that the display of the string is simply presenting the null-terminated buffer (since the debugger visualization presumably pays no attention to the length of that buffer as recorded in the data structure which we can also see is 1 (one)).

由于初始化函数需要一个null终止的源代码，并且已经确定了一个长度因此，这表明该函数认为有一个空终止符immed我在这个文字字符串中的 C 之后：

Since the initialization function expects a null terminated SourceString and has determined a length of 1 as a result, this suggests that the function believes there is a null terminator immediately following the C in this literal string:

RtlInitAnsiString(@AnsiPhysicalMemory, 'C:\test.txt');

在该初始 C 如果编译器将字符串编码为UTF-16，因为UTF-16编码将是：

There will be a null after that initial C if the compiler is encoding the string as UTF-16 since the UTF-16 encoding would be:

C#0:#0\#0t#0e#0s#0t#0.#0t#0x#0t#0

结论

编译器将文字编码为UTF-16，Unicode字符串而不是 AnsiString 。

如果 RtlInitAnsiString（）的声明错误地将 SourceString 参数标识为 PChar 或 PWideChar 当它应该是 PAnsiChar 。

It will do this if the declaration of RtlInitAnsiString() is incorrectly identifying the SourceString parameter as PChar or PWideChar when it should be PAnsiChar.

解决方案：检查并在必要时更正该功能的声明。

Solution: Check and, if necessary correct, the declaration of that function.

这篇关于如何使用Native Api构建文件路径，并使用NtOpenFile api打开？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！