A question about FileSystemObject

I'm using the FileSystemObject in a client-side script that is
intended to be used in Internet Explorer 5.5 or later only on an
intranet.

I developed the script on a Win2K machine that has WSH installed on
it. I actually did not expect it to work on other computers but was
surprised to find out that it did (on 3 machines so far - Win2K and
NT4).

So, my question is: WHERE is FSO (that is, which DLL)? Is it part of
Windows? Or is this working only because Visual Basic is installed on
all of the computers I've tried it on so far?

Michael
Mon Jul 07 10:39:42 CDT 2003

From the OLE browser it appears to be the scripting runtime dll -
scrrun.dll. Look on technet to see the supported versions of Windows, I know
it is native in 2K and XP but I am not sure about NT4.

--
Regards,

Michael Holzemer

Please reply in newsgroup
*************************************************


"Martin" <martinvalley@comcast.net> wrote in message
news:d62jgvo5phav74f397djkkq4jqkv62vejc@4ax.com...
> I'm using the FileSystemObject in a client-side script that is
> intended to be used in Internet Explorer 5.5 or later only on an
> intranet.
>
> I developed the script on a Win2K machine that has WSH installed on
> it. I actually did not expect it to work on other computers but was
> surprised to find out that it did (on 3 machines so far - Win2K and
> NT4).
>
> So, my question is: WHERE is FSO (that is, which DLL)? Is it part of
> Windows? Or is this working only because Visual Basic is installed on
> all of the computers I've tried it on so far?

Tom
Mon Jul 07 10:48:32 CDT 2003

The FSO is supplied by scrrun.dll that is loaded as a
standard part of WSH loaded by W2k and by IE versions 5.0
and later (amoung other ways).

Tom Lavedas
===========

>-----Original Message-----
>I'm using the FileSystemObject in a client-side script
that is
>intended to be used in Internet Explorer 5.5 or later
only on an
>intranet.
>
>I developed the script on a Win2K machine that has WSH
installed on
>it. I actually did not expect it to work on other
computers but was
>surprised to find out that it did (on 3 machines so far -
Win2K and
>NT4).
>
>So, my question is: WHERE is FSO (that is, which DLL)? Is
it part of
>Windows? Or is this working only because Visual Basic is
installed on
>all of the computers I've tried it on so far?
>.
>

Joe
Mon Jul 07 12:10:44 CDT 2003

Hi,

"Martin" <martinvalley@comcast.net> wrote in message
news:d62jgvo5phav74f397djkkq4jqkv62vejc@4ax.com...
> So, my question is: WHERE is FSO (that is, which DLL)? Is it part of
> Windows? Or is this working only because Visual Basic is installed on
> all of the computers I've tried it on so far?

You've got your answer from the other posters. Just wanted to add that, if
you're interested in tracking COM object DLLs/OCXs/CPLs/etc., as well as
their methods and properties, you might want to take a look at Mark Pryor's
free TLViewer utility. Very handy little tool.

http://mysite.verizon.net/res1ur2j/tlviewer.htm

Joe Earnest

Martin
Mon Jul 07 13:07:14 CDT 2003

Michael, Tom, Joe -

Thanks for the responses.

The presence of scrrun.dll serves my purposes very well. But doesn't
that render the "security" of I.E. rather useless? I've read a number
of messages here that I.E. (in DHTML) cannot mess with the user's
files (other than cookies). That may be true as far as DHTML is
concerned but if the page designer can so easily put in a script that
can do anything it wants, what's the difference?

BTW, this is just a rhetorical question - I'm not expecting answers.

Tom
Mon Jul 07 17:55:44 CDT 2003

No, security is not really compromised as the security
model will generally keep the FSO (and similar 'unsafe for
scripting' objects) from being created UNLESS the USER
knowingly lowers the level. The page designer cannot do
it. At least, that's the theory.

That's what I meant when I said it could be done, but
would lead to security issues. The issue being that the
user would need to accept the lower security before the
object could be created. There are some very limited
intRAnet situations where such security issues might be
worth it (specific named trusted sites behind firewalls).
It's clearly NOT a good idea in the general Internet sense.

Tom Lavedas
===========

>-----Original Message-----
>Michael, Tom, Joe -
>
>Thanks for the responses.
>
>The presence of scrrun.dll serves my purposes very well.
But doesn't
>that render the "security" of I.E. rather useless? I've
read a number
>of messages here that I.E. (in DHTML) cannot mess with
the user's
>files (other than cookies). That may be true as far as
DHTML is
>concerned but if the page designer can so easily put in a
script that
>can do anything it wants, what's the difference?
>
>BTW, this is just a rhetorical question - I'm not
expecting answers.
>.
>