Lambda the Ultimate

inactiveTopic .NET Questions?
started 11/28/2000; 11:59:47 AM - last post 12/3/2000; 1:37:23 PM
andrew cooke - .NET Questions?  blueArrow
11/28/2000; 11:59:47 AM (reads: 1104, responses: 5)
I'm off to an MS conference on .NET tomorrow and the day after. Anyone got any questions they'd like answering? Apart from "what is the difference between .NET and .COM for users?"?

Chris Rathman - Re: .NET Questions?  blueArrow
11/28/2000; 12:50:50 PM (reads: 1147, responses: 0)
My only question is about security. Is the security scheme the same as the Java Sandbox?

I read something on ZDNet about how the next generation of Windows will only run applications that have authorized digital signatures. That's all well and good for the ActiveX world, but network apps should be able to be run in a sandbox in order to reduce the danger of runaway programs.

Security is not just for the protection of the end user, but also for us programmers as well. I don't want the liability of having to debug a bunch of brittle Window's machines that just happened to go south when I roll a new software version.

Ehud Lamm - Re: .NET Questions?  blueArrow
11/30/2000; 2:10:59 PM (reads: 1170, responses: 0)
I am not following .NET too closely so I have no specific questions (what's the advantages over the JVM??).

But I am sure the presentaions in the conference will have plenty of URLs. Be great if you share them with us.

andrew cooke - Re: .NET Questions?  blueArrow
12/3/2000; 11:48:52 AM (reads: 1151, responses: 0)
A few notes on C#/.NET after attending a MS developers conference (thanks to Intertrader Ltd, for sending me, but these notes were written in my own time and express my personal out-of-work opinions, not those of my employers):

- .NET is not COM, but has two (apparently only slightly) related components: First, a common runtime environment for VB, C# and (partially) C++. Second, XML based web services.

- Although the .NET runtime (CLR) includes many services, it is more than "another COM wrapper". COM objects still exist, separately, and can be accessed from .NET languages, but the services provided by the CLR are more closely integrated. For example, it appears that class-like services can be subclassed, errors handled as exceptions rather than return codes, and memory management is provided.

- 14 languages are available (most not by MS). I didn't have time to write down the whole list while the overhead was displayed, but believe that they include: Perl, Python, Cobol, Oberon, OCaml, ML, Haskell, JScript, Oz, Mercury, C#, VB, Eiffel (which makes 13).

- Language implementations can either take advantage of the CLR or, more compreehensively, provide services (libraries) to other .NET languages. A service appears to be a class that follows certain restructions (CLS) - single inheritance, safe code (see below), etc. (I may be using the term "service" incorrectly here, but you get the idea).

- The source language of a CLS compliant service should be irrelevant to a user of that service.

- All 14 languages can apparently provide (as well as use) .NET services. This struck me as odd, when some don't support classes (ML, for example) - when I asked the "experts" later, the response was first "what's ML?" and then "Hmm. Who own's it - you'll have to ask them". The idea of a language wasn't (i) commercial and (ii) didnt support OOP, was apparently very odd... (if that sounds like a cheap shot at MS I should add that I really enjoyed the conference).

- C# is, apart from the .NET library, closer to C++ than Java (IMHO). It has things like enums, conversion methods (but not constructors as in C++) and even pointers and explicit relative positioning of structure components in memory (to allow binary level compatability with data structures provided by alien libraries, for example). However, objects are "reference values" (on the heap), so the C++ emphasis on consturctors has gone.

- C# still has a preprocessor. It is restricted to definitions and simple logic, so C# also introduces attributes which are commands inside [] that instruct the compiler to take special action. They are used for a variety of purposes - from adding properties to classes (for documentation) to requesting the compiler to provide an HTML driver interface to a method (data is retruned as XML - this is also how object persistence is implemented and, since XML is ubiquitous in the next set of MS server products this can presumably be automated).

- The use of pointers indicates that the code is "unsafe". Unsafe code affects security (see later). In the last talk I went to we were told that a cast that might fail is also an unsafe operation, but I think this was either an error or a less strict definiton of unsafe, because (as far as I can see) C# suffers from the same problems as Java with containers (which store objects as object instances which must be cast back to the appropriate subclass when extracted). I can't believe that all C# code that uses containers will be rated as unsafe, especially when any cast error is detected at runtime (throwing an exception).

- C# has virtual method versioning, which Chris mentioned a while back (this detects when a method is introduced "below" what was previously the "bottom" virtual method in a class hierarchy). Methods have to be marked explicitly as virtual and it is also possible to have "value types" which are like classes, but have no inheritance and are allocated on the stack (structures with methods).

- Various quirks (like the value types, the "as" operator that saves a test for class type, and being able to turn IEEE numerical handling off) indicate that MS is trying to keep the potential performance of C# code close to C++ (esp. managed C++ - see later). The speakers all seemed to follow the school of thought that advocates discarding lifebelts before taking to the roughest seas...

- All .NET languages compile to a platform independent Intermediate Language. This is then either passed to a JIT at execution time or compiled on installation. When I asked there was no explanation for how MS would avoid the problems that face Java developers in ensuring that the appropriate JIT version is available on the client machine.

- Perhaps assemblies will help with this. Applications are now packaged as directory trees that include all components - assemblies. Each application can then use local libraries (or, depending on configuration, global libraries). This is to avoid problems when different versions of the same library exist.

- Security doesn't seem to be finalized in detail, but will be based on the program's requirements (familiar to anyone who's written for the MS Java VM and wanted to get outside the sandbox). Programs will be able to request priveliges (like access to files). Whether access is granted or not will depend on a variety of factors: unsafe/safe, source (both from signatures and delivery method), privilege requested, etc. I asked for more details about signatures, but couldn't get a firm answer - it is "unlikely" that everything will need to be signed, although quite possible that an administrator and/or user will be able to configure a machine so that this is the case. You might read that as "it would be possible, if you were sufficiently lax with security, to run unsigned code".

- Interestingly, the C# talks were not very popular. The convention had two halls for talks and parallel talks on C# and ADO (I believe) were swapped, moving C# to the smaller hall. The final two (parallel) talks were optional - one was a repeat of the C# talk. But at the last minute the C# talk was moved to an even smaller hall and an extra VB talk was also run (yes, the C# talk was then packed, but it was a very small room....).

- Finally, something I've not heard much fanfare over: MS are introduciing "managed C++". By including an optional keyword in the class definition the memory management can be handed over to the .NET runtime. Given this, and the availability of the .NET libraries to C++ and (fully OO) VB, what is the point of C#?

- Oh, and has anyone managed to get MS's search engine to recognise C#? It seems to return matches to C.

andrew cooke - Re: .NET Questions?  blueArrow
12/3/2000; 11:50:11 AM (reads: 1129, responses: 0)
Hmmm. I haven't put a note about this on the front page - is it worth one?

[OK, done now]

Chris Rathman - Re: .NET Questions?  blueArrow
12/3/2000; 1:37:23 PM (reads: 1134, responses: 0)
Hmmm. I haven't put a note about this on the front page - is it worth one?
Yes, you should provide a link to your message on the main page.

All 14 languages can apparently provide (as well as use) .NET services. This struck me as odd, when some don't support classes (ML, for example)
I read an article a while back about how the ML people were planning on getting around the reliance on classes. Can't recall the details, but IIRC they did have it figured out.

Security doesn't seem to be finalized in detail, but will be based on the program's requirements (familiar to anyone who's written for the MS Java VM and wanted to get outside the sandbox). Programs will be able to request priveliges (like access to files).
It still kind of disturbs me that I don't see a roadmap for the .Net security. I figure they'll pretty well follow the path laid out by Java, but it would be nice to see a firmer committment. Security is not something that you can tack on later - it needs to be integrated into every aspect of the language.

I asked for more details about signatures, but couldn't get a firm answer - it is "unlikely" that everything will need to be signed, although quite possible that an administrator and/or user will be able to configure a machine so that this is the case.
The only reason I mentioned it was that there was ZDNet article about Whistler not running unsigned apps.

Interestingly, the C# talks were not very popular.
I think part of that is the fact that it's not gonna be too difficult for all those Java programmers to pick up C# in a very short amount of time. The secret though is not in the language but in the .Net library and framework. C# is at the heart of the design, so I think if .Net is successful, C# will be successful.

C# still has a preprocessor.
Actually I don't like the preprocessor. I've seen too much C/C++ code ruined by abuse of preprocessors and include files.

C# is, apart from the .NET library, closer to C++ than Java (IMHO).
I would agree that C# is closer to C++ than is Java, but I still think that C# is much closer to Java than C++. For sure, the list of attributes has been rearranged and many of the things that MS wanted to add to Java have been tacked on to C++. All and all, though, the class/interface methodology is just a java spinoff.