🚀 go-pugleaf

dhoke wrote:

>How does one make straightforward use of SetNamedSecurityInfo() in a module 
>that includes vcl.h?

>#include <vcl.h>
>#include <aclapi.h>

>'PACCESS_MASK' and 'Windows::PACCESS_MASK'

That is defined in 2 places: Windows.hpp and winnt.h
aclapi wants the winnt version.

Doing it this way will get you that:

#include <aclapi.h>
#include <vcl.h>

Thank you.

"Bob Gonder" <notbg@notmindspring.invalid> wrote in message 
news:b4soj31tl9vp26q3j5ddduep0cgcpaceuu@4ax.com...
> Doing it this way will get you that:
>
> #include <aclapi.h>
> #include <vcl.h>
>
>
> 

"dhoke" <dhoke.nojunk@east-shore.com> wrote in message 
news:473c4335$1@newsgroups.borland.com...

> How does one make straightforward use of SetNamedSecurityInfo()
> in a module that includes vcl.h?

Just call it like any other function.

> Compiling the above produces:
> Error E2015 C:\Program Files\Borland\BDS\4.0\Include\aclapi.h 103:
> Ambiguity between 'PACCESS_MASK' and 'Windows::PACCESS_MASK'

PACCESS_MASK has nothing to do with SetNamedSecurityInfo().  This is a 
completely different issue.

Did you look at line 103 yet?  The compiler is complaining about 
GetEffectiveRightsFromAcl(), which has a PACCESS_MASK parameter.

Like I told you the other day, PACCESS_MASK is declared in two separate 
namespaces and your project is including both of them - the global namespace 
and the "Windows" namespace.  Since the function declaration does not 
qualify which namespace to use, the compiler does not know which declaration 
of PACCESS_MASK to use, which is exactly what the error message is telling 
you.

This is due to a bug in the Windows.pas source file of the VCL. 
Borland/CodGear is not defining PACCESS_MASK with the EXTERNALSYM flag so 
the Delphi compiler will not re-declare PACCESS_MASK when generating the 
Windows.hpp file.  Since you are not allowed to recompile the VCL, you have 
two choices:

1) edit Windows.hpp to remove/comment the offending declaration of 
PACCESS_MASK

    // RLebeau: comment this out
    // typedef unsigned *PACCESS_MASK;

2) edit aclapi.h to qualify the PACCESS_MASK parameter of 
GetEffectiveRightsFromAcl() with the global namespace:

    WINADVAPI
    DWORD
    WINAPI
    GetEffectiveRightsFromAclA(
        IN  PACL          pacl,
        IN  PTRUSTEE_A    pTrustee,
        OUT ::PACCESS_MASK  pAccessRights // <-- RLebeau: qualified
    );
    WINADVAPI
    DWORD
    WINAPI
    GetEffectiveRightsFromAclW(
        IN  PACL          pacl,
        IN  PTRUSTEE_W    pTrustee,
        OUT ::PACCESS_MASK  pAccessRights // <-- RLebeau: qualified
    );

#1 is technically the best way to go, but if you go with #2 then you will 
have to make the same change for GetAuditedPermissionsFromAcl() as well.


Gambit 

"Bob Gonder" <notbg@notmindspring.invalid> wrote in message 
news:b4soj31tl9vp26q3j5ddduep0cgcpaceuu@4ax.com...

> Doing it this way will get you that:

At the expense of messing up the VCL's precompiled header, if you use PCHs.


Gambit 

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:473c84be$3@newsgroups.borland.com...
>
> "dhoke" <dhoke.nojunk@east-shore.com> wrote in message 
> news:473c4335$1@newsgroups.borland.com...
>
>> How does one make straightforward use of SetNamedSecurityInfo()
>> in a module that includes vcl.h?
>
> Just call it like any other function.
>
>> Compiling the above produces:
>> Error E2015 C:\Program Files\Borland\BDS\4.0\Include\aclapi.h 103:
>> Ambiguity between 'PACCESS_MASK' and 'Windows::PACCESS_MASK'
>
> PACCESS_MASK has nothing to do with SetNamedSecurityInfo().  This is a 
> completely different issue.
>
> Did you look at line 103 yet?  The compiler is complaining about 
> GetEffectiveRightsFromAcl(), which has a PACCESS_MASK parameter.

