刚才吃过午饭就看了一会电视，很久没有象样地看看电视了。
正好碰上方宏进主持的《中国经营者》，采访的对象是UT斯达康的吴鹰。
在谈到小灵通被认为是落后技术的问题时，吴鹰的回答我觉得很好：评价一个技术是先进还是落后，不应该看它是否前卫，因为历史上有太多的前卫技术最终归于消亡并且几乎没有留下什么痕迹，比如“铱星”；最关键的还是看它是不是降低了成本，创造了效益。
那些指责小灵通技术落后的人为什么不问问自己：为什么UT斯达康能凭着一项“落后”的PHS技术，取得了每年近60%的增长率？
归根结底还是取决于市场！
最后吴鹰说了：小灵通最终是一定会被淘汰的，但它具有的历史意义始终存在，那就是–它是中国电信史上第一项被市场选择的技术，而不是被政策所选择的。
软件业其实也一样，我们常常会被大公司层出不穷的新技术引得团团转，按孟岩兄的说法就是：被不断地反复蹂躏。
事实上很多人却忽视了最关键和重要的一点：我们的用户其实最关心的并不是你用的什么技术，而是你的软件是否能解决他们的问题！
只有被市场所选择的技术，才是好的技术！
那么市场是什么？
大公司不可能是我们的市场。如果我们跟着大公司走，正是中了他们的圈套，因为我们就是他们的市场。
要记住的是：我们的用户才是我们的市场！
如果不能意识到这一点，就只能跟在大公司的PG后面转，永远不会有大的成长。
没什么可写的就贴PP吧:)
传说中的“厦大”
南普陀
那天吃完活鱼在员当湖边拍的湖滨北路
中山公园
中山路（从文化宫方向）
大中路
从轮渡上看黄昏的鼓浪屿
厦鼓轮渡
鼓浪屿轮渡的海豚雕塑
鼓浪屿最高点：日光岩
菽庄花园外的海滩（人多垃圾就多啊，汗）
一轮满月照耀下的菽庄花园
夜之海
环岛路的灯火
厦门之夜
轮渡的标志性建筑
老字号黄则和花生汤
熙熙攘攘的定安夜市
EXIF格式分析及通过XML处理
EXIF格式分析及通过XML处理
随着数码相机的普及，EXIF已经被大多数图像处理软件所支持。虽然我做的是一个小玩意儿（见《人个信息助理之我的相册》）但毕竟也是用于图像处理的，虽然目前支持JPEG文件格式，但是还不支持EXIF。
那么，什么是EXIF呢？EXIF是Exchangeable image file format的缩写，即“可交换图像文件格式”，它是由日本电子与信息技术工业协会（JEITA）所制定的一项标准，用于实现在不同的软件或设备之间交流图像数据，典型的应用就是数码相机直接连接打印机打印照片。当然，EXIF中还包含了很丰富的信息，从中可以知道这个数码照片是用什么相机拍的，拍摄时用的光圈、速度、ISO等。而且最新版本的EXIF还支持音频格式文件。
关于EXIF的最权威文档资料当然是JEITA的标准规范[1]，目前最新的版本是2.2。不过JEITA的网站上虽然提供了两个语言版本（日语和英语，并且JEITA声明以日文版为准）的规范文档，但是需要收费的。还好通过GOOGLE还是找到了一个英文版的。
EXIF只提供对两种图像文件格式的支持：TIFF[2]和JPEG[3,4]。其中对不压缩图像使用TIFF格式，对压缩图像使用JPEG格式。本文主要讨论JPEG格式。
我们知道JPEG文件格式是通过所谓的Marker Segments来记录图像的相关信息的，这种方式具有非常好的灵活性和可扩充性，较之早年的PCX，GIF，BMP等采用固定格式文件头记录的方式要好很多（PCX原先是为16色图像设计的，在256色图像出现后，就破坏了原先的格式定义，将调色板续在文件尾部；而GIF虽然内部也有分段机制，后来被扩充为实现动画功能，但仍然是采用固定格式的文件头记录基本信息），而EXIF就是利用了这一点。
JPEG文件中的每一个Marker Segments都是以一个WORD类型的数值开始（注意：这个数值记录在文件中时是高位字节在前，低位字节在后，将在后面介绍这个字节顺序的问题），这个数值即所谓的Marker，每个Marker代表着相应的Segment的意义，如果这个Segment有内容（即长度大于0，是否有内容视具体Marker而定），接下来的一个WORD类型的数值就是这个Segment的长度（这个数值的字节顺序与Marker相同），至于Segment的具体内容，则根据Marker的不同有不同的定义。如FFD8这个Marker叫做SOI，表示图像的开始，这个段是没有内容的；如FFE0则是APP0，即应用程序段0，属于可自定义的数据，它已经被用于JFIF[4]，这个段则是有内容的，接下来的一个WORD就是段长度，段内容的定义是由JFIF规范所定义。
EXIF也是一种扩展定义，类似于JFIF，它使用了APP1和APP2这两个Marker Segments。之所以要用两个Marker是因为如前面所说，Segment的长度是用一个WORD来表示，即最大不超过64K。因为EXIF支持一种被称为Flashpix的无损图像格式，其数据很可能超过64K，所以用了APP2，其中APP2可以有多个，不过因为对Flashpix的支持属于EXIF的扩展功能（在规范文档的附录F中说明[1]），通常很少用到，本文不作讨论。
EXIF定义的APP1段是一个标准的JPEG Marker Segment，如表1所示。其中的APP1 Marker的值为FFE1，Length为这个段的长度，其值包括Length本身所占的两个字节，但不包括Marker所占的两个字节。段中剩下的部分便是EXIF数据。
EXIF数据的格式定义也很简单，如表2所示。它包括两个部分：EXIF< span>头和TIFF头。EXIF头由六个字节组成，其内容为一个长度为4的ASCIIZ（以NULL结尾的ASCII）字符串，加一个字节的0（用于使数据按WORD对齐），而这个ASCIIZ串内容就是“Exif”。而TIFF头则是采用了标准的TIFF文件格式的定义（TIFF同样是一种定义灵活的文件格式，在某种程度上说是太灵活了），这样可以让JPEG和TIFF两种格式中的EXIF信息可以以一致的方法进行处理。
|
起始 |
长度(Bytes) |
内容 |
|
0x00 |
2 |
APP1 Marker(0xFFE1) |
|
0x02 |
2 |
Length |
|
0x04 |
Length – 2 |
EXIF Data |
表1：APP1段格式定义
|
起始 |
长度(Bytes) |
内容 |
|
0x00 |
6 |
EXIF Header |
|
0x06 |
APP1 Length – 8 |
TIFF Header |
表2：EXIF格式定义
|
起始 |
长度(Bytes) |
内容 |
|
0x00 |
2 |
Byte order |
|
0x02 |
2 |
Flag(0x2A) |
|
0x04 |
4 |
The offset of the first IFD |
表3：TIFF Image File Header格式定义
TIFF Header[2]包括两个部分：Image File Header和IFD（Image File Directory）链表。其中Image File Header的定义如表3所示。其中Byte order用于说明此TIFF文件所采用的字节顺序，用两个字符表示，有两种选择，分别是：II和MM（这个MM跟美眉无关J），其中II是指采用Intel字节顺序，而MM是指采用Motolora字节顺序（见下面的说明）。Flag是TIFF文件格式的标志，总是为0x002A，即十进制数42。最后一个DWORD是指向第一个IFD的起始位置，其偏移量的计算起点是TIFF Header的起点，即如果第一个IFD是紧接着Image File Header的话，这一项的值就为8（Image File Header的大小）。
关于字节顺序的说明：
字节顺序是可交换文件格式中，特别需要注意的一个问题。所谓“可交换文件格式”就是说这种文件格式可以在各种不同的软硬件平台下被正确地解读。字节顺序问题的起因在于硬件上。
在CPU发展的早期（8位CPU的时代），由于指令集的丰富，许多8位CPU都可以处理16位数据，当然都是分两次进行的，这时就出现的字节顺序的问题：是先处理高位字节还是先处理低位字节？不同的CPU厂商采用不同的选择！以Intel, Zilog等公司为代表的CPU厂商是采用先低后高的方式，即低位地址保存低位字节的数据；
而以Motolora（它可不止是做手机，它曾经是世界上最大的电子产品制造商）则是采用先高后低的方式，与通常人的阅读顺序一致。对应的硬件就是采用Intel架构的IBM PC及其兼容机上运行的软件都是采用Intel顺序的，而采用由IBM，Motolora，Apple共同设计的Power PC芯片的Apple Mac则是采用Motolora顺序的。
现在，字节顺序问题不只出现在图像格式上，由于Unicode字符集（UCS）也是采用了16位（UCS-2）或32位（UCS-4）来表示一个字符，所以也面临着字节顺序的问题。
另外，按照各自字节顺序的特点，Intel的字节顺序也叫做little-endian，而Motolora的字节顺序就叫做big-endian。
图1：IFD链表结构
IFD是一个链表结构，如图1所示，在每个IFD的末尾包含一个指向下一个IFD的偏移量（同样是从TIFF Header算起），如果这个偏移量为0，则表示已经到了链表的末尾。EXIF只使用了两个TIFF IFD，分别被称作IFD0和IFD1，但定义了三个自己的IFD：EXIF IFD, GPS IFD, Interoperability IFD，它们的结构与标准TIFF IFD相同，但不是记录于TIFF的IFD链表中，而是作为IFD0的扩展记录的。
|
起始 |
长度(Bytes) |
内容 |
|
0x00 |
2 |
Number of Directory Entries(Count) |
|
0x02 |
12 * Count |
Directory Entries |
|
2 + 12 * Count |
4 |
Offset of next IFD |
表4：IFD格式定义
每个IFD由三个部分组成，如表4所示，包括：Number of Directory Entries，Directory Entries和Offset of next IFD。其中Number of Directory Entries指定在Directory Entries中包含多少个Entry。Directory Entries是一个数组，包含若干个Directory Entry。最后的Offset of next IFD即是下个IFD所在的位置，如果此项为0，则表示这是链表中的最后一个IFD。
|
起始 |
长度(Bytes) |
内容 |
|
0x00 |
2 |
Tag |
|
0x02 |
2 |
Type |
|
0x04 |
4 |
Size |
|
0x08 |
4 |
Value |
表5：IFD Entry格式定义
IFD Entry是一个12字节长的结构，如表5所示。正如TIFF的名称所说的那样：A tag-based file format for storing and interchanging raster images[2]。所有的IFD Entry都是通过Tag来标识的，每一个Tag都是一个WORD类型的数值，每个数值有其特定的含义。如0x0131这个Tag表示此Entry记录的是生成此TIFF文件的软件名等。具体每个Tag的含义可能查阅TIFF的规范文档[2]。EXIF只用到了其中部分Tag，另外还扩充了三个Tag用于链接EXIF的三个扩充IFD，这些在EXIF的规范文档中有说明[1]。
IFD Entry中的Type是指明此Entry中记录的数据类型，TIFF规范只定义了五种类型，EXIF增加了三种。各类型说明如表6所示：
|
Type |
类型 |
Size |
Value |
|
1 |
BYTE |
1 |
字节数据，Size一般为1 如果Size大于4，则Value为其位置 |
|
2 |
ASCII |
n |
一个ASCIIZ的字符串，Size为串长度，包括结尾的NULL字符 Size小于等于4则直接存放在Value中 Size大于4，则在Value中指定其位置 |
|
3 |
SHORT |
1 |
无符号短整数，Size一般也为1 如果Size大于2，则Value为其位置 |
|
4 |
LONG |
1 |
无符号长整数，Size一般也是1 |
|
5 |
RATIONAL |
1 |
有理数，TIFF是用分数的形式来表达，用了两个LONG类型的数据，前一个LONG为分子，后一个LONG为分母，Size一般也是1。 因为一个RATIONAL类型包含两个LONG，无法记录在Value中，所以Value中记录的是这个RATIONAL数所在的位置（从TIFF Header开始的偏移） |
|
以上为TIFF定义的类型，以下为EXIF扩展定义类型 |
|||
|
7 |
UNDEFINED |
n |
任意的字节数据，根据具体情况定义 Size小于等于4则直接存放在Value中 Size大于4，则在Value中指定其位置 |
|
9 |
SLONG |
1 |
有符号长整数，与LONG类似，以2的补码形式表示 |
|
10 |
SRATIONAL |
1 |
有符号有理数，与RATIONAL类似，不过是用两个SLONG来表示 |
表6：Type定义
关于Value的内容有一点要注意的是，它可能是数据本身，也可能是数据存放位置的偏移，这取决于Type和Size的大小。数据存放位置都是从TIFF Header开始计算的偏移量。
有一点要注意的是：EXIF的三个扩充IFD Tag也是LONG类型，它记录的是相应IFD的起始位置（从TIFF Header开始的偏移）。在扩充IFD中用到的Tag全部是EXIF重新定义的。
下面是一个典型的EXIF JPEG文件格式分析结果（源文件为一张用Nikon CoolPixel 775相机拍摄的照片，所用的EXIF版本是2.1，与2.2版差别不大）：
JPEG SOI : FF D8 // 图片起始
JPEG APP1: FF E1
APP1 Size : 1C 45 // 注意：前面这三个WORD都是big endian的
EXIF Flag : ‘Exif’, 0, 0
TIFF Header:
Byte Order: ‘II’
Flag : 2A 00
IFD0 offset : 08 00 00 00
Entries Count : 0B 00 // 11
IFD Entry :
Tag : 0E 01 // Image Description 图像说明
Type : 02 00 // ASCII
Size : 0B 00 00 00
Value : 92 00 00 00 // from TIFF Header
IFD Entry:
Tag : 0F 01 // Make 制造
Type : 02 00
Size : 06 00 00 00
Value: B2 00 00 00
IFD Entry:
Tag : 10 01 // Model 型号
Type : 02 00
Size : 05 00 00 00
Value: CA 00 00 00
…
IFD Entry:
Tag : 69 87 // EXIF IFD
Type : 04 00 // LONG
Size : 01 00 00 00
Value: 1C 01 00 00 // Offset of EXIF IFD
END of IFD0
IFD1 Offset : 18 03 00 00
… // 存放IFD的Value数据
EXIF IFD :
Entries Count : 18 00
IFD Entry :
Tag : 9A 82 // Exposure time
…
END of EXIF IFD
Next IFD : 00 00 00 00 // 按标准IFD链表约定，表示没有后继IFD
… // 存放EXIF IFD的Value数据
IFD1 : // EXIF中用于存放缩略图
Entries Count : 06 00
IFD Entry :
Tag : 03 01
…
END of IFD1
Next IFD : 00 00 00 00 // EXIF只用到两个TIFF IFD
… // Thumbnail etc.
// end of TIFF header
// 其它JPEG Marker segments
JPEG EOI : FF D9 // 图片结束
对EXIF格式的分析，至此基本上告一个段落了。从分析结果上可以看出，EXIF是一种非常灵活的格式，具有非常好的可扩充性，要想较好地处理其中的相关数据也是比较麻烦的。
其困难主要在于几个方面：
1、对于每种不同的IFD Entry Type，需要用不同的方法获取数据，特别是对于数据长度不同时，可能采用不同的数据存储方式，而IFD Entry的数量又可能很多，每个Entry根据Tag不同又有不同的意义
2、EXIF IFD是作为TIFF IFD的子链表形式存在（因为EXIF的IFD里定义了不同于TIFF标准的Tag，要保持与标准的TIFF格式互用，必须这样做），使得原来的链表结构变成了树形结构
3、Tag的种类和数量非常之大，在EXIF规范里定义了各个Tag的支持级别（见[1]4.6.8），光是JPEG格式下必须支持的Tag就有十几个，TIFF格式更多，再加上可选支持的Tag，有几十上百个，并且还存在未来继续扩充的可能
4、对于可支持不同语言的软件来说，同一个Tag的意义要用每一种支持的语言表达一次，如果将这部分处理写入代码，对于增加新的语言支持会带来不必要的麻烦
为了解决这些困难，必须要找到一个同样是非常灵活的处理方法来处理EXIF数据。而XML正是这样一种方法。从前面的分析结果可以看出，EXIF的数据记录方式是层层嵌套的树形结构，是非常适合用XML的，因为XML也是这样的树形结构。
通过定义一套XML标签，然后将EXIF数据转换成XML文档，可以最大限度地保留EXIF数据的原始内容及结构。并且作为一种通用格式，XML可以很方便地进行再处理，比如：通过XSLT进行转换，使之成为HTML或其它便于显示的格式；或者将此XML传递给其它软件作进一步处理等。
对于前面说到的困难，XML都很好地解决：
1、不同类型的问题，通过转换为XML，将所有的Value都转换成字符串，便于统一处理
2、XML本来就是树形结构，可以在转换的时候方便地通过调整节点位置，使各IFD统一处理
3、可以将所有的Tag原样导出到XML中，在以后对XML的处理时再根据Tag进行处理，比如通过修改XSL文件实现对新增Tag的支持
4、同样是对XML处理时才需要面对具体的Tag，比如为不同的语言提供相应的XSL文件即可
下面的代码片断(Borland C++ Builder)实现了从EXIF数据到XML的转换：
//---------------------------------------------------------------------------#include typedef struct {WORD EntryTag;WORD EntryType;DWORD EntrySize;DWORD EntryValue;} TIFDEntry;#include //---------------------------------------------------------------------------BYTE * __fastcall TExifXML::GetIFD(_di_IXMLNode aNode, BYTE * aTIFFHeader, int aPosition, AnsiString aName){_di_IXMLNode pIFD = aNode->AddChild( "IFD" );if ( aName != "" )pIFD->Attributes["name"] = aName;BYTE * p = aTIFFHeader + aPosition;WORD nWord;memcpy( &nWord, p, sizeof ( nWord ) );p += sizeof ( nWord );_di_IXMLNode pChild = pIFD->AddChild( "Count" );pChild->Text = Format( "0x%X", ARRAYOFCONST( ( ( int )nWord ) ) );TIFDEntry ent;_di_IXMLNode pEntry;BYTE * pTemp;for ( int i = nWord; i > 0; --i ){memcpy( &ent, p, sizeof ( ent ) );p += sizeof ( ent );pEntry = pIFD->AddChild( "Entry" );pChild = pEntry->AddChild( "Tag" );pChild->Text = Format( "0x%X", ARRAYOFCONST( ( ( int )ent.EntryTag ) ) );pChild = pEntry->AddChild( "Type" );pChild->Text = IntToStr( ent.EntryType );pChild = pEntry->AddChild( "Size" );pChild->Text = Format( "0x%X", ARRAYOFCONST( ( ( int )ent.EntrySize ) ) );pChild = pEntry->AddChild( "Value" );switch ( ent.EntryType ) {case 1 : // BYTEif ( ent.EntrySize == 1 )pChild->Text = Format( "0x%.02X", ARRAYOFCONST( ( ( int )( BYTE )ent.EntryValue ) ) );elsethrow Exception( "Unsupported!" );break;case 2 : // ASCIIif ( ent.EntrySize <= 4 )pChild->Text = reinterpret_cast( &ent.EntryValue );elsepChild->Text = reinterpret_cast( aTIFFHeader + ent.EntryValue );break;case 3 : // SHORTif ( ent.EntrySize == 1 )pChild->Text = Format( "0x%.04X", ARRAYOFCONST( ( ( int )( WORD )ent.EntryValue ) ) );elsethrow Exception( "Unsupported!" );break;case 5 : // RATIONALpChild->Text = FloatToStr( *reinterpret_cast( aTIFFHeader + ent.EntryValue )/ ( double )( *reinterpret_cast( aTIFFHeader + ent.EntryValue + sizeof ( DWORD ) ) ) );break;case 7 : // UNDEFINEDif ( ent.EntrySize <= 4 )pTemp = reinterpret_cast( &ent.EntryValue );elsepTemp = aTIFFHeader + ent.EntryValue;pChild->Text = "";for ( int j = 0; j < ( int )ent.EntrySize; ++j ){pChild->Text = pChild->Text+ Format( " 0x%.02X", ARRAYOFCONST( ( ( int )( BYTE )( *pTemp ) ) ) );pTemp++;if ( j % 16 == 15 )pChild->Text = pChild->Text + "rn";}break;case 9 : // SLONGif ( ent.EntrySize == 1 )pChild->Text = IntToStr( ent.EntryValue );elsethrow Exception( "Unsupported!" );break;case 10: // SRATIONALpChild->Text = FloatToStr( *reinterpret_cast( aTIFFHeader + ent.EntryValue )/ ( double )( *reinterpret_cast( aTIFFHeader + ent.EntryValue + sizeof ( int ) ) ) );break;default: // LONG & other unknown typepChild->Text = Format( "0x%.08X", ARRAYOFCONST( ( ( int )ent.EntryValue ) ) );break;}switch ( ent.EntryTag ) {case 0x8769 : // Exif IFDGetIFD( aNode, aTIFFHeader, ent.EntryValue, "EXIF" );break;case 0x8805 : // GPS IFDGetIFD( aNode, aTIFFHeader, ent.EntryValue, "GPS" );break;case 0xA005 : // Interoperability IFDGetIFD( aNode, aTIFFHeader, ent.EntryValue, "InterOp" );break;}}return p;}//---------------------------------------------------------------------------void __fastcall TExifXML::GetTIFFHeader(_di_IXMLNode aNode, BYTE * aTIFFHeader){BYTE * p = aTIFFHeader;char sByteOrder[3];memcpy( sByteOrder, p, 2 );p += 2;sByteOrder[2] = 0;_di_IXMLNode pChild = aNode->AddChild( "ByteOrder" );pChild->Text = sByteOrder;WORD nFlag;memcpy( &nFlag, p, sizeof ( nFlag ) );p += sizeof ( nFlag );pChild = aNode->AddChild( "Flag" );pChild->Text = Format( "0x%.04X", ARRAYOFCONST( ( ( int )nFlag ) ) );DWORD nPointer;memcpy( &nPointer, p, sizeof ( nPointer ) );int i = 0;while ( nPointer > 0 ){p = GetIFD( aNode, aTIFFHeader, nPointer, AnsiString( "IFD" ) + IntToStr( i++ ) );if ( !p )break;memcpy( &nPointer, p, sizeof ( n
Pointer ) );}}//---------------------------------------------------------------------------int __fastcall TExifXML::LoadFromStream(TStream * aStream){if ( !FXMLDoc )throw Exception( "XMLDoc property is null!" );TMauto_ptr ms( new TMemoryStream( ) );ms->CopyFrom( aStream, aStream->Size );ms->Seek( 0, soFromBeginning );FXMLDoc->FileName = "";FXMLDoc->Active = true;FXMLDoc->Version = "1.0";FXMLDoc->Encoding = "GB2312";_di_IXMLNode pNode = FXMLDoc->AddChild( "ExifAPP1" );_di_IXMLNode pChild = pNode->AddChild( "ExifID" );char sExifID[6];ms->Read( sExifID, 6 );pChild->Text = sExifID;pChild = pNode->AddChild( "TIFFHeader" );BYTE * pHeader = static_cast( ms->Memory ) + ( int )ms->Position;GetTIFFHeader( pChild, pHeader );return ms->Size;}
其中FXMLDoc是一个TXMLDocument控件，用于生成XML。LoadFromStream方法读入的内容为JPEG APP1这个Marker Segment的内容（注意，不是JPEG文件）。GetTIFFHeader方法用于读出TIFFHeader的内容，包括Image File Header和IFD链表。GetIFD则是用于解读IFD的具体内容，其中包括对EXIF的三个扩充IFD的递归解读，并且其中包含了将各种数据类型转换为字符串的部分，特别是对不定长的UNDEFINED类型的处理（其结果见下面转换后的XML）。
转换后的XML大致如下：
<?xml version="1.0" encoding="GB2312"?><ExifAPP1><ExifID>Exif</ExifID><TIFFHeader><ByteOrder>II</ByteOrder><Flag>0x002A</Flag><IFD name="IFD0"><Count>0xB</Count><Entry><Tag>0x10E</Tag><Type>2</Type><Size>0xB</Size><Value> </Value></Entry><Entry><Tag>0x10F</Tag><Type>2</Type><Size>0x6</Size><Value>NIKON</Value></Entry><Entry><Tag>0x110</Tag><Type>2</Type><Size>0x5</Size><Value>E775</Value></Entry>...<Entry><Tag>0x8769</Tag><Type>4</Type><Size>0x1</Size><Value>0x0000011C</Value></Entry></IFD><IFD name="EXIF"><Count>0x18</Count>...<Entry><Tag>0x9000</Tag><Type>7</Type><Size>0x4</Size><Value> 0x30 0x32 0x31 0x30</Value></Entry>...<Entry><Tag>0x9286</Tag><Type>7</Type><Size>0x7D</Size><Value> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x200x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20</Value></Entry>...<Entry><Tag>0xA005</Tag><Type>4</Type><Size>0x1</Size><Value>0x00000376</Value></Entry>...</IFD><IFD name="InterOp"><Count>0x2</Count><Entry><Tag>0x1</Tag><Type>2</Type><Size>0x4</Size><Value>R98</Value></Entry><Entry><Tag>0x2</Tag><Type>7</Type><Size>0x4</Size><Value> 0x30 0x31 0x30 0x30</Value></Entry></IFD><IFD name="IFD1"><Count>0x6</Count><Entry><Tag>0x103</Tag><Type>3</Type><Size>0x1</Size><Value>0x0006</Value></Entry>...</IFD></TIFFHeader></ExifAPP1>
有了这个XML就可以很方便地进行下一步处理了，比如用下面这个XSL文件对上面这个XML进行转换：
<?xml version="1.0" encoding="GB2312" ?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/TR/WD-xsl"><xsl:template match="/"><xsl:for-each select="ExifAPP1/TIFFHeader/IFD/Entry"><xsl:choose><xsl:when test="Tag[.='0x10F']">制造商=<xsl:value-of select="Value" /></xsl:when><xsl:when test="Tag[.='0x110']">型号=<xsl:value-of select="Value" /></xsl:when></xsl:choose></xsl:for-each></xsl:template></xsl:stylesheet>
即可得出下面的结果：
制造商=NIKON
型号=E775
以后不论是增加Tag还是要改语言，只要修改这个XSL文件即可实现，完全不用修改EXIF处理部分的程序代码，非常的灵活方便。
2004-4-3
参考文献：
[1] JEITA CP-3451. Exchangeable image file format for digital still cameras:Exif Version 2.2. JEITA(Japan Electronics & Information Technolog Industries Association). April, 2002.
[2] Aldus Corporation. TIFF Revision 6.0 Final – June 3,1992.
[3] Gregory K.Wallace. The JPEG Still Picture Compression Standard.Communications of the ACM. April, 1991.
[4] Eric Hamilton. JPEG File Interchange Format Version 1.02. C-Cube Microsystem. September 1, 1992.
可怜的中国软件
今天刚写了一篇跟物理有关的BLOG，就在CSDN上看到这个：《[教育]尴尬的国际地位－可怜的中国物理！》
可怜的又何止物理呢？软件业不是一样，推而广之，整个中国计算机业也是。归根到底是整个中国的学术界都有问题。那些所谓的砖家，鞋者们，很多其实在真正的大师面前，是连给人提鞋也不配的。这不是我要妄自菲薄，实在是因为它们“学术腐败”。当然这其中教育要承担很大的责任，所谓上梁不正下梁歪，老师教授都不是靠真正的学术成果得到升迁或好的待遇，那学生自然要靠抄袭才能完成毕业论文了（单MOP上就常见有人散尽MP求论文的，CSDN上也有）。
不过真要深究下去就没底了，因为整个社会的道德水准都在沦丧，这一点只要每个周日看看中央台的《每周质量报告》应该就会深有体会了。
还是回到软件业上。中国自从有了所谓的软件行业，就始终是笼罩在一种急功近利的浮躁氛围中。这其中IT媒体对所谓的科技明星的炒作有一份很大的功劳。于是乎，听说Bill.Gates靠软件发大财了，就一窝蜂地去做软件；听说.com流行了，就一窝蜂地去Internet上淘金；听说JAVA不错，就全开始J2EE/EJB起来；听说.net要后来居上，就全都开始啃C#；听说印度人做软件不错，就排着队上西天取经去了；听说CMM/ISO 9000好，就一个个去过认证，最可笑的是好像很少有过不了的；听说RUP好，就都开始ROSE上了；听说XP不错，就一个个Agile起来……转眼二十几年过去了，MS从一个几十个人的小公司成为世界第一大软件公司，我们呢？什么也没有……不，还有巨人、科利华、TOP之类，都是“大”“软件”公司啊……
我们不是革命者，没有能力去改变这个社会，但至少我们能做到：踏实做好自己的事。浮躁之风，能少一点是一点。
高技术流氓
在偶的QQ里有几个技术群，比较寒的是，在这几个群里的家伙都知道偶是个老流氓。
不过很不幸的是，我昨天在C++NPv2（D.Schmidt的关于ACE的书的第二卷）的译序里看到马维达引用了Linus.Torvalds的一句名言：“Software is like sex: It’s better when it’s free!”原来越是高手就越是流氓啊。
大概这也是人之常情吧。英国著名物理学家Stephen.Hawking（《时间简史》的作者）就曾经因一个关于黑洞的问题和美国著名物理学家Kip.Thorn打赌：“史蒂芬·霍金：我和基帕·索恩打赌说，在天鹅座X－1中没有黑洞，这对我来说像是买保险。我为研究黑洞做了大量工作，如果黑洞不存在，我花的工夫就都白费了。所以，如果黑洞存在，基帕就会得到一年的《阁楼》。如果不存在，我将得到四年的《私人眼睛》作为安慰奖品。”–引自《时间简史》第三章，在Thorn的书《黑洞与时间弯曲》一书中也有讲到这次打赌。
而《阁楼》（或译得更直接一些叫《藏春阁》）和《私人眼睛》（或译作《私家侦探》）都是和《花花公子》类似的成人杂志：P
至于他们打赌结果，据说在新版的《时间简史》第6章中有说到：“事实上，从我们打赌的1975年迄今，虽然天鹅X-1号的情形并没有改变太多，但是人们已经积累了这么多对黑洞有利的观测证据，我只好认输。我进行了约定的赔偿，那就是给基普订阅一年的《藏春阁》，这使他开放的妻子相当恼火。”
不过话说回来，Hawking都那样了，他要《Private eyes》杂志来能干什么？YY吗？^_^
类似的事情还有很多，最典型的便是Kip.Thorn的老师：John.Wheeler了。他也是非常著名的物理学家，黑洞（Blackhole）这一术语便是出自他老人家。据说这个词也是含有一些流氓意味的，当时并不很能让人接受，不过现在不也成了标准词汇了：）还有一个更流氓的词汇是“黑洞无毛”^_^，这也是出自Wheeler之手，其本意不过是要说明：当一个任意形状的恒星最终坍缩成一个黑洞后，就一定是一个理想的球体，表面不会有任何起伏。不过话说回来，用这个词汇来表达，的确比较让人印象深刻。–以上关于Wheeler的内容出自《黑洞与时间弯曲》一书
真流氓总是比伪君子可爱一些，正如鲁迅先生所说：“说自己是强盗的无须防，得其反倒是好人了；说自己是好人的必须防，得其反便是强盗。”:P
自以为是
最近在研究ACE，偶然想起一件有趣的事：
几个月前刚开始研究的时候，在网上碰到有人在讨论ACE，研究过ACE的人都知道，ACE是“ADAPTIVE Communication Environment”的缩写。问题就出在这里了，那天有个家伙就很自以为是地把它写成：“Adaptive Communication Environment”，虽然只是一个大小写的不同，其实差别大了。
因为ADAPTIVE本身也是一个缩写，它的完整意思是：“A Dynamically Assembled Protocol Transformation, Integration, and eValuation Environment” ，它是ACE的前身，是D.Schmidt91年时在UCI读博时做的一个课题，Schmidt就是在做ADAPTIVE时碰到一些偶发复杂性等方面的问题，所以在92年开始了ACE项目。
其实这种自以为是的事还很多，我有个同学（就是那个“叫床”的^_^）就跟我说过两个例子：一个是“苑”字，本来他一直是读得对的，不过一回，有个人很善意地告诉他，这个字读“wan（上声）”，结果他也信以为真，此后一直读错了：）另一个更好玩，有一回他在公交车上和别人讨论PWS（Personal Web Server），结果也是旁边一个很善良的人，告诉他们那个东东叫做WPS！
不过话说回来，这种事我也干过，比如那个looser的问题，自己也寒一个。:)
昨天关于BCB9的聊天记录
2004-05-12 14:56:31 ccrun
http://expert.csdn.net/Expert/topic/3058/3058698.xml?temp=.1365167
2004-05-12 14:57:45 ccrun
BCB 9.0？各位老大可曾听说？
2004-05-12 14:57:51 猛禽
扯吧
2004-05-12 14:58:19 闪电侠
NB，都干到9。0了
2004-05-12 14:58:51 玉笛书生
7都没有呢，跨越式啊。。
2004-05-12 14:59:11 令狐虫
6.0 -> 9.0
2004-05-12 14:59:12 猛禽
正常啊
2004-05-12 14:59:23 闪电侠
不会是印反了吧
2004-05-12 14:59:24 猛禽
当年BCB就是从1跨到3的
2004-05-12 14:59:36 令狐虫
原来Borland对6、9比较感兴趣
2004-05-12 14:59:49 闪电侠
有可能，一定是6弄反了
2004-05-12 14:59:49 猛禽
令狐也有RPWT
2004-05-12 14:59:57 ccrun
哈哈。令狐这个大6毛。
2004-05-12 15:00:14 玉笛书生
人家令狐又没有被抓到公安局。
2004-05-12 15:00:51 ccrun
汗。。。
2004-05-12 15:01:18 令狐虫
好了不开玩笑了，基本上是写反了。
我现在好像对Borland没有以前那种激情了，都不会想去试用新的版本。等BCBX2出来可能会去看一眼吧。
2004-05-12 15:01:22 ccrun
那个BCB9好象是真的？
http://homepages.borland.com/aohlsson/blog_beta/archive/2004_05_09_archive#108429619147508564
2004-05-12 15:01:46 猛禽
总觉得像愚人节
2004-05-12 15:02:16 ccrun
郁闷啊。
2004-05-12 15:10:49 令狐虫
我还是没看出哪儿有BCB9的消息 [:~]
2004-05-12 15:13:26 猎手
BCB9？？那7和８呢
2004-05-12 15:34:32 猛禽
上NG去看BCB9
2004-05-12 15:34:42 令狐虫
哪儿？
2004-05-12 15:42:41 令狐虫
我只看到了有人问BCB7的，BCB9好像还是太超前了吧
2004-05-12 15:43:23 猎手
BCBXXII
2004-05-12 15:43:46 猛禽
有啊，BCB7上面两个贴就是BCB9的
2004-05-12 16:07:19 猛禽
> AFAIK, it isn’t a joke.
> There will be a new version of BCB released,
> it will be version 9. Its release will coincide with
> the release of Delphi 9. This much can be assumed
> from the posts of Robert E and Anders O.
AFAIK, today:
* is my birthday
* I’v heared great news about BCB9
… and that’s enough reson for a beer.
Cheers!
2004-05-12 16:07:23 猛禽
看这个
2004-05-12 16:08:53 猎手
BCB9的图片有吗？
2004-05-12 16:09:04 猛禽
还在计划中呢
2004-05-12 16:09:14 猛禽
据说是要在D9发表之后发表
2004-05-12 16:09:28 猛禽
D9还不知道什么时候出呢
2004-05-12 16:10:04 令狐虫
估计Borland的人也发现了BCBX比较不爽了，想拉住现有的BCB用户
2004-05-12 16:10:30 猛禽
按李维的说法，今年会出一个D8。1
2004-05-12 16:10:38 猛禽
D9还遥遥无期呢
2004-05-12 16:10:53 猎手
D9不会哎
2004-05-12 16:10:58 猛禽
理想情况下也要到明年
2004-05-12 16:16:37 令狐虫
是啊。其实我觉得BCBX的创意是很好的，不过这个BCBX1.0还是很失败的
2004-05-12 16:17:06 令狐虫
不知道会不会变成第二个Kylix
2004-05-12 16:18:23 猎手
不会～～～
2004-05-12 16:19:02 猛禽
难说
2004-05-12 16:19:03 令狐虫
何以见得？
2004-05-12 16:19:19 猛禽
KYLIX是很令人伤心的一件事
2004-05-12 16:19:37 令狐虫
现在BCB9的计划都有了，却看不到BCBX2的计划，很难说没有这种可能性啊
2004-05-12 16:19:55 令狐虫
Kylix……，哎。
2004-05-12 16:19:55 猎手
要相应Borland
2004-05-12 16:20:02 猎手
是相信
2004-05-12 16:20:18 猛禽
BCBX1受的打击太大了：）
2004-05-12 16:20:26 猎手
再不成就去努力询找非程序员工作。
2004-05-12 16:20:26 猛禽
其中包括偶给它的打击：）
2004-05-12 16:20:35 闪电侠
越大越好
2004-05-12 16:20:45 猛禽
打S它就有BCB9了？
2004-05-12 16:20:51 猛禽
这样未必更好
2004-05-12 16:21:10 猛禽
不过我觉得BORLAND现在恐怕有困难
2004-05-12 16:21:17 猛禽
没法完全实现BCBX的设想
2004-05-12 16:21:30 猛禽
否则BCBX还是一个很不错的东东
2004-05-12 16:21:33 令狐虫
其实BCBX最终流产的话，也未必不是好事，就像Kylix一样，虽然终结了，可是它的很多技术应用到了新版的BCB和Delphi里。
2004-05-12 16:21:57 猛禽
也是
2004-05-12 16:22:14 猛禽
难说BCB9不会是BCBX2的改头换面版：）
2004-05-12 16:23:31 令狐虫
其实对一个公司来说，及时终结一个不成功的产品不是坏事。抱着不放才是糟糕的选择。偶尔的弄个试验品试验一下新技术也不错。就是失败的产品会对公司声誉产生一定的影响
2004-05-12 16:23:36 令狐虫
是啊
2004-05-12 16:24:12 令狐虫
我在想要是当初BCBX开发了，但是没发布，可能结果比现在还好些
2004-05-12 16:24:31 猛禽
但是不发布，不可能知道结果会怎么样
2004-05-12 16:24:59 猛禽
不过我倒觉得BORLAND不应该急着把它作为一个正式的产品线发布
2004-05-12 16:25:10 猛禽
可以作为一种试验品发布
2004-05-12 16:25:21 猛禽
面子上好过一些
2004-05-12 16:25:42 猛禽
拿出来当产品，实际上赚不到几个钱，对声誉的损害太大
2004-05-12 16:26:15 猛禽
不过大概是因为Borland花了不少钱搞这个，总是希望能捞回成本吧：）
2004-05-12 16:27:02 令狐虫
Borland好像过一段时间就会头脑发昏一次 [:D]
2004-05-12 16:27:33 闪电侠
然后人就得走两个
2004-05-12 16:33:32 猛禽
我还以为Dale Fuller一向头脑清醒
2004-05-12 16:33:53 猛禽
看来最近是得了老年痴呆了[:D]
2004-05-12 16:34:31 令狐虫
不知道C# Builder现在卖得怎么样了
2004-05-12 16:35:12 猛禽
反应平平
2004-05-12 16:35:16 猛禽
BUG太多
2004-05-12 16:35:34 猛禽
何况现在自己出了D8，又吃掉一部分市场
2004-05-12 16:35:45 猛禽
我对C#B也没什么好感
2004-05-12 16:35:47 令狐虫
看来又是一个创意优秀，实现糟糕的作品
2004-05-12 16:36:02 猛禽
BORLAND完全没有必要在C#领域路MS打
2004-05-12 16:36:13 猛禽
做C#B完全是浪费资源
2004-05-12 16:36:23 猛禽
不如集中精力把D8做好
2004-05-12 16:36:48 闪电侠
D8模仿vs.net
2004-05-12 16:37:02 猛禽
今年内的MS DEV DAY上，BORLAND去那卖Together for vs.net
2004-05-12 16:37:21 猛禽
D8跟VS.net比起来越来越没有优势了
2004-05-12 16:37:42 令狐虫
不能这么说，其实现在的.NET没有好的企业级开发框架，如果Borland能像当年做JB一样，充分参与到.net企业级框架开发中去得话，呵呵，前途无限啊。不过最关键是MS不像sun那么好对付
2004-05-12 16:37:49 闪电侠
长得一样，控件也一样
2004-05-12 16:38:02 猛禽
正如我那时在BLOG上说的，以后大概就靠给MS搭配卖together混饭吃了
2004-05-12 16:38:18 闪电侠
使用方法也一样，和以前的CB6一点也不象了
2004-05-12 16:38:22 猛禽
问题是BORLAND也没有
2004-05-12 16:38:53 令狐虫
是没有，当时它做JB的时候比现在还艰苦，现在至少还有JB的经验和Together了
2004-05-12 16:38:55 猛禽
JB的情况又怎么样，BES搞得不行，只能靠BEA和IBM过日子
2004-05-12 16:39:15 猛禽
现在有ECLIPS，JB的日子也不好过
2004-05-12 16:39:52 猛禽
最大的问题还是利益
2004-05-12 16:40:09 猛禽
BORLAND的MIDAS是基于MS的COM的
2004-05-12 16:40:27 猛禽
现在的问题是MS的COM不行，但它绝不可能支持CORBA
2004-05-12 16:40:43 猛禽
除非BORLAND自己搞一个CORBA.net
2004-05-12 16:41:02 猛禽
但实现的可能性也不是太大
2004-05-12 16:41:48 猛禽
好好的一个visiBroker到了Borland手里，落到现在这步田地，真是可惜了
2004-05-12 16:41:52 令狐虫
现在的Borland似乎又到了“发昏周期”了。现在的产品线有些目的不明。
2004-05-12 16:42:23 猛禽
这次发昏比起当年philip.Kann在BC4时发昏还要严重
2004-05-12 16:42:37 猛禽
而现在外部情况也比那时要严重
2004-05-12 16:43:19 猛禽
MS能有今天，很大程度上它是一直持续在发展，而BORLAND却总是在颠簸
2004-05-12 16:43:33 猛禽
否则绝不致于到今天这个地步
2004-05-12 16:44:42 令狐虫
本来其实很简单的，想办法做一套.net的企业级框架出来，或者充分发挥Javenet的优势，把Java的企业级优势和.net结合起来，在本地代码部分升级BCB，BCBX为C++的跨平台开放和企业级开发做好准备，Delphi维持现有的VCL，结合CLX做一个跨平台、甚至跨本地和.net的开发工具。Borland的日子就会很好过了
2004-05-12 16:45:16 ccrun
.net不是那么好做地。
2004-05-12 16:45:17 令狐虫
同意，Borland的道路确实太坎坷了
2004-05-12 16:45:49 猛禽
MS不会愿意BORLAND在.net上坐大的
2004-05-12 16:45:52 ccrun
偏偏我还是喜欢这可怜的孩。
2004-05-12 16:46:02 猛禽
这一点决定了这个只能是设想
2004-05-12 16:46:30 令狐虫
其实Borland当时有那么多高手，包括像Anders这样的顶尖高手，如果不是管理层的问题，Borland早就变成超一流的开发工具供应商了
2004-05-12 16:46:43 猛禽
否则Borland如果真的能认真做好.net和JAVA的集成，这会是一个非常有前景的东东
2004-05-12 16:46:43 ccrun
官僚主义害死人。
2004-05-12 16:46:51 令狐虫
现在倒好，Borland变成培训基地了
2004-05-12 16:46:59 猛禽
呵呵，是啊
2004-05-12 16:47:09 猛禽
专门为MS培养高手
2004-05-12 16:47:12 令狐虫
为微软培训了多少人才啊 [:D]
2004-05-12 16:47:14 闪电侠
培训基地 呵呵
2004-05-12 16:47:36 令狐虫
本来.net根本轮不到微软的
2004-05-12 16:47:50 猛禽
Borland可以改名了：Microsoft University
2004-05-12 16:48:03 令狐虫
在Delphi3的时候Anders就有很多如今.net的想法了
2004-05-12 16:48:13 令狐虫
好多年前啊……
2004-05-12 16:48:19 猎手
Borland是兵工厂
2004-05-12 16:48:26 猛禽
呵呵，不过话说回来，那时的BORLAND没有条件让ANDERS实现
2004-05-12 16:48:40 令狐虫
MS那里有召唤巫师
2004-05-12 16:49:05 猛禽
倒是比较可惜的是当年BC时代的错误
2004-05-12 16:49:12 令狐虫
那倒是，不过如果能留住Anders，迟早会实现的
2004-05-12 16:49:21 猛禽
不然BCB可能就比DELPHI还要早诞生了
2004-05-12 16:49:26 令狐虫
是啊
2004-05-12 16:49:43 令狐虫
BC4……，Borland永远的痛，呵呵
2004-05-12 16:49:47 猛禽
问题是如果BORLAND不断起伏的话，ANDERS永远等不到那天
2004-05-12 16:49:56 猛禽
那又如何留得住他呢？
2004-05-12 16:50:22 猛禽
光这一个BC4，就足以让我们痛恨KANN
2004-05-12 16:50:29 猛禽
虽然是他创建了BORLAND
2004-05-12 16:51:14 令狐虫
是啊是啊
2004-05-12 16:56:26 令狐虫
其实微软犯的错误也不少，当初对网络发展的错误估计、臭名昭著的MSC7等等，不过操作系统的优势让它有足够的时间反扑。而它一旦反扑过来，威力是相当大的
2004-05-12 16:57:51 令狐虫
对了，还有那个典型的 640k 笑话，那使得多少DOS程序员倍受折磨啊
2004-05-12 16:57:59 猛禽
呵呵
2004-05-12 16:58:21 猛禽
但是对它来说，这些问题都不足以致命
2004-05-12 16:58:45 猛禽
而BORLAND就不同，开发工具是命脉所在
2004-05-12 16:59:03 令狐虫
是啊，其实这些问题都不是小问题，可是摆在MS这里就不算致命伤。MS太强大了
2004-05-12 16:59:38 猛禽
如果在DOS时代，APPLE把MACOS移植到PC上，MS早就不知道S几回了
2004-05-12 16:59:53 猛禽
DOS时代MS也谈不上强大
2004-05-12 17:00:14 猛禽
但在PC OS领域，没有足够强大的竞争对手
2004-05-12 17:00:15 令狐虫
就是，还有那个OS/2，IBM如果对PC市场关注多那么一点点的话……
2004-05-12 17:00:32 猛禽
OS/2应该说是IBM被MS摆了一道
2004-05-12 17:01:01 令狐虫
呵呵，不过跟IBM不重视PC市场也有关系
2004-05-12 17:01:03 猛禽
MS以合作为名，与IBM共同开发OS/2
2004-05-12 17:01:30 猛禽
把IBM在大型机方面的OS经验搞到后回头搞了WINNT
2004-05-12 17:01:40 猛禽
IBM一向如此
2004-05-12 17:01:52 猛禽
仗着自己大，不把别人放在眼里
2004-05-12 17:02:01 令狐虫
是啊，所以说。
2004-05-12 17:02:02 猛禽
到后面就搞不定了
2004-05-12 17:02:07 猛禽
MS就不同
2004-05-12 17:02:39 猛禽
它一向喜欢把别人扼杀在摇篮里
2004-05-12 17:02:44 猛禽
比如Netscape
2004-05-12 17:03:05 玉笛书生
还是MS比较心狠手辣。
2004-05-12 17:03:06 猛禽
大概也怕有人学它这样上来吧
2004-05-12 17:03:08 猛禽
是啊
2004-05-12 17:03:10 令狐虫
Netscape那时不算摇篮了，那个主要是MS优势太明显了
2004-05-12 17:03:16 猛禽
这个世界就是这样
2004-05-12 17:03:31 令狐虫
免费赠送，谁受得了啊
2004-05-12 17:03:38 猛禽
NETSCAPE让它长这么大，也是因为BILL的计算错误
2004-05-12 17:03:56 令狐虫
这就是我说的对网络发展的错误估计
2004-05-12 17:04:03 猛禽
何况它对于MS来说，还只能算是幼儿
2004-05-12 17:04:14 猛禽
刚下摇篮
2004-05-12 17:04:19 猛禽
是啊
2004-05-12 17:04:28 猛禽
否则肯定也是S在摇篮里的
2004-05-12 17:04:32 令狐虫
当初微软对网络真是一点动静也没有，算是名副其实的后来居上
2004-05-12 17:05:09 猛禽
这一点一定要向MS学习
2004-05-12 17:05:14 令狐虫
跟微软作对真的没什么好结果，Borland一路坎坷走到现在，也算很了不起了已经
2004-05-12 17:05:28 猛禽
只要有机会，一定要置竞争对手于S地
2004-05-12 17:06:00 猛禽
只是如果BORLAND不是总犯这些严重的错误的话，它的今天会更好的
2004-05-12 17:06:18 闪电侠
那么SUN会怎么样
2004-05-12 17:06:22 令狐虫
像Oracle、IBM这样的公司，当初不知道比MS大多少倍，可是现在，谁也不敢小瞧MS了
2004-05-12 17:06:26 令狐虫
sun，呵呵
2004-05-12 17:06:43 猛禽
是啊
2004-05-12 17:06:44 闪电侠
又要竞争了。 java .net
2004-05-12 17:06:45 令狐虫
虽然我对Java感觉不错，但是对sun则感觉不太好
2004-05-12 17:06:53 猛禽
呵呵，一样
2004-05-12 17:07:04 令狐虫
它的能力简直……
2004-05-12 17:07:06 猛禽
SUN其实跟MS一样恶心
2004-05-12 17:07:17 猛禽
甚至更恶心
2004-05-12 17:07:34 令狐虫
Java的发展其实sun的贡献并不太大，倒是Borland、IBM和BEA的贡献更大
2004-05-12 17:07:36 猛禽
不过还好JAVA比.net开放那么一点点
2004
-05-12 17:08:17 令狐虫
sun的恶心之处就是别人弄一点东西出来，它就以标准化为名据为己有，J2EE就是这么来的。
2004-05-12 17:08:42 令狐虫
我印象最深的就是J2EE对WebService的支持了
2004-05-12 17:09:05 猛禽
呵呵，最近的JDO2.0和EJB3.0好像也有这么个意思
2004-05-12 17:09:12 闪电侠
sun 能不能会走到borland 这一步
2004-05-12 17:09:23 猛禽
不会
2004-05-12 17:09:38 猛禽
只要它抓着JAVA的标准制定权不放
2004-05-12 17:09:50 猛禽
不过现在的情况也很微妙
2004-05-12 17:10:06 令狐虫
当初是IBM先推出的支持WebService的接口，然后BEA加入。最后sun一看，搞清楚了别人怎么做的，然后推出J2EE的新版，号称支持WebService，还跟上面两家的接口有那么点点区别
2004-05-12 17:10:16 猛禽
因为现在JAVA发展的实际方向控制在IBM/BEA和OpenSource手中
2004-05-12 17:10:24 令狐虫
是啊
2004-05-12 17:10:42 猛禽
所以IBM一直要求SUN放开对JAVA的控制
2004-05-12 17:10:52 猛禽
不过我也不太希望这样
2004-05-12 17:11:00 猛禽
因为这样的结果不过是从SUN转到IBM
2004-05-12 17:11:08 猛禽
没有本质的区别
2004-05-12 17:11:26 令狐虫
优化JVM是borland最早做的，J2EE标准是IBM最先提出的，现在的很多框架是OpenSource社团搞的，sun似乎什么贡献也没有。
2004-05-12 17:11:30 猛禽
在JAVA的开源领域，IBM有最大的影响力
2004-05-12 17:11:57 猛禽
这就决定了IBM现在对ＪＡＶＡ有最大的实际控制权
2004-05-12 17:16:28 令狐虫
接着说Java，其实Java开放也有点好处，真正开放了之后事实上就是谁都对它没有控制权了。就像Ecllipse，现在控制权也不在IBM手上。
2004-05-12 17:21:55 猛禽
但是IBM对Eclipse有最大的影响力
2004-05-12 17:22:06 猛禽
毕竟Eclipse是出自IBM的
2004-05-12 17:22:43 猛禽
而且按GIGIX的说法是IBM里可能有一帮子人参与Eclipse的开发工作
2004-05-12 17:23:15 令狐虫
对，IBM里有一帮人是专门做OpenSource的，不仅仅是Ecllipse
2004-05-12 17:23:37 令狐虫
这帮人可真幸福，拿IBM的钱，不用为IBM做事 [:D]
2004-05-12 17:25:21 猛禽
没办法，谁让IBM钱多呢
2004-05-12 17:26:15 猛禽
所以说，现在很多MS的拥趸用于打击开源的理由就是：OpenSource其实是为IBM服务的
传说中的BCB9
今天在Borland新闻组，有人说Borland计划与Delphi9同时推出BCB9，不过现在还未能最终证实，不知道是不是真的。
见：http://homepages.borland.com/aohlsson/blog_beta
及Borland新闻组：newsgroups.borland.com中的borland.public.cppbuilder.non-techical
八号当铺
昨天在MOP上看到一个贴子：《如果世界上真的有八号当铺》，有些回贴真的很感人。
你会当什么，又想换回什么？
沿着一张地图，你会找到鬼魅的第八号当铺，这里可以实现你的所有欲望，只要你肯典当金银珠宝、地契、楼契，哪怕是你的四肢、内脏，还是运气、智力、理智、快乐、幸福、爱情，甚至价值昂贵的灵魂……
如果你能典当自己,那你会要换取甚么? 财富? 爱你的人? 世界闻名天才钢琴家? 还是永世不衰的容貌?
所谓当铺，要的是用有价值的东西来换取价值更少的东西，这才是当铺的本质。二者的价值差便是当铺的利润来源。即便是八号当铺，大抵也是如此。
然而对价值的评估，不同的人有不同的结果。
选择得到，同时也是选择失去，我们努力想让生活变得更好，然而常常却发现得不偿失。
何况，我们真的有什么东西可以当的吗？
站在八号当铺门口，我发现自己一无所有。
白云苍狗
一个圈内的高人前几天闪电结婚了，许多认识不认识的家伙都去他的BLOG上恭喜他，一片喜气洋洋。
今天去他的BLOG看时，他已经完婚回来了，意外的是发现他的太太居然不是以前大家所知道的他的那个GF（现在应该叫前GF了）。从BLOG上的留言来看，有很多人跟我一样觉得意外。因为就在几个月前，他们还合译出版了一本书，在书的译序里，还有：谢谢你，亲爱的SS（他前GF的名字）。云云。当然也有一些他的朋友（偶可不是，偶认识他，他不认识偶:P）大概是知道内情的留言说：“结婚和恋爱不是一回事的”
也许世界上的事就是这样，我们永远不可能知道明天会怎么样。这样的事又何止爱情？
一个MSN上的朋友今天的ID是：
昨天已成为历史，明天则遥不可知，唯有今天是一个礼物。所以英文把“现在”称作Present，请珍惜这份礼物。
我把这句话送给那位高人，也送给大家。