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

On Wed, 06 Jul 2005 02:52:21 GMT, "Michael D. Ober"
<obermd.@.alum.mit.edu.nospam> wrote:

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

The problem is that the vast majority of Windows machines are not
properly maintained.

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

Some people physically delete it !

>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'm genuinely interested to know what those things are
- most things that can be done with APIs in C can be done in VB

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

We certainly agree on that


<snip>

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

It was not when CP/M was written

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

That's probably true - they also put in ERA as well as DEL

<snip>

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

Sounds a nightmare, I can't envisage a language without simple
procedural code.

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

I don't agree, CrLf is much more widely understood
It is not unreasonable to assume that a coder who wants to read *nix
files is likely to be capable of doing a simple conversion.

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

There is, but it involves manually closing and re-opening the files.

Under DOS it could be done at Int 21h level by creating a duplicate
file handle and then closing one of the clones.

I would say that the problem is really down to DOS
- but it would be nice if they had a Flush/Commit function
- also to be able to get the 'real' file handle (as one once could)

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

To be honest, in the MSDOS days we just used the underlying file
handling stuff rather than Basic for anything non trivial.

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

I would be really interested in the FSO features are impossible to do
in VB with APIs


.

Relevant Pages

  • Re: "scrrun.dll" not compatible in different languages?
    ... Any OS that supports scripting must be properly locked down or the scripting ... some features in FSO that are nearly impossible to ... The fact that VB 6 doesn't support ... The fact that there is no way to write a decent language translator from VB ...
    (microsoft.public.vb.general.discussion)
  • Re: Remote Scripting
    ... but my guess is that CE does not support Remote ... There's tons and tons of stuff on Windows XP/2003 we don't do and it's ... Do you need remote scripting in the first place? ...
    (microsoft.public.windowsce.app.development)
  • Re: GetFiles?
    ... >>But note that the Filter method is not supported for any other OS ... >>than Windows XP and Windows 2003 Server. ... Microsoft VBScript runtime error: Object doesn't support this ... -- torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway Administration scripting examples and an ONLINE version of the 1328 page Scripting Guide: ...
    (microsoft.public.scripting.vbscript)
  • Re: textfile mit bin0 Zeichen einlesen
    ... Das FSO ist eine Funktionalität der Scripting Runtime und nicht ... aber schon vor Erscheinen von VB6 Bestandteil des Windows Scripting ... Warum erfordert das Setup einen Neustart von Windows? ...
    (microsoft.public.de.vb)
  • Re: [ASP] Read file on windows ce
    ... Don't apologize for your English, ... The only way to make this work on Windows CE is to write your own ActiveX ... object to implement FSO. ... > How can I read a file without FSO support? ...
    (microsoft.public.windowsce.embedded.vb)