Quote:Original post by Anonymous Poster
1. What if someone invents new language which won't fit the Microsoft's intermediate language?

Unlikely. How many languages have been created over the last 25 years that didn't "fit" the limited architecture of existing CPU's? Just because the CPU or bytecode engine doesn't support a particular operation doesn't mean it can't be done. there's more than one way to skin a gerbil.

Quote:What if that new language inroduces new cool features which can be implemented EFFICIENTLY ONLY IN MACHINE CODE?

The CLR supports the ability to include CPU specific executable code. No different than inline assembly in C++ source.

Quote:How about a new type system which CAN'T OR SHOULDN'T be dumbed down to the common type system of CLI?

First that's dictated by the CLR which is a PART of the CLI. When was the last time a new primitive data type was introduced?

Quote:How about new base class set which CAN'T OR SHOULDN'T be dumbed down to base class library of CLI?

Exactly how much of the .NET architecture do you actually KNOW about?

Quote:Think of countless possiblities of research in programming languages. Do you believe CLI/CLR/MSIL/whatever-it's-named technologies predicted EVERYTHING?

No different than dealing with the limited instruction set and capabilities of existing CPU's. Research is also not the same thing as production. When researching programming languages not everything needs to run at 100% efficiency. If the current CPU or bytecode environment doesn't support or address an existing requirement it can be given it's own implementation. Do you not remember compiler flags for linking software based floating point libraries?

Quote:2. what if someone invents new Garbage Collection algorithm that is better than that in CLR? (correct me if I'm wrong, but I assume CLR implements own GC algorithm that is shared by all .net-compatible languages?)

Much easier to replace the garbage collection mechanism ONCE rather than requiring all applications to be recompiled with the new libs containing it. This has been done with Java many times over the years. Since the GC is part of the .NET framework you only have to relace it ONCE and all applications immediately benefit from it. No different than updating to newer versions of a shared library.

Quote:But what if those implementation improvements require COOPERATION from THE NEW LANGUAGE, what brings us back to the point 1 ?

If you're going to play "what if" at least go read the ECMA specs so you have an idea of what, if any, constraints might cause problems.

Quote:Original post by Anonymous Poster
well, you may be wrong. otherwise I think Microsoft is building a system that will not work at all, will be made by idiots and will be used only by idiots!!!
How could exist a OS that does not support C programming? (Well I mean C/C++). How do they write the OS? How do companies make programs that work in ugly languages? Even worse code that may be interpreted!!! Videogames wouldn't go much far...

Easily. There is no requirement to support old language without fixed data types. One of requirements of OS might be it MUST be writen in language with fixed data types, and intermediate code (or both intermediate code and source code) must be included in executable.
Lets look for example on:
Data types in assembly
BYTE db 8 bits
WORD dw 16 bits two BYTE
DWORD dd 32 bits two WORD
QWORD dq 64 bits four WORD
so assembly could be used in more restrictive OS, if CPU instruction set will be compatibile.

jnode is OS writen in Java. You can also use lastest version of macro assembly to do it.

Well some companies are using C++ because of all that expensive tools they bought without thinking. They have also a large codebase, and source files with workarounds against compiller bugs.

Quote:Original post by Helter Skelter
When was the last time a new primitive data type was introduced?

I'm a different AP, but you do realize that there are languages:

1) With different primitives
2) Without primitives
3) With type systems that won't fit the mold

right?

Quote:Original post by Fixxer
that would be such a dumb move on microsofts part to exclude C/C++.

It's not likely that MS will abandon C++ entirely. They may eventually only support Managed C++ which isn't all THAT bad. But even if MS were to totally drop C and C++ support it would eventually be taken up by others. LCC, an ANSI-C compiler, was designed to target a broad range of CPU's. It has code generators for Alpha, Sparc, X86, and *start clapping* .NET. The fact that it was done quite easily and very quickly is a good indication of the versatility of the CLR. It's also one of the smallest code generators for LCC (IIRC second only to a generic bytcode generator). The source code of LCC (and the .NET backend) is readily available.

It's unlikely that compilers like GCC will be supporting it anytime soon though but that's mostly due to how the different subsystems in GCC are implemented. the Java compiler parts of GCC are pretty much an extremely ugly HACK. Although I don't keep up on GCC devel much anymore they are addressing it (just very slowwwwwwly).

Quote:Original post by Anonymous Poster
I'm a different AP, but you do realize that there are languages:

1) With different primitives

Yes. And how many of them are supported natively on x86 platforms? If you have to implement special handlers for a primitive data type in ECMA-335 why is it any different than doing the same thing for x86?

Quote:2) Without primitives
3) With type systems that won't fit the mold

right?

It's still no different than #1. In those cases it simply becomes a user defined type. It's no different than what compilers already do when they have to support data types that are not handled by the CPU.

for those curious about LCC and using C to write .NET applications:


http://www.cs.princeton.edu/software/lcc/


Keep in mind that only minimal support is supplied - meaning no libs. But even with minimal support there's been an amazing number of apps run under .NET that were compiled with LCC.

Quote:Original post by Martee

Quote:Original post by Emmanuel Deloget
Consumers are already upset with the current MS "only WinXP SP2 is a supported OS" strategy (it makes Win2k obsolete after only 5 years when the industry standard are 10 years (and 20 in the defense industry)).

What other consumer/business desktop operating systems are/were supported for 10 years?

MS-DOS.

Quote:Original post by markr
Will Longhorn potentially include some optional "trusted computing" profile setting which allows you to restrict users from running arbitrary native-code applications? Possibly, but if it does, it will apply equally to C++, Delphi etc.

Mark

.NET already has restrictions on executing code marked as "unsafe" which is anything using pointers. Unless the user grants the app permission .NET won't launch it.


Of course we all know how good users are at deciding which viru^H^H^H^Hprograms they should run.