.NET

.NET (pronounced "dot-net") is a marketing term from Microsoft. There are at least four things (see also Kevin Kenny's riff [1] on the same subject) that go by that name:

The .NET Framework: A programming environment for web services, dynamic HTML sites, GUI and console programs. Or think of it this way: A big library of common business "controls".
Visual Studio .NET: The latest version of Microsoft's programming IDE. Of course this supports the .NET Framework and a number of languages that Microsoft has ported to it.
The .NET Services: A bundling term for Microsoft's server applications IIS, MS SQL Server and others. This is not new technology, and these applications do not use the .NET Framework. They can be used as building blocks in applications written with the .NET Framework.
The .NET OS: The name given during development to what is now "Windows 2003." "Windows 2003" comes with the .NET Framework and probably adds some .NET Framework features for applications that are not built with the .NET Framework, like code assemblies. [Who knows more?]

The .NET Framework is a layer on top of Win32. Some of its main features are the use of byte code (intermediate language, IL), programming language independence and language cooperation, a common runtime library for all languages (CLR), the new language C# and a sandbox environment with code verification ("managed code").

Microsoft has submitted core parts of the framework to the ECMA for standardization, and the ECMA has basically accepted the submission and started a workgroup for this. An interesting part of the discussion is a call for scripting access to .NET [2]. The ECMA thinks of ECMAScript (JavaScript) here, but Tcl could be used in this place as well. The standardization efforts allow reimplementation on other platforms and Mono http://www.go-mono.com/

is such an effort.

Tcl and Tk could be ported to use the framework instead of the OS API. This would gain us even more interoperability (although we already have that through COM, as cooperation with COM is built into .NET). It would also allow Tcl and Tk to run in a "managed" environment, i.e. Tcl and Tk could be "trusted" in the Microsoft sense of the word.

For a discussion of .NET and Tcl (and Perl and Python) from the Microsoft perspective, see this article in Microsoft's Technet: "Taking Advantage of Windows 2000 and the .NET Platform" [3].

A "Shared Source" version of the CLI and the C# and JScript compilers is at [4]. This code has an actual example "platform-independent UI (PIGUI)" that uses Tcl and Tk.

The ideas of the PIGUI example have been picked up by the TickleSharp project at Novell [5] (thanks to Kevin Vadnais <kevin.vadnais@hp.com> for mentioning this on c.l.t.).

The .NET Framework including the C# compiler can be downloaded from [6].

Discussion edit

TclBridge allows full access to Tcl/Tk from all .NET languages.

That's through COM right? We have a number of packages referenced on the COM page that could help there.

JJM 2003-01-09: Yes. It provides bi-directional communication with COM components. Tcl/Tk scripts may be evaluated from the COM side and new Tcl commands may be added via methods of COM objects. This allows for full Tcl/Tk based scripting of any application capable of using COM objects.

Please see http://www.tclbridge.com/html/CreateCommand.html

and http://www.tclbridge.com/html/CreateDynamicCommand.html

for more information.

JJM 2008-09-16: Also, see Eagle.

DKF 2003-01-06: Note that porting to the IP/CLR is in effect equivalent to porting to Java or Parrot; you're really forced to write a Tcl parser in the target language and then produce an implementation of all (well, a useful subset in the first instance) the commands in the target language too. The key problem is that the current Tcl bytecodes are defined at a level that is meaningful to Tcl, not at a level that virtually any other bytecode operates at; very few bytecodes have an opcode for "increment-hash-entry-and-fire-attached-traces"! Given that, you're either just producing another language reimplementation (like Jacl) or you're taking on the hard task of defining how to go from Tcl to the fairly-common low-level register-based bytecode engines that so many other languages use. Which would be nice and useful, but is a really huge (and definitely complex and deep) task...

CL follows up: perhaps readers are wondering what's wrong with Donal; hasn't Microsoft emphasized that .NET is "multi-lingual" and "standards-based" and so on? Yes, that's how Microsoft markets .NET. Keep in mind that Microsoft feels no obligation to link its marketing to any particular engineering reality. Developers can, in principle, use any language for their .NET work. The reality is quite a bit different, Microsoft collectively knows this, but feels no urgency to correct the confusion.

BR: As I see it the major problem is that Tcl is interpreted (bytescodes are mostly a compile-time feature) while the language portability features of .NET seem to be targeted at (limited to?) compiled languages only. That's why I found the scripting aspect interesting, as ECMAScript/JavaScript also is an interpreted language with facilities like eval.

TAC Tcl runs best under its own virtual machine ;-) The problem with generic (or multi-lingual) virtual machines (byte-code interpreters) is that they provide yet another abstraction above the CPU's machine code (which may not be geared toward your favorite language's semantics anyway). Forth runs fastest on Forth chips (where the machine code and possibly the microcode/wiring is optimized toward running Forth). Sorry, I'm digressing... But anyway, Java runs best under the JVM. In the end, you want your bytecode to match the semantics of your language. I would be interested in finding a language built on top of the Java Virtual Machine (JVM) that runs faster than Java. The idiosyncracies of common .NET languages (C#) set the bytecode for .NET. You can get other languages to play (like Tcl), but be prepared for complex semantic mappings.

