WScript JavaScript library

[pantagruel]

Hi,

I'm thinking of making a WScript based JavaScript library, I can think
of some specific non-browser specific scripting examples that should
probably make it in, like Crockford's little JavaScripter, can anyone
think of anything else. Is anyone familiar with anything similar
already done.

Things that I am thinking that to provide are:

JavaScript helper functions to make WMI queries, manage returned WMI
enumerators.

JavaScript with such technologies as HTA.

Anything that people can think such a library should specifically
have?

 

[Thomas 'PointedEars' Lahn]

I'm thinking of making a WScript based JavaScript library,

That is antivalent. Apparently you don't know what the WScript object and
what JavaScript is.

http://msdn2.microsoft.com/en-us/library/at5ydy31.aspx
http://developer.mozilla.org/en/docs/JavaScript

I can think of some specific non-browser specific scripting examples
that should probably make it in, [...]

The Windows Script Host is somewhat browser-specific itself, as it supports
only Microsoft JScript as ECMAScript implementation (like IE). So there is
little point of excluding other code from it.


PointedEars

 

[beegee]

That is antivalent. Apparently you don't know what the WScript object and
what JavaScript is.

Hoo boy. You are something, PointedEars . If I squint my
"grammatical eyes", I can just barely make out what you are talking
about when you call the OPs statement "antivalent". Of course, you're
completely wrong. The poster does know what the WScript host is and he
obviously knows what javascript is. Man, you really overreach just to
scratch an itch.

So, yes, pantagruel, if you were to write this library, I'd like to
see parameter typing, handling wildcards, recursing through
directories, a wrapper around Exec and handlers for all the possible
return codes. I am not an advanced WScripter and don't wish to be so
you may have to go over to the microsoft forums to get a better
answer.

Bob

 

[pantagruel]

pantagruelwrote:

That is antivalent. Apparently you don't know what theWScriptobject and
what JavaScript is.

I think I do. WScript is a environment for running different Microsoft
ActiveScripting languages, among which the Microsoft implementation of
JavaScript is one.

http://msdn2.microsoft.com/en-us/li...tp://developer.mozilla.org/en/docs/JavaScript

I can think of some specific non-browser specific scripting examples
that should probably make it in, [...]

The Windows Script Host is somewhat browser-specific itself, as it supports
only Microsoft JScript as ECMAScript implementation (like IE). So there is
little point of excluding other code from it.

I meant specifically JavaScript code that runs in the browser and
JavaScript that runs in every JavaScript implementation. For a simple
example of browser specific JavaScript: alert(); is a native function
in the browser. It does not exist in WScript. The WScript version of
alert is WScript.Echo()
For a simple example of browser-agnostic JavaScript the simple looping
of an object function:

function alert(p){
WScript.Echo(p);
}


function loopobject(obj){
if(gettype(obj) == "object" && obj != null){
for (var i in obj) {
alert(i + ": " + obj);
}
}
}

Of course maybe I should use a different term than browser agnostic
because it implies JavaScript that is agnostic about which browser it
runs in, in the common usage whereas I mean JavaScript that is
agnostic about whatever JavaScript environment it runs in.

Actually I am somewhat an odd case where JavaScript is concerned
because I really don't know it well in the browser. I used to use it a
very little bit but my website based work tends to be on the server
side, so I've used JavaScript in BSF some years ago, and in ASP and
ASP.NET, as well as quite a lot in WScript.

Best Regards

 

[pantagruel]

So, yes,pantagruel, if you were to write this library, I'd like to
see parameter typing, handling wildcards, recursing through
directories, a wrapper around Exec and handlers for all the possible
return codes. I am not an advanced WScripter and don't wish to be so
you may have to go over to the microsoft forums to get a better
answer.

Thanks for the suggestions. I was thinking:

1. some smarter command line handling, specify parsing of commandline
so that all files get put into a files object and then you can specify
run function x over all files on command line type stuff.

2. all major vbscript data type conversions supported (basically just
support this by having it in a WSF file with the vbscript functions to
return correct data types) good for handling stuff like WMI dates.

3. definitely filesystem recursing.

a question:

Do you think it would be useful to allow evaluation of JavaScript
code on the command line, i.e. run JavaScript in cscript.exe and allow
it to run as a shell?

Best Regards

 

[pantagruel]

That is antivalent. Apparently you don't know what theWScriptobject and
what JavaScript is.

I think I do.WScriptis a environment for running different Microsoft
ActiveScripting languages, among which the Microsoft implementation of
JavaScript is one.

http://msdn2.microsoft.com/en-us/library/at5ydy31.aspxhttp://develope...

I can think of some specific non-browser specific scripting examples
that should probably make it in, [...]

The Windows Script Host is somewhat browser-specific itself, as it supports
only Microsoft JScript as ECMAScript implementation (like IE). So there is
little point of excluding other code from it.

I meant specifically JavaScript code that runs in the browser and
JavaScript that runs in every JavaScript implementation. For a simple
example of browser specific JavaScript: alert(); is a native function
in the browser. It does not exist inWScript. TheWScriptversion of
alert isWScript.Echo()
For a simple example of browser-agnostic JavaScript the simple looping
of an object function:

function alert(p){WScript.Echo(p);

}

function loopobject(obj){
if(gettype(obj) == "object" && obj != null){
for (var i in obj) {
alert(i + ": " + obj);

}
}
}

Of course maybe I should use a different term than browser agnostic
because it implies JavaScript that is agnostic about which browser it
runs in, in the common usage whereas I mean JavaScript that is
agnostic about whatever JavaScript environment it runs in.

Actually I am somewhat an odd case where JavaScript is concerned
because I really don't know it well in the browser. I used to use it a
very little bit but my website based work tends to be on the server
side, so I've used JavaScript in BSF some years ago, and in ASP and
ASP.NET, as well as quite a lot inWScript.

Best Regards

I should note that this is not truly JavaScript implementation
agnostic since of course I was using WScript.Echo(), but I just wanted
a quick example of code that worked on JavaScript as opposed to
working on the DOM as the kind of thing I meant.

Cheers,

 

[Thomas 'PointedEars' Lahn]

I think I do.

Yes, you *think* you do, but in fact you do not at all.

WScript is a environment for running different Microsoft ActiveScripting
languages,

That, at least, is true.

among which the Microsoft implementation of JavaScript is one.

Wrong. JScript is Microsoft's implementation of ECMAScript. JavaScript is
Netscape's/Mozilla.org's implementation of ECMAScript. Those are similar,
but different languages. Read the FAQ.

http://msdn2.microsoft.com/en-us/li...tp://developer.mozilla.org/en/docs/JavaScript

I can think of some specific non-browser specific scripting examples
that should probably make it in, [...]

The Windows Script Host is somewhat browser-specific itself, as it supports
only Microsoft JScript as ECMAScript implementation (like IE). So there is
little point of excluding other code from it.

I meant specifically JavaScript code that runs in the browser and
JavaScript that runs in every JavaScript implementation.

You have yet to understand that you are dealing with different programming
languages and different runtime environments here as indicated by my
previous comment.

For a simple example of browser specific JavaScript: alert(); is a native
function in the browser.

alert() is a method of a host object provided by the AOM of the HTML UA,
usually a Window object. It is not a feature of the programming language.

It does not exist in WScript.

As WScript provides another API than an HTML UA.

The WScript version of alert is WScript.Echo()

In a sense.

[more misconceptions]

Please learn to understand what you are doing before you can do further harm.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn said the following on 11/23/2007 10:15 AM:

If you are going to be pedantic, at least be completely pedantic.
JScript is Microsoft's implementation of a standard that attempted to
standardize what JScript already was. Not the other way around.

Not true. ECMAScript Edition 1 was based on what *both* JavaScript
(probably 1.1 and maybe even 1.2) and JScript (probably 2.0) supported at
the time.

,-[ECMA-262 Ed. 1, page 5]
|
| Brief History
|
| This ECMA Standard is based on several originating technologies, the most
| well known being JavaScript™ (Netscape Communications) and JScript™
| (Microsoft Corporation). The development of this Standard has started in
| November 1996.

Since then, it is not possible to determine what came first to introduce a
language feature -- the ECMAScript edition or the language implementation.

However, Microsoft itself says that JScript (and JScript .NET) is an
ECMAScript implementation, and rightly so:

,-<http://msdn2.microsoft.com/en-us/library/14cd3459.aspx>
|
| What Is JScript?
|
| JScript is the Microsoft implementation of the ECMA 262 language
| specification (ECMAScript Edition 3). With only a few minor exceptions (to
| maintain backwards compatibility), JScript is a full implementation of the
| ECMA standard.

,-<http://msdn2.microsoft.com/en-us/library/49zhkzs5(VS.71).aspx>
|
| Microsoft JScript Features - ECMA
|
| JScript .NET incorporates almost all of the features of the ECMAScript
| Edition 3 Language Specification. In addition, JScript .NET is being
| developed in conjunction with ECMAScript Edition 4 and incorporates
| many of the proposed features of that language as well. [...]

Needless to say that my statement also is in full accordance with this
newsgroup's FAQ:

,-<http://www.jibbering.com/faq/#FAQ2_7>
|
| 2.7 What is JScript?
|
| JScript is Microsoft's implementation of ECMAScript. [...]

Maybe you want to ask its maintainer why that statement was not changed if
it was deemed wrong. But wait -- isn't that you?


PointedEars

 

[pantagruel]

Wrong. JScript is Microsoft's implementation of ECMAScript. JavaScript is
Netscape's/Mozilla.org's implementation of ECMAScript. Those are similar,
but different languages. Read the FAQ.

Well, IIRC (not reading the faq again, many years since I last did and
am too lazy, but strangely not too lazy to post here) ECMAScript was
the standardisation of JavaScript, the earlier versions of JScript was
a reverse engineered JavaScript and the different name was not so much
because it was a different language but because of various legal
issues surrounding the name (I don't think this is mentioned in the
FAQ), the reverse engineering was done because MS was behind in the
browser war. When the ECMA standardization started MS tried to follow
and I thought that basically the version in IE 6+ (and thus in WScript
on a computer with IE 6+ installed) was ECMA-262 version 3 compatible.
My understanding that the main inconsistencies were in the
implementation of other standards with which the language interacts in
the browser, the DOM, CSS etc. I suppose there probably are going to
be some inconsistencies but I think those inconsistencies would
probably turn out to be things I would classify as pedantry, and
probably most people would agree. But hey, I could also be wrong.

I can think of some specific non-browser specific scripting examples
that should probably make it in, [...]
The Windows Script Host is somewhat browser-specific itself, as it supports
only Microsoft JScript as ECMAScript implementation (like IE). So there is
little point of excluding other code from it.

I meant specifically JavaScript code that runs in the browser and
JavaScript that runs in every JavaScript implementation.

You have yet to understand that you are dealing with different programming
languages and different runtime environments here as indicated by my
previous comment.

Well I guess that's true, as I don't understand I am dealing with
different programming languages I understand rather that I am
discussing bringing the kind of library type functionality that one
sees in the main environment for JavaScript, the browser, to a
somewhat less well known environment, The Windows Scripting Host.

alert() is a method of a host object provided by the AOM of the HTML UA,
usually a Window object. It is not a feature of the programming language.

I think you may be saying tomato and I may be saying tomatoe here.
When I said native function I meant something implemented in the
JavaScript environment as a function accessible by the language but
not a JavaScript function itself, although the type of alert in IE
only returns object which doesn't say much, while in FireFox you can
interact a bit more with alert than you can in IE:

Object.prototype.describe=function(){alert("Description: " +
this);return this;}
alert.describe();
which gives

Description: function alert(){
[native code]
}

which is why I used the term native function to describe it. I'm sorry
if I should have avoided that term.

As WScript provides another API than an HTML UA.


In a sense.

yes, in a sense. perhaps I should have used the word analogue instead
of version.

[more misconceptions]

how where the following things misconceptions exactly:

1. the code that I provided works in WScript and apparently the way I
described. If I create an object then with this code I can loop over
its properties and make WScript.Echos of them, or as I called them in
my function alerts.

2. I suggested in the second paragraph that perhaps I had used the
wrong term for JavaScript that runs in different environments than the
browser when I used the term browser agnostic. IF this is a
misconception are you suggesting either that there is no such thing as
JavaScript that runs outside the browser or are you suggesting that
browser agnostic was a brilliant term and it is a misconception to
consider changing it. In which case, thanks!

3. The last paragraph I state I am somewhat an odd case because I have
spent very little time with JavaScript in the browser and that was
many years ago - basically with IE 5 and Netscape 4 as the main
browsers, although I have done quite a bit on the server in various
implementations - I realize that I mention some versions of the
language that you may describe as not different versions of the
language but different languages altogether (true about JScript.Net
dependent on .NET compatibility settings) was that the misconception?

Please learn to understand what you are doing before you can do further harm.

Well, I suppose that anything I did would not be of great harm,
because it would be limited to the Windows Scripting Host.

Thanks

 

[Thomas 'PointedEars' Lahn]

Well, IIRC (not reading the faq again, many years since I last did and
am too lazy, but strangely not too lazy to post here) ECMAScript was
the standardisation of JavaScript,

Wrong, as stated by the specifications itself which I cited before.

the earlier versions of JScript was a reverse engineered JavaScript

Wrong, or at least virtually impossible to prove at this point. If it was
uncovered that JScript was merely based on unlicensed reverse engineering of
JavaScript code, that would probably have serious legal consequences for
Microsoft (IANAL). I would like to believe instead that they saw what
Netscape implemented and documented, and tried to recreate it in order
to keep up with them.

and the different name was not so much because it was a different
language but because of various legal issues surrounding the name

I don't think so. Microsoft has a long history of relabeling existing
things and then implement them differently in their own, often incompatible,
fashion. Why should it have been any different with JScript?

[...] When the ECMA standardization started MS tried to follow

Microsoft has been an ECMA member since before work on the very first
ECMAScript edition started, and apparently took part in the initial meeting
of the overseeing comittee:

http://cgi.netscape.com/newsref/pr/newsrelease289.html

ECMAScript Edition 1 and all later editions are based on both JavaScript and
JScript. Read the specification(s) once.

and I thought that basically the version in IE 6+ (and thus in WScript
on a computer with IE 6+ installed) was ECMA-262 version 3 compatible.

Nevertheless, JScript is not JavaScript. It is a different ECMAScript
implementation, a different language, not only by name but also by its
features. Take conditional compilation, for example.

Well I guess that's true, as I don't understand I am dealing with
different programming languages I understand rather that I am
discussing bringing the kind of library type functionality that one
sees in the main environment for JavaScript, the browser, to a
somewhat less well known environment, The Windows Scripting Host.

Which does not support Netscape/Mozilla.org JavaScript, but Microsoft JScript.

alert() is a method of a host object provided by the AOM of the HTML UA,
usually a Window object. It is not a feature of the programming language.

I think you may be saying tomato and I may be saying tomatoe here.
When I said native function I meant something implemented in the
JavaScript environment as a function accessible by the language but
not a JavaScript function itself, although the type of alert in IE
only returns object which doesn't say much, while in FireFox you can
interact a bit more with alert than you can in IE:

Object.prototype.describe=function(){alert("Description: " +
this);return this;}
alert.describe();
which gives

Description: function alert(){
[native code]
}

Apparently in Gecko window.alert() is implemented as a Function object
which is why it inherits from Object.prototype. However,

window.alert("Description: " + window.alert);

would have sufficed. Augmentation of Object.prototype and other native
prototype objects is generally frowned upon because of its side effects.

which is why I used the term native function to describe it. I'm sorry
if I should have avoided that term.

"native code" does not refer to code native to the programming language here
but to code native to the runtime environment (i.e., not user-defined code.)

[more misconceptions]

how where the following things misconceptions exactly: [...]

That should be clear to you by now.

Well, I suppose that anything I did would not be of great harm,
because it would be limited to the Windows Scripting Host.

Quite the contrary. Because you are dealing with script code here that does
not run in a sandbox, you have to make even more sure that you know what you
are doing than you would have to with scripting for and in HTML UAs. People
who use your library on their Windows system can suffer greatly from the
consequences of your incompetence up to the point of severe data loss otherwise.


PointedEars

 

[f3l]

Thomas 'PointedEars' Lahn said the following on 11/25/2007 7:35 PM:



It is amazing to me that anybody that displays the level of intelligence
that you display on a regular basis could survive in the real world for
more than a week.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ -http://jibbering.com/faq/index.html
Javascript Best Practices -http://www.JavascriptToolbox.com/bestpractices/

the discussion here is completely off topic, and nobody cared to
answer the OP's question.


OP: have u used dmdscript?

 

[pantagruel]

Wrong, as stated by the specifications itself which I cited before.

I suppose that this may be a simplification of the history but
historical pedanticism isn't necessarily helpful I think.

Wrong, or at least virtually impossible to prove at this point. If it was
uncovered that JScript was merely based on unlicensed reverse engineering of
JavaScript code, that would probably have serious legal consequences for
Microsoft (IANAL). I would like to believe instead that they saw what
Netscape implemented and documented, and tried to recreate it in order
to keep up with them.

by reverse engineered I meant the weak version and legal in most cases
that I can think of of reverse engineering which is absent adequate
documentation taking what documentation there is and testing inputs
and outputs until one has a functioning understanding of what is
supposed to work. This is my understanding of what Microsoft did based
on different presentations and things I've read but I have never read
an authoritative history of the matter, I don't agree a FAQ is an
authoritative history either, FAQs tend to leave the inessential out
and this kind of information is really inessential.

I don't think so. Microsoft has a long history of relabeling existing
things and then implement them differently in their own, often incompatible,
fashion. Why should it have been any different with JScript?

they have a history of embracing and extending and I believe in the
earliest version that is what they tried to do, to make it work as
well as they could with the information they had and to extend it. But
I am probably wrong, I can't say it is historically relevant to
anything but programmer's trivial pursuit.

ECMAScript Edition 1 and all later editions are based on both JavaScript and
JScript. Read the specification(s) once.

If you're suggesting I should read the ECMAScript spec I have read
them some years ago. I used to be quite the spec reader, nowadays I
only read what I have to read, I don't think I have to read a spec to
make a library for an implementation. I have to read the documentation
on the implementation.

Nevertheless, JScript is not JavaScript. It is a different ECMAScript
implementation, a different language, not only by name but also by its
features. Take conditional compilation, for example.

well I guess that can somewhat be agreed on, but it is an ECMAScript
implementation and common usage for ECMAScript implementations is to
call them JavaScript whether they are some other implementation or not
and I will keep with common usage in this case.

I think you may be saying tomato and I may be saying tomatoe here.
When I said native function I meant something implemented in the
JavaScript environment as a function accessible by the language but
not a JavaScript function itself, although the type of alert in IE
only returns object which doesn't say much, while in FireFox you can
interact a bit more with alert than you can in IE:

Object.prototype.describe=function(){alert("Description: " +
this);return this;}
alert.describe();
which gives

Description: function alert(){
[native code]
}

Apparently in Gecko window.alert() is implemented as a Function object
which is why it inherits from Object.prototype. However,

window.alert("Description: " + window.alert);

would have sufficed. Augmentation of Object.prototype and other native
prototype objects is generally frowned upon because of its side effects.

Yes you're right, however I was not presenting this as what to do but
just a snippet of code I had lieing around.

"native code" does not refer to code native to the programming language here
but to code native to the runtime environment (i.e., not user-defined code.)

okay you say so.

Quite the contrary. Because you are dealing with script code here that does
not run in a sandbox, you have to make even more sure that you know what you
are doing than you would have to with scripting for and in HTML UAs. People
who use your library on their Windows system can suffer greatly from the
consequences of your incompetence up to the point of severe data loss otherwise.

ah I understand, I thought the harm you were worried about was the
harm caused by releasing yet another bad library for the JavaScript
browser market, as opposed to releasing a bad one for the JavaScript
WScript market (note earlier determination to follow common usage with
the word JavaScript)
Well I will keep that in mind and perhaps in a year you will be able
to point out how you predicted the catastrophe I unleashed upon the
world.

Thanks

 

[pantagruel]

the discussion here is completely off topic, and nobody cared to
answer the OP's question.

Well I did get some suggestions that were useful from beegee

OP: have u used dmdscript?

No, thanks, I saw that a long time ago but had totally forgot. This is
actually great for some of the work I have to do now. This makes the
whole thread worth it.

Cheers!

 

[pantagruel]

the discussion here is completely off topic, and nobody cared to
answer the OP's question.

OP: have u used dmdscript?

oh and I will stop replying to the thread now to let it die. Thanks
again for dmdscript!

 

[Thomas 'PointedEars' Lahn]

I suppose that this may be a simplification of the history but
historical pedanticism isn't necessarily helpful I think.

It certainly serves to point out the fact that there are at least three
different languages on-topic here, and that it is unwise to ignore that
difference.

well I guess that can somewhat be agreed on, but it is an ECMAScript
implementation and common usage for ECMAScript implementations is to
call them JavaScript whether they are some other implementation or not
and I will keep with common usage in this case.

It is also common usage to call the Web the Internet and vice-versa, and
write "IP" for "IP address" aso. which are equally wrong.

okay you say so.

It is documented so.

Quite the contrary. Because you are dealing with script code here that does
not run in a sandbox, you have to make even more sure that you know what you
are doing than you would have to with scripting for and in HTML UAs. People
who use your library on their Windows system can suffer greatly from the
consequences of your incompetence up to the point of severe data loss otherwise.

[...]
Well I will keep that in mind and perhaps in a year you will be able
to point out how you predicted the catastrophe I unleashed upon the
world.

You misunderstood; I wish you good luck in your endeavour. I was merely
pointing out the caveats.


PointedEars