Y
yitang
Unregistered / Unconfirmed
GUEST, unregistred user!
Hot topic on dn.codegear.com
http://blogs.codegear.com/NickHodges/archive/2006/12/14/30532.aspx
为什么我们用.NET.开发IDE？
许多年以前，我们公布了一个产品-C#Builder，这是我们使用新的IDE框架（代号伽俐略）推出的第一个产品，自从那以后我们已经使用伽俐略开发了Delphi8、BDS2005、BDS2006。伽俐略是自发布Delphi1发布以来公司对IDE第一次做的主要升级！一开始只是单一的IDE，但从BDS2005开始它已经成了多开发平台，包括 C#、Delphi win32，Delphi.NET、C++Builder。目前它还相当不错！我希望它将来会更好！
伽俐略一个关键的特征是它依赖于.NET，目前所有产品的版本都依赖.NET 1.1环境，后续的版本会使用.NET 2.0。这个情况引起了一些人的不安，特别是那些藐视.NET的Win32程序开发人员。
用两个角度去看待.NET平台，两个角度对我们来说都是合适的。一个是从我们是开发工具生产商的角度，另一个角度是，我们公司销售着相当复杂的软件包。
首先，.NET是开发人员写代码依托的平台，它是一个很大的功能库，而这些库对开发人员来说开发起来比以前更简单了，作为一个开发工具开发供应商，我们想要生产出能让你在.NET下开发的工具，对我们来说，.NET是我们客户所乐意转向的平台，所以，我们要为他们推出能开发.NET程序的工具，当然，想要做到这点，我们很自然的非得在电脑上安装.NET framework不可。强调一点，你不可能在一台未安装.NET framework的电脑上开发.NET程序。
第二点，.NET有着功能强大的代码库，这些成千上万的功能很有使用价值并且很显然，它们可以很好地再利用。
所以，.NET有着如此相当强的功能以致于开发人员不必重新建立、创建它们（只复用吧）。像Delphi的VCL/RTL，.NET framework做了很大提升，开发人员在开发的时候它能提供很多的代码。
正是第二点原因使得伽俐略使用.NET framework，如果不利用，它们只是仅仅徒有如此大量的素材！如果我们不用，我们不得不重新开发已经存在的成千上万的功能，我们得维护他们并且不断的开发，如果我们使用.NET,就不必那样做了，这不是代码库精髓所在吗？另外，如果我们支持.NET开发，使用公共代码库就变得有意义了，那样我们就不必在Win32和.NET上做同样的事了！
因此，如果你只是纯粹的Win32开发人员，你也必须安装.NET framework来运行IDE。但是，如果你只是认为它只是一个代码库，也许它应该不会像你所想象的那样糟糕（你也不得不装载那么多的VCL包，当你想研究它是恐怕还找不找代码）。.NET是windows Vista的一部分，可以知道将来的操作系统也会集成它，为什么不利用操作系统而自己去开发一套呢？另外，伽俐略本地运行-它不是虚拟机或解释型代码。所有的集合都会被及时编译成原生代码到你机器上运行。
如果你从这个角度看.NET framework--作为操作系统的代码库，使用它们，使用它们创建像我们的BSD如此复杂的软件是很用意义的。
Why We Use the .Net Framework for Our IDE
A couple of years ago, we released a product called C#Builder. It was the first release using our new IDE framework called Galileo. Since then
we've used Galileo to produce Delphi 8, BDS2005, and BDS2006. Galileo was the first major overhaul of our Windows IDE since Delphi 1 was released. It started out as a single personality IDE, but BDS2005 saw it become a multi-personality release, including C#, Delphi for Win32, Delphi for .Net and C++Builder. It's has served us fairly well so far, and I expect it to do
so going forward.
One key feature of Galileo is that it relies on the .Net Framework. All the versions so far rely on the 1.1 version of the framework, but the forthcoming version will use the .Net 2.0 framework. This fact has caused a certain amount of consternation for some folks, particularly Win32 developers who, for whatever reason, disdain .Net.
There are really two ways to look at .Net. Both of those ways come into play for us. One comes into play if you look at us as a producer of development tools. The other if you look at us as a company that sells a rather complicated software package.
First, .Net is a platform against which developers write code. It is a large library of functionality that is exposed in a way that makes it pretty easy for developers to build applications on top of. As a Developer Tools vendor, we want to produce tools that you can use to code for .Net. Thus, for us, .Net is a place where our customers want to go, and so we produce tools so that hey can create .Net applications. To do
that, of course, we naturally have to install the .Net framework on your machine. Makes sense -- you can't develop for the .Net framework without have it installed on your development machine.
But the second way to look at .Net is as a really powerful library of code. There's tons of functionality in it that is useful and obviously reusable. And of course, the .Net framework is a whole lot of functionality that a developer of a large software package do
esn't have to reproduce or build themselves. Sort of like the VCL/RTL in Delphi, the .Net framework do
es a lot of heavy lifting when it comes to providing a lot of code that developers want to use.
It is this second reason that Galileo uses the .Net framework. There is just simply too much great stuff in there not to take advantage of it. If we didn't use it, we'd have to reproduce a ton of the functionality that already exists, and that we'd have to deliver anyway. We'd have to maintain it and continue developing it. By using it, we do
n't have to do
that. And that's the whole point of code libraries, right? In addition, if we are going to support .Net development, then
it makes sense to use a common code base so that we do
n't have to implement the same thing on Win32 and on .Net.
So, if you are a Win32 developer only, yes, you have to load up the .Net framework to run the IDE. But if you just think of it as a code library, maybe it won't be as bad as you think. (You also have to load up a bunch of VCL packages as well. There's really no way to get around code libraries when you get right do
wn to it.) The .Net framework comes installed as part of Vista, and so it is pretty much going to be part of the operating system going forward. And why wouldn't we want to take advantage of the operating system rather than creating our own libraries? In addition, it runs natively -- it's not a virtual machine or interpreted code. The assemblies are JITed into asm code native to your machine.
So if you look at the .Net Framwork that way -- as a code library that is part of the OS -- it makes sense to take advantage of it and use it to build a complicated piece of software like our Developer Studio.
http://blogs.codegear.com/NickHodges/archive/2006/12/14/30532.aspx
为什么我们用.NET.开发IDE？
许多年以前，我们公布了一个产品-C#Builder，这是我们使用新的IDE框架（代号伽俐略）推出的第一个产品，自从那以后我们已经使用伽俐略开发了Delphi8、BDS2005、BDS2006。伽俐略是自发布Delphi1发布以来公司对IDE第一次做的主要升级！一开始只是单一的IDE，但从BDS2005开始它已经成了多开发平台，包括 C#、Delphi win32，Delphi.NET、C++Builder。目前它还相当不错！我希望它将来会更好！
伽俐略一个关键的特征是它依赖于.NET，目前所有产品的版本都依赖.NET 1.1环境，后续的版本会使用.NET 2.0。这个情况引起了一些人的不安，特别是那些藐视.NET的Win32程序开发人员。
用两个角度去看待.NET平台，两个角度对我们来说都是合适的。一个是从我们是开发工具生产商的角度，另一个角度是，我们公司销售着相当复杂的软件包。
首先，.NET是开发人员写代码依托的平台，它是一个很大的功能库，而这些库对开发人员来说开发起来比以前更简单了，作为一个开发工具开发供应商，我们想要生产出能让你在.NET下开发的工具，对我们来说，.NET是我们客户所乐意转向的平台，所以，我们要为他们推出能开发.NET程序的工具，当然，想要做到这点，我们很自然的非得在电脑上安装.NET framework不可。强调一点，你不可能在一台未安装.NET framework的电脑上开发.NET程序。
第二点，.NET有着功能强大的代码库，这些成千上万的功能很有使用价值并且很显然，它们可以很好地再利用。
所以，.NET有着如此相当强的功能以致于开发人员不必重新建立、创建它们（只复用吧）。像Delphi的VCL/RTL，.NET framework做了很大提升，开发人员在开发的时候它能提供很多的代码。
正是第二点原因使得伽俐略使用.NET framework，如果不利用，它们只是仅仅徒有如此大量的素材！如果我们不用，我们不得不重新开发已经存在的成千上万的功能，我们得维护他们并且不断的开发，如果我们使用.NET,就不必那样做了，这不是代码库精髓所在吗？另外，如果我们支持.NET开发，使用公共代码库就变得有意义了，那样我们就不必在Win32和.NET上做同样的事了！
因此，如果你只是纯粹的Win32开发人员，你也必须安装.NET framework来运行IDE。但是，如果你只是认为它只是一个代码库，也许它应该不会像你所想象的那样糟糕（你也不得不装载那么多的VCL包，当你想研究它是恐怕还找不找代码）。.NET是windows Vista的一部分，可以知道将来的操作系统也会集成它，为什么不利用操作系统而自己去开发一套呢？另外，伽俐略本地运行-它不是虚拟机或解释型代码。所有的集合都会被及时编译成原生代码到你机器上运行。
如果你从这个角度看.NET framework--作为操作系统的代码库，使用它们，使用它们创建像我们的BSD如此复杂的软件是很用意义的。
Why We Use the .Net Framework for Our IDE
A couple of years ago, we released a product called C#Builder. It was the first release using our new IDE framework called Galileo. Since then
we've used Galileo to produce Delphi 8, BDS2005, and BDS2006. Galileo was the first major overhaul of our Windows IDE since Delphi 1 was released. It started out as a single personality IDE, but BDS2005 saw it become a multi-personality release, including C#, Delphi for Win32, Delphi for .Net and C++Builder. It's has served us fairly well so far, and I expect it to do
so going forward.
One key feature of Galileo is that it relies on the .Net Framework. All the versions so far rely on the 1.1 version of the framework, but the forthcoming version will use the .Net 2.0 framework. This fact has caused a certain amount of consternation for some folks, particularly Win32 developers who, for whatever reason, disdain .Net.
There are really two ways to look at .Net. Both of those ways come into play for us. One comes into play if you look at us as a producer of development tools. The other if you look at us as a company that sells a rather complicated software package.
First, .Net is a platform against which developers write code. It is a large library of functionality that is exposed in a way that makes it pretty easy for developers to build applications on top of. As a Developer Tools vendor, we want to produce tools that you can use to code for .Net. Thus, for us, .Net is a place where our customers want to go, and so we produce tools so that hey can create .Net applications. To do
that, of course, we naturally have to install the .Net framework on your machine. Makes sense -- you can't develop for the .Net framework without have it installed on your development machine.
But the second way to look at .Net is as a really powerful library of code. There's tons of functionality in it that is useful and obviously reusable. And of course, the .Net framework is a whole lot of functionality that a developer of a large software package do
esn't have to reproduce or build themselves. Sort of like the VCL/RTL in Delphi, the .Net framework do
es a lot of heavy lifting when it comes to providing a lot of code that developers want to use.
It is this second reason that Galileo uses the .Net framework. There is just simply too much great stuff in there not to take advantage of it. If we didn't use it, we'd have to reproduce a ton of the functionality that already exists, and that we'd have to deliver anyway. We'd have to maintain it and continue developing it. By using it, we do
n't have to do
that. And that's the whole point of code libraries, right? In addition, if we are going to support .Net development, then
it makes sense to use a common code base so that we do
n't have to implement the same thing on Win32 and on .Net.
So, if you are a Win32 developer only, yes, you have to load up the .Net framework to run the IDE. But if you just think of it as a code library, maybe it won't be as bad as you think. (You also have to load up a bunch of VCL packages as well. There's really no way to get around code libraries when you get right do
wn to it.) The .Net framework comes installed as part of Vista, and so it is pretty much going to be part of the operating system going forward. And why wouldn't we want to take advantage of the operating system rather than creating our own libraries? In addition, it runs natively -- it's not a virtual machine or interpreted code. The assemblies are JITed into asm code native to your machine.
So if you look at the .Net Framwork that way -- as a code library that is part of the OS -- it makes sense to take advantage of it and use it to build a complicated piece of software like our Developer Studio.