**Summary** '''.NET''' (pronounced "dot-net") is a marketing term from [Microsoft]. There are at least four things (see also [Kevin Kenny]'s riff [http://groups-beta.google.com/group/comp.lang.tcl/msg/cbba275d4454fb67] on the same subject) that go by that name: The .NET Framework: A programming environment for [web service]s, 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 [http://www.ecma-international.org/MEMENTO/TC39.HTM]. 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" [http://www.microsoft.com/technet/prodtechnol/iis/deploy/depovg/takeadv.asp]. A "Shared Source" version of the CLI and the C# and JScript compilers is at [http://msdn.microsoft.com/library/default.asp?url=/downloads/list/netdevgeneral.asp]. 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 [http://forge.novell.com/modules/xfmod/project/?ticklesharp] (thanks to Kevin Vadnais for mentioning this on [c.l.t.]). The .NET Framework including the [C#] compiler can be downloaded from [http://www.microsoft.com/downloads/details.aspx?familyid=4fe5bdb5-c7a7-4505-9927-2213868a325b&languageid=f49e8428-7071-4979-8a67-3cffcb0c2524&displaylang=en]. [BR] (Updated 2004-02-04) ---- **Discussion** [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. 2003-01-09 [JJM] -- 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. 2008-09-16 [JJM] -- Also, see [Eagle]. ---- 06-Jan-2003: ''[DKF] -'' 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 TVM (Tcl 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 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 Jan 17/2003 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 (Jan 18 2003) 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. [http://rubydotnet.sourceforge.net] ---- [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'." ---- 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. -- Peter da Silva ---- [Tablet PC] ---- Rather remarkably, there's a [Jacl.NET] and [tclcsharp]. Even more remarkable is that [Jacl] runs unmodified in .NET, through use of IKVM [http://www.ikvm.net/] and [http://weblog.ikvm.net/allentries.aspx] ---- !!!!!! %| [Category Acronym] | [Category Porting] |% !!!!!!