More Technology Stuff, and your .NET questions answered
.NET is a big thing. A really, really big thing. You hear the hype, you read the reviews and white papers and write-ups, but it's not until you sit down and arrange the pieces around you do you realise that it's not just a new language and an updated UI. Everything has changed - and yet, everything you've ever done will still Just WorkTM (1). Well, pretty much everything.
 |
| Microsoft breakfast |
By now you have probably heard all this a million times but if you are like me then the more you hear the more you understand. If you feel you have heard all this way
too much then you can skip ahead to the bits where I complain about orange cheez.
For Windows programmers, the underlying Win32 framework is still there, but the way in which you interact with this is entirely new. The Common Language Runtime enables you to write code faster, easier, that will have less bugs, and will be more secure. Remember - you don't have to target .NET - you can continue to write your C++ unmanaged COM classes and handle your own threading and marshalling issues, and you can also continue to write your high performance device drivers using ASM and C - but for the rest of us who like having weekends there will be C++ with managed extensions, C# and VB (or FORTRAN, or COBOL, or Objective Pascal, or...).
And yet I still feel there is a little bit of reluctance to take on a new language such as C#, or to use managed extensions in C++, or to trust that the garbage collection will not go on strike. Is it because developers have spent so much time, and gone through so much pain to understand COM and threading models and esoteric VB hacks that they feel that with the new generation of tools this hard won and much valued knowledge will reset the pecking order so they are no longer the gurus they once were? Is there a fear that all their legacy code will no longer work? Or is there something more basic (the whole C# vs Java thing? The perceived cost? The "but VC6 still has bugs!" walk-before-you-can-run argument?). I would like to hear from you guys.
 |
| Microsoft morning tea. |
At the basic "show me an app" level WinForms replace the common controls you are used to. They work roughly the same, but smell slightly different and have a new light-beige cover. Designing your GUI is a lot easier. Adding controls to a form in the designer is intuitive, the controls are active while in the designer (eg add a clock face control and you see it tick along while in the designer). The property pages for controls is very VB-esque, but so much nicer. Those who have ever played with Delphi will start having some flashbacks when they start designing forms (not surprising considering who has been working on this). There are now "panels" that hold sets of controls (analogous to a Group Box), and controls can have their sides docked, meaning all resizing and repositioning logic is handled by the framework.
Drawing on the screen has also changed. GDI+ adds a slew of features such as JPEG/GIF/PNG etc support, anti-aliasing, alpha-blending, gradient brushes etc. ClearType text output (makes text look great, especially on LCD screens) has been sped up significantly. GDI+ is strictly 2D only and does not use hardware acceleration. Microsoft will be working with hardware manufacturers and expect to have hardware acceleration within 2 years. 3D support is a little hazy, but I would be extremely surprised if it wasn't included in the next release.
Writing your code can be a whole new experience. The Common Language Specification specifies common data types that are used across the languages. Obviously there are new languages - C# being the most notable, but C++ has managed extensions, VB7 is much improved, and other .NET ready languages are emerging all the time. Essentially you can now pick the language you are most comfortable with and code away happily knowing that anyone else can extend your logic by deriving new classes from your classes in whatever language they wish, or can use your components from any language/environment with similar lack of pain.
Web applications are also immensely different. Web Forms replace server side controls and remove the need to add logic to maintain state (such as the currently selected item in a listbox), plus they take care of providing the client with a representation of the control regardless of the clients capability or idiosyncrasies. ASP.NET replaces ASP and moves the spaghetti code model to a logic/display/event handler model. Everything is pre-compiled and you can use whatever language you want to write your web pages. IIS is improved in terms of performance, scalability, resource management and security. You want faster pages? The try experimenting with ATL Server to see if you can squeeze some more performance. Want to continue using your old ASP pages and COM components? No problemo. It'll work.
ADO.NET replaces the rowset mentality of ADO and provides a replacement in the form of DataSets. Accessing your database info is now done in a type safe object oriented way. It's more efficient, it's faster, it's less error prone and your code is far more readable. Again, everything is written on top of the existing ODBC data providers to ensure that everything is backwards compatible.
 |
| PIII Xeons. I think these were promotional giveaways or something... |
COM works in .NET using COM Callable Wrappers. Your COM clients don't even know they are using a COM control since it appears as a managed wrapper. All COM types are mapped to native .NET types. You can also use managed components in unmanaged code. Everything gets wrapped and packaged and called using COM Interop.
Remember, everything is built on top of the standard Win32. Most things have managed wrappers and most functionality is exposed - but in case there is a situation where you find a particular Win32 piece that you need then P/Invoke allows you to access any Win32 API from the OS. We also get source, and lots of it. Maybe not all of it, but the guys working on this stuff are pushing to get the source to as many of the base classes as possible out to us. To me this is a Good Thing.
The old horrible printing API has been wrapped to make it easier to use, and with new laws requiring that applications support accessibility features, the wrapping of the accessibility API will be a GodSend.
 |
