Upgrading Applications Created in Previous Versions of JScript
A majority of existing JScript code will work fine with the enhancements included in JScript 8.0 because JScript 8.0 is almost completely backwards compatible with previous versions. The new features of JScript 8.0 cover new areas.
By default, JScript 8.0 programs are compiled in fast mode. Since fast mode places some restrictions on the types of code that are allowed, programs can be more efficient and execute faster. However, some features available in previous versions are not available in fast mode. For the most part, these features were incompatible with multi-threaded applications and produced inefficient code. For programs compiled with the command-line compiler, you can turn fast mode off and have complete backwards compatibility. Note that code compiled in this way is slower and more susceptible to errors. Fast mode cannot be turned off in ASP.NET applications because of the stability issues it would present. For more information, see /fast.
In fast mode, the following JScript behaviors are triggered:
Previous versions of JScript did not require explicit declaration of variables. Although this feature saves keystrokes for programmers, it also makes it difficult to trace errors. For example, you could assign a value to a misspelled variable name, which would neither generate an error nor return the desired result. Furthermore, undeclared variables have global scope, which can cause additional confusion.
Fast mode requires explicit variable declarations. This helps prevent the types of errors mentioned above and produces code that runs faster.
JScript .NET also supports type-annotated variables. This binds each variable to a particular data type, and the variable can store only data of that type. Although type annotation is not required, using it helps prevent errors associated with accidentally storing the wrong data in a variable and can increase program execution speed.
For more information, see JScript Variables and Constants.
In previous versions of JScript, functions declared with the function statement were treated the same as variables that held a Function object. In particular, any function identifier could be used as a variable to store any type of data.
In fast mode, functions become constants. Consequently, functions cannot have new values assigned to them or be redefined. This prevents accidentally changing the meaning of a function.
If your script requires that a function change, you can explicitly use a variable to hold an instance of the Function object. Note, however, that Function objects are slow. For more information, see Function Object.
In previous versions of JScript, you could add expando properties to intrinsic objects. This behavior could be used to add a method to a String object to trim leading spaces for the string, for example.
In fast mode, this is not allowed. If your script relies on this feature, you must modify the script. You can define functions in the global scope instead of attaching those functions to objects as methods. Then, rewrite each instance in the script where an expando method is called from the object so that the object is passed to the appropriate function.
One notable exception to this rule is the Global object, which still can have expando properties. All identifiers in the global scope are actually properties of the Global object. Obviously, the Global object must be dynamically extensible to support the addition of new global variables.
In previous versions of JScript, you could delete, enumerate, or write to the predefined properties of intrinsic objects. This behavior could be used to change the default toString method of the Date object, for example.
In fast mode, this is not allowed. This feature is no longer necessary since intrinsic objects cannot have expando properties, and the properties for each object are listed in the reference section. For more information, see Objects.
Previous versions of JScript provided an arguments object inside function definitions, which allowed functions to accept an arbitrary number of arguments. The arguments object also provided a reference to the current function as well as the calling function.
In fast mode, the arguments object is not available. However, JScript 8.0 allows function declarations to specify a parameter array in the function parameter list. This allows the function to accept an arbitrary number of arguments, thus replacing part of the functionality of the arguments object. For more information, see function Statement.
There is no way to directly access and reference the current function or calling function in fast mode.
In previous versions of JScript, statements could appear to assign a value to a read-only identifier. The assignment would fail quietly, and the only way to discover the assignment failure would be to test if the value actually changed. Assignment to a read-only identifier usually is the result of a mistake, since it has no effect.
In fast mode, a compile-time error will be generated if you attempt to assign a value to a read-only identifier. You can either remove the assignment or try assigning to an identifier that is not read-only.
If you turn fast mode off, assignments to read-only identifiers will fail silently at run-time, but a compile-time warning will be generated.
In previous versions of JScript, functions and variables could be defined in the local or global scope by a call to the eval method.
In fast mode, functions and variables can be defined within a call to the eval method, but they are accessible from within that particular call. Once the eval is finished, the functions and variables defined within the eval are no longer accessible. The result of a calculation made within an eval can be assigned to any variable accessible in the current scope. Calls to the eval method are slow, and you should consider rewriting code that contains them.
The previous behavior of the eval method is restored when fast mode is turned off.
In previous versions of JScript, code passed to the eval method would run in the same security context as the calling code.
To help protect users, code passed to the eval method executes in a restricted security context, unless the string "unsafe" is passed as the second parameter. The restricted security context helps to prevent access to system resources, such as the file system, the network, or the user interface. A security exception is generated if the code attempts to access those resources.
When the second parameter of eval is the string "unsafe", the code passed to the eval method is executed in the same security context as the calling code. This restores previous behavior of the eval method.
Use eval in unsafe mode only to execute code strings obtained from well-known sources.