Closed Bug 41274 (vbscript) Opened 24 years ago Closed 12 years ago

Add VBScript engine for Mozilla

Categories

(Core :: General, enhancement)

Product:
Core
Component:
General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: zuperdee, Unassigned)

References

Details

(Keywords: helpwanted) 

This bug is kind of a spin-off of 40952.

Basically, it would be interesting if Mozilla supported other scripting
languages besides JavaScript, like VBScript.  Not essential, I'll agree, but it
would be interesting.
Hmm...  Now if only someone could come up with a VBScript engine, is it possible
for it to be plugged into Mozilla the same way JavaScript is?
Keywords: helpwanted
*** Bug 47161 has been marked as a duplicate of this bug. ***
It has just occurred to me that GNOME Basic claims to be Visual Basic
compatible.  Therefore, that may be a good base to start from, if one wanted to
start making an open source VBScript engine for Mozilla.  Hmm...  Anyone?
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → Future
leger is no longer @netscape. changing qa contact to component's default
QA Contact: leger → chofmann
*** Bug 146690 has been marked as a duplicate of this bug. ***
The link for GNOME Basic is http://www.gnome.org/projects/gb/ if anyone is
interested.  As I say, this might be a good starting point for creating a Visual
Basic engine that could be plugged into Mozilla.  Also, I am beginning to think
there may be far more of a market for this feature today than there was at the
time I filed this, since 1) There are a growing number of sites (other than
Microsoft) using VBScript today, like the one cited in bug 146690, and 2) the
".NET initiative" is rapidly gaining traction (of which VBScript is one
component, as I understand it).

Therefore, I'd now *REALLY* like to see this implemented.
VBScript is unhealthy.
Component: Tracking → Browser-General
Brendan, in the unlikely event that someone were to produce a patch that would
add support for VBScript, would it be accepted or rejected? (IOW, WONTFIX or not?)
Whiteboard: Propose WONTFIX
*** Bug 153668 has been marked as a duplicate of this bug. ***
Maybe Moz could just use Windows' built-in vbscript engine?
as with most mozilla rfes, we prefer cross platform implementations (see also
NTLM).  This bug is filed for a cross platform implementation, so if you want to
file or find a bug to add support for windows activescripting you are free to
use it to develop a patch.

As for Gnome Script, that's GPL so i don't think we can realistically use it for
a while.
Hmm...  Any chance of talking to the GNOME Basic author, and asking if he'd be
willing to dual-license it under the MPL and GPL?  Would that help?  Just a
thought...
In that case I suggest changing the title to "Add cross-platform VBScript engine
for Mozilla".

Is someone working on this?
Alias: vbscript
Summary: VBScript support would be neat to have! → Add VBScript engine for Mozilla
Whiteboard: Propose WONTFIX
AFAICT, there would be at least two general issues here.

1. We'd need an engine (XP or otherwise).
2. We'd need to start handling language="vbscript". That would require accepting
said language tag *and* handling the language itself; the latter part seems to
be the hardest part.?
Yeah, the content code is not set up to handle new scripting language types
smoothly.  Cc'ing jst.  I expected the ActiveState guys to make Python work, but
they never needed it -- they only needed PyXPCOM (the Python "XPConnect").

/be
Once we have a VBScript engine, making the content code do the right thing with
language="vbscript" should be trivial.
jst: really?  Don't we need to have multiple nsIScriptContexts, one for each
language type, per window?  And nsIScriptGlobalObject{,Owner}s?  Don't we need
some extra layer of dispatching and multiplicity to cope with event handlers
written in VBScript as well as those written in JS?  Etc.

/be
How about nsDOMClassInfo?
Eh, yeah, sure. There's a lot to this, but I was specifically refering to the
content code that deals with figuring out what language a script is in, that
part should be trivial.

But there's obviously a lot of work to be done to integrate the engine itself
into mozilla. Did someone say VBConnect? Eh, hmm... :-) I don't know how much
quirkyness there is in VBScript when run in IE, so we may or may not need much
hacking in nsDOMClassInfo. I guess I don't know enough about VBScript to say,
nor do I know how IE's DOM is exposed to VBScript either... But having said
that, it seems like in comparison to writing the VBScript engine, hooking it
into Mozilla should be fairly easy once we have an engine.
If you want an Win32 only VBScript engine, then why not use the IE one? There
are APIs in the form of IActiveScript & IActiveScriptSite through which you can
instantiate and control it.
http://www.newwindenergy.com/regional/mid-atlantic/buywind.asp
is currently VBScript
and since Mozilla can't do it (sometimes??) this is
preventing me from signing up to get wind power for my
electricity source!

