[PATCH 1/2] kernel32: Add CreateBoundaryDescriptorA semi-stub.
Needed for IE11. Signed-off-by: Mohamad Al-Jaf <mohamadaljaf(a)gmail.com> --- Documentation written in my own words. --- dlls/kernel32/kernel32.spec | 2 +- dlls/kernel32/sync.c | 35 +++++++++++++++++++++++++++++++++++ include/namespaceapi.h | 2 ++ 3 files changed, 38 insertions(+), 1 deletion(-) diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec index 7db82db375d..e040fedab08 100644 --- a/dlls/kernel32/kernel32.spec +++ b/dlls/kernel32/kernel32.spec @@ -266,7 +266,7 @@ @ stdcall CopyLZFile(long long) LZCopy @ stdcall CreateActCtxA(ptr) @ stdcall -import CreateActCtxW(ptr) -# @ stub CreateBoundaryDescriptorA +@ stdcall CreateBoundaryDescriptorA(str long) @ stdcall -import CreateBoundaryDescriptorW(wstr long) @ stdcall -import CreateConsoleScreenBuffer(long long ptr long ptr) @ stdcall -import CreateDirectoryA(str ptr) diff --git a/dlls/kernel32/sync.c b/dlls/kernel32/sync.c index 219800a46e5..27a1ab86d8a 100644 --- a/dlls/kernel32/sync.c +++ b/dlls/kernel32/sync.c @@ -190,6 +190,41 @@ HANDLE WINAPI DECLSPEC_HOTPATCH OpenMutexA( DWORD access, BOOL inherit, LPCSTR n } +/****************************************************************************** + * CreateBoundaryDescriptorA (KERNEL32.@) + * + * Creates and returns a handle to a boundary descriptor. + * + * PARAMS + * name [I] Boundary descriptor name + * flags [I] Flags for the descriptor + * + * RETURNS + * Success: Handle to boundary descriptor + * Failure: NULL + */ +HANDLE WINAPI CreateBoundaryDescriptorA( LPCSTR name, ULONG flags ) +{ + DWORD len; + HANDLE ret; + LPWSTR str = NULL; + + FIXME("%s %u - semi-stub\n", debugstr_a(name), flags); + + if(name) + { + len = MultiByteToWideChar( CP_ACP, 0, name, -1, NULL, 0 ); + str = HeapAlloc( GetProcessHeap(), 0, len*sizeof(WCHAR) ); + MultiByteToWideChar( CP_ACP, 0, name, -1, str, len ); + } + + ret = CreateBoundaryDescriptorW( str, flags ); + + HeapFree( GetProcessHeap(), 0, str ); + return ret; +} + + /* diff --git a/include/namespaceapi.h b/include/namespaceapi.h index 9446806f82e..f219a2a7488 100644 --- a/include/namespaceapi.h +++ b/include/namespaceapi.h @@ -27,7 +27,9 @@ extern "C" { WINBASEAPI BOOL WINAPI AddSIDToBoundaryDescriptor(HANDLE*,PSID); WINBASEAPI BOOLEAN WINAPI ClosePrivateNamespace(HANDLE,ULONG); +WINBASEAPI HANDLE WINAPI CreateBoundaryDescriptorA(LPCSTR,ULONG); WINBASEAPI HANDLE WINAPI CreateBoundaryDescriptorW(LPCWSTR,ULONG); +#define CreateBoundaryDescriptor WINELIB_NAME_AW(CreateBoundaryDescriptor) WINBASEAPI HANDLE WINAPI CreatePrivateNamespaceW(LPSECURITY_ATTRIBUTES,LPVOID,LPCWSTR); WINBASEAPI void WINAPI DeleteBoundaryDescriptor(HANDLE); WINBASEAPI HANDLE WINAPI OpenPrivateNamespaceW(LPVOID,LPCWSTR); -- 2.35.1
Signed-off-by: Mohamad Al-Jaf <mohamadaljaf(a)gmail.com> --- Written in my own words. --- dlls/kernelbase/security.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/dlls/kernelbase/security.c b/dlls/kernelbase/security.c index 3c1a3d7f077..7139dc26189 100644 --- a/dlls/kernelbase/security.c +++ b/dlls/kernelbase/security.c @@ -924,6 +924,16 @@ BOOL WINAPI ConvertToAutoInheritPrivateObjectSecurity( PSECURITY_DESCRIPTOR pare /****************************************************************************** * CreateBoundaryDescriptorW (kernelbase.@) + * + * Creates and returns a handle to a boundary descriptor. + * + * PARAMS + * name [I] Boundary descriptor name + * flags [I] Flags for the descriptor + * + * RETURNS + * Success: Handle to boundary descriptor + * Failure: NULL */ HANDLE WINAPI CreateBoundaryDescriptorW( LPCWSTR name, ULONG flags ) { -- 2.35.1
Hi, I don't think sync is an appropriate file to put this function in and I don't know where else it could go. I don't think kernel_main is right either. Should I create a new security file? It's just one function so I'm not sure if this is okay. -- Kind regards, Mohamad
On 2/18/22 19:42, Mohamad Al-Jaf wrote:
Hi,
I don't think sync is an appropriate file to put this function in and I don't know where else it could go. I don't think kernel_main is right either. Should I create a new security file? It's just one function so I'm not sure if this is okay. --
I'd put it to kernel_main.c, new file is probably too much. Note that it's not really right to keep calling it semi-stub, or leaving a fixme in, because once you forward to W variant there is nothing else to do for A call. Another thing is that you could get away with static sized buffer, like e.g. OpenMutexA() does, if tests show similar name length limit.
Kind regards, Mohamad
On 2/18/22 19:42, Mohamad Al-Jaf wrote:
Hi,
I don't think sync is an appropriate file to put this function in and I don't know where else it could go. I don't think kernel_main is right either. Should I create a new security file? It's just one function so I'm not sure if this is okay. --
Another thing I forgot to mention. I personally find documentation headers before functions quite useless, when they don't describe anything more than argument types that you can already see right below.
Kind regards, Mohamad
Hi Nikolay,
I'd put it to kernel_main.c, new file is probably too much. Note that it's not really right to keep calling it semi-stub, or leaving a fixme in, because once you forward to W variant there is nothing else to do for A call. Another thing is that you could get away with static sized buffer, like e.g. OpenMutexA() does, if tests show similar name length limit.
I just remembered that the functions in namespaceapi are dependent on one another. So I'm also going to have to add CreatePrivateNamespaceA and OpenPrivateNamespaceA to kernel32. Also, I think I need to add a new test called security for these functions. In this case, would a new file still be too much? Kernel_main says it's for kernel initialization so these functions don't seem like they belong there. For the subject, would it be better to say it's an implementation, e.g. kernel32: Implement CreateBoundaryDescriptorA. Regarding the static sized buffer, I did a test on my Windows 10 machine. It does not seem to have a name length limit. But, I also tested other functions, including one that has a MAX_PATH limit according to Microsoft Docs. None of them have a limit on my machine. I'm guessing it differs depending on whether it's 32-bit or 64-bit. But shouldn't the ANSI function check if the argument exceeds MAX_PATH before it's forwarded to the Unicode function? In any case, given the nature of the function, MAX_PATH should be more than enough to accommodate a name. I'm guessing I should submit a test patch for CreateBoundaryDescriptorA so that the testbot can verify if it doesn't have a limit on other configurations. I've attached the test. It has some extra traces that I added temporarily. I'll remove them when I submit the patch and of course create a new file. Also, please let me know if the test is incorrect.
Another thing I forgot to mention. I personally find documentation headers before functions quite useless, when they don't describe anything more than argument types that you can already see right below.
Okay, I'll remove the documentation. -- Kind regards, Mohamad
participants (2)
-
Mohamad Al-Jaf -
Nikolay Sivov