Jeffrey Hobbs just had this to say on the very topic on comp.lang.tcl:

 From: Jeffrey Hobbs <JeffH@ActiveState.com>
 Subject: Re: TCL/TK .NET
 Newsgroups: comp.lang.tcl
 Date: Tue, 07 Jan 2003 03:32:10 GMT
 Organization: ActiveState

 [...] Tk does not become any more x-platform than it currently is
 by having an IL implementation of Tcl.  While this may be interesting
 in the research sense now, I'm not sure that there is much practical
 value.  The .NET CIL is not well suited for dynamic languages, but
 there is also no limitation in using the current Tcl binaries on
 Microsoft's .NET OSes, as .NET is (currently) just an adjunct to the
 rest of the system.

 I'm not against seeing such an implementation, but I do try and
 understand the motivation behind seeking way (and trying to make
 sure people aren't misled by MS's misleading marketing mumbo-jumbo).

ulis 2002-01-07:

Does not Tcl be already running under all Windows? What is the interest of having Tcl included in the .NET platform?

My understanding is that Tcl is for all and .NET only for Microsoft.

Sean Halliday 2003-01-17:

I think some people might be missing the big picture with .NET. The .NET IL gets compiled to native code at run-time. This makes it a big win over other byte-code languages that interpret the byte code. There is also a common type system (CTS) and common runtime. This allows code that was written in various languages to all work together. I am a big fan of Tcl/Tk and have been using it for about 8 years. I am now a big fan of .NET and I hate COM and ActiveX. Don't prejudge .NET just because it is from MS. As for Tcl/Tk being a .NET language, I don't know. I think if it was taken seriously, it could be done quite well. The big question is whether the .NET framework will really catch on. Anyway, I currently have Tcl and .NET working together just fine (without the need for COM.) I just write managed C++ code to access .NET. Since unmanaged code can call managed code, the Tcl commands I add can access .NET. I have even hosted C# windows forms in a Tcl app (again without ActiveX or COM.) This is the other really big win with .NET, it is very easy to write interfaces to existing C/C++ libraries - I didn't even need a Wizard :-)

BR: That last sentence sounds more like Tk to me ;-)

Sean brings up an interesting idea on interopability. Let Tcl be as it is with an adaptor handling the connection. But I'm wondering (don't have VC7, so I can't test), as C# is so close to the C syntax, can Tcl's generic code be compiled by C# ?? If so, could a new platform directory be made for ngws ? -- DG

CL reacts: so many ideas are showing up here. I know I am confused.

Davy, it would be entertaining to compile Tcl with C#. Maybe I'll try that when I can make time ... In any case, don't think you need VC7; there are open-source C# compilers. I'm working to make this more obvious on the C# Wiki page.

In fact, an "adaptor" already exists: TclBridge. I'll let Joe Mistachkin explain more on that subject.

