Microsoft Scripting Runtime Reference

[Karl Irvin]

To use the Textstream object, I had to set a Reference to the Microsoft
Scripting Runtime.

This works good with A2000

Is the Scripting Runtime included with A2002 and A2003 so the Reference
won't be broken when my app is opened with those versions.

Also is the Scripting Runtime included as part of the A2000 Runtime Engine
which some of my customers use.

[Douglas J. Steele]

There's actually no connection that I'm aware of between the Scripting
Runtime and Access: I believe the Scripting Runtime comes with the operating
system, not Office.

If you're concerned about references, try using Late Binding, so that you
don't need to set a reference.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)

"Karl Irvin" <88********@comcast.net> wrote in message
news:RM********************@comcast.com...

To use the Textstream object, I had to set a Reference to the Microsoft
Scripting Runtime.

This works good with A2000

Is the Scripting Runtime included with A2002 and A2003 so the Reference
won't be broken when my app is opened with those versions.

Also is the Scripting Runtime included as part of the A2000 Runtime Engine
which some of my customers use.

[Tom van Stiphout]

On Thu, 25 Aug 2005 15:45:12 -0500, "Karl Irvin"
<88********@comcast.net> wrote:

It's part of the OS and pretty much guaranteed to be there. You should
have no problems.

-Tom.

To use the Textstream object, I had to set a Reference to the Microsoft
Scripting Runtime.

This works good with A2000

Is the Scripting Runtime included with A2002 and A2003 so the Reference
won't be broken when my app is opened with those versions.

Also is the Scripting Runtime included as part of the A2000 Runtime Engine
which some of my customers use.

[David W. Fenton]

Tom van Stiphout <no*************@cox.net> wrote in
news:4b********************************@4ax.com:

On Thu, 25 Aug 2005 15:45:12 -0500, "Karl Irvin"
<88********@comcast.net> wrote:

To use the Textstream object, I had to set a Reference to the
Microsoft Scripting Runtime.

This works good with A2000

Is the Scripting Runtime included with A2002 and A2003 so the
Reference won't be broken when my app is opened with those
versions.

Also is the Scripting Runtime included as part of the A2000
Runtime Engine which some of my customers use.

It's part of the OS and pretty much guaranteed to be there. You
should have no problems.

But it's one that is very often disabled through domain policies by
security-conscious system administrators.

I wouldn't count on it being installed or usable.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Gord]

>I wouldn't count on it being installed or usable.

In which case you should ask those same administrators to tell you up
front which other *integral parts* of the OS they have disabled. It
will make your life as a developer a lot easier.
Gord

[David W. Fenton]

"Gord" <gd*@kingston.net> wrote in
news:11**********************@g49g2000cwa.googlegr oups.com:

I wouldn't count on it being installed or usable.

In which case you should ask those same administrators to tell you
up front which other *integral parts* of the OS they have
disabled. It will make your life as a developer a lot easier.

The WSH is *not* an "integral part" of the oS. It's an insecure,
badly designed add-on to the OS that opens up massive security
vulnerabilities.

Yes, it's extraordinarily capable, but it's simply not designed to
be secure, so I don't think it's something anyone should count on
using, unless they are assured that it is available. And, of course,
when one is assured of that, one knows the network involved is not
terribly well administered from a security standpoint.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Sat, 27 Aug 2005 15:01:10 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

"Gord" <gd*@kingston.net> wrote in
news:11**********************@g49g2000cwa.googleg roups.com:

I wouldn't count on it being installed or usable.

In which case you should ask those same administrators to tell you
up front which other *integral parts* of the OS they have
disabled. It will make your life as a developer a lot easier.

The WSH is *not* an "integral part" of the oS. It's an insecure,
badly designed add-on to the OS that opens up massive security
vulnerabilities.

Yes, it's extraordinarily capable, but it's simply not designed to
be secure, so I don't think it's something anyone should count on
using, unless they are assured that it is available. And, of course,
when one is assured of that, one knows the network involved is not
terribly well administered from a security standpoint.

I know what you're saying used to be true, and perhaps it still is, but I'm
not at all certain of that.