For those who want to use microsoft tools - please forget it.
I'm on a Mac and don't have those.  Nor do I on any other
unix os.
Blocks: winupdate
Marked 28321 (Adding windowsupdate support) as being blocked by this.
Status: NEW → ASSIGNED
Is anyone working on this. There are quite a lot of pages today that use
VBScript and it would really be nice to see Mozilla support it.
>Is anyone working on this.
No

Assuming someone added plumbing such that any ActiveScript engine could be
plugged into Mozilla, then yes VBScript (and JScript, PerlScript etc.) could be
supported, at least on Win32.

Other than that, no one to my knowledge is working on support, primarily because
VBScript is a junk language and proprietary to boot. Implementing it would allow
Moz to render more pages, but the significant effort required would be high and
payoff would be small since many VBscript sites still wouldn't work because they
rely on other proprietary features such as ActiveX.

Of course if there was a ready to use open source VBScript impl out there, then
it should at least be considered. Does anyone know if there is?
So interesting, but it couldn't be include in Moz 1.4 final, at least.
Well, I just wrote to the GNOME Basic author, and here's what he said:

------------------------------------

Hi Daniel,

On Sat, 2003-09-20 at 07:44, Daniel wrote:
> You say GNOME Basic can do VBScript?  Is there any
> chance of GNOME Basic being a cross-platform VBScript
> solution? 

Absolutely non at all :-)

Gnome Basic is completely dead - however it's not all bad news; some of the
code, and most of the contributors live on in the Mono project:
http://www.go-mono.com/  which already has a better VB.Net implementation, a
beautiful JIT etc. etc.

> The Mozilla bug I speak of is found here:
> http://bugzilla.mozilla.org/show_bug.cgi?id=41274

Interesting.

Of course - the only hope is if you are prepared to do the work yourself; I'd
join the mono mailing list and see if anyone is going to help you learn to hack
mono into what you want.

Regards,

Michael.

------------------------------------

I have no idea how the licensing of Mono would fit into it, but it *IS*
cross-platform, according to:
http://www.go-mono.com/faq.html#portability

Here is how it is licensed:
http://www.go-mono.com/faq.html#licensing
*** Bug 241462 has been marked as a duplicate of this bug. ***
Depends on: dom-agnostic
Perhaps a VBScript to JavaScript translator would be better than building a 
VBScript Engine? This would avoid duplicating a lot of things that the JS 
Engine team has already done.

Then if Mozilla sees any vbscript it could just replace it with corresponding 
JavaScript before it is run?
I really don't care about this bug, except that if someone is motivated to help
prove the new APIs being developed to fix bug 255942, by using them to embed
some optional VBScript extension that isn't any more broken than the one
available in IE, then that would *probably* be helpful test the new APIs.

But it might just be one too many cases to support at once, or a case that we
never care about but that has its own hard edges that cost us.  The explicit
goal of bug 255942 is to support <script type="application/x-python"> in XUL
only, with some support for TCL looking likely to come along for the ride.

Since this bug remains assigned to nobody, helpwanted, Future, I wouldn't sweat
the details of how it should be fixed.

/be
No matter what hosting APIs we come up with, they are unlikely to mesh well with
the existing WSH engines.  I don't think compatibility is going to be a goal (or
necessarily should be).  Those hookups are old, crufty, and very historical to
handle a lot of edge cases and backwards compat.  If somebody someday decides to
try this, expect to wander far into the world of undocumented Windows
interfaces.  On the other hand, that's still probably easier than trying to put
together a new engine for this language.
Product: Browser → Seamonkey
Assignee: nobody → general
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: chofmann → general
I have a question, If this is ever implimented (which looks doubtful unless someone is willing to work on it), won't using an existing Windows interface limit compatability with Linux and Mac?

I know it was never designed to work on Linux and Mac but if its own engine was buit within Gecko, would it have compatability with Linux and Mac?
I did see some recent articles that Microsoft is slowly starting to do less with the ActiveX while replacing a few of them with a non-ActiveX stuffs.  Thought that was interesting but that DOESN'T mean it is what will happen to all of them in the foreseen future.
Assignee: general → nobody
Product: Mozilla Application Suite → Core
QA Contact: general → general
*** Bug 349302 has been marked as a duplicate of this bug. ***
*** Bug 362280 has been marked as a duplicate of this bug. ***
On the Windows side, VBScript makes it very easy to use WMI Classes making it very useful.


For instance I need to update 65 computers to use a new database configuration at work. Using VBScript and WMI Classes from Explorer I can update the computers remotely. I can also craete a web page that lists all the computers in active directory etc..


Paul 
VBScript is pretty much dead now as it had crossed-over to VB .NET.  You can alway use the .NET framework for that.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.