4

Recently I have been asked to do some maintenance on a VB6 application. This involves some file IO. I find the IO operations offered by referencing the windows script host and using the FileSystemObject a lot friendlier than the IO operations that come with VB6.

But will this cause problems because of security issues, or because of the fact that the script host will be disabled on some users' computers?

Update (aug 20, 2012): Since asking this question we have encountered the problem of a non functional scrrun.dll three times among 3000 customers. We had to fix these manually through remote support. It seems that sometimes a virusscanner is to blame.

Dabblernl
  • 15,831
  • 18
  • 96
  • 148
  • I haven't seen your hypothetical example emerge as a practical problem in the real world. But if WSH is disabled, that would certainly prevent WSH scripts from executing. – Robert Harvey May 16 '10 at 22:54
  • Could rewriting the application in a modern language be considered justified maintenance? – Matti Virkkunen May 16 '10 at 22:54
  • The Scripting Runtime is entirely separate from WSH. The native I/O statements can be considerably more powerful than using the FSO however. – Bob77 May 17 '10 at 06:11
  • I've seen virus scanners disable / interfere with scrrun.dll. From memory, it was a kapersky virus scanner – MarkJ Aug 21 '12 at 20:24

3 Answers3

4

As Robert Harvey mentioned in his comment, this isn't usually a problem in practice. It's possible that the scrrun.dll may either not be installed or is not registered correctly on a given machine though. We've encountered both scenarios when installing our own VB6 application on customer's machines.

As for scripting being disabled, we've actually run into this problem with other applications (such as Microsoft InfoPath), and got around the issue by having the InfoPath form (which needed to do some file I/O) call out to a VB6 DLL that used the WSH FileSystemObject, so if anything, you can actually work around script security problems by using the library in conjunction with VB6. As far as I know, WSH security settings apply specifically to actual scripts, not to programs that happen to use components from the scripting runtime.

In fact, you can completely disable the Windows Scipt Host on your machine, and still access the WSH components, such as FileSystemObject, from a VB6 application.

Mike Spross
  • 7,999
  • 6
  • 49
  • 75
  • +1 I too have encountered customer machines where `FileSystemObject` didn't work, presumably because of paranoid IT departments – MarkJ May 17 '10 at 13:02
  • @MarkJ: As I mention in my answer, disabling WSH won't prevent you from using `FileSystemObject` in a VB6 application, since those settings only affect whether you can run scripts. Interestingly, this article from Microsoft (http://technet.microsoft.com/en-us/library/cc875829.aspx) seems to indicate that the way to disable access to `FileSystemObject` specifically is to simply unregister `scrrun.dll` on the machine. There doesn't seem to be a dedicated setting or permission to turn it on or off. – Mike Spross May 18 '10 at 03:22
  • For our own application, certain components are dependent on `scrrun.dll` for either the `FileSystemObject` or `Dictionary` classes, and since we are trying to phase out the VB6-based products, I doubt we will refactor them to use native methods. In cases where `scrrun.dll` is unregistered, we simply re-register it, and if anyone asks, we explain that our application needs it. So far the IT departments we've encountered haven't been paranoid enough to tell us no ;-) – Mike Spross May 18 '10 at 03:27
  • You are correct in that if you choose to disable WSH and you follow the approved Microsoft way to do that, it doesn't affect `FileSystemObject`. We have encountered a couple of customers with IT departments who like to go further. It's rare but they are a pain to sort out. We distribute thousands of copies of our installation disks worldwide - it can be hard to get the IT department to even talk to us, let alone register a DLL. – MarkJ May 18 '10 at 09:07
3

File IO in VB has always had a bit of syntactic "oddness" due to its inheritance from Q/BASIC but its simple to use if you stick to direct read/writes (avoiding Line Input/Write/Get). Using the native methods will be faster than the FSO and avoid any dependency issues, no matter how rare they may be.

Another consideration is that if you want to perform binary file IO you will have to use the native methods anyway as the FSO is text only.

Alex K.
  • 171,639
  • 30
  • 264
  • 288
3

I have occasionally encountered customer machines where FileSystemObject didn't work, presumably because of paranoid IT departments disabling it somehow. I now try to avoid FileSystemObject if possible.

You can usually replace the FileSystemObject with native VB6 code or API calls direct to the Windows API. For example Karl E Peterson's excellent VB6 website has some great objects written entirely in VB6.

Some examples

Community
  • 1
  • 1
MarkJ
  • 30,070
  • 5
  • 68
  • 111