Hi, jim2003-ga:
Just in Time Compilation
========================
To a "simple" end-user perhaps the most compelling benefit of .Net
technology is the JIT compilation. This allows Microsoft to "migrate"
an application from one hardware platform to the next in a uniform and
transparent manner.
Although .Net applications still appear to be packaged as .exe and
.dll files, as Windows programs have from the 16-bit days, under the
hood there is something very novel. The typical "end-user" code that
is supplied is actually in Common Intermediary Language (CIL or more
often simple IL), which is compiled (just in time) upon the first
invocation of a program or library (and the results of the compilation
saved into a new "assembly cache" so that it will in all probability
only be compiled once per session).
Therefore next year when you get that 64-bit Windows system we've all
been dreaming about, old .Net applications will not need to be
specifically upgraded by their vendors. The migration from 16-bit
Windows to 32-bit Windows was quite a hassle, by comparison. Example:
I'd supplied a 16-bit DLL to a client who distributed it to employees
to use with an Excel spreadsheet for modeling retirement benefits.
When it came time to migrate to a 32-bit version of Windows and hence
of Excel, the whole ballgame had changed. Not so with .Net
applications; the 64-bit implementation of the .Net common runtime
should simply pick up the IL distributables and go with them,
transparently handling all the recompilation and linking issues to
take advantage of new processor instructions and any new runtime
optimizations.
Details
=======
Although Microsoft's main focus with the Common Intermediary Language
was language interoperability, rather than cross-platform portability,
who looks a gift horse in the mouth?
A couple of notes about this JIT compilation/IL assembly approach.
Long time users will recall that Pascal and some other language
systems supported "cross platform portability" by providing
distributables in p-code, an approach not unlike that taken by Sun
Microsystem's Java. One issue there, however, was performance,
because the "intermediate" code was interpreted, not compiled by the
p-code engine (or Java virtual machine). Here Microsoft avoids the
performance issue and even turns the situation to some advantage (the
one-time compilations per session and caching seem to have benign
performance penalties).
A related issue is the ease with which a "high level" language like IL
might be subject to decompilation attacks, where a proprietary
implementation is at stake. To handle this Microsoft offers an option
for tough encryption of the IL code. I've not worked with the
encryption mechanism myself, so I don't have any first-hand knowledge
of how well or easily it applies, but presumably this is key to
obtaining commercial vendor buy-in for the .Net platforms.
One more comment about IL: it's not a standard set in stone.
Although we may expect any extensions to IL (or more properly, CIL) to
be conservative (in the sense of forward compatibility), new .Net
languages will almost certainly require such extensions. One of my
first questions to Microsoft was whether any of the .Net languages
would support coroutines. That ability, which is a big convenience in
implementing AI-like very high level languages, is not supported in
the existing IL standard. See here, however, for proposed extensions
to IL for supporting functional languages like Haskell:
[ILX: Extending the .NET Common IL for Functional Language
Interoperability]
http://research.microsoft.com/~dsyme/papers/babel01.pdf
Ubiquitous XML
==============
For the power-user such as yourself I expect the most important
implication of the .Net technology will be the degree to which XML
documents and interfaces which rely on related standardization become
commonplace.
XML has become a raging fashion in data manipulation applications of
all sorts. I have an essay I could tack on, if you are interested, in
Microsoft's proposed use of XML in data mining tools, and of course
the SQL Server 2000 support for XML is substantial even if not yet
built down to the DTS level.
But it is within the Microsoft Office suite that the most rapid
incorporation of XML standards have taken place. Beyond viewing an
XML document with your IE browser, you can now open such documents in
Excel or Word. For an example of using Access 2002 to import and
export XML documents, see here:
[XML in Office XP: Part II]
http://msdn.microsoft.com/library/en-us/dnoffpro01/html/XMLinOfficeXPPartII.asp
Since Microsoft was one of the key contibutors to the development of
the XSD (XML Schema document) approach to XML validation, they have
naturally been quick to support the "Schema" approach in Office tools
(as well as in the underlying DOM parser engine, MSXML).
Here's a more updated article on the use of XML in Access, to simplify
dynamic linking of tables:
[Put XML to Use in Access XP By Danny Lesandrini]
http://www.databasejournal.com/features/msaccess/article.php/1465481
Details
=======
Although XML itself has achieved widespread adoption quite
independently of the .Net technology, Microsoft is both lowering the
bar to using SOAP and other XML related protocols with their VS.Net
tools _and_ making an intentioned effort to promote the use of XML
within such tools for documentation of interfaces.
If you've enjoyed the (increasingly reliable) use of Intellisense
technology (to pick out the correct syntax for object declarations and
method calls), the kicker with .Net tools is that your own interfaces
(and not just Microsoft's system interfaces) can now become
incorporated in the Intellisense "help" through the magic of XML
documentation that you are prompted to supply as you develop your own
.Net classes and methods.
For explanations of how this works, see here:
[XML Documentation Tool]
http://msdn.microsoft.com/library/en-us/dnvssamp/html/vbcs_XMLComments.asp
[XSLT Transformations and XSLT Intellisense within the .NET IDE]
http://www.codeproject.com/macro/dotnetxslt.asp
regards, mathtalk-ga |
Clarification of Answer by
mathtalk-ga
on
06 Jun 2003 20:40 PDT
Hi, Jim:
I see in your "request for clarification" that you are uncertain "who
is answering what" and that you'd "like to withdraw the question".
First, note that this second answer was submitted by me, subsequent to
the Clarification of Question you posted up top for me to do so.
Recall that, after reading my comment, you asked that I give one or
two "for instances" about how a layman might use .Net.
I response I have discussed:
1) How .Net benefits a "simple" end-user, who benefits passively from
.Net technology (because of how it works behind the scenes). For
instance, you might upgrade your computer from 32-bits to 64-bits, and
the .Net applications would continue working, taking advantage of the
new processing instructions, without any vendor-supplied upgrades.
2) How .Net benefits a "power" user like yourself, who may work with
Access data pages and other MS Office suite products (including
limited amounts of VB programming to support those activities). For
instance you might work with XML documents directly in your Access
databases or Excel workbooks.
Your request to "withdraw" the question thus has me a bit confused. I
feel I've taken a very conservative approach to answering your
question. If there is something about my answer that you would like
to have clarified, I would be happy to do this.
The procedure for requesting a refund for a question to which you did
not receive a satisfactory reply is described here, near the bottom of
the page:
http://answers.google.com/answers/help.html#followup
The directions there explain what information will be required to
process a refund request.
I sincerely hope that there is something which I can clarify for you
to make my answer acceptable. If not, I hope that the Google Answers
experience has been beneficial for you in spite of the unsatisfactory
nature of the two answers posted (first by jbf777-ga and then by
myself).
best wishes, mathtalk-ga
|
