升级驱动程序是为了能让你的硬件更能充分地展现出它的工作性能,在升级硬件的情况下是比较浪费,只能在软件上升级来满足你所要求的最佳性能。在升级的条件下只要驱动匹配那就会多少提升硬件的性能。
本文介绍如何开发和测试 Windows CE 50 设备驱动程序。本文循序渐进地介绍如何创建流驱动程序,如何创建自定义 Windows CE Test Kit
(CETK) 测试,以及如何编写应用程序来测试驱动程序。这要花费大约 60 分钟来完成。
本页内容
第一部分:建立设备驱动程序
第二部分:测试流驱动程序测试代码
第三部分:检验驱动程序
第四部分:使用
Windows CE Test Kit
第五部分:创建自定义
CETK 测试
第六部分:确定谁拥有流驱动程序
小结
第一部分:建立设备驱动程序
在本练习中,您将使用 Platform Builder 来添加作为设备驱动程序的项目。
在 开始编写驱动程序之前,您应该了解设备驱动程序的用途。驱动程序将基础硬件从 *** 作系统中抽象出来,使之更好地面对应用程序开发人员。应用程序开发人员无需
知道显示硬件或串行硬件的详细信息 — 例如,串行设备是用 Universal Asynchronous Receiver/Transmitter (UART)
实现的还是用 field-programmable gate array (FPGA)
实现的。在大多数情况下,应用程序开发人员根本不需要知道硬件是如何实现的。
Microsoft Windows 为开发人员公开了调用硬件的应用程序编程接口
(API),他们不需要知道物理硬件的情况。例如,为了向串行端口写入数据,应用程序开发人员只需调用 COMx 上的 CreateFile( )(其中 x
表示您要打开的串行端口编号,例如 COM1 代表串行端口 1),再调用 WriteFile( ) 以将一些字节数据写入串行端口,然后调用
CloseHandle( ) 以关闭串行端口。不管基础串行硬件是什么(也不管您运行的是哪个 Windows *** 作系统),API 都会以同样的顺序执行。
相同的情况也适用于其他 API:如果您希望在显示表面画一条线,那么您只需调用 PolyLine( )、MoveToEx( ) 或 LineTo(
)。作为应用程序开发人员,大多数情况下您都不需要知道显示硬件的情况。此处调用的 API 将返回显示表面的维数、颜色深度等等。
好 消息是开发人员可以调用一个一致的、众所周知的 API 集。这些 API
将他们的应用程序从基础硬件中抽象出来。这至关重要,因为应用程序开发人员无法知道应用程序是运行在便携式计算机上,还是运行在 Tablet PC
上,抑或运行在桌面计算机上。无论电脑以 1024×768 还是 1600×1200
的分辨率运行,应用程序开发人员都可以在运行时查询屏幕分辨率和颜色深度,因此不需要构建只在特定硬件上运行的应用程序。
驱动程序只是一 个动态链接库(DLL)。将 DLL 加载到父进程地址空间;然后父进程就可以调用从该 DLL 公开的任何接口。通常,父进程通过调用
LoadLibrary( ) 或 LoadDriver( ) 来加载驱动程序。LoadDriver 不仅将 DLL 加载到父进程地址空间中,而且还要确保 DLL
没有“paged out”。
调用进程如何知道从您的 DLL 或驱动程序公开了哪些 API 或函数呢?父进程调用 GetProcAddress( ),后者可以获取函数名称和所加载的
DLL 的 hInstance。如果函数存在,调用返回该函数指针;如果没有从 DLL 公开该函数,则返回 NULL。
流驱动程序也公开了一个众所周知的函数集。对于流驱动程序,您会希望能够将字节流写入设备中,或者从设备中读取字节流。因此,在前面使用的串行端口示例中,您可能希望从您的驱动程序公开如下函数集:Open、Close、Read
和
Write。流驱动程序还公开一些其他函数:PowerUp、PowerDown、IOControl、Init
和 DeInit。
您可以将现有的 *** 作系统映像用于模拟器平台(Basic Lab MyPlatform 平台最理想)。然后,您就可以将
DLL/驱动程序项目添加到该平台了。
在构建并下载了该平台之后(这表明 *** 作系统启动并运行良好),您需要创建您的主干驱动程序。您可以使用 File 菜单上的 Platform
Builder New Project or File 命令创建一个 Microsoft Windows CE DLL。创建用于公开函数或资源的
DLL 与创建用作驱动程序的 DLL 之间没有什么不同;唯一的不同之处在于 DLL 公开哪些函数,以及如何在平台上注册或使用 DLL。
此 外,一种创建国际化应用程序的方法是,首先创建包含一组核心语言字符串、对话框和资源的基本应用程序,然后创建许多外部
DLL,其中每个都包含针对特定区域设置的对话框、字符串和资源。然后,应用程序就可以在运行时加载相应的语言资源。只需要添加 DLL
文件,您就可以将语言添加到应用程序中。在 Developing International
Software 一书中描述了与此相关的主题以及其他一些有趣的主题,可以在 Microsoft Press 网站上获得此书。
添加一个作为设备驱动程序的项目
用 Platform Builder 打开现有的 MyPlatform 工作区。
在 File 菜单上,单击 New Project or File。
选择 WCE Dynamic-Link Library,给它一个合适的名称(例如,StreamDrv),然后单击
OK,如下图所示。
在下图所显示的页面中多少填写一些您需要的信息,然后单击 Next。
单击 A simple Windows CE DLL project,如下图所示。
单击 Finish 完成此向导。
此时,DLL 只包含一个空的 DllMain
函数。您可以公开一些应用程序要调用的函数,并公开一些资源(可能使之成为识别语言/文化的应用程序的一部分),或者使之成为一个设备驱动程序。在本文中,您将使用
Windows CE Stream Driver Wizard 创建您的主干流驱动程序。
在 Windows CE 中,打开流驱动程序就像打开文件一样,只需根据唯一的三字母前缀(例如,COM)。
为您的驱动程序选择一个唯一的三字母标识符。在 Location
框中输入您之前创建的流驱动程序的完整路径。或者使用“browse”按钮定位到 Platform Builder 安装中的 PBWorkspaces
目录,找到您前面创建的平台,然后找到流驱动程序的名称(在前面的示例中,此路径为 PBWorkspaces\TuxPlat\StreamDrv)。
在 Driver Filename 框中输入驱动程序的名称。如下图所示,使用与您前面使用名称 (StreamDrv)
相同的名称,以确保改写在 Platform Builder 中创建的原始文件。
按 Go,将生成流驱动程序源代码。
返回页首
第二部分:测试流驱动程序测试代码
现在您已经编写了用于 Windows CE 的自定义流驱动程序的基本代码。此时,驱动程序还没有与任何硬件连接。
在 编写完驱动程序之后,您需要为开发人员提供一种测试它的方法。Windows CE 附带了 Windows CE Test Kit
(CETK),它提供了用于各种驱动程序类型的驱动程序测试,包含网络连接、蓝牙、串行端口以及显示。您编写的驱动程序是一种自定义的流驱动程序,它没有
公开与现有的驱动程序测试一样的功能,因此您需要为该驱动程序编写一个自定义测试。虽然您完全可以编写一个应用程序来演练驱动程序,但提供一个 CETK
模块或许更好些,在开发期间可以使用此模块,并且还可以将此模块提供给客户,供他们在装配硬件上测试驱动程序。
在这一部分的练习中,您将执行以下过程:
创建主干 Tux 模块
将自定义驱动程序的测试代码添加到 Tux DLL 中
重新构建 *** 作系统
设置断点
创建主干 Tux 模块
在 Platform Builder 中,在 File 菜单上单击 New Project or File。
选择 WCE TUX Dynamic-Link Library,键入 TuxTest 作为项目名称,输入一个位置,单击
Workspace Project,然后单击 OK,如下图所示。(实际上,您可以选择任意一个项目类型;对于本文,单击
Workspace Project)。
在下图显示的页面中多少填写一些您需要的信息,然后单击 Next。
阅读下图所显示的屏幕上的信息,然后单击 Next。
在最后一页上,您可以选择选取 Release Type 下的
CETK,如下图所示。该选项关闭了某些二进制的优化,以提高调试工作效率。单击 Finish。
单击 View | File View,然后展开 Projects 树显示 tux
源代码,如下图所示。
前图中需要注意的重要文件是:
fth — 该文件包含 tux DLL 所用的函数表。
testcpp — 该文件包含从该函数表中调用的测试过程。
TuxStreamTestcpp — 该文件包含 DLLMain 和 ShellProc,后者是从 Tuxexe
调用的。
将自定义驱动程序测试代码添加到 Tux DLL 中
打开源代码 Testcpp。
使用 CodeClip 来获得 Tux_Custom_Test | TuxCode 源代码。
用 CodeClip 中的代码替代函数 TestProc 中的内容。
您会注意到,Testcpp 中的代码加载了一个名为 Demodll 的驱动程序。对于本文,您创建了一个名为 StreamDrv
的驱动程序。您需要修改源代码以加载您的 StreamDrvdll 驱动程序。
找到 Testcpp 中调用 LoadLibrary 的源代码的位置,然后将要从 Demodll
中加载的驱动程序的名称修改为 StreamDrvdll。
在 Platform Builder 文件视图中,右键单击 TuxTest 项目,然后单击 Build Current
Project。
您还需要从该目录中添加 Windows CE Test Kit 组件。
在 Device Drivers 下,找到该目录中 Windows CE Test Kit 组件的位置,然后选择
Add the Windows CE Test Kit,将该组件添加到您的平台中。
注 将该组件添加到您的平台上并没有将任何文件添加到最后的 *** 作系统映像中;它将 Clientside 文件添加到 build release
文件夹中。您可以从 Platform Builder 下载 Clientside 应用程序,并在目标设备上运行该应用程序。
现在您需要重新构建您的 *** 作系统,以便合并这些变更。
重新构建 *** 作系统
在 Platform Builder 中,选择 Build OS | Sysgen。
构建过程将会花大约 5 分钟完成。
当加载驱动程序时,在流驱动程序的入口点设置一个断点来观察非常有用。
设置断点
单击 File View,打开 StreamDrv 项目,然后打开 Source files。
找到并打开 StreamDrvcpp。
找到 DllMain,然后找到并单击 switch 语句。
按 F9 设置断点。
单击 Target | Attach,将 *** 作系统下载到模拟环境中。
您会看到以下调试输出,断点将启用。注意,在加载 *** 作系统的用户接口 (UI) 之前,这早就发生了。
4294780036 PID:23f767b6 TID:23f767e6 0x83fa6800: >>> Loading module
streamdrvdll at address 0x01ED0000-0x01ED5000
Loaded symbols for
'C:\WINCE500\PBWORKSPACES\DRVDEMO\RELDIR\EMULATOR_X86_DEBUG\STREAMDRVDLL'
单击 switch 语句,然后按 F9 禁用断点。
按 F5,允许 *** 作系统继续加载。
现在,您已经构建了一个 Windows CE 50
*** 作系统,它包含一个自定义流驱动程序,并且您已经在 *** 作系统引导顺序的过程中看到了驱动程序加载。
返回页首
第三部分:检验驱动程序
在这一部分的练习中,您将执行以下过程:
使用命令行工具查看从驱动程序公开的函数
使用远程系统信息 (Remote System Information) 工具检验驱动程序
确定驱动程序已加载
检验您所创建的设备驱动程序的第一种方法是查看从该驱动程序公开的函数。Windows CE 附带了一个名为 Dumpbin
的命令行工具,可以用于检验导入应用程序或模块的内容,或者从 DLL(或驱动程序)导出的内容。
使用命令行工具查看从驱动程序公开的函数
在 Platform Builder 中,单击 Build OS | Open Release
Directory。该 *** 作为当前的工作区打开 build release 文件夹中的 Command Prompt 窗口。
键入 dumpbin exports StreamDrvdll
下图显示输出。您可以看到,所有需要的流驱动程序函数都是从驱动程序公开的;函数是从 DLL 公开的(通过该项目的 def 文件)。
键入 Exit 关闭 Command Prompt 窗口
StreamDrvdef 文件的内容如下所示。
LIBRARY DemoDriver
EXPORTS
DEM_Init
DEM_Deinit
DEM_Open
DEM_Close
DEM_IOControl
DEM_PowerUp
DEM_PowerDown
DEM_Read
DEM_Write
DEM_Seek
CustomFunction
CustomFunctionEx
您可以检验驱动程序的第二种方法是通过远程系统信息工具。
通过远程系统信息工具检验驱动程序
在 Platform Builder 中,单击 Tools | Remote System
Information。
选择 Windows CE Default Platform | Default Device,然后单击
OK,如下图所示。
此过程将远程系统信息应用程序连接到 Platform Builder 正在使用的当前活动平台上。下图显示了结果。
您也可以使用加载模块列表来确定已加载了您的驱动程序。
确定驱动程序已加载
在 Platform Builder 中,使用 Target Control 窗口 (gi mod) 或 View |
Debug Windows | Modules and Symbols。
下图显示了此过程的结果。
返回页首
第四部分:使用 Windows CE Test Kit
Windows CE Test Kit 包含设备端组件和桌面组件。设备端组件叫做 Clientsideexe,通过从目录中添加 CETK
组件,您可以将设备端组件添加到您的工作区中。注意,将 Clientsideexe
应用程序添加到工作区中并没有将任何文件添加到最终 *** 作系统映像中,但它却将应用程序复制到 build release 文件夹中。
在桌面计算机上运行 CETK 之前,您需要启动设备上的 Clientsideexe 应用程序。没有链接工具(比如远程工具)的原因在于,CETK
也将运行在装配(零售)设备(比如 Pocket PC)上。
在这一部分的练习中,您将执行以下过程:
检验 Windows CE Test Kit 用户接口
运行一个标准测试
检验 Windows CE Test Kit 用户接口
在 Platform Builder 中,在 Tools 菜单上单击 Windows CE Test
Kit。
这 一步启动 Windows CE Test Kit 应用程序,如下图所示。注意,这不是一个标准的远程工具。Windows CE
附带的大多数远程工具都使用 Kernel Independent Transport Layer
(KITL),一种将工具从基础通信硬件中抽象出来的传输,以便这些工具可以运行在以太网、串行端口、1394、USB 或者其他传输上。
虽然对于 Windows CE 50,Windows CE Test Kit 通常通过套接字连接,但是也已经更新了工具来支持 KITL。
在 Windows CE Test Kit 中,单击 Connection | Start
Client。
这一步显示 Device Connection 对话框,其中您可以选择是通过套接字连接还是通过 KITL 连接。
确保清除了 Use Windows Sockets for the client/server communication
复选框,如下图所示。
单击 Connect。
在远程工具 (KITL) 的标准用户界面中,选择 Windows CE Default Platform | Default
Device,然后单击 OK,如下图所示。
该过程在目标设备上启动 Clientsideexe,并连接到目标设备上。在完成连接之后,CETK 枚举目标平台上支持的设备,并禁用 CETK
中不支持的设备。
在 CETK 连接到目标设备并枚举设备之后,UI 如下图所示。注意,禁用了某些硬件类别,比如 Bluetooth、IR
Port 和 Modem。
将自定义测试添加到 CETK 中之前,您可以运行一个标准测试,以查看测试工作如何进行。
运行标准测试
在 CETK 中,展开 Windows CE (x86)。
找到并展开 Serial Port。
右键单击 Serial Port Driver Test,然后单击 Quick Start。
这一步只运行了这一个测试,还没有运行所选的其他测试。UI 指示测试正在进行,如下图所示。
CETK 提供测试过程和测试输出的更新。您也可以在 Platform Builder 中检验调试输出,以便查看测试过程,如下例所示。
405910 PID:83d4ee4a TID:83ea5a8a Test Name: Set event mask and wait for
thread to close comm port handle
405920 PID:83d4ee4a TID:83ea5a8a Test ID: 1007
405920 PID:83d4ee4a TID:83ea5a8a Library Path: \serdrvbvtdll
405920 PID:83d4ee4a TID:83ea5a8a Command Line:
405920 PID:83d4ee4a TID:83ea5a8a Result: Passed
405920 PID:83d4ee4a TID:83ea5a8a Random Seed: 15595
405930 PID:83d4ee4a TID:83ea5a8a Thread Count: 1
405930 PID:83d4ee4a TID:83ea5a8a Execution Time: 0:00:05110
405930 PID:83d4ee4a TID:83ea5a8a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
如果 CETK UI
指示模拟器上的串行端口测试已经失败(如下图所示),那么失败可能不是由于每个测试的完全失败而导致的。它可能表明,全部测试套件只有一部分已经失败,并且这部分实际上也是期望的行为。
右键单击 Serial Port Driver Test [Failed],然后单击 View
Results。
出现如下图所示的窗口。
查看上图所示的结果,您可以看到,已经运行了 10 个单独的测试。除了 Set and verify receive timeout
以外,所有这些测试都已经通过。
要获得更多信息,您可以单击个别测试。
返回页首
第五部分:创建自定义 CETK 测试
通过使用 Platform Builder User-Defined Test Wizard,您可以创建一个自定义 CETK
测试。该测试将验证自定义流驱动程序(您也已经将其添加到平台中)的导出函数。
在这一部分的练习中,您将执行以下过程:
列出 CETK 中的自定义流驱动程序测试
运行自定义流驱动程序测试
列出 CETK 中的自定义流驱动程序测试
在 CETK 中,单击 Tests | User Defined。
这一步启动 User-Defined Test Wizard。该向导的第一页只是一些信息。
单击 Next,如下图所示。
单击 Add a New Test,然后单击 Next,如下图所示。
输入下列信息,然后单击 Next:
· 在 Name of Test 框中键入 Custom Stream Driver Test
· 在 Tux Module (DLL) 框中,定位到
C:\Wince500\PBWorkspaces\MyPlatform\RelDir\Emulator_x86_Debug 目录,然后选择
testdll 或 TuxTestdll(这依赖于您在 Platform Builder 中所使用的 Tux
测试的名称)。
· 在 Command Line 框中,保留当前测试的默认设置。
· 在 Processor 框中键入 x86
下图显示信息如何出现在当前的向导页中。
单击 Copy the files to the directory for user-defined tests,然后单击
Next,如下图所示。
您需要将自定义驱动程序测试(您的 DLL)复制到用户定义的测试文件夹中。如果您要删除现有的工作区,那么自定义驱动程序测试仍然保持完好。
单击 Next,如下图所示。
单击 Finish,如下图所示。
CETK 应用程序不会用新的测试进行自动刷新。您需要重新同步桌面应用程序,以查看新添加的测试。
右键单击 Windows CE (x86),然后单击 Redetect Peripherals。
该过程添加了一个名为 User Tests 的新驱动程序类别。您只添加了一个测试,因此,当您展开这个项目时,您只能看到 Custom
Stream Driver Test。
注 已经将自定义流驱动程序测试的 DLL 复制到下列位置: C:\Program Files\Windows CE Platform
Builder\500\CEPB\wcetk\user\x86
运行自定义流驱动程序测试
在可用的测试列表中展开 User Tests。
右键单击 Custom Stream Driver Test,然后单击 Quick Start。
1、电脑硬件没有驱动程序,硬件就无法工作,什么样的硬件,使用什么样的驱动,这就是所谓匹配问题。正因如此,电脑硬件厂商在生产电脑硬件同时,及时发布这个硬件的驱动文件。随时着用户使用,厂家还随时发布该硬件的新版本驱动,以提高这个硬件的性能。总的来说驱硬版本越新越好。
2、电脑硬件是高科技产品,尽管是批量生产,每个件总还是会有不同的地方,不同批次生产,厂家有时会做一些微小的变动,这样就出现了同型号的硬件品质上的差异,正因为有这些差异,就要求有与之匹配的驱动。最新的并不一定同它最匹配。
使用什么版本的驱动还要考虑到,使用的是什么 *** 作系统,要使用与之匹配的驱动;还有使用这个驱动会不会同其他硬件驱动发生冲突等等。
3、已安装好的驱动,如果在使用中没发现什么问题,一般就不要更新。想升级更新,要把现在使用的驱动备份起来,如升级后效果不理想,可还原先前的备份的驱动。
如果我的回答对你有帮助请采纳
*** 作系统自带的驱动并不一定是最好的驱动
相信我们身边有许多这样的“高手”,当同学或别人找不到某款硬件的驱动或不知安装什么 *** 作系统好时,他们往往干脆地回答:“当然是装Vista了,什么驱动都不用装,系统自己就会认出来了!” 如果你愿意深入想一下的话你就会明白这句话是错误的,照那样说的话十年之后的硬件Vista也都能支持了?这显然没有辩证地看问题, *** 作系统自带的驱动仅仅是那些在 *** 作系统推出之前就存在的硬件,那些后于 *** 作系统推出的硬件自然就不在支持之列了。即便如此对于在系统支持之内的硬件而言系统自带驱动也存在两点先天的缺陷:
缺陷1:硬件性能无法得到充分发挥
系统支持的硬件在安装驱动时确实很方便,方便到了连安装程序都不用,打开你的资源管理器就可以看到具体的型号,但是除此之外和正常安装的驱动相比是不是缺了些什么呢?最显著的是少了许多对硬件工作状态的详细设置界面,例如你的显卡可能除了设置颜色质量、分辩率、刷新率外就什么都没有了,猫虽然可以使用了,但是却找不到诊断和通讯的接口等等,归根结底是因为系统更多是从稳定性和兼容性出发,仅仅驱动了硬件最基本的的工作能力。
况且系统很多时候并没能识别所有的硬件,目前最新的Win7 RC就没能识别笔者07年的老主板中的协处理器,必须安装主板芯片组驱动才能识别。
缺陷2:对软件的“兼容性”会越来越差。
为什么要说是硬件对软件也有“兼容性”呢?我们知道,一款硬件在推出之后,技术仍然会继续向前发展,当更先进的技术出现并应用于新产品中后,对应的软件运行环境也会发生相应的变化,旧产品如果得不到驱动程序的支持不能工作于新的软件环境下,将面临着被市场淘汰。相反的,新产品如果得不到驱动的有效支持也是无妨发挥最大性能的,严重的甚至无法工作。
具体到 *** 作系统,有些经验的用户都知道,如果不是进行大规模的Sever Park升级, *** 作系统中集成的驱动是不会更新的。也就是说在相当长的一段时间内你都只能依靠老旧的驱动程序支持硬件工作,让这样一款驱动在几年内应付纷繁复杂的软硬件环境显然是不合适的。
这些与软件“不兼容”现象仅仅靠通过安装系统自带驱动程序是远远不能够解决的,解决的办法一般而言,就是升级最新的驱动程序,那么自然又有人要疑问,这样说来,最新的驱动程序一定就是最好的了?
最新的驱动程序并不一定就是最合适的驱动程序
升级最新的驱动程序几乎可以肯定地说能只会提高硬件的兼容性,至少不会降低硬件的兼容性,但是对于性能来说,就不就这么简单了。拿显卡来说一款硬件在发布之后,初期的驱动程序肯定不可能全部发挥硬件的性能,因此厂家会在后期不停改善算法优化结构从而将硬件的性能充分提炼出来,升级驱动对硬件性能提升总体上是呈现上升趋势的,但是性能的提升不是无限度的,愈到最后提升就会越少,更为重要的是,当产品线不断拉长,新旧显卡在技术上存在较大差异,导致驱动难以采取一致的性能增益标准,最终新版驱动只能放弃那些“前朝遗民”,而且新版本驱动有时还会增加一些早期硬件不能支持的功能,导致早期硬件在安装最新的驱动程序后性能不升反降的现象。
如ATi最新发布的催化剂94版驱动,首次放弃了对DX9显卡的支持。这样做看似慢待了老用户,实际上驱动两极分化的好处是显而易见的。老硬件用老版本驱动,兼容性稳定性兼顾。新硬件安装新驱动,最大限度榨取硬件性能。而且两极分化后更方便驱动的编写,文件体积也大大减小,实在是一举两得。
至于NVIDIA,虽然没像ATI这么正式的宣布放弃对老硬件的支持,但是放弃老硬件的意图也比较明显了。经常更新N卡驱动的用户肯定注意到了,最近发布的GeForce驱动大都集成了PhysX物理加速驱动, NVIDIA PhysX物理驱动只适用于显存容量不少于256MB的GeForce 8/9/200系列显卡,支持Windows XP和Windows Vista 32/64-bit *** 作系统。这样就排除了相当一部分使用低端显卡的用户。
并不是所有的第三方驱动都是最好的
所谓的第三方驱动,通常指那些不满足官方驱动而动手能力比较强的玩家,在官方驱动的基础上进行一系列的破解改造从而将屏蔽的功能或保守的设置强行打开后生成的驱动,如ATi除了Catalyst驱动之外的DNA和Omega驱动,nVIDA除了ForceWare之外的Omega驱动,将nForce2不同版本主板驱动中的AudioDrv、AudioUtl、Ethernet、GART、IDE、MemCtl、SMBus进行自由组合后生成的混合型驱动,再有就是创新声卡中威望甚高的KX、YouP-PAX系列驱动,这些驱动甚至为许多玩家视苦珍宝,的确一些修改较完美的第三方驱动,如声卡驱动,音质提高的快感实在是非外人所感觉到的。但是这些第三方驱动大部分也都存在这样的缺点,没有安装程序,安装复杂,多需要手动设置,同时因为过分追求性能在兼容性上必然有所降低。ATi Catalyst制作人Terry Makedon曾表达过这样的观点:“其他两种驱动(DNA和Omega)都是在ATI开发和测试驱动的基础上的改造,ATi有上百名软件工程师,上千台测试机器,还有一个称为源代码的小东西。如果出于某些原因人们不想用Catalyst,那么我推荐的修改驱动应该是Omega,他一直和ATI合作,并且是Catalyst Beta程序成员,我个人认为他非常专业。因此作为一个终端用户,我感觉Oemga更有可信性。不过我要再说一次,没有一个驱动象Catalyst经过上百种配置测试,并完全由我们支持。”显而易见,对于大多数玩家而言,使用公版驱动得到的是有充分保证的兼容性和稳定性,而第三方驱动并不能保证这一点,如果稳定性和兼容性都无法保证,过分追求性能很容易得不偿失。
选择驱动程序的三个标准
说了这么多,具体于一款硬件究竟该如何选择适合它的驱动程序版本呢?
我们在长期的驱动评测过程中,从大量的实例中总结出了驱动程序版本选择的三条建议,希望能做为大家在驱动版本选择上带来一些启示,从而指导你找到适合自己硬件的最佳驱动版本。
1、 通过官方和微软WHQL认证的
正如ATi Catalyst制作人Terry Makedon所言,任何一家负责的硬件厂商在推出新产品之前必须进行大量的不同平台下的兼容性稳定性测试,如果硬件在某一使用环境中存在问题,厂家就会在驱动内对硬件在该环境下的性能参数进行调低或者更改设置,通过大部分硬件和软件环境测试之后,厂商就会推出一款所谓的官方正式版驱动,当然官方试验室并不能模拟出所有的硬件和软件使用环境,因此如果后续使用中发现新的兼容性问题,厂商就会在适当的时候推出更高版本的官方正式版。驱动程序在通过了厂商测试这一关之后,并不能意味在兼容性上完全没有问题了,在硬件在 *** 作系统使用过程中是否百分之百兼容还需要Windows的掌门人微软出来说话。
WHQL认证的全称为Windows Hardware Quality Labs—Windows硬件质量实验室,它的主要作用是负责创建管理用于测试Windows *** 作系统及外围设备的兼容性测试工具包,并利用这个工具包以及各种方法对硬件和驱动进行兼容性测试,来保证各种设备和驱动在Windows中的稳定运行。WHQL认证对于用户来说无疑是为驱动买了一份保险,因为微软自己的 *** 作系统由他来做这个认证自然有着令人不容置疑的权威地位,但对于厂商来说却不是一件轻松的事情,它意味着驱动要经过更为严厉更为全面的的软硬件测试流程,通过检测的驱动微软会在驱动中加入数字签名,系统便会自动加载这些驱动程序,反之会在安装时出现如下提示窗口:
没有经过微软WHQL认证的驱动在安装时的提示
经过数字签名的ATI WHQL版驱动
未经数字签名的驱动
从上面的驱动认证过程我们可以看出一款经过WHQL认证的官方正式版驱动无疑在兼容性和稳定性上有着强有力的保证,因此这将是我们进行驱动选择时应第一位考虑的因素。
2、 在硬件推出之后退出市场之前发布的驱动程序
nVIDIA软件工程部副总Dwight Diercks曾向外界阐述了厂家在不同时期的驱动开发侧重点:每当nVIDIA伴随新显卡推出新驱动,新驱动的重点是解决新卡的稳定性和兼容性,而性能则放在了其次的地位。之后随着时间的推移和技术的进展,就会出现一款对这个新卡来说性能得到充分优化,同时兼容性也不错的驱动。
Dwight Diercks的话和我们的观点不谋而合,一款硬件在发布最初稳定性和兼容性是驱动首要解决的问题,硬件的性能往往不能得到百分之百的发挥,但是随着产品上市时间的拉长,程序员有更充足的时间来对驱动进行深度开发,同时根据在使用过程中反馈的情况对驱动进行改进提高,因此在新品发布后期推出的驱动程序往往会在性能上有较大的提升。这一点在ATi和nVIDIA历次新品发布后都有力地得到证明,最为明显的一个例子是NVIDIA发布GeForce 17779和PhysX 80718驱动后,GeForce8/9/GT200系列显卡被赋予了物理加速功能,性能得到极大的提升。
GeForce GTX280《虚幻竞技场3》开、关物理加速的测试结果
近一年以来由于经济危机的影响,NVIDIA减缓了新产品的研发,转而充分发掘现有产品的潜力,不断推出新版驱动尽可能的榨取现有产品的剩余性能。短短几个月就发布了数十款显卡驱动。测试版、泄露版、官方正式版交替发布,同一系列显卡短时间内数目如此众多的驱动让谁看都头晕眼花,但是如果按照上面两条原则就可以很快找到你所要的驱动了,排除掉非WHQL官方正式版外,再从剩余中选择版本最高的那一款即是最理想的驱动了。
对于主流硬件而言,上面两个步骤就基本上能找到理想的驱动版本,但是对于那些业已退出市场不再销售的显卡而言,在驱动的选择上还要加上这个条件:
3驱动是在硬件退出市场之前推出的。
关于这一点我们在第一部分已经做过相关解释,对于那些已经退出市场而且与主流硬件隔代很远的硬件来说,最适合的驱动程序主要是看在它退出市场之前所推出的驱动程序,因为只有那些驱动才是专门为这些硬件量身定做的,而最新的驱动程序即使也能支持它,但是在在兼容性和性能上已经不会有什么大的能量可挖了。
概括起来硬件在驱动选择上需要三步:WHQL官方认证+产品推出之后发布的+产品退出市场之前发布的。
除此之外还有一种驱动选择方法,那就是通过互联网或其它各种途径来选择那些大部分人试用之后反映较好的版本,对首次采用新技术的驱动要谨慎使用。同时我们应该知道:兼容性在不同平台上表现是不一样的,因此要想选择出适合自己硬件的版本,需要使用者多少拥有一点动手能力,通过实际测试从可用的版本中挑选出兼容性和性能真正适合自己的一款驱动。
问题一:显卡驱动应该安装在哪个盘里 装在c盘的programfiles文件夹里(这个文件夹是用来专门装软件的)
问题二:驱动一般安装在哪个盘 一般都默认安装路径就可以了。。。 但是建议安装好了把驱动备份到别的盘一份。。
安装驱动推荐使用 蓝色精灵 很好用 几乎全自动解决。。
问题三:显卡驱动应该装在哪个? 有些驱动是默认装系统盘的,不让你选择,如果让你选的,当然可以装别的盘硬盘分多个区当然比一个区要好一点
通过C盘访问速度要比D盘快,D盘又比E盘要块
因为C盘我们一般不放什么东西,分 10G 给他的话,最多用个4G样子,装个驱动在上面比较好而像驱动以及某些应用软件,就算你装别盘,他也会写很多文件在C盘的,像驱动这样的几乎开电脑就会运行的程序,最好是装C盘了,个人觉得
用NTFS格式,多整理整理碎片寻道时间 --在碎片多时比较占时间用LINUX最好,它不存在碎片
问题四:驱动要下载哪个盘里 驱动程序是随便你下在哪个盘里的。但是要载入才能有效。
一般驱动程序有安装程序的,直接安装完毕就可以了。
如果没有安装程序的,在设备管理器里面,选择你要驱动的设备,然后点更新,之后指向你所鼎载的驱动程序所在目录装载就好了。:)
问题五:驱动程序安装在哪个文件夹 所有的程序默认安装到c:\programe files\子目录下,驱动程序默认安装到c:\Windows\syetem32\drivers子目录下。
如果系统有问题了。直接换个验证过的系统盘重装系统就行了,这样就可以全程自动、顺利解决 win7系统安装 的问题了。用u盘或者硬盘这些都是可以的,且安装速度非常快。但关键是:要有兼容性好的(兼容ide、achi、Raid模式的安装)并能自动永久激活的、能够自动安装机器硬件驱动序的系统盘,这就可以全程自动、顺利重装系统了。方法如下:
1、U盘安装:用ultraiso软件,打开下载好的系统安装盘文件(ISO文件),执行“写入映像文件”把U盘插到电脑上,点击“确定”,等待程序执行完毕后,这样就做好了启动及安装系统用的u盘,用这个做好的系统u盘引导启动机器后,即可顺利重装系统了;
2、硬盘安装:前提是,需要有一个可以正常运行的Windows系统,提取下载的ISO文件中的“GHO”和“安装系统EXE”到电脑的非系统分区,然后运行“安装系统EXE”,直接回车确认还原 *** 作,再次确认执行自动安装 *** 作。(执行前注意备份C盘重要资料!);
3、图文版教程:有这方面的详细图文版安装教程怎么给你?不能附加的。会被系统判为违规的。
用这个可以解决问题的,重装系统的系统盘下载地址在“知道页面”右上角的…………si xin zhong…………有!望采纳!
问题六:驱动安装在哪个盘好?为什么?? 如果安装时有个选项给你选的话,你选其他位置也可以,毕竟软件设计人员比你专业,他们这样设计就表示没问题。你装了别不小心删了就行。
问题七:驱动最好装在那个盘里? 驱动 如果是安装的话是默认装在C盘的也是最理想的 因为计算机系统是装在C盘,计算机启动时会调用驱动所以安装在C盘理论是要快一些的。
如果是备份驱动的话 建议放到非C盘就是除了系统盘随便你放哪,这样做的目的是偶尔重装了系统驱动不格式化硬盘其他分区数据的话 驱动不会丢失。
问题八:笔记本电脑所有驱动程序默认安装在哪个文件夹里 驱动程序会根据不同的硬件需求安装在不同的目录下面,但是很多在系统目录下边,你可以通过“设备管理器”中的硬伯属性中“查看驱动的详细信息”来查看相应的驱动存放路径。
问题九:电脑的驱动安装在什么盘好? 硬件驱动安装时 会自动安装在 系统所在的盘符,如C:\Windows\System32\drivers 下,你是不能更改安装位置的
问题十:下载驱动人生,安装在哪个盘? 哪个盘都可以,建议安装在默认位置,驱动安装完成后卸载就行了!
以上就是关于升级驱动程序有什么用全部的内容,包括:升级驱动程序有什么用、如何在 Windows CE 5.0 中开发和测试设备驱动程序、电脑驱动程序有没有必要更新等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)