[PATCH 1/2] kernel32: Add CreateBoundaryDescriptorA semi-stub.

Mohamad Al-Jaf mohamadaljaf at gmail.com
Sun Feb 20 23:42:41 CST 2022


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220221/1f72426d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: power.c
Type: text/x-c-code
Size: 7019 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220221/1f72426d/attachment.bin>


More information about the wine-devel mailing list