Technology
软件的分类
Apr 30th
什么叫应用软件？什么叫系统软件？什么叫客户端软件？
最近被IT行业的“软件”一词搞得有点混，亏得我还是一个计算机专业的学生,还满脑子地想去做开发。。。现在我才明白，我想做的那个玩意儿，应该叫 “应用软件”。先特此收集，答案来自网上
软件（英语：Software）是 一系列按照特定顺序组织的计算机数据和指令的集合。一般来讲软件被划分为函数编程语言、系统软件、应用软件和介于这两者之间的中间件。其中系统软件为计算机使用提供最基本的功能，但是并不针对某一特定 应用领域。而应用软件则恰好相反，不同的应用软件根据用户和所服务的领域提供不同的功能。
软件并不只是包括可以在计算机上运行的计算机程序，与这些计算机程序相关的文档，一般也被认为是软件的一部 分。简单的说软件就是程序加文档的集合体。软件被应用于世界的各个领域，对人们的生活和工作都产生了深远的影响。
软件是计算机的灵魂，没有软件的计算机就如同没有磁带的录音机和没有录像带的录像机一样，与废铁没什么差别。使用不同的计算机软件，计算机可以完成许许多多不同的工作。它使计算机具有非凡的灵活性和通用性。也正是这一原因，决定了计算机的任何动作都离不开由人安排的指令。人们针对某一需要而为计算机编制的指令序列称为程序。程序连同有关的说明资料称为软件。配上软件的计算机才成为完整的计算机系统。
一般把软件分为两大类：应用软件和系统软件。
Read the rest of this entry »
Eclipse启动参数大全
Mar 20th
http://www.cn-java.com/www1/bbs/viewthread.php?tid=14813
Eclipse 运行命令行参数大全
包括英文版本和中文版本两种的说明, 特别需要值得一提的是那个 -nl 参数, 可以指定程序启动时所使用的语言. 例如:
eclipse -nl en_US
将启动英文语言, 这个特性在安装了国际化语言包以后特别有用, 可以方便的切换各个语言的版本. 注意 IBM WSAD v5.1 也支持这个功能.
运行 Eclipse
将 Eclipse 驱动程序安装（解压缩）到某个目录（例如，c:\eclipse）中之后，通过运行顶级安装目录中的 Eclipse 可执行文件来启动”工作台”。在 Windows 系统上，该可执行文件称为 eclipse.exe，而在 Linux 系统上称为 eclipse。注意：下列讨论描述 Windows 系统上的设置。Linux 上的设置是相似的。
如果您没有另行指定，则平台将缺省工作区目录创建为可执行文件的兄弟目录（例如 c:\eclipse\workspace）。此工作区目录用作项目的缺省内容区，还用于保存任何必需的元数据。要进行共享安装或多工作区安装，应明确指出工作区的位置而不是使用缺省值。有两种控制工作区位置的方法：使用当前工作目录或使用 -data 命令行自变量。
将工作区位置设置为在当前工作目录内
在此方案中，工作区位置将是当前工作目录中称为 workspace 的目录。
实现此目的最容易的方法可能是使用下列步骤来创建快捷方式：
导航到 Windows 资源管理器中的 eclipse.exe 并使用右键拖动来创建 eclipse.exe 的快捷方式。
编辑快捷方式的属性，以使启动位置：字段标识工作区位置的父目录（例如，c:\users\robert）。
关闭属性对话框并双击快捷方式（如果提供的目录为 c:\users\robert，则工作区位置将为 c:\users\robert\workspace）。
当然，您也可以使用命令提示符（通过将目录切换为工作区父目录然后运行 eclipse.exe）来获得同样的效果。
使用 -data 设置工作区的特定位置
要使用 -data 命令行自变量，只要将 -data your_workspace_location（例如，-data c:\users\robert\myworkspace）添加至快捷方式属性中的目标字段或显式地将它包括在命令行上。
使用 -vm 设置 java VM
建议显式指定在运行 Eclipse 时要使用哪个 Java VM。使用 -vm 命令行自变量（例如，-vm c:\jre\bin\javaw.exe）可以实现此目的。如果不使用 -vm，则 Eclipse 将使用在 O/S 路径上找到的一个 Java VM。当安装其它产品时，它们可更改您的路径，导致在下一次启动 Eclipse 时使用另一 Java VM。
Read the rest of this entry »
IE9最终准备加入HTML5行列
Mar 17th
For the past few years it seems like Microsoft’s Internet Explorer has let web standards and competing browsers pass it by. Internet users with even a hint of technical-savvy were more likely to have tried, and preferred, an alternative to IE. It wouldn’t be a such an issue if Microsoft didn’t have over 50% of the world’s browser market share. This fact has given web developers countless headaches when they face browser compatibility issues working with new web standards like SVG, CSS3, and HTML5. But the dawn is finally coming for IE users and web developers that have been putting up with Microsoft’s browsing dark ages. At the MIX 10 conference today, Microsoft announced the release of a IE9 developer preview. Microsoft’s new browser will add support for the latest web technologies including SVG and HTML5. The company also announced that they would become a committer for the jQuery project.
The current software is just a framework right now, and it’s in such an early stage that it doesn’t even have a back button yet, but more preview versions will arrive in eight week intervals. The preview of IE9 showcases new support for SVG 1.1 imagery inline, CSS3, and of course HTML5. It also has an Acid3 score of 55 currently and its CSS3 Selectors all pass the Selector test. Microsoft also showed its commitment to developing industry standard test suites by submitting over 100 additional HTML5, CSS3, DOM, and SVG tests to the W3C.
Following in the footsteps of Chrome’s V8, Opera’s Carakan, and Firefox’s SpiderMonkey, IE9 has a creatively-named JavaScript powerhouse of its own. The “Chakra” JS engine in the IE9 developer preview was tested against against competitors using the WebKit SunSpider JavaScript benchmark (see results below). I’m sure we’ll see some benchmarks from other sources very soon.
Mozilla borrows from WebKit to build fast new JS engine
Mar 10th
Mozilla’s high-performance TraceMonkey JavaScript engine, which was first introduced in 2008, has lost a lot of its luster as competing browser vendors have stepped up their game to deliver superior performance. Firefox now lags behind Safari, Chrome, and Opera in common JavaScript benchmarks. In an effort to bring Firefox back to the front of the pack, Mozilla is building a new JavaScript engine called JägerMonkey.
The secret sauce that will drive Mozilla’s new JavaScript engine engine into the fast lane is some code borrowed from Apple’s WebKit project. Mozilla intends to bring together the powerful optimization techniques of TraceMonkey and the extremely efficient native code generator of Apple’s JSCore engine. The mashup will likely deliver a significant boost in Firefox’s JavaScript execution speed, making Mozilla’s browser a formidable contender in the ongoing JavaScript speed race.
Mozilla’s current JavaScript engine uses nanojit as its native code generator. Adobe originally developed nanojit to power Flash’s ActionScript execution and released it under an open source software license in 2006. Mozilla and Adobe were going to use nanojit to build an ECMAScript 4 implementation called Tamarin, but the project was largely abandoned when ECMAScript 4 was shelved. Mozilla integrated nanojit into its existing SpiderMonkey engine and added tracing optimization to build TraceMonkey.
Mozilla’s new JägerMonkey engine will continue to use nanojit for some things, but will rely on Apple’s Nitro Assembler to generate efficient native code. This will allow JägerMonkey to benefit from the performance advantages of method-based just-in-time (JIT) compilation. JägerMonkey will also use tracing optimization to flatten out loops and speed up other kinds of execution paths that can benefit from further optimization. Mozilla says that this blend of technologies potentially offers the best of all worlds.
“The reason we’re [building JägerMonkey] is that TraceMonkey is very fast for code that traces well, but for code that doesn’t trace, we’re stuck with the interpreter, which is not fast. The JägerMonkey method JIT will provide a much better performance baseline, and tracing will continue to speed us up on code where it applies,” wrote developer David Mandelin a blog entry about the new engine.
The project is said to be at a relatively early stage of development and is not yet ready to be broadly demonstrated. Developers who want to have a look at the code can download it from Mozilla’s version control repository. The current development status is described in a page at the Mozilla wiki.
Further reading
- Mozilla Hacks (1) (hacks.mozilla.org)
- Mozilla Hacks (2) (hacks.mozilla.org)
Windows 目录到底占用了多少真实的硬盘空间
Feb 2nd
新闻来源:CCF
原文是 张康宗（Smallfrogs）写的，原文地址,个人觉得很不错，特地转载。
原本这个话题是准备在8个月前写的，但是由于种种原因，一直推迟到现在。今晚（或者说今天凌晨），抽空把程序弄完了，因为只有程序写完以后，这个话题才有 实际的价值。
这个话题就是：Windows 目录到底占用了多少真实的硬盘空间？
看到这个问题，我想99%的人都会说：用资源管理器右键点击Windows目录，看看属性不就知道了吗？何必故弄玄虚呢！
但是，我 Smallfrogs 会有那么傻的把一个大家都知道的问题重新翻出来吗？既然提出了这个话题，就有我的道理！请各位耐住性子往下看，看看我们的Microsoft同学又玩了什 么样的花活，呵呵。
我们知道，查看一个目录有多大的最快捷的方法就是看看资源管理器文件夹的属性，但是我今天要说的是：如果你用这个方法去看 Windows Vista / Windows 7 系统的目录，你会被你的眼睛所欺骗，因为，Microsoft 同学在 Windows Vista/ Windows 7 里面大量使用了NTFS文件系统的特性之一的：硬连接（Hard Link）来实现WinSxS机制！
关于 WinSxS，可以看我之前写的 《WinSxS 混乱导致的应用程序不能启动》一文。
我们知道，要安装 Windows Vista / Windows 7系统，那么系统分区必须是NTFS文件系统。原因有以下一些：
- 系统文件保护所需
- 各种安全保护机制，如MIC所需
- WinSxS 所需
- ……
关于最后一点的 WinSxS 所需，我没有看到过相关的资料说明，不过可以肯定的是，这也是Windows Vista / Windows 7 系统需要NTFS文件系统的一个条件，因为只有在 NTFS 文件系统上面，才能实现硬连接机制，也才能达到优化Windows目录占用磁盘空间的目的。 关于硬连接，MSDN是这样解释的： A hard link is the file system representation of a file by which more than one path references a single file in the same volume. To create a hard link, use the CreateHardLink function. Any changes to that file are instantly visible to applications that access it through the hard links that reference it. However, the directory entry size and attribute information is updated only for the link through which the change was made. 简单的说，就是一种针对文件的特殊快捷方式，只不过这种快捷方式的实现和一般的快捷方式不一样。
- 一般的快捷方式是创建一个LNK文件，在这个LNK文件里面描述了目标文件/目录的属性，资源管理器或者其他文件管理工具利用 SHELL32.DLL里面的API函数获得这个LNK文件所指向的文件/目录，从而进行访问。
- 硬连接：是一种基于文件系统级别上的针对文件的快捷方式，基于文件系统级别的含义就是说，只要文件系统启动了，那么对应的快捷方式也就生 效了。换句话说，这种连接是常存的，因为文件系统是必须要随机启动的。硬连接是NTFS文件系统特有的属性之一，在Linux下面，也有类似的机制。硬连接适用于在同一个卷的文件级别，硬连接是不能跨卷的。
Windows Vista / Windows 7 自带了创建硬连接的命令：mklink.exe，利用这个命令，我们可以给指定的文件创建硬连接： 下面的命令将在link.txt和source.txt之间建立硬连接关系 C:UsersSmallfrogsDesktop>mklink /h link.txt source.txt 为 link.txt <<===>> source.txt 创建了硬链接 注 意上面的例子：link.txt本是一个不存在的文件，但是当执行完mklink命令以后，link.txt文件也就被创建了。其实，link.txt是 一个虚假的文件，它是在文件系统层面上对source.txt文件的一个映射，而link.txt是不占硬盘空间的。 关于硬盘空间的占用问题，Smallfrogs 是这样测试的： 1、给硬盘划分一个新分区，空间只有2GB 2、在这个分区的test目录里面新建了一个1.9GB大小的文件，此时剩余空间是0.1GB 3、用mklink命令给这个1.9GB大小的文件建立了一个硬连接 4、检查这个分区的剩余空间，还是0.1GB，但是如果用资源管理器看test目录的属性，会发现有2个文件，总大小是3.8GB（整个分区才2GB，能 够容纳3.8GB大小的文件吗？显然不可能了） 还是针对上述的例子，如果我们把原始的文件 source.txt 删除以后，link.txt文件还是会继续存在的，且内容就是source.txt的文件内容。也就是说，我们删除source.txt，实际上删除的仅 仅是这种连接关系，文件本身还是没有被操作的。 关 于硬连接，最后一个需要介绍的内容是：当硬连接建立以后，硬连接双方任何一个对象被修改，都会造成对应的连接对象被修改。例如上面的例子：如果修改了 link.txt，那么source.txt文件也会同步被修改，反之亦然。这一点和SHELL层面的快捷方式不同，SHELL层面的快捷方式文件LNK 仅仅是一个指示关系，修改LNK文件并不影响LNK文件指向的对象，修改LNK文件指向的对象也不会影响LNK文件。 好了，基本知识介绍完了，我们来实际看看Windows目录里面对于硬连接的使用情况吧。 经常看到有人抱怨，WindowsWinSxS目录占用了太多的空间，里面经常发现有同名的文件，而且这些同名的文件在 WindowsSystem32 目录下面也有存在，这是为啥呢？其实这就是硬连接导致的。 Microsoft 实际上在 WindowsWinSxS 目录和Windows目录之间建立了硬连接的关系，举一个最简单的例子： 对于 Windows 7 RTM 来说，你可以在2个地方找到Ntoskrnl.exe文件。第一个地方是：WindowsSystem32ntoskrnl.exe，另外还有一个地 方是WindowsWinSxSx86_microsoft-windows-os- kernel_31bf3856ad364e35_6.1.7600.16385_none_6c06b7c41576a7d9ntoskrnl.exe， 这就是一个典型的硬连接例子。Microsoft 在文件系统上面对 ntoskrnl.exe 做了一个硬连接，使得 ntoskrnl.exe 能够出现在不同的目录里面，但是只占用了一份 ntoskrnl.exe 的硬盘空间。利用这种机制，有下面的一些好处：
- 同样的文件，只需要维护硬连接关系，不需要进行多重的拷贝，这样可以节省硬盘空间
- 如果涉及文件更新，只需要先在WinSxS 目录里面下载好一个新版本，然后修改 WindowsSystem32 下面同名文件的硬连接关系，从旧版本的硬连接指向新版本的硬连接，这样就能够快速的完成文件的更新工作，而不需要进行文件的复制，速度也会快不少
- 补丁卸载也是一样的，只需要把硬连接指向改为旧版本就可以了，没有文件替换的问题。而且建立了硬连接关系的文件之间的修改是同步的，因此 只要有一方被修改了，另一方也会得到修改