Re: "scrrun.dll" not compatible in different languages?



"J French" <erewhon@xxxxxxxxxx> wrote in message
news:42cb2f25.69809806@xxxxxxxxxxxxxxxxxxxxxxx
>
> On Tue, 05 Jul 2005 12:06:50 GMT, "Michael D. Ober"
> <obermd.@.alum.mit.edu.nospam> wrote:
>
> <snip>
>
> >> I suppose you know that the FSO will simply not work on well set up
> >> machines, since it is part of VB Scripting (AKA Viruse Gateway) canny
> >> administrators disable it.

Any OS that supports scripting must be properly locked down or the scripting
will become an avenue for viruses. The very first internet worm (google
Robert Morris Worm) used a hole in the debug configuration of the Unix
sendmail program along with the native scripting in Unix to recompile and
propagate itself. It wasn't the scripting that was the problem - it was the
fact that the default installation of sendmail at the time was debug mode.
Those sites that had turned off the debug mode weren't infected. The same
situation exists today with Windows. There is an abnormal fear of windows
scripting because it is extremely powerful and if you don't properly secure
your system, it can become an avenue of attack.

Even with VB Scripting disabled, the scrrun.dll file is, in many cases,
still available. There are two major problems with this file. First, it
doesn't appear on all versions of Windows. Second, even when it does
appear, it doesn't have a consistent interface. Unfortunately, there are
some features in FSO (and also wscript.exe) that are nearly impossible to
implement in VB 6 without FSO or another file system interface. The API
calls to do some of this stuff, while easy in C++, are nearly impossible to
get right in VB6. I wholehearteldy agree that if there is a native VB
method or function, use it instead - it will almost always be faster and is
far less likely to have platform dependent compatiblitiy issues.

>
> >Some do, some, such as myself, use other methods to block viruii. I
haven't
> >had a virus get lose on my network in over 4 years and I have VB
Scripting
> >turned on - it's simply a matter of have a good virus scanner that's
updated
> >daily (not weekly as most AV companies do) along with appropriate network
> >security policies in place.
>
> Yes, well your programs may well not work under other regimes
>
> >> However, since you seem to have some peculiar ideas about what should
> >> and what should not be supplied by a language,
>
> >Actually, this group has helped me on numerous occassions and I have also
> >provided assistance here. The fact that VB 6 doesn't support
multi-platform
> >file IO is a flaw (and shows that VB's roots are in DOS)
>
> It shows nothing of the sort
> - VB's roots go back well before DOS
> - CP/M - Apple - Commodore - all had versions of BASIC from M$
>

The original PC-DOS 1.0 (MS-DOS 1.1 was released with the first PC clones)
was a repackaged version of Seatle DOS, which in turn was based on CP/M. In
all cases, the environment was a single, isolated, machine. My statement
that VB 6 doesn't support multi-platform file IO is based on the fact that
the single most common end of line marker on mini-computers is a single LF.
IBM mainframes were the primary generators of CR as a end of line marker,
which is why Microsoft chose to support CR as well as the CP/M standard of
CRLF. Gates and Allen had to support CR in order to sell PC-DOS and
ROM-BASIC to IBM.

> >> I suggest that you
> >> migrate to VB.NET
> >> - we obviously cannot help you here
>
> >This and other VB newsgroups have been useful over the years, much more
so
> >than TechNet. I have also posted solutions here.
>
> >I will be once VB 2005 is released. After using BETA 2 for some
projects, I
> >find the .NET class library to be extremely helpful. However, I have no
> >plans to migrate existing code as there is no real up-translator for VB 6
to
> >VB 2005. VB 6 is procedural with object support while VB 2005 is object
> >oriented with procedural support.
>
> It would be very funny if it did not have procedural support

I have worked with languages that don't have procedural support. They can
be extremely powerful (PROLOG) and extremely infuriating (SuperNova 4.1.1).
Both are purely Object Oriented.

>
> >This fundamental difference makes it
> >nearly impossible to write a good language translator. The provided
> >translator is useful for short segments of code however, which eases the
> >transition process.
>
> Go back and look at the OP's original post
>
> He was getting grief from using the FSO
> - your reply was that VB is rubbish because it's Line Input does not
> support #10 delineated text files.
>

My reply is that the fact that Line Input doesn support Unix style text
files is a design flaw in VB 6 - nothing more, nothing less. By the way,
this isn't the only oversight in VB 6's file handling. There is also no way
of flushing the file buffers under program control without use the API to
perform all your file IO.

The fact that there is no way to write a decent language translator from VB
6 to VB 2005 (skip the weak sibling VB.Net 1.x) is irrelevant to the fact
that VB 6 has a design flaw in file handling.

OPs real problem is that he was using FSO for features that are built into
VB 6, thus forcing his code to unnecessarily handle compatibility issues
across different versions of Windows. Unfortunately, there are a small
number features of FSO and WScript that simply aren't available in any other
method to the average VB 6 developer.

Mike Ober.



.

Relevant Pages

  • Re: "scrrun.dll" not compatible in different languages?
    ... >Any OS that supports scripting must be properly locked down or the scripting ... >situation exists today with Windows. ... >implement in VB 6 without FSO or another file system interface. ... >that VB 6 doesn't support multi-platform file IO is based on the fact that ...
    (microsoft.public.vb.general.discussion)
  • Re: File.datecreated doesnt change
    ... I have a VBScript book from 1997 that presents VBS as ... being just a new language for webpage scripting. ... So at that point there was no CreateObject, no FileSystemObject, ... The O'Reilly VB6 reference book includes all of the FSO ...
    (microsoft.public.scripting.wsh)
  • Re: Inline frames, die, die, die (aka please help!)
    ... The reason my preference is the Windows platform and for scripting ASP/VBScript, ... ASP/VBScript on Unix/Linux, but you can not use Access or Excel as a data source. ... support here in this newsgroup, then you will find for PHP and any other scripting language. ...
    (microsoft.public.frontpage.client)
  • Re: Create folder from within Access VB
    ... a program to wreak havoc from a batch file. ... using the File Scripting Object in an Access app. ... of a single reason to use that abomination (FSO) in an Access application. ... Set objTemp = fs.CreateFolder ...
    (microsoft.public.access.formscoding)
  • Re: Create folder from within Access VB
    ... The use of FSO in a scripting environment is fine as this is what it was ... Set objTemp = fs.CreateFolder ...
    (microsoft.public.access.formscoding)