现在很多人都说DELPHI6BUG太多，各位发表一下意见吧！500分，别混分啊！(0分)

to rainyu
我已跳过了
还好我聪明重建了datamodule 要不然......886....

出现dbc.dbi错误

ADOConnection1(在数据模板内)当连接到数据库并打开(即设Active为True)，ADOTable1(在
窗体内)的connection属性设为ADOConnection1后并也打开。然后把所有单元关闭。打开数
据模板把ADOConnection1关闭。再打开ADOTable1所在的窗体就会出现非法操作，D6被
Windows关闭，Is Over。

还有：如果，比如说，在SQL中建好了库T,表有t1,用ADOConnection1连接成功后，
ADOTable1的connection属性设为ADOConnection1后，TabelName为t1并打开
（ADOConnection1、ADOTable1都在数据模板内），然后关闭数据模板单元。
当SQL中的库T中的表t1名改为t2，即ADOTable1.TabelName的属性已无效了。
当再次打开时数据模板，也会出现上面的结局并数据模板再也打不开了。
有两个方法可以解决：
1，还原数据库把ADOConnection1连接关闭，然后再改数据库，再连接。（注意备注）
2，在程序里实际连接数据库，错了可以打开数据模板来改。

我感觉D6还可以罢，但就是有以下几点不好：
1.D6下写的程序到D5下完全打不开。
2.装两个系统时（win98andwin2000)时，D6只能装在其中的一个系统上。
3.支持D6的控件太少了。

我用的 6.0 在 windows 2000 常常发生代码不能自动查询的情况,还会提示无缘无故的错误.
很不爽!以前我以为是内存的问题,但是现在我把内存加到了 192M 还是那个鬼样...

请看李维老师的评论：
樂趣無窮，可能無限的新技術-Web Service


雖然電子商務的狂熱在最近似乎有減溫的現象，讓許多人能夠回歸到正常的步調之中，不過隨著電子商務而發展的軟體技術並沒有稍停腳步，反而更加蓬勃發展。因為由這些技術創造的應用早已成為許多人生活的一部份，甚至是開啟未來趨勢的基石。在目前最熱門且最被看好的技術便是所謂的Web Service了，那麼什麼是Web Service呢？

簡單的說，Web Service是一種想把全世界的Internet/Intranet變成一個虛擬計算環境的觀念和技術。在由Web Service組成的虛擬環境中使用者可以任何的用戶端軟體，例如瀏覽器，一般的Window或是Java應用程式或是電子行動設備等，來呼叫Web Service提供的服務。而Web Service本身則可以由任何的技術實作，例如開發者可以使用Delphi，Java，C/C++或是C#等的語言和工具來開發。

Web Service是建立在開放和標準的規格之上，允許異質的用戶端呼叫以使用它提供的服務。因此各種異質的用戶端必須使用一種共通的溝通標準才能夠順利的和由各種不同技術實作的Web Service互通。目前最流行而且最具潛力的溝通標準當屬SOAP了。
SOAP (Simple Object Access Protocol)是由Don Box起草，並且獲得IBM，Microsoft，Lotus和UserLand等大型公司支持而成為W3C標準之一的通訊協定規格。從SOAP的名稱中我們便可以知道它是讓用戶端呼叫遠端物件服務的一種機制。SOAP以XML標準封裝呼叫遠端服務的格式，有別於其他分散式物件模型呼叫特定的呼叫格式，例如CORBA的GIOP以及DCOM的ORPC。由於SOAP以XML封裝呼叫格式，因此它可以使用任何的實體傳輸層來傳送，例如HTTP，TCP或是SMTP等。也許讓我們使用一個簡單的概例來說明會讓各位更容易的瞭解。
假設現在我在Linux平台上以Java語言實作了一個Web Service，這個Web Service提供了一個服務GetSystemTime。這個服務接受一個使用者名稱和一個密碼，如果成功的登錄之後，這個服務便會回傳Linux平台目前的系統時間。那麼我可以使用Delphi以SOAP的標準封裝使用者名稱和密碼來呼叫這個在Linux平台上的GetSystemTime服務。例如下面就可能是由SOAP封裝的格式：


GordonLi
xx12yh_49


藉由SOAP，Delphi的用戶端應用程式可以輕易的呼叫Linux平台上的Web Service，而無需關心這個Web Service是由什麼技術實作的，或是存在於任何地方，更不需要以特定的二進位格式來封裝呼叫。因此藉由Web Service和SOAP，開發者可以輕易的整合各種異質平台，異質分散式物件模型，而充分的利用所有的計算資源，這在以前是不可能輕易做到的，同時Web Service和SOAP也為未來的發展開啟了另一扇的大門。目前Web Service已經在國外快速的蓬勃發展，各種Web Service也已經在Internet上供人使用，例如搜尋MP3的服務，或是查詢全世界各地氣象的服務等。相信Web Service和SOAP也將很快的在國內發展起來，也終將成為軟體開發人員必備的軟體技能之一。
Web Service本身包含了許多的意義，觀念和技術，在RUN!PC 2001年5月份的『解析Web Service的技術內容與意涵』一文中已經對於Web Service和SOAP有基本的介紹，讀者可以參考該文的說明。

本篇文章的內容在於討論Web Service的技術架構和實作的技巧，並且首先以Delphi 6做為說明如何實際的開發Web Service以及用戶端應用程式來呼叫Web Service。接著再說明如何使用Delphi開發的用戶端應用程式來呼叫Internet上由Java開發的Web Service，來向各位讀者展示Web Service和SOAP的開放性以及標準性。當我們成功的在本地機器呼叫了在世界上某一個角落，由某一個人使用某一種工具開發的Web Service時，相信讀者也會讚嘆Web Service和SOAP所帶來的無限可能和下一波的軟體技術的革命。



Web Service和SOAP的架構

那麼我們要如何才能夠知道每一個Web Service提供的服務？要如何才能夠呼叫到Web Service？又要到那裡找到適合的Web Service呢？簡單的說，Web Service提供的服務是以所謂的WSDL(Web Service Description Language)標準來敘述的，只要我們能夠取得特定Web Service的WSDL，就可以從其中瞭解它提供的服務，以及如何呼叫這個Web Service。
最後一個問題是如何找到適用的Web Service，在目前全世界已經有人公佈了許多的Web Service供人呼叫使用。此外IBM和Microsoft等公司也正在研擬所謂的UDDI標準以提供註冊，搜尋，交換和使用Web Service的標準，開發人員可以藉由UDDI找到需要的Web Service，當然我相信許多的Web Service將會由開發人員根據自己的需求而使用工具開發出來。

說了那麼多，可能讀者會想要知道到底Web Service要如何實作？要使用什麼語言或是工具才能夠撰寫的呢？事實上Web Service並不限定任何特定的工具或是語言才能夠開發，簡單的說你可以使用任何的工具或是語言來開發，甚至可以使用ASP/JSP等稿本語言(Script Language)來實作。當然，開發人員也可以結合各種不同的軟體技術和元件架構來開發。
下圖是以比較實體架構的觀點來敘述Web Service的觀念。圖中的用戶端藉由SOAP和HTTP通訊協定，透過Web Service Provider找到適合的Web Service，再呼叫它。而實體的Web Service可以是實作在Window平台的MTS/COM+或是.NET物件，也可以是實作在Linux/UNIX平台中的CORBA或是EJB物件。這個觀點是以各種元件模型來實作Web Service。







圖一 Web Service的架構示意圖


至於下圖則是以更細微的觀點來看Web Service的實體架構。在這個圖形中呈現了Web Service可以由ASP/JSP或是CGI，ISAPI的形式來實作，以服務用戶端的請求。開發人員可以把所有的Web Service企業邏輯實作在ASP/JSP/CGI/ISAPI/DSO之中。或是只把回應用戶端請求的邏輯實作在ASP/JSP/CGI/ISAPI/DSO之中，而把真正的企業邏輯實作在後端的元件模型之中，或是後端的應用程式之中，例如Delphi的DataSnap伺服器。







圖二 Web Service的實作架構圖


從上面的討論中可以知道，開發人員可以使用任何的技術實作Web Service，只需要根據標準輸出Web Service，就可以由用戶端呼叫使用之。
討論完了觀念之後，現在讓我們回到實際的實作層次中。雖然Web Service可以由任何的技術實作，但是開發人員仍然需要選擇一種方式來開發。開發Web Service除了實作Web Service的企業邏輯之外，也必須提供Web Service的WSDL，並且分發Web Service。由於目前使用Web Service的情形仍然以SOAP/HTTP型式呼叫，因此許多的Web Service也是以Web應用程式的型態實作，例如把Web Service實作成CGI或是ISAPI/DSO的型式，不過只要能夠處理HTTP的呼叫，Web Service也可以實作成一般的獨立應用程式，這一點是讀者必須瞭解的。

