0

As mentioned here, this component became a part of the windows operating system. However VB6 runtime may not be supported on Windows 8 and beyond. So I'm afraid this component may be going away too (even tho it is a part of windows OS). We are going to be attempting to utilize it via a C# consumer using Interop.MSScriptControl.dll, very soon. I've even seen some folks have issues with it on Windows7. Has anyone had success running it on Windows 7 and Windows Server 2008 R2? Does anyone think it will still work on Windows 8? Currently compiling for x86 32-bit CPU with thought that 64 bit system would use WoW64 to use it. Thanks!

Community
  • 1
  • 1
Scott
  • 5
  • 1
  • 2
  • I wouldn't expect anyone to be able to answer this with any degree of certainty. Maybe you should look to evolve your solution regardless, look to see if what you want can be achieved with a combination of HTML5, elevated OOB Silverlight and PowerShell. – slugster Nov 05 '10 at 21:40
  • 2
    What does msscript.ocx have to do with VB6? – Gabe Nov 07 '10 at 04:03
  • Gabe: Because msscript.ocx documentation is usually linked directly from VB6 documentation (see http://support.microsoft.com/kb/184739), this has proven on several occasions to be a point of contention. While, Visual Basic and VBScript and ScriptControl are all distinctly different, they are - in my experience - lumped together. – jveazey Nov 07 '10 at 05:41
  • Microsoft have now announced the VB6 [runtime is supported on Windows 8](http://msdn.microsoft.com/nb-no/vbrun/ms788708%28en-us%29.aspx). – MarkJ Feb 14 '12 at 16:56

1 Answers1

3

The ScriptControl (msscript.ocx) is specific to 32bit Windows and is specific to older languages that cannot interact with the CLR/.Net. It continues to exist on Windows 7 in C:\Windows\System32 for 32bit and C:\Windows\SysWOW64 for 64bit. With Microsoft slowly phasing out 32bit portions of the Windows OS, this will eventually go away, too. When that may happen is anyone's guess, though.

There is a .Net equivalent though that can be used in 32bit and 64bit flavors of the Windows OS.

.Net 1.1 and up provides this functionality through Visual Studio for Applications. An example project for this is on CodeProject named VSA Scripting in .NET.

With .Net 3.5 this functionality has been deprecated in favor of Powershell using the System.Management.Automation namespace. An example project for this is on CodeProject named How to run PowerShell scripts from C#.

jveazey
  • 5,398
  • 1
  • 29
  • 44
  • 4
    Considering that most 16-bit code continues to work on 32-bit Windows, it's hard to imagine that any 32-bit programs will be phased out in less than a decade or two. – Gabe Nov 07 '10 at 04:12
  • I agree wholeheartedly. 32bit code is definitely around to stay for a long time, but Microsoft is slowly phasing out certain libraries in newer OS's. The VB5 runtime has been already been removed from Windows starting with Windows 7/2008 R2. Killing the 32bit portion of the OS as a whole will not happen for some time, but secondary libraries such as VB runtimes or VBScript/JScript will probably happen within the next version or two of Windows. – jveazey Nov 07 '10 at 04:33
  • It's not exactly true that it cannot interact with .Net/CLR. I've used this control in a few .Net applications and I can pass .Net objects to the engine / have the engine call .Net code on those objects essentially allowing for me to create scripting commands that execute managed code. That meets my definition of being able to interact. – b.pell Jul 05 '12 at 14:55
  • @b.pell Agreed, but I wan't trying to say that CLR/.NET cannot interact with MSScript.ocx. I was saying that older languages - such as Visual Basic 6 - which do not have access to CLR/.NET, must use MSScript.ocx for embedding scripting functionality into their program. – jveazey Jul 06 '12 at 00:44