| A very strange place. |
Coding conventions have also changed. VB programmers will not find things any different, but C++ developers may rue the lack of hungarian notation (or rejoice - your call), and there are no more all-caps names for
#defines and constants, and the old C-style
variable_name_with_underscores are definitely out. Instead we get
camelCase and
PascalCase style variable names. Not having
m_ or
lptstr in front of variables means that your property names will be a lot neater, but internally I always enjoyed being able to skim through code and be able to work out approximate variable types based on the variable's prefixe. Call me old fashioned.
The UI for beta 1 is, well, interesting. If you haven't ever used X-Windows then you may get a pleasant surprise. Otherwise the flat-look box-highlight menus and controls may look a little antiquated.
All this works on all platforms - everything from Windows 95 up to Whistler (what? No Windows 3.1?). Where the underlying OS doesn't support certain features (eg GDI+ features or Unicode) these will be implemented internally by .NET. .NET compact is definitely on the way and will be implemented on devices such as PDAs, cellphones and game boxes.
One interesting note for VB programmers: Visual Studio.NET contains migration tools that allow you to port your VB6 projects to VB7. They use an AI engine to intelligently port the code, and any areas that are ambiguous or problematic will be flagged and appropriate messages displayed.
(1) I'm not sure if this is trademarked yet but by the number of times I've seen it used it is merely a matter of time.
Your .NET questions
Chris Anderson has kindly sent back some answers to the .NET questions sent in by you guys.
Stephen Kellett: Will there be an instrumentation API for .net - similar in purpose (hopefully not implementation) to the Java Virtual Machine Profiler Interface (JVMPI)?
Chris Anderson: The CLR has a complete set of instrumentation APIs that profilers can use. I can't comment on partner plans, but we internally have a profiler and two debugger implementations that use the instrumentation and debugging APIs.
Paul Wolfensberger: When using ADO, often there are a set of flags that have to be ORed together for the variable you're going to pass....sadly this isn't type safe if the variable is something like a DWORD....I'd love to see something that allow the developer to specify something like: Use these values to create the unioned bit flag value.
Chris Anderson: C# has full support for enums. In addition there is a "Flags" metadata attribute that hints to the user that the values should be or'd together. Since enums are strongly typed, I think this solves your problem...
[Flags]
public enum MyEnum { Value1 = 1, Value2 = 2, Value3 = 4 }
string s = Enum.Format(typeof(MyEnum), MyEnum.Value1 | MyEnum.Value3, "G");
Jeremiah S. Talkar: Will there be support for the following features within the .Net platform:
Chris Anderson:
- We have a complete code access security system in the runtime. It is based on an evidence based system. We allow granular control over what permissions code is granted, and the host of the code (Internet Explorer, ASP.NET, etc.) can offer policy or evidence for loaded code.
- We have worked closely with the NLS team from Windows 2000 to deliver a fully features I18N and L10N system for .NET. We fully support unicode and have a binary and XML based resource system. All of our controls will be localized into (i believe) 8 langauges with complete support for all languages that Windows 2000 supports. Our visual forms designer for Visual Studio.NET supports visual localization of Windows Forms applications.
Jeremiah S. Talkar: Having watched Episode 5 of the MSDN show that contains some details regarding the WIN64 release for the Intel Itanium processor, I am definitely curious about things like pointer sizes (and hence available address space) in .Net for languages like C/C++ that expose pointers?
What design considerations are being taken to ensure that code runs (mostly unaltered) when .Net specific code runs optimally on future OS releases like WIN128, WIN256 etc? Or is the underlying OS irrelevant when running under .Net?
Chris Anderson: We will have a "System.IntPtr" data type that is a "pointer-sized-int" type. This will be 32 bits on Win32, 64 bits on Win64. This is similiar to the DWORDPTR defined for Win64 C/C++ libraries.
Jeremiah S. Talkar: A recent article posted on the www.javasoft.com site (An analysis on .Net) has reference to the fact that an ECMA standard C# is not of much use unless the CLR itself is standardized.
After thinking more about it, I tend to agree with this conclusion. So what I would like to know is whether the .Net team agrees with this point? If the answer is 'No', it would be nice if they can provide a justification. If the answer is 'Yes' then it would be nice to know what steps are being taken to address the same.
Chris Anderson: The CLI (Common Language Infrastructure) is part of the C# ECMA submission. The CLI definies the minimal "standard" runtime for the C# language. I am not part of the team working on the ECMA submission, so I can make specific comments about what is or isn't part of the submission.
Sandu Turcan : Ask them, please, if they've given any thought to adding expando-like functionality in .NET. Wouldn't you agree that being able to associate your own data with an instance of a class written by somebody else would make live easier? The implementation of this seems to be trivial - a hidden hashtable in "object", what raises questions is what do you map your data to. Is it strings? If so, then how do you make sure noone overrides your data?
Chris Anderson: There are some pretty severe performance implications with this. Specifically every object in the system would have 4 bytes extra for the Hashtable pointer. In addition you would now have two types of properties... expandos and real properties...
SomeObject o = new SomeObject();
o.MyRealProperty = value;
o["expando"] = value;
These expando properties wouldn't be strongly typed, and any struct (value type) would be boxed to put into the property bag.
However, we totally understand that languages will want to do this. The CLR reflection API allows for dynamic properties using IReflect and IExpando to allow people to find these. The JScript support in .NET uses these to offer expandos.
Next...
Seattle. Again..
- Security and Privacy
- Internationalization and Localization:
