Is .NET a runtime service or a development platform?
It's both and actually a lot more. Microsoft .NET is a company-wide initiative. It includes a new way of delivering software and services to businesses and consumers. A part of Microsoft.NET is the .NET Frameworks. The frameworks is the first part of the MS.NET initiate to ship and it was given out to attendees at the PDC in July. The .NET frameworks consists of two parts: the .NET common language runtime and the .NET class library. These two components are packaged together into the .NET Frameworks SDK which will be available for free download from Microsoft's MSDN web site later this month. In addition, the SDK also includes command-line compilers for C#, C++, JScript, and VB. You use these compilers to build applications and components. These components require the runtime to execute so this is a development platform. When Visual Studio.NET ships, it will include the .NET SDK and a GUI editor, wizards, tools, and a slew of other things. However, Visual Studio.NET is NOT required to build .NET applications.
How likely it is for C# to become a general-purpose (meaning: not MS-specific) language and if so, have any other vendors committed to providing compilers on any non-Windows platforms?
It's hard to answer this right now. I have been programming in C# almost exclusively for about the past year and I love it. It only took me a few days to learn most of it since it is very similar to C++. It was designed to compliment the common language runtime and I think that it's unlikely to gain much momentum if decoupled from the runtime. However, you never know. Microsoft is submitting C# to the ECMA standards body so any company will easily be able to produce their own C# compiler however, without a runtime, the compiler itself is not that useful. I'm not aware of any companies currently working on their own C# compiler. Certainly, porting the runtime to another OS is no small undertaking.
Can you tell us specific practical problems that C# can fix better than Java?
I must be honest with you: I have never programmed in Java. I know what C# offers the C/ C++ programmer: simpler syntax, components that seamlessly fit together, type safety, and so on. Other people should be able to address the C# <-> Java comparison.
Will ADO+ be the preferred and most efficient method to access databases from C# or will it have it own (or .NET) class wrappers for the OLEDB API?
The .NET class library includes a System.Data namespace with many types for database access. These wrappers will be the best (and most efficient) way for a C# programmer to access data.
Can C# be used to develop Windows applications or is it soley used for developing distributed applications?
C# can absolutely be used to develop classic-style Windows applications. Actually, this is more a function of the runtime, not the language. So, the runtime supports console apps, GUI applications, NT Service applications, simple components which can be used in applications, web pages and so on. You can't write a device driver but that's about all I can think of that the runtime doesn't support.
What is the C# relationship to WinForms?
Win Forms is a set of classes in the .NET class library that wrap Win32 windows, brushes, pens, etc. Any language targeting the runtime (including C#) can construct instances of these types and manipulate them. This is how you would create an app like Notepad, Calc, or Wordpad. I know that Win Forms has similarity to J++'s WFC library but I also know that there have been some major changes.
Rumor has it that the C# language has been submitted to the ECMA for ratification. Is this true and what impact do you see that having on other companies adopting it as a general language (such as C and C++)?
Yes, it is true. I pretty much answered this in question 2.
Which will be the role of ATL and COM in the new .NET technologies?
The .NET frameworks offers a replacement for many existing libraries, like ATL, MFC, C runtime library, standard template library and so on. .NET programming is significantly easier than using any of these older technologies. For this reason, I suspect many developers will move away from using the older technologies. The older technologies can buy you performance however; so, some people that are very concerned about this will stick with what's around. As for COM, developing components with .NET is orders of magnitude easier and the interoperation between components pretty much happens for free. Again performance may be an issue for some. And, for the time being COM+ services, like transactions, are not being offered directly to .NET code. You can still access these COM+ services but .NET code must incur an interoperability transition, which translates to a performance hit.
Why was the templates feature not carried over from C++ to C#?
Again, this is more of a runtime issue than a C# issue. First, templates are difficult to implement and Microsoft choose not to do the work for Version 1 of the product. They may do templates or something similar in future versions. Second, since the runtime is a multi- language runtime, introducing templates means that all languages targeting the runtime would be required to support templates in some form. There are a lot of issues here that need to be carefully considered.
Will C# replace the pseudo keywords that clutter ATL COM code with real keywords? Examples: OLE_COLOR, BOOL, VARIANT_BOOL, and DISPID_XXXXXX.
Absolutely, all types have new names as provided by the .NET class library.
We've seen managed extensions, but aside from that, what future does C++ have at MS and in .NET?
C++ is unique in that it is the only Microsoft language that allows the developer to write managed and unmanaged code. So, I can easily see developers writing in unmanaged C++ for performance-critical algorithms and then using managed C++ for type-safety and component interoperability. I'm sure Microsoft will keep C++ going for years to come: device drivers need it, Windows is built with it, SQL Server< Exchange, and other BackOffice products will probably use C++ for a long, long time.
If .NET supports ActiveX/COM, how will security be assured if a C# application runs from within a browser?
The .NET runtime offers code access security, which allows an administrator/user to configure security based on code identify. By default, any code downloaded via the Internet or intranet is untrusted and will not be able to access files and other resources. In fact, when I build a console application and run it from a network share, I get an exception when it tries to access certain resources. If I copy the same file to a local disk directory and run it, it runs fine. Code access security is integrated with the runtime and is too deep a subject to cover here.
With regards to the .NET runtime, do I need it on the machine that I deploy C# apps on?
Yes. All managed apps need a manager; the runtime is the manager. Microsoft will eventually package the runtime so that it is freely redistributed. For now, end-users will have to install the full .NET SDK from MSDN web site (when available). This is similar to how VB developer must ship the VB runtime today.
There has been mention of being able to derive C# classes from VB classes. Is this true and where can we see an example of how to do this?
This is true. In fact, any language that targets the runtime can derive from any type created in another language. Also, the Visual Studio debugger fully supports debugging across languages. Each entry in the call stack window shows the function on the stack and the language that the function was written in. This is very cool and got a round of spontaneous applause when shown at the PDC. There are samples in the .NET SDK that demonstrate how to do this. It's really quite simple. Actually it just happens, there is nothing for you to do. You can also throw exception across language boundaries as well for error handling.
Can I derive a C# class from a C++ class? If so, how?
Same as the answer above: Any managed language can inherit from a type in another other managed language. If you use native C++, then you can't do this, however.
Will the new version of MFC have the option of working in a managed environment?
I haven't been tracking the new version of MFC but I'm pretty sure the answer is no. MFC is all unmanaged just like it has always been. For managed applications, Win Forms is the window manager that people should use.
If the new version of MFC will operate in a managed environment, will it have the option of building desktop Win32 apps and not needing .NET runtime support?
I'm pretty sure MFC is unmanaged and will never require the runtime.
Stroustrup has been quoted as saying "I have not expressed a technical opinion on C#, and I don't plan to do so. C# is yet another proprietary language specialized for Microsoft's Windows system." Do you agree or do you think C# is more of a generic language open to other platforms?
C# is a language designed for the common language runtime; not Windows. The CLR can be ported to other operating system like Linux and Solaris and if the CLR is there, then C# will probably be there as well. In the grand scheme of things, C# is not that important or interesting. It is a syntax checker that spits out intermediate language consumable by the runtime. You can love C# or hate C# - your choice. I happen to love it and think is the best programming language for the types of applications I write.
I heard a rumor that VB7 will allow static linking of the runtime, like MFC. Is there any truth in this? If so, will C# also be able to create standalone apps?
This is absolutely not true. No language will able to statically link to the runtime.
Does C# still use resource files? If not, what mechanism is provided to allow for localization?
The .NET frameworks designers have created a new resource model. Resources can be embedded in EXE or DLL files the way Win32 resources are or resources files can now be stand-alone files like a single jpg or bmp file. There is also the concept of fall-back cultures. If the Swiss German resource can't be found, the runtime looks for the German resource. If the German resource can't be fond, it looks for the "default" resource. Each language will typically be built and shipped as a separate assembly rather than packaging everything up into a single file. Like code access security, a full discussion of the new resource model is too much to put here.