From: Paul Clement on
On Sun, 7 Mar 2010 23:22:04 -0500, "mayayana" <mayayana(a)nospam.invalid> wrote:


� >

� Those are both VBScript hacks with dependencies.


Nope. ADSI is a COM library that is already installed. It can be used from VBScript but otherwise
has nothing to do with it.


Paul
~~~~
Microsoft MVP (Visual Basic)
From: mayayana on
> �
> � Those are both VBScript hacks with dependencies.
>
>
> Nope. ADSI is a COM library that is already installed. It can be used from
VBScript but otherwise
> has nothing to do with it.
>

Your link gives directions to download and
register the file, so it's apparently not already
installed on all systems. (Maybe you mean
the XP SP2+ "supported systems" and just can't
be bothered to mention that detail for
clarification?)

The links I find seem to all refer to script.
And they refer to the file as being part of the
ADSI SDK, not the system.

I got a lot of hits on Google about people
looking for a download link. And the MS pages
I find -- your link and this:

http://support.microsoft.com/kb/279682

-- both show VBS sample code. Obviously that
*can* be used from VB, but it appears to be
an ActiveX DLL designed for script. In addition,
according to your link, it takes some work to
get the permissions inherited.

And this conversation implies that the file is
really for AD use, not ideal for setting permissions:

http://74.125.47.132/search?q=cache:OD6KsVs9gwAJ:www.experts-exchange.com/Se
curity/Win_Security/Q_21019361.html+ADsSecurity.DLL+available+download&cd=13
&hl=en&ct=clnk&gl=us


So what's the point? I posted a link to basic
API code that sets inherited permissions. Why
would one choose ADsSecurity.DLL over that?
So that you can later come back and say it would
have been easier in .Net?


From: Paul Clement on
On Mon, 8 Mar 2010 10:24:48 -0500, "mayayana" <mayayana(a)nospam.invalid> wrote:

� > �
� > � Those are both VBScript hacks with dependencies.
� >
� >
� > Nope. ADSI is a COM library that is already installed. It can be used from
� VBScript but otherwise
� > has nothing to do with it.
� >

� Your link gives directions to download and
� register the file, so it's apparently not already
� installed on all systems. (Maybe you mean
� the XP SP2+ "supported systems" and just can't
� be bothered to mention that detail for
� clarification?)

� The links I find seem to all refer to script.
� And they refer to the file as being part of the
� ADSI SDK, not the system.

� I got a lot of hits on Google about people
� looking for a download link. And the MS pages
� I find -- your link and this:

� http://support.microsoft.com/kb/279682

� -- both show VBS sample code. Obviously that
� *can* be used from VB, but it appears to be
� an ActiveX DLL designed for script. In addition,
� according to your link, it takes some work to
� get the permissions inherited.

� And this conversation implies that the file is
� really for AD use, not ideal for setting permissions:

� http://74.125.47.132/search?q=cache:OD6KsVs9gwAJ:www.experts-exchange.com/Se
� curity/Win_Security/Q_21019361.html+ADsSecurity.DLL+available+download&cd=13
� &hl=en&ct=clnk&gl=us


� So what's the point? I posted a link to basic
� API code that sets inherited permissions. Why
� would one choose ADsSecurity.DLL over that?
� So that you can later come back and say it would
� have been easier in .Net?


You dismissed both as VBScript hacks and that was not true. That was all that I was pointing out in
my reply. I am certain that you understand that both of the COM libraries can be used from VB 6.0
(you only need the ADsSecurity.DLL).

Kind of ironic that the solution chosen by the OP at the Experts Exchange link you posted
implemented the scripting solution from my first link. ;-)

In any event, I'm not really going to debate which is the *best* method, and I didn't dismiss yours.
I'll leave it up to the OP to chose. My reason for posting those examples is that they are
alternatives to the Windows security API, which can be fairly complicated, especially if it needs to
be modified in order to satisfy the requirements.

I didn't really see any reason to attack my suggestions and mislead. I did not attack yours.


Paul
~~~~
Microsoft MVP (Visual Basic)
From: mayayana on

> I didn't really see any reason to attack my suggestions and mislead. I did
not attack yours.
>

They're not "mine" or "yours". They're just code.
If you have any useful critique of limitations or
issues with the code I linked then I'd be very
interested to know about those. In my usage that
code has been dependable, simple, and it's easy
to add into a project. (There is one caveat:
it's designed for setting or removing permissions
for all. As written the class doesn't deal with
setting fine-grained permissions for specific
people. The logic in that is that it's usually not
relevant -- as is true in this case.)

You're supposed to be an expert in VB. I don't
see how you can prefer shelling to a utility or
calling a specialized COM DLL over simple, concise
API code. Both of the methods you're suggesting
provide VBS samples for a good reason: They're aimed
at system admins who don't have access, knowledge,
or tools to use the API. What could be more of a hack
in compiled software than shelling out to a command
line utility designed for system admins?

> Kind of ironic that the solution chosen by the OP
> at the Experts Exchange link you posted
> implemented the scripting solution from my first link. ;-)

Ironic? Yes, the OP decided to call xcacls via
WScript.Shell. You think that makes your case?
The link is a discussion between scripters using
VBS under the WSH!


From: Paul Clement on
On Tue, 9 Mar 2010 10:05:25 -0500, "mayayana" <mayayana(a)nospam.invalid> wrote:


� > I didn't really see any reason to attack my suggestions and mislead. I did
� not attack yours.
� >

� They're not "mine" or "yours". They're just code.
� If you have any useful critique of limitations or
� issues with the code I linked then I'd be very
� interested to know about those. In my usage that
� code has been dependable, simple, and it's easy
� to add into a project. (There is one caveat:
� it's designed for setting or removing permissions
� for all. As written the class doesn't deal with
� setting fine-grained permissions for specific
� people. The logic in that is that it's usually not
� relevant -- as is true in this case.)

� You're supposed to be an expert in VB. I don't
� see how you can prefer shelling to a utility or
� calling a specialized COM DLL over simple, concise
� API code. Both of the methods you're suggesting
� provide VBS samples for a good reason: They're aimed
� at system admins who don't have access, knowledge,
� or tools to use the API. What could be more of a hack
� in compiled software than shelling out to a command
� line utility designed for system admins?

I didn't state a preference, simply a couple of alternatives. Like I said, it's up to the OP. If he
is comfortable working with the Windows API and the solution satisfies his requirements then by all
means I see no reason why he shouldn't use it instead of the alternatives.

� > Kind of ironic that the solution chosen by the OP
� > at the Experts Exchange link you posted
� > implemented the scripting solution from my first link. ;-)

� Ironic? Yes, the OP decided to call xcacls via
� WScript.Shell. You think that makes your case?
� The link is a discussion between scripters using
� VBS under the WSH!


It's not about making a case. What I choose to implement may be different than what you or someone
else may choose, based upon knowledge, experience, requirements and other factors.


Paul
~~~~
Microsoft MVP (Visual Basic)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: Filling an excel range from a vb function
Next: 1.0e to VB6