開發Web Service雖然不是非常的困難，但是它仍然需要許多的開發步驟和處理程序，這也仍然需要花費一些開發成本。在Borland最新推出的Delphi 6中，Borland特別提供了7個直接的Web Service元件，三個Web Service精靈以及其他數個相關的VCL元件來幫助開發人員快速的開發Web Service，更棒的是，開發人員也可以再結合Delphi原有的MTS/COM+/CORBA/EJB元件模型開發更具延展性的Web Service。下圖便是Delphi 6中直接和Web Service相關的Web Service元件組。







圖三　Delphi 6提供的WebServices元件


這7個Web Service元件可以讓開發人員呼叫遠端Web Service，自動產生Web Service的WSDL，以及進行SOAP/HTTP和Object Pascal語言之間的繫結(Binding)，以便讓Delphi的程式師能夠使用Object Pascal直接處理SOAP之中的訊息。
下圖則顯示了在用戶端應用程式和遠端Web Service之間如何藉由這些元件溝通，以及每一個元件之間的關係。由於Delphi 6是Window平台上的開發工具，因此它使用了Wininet.dll來傳送HTTP封包資訊。







圖四 Delphi 6 WebServices元件的功能示意圖


從上圖可以知道，Delphi 6用戶端應用程式藉由THTTPRIO呼叫遠端Web Service，而TOPToSoapDomConvert可以把Object Pascal的呼叫和參數自動轉換為SOAP封裝的格式資訊，再藉由THTTPReqResp傳送HTTP封包。而在伺服端THTTPSoapDispatcher則負責處理用戶端傳送來的SOAP/HTTP資訊，並且透過THTTPSoapPascalInvoker元件來自動啟動能夠處理這個SOAP/HTTP請求的Object Pascal程式碼。至於TWSDLHTMLPublish則能夠自動的根據Delphi實作的Web Service來產生WSDL並且輸出此WSDL讓用戶端應用程式能夠使用這個WSDL來呼叫Web Service。
說明了Delphi 6中有關Web Service的元件和其功能之後，現在就讓我們看看在Delphi 6中開發Web Service的步驟。下圖便是在Delphi 6中開發Web Service簡易的步驟：







圖五 使用Delphi 6開發 Web Service的步驟


首先程式師必須撰寫Web Service的核心邏輯，然後定義此Web Service的WSDL，以便讓用戶端能夠遵循標準呼叫。在實作完Web Service之後，接著程式師就可以使用Delphi 6提供的WebServices元件組來實作用戶端應用程式，並且藉由WSDL來呼叫Web Service。
在實作Web Service用戶端應用程式時，Delphi 6提供了非常彈性的方法，允許程式師使用Early Binding或是Late Binding，不像某些解決方案只允許使用Late Binding。這種設計可以讓程式師在開發Web Service解決方案時可以根據執行效率或是執行彈性來決定使用Early Binding或是Late Binding。
為了讓讀者能夠真正的瞭解如何開發Web Service系統並且範例Delphi 6在SOAP和Web Service方面的強勁功能，就讓我們使用一個實際的範例來說明如何使用Delphi 6快速開發Web Service和用戶端應用程式，並且結合資料庫來提供用戶端資訊。這個範例Web Service是把MYESSAYS資料表中的所有我寫的文章輸出給用戶端以便查詢資訊，而且不管用戶端是瀏覽器，一般的Window應用程式，或是Linux下的應用程式都可以。下圖便是儲存這些文章資訊的畫面：







圖六 範例資料表


至於這個範例的整體架構如下圖所示。文章資訊是儲存在InterBase之中，並且藉由Delphi 6的dbExpress來技術存取。至於實作Web Service的主體則是一個由Delphi 6撰寫的簡單Web應用程式。最後我們實作一個原生視窗應用程式藉由SOAP來呼叫此Web應用程式實作的Web Service。







圖七 實作Web Service的架構圖




步驟1 – 開發SOAP伺服端應用程式

首先程式師可以在Delphi中使用SOAP Server Application精靈來開發Web Service伺服器。在Delphi 6中我們只需要點選File|New|Others功能表，然後點選WebServices頁次即可看到下圖的畫面，然後再點選SOAP Server Application圖像。







圖八 Delphi 6的SOAP Server Application精靈


在點選了SOAP Server Application圖像之後，Delphi會詢問程式師要以那一種的實體型態來實作Web Service，如下圖所示。程式師可以選擇欲實作的程式型態，例如在這個範例中我選擇以Web App Debugger executable來實作，因為這個程式型態可以讓我們在開發Web Service時能夠輕易的除錯。當然，程式師也可以選擇以一般的Window應用程式來實作Web Service，而不使用SOAP Server Application精靈提供的下列實體型態的程式。







圖九 以Delphi 6的Web App Debugger應用程式的形式開發Web Service


在點選了圖九的程式型態和Ok按鈕之後，Delphi便會自動幫助程式師產生如下的Web模組。







圖十 Delphi 6建立建立的Web Module以及WebServices元件


在圖十的Web模組之中，Delphi自動產生的THTTPSoapDispatcher元件可以讓Web Server自動呼叫此應用程式，而TWSDLHTMLPublish元件則可以自動產生敘述此Web Service的WSDL內容。







圖十一 範例Web Service的主表單


現在再讓我們在這個Web Service程式的主表單中加入一個TLabel並且設定它的Caption特性值為『我的第一個Web Service』，如上圖所示。



步驟 2 – 定義Web Service的服務介面並且實作它

接下來的步驟便是真正的實作此Web Service。首先在Delphi 6中建立資料模組，並且使用dbExpress連結到InterBase：







圖十二 範例Web Service的資料模組，它使用dbExpress元件存取InterBase


點選File|New|Unit功能表定義如下的IMyEssays介面，這個介面定義了此Web Service提供的服務，用戶端應用程式可以呼叫GetEssayTitles函式取得所有文章的資訊，而這些資訊是儲存在TEssaysInfos的陣列中，這個方法展示了Delphi 6的Web Service可以處理複雜的資料型態。至於GetEssayContent則可以根據用戶端傳遞來的文章ID而回傳此文章的內容給用戶端應用程式。




unit uMyEssaysInf;
interface
uses
Types, XSBuiltIns, uEssaysInfo;
type
IMyEssays = interface(IInvokable)
['{1C8ABA87-455B-4430-9881-239F5FFE7F49}']
function GetEssayTitles : TEssaysInfos ; stdcall;
function GetEssayContent(const iID : Integer) : String; stdcall;
end;
implementation
uses
InvokeRegistry;
initialization
InvRegistry.RegisterInterface(TypeInfo(IMyEssays));
end.



接著我們定義儲存文章資訊的資料結構。為了讓文章資訊能夠自動傳遞回用戶端，我們可以在Delphi 6中從TRemotable類別繼承子類別，如此一來Delphi 6便會自動幫助我們處理資料Marshalling的問題。最後必須呼叫Delphi 6提供的RemClassRegistry物件來註冊這些類別。




unit uEssaysInfo;
interface
uses
InvokeRegistry, XSBuiltIns;
type
TEssaysInfo = class(TRemotable)
private
FEssayID : Integer;
FEssayTitle : WideString;
published
property EssayTitle : WideString read FEssayTitle write FEssayTitle;
property EssayID : Integer read FEssayID write FEssayID;
end;

TEssaysInfos = array of TEssaysInfo;
implementation

initialization
RemClassRegistry.RegisterXSClass(TEssaysInfo, 'http://www.w3.org/2001/XMLSchema', 'TEssaysInfo', '',False );
RemTypeRegistry.RegisterXSInfo(TypeInfo(TEssaysInfos), 'http://www.w3.org/2001/XMLSchema', 'TEssaysInfos');
finalization
RemClassRegistry.UnRegisterXSClass(TEssaysInfo);
RemTypeRegistry.UnRegisterXSInfo(TypeInfo(TEssaysInfos));
end.



現在到了實作ImyEssays介面的時候了，我們定義TMyEssays類別從TInvokableClass繼承下來並且實作IMyEssays介面。TInvokableClass類別可以讓用戶端從遠端呼叫。最後同樣呼叫InvRegistry物件註冊TmyEssays類別，以便讓THTTPSoapDispatcher元件可以啟動。至於IMyEssays介面之中的GetEssayTitles方法則是使用dbExpress從InterBase中讀取所有的資料，並且把文章的ID和名稱儲存在一個TEssaysInfo物件中，再把TEssaysInfo物件儲存在TEssaysInfos陣列中，最後回傳此陣列給用戶端。




unit uMyEssaysImpl;
interface
uses
SysUtils, Classes, InvokeRegistry, XSBuiltIns, uMyEssaysInf, uEssaysInfo, DB, HTTPProd, udmMyEssays, DBXpress;
type
TMyEssays = class(TInvokableClass, IMyEssays)
private
procedure CreateDataModule;
procedure FreeDataModule;
public
{ IISAPITutorials }
function GetEssayTitles: TEssaysInfos; stdcall;
function GetEssayContent(const iID : Integer) : String; stdcall;
end;
implementation
{ TISAPITutorials }

procedure TMyEssays.CreateDataModule;
begin
dmMyEssays := TdmMyEssays.Create(nil);
end;

procedure TMyEssays.FreeDataModule;
begin
if (Assigned(dmMyEssays)) then
begin
dmMyEssays.Free;
dmMyEssays := nil;
end;
end;

function TMyEssays.GetEssayContent(const iID: Integer): String;
begin
Result := '尚未實作, 請待續!!!';
end;

function TMyEssays.GetEssayTitles: TEssaysInfos;
var
iNo : Integer;
iID : Integer;
eInfo : TEssaysInfo;
TD: TTransactionDesc;
begin
CreateDataModule;

TD.TransactionID := 1;
TD.IsolationLevel := xilREADCOMMITTED;
try
dmMyEssays.sconnMyEssays.StartTransaction(TD);
iNo := dmMyEssays.sdsMyEssays.RecordCount;
SetLength(Result, iNo);
iID := -1;
with dmMyEssays.sdsMyEssays do
begin
while not Eof do
begin
Inc(iID);
eInfo := TEssaysInfo.Create;
eInfo.EssayID := FieldByName('EID').Value;
eInfo.EssayTitle := FieldByName('ETITLE').Value;
Result[iID] := eInfo;
Next;
end;
end;
finally
dmMyEssays.sconnMyEssays.Commit(TD);
FreeDataModule;
end;
end;
initialization
InvRegistry.RegisterInvokableClass(TMyEssays);
end.



現在這個能夠處理複雜資料的Web Service便藉由Delphi 6提供的WebServices元件和精靈完成了，接下來就是開發用戶端應用程式來呼叫此Web Service以取得文章資訊了。



步驟 3 – 開發用戶端應用程式呼叫Web Service

使用Delphi 6開發呼叫Web Service的用戶端應用程式更簡單，因為Delphi 6提供的WebServices元件組中的THTTPRIO元件實在是太方便了，我們只要使用物件檢視器設定THTTPRIO元件的WSDLLocation特性值為欲呼叫的Web Service的WSDL，那麼THTTPRIO元件便可以自動的處理所有呼叫Web Service的細節。
例如下面便是使用Delphi 6開發的用戶端應用程式，在這個應用程式的主表單上使用了一個THTTPRIO元件，並且在它的WSDLLocation特性值中輸入剛才開發的Web Service的WSDL檔案的位址。







圖十三 範例用戶端應用程式的主表單


接著在『 我的文章』按鈕的OnClick事件處理函式中撰寫如下的程式碼：




procedure TForm2.BitBtn1Click(Sender: TObject);
var
oriCursor : TCursor;
eInfos : TEssaysInfos;
iCount : Integer;
lStart, lEnd : Longint;
begin
ShowCaption;

StatusBar1.Panels[0].Text := '呼叫Web Service中...';
StatusBar1.Refresh;
lvMyEssays.Items.BeginUpdate;
lvMyEssays.Items.Clear;
oriCursor := Screen.Cursor;
Screen.Cursor := crHourglass;
lStart := GetTickCount;
try
eInfos := (HTTPRIO1 as IMyEssays).GetEssayTitles;
for iCount := low(eInfos) to High(eInfos) do
begin
with lvMyEssays.Items.Add do
begin
Caption := eInfos[iCount].EssayTitle;
Data := Pointer(eInfos[iCount].EssayID);
end;
end;
finally
lEnd := GetTickCount;
ShowRunTime(lStart, lEnd);
lvMyEssays.Items.EndUpdate;
StatusBar1.Panels[0].Text := '完成呼叫Web Service';
StatusBar1.Refresh;
Screen.Cursor := oriCursor;
end;
end;

procedure TForm2.ShowCaption;
begin
lblCaption.Caption := '太棒了, 我的第一個Web Service程式';
end;

procedure TForm2.ShowRunTime(const lStart, lEnd: Integer);
begin
StatusBar1.Panels[1].Text := FloattoStr((lEnd - lStart) / 1000.0) + '秒';
end;



上面的程式碼藉由THTTPRIO元件呼叫IMyEssays介面的GetEssayTitles方法，取得TEssaysInfos陣列，再從陣列中一一的取出每一篇文章的名稱，最後再填入到主表單中的TListView元件之中。下圖就是執行此用戶端應用程式呼叫Web Service伺服器，並且取得所有文章資訊的畫面。從這麼簡單的數個步驟中，我們已經使用Delphi 6開發了一個真正的Web Service應用系統。







圖十四 範例用戶端應用程式呼叫Web Service得到資料的畫面


雖然這是我們使用Delphi 6建立的第一個Web Service，但是這個範例Web Service展示了Delphi 6的SOAP/Web Service解決方案能夠輕易的傳遞複雜的資料型態，因為在範例Web Service中是使用陣列的型態來傳遞所有的文章資訊。Delphi 6的SOAP/Web Service技術絕不是像一些工具只提供簡單的SOAP/Web Service解決方案，而是充分的提供了一般和複雜的應用程式，並且能夠整合各種元件模型，是目前最具威力，也是最先進的SOAP/Web Service開發工具之一。
Delphi 6除了提供強勁的Web Service開發功能之外，新的Web App Debugger不但可以幫助程式師除錯Web應用程式之外，也可以幫助程式師監督用戶端應用程式和Web Service之中傳遞的資訊。這些資訊包含了SOAP的封包，以及Web Service伺服器回傳回用戶端的所有SOAP封包。這對於程式師學習SOAP和解析SOAP Payload都非常有幫助。例如下圖便是我使用Web App Debugger檢視此範例Web Service應用系統傳遞的SOAP Payload。







圖十五 Delphi 6的Web App Debugger可以顯示用戶端和伺服端之間所有的訊息


為了證明Web Service的威力和相通性，目前全世界已經有許多人成立了各種Web Service的網站，讓開發人員能夠測試Web Service。例如現在WWW.XMethods.COM便是提供各種Web Service的網站之一。這個網站羅列了許多的Web Service，下圖便是這個網站目前提供的Web Service。







圖十六 Internet上的XMethods(www.xmethods.com)提供了許多的Web Service供人呼叫使用


現在讓我們使用Delphi 6開發一個用戶端應用程式來透過Internet/Intranet呼叫遠端由Java實作，執行在Apache上的一個查詢美國各州氣溫的Web Service。下圖是這個Web Service的詳細資訊，這個Web Service的作者甚至提供了Java用戶端應用程式展示如何呼叫這個氣溫Web Service，不過現在我想使用Delphi的用戶端應用程式來呼叫，而不是Java。







圖十七 XMethods上的眾多Web Service之一，Temperature Web Service


下圖便是在我的機器中使用Delphi 6開發的用戶端應用程式，藉由Delphi 6的WebServices元件組來呼叫這個位於遠端，我也不知道在什麼地方的氣溫Web Service的結果畫面。
從下圖中可以證明，雖然我並不知道這個Web Service在那裡，我仍然可以藉由Web Service的標準介面敘述WSDL來使用它，即使它是使用Java實作的，並且執行在Apache之上。







圖十八 Delphi實作的用戶端應用程式呼叫執行在遠端Apache上的Web Service


希望上面的內容可以讓各位讀者瞭解Web Service和SOAP在應用上的潛力以及Delphi 6提供的元件技術可以讓開發人員快速而且輕易的實作出各種威力強大的Web Service。
也許藉由Web Service和SOAP的出現，也會對於目前應用系統架構產生巨大的影響。例如現在『供應鏈』軟體非常的流行，但是許多的供應鏈軟體在整合上，中，下游廠商時，經常會需要所有的廠商使用相同的平台以及基層軟體。但是對於下游廠商而言，可能無法像上游廠商一樣使用昂貴的設備，例如UNIX BOX和大型ERP軟體，許多的下游小廠也許只能使用Window NT或是Linux平台。不過現在Web Service和SOAP可以提供非常完善的解決方案，就如同下圖顯示的一樣，下游廠商可以只使用ASP提供簡單的Web Service讓他的中游廠商呼叫。而上游廠商則可以在UNIX Box中藉由大型的ERP軟體呼叫中游廠商執行在Window 2000中的BizTalk Service。如此一來不但每一個廠商都可以選擇最適合的執行平台和軟體，也可以藉由Web Service和SOAP整合上，中，下游廠商而提供一個及時且完備的供應鏈。Web Service和SOAP正為軟體帶來無限的發展契機。







圖十九 Web Service的應用架構之一


雖然SOAP和Web Service目前已經成為標準並且也已經被世界廠商所接受和支援。但是SOAP和Web Service仍然是在成長期，功能規格仍然在繼續的改善和強化之中，因此SOAP和Web Service的變化也在預期之中。Delphi 6實作的SOAP和Web Service似乎是比較偏向IBM和Java的陣營，因此Delphi 6能夠很容易的和Java以及PHP，Perl等SOAP/Web Service解決方案整合。至於Microsoft的SOAP和Web Service則稍有不同，需要程式師特別注意一下。
如果下次有時間的話，那麼就讓我們繼續討論Microsoft的SOAP Toolkit以及.NET之中的SOAP解決方案，並且比較Delphi和它們之間的差異以及如何整合這些不同的SOAP實作技術。



相关帖子:

李维：軟體服務時代的來臨

看看什么是软件服务时代！大家快来看看！

李维:.net vs delphi 6

delphi6 爆发还是灭亡？

李维:我的回忆和一些有趣的事

看IT风云变幻,宝兰与微软背后的故事,

李维:2001 年軟體界的巨星 - Kylix

看宝兰, 一年之间连续推出kylix1.0 ,interbase6.0, delphi6,jbuilder5 ,c++builder6也不日即出,敬请关注宝兰2001年与微软对绝的杀手锏kylix

李维:Windows 原生開發工具的瑰寶 – Delphi 6



李维问答集之语言选择篇

李维：樂趣無窮，可能無限的新技術-Web Service

我推荐的帖子

陈宽达: 遊戲程式設計初學者常遇之疑問

明修栈道,暗渡陈仓,陈宽达点指开发工具

软件开发中的弊病

这篇文章不算精彩，但是引来的评论却很精彩

聲明
以下的這篇文章內容是我個人的回憶以及看法，沒有任何特別的偏見，許多的事情是根據我的記憶以及從許多人的訴說中得知的，也許內容不是百分之百的正確，不過我想這些內容有一定的可信度到是可以保證的。當然有一些事情確定的發生時間和順序不一定都和我的記憶一致，不過我想大部份應該是相去不遠的。當然各位如果知道確定的事件而我的記憶有誤，那麼我將非常歡迎您糾正我，我希望這些故事的經歷能夠一直陪我走下去，謝謝。

一直想寫一篇我個人在過去10多年來工作中經歷的一些事情，以及看著一些我認為是偉大的工程師在這些日子中對於資訊界的貢獻。如果你和我的年齡差不多，那麼你可能會對於這些內容很有興趣，因為它們說明了當時許多軟體的興起和沒落的過程以及原因。雖然這些事情已經距離我們很遙遠了，但是我相信許多人仍然對於背後的故事有興趣。如果你沒有經歷過那段美好的回憶，那麼就把這些內容當成是一個有趣的故事來看吧。但是我想更重要的是讓我們一起認識一些偉大的人物，我對於其中的許多人都非常的佩服，也非常的羨慕。我常常在想，如果我也有他們的環境，我是不是也能夠和他們一樣這麼有成就呢?這些人對於以往都有重要的貢獻，在未來也將仍然有重要的影響，因為他們都有一身不凡的技術。對於許多重要的人我都儘量的收集了他們的照片，讓各位也能夠看看這些優秀的工程師和傑出的人物。當然，如果各位也能夠從這些內容中學習到失敗的原因以及成功的經驗，那麼這篇文章就更有價值了。



和Borland的緣由


記得我在大學時第一個在PC上使用的軟體便是SideKick，至今我仍然無法忘記這個讓我津津樂道的軟體，而Borland在當時也就是以SideKick成為全球知名的軟體公司。不過Borland第一個奠立創業基業的軟體卻是我大二使用來交作業的Turbo Pascal。而Turbo Pascal也是第一個我聽到關於Borland的有趣的故事

當年Philippe Kahn (Borland的創使人)和Anders Hejlsberg到美國創業時，便由Anders以組合語言撰寫了Turbo Pascal的編譯器，而Philippe則包辦了Turbo Pascal其他的部份。在這兩位人兄開發完Turbo Pascal之後，窮得快連登廣告的錢都沒有了。但是Philippe為了在Byte雜誌(還記得這個著名的雜誌嗎?)刊登Turbo Pascal的廣告，因此和Anders商量了一個方法，那就是一天他們約了Byte雜誌的人到當時Borland的辦公室討論刊登廣告的事情。

當Byte的人到了Borland之後，Philippe，Anders和公司的助理小姐故意忙著接電話，接受Turbo Pascal的訂單，並且告訴Byte雜誌的人等一下。過了一陣子之後Philippe才進入房間向Byte的人道歉，說他們的Turbo Pascal受到市場的熱烈歡迎，訂單源源不斷的到來，因此可能不需要在Byte雜誌刊登廣告了，接著Philippe向Byte的人展示Turbo Pascal這個產品。由於在當時的機器中Turbo Pascal能夠在少少的RAM中常駐執行，又提供閃電般的編譯速度，立刻讓Byte雜誌的人震驚在當場，憑著專業知識和豐富的經驗，Byte的人也立刻知道這將是一個革命性的軟體，因此馬上希望Philip能夠在Byte雜誌刊登Turbo Pascal的廣告，並且願意以半價刊登。當然，Philip也立刻的答應了，於是一個革命性的軟體Turbo Pascal終於在Byte雜誌刊登出來了，售價49.99美元的Turbo Pascal立刻為Borland帶來了大量的財富，Turbo Pascal也立刻的成為PC上除了基本的Basic之外最暢銷的開發工具，也正式揭開了Borland影響PC開發工具10幾年的序幕。

在Turbo Pascal之後，Borland接著推出了SideKick這套軟體，SideKick可以說是隨後著名的記憶體常駐軟體(TSR)的始祖，也是讓Borland跨出開發工具界，讓幾乎所有PC使用者認識Borland的關鍵軟體。當然SideKick也很快的成為了全球的暢銷軟體，繼續的把Borland往頂尖的軟體公司上推。

而Turbo Pascal也成了我大二，大三撰寫作業的最愛，幾乎所有的作業都是使用Turbo Pascal完成的，當然其時Horowise的Data Structure這門課也是使用Turbo Pascal過關的，因此從那個時候開始我便非常喜歡Borland這家公司，慢慢的也開始對Borland有了特別的感情。

大二時Microsoft也推出了Microsoft Pascal，但是它和Turbo Pascal的確是有一段差距，我使用了一次之後便把它丟到垃圾桶。稍後Borland也推出了Turbo Basic，我記得這個編譯器非常的棒，編譯速度就和Turbo Pascal一樣，是一個非常有前途的產品。但是我不知道為什麼它只有1.0，之後便和Microsoft Pascal一樣消失了。我聽說Microsoft和Borland互相交換條件，Microsoft不進入Pascal的市場，而Borland則退出Basic的市場。至於是不是真的我就不得而知了。

在大二初次的接觸到C語言，第一本閱讀的書便是王興隆先生寫的C語言，也從此開始和C語言結下了淵源。平生第一個使用的C編譯器便是Lattice C，不知道還有沒有人記得。我還記得那個時候使用2個5又1/4磁片抽換以便編譯C程式的情景。稍後Borland終於推出了風行天下的Turbo C編譯器，當然，從此之後Turbo C便成了不離身的工具，而Borland也藉由Turbo C這第三項暢銷產品邁向了世界前10名的項尖軟體公司。

當完2年的兵之後，我在中研院首次使用了C++語言，第一個使用的C++編譯器則是Zortech C/C++，這家公司稍後被Symantec收購成為Symantec C/C++的核心，這個故事稍後再說。後來Borland也推出了Turbo C/C++ 1.0這第一個C/C++編譯器，但是在我和Zortech C/C++比較之後，還是覺得Zortech C/C++比較好，因此就繼續使用Zortech C/C++。一直到Borland的Turbo C/C++ 2.0編譯器推出之後，才逐漸成為C/C++語言的王者，而我也像以往一樣把Zortech C/C++換成了Turbo C/C++。

在1991年到Georgia Institute Of Technology唸碩士時，終於使用自己的零用錢美金49.99購買了生平第一套的正版軟體Turbo C/C++ 4.5，隨後又購買了Borland Pascal。在畢業前的一個Quarter，Microsoft 推出了Microsoft C/C++ 6.0以及MFC 1.0，由於是第一個C/C++的Framework，因此也花了一些錢購買了一套以便瞭解MFC。但是在收到之後卻很失望，因為Microsoft C/C++ 6.0仍然沒有圖形整合發展環境，還是在DOS下的整合發展環境，而且MFC 1.0以我的眼光來看又不好用，而且Microsoft C/C++ 6.0的C/C++最佳化編譯器在其時是一個笑話，不但產生的程式碼效率不好，甚至會產生錯誤的程式碼，許多雜誌也稱Microsoft C/C++ 6.0是一個平庸的(Mediocre)產品。因此就把它丟在一邊。在Microsoft C/C++ 6.0不久之後，Borland終於推了Borland C/C++ 3.0。而這套軟體也開啟了Borland雄霸C/C++編譯器常達5,6年之久的序幕。

Borland C/C++ 3.0推出之後由於擁有第一個在Window下的穩定的圖形整合發展環境，而且它產生的最佳化程式碼也是Microsoft C/C++ 6.0望塵莫及的，因此很快的幾乎所有的C/C++程式師轉而使用Borland C/C++ 3.0。因此在那個時候有一個現象，那就是幾乎所有的公用程式或是Shareware都是使用Borland C/C++開發的，許多硬體廠商的驅動程式也是使用Borland C/C++ 3.0來撰寫的。

1992年我取得Georgia Institute Of Technology的碩士學位之後最想進入的公司便是Borland和Microsoft，不過最後我還是決定回台灣工作。在此時Borland也進入了最巔峰的時期，因為Borland推出了Borland C/C++ 3.1。

Borland在Borland C/C++ 3.0獲得空前的勝利之後，並沒有鬆懈下來，因為Borland知道Borland C/C++ 3.0還缺了一個最重要的勝利因子，那就是如同Microsoft的MFC一樣的C/C++的Framework，因為Borland也看出了Framework將會是未來C/C++產品中最重要的一環科技。不過Borland此時面臨了一個重要的十字路口，那就是到底要自己開發一個和MFC抗衡的Framework，還是要如何做。因為如果要自己開發Framework，那麼勢必要花上一些時間，但是Borland想趁Borland C/C++ 3.0如虹的氣勢再下一城，以便徹底擊潰Microsoft C/C++。因此最後Borland決定向一家叫White Water的公司購買一套由這家公司開發的一個Framework，這套Framework便是後來鼎鼎大名的OWL的源流。而Borland也因為向White Water購買了這套Framework，因而也引進了一個日後非常重要的人物，那就是後來負責開發Delphi的一員大將 - Zack Urlocker。



C/C++的光榮戰役


在Borland購買下White Water的C++ Framework之後，便更命為OWL(Object Window Library)，並且很快的推出了以OWL 1.0為核心的Borland C/C++ 3.1。由於OWL比當時的MFC 1.0封裝的更為完整和好用，再加入Resource Workshop視覺化能力，以及Borland C/C++ 3.1自己最強勁的編譯器和整合發展環境，因此立刻的風靡了全世界，其受歡迎的程度更是遠遠的超過了它的前一版本Borland C/C++ 3.0。

由於Borland C/C++ 3.1的暢銷，立刻讓Borland在C/C++市場一舉擊潰了Microsoft C/C++，市場佔有率超過了50%，是全球第一的C/C++產品，也把Borland推上了最高峰，成為全世界第三大的軟體公司。

很快的，我所工作的開發小組也立刻的以Borland C/C++ 3.1來開發系統，Borland C/C++ 3.1也是我使用過Borland最穩定的C/C++版本之一。也由於那個時候一天到晚都使用C/C++工作，因此就有了一些小心得。稍後我整理了一些東西便投稿到剛出刊不久的RUN!PC，也許是運氣不錯，RUN!PC很快的也登出了我的文章。就是這篇文章登出之後，台灣的Borland注意到了我，開始和我連絡，並且從此展開了和Borland的互動。而Borland C/C++ 3.1也是第一套Borland免費送我的軟體，當然代價就是希望我多寫一些Borland產品的文章。

接著Borland又計劃推出Windows版的Borland Pascal，不過在Borland開發Borland Pascal For Windows 時，當時(現在也還是)最具盛名的Charles Petzold(我的第一本Windows 程式設計的書就是這位仁兄寫的，相信許多人也是看他的書一路學來的)就說除了C/C++之外，Borland不可能做出能夠在 Windows 下執行的Borland Pascal，不過很明顯的，即使是Windows API的大師Charles也錯了。Borland不但做出來了，而且Borland Pascal For Windows 還非常的暢銷，當然Borland Pascal For Windows 也是後來Delphi的根基。

當時的Borland可說是不可一世，不但產品大賣，而且日進斗金。Borland在Scotts Valley豪華的總部也是在那個時候由Philippe Kahn大手筆的花了一億多美金搭建的(想想10年前的60多億台幣可以蓋什麼樣的房子?)。不過也許是Borland太成功了，因此也開始讓Philippe Kahn漸漸的養成了好大喜功，目中無人的態度，也種下了Borland開始走向衰退的因子。








Borland 位於美國加州 Scotts Valley 總部


不過在Borland最強盛的時期，當然也就是Microsoft最想痛宰Borland的時候，在這個時候發生了一個著名的事件和一個著名的虛擬人物。話說由於當時Microsoft的開發工具一直打不過Borland的產品，因此在Microsoft的開發工具刊物上便出現了一個作者不斷的以文章嘲笑Borland，這個作者的筆名是Buck Forland。後來由於這位作者的文章內容以及他的筆名引起了當時Borland的不滿以及大量Borland使用者的強烈抗議，因此稍後這位作者就突然的消失不見了。因此有許多人就推測這個作者應該是Microsoft的工程師，由於一直無法打敗Borland的產品，腦羞成怒，因此才會以這個筆名來發洩。如果各位看倌到現在還摸不著頭為什麼這個筆名會引起軒然大波，那麼請你試著把Buck Foland這兩個英文字的第一個字母一對調就知道為什麼了。現在各位是否會心一笑了?








Philippe Kahn-Borland的創始人


在Borland C/C++ 3.1大獲成功之後，Borland卻開始鬆懈了下去，並且開始走下坡。當然這有許多的原因，我所知其中最重要的原因有數項 :

■Philippe Kahn和當時Borland C/C++的產品經理鬧翻了。這位Borland C/C++的產品經理的名字是Eugene Wang，他是一位非常聰明的中國人。他一手把Borland C/C++ 帶到了世界第一的地位，並且在Borland C/C++ 3.1成功之後有了更偉大的想法，那就是 Eugene Wang 想在下一個Borland C/C++版本中完整的以OWL封裝所有的Windows API，因為OWL 1.0雖然比MFC 1.0來得優秀，但是OWL的隱憂就是OWL尚未完整的封裝所有Windows的API。此外Eugene還計劃以OWL為核心，開發一個類似今日Borland C/C++ Builder的以視覺化元件為開發方式的開發工具。請各位想一想，如果在當時Borland能夠開發出這種C/C++開發工具，那麼將會是一個多麼可怕的產品，稍後Microsoft的Visual C/C++ 1.0只是能夠在整合發展環境中自動產生MFC的程式碼就立刻的轟動了C/C++市場，造成了大量程式師轉入Microsoft的陣營。即使是目前的Borland C/C++ Builder使用的Framework仍然是以Object Pascal以核心的元件Framework，而不是純粹的C/C++程式碼。如果當時 Eugene Wang 能夠做出他心中的下一版Borland C/C++，那麼我想到現在Borland C/C++可能還是市場中第一的C/C++開發工具。不過很不幸的是，Eugene Wang 稍後和Philippe Kahn發生了爭執，Eugene Wang 一氣之下離開了Borland。而Philippe Kahn則認為Borland C/C++的地位已不可動搖，因此也沒有想立刻的做下一版的Borland C/C++。這樣一拖竟然浪費將近2年的時間。

Microsoft Visual C/C++ 1.0在Borland C/C++ 3.1 2年之後推出，並且立刻獲得市場好評。不但在編譯器方面能夠和Borland C/C++ 3.1相抗衡，在整合發展環境方面更大幅領先了Borland C/C++ 3.1，還能夠自動產生MFC的程式碼，再也不是昔日的吳下阿蒙。直到此時Philippe Kahn才從夢中驚醒而急於開發下一代的Borland C/C++ 4.0，但是為時已晚，C/C++的開發工具市場從此就開始逐漸的被Microsoft蠶食了。

Eugene Wang在離開Borland之後，立刻的被Symantec所網羅，稍後Eugene Wang也在非常短的時間之內為Symantec開發出了著名的Symantec C/C++。Symantec C/C++在當時被所有的技術刊物評比為擁有最棒的整合發展環境和最有創意的C/C++開發工具，從此可見Eugene Wang的功力。不過Symantec C/C++稍後也不敵Microsoft Visual C/C++，這個故事的原因在稍後四大C/C++編譯器之爭的段落中再詳細的說明。

我最後聽說Eugene Wang跑去做生意了，並且在前幾年寫了一本教導科技人員如何面試的書籍。我,一直很痛心Borland失去了這麼一位優秀的人材，我常想如果當初Eugene Wang沒有離開Borland，那麼歷史就可能不是現在的這樣了，Sign!!!

■Philippe Kahn大手筆的花了一億多美金買下了Ashton-Tate公司和dBase。在當時許多人都批評Philippe Kahn做了不值得的事情，因為Ashton-Tate不值這麼多錢。但是由於當時Borland多的是錢，因此Philippe Kahn也不多意。不過這並不是Borland走向逐漸走向衰敗的主因，而是在Borland買下了dBase之後，並沒有立刻積極的發展dBase For Windows，反而把dBase丟在一旁。這個原因便是當時Borland的另外一個和資料庫有關的產品Paradox賣得也很好，因此Philippe Kahn並不急著打算開發dBase For Windows。不過Philippe Kahn忘記了一件事情，那就是當時在市場大量人口的dBase程式師需要一個好的Window版dBase，但是Philippe Kahn購買了dBase卻不提供Windows 版的解決方案。因此當稍後Microsoft以極小的代價買下Fox這家公司，並且在數年之後推出FoxPro For Window，吸引了大量原先的dBase程式師以及Paradox的程式師之後，Philippe Kahn才警覺事情不對而充充忙忙的開發dBase For Windows。但是當dBase For Windows 推出之後，Microsoft早已推出了兩個FoxPro For Windows 的版本，而佔據了大部份的市場，dBase For Windows其勢已不可為了。

■Microsoft開始向Borland挖角。由於Microsoft在許多的開發工具戰役中一直被Borland打得灰頭土臉。更何況Borland C/C++ 3.1幾乎搶佔了大部份的市場，因此Microsoft開始準備好好的對付Borland。但是由於其時Borland在編譯器的技術領域領先了Microsoft數年之久，Microsoft無法在短時間之內趕上Borland，因此Microsoft決定使用最有效的方法立刻追上Borland技術，那就是直接挖角。因此稍後Microsoft的Visual C/C++小組有60%的成員是從Borland挖來的，這個舉動不但立刻的讓Borland流失了大量的優秀技術人才，也在數年之後造成了Borland控告Microsoft的導火線。不知道各位看到這裡有什麼感覺，或是沒有感覺。不過我總是覺得Microsoft使用了不好的手段來競爭，並不是光明正大的擊敗Borland，而是使用了不公平的競爭手段。

Philippe Kahn在這段時間不但讓Borland C/C++被Microsoft Visual C/C++反敗為勝，也痛失了幾乎所有dBase的市場，更浪費了大量的金錢，和流失了大量的優秀人員。在這些重要的原因之下，Borland已經不可避免的開始走下坡了。

我最後一次看到Philippe Kahn時是在1994年未於亞特蘭大(Atlanta)參加國際Conference時，還和他打了一聲招呼。後來Philippe Kahn離開了Borland，另外創立了StarFish這家公司，稍後StarFish也被Motorola併購。雖然Borland由於Philippe Kahn一些錯誤的決策而逐漸的從巔峰開始下降，但是Philippe Kahn也不愧為一個人物。因為Philippe Kahn能夠和Bill Gates一直周旋數年之久，而同一時期的許多公司，例如Lotus都一一的被Microsoft所擊敗，因此Philippe Kahn還有一套的。此外Philippe Kahn也是唯一一個擁有工程師特性的Borland CEO，Philippe Kahn仍然重視技術產品和技術人員。但是Borland隨後的CEO幾乎都是Marketing，Finance或是Sales出身的人，這真讓我懷念以往以產品和技術為優先的CEO了。

看完了上面這段今人傷心的歷史之後，再讓我們看看當Borland在受到Microsoft Visual C/C++的強大衝擊之後，如果思索反擊之道。在這段期間也出現了令我敬佩的第一個Borland技術工程師，Carl Quinn。

Carl Quinn在Microsoft Visual C/C++ 1.0推出之後，立刻奉命開發一個能夠和MFC相抗衡的全新OWL，而Carl Quinn也是數年後JBuilder的JBCL Framework的靈魂開發人物。Carl Quinn不但負責開發OWL，也為Borland在元件Framework的技術領域立下了重要的貢獻。由於Carl Quinn的投入，因此開啟了OWL大戰MFC，Borland C/C++纏鬥Visual C/C++數年精彩好戲的序幕。



Carl Quinn到現在我還記得和敬佩的人物，讓我再一次的向他致敬，並且介紹他讓大家認識。









Carl Quinn-我第一個佩服的Borland工程師




Borland C/C++的反擊
火線全開

Borland除了在開發工具市場和Microsoft熱戰之外，其時和Microsoft ，Lotus鼎足而立的Borland看到Microsoft和Lotus正在試算表工具以及文書處理工具大戰之暇，不思好好的集中資源開發新的開發工具和資料庫工具(下一節會詳說)，也不甘寂莫的投入了大量的資源進入這個慘烈的市場。也許是當是Borland太有錢了，或是Philippe Kahn腦袋有問題，居然決定進入這個Borland陌生的市場，更何況在Borland投入時Lotus已現敗象，市場已經慢慢的被Microsoft所一步一步的掌握了。

Borland進入Office市場的第一個產品便是著名的Quattro Pro這個試算表，雖然Quattro Pro是一個不錯的產品，而且當時由Borland C/C++編譯器所開發的Quattro Pro在執行效率上幾乎是最好的，但是Borland沒有想到使用試算表的使用者是一般的辦公室人員，這些人注重的是方便性和功能性，而不是最重視執行速度，這和開發人員是不一樣的。Borland以開發者的心態來開發試算表工具基本上是走錯了方向。因此我記得在那段時間中，雜誌評比Microsoft的Excel，Lotus的1-2-3和Borland的Quattro Pro時，在功能方面領先的都是Excel和Lotus，在執行效率方面領先的則是Excel和Quattro Pro。到了試算表熱戰的未期1-2-3甚至比不上Quattro Pro，因此Lotus敗走試算表市場已是不可避免的結果了。

不過Borland雖然贏了1-2-3，但是和Excel仍然有一大段的距離，Microsoft一統試算表江山之勢已不可搖，因此最後Borland在損失了大量的資源之後，Quattro Pro只能賣給Novell。除了Quattro Pro之外，Borland也投入了很多的資源秘密的開發一個代號稱為Spring的文書處理程式準備和Microsoft的Word以及WordPerfect競爭，這可能是許多人不知道的。但是這個產品最後仍然無法問市而胎死腹中，在文書處理市場方面Borland不但浪費了時間，更虛擲了大量的資源。Philippe Kahn在Office產品方面消耗了Borland大量的金錢和時間，卻落得鎩羽而歸，更連累了開發工具市場以及最有可能成功的資料庫產品市場。

另外一個和Borland無關的故事是關於Excel如何興起的。話說當Lotus 1-2-3最盛的時期，Microsoft一直計覬覦這個市場，但是苦於無法開發一個能夠和1-2-3相競爭的產品。有一次Lotus 1-2-3舉辦了一個Lotus 1-2-3的技術研討會，由當時Lotus 1-2-3的首席工程師主講。在Microsoft知道了這個技術研討會之後，立刻派出了最好的程式設計師，在現場詢問Lotus是如何開發1-2-3的並且也趁機詢問這位首席工程師如何克服1-2-3在許多技術方面的難點，而這些困難處正是 Microsoft 的工程師無法克服的。

當時在現場中Lotus的這位首席工程師雖然知道這些人是Microsoft派來的，而且詢問的問題正是1-2-3許多關鍵的技術點。但是這位首席工程師憑藉著多年開發經驗，並且認為Microsoft不可能在短期之內追上1-2-3，因此就沒有多做保留的回答了許多重要的問題。沒有想Microsoft的這些程式師也是非常聰明的的人，在一經指點之後，立刻暢然全通，在短短的1,2個版本之後不但馬上追上了1-2-3，在許多功能方面更是青出於藍，1-2-3便逐漸失去優勢了。我想這位1-2-3的首席工程師一定很後悔當時回答了關鍵的技術問題吧。

結論 : 千萬不要小看Microsoft，他是非常精於模仿的，也永遠不要小看你的對手。



資料庫市場的失誤


當Borland全盛的時期，事實上也是發展資料庫產品最好的機會。因為在當時Borland手握DOS最暢銷的Paradox，又併購了Ashton-Tate而擁有世界大部份dBase的市場，後來又從 Digital 取得了真正的 RDBMS-InterBase，可以說是全世界資料庫實力最雄厚的廠商。當時的 Oracle 和 Borland 比起來，簡直是小巫見大巫，而 Sybase 更不知道在那裡。如果當時 Borland 能夠好好的掌握這個機會，並且極力發展資料庫產品的話，那麼現在Borland 就算不是世界第一的軟體公司，也將是世界第二的軟體廠商。

可惜 Philippe Kahn 並沒有看到這個在年代80未到90年代成長最快速的產品。說句笑話的是，如果當時Philippe Kahn的死對頭Bill Gates早一點對 Philippe Kahn 說出Information At Your Finger-Tip』的話，那麼 Borland 就可能是現在的 Oracle 了。

說到資料庫市場就不得不對 Microsoft 的眼光佩服，也可以看到Microsoft行銷能力的強悍。當Microsoft以FoxPro For Window強佔了開發者的資料庫市場之後，又看到了一般使用者也需要使用簡易好用的資料庫管理工具。因此發展出了Access。但是當時在這種市場中，Paradox佔有開發者的資料庫大部份的江山，而一般使用者的資料庫管理工具市場則由Lotus的Approach拔得先機。Microsoft為了扳回劣勢，我還記得在當時Visual Basic 3的套裝軟體中Microsoft附了一張優待卷，只要800新台幣就可以買一套Access。這簡直就是流血大拍賣，目標很明顯，就是當時在市場中賣1萬多元的Lotus Approach。果然，Microsoft此招一出，Approach便在市場被Access打得落花流水，很快的便失去了市場，也很快的退出了市場。從此一般使用者的資料庫管理工具市場便逐漸由Access所取代。

但是Borland並沒有警覺到Access會繼續的往開發者市場進功，因此仍然沒有加緊在Paradox產品上開發，Borland總覺得以Paradox在市場的地位是無法輕易憾動的，而且Access的目標市場也不是Paradox的市場。但是Borland忘記了Microsoft非常散擅長模仿，因此在隨後的Access版本中，Microsoft不斷的為Access加入可程式設計的功能，因此也逐漸的吸引了一些Paradox入門使用者的市場，再加入FoxPro For Window又持續的強功開發者資料庫市場，Paradox終於在背腹受敵之下也逐漸的敗下陣來。雖然在未期Philippe Kahn已經對Paradox投下重兵，希望能夠挽回Paradox的劣勢，奈何時不我予，Paradox在奮鬥了Paradox 6和Paradox 7的2個版本之後，終究難逃失敗的命運。

