June 2003 - Posts
The subject of dynamic compilation and unloading of assemblies in relation to
the .NET VSA namespaces came up in discussion today.
As I'm currently writing a user manual topic about the different types of
scripting (integrated, web and administrative), I though I might share the
paragraph about integrated scripting which relates to that discussion...
Integrated Scripting provides for the extension or modification of
program functionality by the end user. Generally this is through user defined
macros, plugins(1), or a framework for functional customization.
At the time of publication, there are no .NET integration scripting
solutions available. That is likely to continue, given architectural
limitations in the .NET framework which prevent the effective use of compiled
dynamic code at runtime. Microsoft's VSA, despite some early articles, is
largely unsuited to anything other than offering customization by the
implementor at design time. Microsoft's forthcoming Visual Tools for Office,
which only offers .NET based customization at design time, reflects that
limitation.
(1) script based rather than binary
plugins
I should point out that one can use JScript.NET's eval function, but it has
practical limitations.
Integrated scripting requires access to to an application's live objects and
events. The architectural limitations referred to above, relate to the current
implementation of the CLR which cannot unload assemblies from the primary
AppDomain and recover that memory other than at end of process. The only way
around this is to use an AppDomain recycling scheme, which obviates the ability
to use live objects and events, other than through remoting.
Some of the more eagle eyed amongst those who read my my previous post
about writing a 'whois' script with
Alintex Script .NET 1.1, pointed out that the code didn't handle
exceptions.
Note: see the Portable Script File Description at the
bottom of the whois post to view the code.
The simple answer to that is that it does. The Alintex Script
application itself will ultimately catch any unhandled exception. Infact,
one can use that mechanism to easily report an error back to the user running
the script.
For example, the following code will produce the output similar to that
shown in the image below:-
[VB.NET]
#region
"Script"
throw new System.Exception("Where am I
caught?")
#end region
[C#]
#region
Script
throw new System.Exception("Where am I
caught?");
#endregion
[JScript.NET]
import System;
throw new
System.Exception("Where am I caught?");
What about Java (J#)?
A script written in Java has the luxury of throwing a Java or .NET
exception. Alintex Script handles both.
[Java]
#region
Script
throw new java.lang.Exception("Where am I
caught?");
#endregion
OR
#region
Script
throw new System.Exception("Where am I
caught?");
#endregion
Of course you can choose to handle an exception in the script itself.
Additionally, there as an /unattended command line option that prevents the
visible reporting of errors.
Another option lets you record all errors to the application event log as
shown in the image below.
Please note that Alintex Script .NET 1.1 has not yet been released and is not
available from the Alintex web site.
I found Eric Kidd's article (via James Avery) about 'The Missing Future' in software both interesting and a little sad.
Eric seems to view the industry though a developer viewpoint that is increasingly common. One where he questions where he fits in a world dominated by huge software companies, a monolithic open source movement and small software companies with (sic) no apparent hope. I think he would like to make a BIG difference, but given this viewpoint - how?
To him I would answer, that rather than being powerless, he holds the key to what awaits him at 55. But in order to do so he needs to change his focus away from technology, platforms and the development community, to real world end-users and their requirements.
To make a real difference, he needs to develop specialized knowledge about a field or discipline to which he can address his skills.
We as programmers, lets face it, are a dime a dozen. Some are faster, some slower - some more efficient. But ultimately we are just another set of hours of available resource on a project plan.
But a programmer who has industry specific knowledge - now that's something different. Come to realize that the software industry is dominated NOT by companies like Microsoft or the open source movement. That's a developer-centric view of the industry.
Instead, realize that it is dominated by individuals and companies who simply use tools and technology as a vehicle to meet the requirements of the real world - and make a difference.
Microsoft have released a Supplemental UI Library for Visual J#.NET 1.1 which provides much of the functionality described in the Java 2 JFC Swing specification, as well as much of the functionality found in the JDK 1.2 java.util package. Updated versions of the Microsoft Visual J# .NET class libraries are also included.
This release is intended for academic users, and is not supported for commercial use. I think that's understandable in regards to the Swing classes, as it is in Microsoft's interest to steer Java users towards the .NET libraries.
However, the 1.2 java.util package is another thing. That should have been included in a new main Redistributable release with the updated libraries. Well maybe not - strong naming can be a curse as well as a feature.
The bad news is that it's hard to determine where Microsoft's implementation starts and ends. One gets JDK 1.1.4 plus some of this and some of that.
Additionally, we now have an installation mess - one has to install the J# Redistributable on top of .NET, and then install this Supplemental Library on top of that. Just want the latest versions of the Microsoft Visual J# .NET class libraries but not the Supplemental Library? Then you have to install the Supplemental Library, then uninstall it leaving behind the updated libraries.
Looking for a faster Java?
Don Browning performed an
interesting "unscientific" performance test of
C#, Java, and C++ and subsequently provided the source code.
These were his original results...
Time to find the first 7 magic numbers:
1.4.0 JVM - 8.1
seconds
1.4.2 JVM - 5.2 seconds
1.0.3705 CLR - 3.9 seconds
Good Old
C++ - 2.3 seconds
I thought it would be interesting to throw both the C# and Java versions
against Alintex Script .NET
1.1 and see the results. Please note that Alintex Script .NET 1.1 has not
been publicly released and is not available from the Alintex web site.
Update: Alintex Script isnow available for
download
Isn't the result afaster Java than Java?
Time to find the first 7 magic numbers:
Alintex Script
1.1 C#code (1.0.4322 CLR) -3.7
seconds
Alintex Script 1.1Javacode (1.0.4322 CLR)
-3.85 seconds
In the screenshots below, I explicitly specify the compile (/c)
command line option so that the scripts do not receive any performance advantage
from already being in the script cache. I also specify the entry points (/et)
because both scripts use a non-standard script entry point.
I added a single line to both scripts, that displays the script
elapsed time for interest. Alintex Script provides a ScriptInfo class that can
be used within a script to obtain information such as the script start time and
elapsed time.
* Java and all Java-based
marks are trademarks or registered trademarks of Sun Microsystems, Inc. Visual J# .NET has been developed independently by Microsoft. It is
neither endorsed nor approved by Sun Microsystems,
Inc.
In my last post, I showed the code for a "hello world" script supported by the soon to be released Alintex Script .NET 1.1.
Before discussing some specific product features, I though I might provide a birds eye view of a slightly more useful script - one that say, looks up a registrant on a whois server. I'll leave a discussion of the code for another day, however it can be seen in the Portable Script File Description mentioned at the end of this post.
Because Alintex Script supports multiple script files in different languages within one script, I can break out the functionality into different script files. In this case I'll put most of the functionality in a C# script file and create a separate VB.NET script which implements a Windows Form for output. That way I can reuse the Windows Form in other scripts.
The result of my coding efforts are the two script files shown below. The csx extension indicates that this is a shell executable file and also that this is a non-standard C# file.
How do you run this script and look up 'microsoft.com'? Well one way is to type the following at a command prompt...
> axwscript /a:microsoft.com whois.csx textdialog.vb
The /a (argument) option stops Alintex Script from assuming microsoft.com is a file. The result is reasonably predictable...
Mind you, Alintex Script provides language extensions which allow one to produce a single script that is supported on the console, through a Windows interface and in an unattended mode through what is called the Gui/Cui/Unattended (GCU) design pattern.
It means that I can type the following...
> axwscript whois.csx textdialog.vb
which will result in me being prompted for the information required...
entering 'microsoft.com' displays that VB form...
OK, what if I want to give this file to someone else, and what if I want to include some author and script information? You can do that too.
Alintex Script lets one pack scripts, settings and author information into a Portable Script File. In this case I would type the following:-
> axwscript /pack:whois.psf whois.csx textdialog.vb
The result is a script file named 'whois.psf' which can be run from the command line as well as by clicking on it's icon.
One can get a summary of the contents in a Portable Script File by using the /info option...
> axwscript /info whois.psf
Doing so will display script information in your browser...
Please note that Alintex Script .NET 1.1 has not yet been released and is not available from the Alintex web site.
Update: code is now available from http://www.alintex.com/scripts-exe.aspx
As my previous "hello world" post generated a lot of emails, I thought I would offer some clarification.
The syntax shown is supported by Alintex Script .NET 1.1 - a product due for release next week. That previous post was designed to illustrate that the product not only supported the .NET libraries, but also Microsoft's implementation of the JAVA JDK 1.1.4 libraries.
I'm going to use this weblog as a mechanism to provide more pre-release information, however, in the meantime, I should point out that the previous post's "hello world" is not the shortest possible version...
A new "Hello World" coming next week?
As time gets closer to ship, I'm pretty happy with obfuscated code like that shown below. Especially, as all those "|" symbols really are the same symbol in the PE file - rather than different (and hence traceable) undisplayable symbols.
Isn't that really is what obfuscation is about? Making it so hard (or so uneconomic) that one's target audience wouldn't bother?
A free VS.NET utility I find helpful is QuickJump by Thierry Bouquain. Its character incremental search lets you quickly find, then jump to code.
More Posts
Next page »