Yes, I looked at it, and I understood why it was complaining.

(BTW, the compiler was indeed providing information it obtained from the 
prototype, _not_ from the types provided in the call made from the 
CSharedStruct.h code.  I mentioned this in a different reply, but from 
reading this have the suspicion that you didn't see it.)

>
> Like I told you the other day, PACCESS_MASK is declared in two separate 
> namespaces and your project is including both of them - the global 
> namespace and the "Windows" namespace.  Since the function declaration 
> does not qualify which namespace to use, the compiler does not know which 
> declaration of PACCESS_MASK to use, which is exactly what the error 
> message is telling you.

And in a reply, I indicated that even when I removed the direct include of 
windows.h from the sample, the ambiguity error was still reported...  I did 
not attempt to pursue if it had anything to do with CSharedStruct.h 
including aclapi.h, which may have still been including windows.h...

And I understood where the ambiguity was before your reply - your following 
paragraph at least explains to me likely why the ambiguity exists.

Seems it might be a good idea for Borland/CodeGear to add a pretty simple 
canned automated test that tries to make sure they can build an application 
that includes _all_ of the headers they distribute, and has coded calls to 
all APIs that are present in those headers.  This headache might have been 
avoided, had that been done.  (radstudio2007trial still reports same 
errors.)

>
> This is due to a bug in the Windows.pas source file of the VCL. 
> Borland/CodGear is not defining PACCESS_MASK with the EXTERNALSYM flag so 
> the Delphi compiler will not re-declare PACCESS_MASK when generating the 
> Windows.hpp file.  Since you are not allowed to recompile the VCL, you 
> have two choices:
>
> 1) edit Windows.hpp to remove/comment the offending declaration of 
> PACCESS_MASK
>
>    // RLebeau: comment this out
>    // typedef unsigned *PACCESS_MASK;

But then one has to remember to research/address this in upgrades, and be 
sure all developers in the site make this change, and that the change is 
made anytime a new installation of the development environment might be made 
(adding staff, upgrading machines, repairing machines) - not something I've 
ever thought was a good idea (changing vendor provided files.)

>
> 2) edit aclapi.h to qualify the PACCESS_MASK parameter of 
> GetEffectiveRightsFromAcl() with the global namespace:
>
>    WINADVAPI
>    DWORD
>    WINAPI
>    GetEffectiveRightsFromAclA(
>        IN  PACL          pacl,
>        IN  PTRUSTEE_A    pTrustee,
>        OUT ::PACCESS_MASK  pAccessRights // <-- RLebeau: qualified
>    );
>    WINADVAPI
>    DWORD
>    WINAPI
>    GetEffectiveRightsFromAclW(
>        IN  PACL          pacl,
>        IN  PTRUSTEE_W    pTrustee,
>        OUT ::PACCESS_MASK  pAccessRights // <-- RLebeau: qualified
>    );

Again, changing vendor provided files, not a good idea, IMO.

>
> #1 is technically the best way to go, but if you go with #2 then you will 
> have to make the same change for GetAuditedPermissionsFromAcl() as well.
>
>
> Gambit
>

Bob's approach works for me for now - I can live with the precompiled header 
loss.  (I'm hoping/assuming it will only affect the one source module where 
that change was required.) 

"dhoke" <dhoke.nojunk@east-shore.com> wrote in message 
news:473ca34f$1@newsgroups.borland.com...

> I understood where the ambiguity was before your reply -
> your following paragraph at least explains to me likely why
> the ambiguity exists.

Not "likely why", but "exactly why".  The declaration in Windows.hpp does 
not belong there in the first place.  It is an omission on Borland's part 
inside of Windows.pas.  I have reported the issue to QC now (#54900). 
Hopefully it will make it into the next service pack or something.


Gambit 

I strongly suggest that for each project you establish a custom precompiled 
header name.  It will build the precompiled header on the first time.  Don't 
worry about how long, it is a one-time thing - go have a coke.

.  Ed

> Remy Lebeau wrote in message
> news:473c84ec$1@newsgroups.borland.com...
>
> At the expense of messing up the VCL's precompiled header, if you use 
> PCHs.