I agree that there's an open question about whether .NET will succeed and be pervasive. No, wait, there isn't; MS's marketeers already have enough to ensure its longevity. The library is so big and compelling to conventional development shops, that they're switching to it from MFC, win32api, and such, so .NET is successful. With just a bit more lubrication, that'll be interpreted as success for the whole architecture.

I'd love to learn more about the contrast Sean Halliday sketches between COM and .NET. Jacob Levy, for example, has written me that "Every '.NET' object is a COM+ object with some more stuff thrown in. If you don't need that additional stuff (you only need it if you're running on the CLR -- the common language runtime, their name for their VM) then calling through COM+ should work fine. Calling in the other direction -- from a '.NET' object to an old-style COM object -- might not work.

I think Tcl has adequate mechanisms for talking to COM+ objects. All '.NET' objects support type information, so it should even be easy to auto-generate a procedure that makes this efficient as well as type-safe." That matches my understanding. So how can one like .NET so much while abhorring COM?

Sean Halliday 2003-01-18

You really have to work with .NET and COM to understand why .NET is head and shoulders better than COM. Interoperability with COM and .NET is quite easy. You can easily access COM objects in .NET (one line of code brings in the COM object interface). There are tools to convert/wrap .NET code with COM. I think there even may be one to convert .NET controls to ActiveX. I wrote a Tcl/Tk based program that I eventually made an ActiveX control and it was a MAJOR pain! The .NET control version was WAY easier to write and didn't even require a wizard. This does not have much to do with the topic except that .NET will not just catch on because MS is pushing it. Every programmer I have talked to about using .NET likes it a lot - and they were all very sceptical :-)

peterc 2008-02-19: Some big reasons why .NET is an interesting technology and may be useful for Tcl coders: (1) Dotnet on Windows and Mono elsewhere makes it fairly multiplatform, (2) It's a big tickbox in today's job and IT procurement market, (3) Dotnet is well documented, while COM isn't anymore, (4) There may be some efficiency pay-offs by calling Dotnet functions instead of their Tcl/Tk counterparts, particularly on Windows, by virtue of the Dotnet variant not using Tk's X11 emulation layer (XLEL).

SC: This all sounds great and good but is there any evidence that .NET will be anything but the next generation of the Windows API? I realise that mono is more cross-platform but will it ever catch on enough that one could hope to deploy to Mac and Unix based systems and gain some advantage over the current Way of Things?

Technical points: COM interoperability is slower than pure COM or pure .NET (true?). REGASM.EXE can be helpful in interoperability, because it creates the type libraries and registers them for COM.

Tcl Interpreter in C# Application code example for embedding Tcl in C# Application

A Tcl/.net interop solution would allow Tcl script to use the entire .net framework and any other CLS compliant assembly without sacrificing the huge investment made in the existing Tcl interpreter and associated libraries. If someone were to write such a bridge they could take advantage of the ScriptingExtensions for .net library that has been developed for rubydotnet. [7]

JH: has written, "... in general, Tcl works just fine in the .NET world as an unmanaged component. Since that's true of a lot of stuff, there is nothing wrong with just assuming that your Tcl works fine on a '.NET desktop'."

Peter da Silva:

Calling Tcl from C# isn't all that exciting to me. What I want to see is something like this:

#!/usr/bin/tclsh

using System
import Console -from System

Console WriteLine "Hello World!"

Whether this is a managed or unmanaged application isn't all that interesting, I'm just here for the scripting.

See: Tablet PC

Rather remarkably, there's a Jacl.NET, tclcsharp and Eagle.

Even more remarkable is that Jacl runs unmodified in .NET, through use of IKVM [8] and [9]

[veb] 2010-09-30 18:04:34:

Hi friends,

I am working on an application which involves both TCL command line and C# .NET based application. C# .NET application is a console based wherein it outputs the data it sniffs to the console. At a same time, it wait for the user input. We want tcl to invoke this application .exe and then inject some input to the console such that it is read by the .exe console application. I had success invoking the .exe from tcl command based utility, however, I did not get the control back to the tcl which I should. I do not have any previous experience working with it. Can you please advice what causing the problem? Is it the .NET framework or something else??

Thanks

Page Authors edit

BR
others ...

Category Glossary

Category Porting