[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Make 9pfs buildable for Windows
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] Make 9pfs buildable for Windows |
Date: |
Mon, 6 Nov 2017 16:36:23 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
On 06/11/2017 16:14, Michael Fritscher wrote:
> The main thing was the question whether to make a sort of "hack" to
> emulate the *at commands (which is the way used by the patch, the main
> idea using /proc/<pid>/fd information) or make a 9pfs_local_windows
> variant which uses the native ntdll api. Which is ... another style of
> codeing, let me say it this way...
Yeah, that's expected.
> To get an idea I've attached the "main" code with my experiments to open
> the directory. The main question is: Is this kind of code ok? Sadly it
> seems the only way to access the ntdll's function, which in turn is the
> only way to have *at aquivalents.
Just one note, it's probably better to use UTF-8 for the codepage instead
of CP_ACP:
MultiByteToWideChar(CP_ACP, 0, relative, -1, filename_WIDECHAR,
sizeof(filename_WIDECHAR));
RtlInitUnicodeStringStruct(&filename_UNICODE, filename_WIDECHAR);
> Yes, the code is a bit dirty (very WIP). Additionally, I seem to destroy
> the stack, because after running this function qemu exists. Fixing this is
> my next step.
For what it's worth, the Wine code for kernel32 (see
https://github.com/wine-mirror/wine/blob/master/dlls/kernel32/file.c)
might be of some help.
> NT_OPEN_FILE NtOpenFileStruct;
Better:
static NT_OPEN_FILE p_NtOpenFile;
Paolo
>
> Best regards,
> Michael Fritscher
>