當時我看到Microsoft如何打擊競爭對手時，我就和朋友開玩笑的說。Microsoft有天下無敵的3絕招，那就是『打不過你就模仿你(這讓我想起電影秘密客(Mimic) )，再打不過就和你比流血，看誰流得久(這讓我想起吸血鬼)，最後如果再不行的話，那就挖光你的人(這讓我想起電影 Other People's Money)』。Lotus就在Microsoft的前2個絕招下到地不起，而Borland還算是功力深厚的了，連中了3絕招，雖然不像Lotus和許多其他公司一樣從此Bye-Bye，但也是受傷極重的了。



ODBC和IDAPI之爭


當Microsoft在逐漸的擊敗他的競爭對手，並且擁有了大部份PC資料庫市場之後，便慢慢的瞭解到掌握標準的重要性。此外Microsoft為了統一各應用程式之間不同資料的存取，因此開始製定存取資料的統一標準-ODBC。

Microsoft更大的目的是為了準備和瞄準下一場的大戰，那就是PC上的RDBMS產品。
當然，Microsoft要一統資料存取的江山，Borland不同意，其時一心想從Microsoft扳回一城的IBM也不同意，而Novell更是害怕，因為Novell怕Microsoft成功之後，Netware會消失得更快。於是IBM，Novell和Borland以及一些其他的小廠便聚集在一起，決定也製定一套存取資料的標準介面來和Microsoft對抗，這個製定的資料存取標準便是IDAPI。此時也正式揭開了ODBC和IDAPI競爭的序幕。

不過IBM，Novell和Borland的結合很快的就證明是失敗的，因為就像稍後說明的一樣，IBM在PC軟體上的發展一直是三心二意，反反覆覆，因此當IDAPI 1.0的規格出來之後，IBM這位老兄又失去了和Microsoft對抗的興趣，於是就退出了IDAPI聯盟。至於Novell就更不用說了，Novell對於和Microsoft一象是『說說可以，真打不行』，一定要找到一群廠商才敢和Microsoft對抗。Novell在眼看IBM推出之後，也馬上不戰而降，很快的就也退出IDAPI聯盟，這個現象和稍後Novell對於和Borland秘密合作的Appware/AppBuilder計劃如出一轍，都是虎頭蛇尾，草草收場。

在兩個大ㄎㄚ臨陣脫逃之後，Philippe Kahn仍然不畏懼Microsoft的競爭，還是以IDAPI 1.0的規格實作資料存取引擎，這就是我們現在使用的BDE/IDAPI和SQL Links的前身。當時IDAPI 1.0的功能規格比ODBC 1.0好得多了，我記得Delphi 1.0使用的BDE/IDAPI和SQL Links驅動程式也比當時慢得像烏龜的ODBC快上太多了。只可惜在IBM和Novell推出之後，其他的小廠也是一轟而散。因此Borland只能靠自己獨自和Microsoft對抗。Borland能夠以少量的資源一直對抗到Delphi 3的BDE/IDAPI才逐漸的被ODBC追過，也算是非戰之罪了。怪也只能怪Borland意志不堅的盟友。當然由於IBM和Novell的行事做風是如此，在稍後許多能夠和Microsoft一較長短的機會也因為如此而消逝，最後自食惡果，逐漸失去了PC的軟體市場，再也無力和Microsoft抗衡了。

現在呢Borland似乎記取了當時的錯誤, 正努力的在Linux上定義標準資料存取介面dbExpress, 我希望也祝福Borland能夠成功.

你到底想干么

我在使用过程中发现，关闭当前工程，然后打开一个工程有时会出错，退出
Delphi6后再重新打开就没问题了。

国内不谈java

原作者：JLang
来源：BBS
　　　国内不谈java－－会有千万人跳出来和你争嘴的。越是如此，我越是不忍心不说出来，越是不不忍心看到在这个领域被国外的同行越拉越远－－在硅谷的感受。
　　我是96年毕业的,正值java刚出,火气冲天之时。我当时是一名C++的狂热者，有着3年的C++经验。接触java也仅仅是在作毕业设计的时候用过，对java也算是有了基本了解，那时的java才jdk1.0，烂的很，连些基本功能都没有，和大家一样，对java根本就不认可。作完了设计之后，就把java扔到一边去了。自认为C++不错，还是干自己的老本行吧。毕业时我认为精通C++，并且有java的基础，算是身怀两种绝技了，在国内的IT（那时还不叫IT）还可以混个明堂出来吧。
　　怀着对未来美好的憧憬和对C++的无限的崇拜，我出来闯荡了。唉－－出去的情况于我的想法完全两样，delphi,VB漫天飞，C＋＋高不可攀，根本无用武之地。我大失所望，可我偏偏又是一个C＋＋偏执狂，要我去改学其它语言，在我看来简直是对C++的侮辱，也是对我信念的侮辱，是绝对不可能的！对国内失望之余
，于是我想到IT技术前沿的美国，于是满怀希望来到到了IT精英汇集的地方－－硅谷。我想这下总算可以施展我深藏多年的C＋＋才华了吧。我－－再一次的错了－－在硅谷，VB,delphi根本不入流，虽然C++还继续再用，
但是已经是大不如以前了，不过有c++背景的找工作要相对容易些。这里，程序员们，大小的managers，chargers只对Java感兴趣。 没想到，万万没想到。－－这里反微软的气氛很浓，也许是Sun,Oracle,IBM,AOL等巨头公司的大本营在此的缘由吧。呆过一段时间后，我发现这里只要是稍大一点的公司，都在同时在维护着几套System，要一劳永逸的解决这些问题，让这些System无缝的衔接起来，java是最好的不过的解决方案。
在这里，个大巨头公司们对java几乎在玩命似的疯狂：ibm在全球16个java实验室24小时续以奋战，扛着“java就是一切”的大旗，投入java的钱不比sun的少；intel整装待发，全力以赴赶制java芯片，以求在java谋得一席之地；oracle,Sybase,informix,DB2这些王牌数据库厂商更是纷纷下马，把java绑定到自己的产品中，提供对java最全面，最直接的支持；Inprise,BEA,Iona,netscape联盟等一大批系统集成、支援厂商，也不甘落后，争先恐后的开发自己的java工具、应用服务软件，目的只有一个，让自己的产品带上一个响亮的"J"字；
cisco,3Com,HP,NEC等一大批网络设备供应商对embed java表现了浓厚的兴趣，一批又一批的带java接口的智能设备相续涌现出来，在这个市场上的竞争异常激烈，谁也不敢怠慢；sun自己就更不用说了，sun创造了java,但java并非sun的专有，来自巨头们的竞争，也让sun感到了前所未有的压力，在“捍卫java，保卫java,发展java”的方针下，带领巨头们发布了面向不同领域的各个版本：面向PC领域的java2 Standard Edition，面向企业级计算的Java 2 Enterprise Edition，面向嵌入式系统的Java2 Embedded Edition, 面向智能终端的Personal Java Edition。
　　在这样的一种趋势下，迫不得已，只有放下曾经让我无限自豪、热情彭湃的C++－－我心爱的C++！
一边，在国内，是还达不到使用C++这样的高度；另一边，在硅谷，C++已经丧失了昔日的辉煌。感叹万余，痛定思痛－－随即，以着极大的热情投入到java的事业中，幸好有着C++的功底和以前对java的基本接触，java很快就上手，来到了java世界里，啊，原来java还可以这么用，这是以前根本没想到的，以前一直以为自己是个oop行家，这才发现跟java比，简直就是小巫见大巫－－oop在java中被运用的炉火纯青，java本是是一个开放的体系，各家厂商都可以对她扩展、实现，要维护整个java世界的纯洁，他们采用了一种绝妙的方法，运用java的100%oop特点，对于规范的定义只是一些接口，而这些接口的实现，则完全由各个厂家去负责，多么的和谐，多么的完美！理解不了这些，你就根本无法理解象EJB,Servlet/JSP,JTA、RMI/IIOP、JNDI,JMS，Jini....这些java新秀的威力，稍大一点的公司（除了Microsoft），无一不对她趋之若宠，源源不断的
钱财、人力往这里白扔也值。这仅仅只是个j2ee，也是到目前为止，业界中最为完美的企业解决方案，就更不用说j2me了，想做下一代internet接入设备，除了j2me可以说是别无选择，更要命的是她完全可以与现有系统紧密的衔接起来......
　　......
　　－－我并非是想把C＋＋说得一无是处，我本人对C＋＋仍然是有着无比的崇拜，只是每把刀都有每把刀的用处，在系统、支撑软件领域，C++还是老大，只是不要把这种老大的思想随处烂放。在应用领域现在是java，不管你承认也好，否认也罢，辛辛苦苦用C++写的一套Solution才买10万还不到，而java轻松就完成的Solution可以卖到几百万，这就是区别；同样，如果仅仅把java当作applet，application用在桌面环境中，她的的确确又比任何一种语言都烂。
　　我所说的只是国内的环境影响着我们每一个人，当java one 2000在美国红红火火的举行，多达4万家公司挤进会场，更是有3000余名专家、学者在会上慷慨陈辞时，而国内还是不以为然，守着以前的老家当，倒是精明的日本人，早就预定了数十个座位；当个大公司在java的领域里进行惨烈争夺的时候，国内还抱着VB,Delphi 枕着C＋＋睡大觉。
　　“java？－－不过是个玩具儿”，朋友、兄弟－－我真的再也不想听到这样的话了，也许你说这话的时候，有一丝的快感，但是你应该知道，在你笑得时候，人家国外的同行比你笑得更开心，他们是何等的希望我们永远都把她当作玩具！
　　我真的希望国内的朋友们，到网上去看一看，到国外的公司去看一看，不要被国内的氛围、环境所左右。
我不想再说了，我实在是不忍心看到在这个领域里，被国外的同行越拉越远！－－事实上是已经被远远的
拉在后面！

D6的LIB中丢失了一个proxies.dcu文件，导致它的Demos/Propedit包虽可安装但无法

正常使用，一些用到（或间接用到这个文件）的控件也无法正常使用，如ABF控件

To：homejun

这就是你的不对了，proxies.dcu已被包含入designide.dcp中，包含即可。

这是我看来的，
还没有经过实际测试
=====================
Delphi6的严重Bug?
我也不知道这算不算一个Bug,不过他实在是太严重啦！
我正在学习使用TDBLookupComboBox和TdataSource显示数据，可是奇怪的现象发生了，
当我在Project管理器中双击打开含有这两个控件的窗体时，整个Delphi一下了就退出了，
没有停滞，没有任何反应，也不提示你保存什么的，实在是太快啦！要知道正常关闭delphi6
要花很多时间来释放内存，可是这一下子比我关闭一个什么内容都没有写的NotePad还要快，
我估计是Delphi崩掉了，所以退出特别快！虽然Delphi6启动很慢(Delphi6的启动可是比我
的windows启动还要慢)，如果只是退出还好说，可是以后只要再打开出错的窗体，
整个Delphi6又刷的一下退出了，如此反复，我试了几十次，中间居然有一次成功了，
可是只要一执行语法检查或complie，则又退出了！要知道那个窗体是我花了整整一天的
时间做出来的呀！(呜呜......)今天早上我只好重新做起，可是噩梦再次降临，我已经
几乎做完了，可是当我再加上TDataSource(加TDBLookupComboBox时还没有)时，我知道已
经完了，今天一天又白做了！呜呜呜！我该怎么办呢？这种现象我以前使用PB时也碰到过，
可是PB的启动实现是太快了，退出我可以再来(在我机器上PB启动五次Delphi6只能启动一次
)，而且像这样的错误可以使用Regenerate修复窗体，可是Delphi6怎么办呢？各位大哥有没
有碰到这种情况？我希望是我没有调节好，请各位帮助我吧！
注：到我写这篇文章时，只要我在任何地方uses 这个窗体的单元文件，整个delphi就崩掉!!!
======================================================
你们碰到了吗？？？

很多，
我说一个，不知是不是！
用FileOpen+共享只读模式能打开的文件！
而用AssignFile＋Reset＋FileMode:ReadOnly却不行，还会非法操作！
我不明白，我不懂！

最大的bug就是无法安装！

从6到5有什么特别显著出色的变化我还没有把握到，但是我很喜欢它的代码助手哟，爽！
不用记这么多单词怎么拼了，嘿嘿

我害怕看那么长的文章.

to whg972
你说的不对，我买的delphi6 2cd装的（当然是D版），其中第二张全是控间
难道还说支持的少吗？？？

现在很多人都说DELPHI6BUG太多，都不敢用。说是功能强了，但BUG太多，这样的编译器
必将影响DELPHI的发展。很有可能DELPHI5会成为DELPHI发展最鼎盛的时期。所以，作为
一门开发工具，只有用的多，才会有生命力的。BOLAND两年以后才出大家所共同期待的
DELPHI6，但我发觉越来越多的人评价他的BUG问题。大家一定听说过BORLAND公司的DELPHI
开发TEAM，现在不知是不是因为BORLAND公司不重视DELPHI了还是这个TEAM里的人员技术太
差，导致很多开始用DELPHI6的程序员都骂人，我很喜欢DELPHI，我希望他始终是一个让很
多程序员都愿意选择的开发工具。可谁又能保证他还能风光多久呢？

The Delphi Bug List
http://jp.njuct.edu.cn/crystal/turn_to.asp?class=urllink&id=23
Borland Delphi Information and Utilities
http://jp.njuct.edu.cn/crystal/turn_to.asp?class=urllink&id=24