🚀 go-pugleaf

"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.)