【導(dǎo)讀】會有一定的幫助。盡管所有的Windows操作系統(tǒng)在表面上看來完全不同，但從。Windows到WindowsServer2021，在內(nèi)核上都有相同的WindowsAPI。演化和擴(kuò)展API的過程，并非是替換它。向后兼容性是Windows技術(shù)的極其重要的特性，也是Windows平臺的一個長處，但它有一個很大的缺點。每次某項技術(shù)進(jìn)行演化，增加了新功能后，都會比它以前更。很明顯，對此必須進(jìn)行改進(jìn)。Microsoft不可能一直擴(kuò)展這些開發(fā)工具和語言，如果要得到一種簡單而專業(yè)化的語言、環(huán)境和。開發(fā)工具，讓開發(fā)人員輕松地編寫優(yōu)秀的軟件，就需要一種新的開端。這就是C#和.NET的作用。所有新特性，以及在最近20年來出現(xiàn)的面向?qū)ο蟮木幊谭椒?。在繼續(xù)介紹前，必須先說明，向后兼容性并沒有在這個演化進(jìn)程中失去。程序仍可以使用，.NET也兼容現(xiàn)有的軟件。因此，.NET能夠提供現(xiàn)有COM組件的包裝器，以便.NET組件與之通信。最近，許多Inter使用IP4運行，IP4也稱為IPv4。Studio.NET2021，就會得到兩個完全獨立的IDE。另一方面，C++在ANSIC++語言定義中有其自己的根。

　　

【正文】 d about whether a loop takes 1,000 or 1,050 machine cycles to run through, and you need to clean up your resources the millisecond they are no longer needed. C++ is likely to continue to reign supreme among lowlevel languages in this area. C lacks certain key facilities needed for extremely high perfor 7 mance apps, including the ability to specify inline functions and destructors that are guaranteed to run at particular points in the code. However, the proportions of applications that fall into this category are very low. .NET will run on Windows 98, 2021, XP, and 2021. In order to write code using .NET, you will need to install the .NET SDK unless you are using Windows Server 2021, which es with the .NET Framework and already installed. Unless you are intending to write your C code using a text editor or some other third party developer environment, you will almost certainly also want Visual Studio .NET 2021. The full SDK isn’t needed to run managed code, but the .NET runtime is needed. You may find you need to distribute the .NET runtime with your code for the benefit of those clients who do not have it already installed. The language independence of .NET does have some practical limitations. I L is inevitably going to imple ment some particular programming methodology, which means that languages targeting it are going to have to be patible with that methodology. The particular route that Microsoft has chosen to follow for IL is that of classic objectoriented programming, with single implementation inheritance of classes. Besides classic objectoriented programming, IL also brings in the idea of interfaces, which saw their first implementation under Windows with COM. .NET interfaces are not the same as COM interfaces。 they do not need to support any of the COM infrastructure (for example, they are not derived from IUnknown, and they do not have associated GUIDs). However, they do share with COM interfaces the idea that they provide a contract, and classes that implement a given interface must p rovide implementations of the methods and properties specified by that interface. We have now seen that working with .NET means piling to IL, and that in turn means that you will need to use traditional objectoriented methodologies. However, that alone is not sufficient to give us language interoperability. After all, C++ and Java both use the same objectoriented paradigms, but they are still not regarded as interoperable. We need to look a little more closely at the concept of language interoperability. To start with, we need to consider exactly what we mean by language interoperability. After all, COM allowed ponents written in different languages to work together in the 8 sense of calling each other’s methods. What was inadequate about that? COM, by virtue of being a binary standard, did allow po nents to instantiate other ponents and call methods or properties against them, without worrying about the language the respective ponents were written in. In order to achieve this, however, each object had to be instantiated through the COM runtime, and accessed through an interface. Depending on the threading models of the relative ponents, there may have been large performance losses associ ated with marshaling data between apartments or running ponents or both on different threads. In the extreme case of ponents that are hosted as an executable rather than DLL files, separate processes would need to be created in order to run them. The emphasis was very much that ponents could talk to each other, but only via the COM runtime. In no way with COM did ponents written in di fferent languages directly municate with each other, or instantiate instances of each other—it was always done with COM as an intermediary. Not only that, but the COM architecture did not permit implementa tion inheritance, which meant that it lost many of the advantages of objectoriented programming. As with any programming language, IL provides a number of predefined primitive data types. One characteristic of IL, however, is that it makes a strong distinction between value and reference types. Value types are those for which a variable directly stores its data, while reference types are those for which a variable simply stores the address at which the corresponding data can be found. In C++ terms, reference types can be considered to be similar to accessing a variable through a pointer, while for Visual Basic, the best analogy for reference types are objects, which in Visual Basic 6 are always accessed through references. IL also lays down specifications about data storage: instances of reference types are always stored in an area of memory known as the managed heap, while value types are normally stored on the stack (although if value types are declared as fields within reference types, then they will be stored inline on the heap).