1. I have an impression (though I don't know it for a fact) that large enough
fraction of commercial software is now written with the assumption that the
WSH libraries are available that WSH might now have to be considered integral
to the OS. If it's a piece that many popular applications won't function
without, that makes it integral.
2. Microsoft might have done better to engineer security in up front rather
than breaking everything later to achieve it, they have locked a lot of things
down much better how. I believe that WSH was one of the highest profile holes
that really did get boarded up. No program can make calls to very much of the
WSH now unless security is set to low or the user has chosen to allow a
specific application to use "unsafe expressions". The gaping security holes
that still do exist (like the ones a gazzillion spyware apps use) don't seem
to depend on WSH.
3. Many core microsoft libraries seem to now make the assumption that WSH is
also available. For instance, show me a way to stream MSXML SAX output to a
file on disk without FSO. You can do it to a stream in memory (which kinda
defeats the purpose) using an ADO stream, or you can stream to http in ASP,
but neither of those will get you a stream directly to a local file.
4. Dictionaries are mindbogglingly useful, but VB doesn't have one, and if you
roll your own, you have to debug it yourself, and you make your app harder to
maintain. WSH has a good dictionary object.

I'm not saying I'm sure you're wrong, but I think the above are some good
reasons to consider the answer less than black or white.

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0i********************************@4ax.com:

On Sat, 27 Aug 2005 15:01:10 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

"Gord" <gd*@kingston.net> wrote in
news:11**********************@g49g2000cwa.google groups.com:

I wouldn't count on it being installed or usable.

In which case you should ask those same administrators to tell
you up front which other *integral parts* of the OS they have
disabled. It will make your life as a developer a lot easier.
The WSH is *not* an "integral part" of the oS. It's an insecure,
badly designed add-on to the OS that opens up massive security
vulnerabilities.

Yes, it's extraordinarily capable, but it's simply not designed to
be secure, so I don't think it's something anyone should count on
using, unless they are assured that it is available. And, of
course, when one is assured of that, one knows the network
involved is not terribly well administered from a security
standpoint.

I know what you're saying used to be true, and perhaps it still
is, but I'm not at all certain of that.

1. I have an impression (though I don't know it for a fact) that
large enough fraction of commercial software is now written with
the assumption that the WSH libraries are available that WSH might
now have to be considered integral to the OS. If it's a piece
that many popular applications won't function without, that makes
it integral.

Well, this seems to me to be the lemming argument. That lots of
software companies are jumping off the cliff doesn't mean I should
jump off the cliff. This point is only relevant to the question of
whether you can count on it to be available for use, and is an
indirect argument (sort of like looking out the window, seeing
people carrying umbrellas and assuming it's therefore raining; if
everybody's carrying one, your conclusion is pretty firm; if only a
few people are, it's not so dependable).

One should choose the components incorporated into your Access
application based on merit and ease of maintenance. For
functionality that can be implemented without WSH components (such
as file system access), it seems to me obvious that you should
construct your Access app without any outside dependencies.

For things that Access can't do by itself, it's a harder question.
But I strongly doubt that there's any common area of functionality
that one would want to include in an Access app for which there is
not some alternative to using the WSH.
2. Microsoft might have done better to engineer
security in up front rather than breaking everything later to
achieve it, they have locked a lot of things down much better how.
I believe that WSH was one of the highest profile holes that
really did get boarded up. No program can make calls to very much
of the WSH now unless security is set to low or the user has
chosen to allow a specific application to use "unsafe
expressions". The gaping security holes that still do exist (like
the ones a gazzillion spyware apps use) don't seem to depend on
WSH.
Well, setting security to low opens up gaping security holes.

The WSH should be re-engineered to be able to run safely in
high-security environments. If it's not, it's worthless, as using it
requires you to make your system vulnerable.

That's unacceptable to me, and should be unacceptable to other
Access programmers.
3. Many core microsoft libraries seem to now make the
assumption that WSH is also available. For instance, show me a
way to stream MSXML SAX output to a file on disk without FSO. You
can do it to a stream in memory (which kinda defeats the purpose)
using an ADO stream, or you can stream to http in ASP, but neither
of those will get you a stream directly to a local file.
Many MS products assume that IE is your default brwoser, or force
you to use it. That this is so does not make it a good idea. Indeed,
it's extremely bad design on MS's part, and to me, screams of
anti-competitive business practices.
4.
Dictionaries are mindbogglingly useful, but VB doesn't have one,
and if you roll your own, you have to debug it yourself, and you
make your app harder to maintain. WSH has a good dictionary
object.
Dictionaries? What are you talking about? And why would I need one?
I'm not saying I'm sure you're wrong, but I think the above are
some good reasons to consider the answer less than black or white.

It's an unsafe, insecure pile of garbage. It was badly designed and
implemented from the beginning and MS should be ashamed of
themselves for putting out such a poorly thought-out scripting
engine.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[rkc]

David W. Fenton wrote:

Dictionaries? What are you talking about? And why would I need one?

A Dictionary is a Collection object on steroids.

You don't need one.

[Steve Jorgensen]

On Sun, 28 Aug 2005 14:41:17 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0i********************************@4ax.com :

On Sat, 27 Aug 2005 15:01:10 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

"Gord" <gd*@kingston.net> wrote in
news:11**********************@g49g2000cwa.googl egroups.com:

>I wouldn't count on it being installed or usable.

In which case you should ask those same administrators to tell
you up front which other *integral parts* of the OS they have
disabled. It will make your life as a developer a lot easier.

The WSH is *not* an "integral part" of the oS. It's an insecure,
badly designed add-on to the OS that opens up massive security
vulnerabilities.

Yes, it's extraordinarily capable, but it's simply not designed to
be secure, so I don't think it's something anyone should count on
using, unless they are assured that it is available. And, of
course, when one is assured of that, one knows the network
involved is not terribly well administered from a security
standpoint.
I know what you're saying used to be true, and perhaps it still
is, but I'm not at all certain of that.

1. I have an impression (though I don't know it for a fact) that
large enough fraction of commercial software is now written with
the assumption that the WSH libraries are available that WSH might
now have to be considered integral to the OS. If it's a piece
that many popular applications won't function without, that makes
it integral.

Well, this seems to me to be the lemming argument. That lots of
software companies are jumping off the cliff doesn't mean I should
jump off the cliff. This point is only relevant to the question of
whether you can count on it to be available for use, and is an
indirect argument (sort of like looking out the window, seeing
people carrying umbrellas and assuming it's therefore raining; if
everybody's carrying one, your conclusion is pretty firm; if only a
few people are, it's not so dependable).

One should choose the components incorporated into your Access
application based on merit and ease of maintenance. For
functionality that can be implemented without WSH components (such
as file system access), it seems to me obvious that you should
construct your Access app without any outside dependencies.

Yeah, and I keep finding myself making my own wrappers around the VB file
statements or around API calls to correctly deal with file attributes, etc.
Also, since Dir has a global context, you have to make sure you don't do
nested Dir calls to try to navigate a directory tree.
For things that Access can't do by itself, it's a harder question.
But I strongly doubt that there's any common area of functionality
that one would want to include in an Access app for which there is
not some alternative to using the WSH.
Streaming to files, and dictionaries are 2 that come to mind. Not every app
needs these, but many do. The question for those is use the WSH, or roll your
own. In the case of streams, I don't know how to work around it shor of
writing custom C++ code.

2. Microsoft might have done better to engineer
security in up front rather than breaking everything later to
achieve it, they have locked a lot of things down much better how.
I believe that WSH was one of the highest profile holes that
really did get boarded up. No program can make calls to very much
of the WSH now unless security is set to low or the user has
chosen to allow a specific application to use "unsafe
expressions". The gaping security holes that still do exist (like
the ones a gazzillion spyware apps use) don't seem to depend on
WSH.

Well, setting security to low opens up gaping security holes.

Exactly - so if WSH is now only vulnerable if you do that, who cares, because
the system is wide open anyway.
The WSH should be re-engineered to be able to run safely in
high-security environments. If it's not, it's worthless, as using it
requires you to make your system vulnerable.

Isn't that what they did by blocking "unsafe" expressions? Nothing can now
use the WSH to get to the file system, even for read-only unless the user
grants permission to execute unsafe expressions. Whether it's now safe or
not, I get the impression you'd never believe that it was so long as it is
called WSH (and I won't say for sure that you're wrong in that).

....

3. Many core microsoft libraries seem to now make the
assumption that WSH is also available. For instance, show me a
way to stream MSXML SAX output to a file on disk without FSO. You
can do it to a stream in memory (which kinda defeats the purpose)
using an ADO stream, or you can stream to http in ASP, but neither
of those will get you a stream directly to a local file.

Many MS products assume that IE is your default brwoser, or force
you to use it. That this is so does not make it a good idea. Indeed,
it's extremely bad design on MS's part, and to me, screams of
anti-competitive business practices.

I don't see the WSH as being in that category. WSH is a library, just like
DAO is a library, that keeps everyone form having to choose to reinvent the
functionality within it or go without.

4.
Dictionaries are mindbogglingly useful, but VB doesn't have one,
and if you roll your own, you have to debug it yourself, and you
make your app harder to maintain. WSH has a good dictionary
object.

Dictionaries? What are you talking about? And why would I need one?

I keep finding that my code is easier to maintain the more I use constructs
like collections and dictionaries, and move away from nested logic. A
dictionary is, in memory, much like the environment is in batch files. It's a
collection of values with names, in which new elements are transparently
created when assigned if they don't already exist, and a default value is
returnd for a non-existent element. You can also retrieve a list of the names
in a dictionary, unlike the names list in VBA collections which is write-only
for some really dumb reason.

I'm not saying I'm sure you're wrong, but I think the above are
some good reasons to consider the answer less than black or white.

It's an unsafe, insecure pile of garbage. It was badly designed and
implemented from the beginning and MS should be ashamed of
themselves for putting out such a poorly thought-out scripting
engine.

If you're talking about the fact that it's callable from Web page scripts -
yeah, I'm right with you. As a library of really useful coding tools, I don't
see that it has any problems. I know your issue is that whether it is useful
or not, it is unsafe to have it around. I'm not sure that's still true, and
I'm not sure it's not, but It seems like you're still in knee-jerk mode and
have not considered that things may be different than when you formed your
initial opinion.

[Steve Jorgensen]

On Sun, 28 Aug 2005 22:35:46 GMT, rkc <rk*@rochester.yabba.dabba.do.rr.bomb>
wrote:

David W. Fenton wrote:

Dictionaries? What are you talking about? And why would I need one?

A Dictionary is a Collection object on steroids.

You don't need one.

Frankly, I can count the hours I've spent doing things the harder way instead
of using a dictionary in at least hundreds of hours. Collection oriented
development is a good paradigm that's greatly underappreciated, and
dictionaries are an essential component of that process.

[rkc]

Steve Jorgensen wrote:

On Sun, 28 Aug 2005 22:35:46 GMT, rkc <rk*@rochester.yabba.dabba.do.rr.bomb>
wrote:

David W. Fenton wrote:

Dictionaries? What are you talking about? And why would I need one?

A Dictionary is a Collection object on steroids.

You don't need one.

Frankly, I can count the hours I've spent doing things the harder way instead
of using a dictionary in at least hundreds of hours. Collection oriented
development is a good paradigm that's greatly underappreciated, and
dictionaries are an essential component of that process.

I agree dictionaries can be useful, but I have never used them outside
of ASP web scripting.

I was simply agreeing with dwf that he doesn't need them.

I didn't get any hits on "Collection oriented development", so I am
not sure what the paradigm is.

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:hn********************************@4ax.com:

On Sun, 28 Aug 2005 14:41:17 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0i********************************@4ax.co m:

On Sat, 27 Aug 2005 15:01:10 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

"Gord" <gd*@kingston.net> wrote in
news:11**********************@g49g2000cwa.goog legroups.com:

>>I wouldn't count on it being installed or usable.
>
> In which case you should ask those same administrators to tell
> you up front which other *integral parts* of the OS they have
> disabled. It will make your life as a developer a lot easier.

The WSH is *not* an "integral part" of the oS. It's an insecure,
badly designed add-on to the OS that opens up massive security
vulnerabilities.

Yes, it's extraordinarily capable, but it's simply not designed
to be secure, so I don't think it's something anyone should
count on using, unless they are assured that it is available.
And, of course, when one is assured of that, one knows the
network involved is not terribly well administered from a
security standpoint.

I know what you're saying used to be true, and perhaps it still
is, but I'm not at all certain of that.

1. I have an impression (though I don't know it for a fact) that
large enough fraction of commercial software is now written with
the assumption that the WSH libraries are available that WSH
might now have to be considered integral to the OS. If it's a
piece that many popular applications won't function without,
that makes it integral.
Well, this seems to me to be the lemming argument. That lots of
software companies are jumping off the cliff doesn't mean I should
jump off the cliff. This point is only relevant to the question of
whether you can count on it to be available for use, and is an
indirect argument (sort of like looking out the window, seeing
people carrying umbrellas and assuming it's therefore raining; if
everybody's carrying one, your conclusion is pretty firm; if only
a few people are, it's not so dependable).

One should choose the components incorporated into your Access
application based on merit and ease of maintenance. For
functionality that can be implemented without WSH components (such
as file system access), it seems to me obvious that you should
construct your Access app without any outside dependencies.

Yeah, and I keep finding myself making my own wrappers around the
VB file statements or around API calls to correctly deal with file
attributes, etc. Also, since Dir has a global context, you have to
make sure you don't do nested Dir calls to try to navigate a
directory tree.

Well, any tool allows you to make mistakes, so I don't see that as
much of an advantage incomparison to the downside of introducing an
outside dependency, with the uncertainty that comes from not knowing
if it will be installed, as well as MS's habit of noncompatible
component versions.

For things that Access can't do by itself, it's a harder question.
But I strongly doubt that there's any common area of functionality
that one would want to include in an Access app for which there is
not some alternative to using the WSH.

Streaming to files, and dictionaries are 2 that come to mind. Not
every app needs these, but many do. The question for those is use
the WSH, or roll your own. In the case of streams, I don't know
how to work around it shor of writing custom C++ code.

I don't even know what a stream is, except the basic definition, and
don't know why I'd ever need one. I can write data to files already
without outside components.

Of course, you seem to think XML is useful, and I don't, except as
an export/import format. And that functionality should be supported
natively in Access, not through outside components that are not part
of Access.

2. Microsoft might have done better to engineer
security in up front rather than breaking everything later to
achieve it, they have locked a lot of things down much better
how.
I believe that WSH was one of the highest profile holes that
really did get boarded up. No program can make calls to very
much of the WSH now unless security is set to low or the user
has chosen to allow a specific application to use "unsafe
expressions". The gaping security holes that still do exist
(like the ones a gazzillion spyware apps use) don't seem to
depend on WSH.

Well, setting security to low opens up gaping security holes.

Exactly - so if WSH is now only vulnerable if you do that, who
cares, because the system is wide open anyway.

Eh? My recommendation has always been to *disable* the WSH in the
first place. And any security-conscious sysadmin is not going to let
you run your WSH-using app on her network if you're requiring the
lowering of security levels.

Maybe it's the case that there are virtually no such administrators,
but I wouldn't count on that continuing forever.

The WSH should be re-engineered to be able to run safely in
high-security environments. If it's not, it's worthless, as using
it requires you to make your system vulnerable.

Isn't that what they did by blocking "unsafe" expressions?
Nothing can now use the WSH to get to the file system, even for
read-only unless the user grants permission to execute unsafe
expressions. Whether it's now safe or not, I get the impression
you'd never believe that it was so long as it is called WSH (and I
won't say for sure that you're wrong in that).

The continuity of the name indicates a continuity of codebase. You
can't bolt security onto a 2nd- or 3rd-generation system -- it has
to be engineered into the basic system, and the fact that the SWH is
still a revision to a system that wasn't originally designed to be
secure means that it can't possible be made secure without
completely revising the basic design of it.

Making the "scurity" prompt-based, as in "Do you want to run this
script?" is no security at all. It annoys the users who quickly
start ignoring the prompts, which they wouldn't understand in the
first place.

And if WinXP SP2 and Win2K3 Server block access to the file system,
then the file-system object is of no use in an Access app, and it's
one of the chief components that people have been advocating as a
useful adjunct to Access.

3. Many core microsoft libraries seem to now make the
assumption that WSH is also available. For instance, show me a
way to stream MSXML SAX output to a file on disk without FSO.
You can do it to a stream in memory (which kinda defeats the
purpose) using an ADO stream, or you can stream to http in ASP,
but neither of those will get you a stream directly to a local
file.

Many MS products assume that IE is your default brwoser, or force
you to use it. That this is so does not make it a good idea.
Indeed, it's extremely bad design on MS's part, and to me, screams
of anti-competitive business practices.

I don't see the WSH as being in that category. WSH is a library,
just like DAO is a library, that keeps everyone form having to
choose to reinvent the functionality within it or go without.

If it had been implemented the way it should have been, I'd use it.

But it wasn't designed with security in mind, so it's not a viable
candidate for use in an application, in my opinion, the same way
that nothing that depends on IIS is viable.

4.
Dictionaries are mindbogglingly useful, but VB doesn't have one,
and if you roll your own, you have to debug it yourself, and you
make your app harder to maintain. WSH has a good dictionary
object.

Dictionaries? What are you talking about? And why would I need
one?

I keep finding that my code is easier to maintain the more I use
constructs like collections and dictionaries, and move away from
nested logic. A dictionary is, in memory, much like the
environment is in batch files. It's a collection of values with
names, in which new elements are transparently created when
assigned if they don't already exist, and a default value is
returnd for a non-existent element. You can also retrieve a list
of the names in a dictionary, unlike the names list in VBA
collections which is write-only for some really dumb reason.

Sounds like a class object to me. Why would I need an external
library to do that?

I'm not saying I'm sure you're wrong, but I think the above are
some good reasons to consider the answer less than black or
white.

It's an unsafe, insecure pile of garbage. It was badly designed
and implemented from the beginning and MS should be ashamed of
themselves for putting out such a poorly thought-out scripting
engine.

If you're talking about the fact that it's callable from Web page
scripts - yeah, I'm right with you. . . .

No, I"m talking about the entire implementation from beginning to
end. If it had been properly designed it could have offered the same
functionality without being a gaping security hole.
. . . As a library of really useful
coding tools, I don't see that it has any problems. I know your
issue is that whether it is useful or not, . . .
I have not yet seen anyone make a case for anything in it that is
indispensible. I've seen precious few arguments for even marginal
utility, except for the FSO, which I don't see as necessary at all
(just, perhaps, more convenient). Security issues aside, I don't
think introducing outside dependencies is worth that convenience.
. . . it is unsafe to have it
around. I'm not sure that's still true, and I'm not sure it's
not, but It seems like you're still in knee-jerk mode and have not
considered that things may be different than when you formed your
initial opinion.

You can't bolt security on top of an existing technology. It has to
be engineered into the innards of that product.

I'm not sure *any* scripting enging could run safely on Windows
because there isn't any sandbox for it to run in. Microsoft employs
many very smart people and they should have been smart enough to
know that no scripting engine should ever be implemented outside a
sandbox.

But they did it anyway, and no amount of "security" prompts is going
to fix that fundamental and fatal flaw.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Steve Jorgensen]

On Mon, 29 Aug 2005 13:46:18 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

....

Yeah, and I keep finding myself making my own wrappers around the
VB file statements or around API calls to correctly deal with file
attributes, etc. Also, since Dir has a global context, you have to
make sure you don't do nested Dir calls to try to navigate a
directory tree.
Well, any tool allows you to make mistakes, so I don't see that as
much of an advantage incomparison to the downside of introducing an
outside dependency, with the uncertainty that comes from not knowing
if it will be installed, as well as MS's habit of noncompatible
component versions.

The point is that FSO is much better designed and encapsulated, and it's a
commonly used standard. Of course, one has to weigh that against the safety
of using the library, it'm just not convinced if it is or isn't now safe.

For things that Access can't do by itself, it's a harder question.
But I strongly doubt that there's any common area of functionality
that one would want to include in an Access app for which there is
not some alternative to using the WSH.

Streaming to files, and dictionaries are 2 that come to mind. Not
every app needs these, but many do. The question for those is use
the WSH, or roll your own. In the case of streams, I don't know
how to work around it shor of writing custom C++ code.

I don't even know what a stream is, except the basic definition, and
don't know why I'd ever need one. I can write data to files already
without outside components.

Streams are ways of hooking the output of one process to the input of another,
similar to pipes. The nice thing is that something that accepts or produces a
stream doesn't have to know if the source/destination is another process in
the same application, a file on disk, a post message coming from a Web form,
or whatever. It makes code more loosely coupled, and more reusable. Of
course, this only works it everything shares the same implementation of a
stream interface, hence IStream.
Of course, you seem to think XML is useful, and I don't, except as
an export/import format. And that functionality should be supported
natively in Access, not through outside components that are not part
of Access.
I have only a couple of applications that make use of XML. My point is that I
don't have to look hard to find a library that expects to use IStreams for
something that would frequently need to be an input from or output to a file.
I only expect that situation to grow from here on.

....

Well, setting security to low opens up gaping security holes.

Exactly - so if WSH is now only vulnerable if you do that, who
cares, because the system is wide open anyway.

Eh? My recommendation has always been to *disable* the WSH in the
first place. And any security-conscious sysadmin is not going to let
you run your WSH-using app on her network if you're requiring the
lowering of security levels.

Maybe it's the case that there are virtually no such administrators,
but I wouldn't count on that continuing forever.

I don't think you're getting what I'm saying. I'm saying if WSH is now only
insecure if you lower the security level, that's not a security hole.

The WSH should be re-engineered to be able to run safely in
high-security environments. If it's not, it's worthless, as using
it requires you to make your system vulnerable.

Isn't that what they did by blocking "unsafe" expressions?
Nothing can now use the WSH to get to the file system, even for
read-only unless the user grants permission to execute unsafe
expressions. Whether it's now safe or not, I get the impression
you'd never believe that it was so long as it is called WSH (and I
won't say for sure that you're wrong in that).

The continuity of the name indicates a continuity of codebase. You
can't bolt security onto a 2nd- or 3rd-generation system -- it has
to be engineered into the basic system, and the fact that the SWH is
still a revision to a system that wasn't originally designed to be
secure means that it can't possible be made secure without
completely revising the basic design of it.

That's true of a tighly intertwined and massively complex codebase like IE or
MS Word, but WSH is nothing more than a bag of relatively loosely coupled
utilities. Microsoft's error was in treating all of it as rougly equal and
making it accessible to Web page scritps. That doesn't seem like a
fundamental and irreparable problem to me. it would be like saying that
Harleys used to be crap, therefore they must still be crap because they're
still motorcycles, and they're still made by Harley. A friend of mine tells
me that logic would not be correct.
Making the "security" prompt-based, as in "Do you want to run this
script?" is no security at all. It annoys the users who quickly
start ignoring the prompts, which they wouldn't understand in the
first place.
See my end-reply on this point.
And if WinXP SP2 and Win2K3 Server block access to the file system,
then the file-system object is of no use in an Access app, and it's
one of the chief components that people have been advocating as a
useful adjunct to Access.
That one doesn't fly. The problem is that Access' normal functioning is a
security hole as much so as anything in WSH. You can't run any meaningful
Access application on your system unless you trust it not to run amok. If you
do try to run any ordinary Access application with "unsafe" expressions
blocked, it fails almost immediately, WSH or no WSH. If you don't block
unsafe expressions, Access can do just as much damage without WSH as it can
with WSH, it just does it in a more object oriented way with WSH <g>.

....

I don't see the WSH as being in that category. WSH is a library,
just like DAO is a library, that keeps everyone form having to
choose to reinvent the functionality within it or go without.

If it had been implemented the way it should have been, I'd use it.

But it wasn't designed with security in mind, so it's not a viable
candidate for use in an application, in my opinion, the same way
that nothing that depends on IIS is viable.

Again, I don't see the contents of the WSH libraries as being so dense that it
could amount to an unpluggable hole. Just because MS didn't think before
leaving it wide open the first time out doesn't mean it was ever fundamentally
insecurable.

...

I keep finding that my code is easier to maintain the more I use
constructs like collections and dictionaries, and move away from
nested logic. A dictionary is, in memory, much like the
environment is in batch files. It's a collection of values with
names, in which new elements are transparently created when
assigned if they don't already exist, and a default value is
returned for a non-existent element. You can also retrieve a list
of the names in a dictionary, unlike the names list in VBA
collections which is write-only for some really dumb reason.

Sounds like a class object to me. Why would I need an external
library to do that?

I have made a class library to do that, and the way it has to be implemented
in VBA is a real mess. For one thing, I have to use the save as text kludge
if I want iterators, and iterators implemented in VB are highly kludgey,
themselves. Finally, since I sure don't want to write my own hash lookup
algorith, I have ot use 2 VBA collections to implement the dictionary, storing
each key value in memory 3 times, and catch errors to see of items are in the
collection or not. In short, my best code for this smells bad.

The dictionary object in WSH is written and optimized in C, it's used widely
enough that we know it behaves as expected, and if I want to make library
functions that can receive and return dictionaries, other applications won't
have to include and trust my unique dictionary object, or perhaps translate
between 2 or more different custom dictionaries from different external
libraries. No, that's not an issue I actually run into on a regular basis,
but conceptually, it contributes to the smell factor. So - I end up asking
whether that or WSH smells worse, and WSH doesn't seem to smell quite as bad
as it used to.

....

If you're talking about the fact that it's callable from Web page
scripts - yeah, I'm right with you. . . .

No, I"m talking about the entire implementation from beginning to
end. If it had been properly designed it could have offered the same
functionality without being a gaping security hole.

What about its design is fundamentally hard to secure? What different sort of
design that includes utilities for file maintenance would be more secure? it
looks to me like securing it was little more than saying untrusted sources
can't make file system calls or registry calls.

....

. . . it is unsafe to have it
around. I'm not sure that's still true, and I'm not sure it's
not, but It seems like you're still in knee-jerk mode and have not
considered that things may be different than when you formed your
initial opinion.

You can't bolt security on top of an existing technology. It has to
be engineered into the innards of that product.

I don't agree with that as a blanket statement. I do agree with it as a
general statement. WSH is not an full-fledged application, though, with vast
interdependencies among its components. it's just a fairly flat utility
toolkit.
I'm not sure *any* scripting enging could run safely on Windows
because there isn't any sandbox for it to run in. Microsoft employs
many very smart people and they should have been smart enough to
know that no scripting engine should ever be implemented outside a
sandbox.
A sandbox is nothing more than an app that has no calls in it that can do
unsafe things. A set of libraries in which the safe ones are accessible, and
the unsafe ones are not amounts to a sandbox, does it not?
But they did it anyway, and no amount of "security" prompts is going
to fix that fundamental and fatal flaw.

I think MS severely bungled the security prompts thing, but I think WSH is the
least of that worry. The problem is that, in order to get things done, users
have to run programs that can do things on their behalf that would be unsafe
if done by programs the user did not choose to run or programs that lie about
what they do.

By locking out anything the user could hurt themselves with short of a user
confirmation, MS is training users to accept any message about anything
wanting to do anything. Obviously I'm preaching to the choir on this one, but
removing WSH because it has file system calls in this environment is roughly
like removing VBA because it has file system calls. Either way, you're
blocking what the user is trying to do more often than you're blocking a
malicious program.

To continue the confirmation rant, do you know that in the default, full
security mode, I can now create a new MS Access file on my drive with
right-click, New -> MS Access Application, double-click the file, and be told
that I can't open it because it might be insecure? Useful, eh?

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:td********************************@4ax.com:

I don't think you're getting what I'm saying. I'm saying if WSH
is now only insecure if you lower the security level, that's not a
security hole.

Sorry, but I haven't heard anything that indicates to me that WSH is
not "safe" with default security settings. You can't make secure
something that is fundamentally insecure at root simply by limiting
the operations it can do without user permission.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:td********************************@4ax.com:

Microsoft's error was in treating all of it as rougly equal and
making it accessible to Web page scritps.

No, Steve, that's not Microsoft's error.

The ILOVEYOU virus is the illustration of what was wrong with WSH.
THe vulnerabilities of WSH have zilch to do with web scripts --
client-side VBScript is ont used by anyone at all, and if it is,
it's executed in process by IE (and no other browser), not by
calling the WSH.

It's no wonder you downplay the security flaws of the WSH if you
misidentify the basic security vulnerability that it represents.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:td********************************@4ax.com:

[me:]

And if WinXP SP2 and Win2K3 Server block access to the file
system, then the file-system object is of no use in an Access app,
and it's one of the chief components that people have been
advocating as a useful adjunct to Access.

That one doesn't fly. The problem is that Access' normal
functioning is a security hole as much so as anything in WSH. You
can't run any meaningful Access application on your system unless
you trust it not to run amok. If you do try to run any ordinary
Access application with "unsafe" expressions blocked, it fails
almost immediately, WSH or no WSH. If you don't block unsafe
expressions, Access can do just as much damage without WSH as it
can with WSH, it just does it in a more object oriented way with
WSH <g>.

If there were as many potential Access exploits as there are
postential VBScript exploits, you might have a point, but THERE
AREN'T.

The reason it's safe to lower security to run Access apps is because
there is ABSOLUTELY NO REAL-WORLD THREAT from doing so.

That is patently *not* the case with WSH, and that's why it's
prudent to never lower security for it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:td********************************@4ax.com:

A sandbox is nothing more than an app that has no calls in it that
can do unsafe things.

Sorry, but that's simply not true. A sandbox is a virtual machine in
which code of any kind executes and is prohibited from doing things
that the virtual machine does not allow it to do. This conventially
include interaction with outside objects and, particulary, the file
system.

Once you've built a sandbox, you can build functionality into it to
allow relative levels of restriction on the processes running in the
sandbox.

But the lame security levels is not a sandbox, and not even close to
it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc