I noticed that if I have a .js file in windows explorer (not Internet Explorer, I'm meaning the folder explorer...) I can actually click on it and it will execute, giving error messages, like say "window object is undefined". Is there more information about the environment where the .js script are run into and the objects available?
Take a look at the Windows Scripting Host Docs (JScript).
Windows Script Host provides a reasonably rich environment allowing one to do a variety of interesting things - just yesterday I used it to create a tool that analyses a directory full of XML files which reference various resources such as images and other XML files, and produce an XML manifest in a predefined schema.
It's worth taking the time to get used to creating .wsf files (which use an XML-based syntax), rather than just running .js (JScript) or .vbs (VBScript) files - .wsf files offer much finer control over modularity and allow for better in-file documentation and usage explanations, and also allow scripts written in several different languages to be combined, which is handy if you find a VBScript that does 40% of what you need and don't want the hassle of converting it to use with the 60% you're writing in JScript.
The Windows® Scripting Guide provides technical resources, information and source code to help you automate the Windows® operating system using Windows® Script Host (WSH) and the VBScript and JScript scripting languages.
There is much information out there to get you started. There are many things you can do with it. I'm using a VBScript that makes the window handling work as in Linux (alt+Drag moves a window) with jus a few lines of code.
You can access many hooks to the system, including the file system. You can use any language that has registered itself with Windows Script Host, by default, VBScript and JScript.
You can run JScript (.js) and VBScript(.vbs) scripts directly in windows.
As what you have is a Javascript file intended to run in a web page, the environment that it expects is different. The window and document objects are only available inside the browser, so they don't work when you run the script outside the browser.
The objects that you have available are instead the ActiveX objects that are registered on the computer, like for example the Scripting.FileSystemObject object that you can use to access the file system.
JavaScript can be executed from the command line of any operating system provided you have access to a JavaScript interpreter that can be executed from the command line. The two common command line JavaScript interpreters are Rhino from Mozilla, which requires Java, and Windows Script Helper which can run natively in a Windows environment.
Related
Sorry this is a relatively simple question, but there's some confusion between the firefox javascript scripting interface and the scripting interface that comes with the enterprise version of iMacros.
Here's what I'm trying to do:
Make a javascript file which utilizes the enterprise version of iMacros' scripting interface. Not the one bundled with the firefox version.
Be able to use any browser via that scripting interface. This means using iimOpen("-fx") for firefox, -ie for IE, -cr for chrome, etc, using the command reference found here
Be able to call that javascript file from a .bat file so that I can automate it with Windows Task Scheduler
I've searched around a lot, and most questions are related to the firefox-specific scripting interface and are only for javascript/one browser. The few that are using the enterprise scripting interface don't have good answers/examples. I basically just want to have the shell of what I need to get started so that I can just start writing the actual script with iimPlayCode() calls. I'm new to javascript for scripting purposes, and most things I've done are using projects such as visual studio solutions, so I'm used to imports and such. For example, what do I need to define so that the script knows how to interpret iMacros commands? Usually that would be an import, but do I need an import for a script or is that built in somehow? Do I need a main or something similar? etc
There's this example on the iMacros wiki, but it's built like an html file that you have to click to start, and I don't think that'd work well with a batch file for scheduling. As far as I know, that's the only javascript example using the enterprise scripting interface.
System information:
Windows 10
iMacros 11.1 Enterprise
Latest Firefox/Chrome/IE
How to run compiled files directly using Google Native Client (PNaCl)? It tried checking their documentation. It said that -
Native Client is a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system.
But in their documentation, they only deal with sources of the application. Is there any way to run compiled code directly? I want to run files with .exe and .deb extensions
I'm not limiting the answer to Native Client. Any mechanism which can do that sort of work will work for me.
You can't run pre-compiled code within NaCl or PNaCl. You have to use the compilers provided by the SDK. There are three main reasons for this:
NaCl is an execution sandbox which relies on crafting machine code (x86-32, x86-64, ARM, MIPS) in a very particular way. This is regular machine code from the CPU's point of view, but allows the sandbox to run a validator and make sure that the code can't do anything malicious. This is called Software Fault Isolation, and is explained in this paper. The other ISA sandboxes are also documented.
PNaCl targets NaCl, but is an architecture-agnostic intermediate representation. This means that you ship what can be thought of as bytecode, and the browser figures out which type of machine code (x86-32, x86-64, ARM, MIPS) to generate based on the user's machine. The developer doesn't generate 4 binaries.
In both above cases, the code can execute as-is on Windows, MacOSX, Linux, ChromeOS, and (while not usually shipping) Android. This means that the NaCl sandbox presents itself as an operating system, and offers the same APIs. These APIs are different from other OSes, though they're pretty close to POSIX especially if you use nacl_io.
The above points require that you use the compilers provided by the SDK.
It is technically possible to run binaries built for other architectures or operating systems since the system is Turing-complete. That's what QEMU does, what Rosetta did, what Transmeta did, and what the Android Runtime for Chome (ARC) enables. This usually requires binary translation and emulation of all operating system calls. This is technically difficult to implement, and often has severe performance cost. I do not recommend exploring this option.
As #JFBastien pointed out, emulation is the only option to execute pre-compiled native code in the browser environment. But it is an option nevertheless. Depending on your demands on performance, it might even be a viable option.
Click here for example to boot up an emulator running Windows (a very old version though) in your browser.
From the menu pick, for example, notepad.exe (using the cursor down key on your keyboard) and hit enter. There you have it: an unmodified, precompiled, native notepad.exe running inside your browser! (and probably even faster than back in the day when this OS was new).
There are a lot of emulators written in Javascript all around the web. Running a small Linux distribution with usable performance and even with networking(!), graphics and sound is actually possible. Check out the OpenRISC emulator. You can even run an ssh daemon and log into it from your local machine!
Instead of having V8 compile JavaScript on the fly and then execute it, isn't it possible to just compile the JavaScript beforehand and then embed the machine code in the page instead of embedding JavaScript in the page?
There are two main problems with shipping machine code on the web:
Portability. No server can afford providing appropriate machine code for all possible system architectures out there (present and future). E.g., V8 already supports 10 different CPU architectures.
Security. No client can afford to run random machine code on their machine without knowing if it can be trusted.
To address (1) you'd generally need to cross-compile machine code, which is more difficult and costly than compiling down from a high-level language. To address (2), you'd need to validate the machine code you receive, which is more difficult and costly than compiling a high-level language.
Machine code also tends to be much larger than high-level code, so there is a bandwidth issue as well.
Now, JavaScript may not be a particularly great choice of high-level language. But it is what we are stuck with as the language of the web.
The way I understand it, the V8 JavaScript engine compiles to machine code anyway so why not just do it beforehand?
According to the W3C HTML5 Scripting specification, there's no standards-based reason why a browser couldn't support machine code with special type attributes (as Chrome does with the Dart language):
The following lists the MIME type strings that user agents must recognize, and the languages to which they refer:
"application/ecmascript"
"application/javascript"
...
User agents may support other MIME types for other languages...
Currently, no browser has implemented such a feature.
I suspect the primary shortcoming of such an approach is that each chip architecture would require a machine-code version of the script compiled for it specifically. This means that in order to support three architectures, a page would need to include a compiled script three times. (And it should be included a fourth time, as plain JavaScript, as a fallback for architectures that you didn't include, or for browsers that can't/don't support compiled code.) This could significantly bloat the size of the page with data that is mostly useless. The increase in load time would seem to significantly offset or completely outweigh whatever time you save on compilation.
An architecture-independent compromise solution like bytecode seems pretty poor: you still need to include the script twice (once for the bytecode, once normally for scripts that don't support it) and you need to do some kind of run-time processing on the bytecode to turn it into machine code.
The multiple-includes-with-fallback problem is exactly why other scripting languages have not made it into the Web environment: they would need coordinated cross-vendor support to be useful. Google is trying with Dart, but it remain to be seen what degree of success they see.
Note that Chrome does cache compiled versions of scripts so a script only needs to be compiled once and then the compiled code is cached for reuse when the user re-visits the page.
https://github.com/rogerwang/node-webkit/wiki/How-to-package-and-distribute-your-apps
While packaging my node-webkit app for windows using the steps given in the above link I could not find how to avoid readability of the resulting executable from the merge by archiving software, such as WinZip. EXCERPT(from link above): "The resulting executable from the merge will still be readable by archiving software, such as WinZip."
Is it possible to avoid readability by the archiving apps?
Any help is appreciated!
Fundamentally, running node-webkit is similar to running in a browser, so just as you can't hide your webpage source, you can't truly hide your HTML and CSS in such a way that it can't be read, because it needs to be read by node-webkit at runtime.
The situation is almost the same for Javascript code, with one exception. V8 (the javascript engine in Chrome) provides a "snapshot" capability, which sort of compiles your Javascript into a sort of bytecode that V8 understands. Nwsnapshot is available for node-webkit, which will allow you to avoid shipping your JS code (or at least some of it). However, this option is still experimental, and in fact there is a problem in version 0.8.* of node-webkit (referred to as v8 in the wiki, but not to be confused with the V8 js engine), though it should be working again now in v9. Details can be found here if you're interested:
https://github.com/rogerwang/node-webkit/wiki/Protect-JavaScript-source-code-with-v8-snapshot
Also be aware that it can have performance impacts, if that matters for your application.
You could also make an exe file.
See "Step 2b: Alternative way - Making an executable file out of a .nw file" from the link you provided.
I have a number of users with multi-megabyte files that need to be processed before they can be uploaded. I am trying to find a way to do this without having to install any executable software on their machines.
If every machine shipped with, say, Python it would be easy. I could have a Python script do everything. The only scripting language I can think of that's on every machine is JavaScript. However I know there are security restrictions that prevent reading and writing local files from web browsers.
Is there any way to use this extremely pervasive scripting language for general purpose computing tasks?
EDIT: To clarify the requirements, this needs to be a cross platform, cross browser solution. I believe that HTA is an Internet Explorer only technology (or that the Firefox equivalent is broken).
Would Google Gears work here? Yes, users have to install something, but I think the experience is fairly frictionless. And once it's installed, no more worries.
The application that I maintain and develop for work is an HTML Application or HTA, linked with a SQL Server 2005 backend. This allows various security restrictions to be "avoided". All the client-side components in the application are done with javascript, including writing files to locally mapped network drives and loading data into screens/pages in an AJAXy way.
Perhaps HTA could be helpful for your situation.
For an example of javascript accessing a local file, you might try taking a look at the source of TiddlyWiki, specifically the saveFile, mozillaSaveFile, and ieSaveFile functions. Just click the download link, open the html file it sends you, and search for those functions.
Of course, tiddlywiki is supposed to be used as a local file, not served over the web, so the methods it uses may only work locally.. But it might be a start.
Why not use a flash uploader? http://swfupload.org/
Adobe Flex 4 lets you to open and process a file on a local machine:
http://livedocs.adobe.com/flex/3/langref/flash/net/FileReference.html#load()
It's not exactly JavaScript, but hope that helps.
I believe you can accomplish this using the HTML5 File API.
It is supported in Opera, IE, Safari, Firefox, and Chrome.
you can use fs module from nodeJS to manipulate with filesystem nowadays!