附图简述
通过参考以下考虑到各附图的描述就可以获得对本发明及其优点的更完全理解,在附图中类似的编号指示相似的特征,并且在附图中:
图1示出了可在其上实现本发明的合适计算系统环境的一个示例。
图2示出了用作管道使得第一和第二代码段经由其通信的接口。
图3示出了包含接口对象的接口。
图4示出了通过细分一接口以将该接口的通信转换至多个接口而提供的函数。
图5示出了通过将一接口细分为多个接口而提供的函数。
图6示出了在仍完成相同结果时一编程接口的忽略、添加或重新定义等方面的一个示例。
图7示出了在仍完成相同结果时一编程接口的忽略、添加或重新定义等方面的另一示例。
图8示出了与图2所示示例有关的合并代码段。
图9示出了与图3所示示例有关的合并接口。
图10示出了转换通信以符合不同接口的中间件。
图11示出了与一分离接口相关联的代码段。
图12示出了一个示例,在其中安装的应用程序基础是被设计成根据接口协议与一操作系统通信,其中该操作系统被改变以使用不同的接口。
图13示出了重写各接口以动态分解或改变这些接口。
图14根据本发明的一个方面示出了提供诸如为指定的KnownFolderID检索Knownfolder PIDL之类功能的扩展API。
图15根据本发明的一个方面示出了提供诸如向调用者提供已知文件夹实际文件系统路径之类功能的额外的扩展API。
图16根据本发明的一个方面示出了提供诸如允许调用者为给定已知文件夹设置路径之类功能的第三扩展API。
图17根据本发明的一个方面示出了提供诸如授予一应用程序具有获取用于一限定已知文件夹的GUID值和/或PIDL值的能力之类功能的IKnownFolder API。
图18根据本发明的一个方面示出了提供创建或删除已知文件夹的能力的IKnownFolderManager API。
图19根据本发明的一个方面示出了KnownFolder Definition结构。
图20根据本发明的一个方面示出了提供列举已知文件夹能力的IEnumKnownFolder()API。
图21根据本发明的一个方面示出了为其他组件提供添加特殊代码用以创建和/或删除已知文件夹能力的IKnownFolderHandler()API。
图22根据本发明的一个方面示出了利用对操作系统的编程接口调用的请求组件。
图22a示出了本发明的另一方面,在其中根据本发明的一个方面一应用程序发送一请求以及一已知文件夹的标识,从而确定已知文件夹的位置。
图23根据本发明的一个方面示出了一种创建新的已知文件夹的方法。
发明详述
为了阐明本发明的揭示,在此提供几个相关术语的定义。
简档(Profile):提供带有每一用户位置以存储用户专用的数据和设置的操作系统和应用程序。
已知文件夹/KnownFolder:为Windows外壳以及其他组件和应用程序所知的一类文件夹。
SHFolderPath()API:包括SHGetFolderLocation()、SHGetFolderPath()和SHSetFolderPath()的一组外壳文件夹API。
CSIDL:用于标识文件夹并提供与系统无关的唯一方式来标识由各应用程序频繁使用的特殊文件夹的序数值。
图1示出了可在其上实现本发明的合适的计算系统环境100的示例。计算系统环境100仅作为合适计算环境的一个示例,并不意味着对权利要求中所述的方法和装置的使用和功能作出任何限制。也不应该将计算环境100解释为对在典型操作环境100中示出的组件中的任何一个或它们的组合具有依赖或要求。
参见图1,一个用于实现本发明的示例系统包括计算机110形式的通用计算设备。计算机110的组件包括但不限于:处理单元120、系统存储器130以及把包括系统存储器在内的各种系统组件耦合至处理单元120的系统总线121。系统总线121可以是任何类型的总线结构,包括存储器总线或存储器控制器、外围总线和使用各种的总线体系结构的任何一种本地总线。作为示例而非限制,这些体系结构包括工业标准体系结构(ISA)总线、微通道体系结构(MCA)总线、增强型ISA(EISA)总线、视频电子技术标准协会(VESA)本地总线以及也被称为Mezzanine总线的外围部件互连(PCI)总线。
计算机110通常包括各种计算机可读介质。计算机可读介质可以是能够被计算机110访问的任何可用介质,且包括易失性和非易失性介质、可移动和不可移动介质。作为示例而非限制,计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以任何方法或技术实现的用于存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括,但不限于,RAM、ROM、EPROM、闪存或其它存储器技术;CD-ROM、数字多功能盘(DVD)或其它光盘存储;磁带盒、磁带、磁盘存储或其它磁性存储设备;或能用于存储所需信息且可以由计算机110访问的任何其它介质。通信介质通常具体化为诸如载波或其它传输机制等已调制数据信号中的计算机可读指令、数据结构、程序模块或其它数据,且包含任何信息传递介质。术语“已调制数据信号”指的是这样一种信号,其一个或多个特征以在信号中编码信息的方式被设定或更改。作为示例而非限制,通信介质包括诸如有线网络或直接线连接的有线介质,以及诸如声学、RF、红外线和其它无线介质的无线介质。上述中任一个的组合也应包括在计算机可读介质的范围之内。
系统存储器130包括易失性或非易失性存储器形式的计算机存储介质,诸如只读存储器(ROM)131和随机存取存储器(RAM)132。基本输入/输出系统133(BIOS)包含有助于诸如启动时在计算机110中元件之间传递信息的基本例程,它通常存储在ROM 131中。RAM 132通常包含处理单元120可以立即访问和/或目前正在操作的数据和/或程序模块。作为示例而非限制,图1示出了操作系统134、应用程序135、其它程序模块136和程序数据137。
计算机110也可以包括其它可移动/不可移动、易失性/非易失性计算机存储介质。仅作为示例,图1示出了从不可移动、非易失性磁介质中读取或向其写入的硬盘驱动器140,从可移动、非易失性磁盘152中读取或向其写入的磁盘驱动器151,以及从诸如CD ROM或其它光学介质等可移动、非易失性光盘156中读取或向其写入的光盘驱动器155。可以在示例性操作环境下使用的其它可移动/不可移动、易失性/非易失性计算机存储介质,它们包括但不限于:盒式磁带、闪存卡、数字多功能盘、数字录像带、固态RAM、固态ROM等。硬盘驱动器141通常由诸如接口140的不可移动存储器接口连接至系统总线121,磁盘驱动器151和光盘驱动器155通常由诸如接口150的可移动存储器接口连接至系统总线121。
以上描述和在图1中示出的驱动器及其相关联的计算机存储介质为计算机110提供了对计算机可读指令、数据结构、程序模块和其它数据的存储。例如在图1中,硬盘驱动器141被示为存储操作系统144、应用程序145、其它程序模块146和程序数据147。注意,这些组件可以与操作系统134、应用程序135、其它程序模块136和程序数据137相同或不同。操作系统144、应用程序145、其它程序模块146和程序数据147在这里被标注了不同的标号是为了说明至少它们是不同的副本。用户可以通过输入设备,诸如键盘162和定点设备161(通常指鼠标、跟踪球或触摸垫)向计算机110输入命令和信息。其它输入设备(未示出)可以包括麦克风、操纵杆、游戏垫、圆盘式卫星天线、扫描仪等。这些和其它输入设备通常由耦合至系统总线的用户输入接口160连接至处理单元120,但也可以由其它接口或总线结构,诸如并行端口、游戏端口或通用串行总线(USB)连接。监视器191或其它类型的显示设备也经由接口,诸如视频接口190连接至系统总线121。除监视器以外,计算机也可以包括其它外围输出设备,诸如扬声器197和打印机196,它们可以通过输出外围接口190连接。
计算机110可在网络化环境下操作,使用至一个或多个远程计算机,诸如远程计算机180的逻辑连接。远程计算机180可以是个人计算机、服务器、路由器、网络PC、对等设备或其它常见网络节点,且通常包括上文相对于计算机110描述的许多或所有元件,尽管在图1中只示出存储器存储设备181。图1中所示逻辑连接包括局域网(LAN)171和广域网(WAN)173,但也可以包括其它网络。这种连网环境在办公室、企业范围计算机网络、内联网和因特网中是常见的。
当在LAN连网环境中使用时,计算机110通过网络接口或适配器170连接至LAN 171。当在WAN连网环境中使用时,计算机110通常包括调制解调器172或用于在诸如因特网等WAN 173上建立通信的其它装置。调制解调器172可以是内置或外置的,它可以通过用户输入接口160或其它合适的机制连接至系统总线121。在网络化环境中,相对于计算机110描述的程序模块或其部分可以存储在远程存储器存储设备中。作为示例而非限制,图1示出了远程应用程序185驻留在存储器设备181上。可以理解,所示的网络连接是示例性的并且可以使用在计算机之间建立通信链路的其它手段。外围接口195可以连接至诸如扫描仪(未示出)或数码照相机194的视频输入设备,在那里输出外围接口可以支持包括通用串行总线(USB)接口在内的标准化接口。
本发明可使用众多其它通用或专用计算系统环境或配置来操作。适合于在本发明中使用的周知的计算系统、环境和/或配置的示例包括,但不限于,个人计算机、服务器计算机、手持或膝上型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费者电子产品、网络PC、小型机、大型机、包含上述系统或设备中的任一个的分布式计算机环境等。
本发明可在诸如由计算机执行的程序模块等的计算机可执行指令的通用上下文中描述。一般而言,程序模块包括例程、程序、对象、组件、数据结构等,它们执行特定任务或实现特定抽象数据类型。本发明也可以在分布式计算环境中实现,其中任务由通过通信网络连接的远程处理设备执行。在分布式计算环境中,程序模块可以位于包括存储器存储设备在内的本地和远程计算机存储介质中。
可以将编程接口(或者更简单地称为接口)看成是能够让一个或多个代码段与由一个或多个其他代码段提供的功能通信或对其进行访问的任何机制、过程或协议。可选地,还可以将编程接口看成是能够与其他组件的一个或多个机制、方法、功能调用、模块等通信耦合的系统组件的一个或多个机制、方法、功能调用、模块和对象等。在前句中的术语“代码段”意味着包括一个或多个指令或代码行,并且包括例如代码模块、对象、子例程、功能等,而无需考虑所应用的术语或者这些代码段是否被分别编译,或者这些代码段是被提供为源、中间还是目标代码,或者这些代码段是在运行时间系统还是过程中被利用,或者它们是位于相同或不同的机器还是分布式的位于多个机器上,或者由这些代码段表示的功能是完全由软件、完全由硬件、还是由硬件和软件的组合来实现。
概念上,一般可将编程接口看成是如图2或图3所示的那样。图2示出了用作管道以使第一和第二代码段能够通过其而进行通信的接口Interface1。图3示出了能够让系统的第一和第二代码段经由介质M通信的包含接口对象I1和I2(可以是第一和第二代码段的一部分,也可以不是)的接口。在图3的视图中,可以把接口像I1和I2那样看做是相同系统的分离接口,也可以认为对象I1和I2加上介质M组成该接口。虽然图2和图3示出了双向流以及在该流两侧上的接口,但是某些实现可以仅具有单向信息流(或者如下所述无信息流)或者可以仅在一侧具有接口对象。作为示例而非限制,诸如应用编程接口(API)、入口点、方法、功能、子例程、远程过程调用以及组件对象模型(COM)接口之类的术语包含在编程接口的定义内。
这一编程接口的各方面可以包括籍此第一代码段向第二代码段发送信息(其中“信息”做广义用并且包括数据、命令、请求等)的方法;籍此第二代码段接收该信息的方法;以及该信息的结构、顺序、语法、组织、模式、定时及内容。在这点上,只要该信息按照该接口定义的方式传输,则下层传输介质本身(无论该介质是有线还是无线的或是有线与无线的组合)对接口的操作并不重要。在某些情况下,信息可以不按传统意义单向或双向传递,因为该信息的传送可以经由另一种机制(例如,放置在缓冲区、文件等内的信息与代码段之间的信息流分开)或者根本不存在某种机制,因为存在一个代码段可以简单访问由第二代码段执行的功能的情况。这些方面的任何一种或所有方面在一给定情形下可能很重要,例如根据上述各代码段是紧耦合还是松耦合配置系统的一部分,所以应该认为该列表是示例性而非限制性的。
编程接口的这一概念是本领域普通技术人员已知的并且可以从本发明在前的详细描述中清楚理解。然而,仍存在实现编程接口的其他方式,并且除非特别指出,这些方法也意欲由在该说明书结尾处的权利要求书的阐述所包括。上述其他方式看上去要比图2和图3的简单化视图更为高级或复杂,但是它们仍执行类似的功能以实现相同的总体结果。现将描述编程接口的某些示例性的可选实现。
从一个代码段到另一个代码段的通信可以通过将该通信打散成多个离散的通信而间接地实现。这在图4和图19中示意性地描绘。如图所示,部分接口可以根据可分的功能集合来描述。于是,可以把图2和图3的接口功能分解因子以实现相同的结果,正如可以算术地提供24或者2乘2乘3乘2一样。因此,如图18所示,可以细分由接口Interface1提供的功能以将该接口的通信转换成多个接口Interface1A、Interface1B和Interface1C等,同时仍实现相同的结果。如图5所示,可以将由接口I1提供的功能细分成多个接口I1a、I1b和I1c等,同时仍实现相同的结果。类似地,从第一代码段中接收信息的第二代码段的接口I2可以被分解成多个接口I2a、I2b和I2c等。在分解时,第一代码段包括的接口数不需要与第二代码段包括的接口数相匹配。在图4和图5的任一情况下,接口Interface1和I1的功能精髓分别保持与图2和图3相同。各接口的分解还可遵循联合、交换和其他数学属性,从而使该分解难以辨认。例如,操作顺序可能不重要,因此由一接口执行的函数可能在到达该接口之前已由另一片代码或接口良好地执行,或已由该系统的独立组件执行。此外,编程领域的普通技术人员能够认识到存在能够实现相同结果的各种不同函数调用的方式。
在某些实施例中,可以在忽略、添加或者重新定义编程接口的某些方面(例如,参数)的同时仍然完成预想的结果。这在图6和图7中示出。例如,假设图2的接口Interface1包括函数调用Square(input,precision,output),即包括三个参数input、precision、output并且由第一代码段向第二代码段发出的调用。如果中间参数precision在如图6所示的给定情况中没有涉及,则忽略该参数甚至用“无意义”(在此情况下)参数来代替该参数都无关紧要。还可以添加无关的“额外”参数。无论以上的哪种情况,只要在第二代码段平方输入之后返回输出,则都能够实现该平方的功能。precision对某些下行或计算系统的其他部分很可能是有意义的参数;然而,一旦认识到precision对计算平方这一狭窄目的而言是多余的,该参数就可以被代替或忽略。例如,代替有效precision值的传递,可以传递诸如出生日期的无意义值而不会对结果产生不利影响。类似地,如图7中所示,接口I1可由接口I1’代替,被重新定义以忽略或添加该接口的参数。接口I2类似地可被重新定义为接口I2’,被重新定义以忽略多余的参数,或是可在别处被处理的参数。此处的要点是在某些情况下编程接口可能包括某些目的不需要的方面(诸如,参数),所以可以忽略或者重新定义这些方面,或者出于其他目的在别处对其进行处理。
将两个分离代码模块的部分或全部功能合并以使它们之间的“接口”改变形式也是可行的。例如,图2和图3的功能可以分别转换成图8和图9的功能。在图8中,图2中的前述第一和第二代码段可以合并成同时含有上述两者的模块。在此情况下,各代码段仍相互通信,但是该接口适用于更适合单个模块的形式。于是,例如正式的调用和返回语句可能不再是必须的,但是按照接口Interface1的类似处理或响应可能仍然有效。类似地,如图9所示,可以将图3中接口I2的部分(或全部)内联地(inline)写入接口I1以形成接口I1”。如图所示,接口I2被分成I2a和I2b,并且接口部分I2a已被内联编码以与接口I1形成接口I1”。对于一具体示例,考虑图3中的接口I1执行函数调用square(input、output),该函数调用由接口I2接收,在由第二代码段处理由input传递的值(即对其进行平方)之后,由output返回该平方值。在这一情况下,由第二代码段执行的处理(平方input)可由第一代码段执行而无需调用该接口。
从一个代码段到另一个代码段的通信可以通过将该通信打散成多个离散的通信来间接实现。这在图10和图11中示意性地描绘。如图10所示,可以提供一个片段或多个片段的中间件(分离接口,因为它们将功能和/或接口函数与原始接口分离)用以将接口Interface1上的通信转换成符合这些中间件的不同接口,即在此情况下的接口Interface2A、Interface2B和Interface2C。这可以在被设计用来根据Interface1协议与例如操作系统通信的基于安装的应用程序中存在,但是随后该操作系统被改变使用一个不同的接口,即在此情况下的接口Interface2A、Interface2B和Interface2C。要点是由第二代码段使用的原始接口被改变,从而不再与由第一代码段使用的接口兼容,所以使用中间物以使得新老接口兼容。类似地,如图11所示,可以引入第三代码段,它带有分离接口DI1以接收来自接口I1的通信并且带有分离接口DI2以将接口功能发送到例如为与DI2一并工作而被重新设计的接口I2a和I2b,但是该第三代码段能够提供相同的功能结果。类似地,DI1和DI2可以一并工作以将图3的接口I1和I2的功能转变至新的操作系统,同时提供相同或类似的功能结果。
另一种可能的变化是动态重写上述代码以使用别的内容来代替该接口功能但能够实现系统的总体结果。例如,存在这样一种系统,在其中将以中间语言(例如,Microsoft IL、Java ByteCode等)呈现的代码段提供给执行环境中的(诸如由.Net框架,Java运行时间环境或者其他类似的运行时间型环境提供的)Justin-Time(JIT)编译器或解释器。可以写出JIT编译器以使其能够将来自第一代码段的通信动态地转换至第二代码段,也就是使上述通信与第二代码段(原始的或不同的第二代码段)可能要求的不同接口一致。这在图12和13中有所描述。从图12中可见,本方法与上述分离情况类似。该方法例如可以在基于安装的应用程序中被设计用来根据Interface1协议与操作系统通信,但是随后该操作系统被改变使用不同的接口。该JIT编译器可使来自基于安装的应用程序到该操作系统的新接口的通信过程中的通信相一致。如图13中所描绘的那样,可以将动态重写一个或多个接口的本方法应用于该一个或多个接口的动态分解或变化。
还应该注意到经由可选实施例的接口来实现相同或类似结果的上述情况也可以按各种方式、串行地和/或并行地、或与其他插入的代码相组合。于是,上述各可选实施例不是互斥的并且可以相互混合、匹配并组合以产生与图2和图3中所呈现的一般情况相同或等效的情况。还应该注意到,如同大多数编程构造一样,存在未在此描述的能够实现相同或类似接口功能的其他类似方法,但是它们仍由本发明的精神和范围所呈现,即应该注意到根据该接口价值的接口表示了至少部分功能,并实现了至少部分的有用结果。
用户接口让用户可以访问运行应用程序及管理操作系统所需的对象。这些对象可以包括驻留在计算机硬盘驱动器上的文件夹和文件。外壳提供用户接口或通过应用程序将这些对象组织成分级的名字空间结构。该外壳可以含有其位置和存在为系统所知并且可从该外壳中的多处(诸如,开始菜单)提供访问的特殊文件夹。
在本发明的一个方面,可以利用GUID(全局唯一标识符)指定系统上每个独立的已知文件夹。已知文件夹可以属于包括虚拟文件夹、固定文件-系统文件夹、公用文件夹和每-用户文件夹在内的四类文件夹中的一种。
虚拟文件夹可以是在外壳名字空间中出现并且不具有与其相关联的任何实际文件系统文件夹的虚拟外壳文件夹。例如,控制面板文件夹和打印机文件夹可以是不为任何实际文件系统文件夹所支持但是仅在外壳虚拟名字空间中存在的虚拟文件夹。这些固定文件文件夹可以是不由外壳管理并且其位置在系统安装时就被固定的文件系统文件夹。例如,“Windows”文件夹和“ProgramFiles”文件夹是固定文件夹。公用文件夹可以是用于用户间共享数据和设置的文件系统文件夹。例如,机器的所有用户可以共享一个公用桌面文件夹。最后,每-用户文件夹可以是位于独立简档之下并由独立用户拥有的文件系统文件夹。例如,“%USERPROFILE%\Pictures”是用于当前用户图片的文件夹。
在本发明的一个方面,已知文件夹的功能由Win32和Com API提供。Win32API可以提供与SHFolderPath API的向后兼容。SHFolderPath API可以是ComAPI的包装,带有用于那些各自的文件夹至新FOLDERID的CSIDL的硬编码映射列表。
为了支持向后兼容,已知文件夹接口可以支持三个Win32 API调用,包括SHGetFolderLocationEx()、SHGetFolderPathEx()和SHSetFolderPathEx()。
SHGetFolderLocationEx()API包含SHGetFolderlocation()API并且可以提供带有额外能力的调用程序,诸如检索用于特定KnownFolderID的KnownfolderPIDL的能力和/或在被请求Knownfolder尚不存在的情况下指定创建该Knownfolder的能力。SHGetFolderLocationEX()API 1400如图14所示。SHGetFolderLocationEX()API 1400的参数可以包括rfid参数1401。rfid参数1401可以表示用于已知文件夹的GUID身份。dwFlags参数1402可以指定当该文件夹被引用时要执行的特殊选项。dwFlags参数1402的默认值可以是零。dwFlags参数1402的其他示例值如下表1所示。
表1
dwFlag的值 |
命令 |
KF_FLAG_CREATE |
当标志被指定时,API将在文件夹不存在的情况下尝试创建该文件夹。 |
KF_FLAG_DON’T_VERIFY |
当标志被指定时,API将不验证该文件夹路径被存储。 |
KF_FLAG_NO_ALAS |
当标志被指定时,API将不尝试映射至别名的PIDL。 |
KF_FLAG_PER_USER_INIT |
指定每-用户初始化应该运行。 |
hToken参数1403可以指定每-用户已知文件夹的所有者。部分已知文件夹,例如“我的文档”文件夹是每-用户文件夹。每个用户可以为他们的“我的文档”文件夹具有不同的路径。如果hToken参数1403具有NULL值,则API访问当前用户(调用者)的文件夹实例。如果hToken参数1403具有有效的用户权标,则API将尝试模仿用户使用该权标并尝试访问该用户的实例。此外,如果hToken参数1403具有为-1的值,则随后该API可以尝试访问默认的用户文件夹。ppidl参数1404可以返回被请求已知文件夹的PIDL。
SHGetFolderPathEx()API包含SHGetFolderPath()API并且可以向调用者提供该已知文件夹的实际文件系统路径。SHGetFolderPathEx()API 1500如图15所示。SHGetFolderPathEx()API 1500参数可以包括与SHGetFolderLocationEx()API 1400的上述讨论相类似的参数,诸如rfid参数1401、dwFlags参数1402和hToken参数1403。此外,SHGetFolderPathEx()API 1500还可以包括pszPath参数1508和cchPath参数1509。然而pszPath参数1508可以返回已知文件夹的路径;cchPath参数1509可以指定pszPath参数1508的缓冲区大小。此外,SHGetFolderPathEx()API 1500还具有可如下表2所示使用的dwFlag值。
表2
dwFlag的值 |
命令 |
KF_FLAG_DEFAULT_PATH |
某些已知文件夹可被重定向至不同的位置,而非默认位置。如果没有标志被指定,API将不会返回该文件夹的当前(重新定向)路径。当标志被指定时,API将会返回被指定已知文件夹的原始默认位置。 |
KF_FLAG_NOT_PARENT_RELATIVE |
与KF_FLAG_DEFAULT_PATH一并使用以给出独立于其上层当前位置的“名字空间原始”默认路径。 |
KF_FLAG_SHARE_PATH |
用于指定与该文件夹相对应的远程共享路径,例如\\computer\user$\ming\Documents. |
SHSetFolderPathEx()API 1600包含SHSetFolderPath()API并且允许调用者为给定的已知文件夹设置路径。SHSetFolderPathEx()API 1600如图16所示。SHSetFolderPathEx()API 1600的参数可以包括与SHGetFolderLocationEx() API1400的上述讨论相类似的参数,诸如rfid参数1401、dwFlags参数1402和hToken参数1403。此外,SHSetFolderPathEx()API 1600还可以包括用来为已知文件夹指定重定向路径的pszPath参数1608。此外,SHSetFolderPathEx()API1600还具有可如下表3所示使用的dwFlag值。
表3
dwFlag的值 |
命令 |
KF_FLAG_DON’T_UNEXPAND |
添加KF_FLAG_DON’T_UNEXPAND值以确保写入登记表的字符串与所提供的完全相同。如果该KF_FLAG_DON’T_UNEXPAND未被包括,这该路径的部分可由环境字符串代替,诸如%USERPROFILE%。 |
如上所述,在本发明的另一方面,已知文件夹的功能可由Com API提供。COM接口可以包括IKnownFolder API、IKnownFolderManager API、IEnumKnownFolder接口以及IKnownFolderHandler。
如图1 7所示,IKnownFolder API 1700可以向应用程序提供为限定已知文件夹获取GUID值和/或PIDL值的能力。此外,IKnownFolder API 1700可以为该限定已知文件夹获取或设置路径。该IKnownFolder API参数可以包括GetID()参数1701。GetID()参数1701可以为指定已知文件夹获取GUID。GetCategory()参数1702可以检索用于指定已知文件夹的已知文件夹类型。该已知文件夹种类可以包括虚拟文件夹类、固定文件系统类、公用文件夹类和/或每-用户文件夹。
IKnownFolder API 1700的额外参数可以包括GetPath()参数1703、SetPath()参数1704、GetLocation()参数1705以及GetItem()参数1706。GetPath()参数1703可以为给定已知文件夹获取路径。SethPath()参数1704可以为已知文件夹设置路径。GetLocation()参数1705可以提供与已知文件夹相关联的PIDL,而GetItem()参数1706可以检索与指定文件夹相关联的外壳接口。
此外,IKnownFolder API 1700还可提供重定向。重定向可以通过使用IsRedirectable()参数1707、IsValidFolderPath()参数1708、Redirect()参数1709和RedirectWithUI()参数1710来指定。可以提供IsRedirectable()参数1707用以检验查明该指定已知文件夹是否允许被重定向。IsValidFolderPath()参数1708可以验证提供的路径是否是用于重定向的有效路径。Redirect()参数1709可以将指定已知文件夹重定向至指定路径。Redirect WithUI()参数1710可以在将已知文件夹重定向至指定路径的同时显示出用户接口。
在本发明的另一方面,可以提供IKnownFolderManager API。如图18所示,IKnownFolderManager API l800可以提供创建或删除已知文件夹的能力。IKnownFolderManager API 1800还可以管理已知文件夹的定义,诸如已知文件夹的描述、该已知文件夹的类型、该已知文件夹的所有权信息和/或已知文件夹的相关路径。此外,IKnownFolderManager API 1800还可以提供列举计算系统上或计算系统环境上所有可用已知文件夹的能力。例如,IKnownFolderManagerAPI 1800可以为访问计算机网络的用户列举所有可用的周知文件夹。
根据本发明的一个方面,IKnownFolderManager API 1800可以包括多个参数。例如,IKnownFolderManager API 1800可以包括FolderIdFromCSIDL()参数1801。FolderIdFromCSIDL()参数1801可用于检索与指定CSIDL相关联的KnownFolder_ID。FolderldFromCSIDL()参数1801因此可以提供CSIDL和KnownFolder_ID之间的转换。类似地,还可以定义FolderldToCSIDL()参数1802以获取用于指定KnownFolder_ID的CSIDL值。
也可以将GetFolder()参数1803定义为IKnownFolderManager API 1800的参数。GetFolder()参数1803可用于直接获取与一具体已知文件夹有关的信息,其中该已知文件夹的ID可用。GetFolder()参数1803可以返回IKnownFolder指针以获取信息,诸如与已知文件夹有关的GUID值、已知文件夹的类型、已知文件夹的路径和/或与已知文件夹相关联的PIDL等。与GetFolder()参数1803类似,还可以定义GetFolderForUser()参数1804,用以向调用者提供获取属于该特定用户的已知文件夹的路径的能力。
参见图18,可以提供GetFolderDefinition()参数1805以获取与指定KnownFolder_ID相关联的所有属性。根据本发明的一个方面,如图19所示定义KnownFolder_Definition结构1900。KnownFolder_Definition结构1900如图19所示可以含有多个限定字段并且在表4中有进一步的描述。这些字段包括category 191O、pszName 1911、pszCreator 1912、pszDescription 1913、pfidParent1914、pszRelativePath 1915、pszParsingName 1916、pszTooltip 1917、pszLocalizedName 1918、pszIcon 1919、pszSecurity 1920、dwAttributes 1921、pszLegacyPath 1922、clsidHandler 1923、and kfdFlags 1924。
表4
category |
指示该指定文件夹属于哪一个已知文件夹类型。 |
pszName |
为该已知文件夹提供未-本地化名。 |
pszCreator |
定义该已知文件夹的应用程序名。 |
pszDescription |
该已知文件夹表示内容的简短描述。 |
pfidParent和pszRelativePath |
可与公用和每-用户文件夹一并使用以指出一具体文件夹应该在另一个已知文件夹下被创建。 |
pszParsingName |
该字段可用于虚拟文件夹指出外壳名字空间文件夹路径。 |
pszTooltip |
该字段可表示当一已知文件夹由API创建时用于该文件夹的默认工具提示。 |
pszLocalizedName |
当已知文件夹由API创建时该文件夹的默认本地化名。 |
pszIcon |
当该已知文件夹由API创建时用于该文件夹的默认图标。 |
pszSecurity |
当该已知文件夹由API创建时用于该文件夹的用以描述默认安全描述符的SDDL格式字符串。 |
dwAttributes |
当该文件夹被创建时设置的默认文件系统属性,诸如只读 |
pszLegacyPath |
提供与各文件夹有关的旧版本路径。它可用于迁移/漫游以及应用程序的兼容。 |
clsidHandler |
可以指定IKnownFolderHandler对象,该对象可以在诸如创建和删除该已知文件夹的特定情况下被调用以进行某些定制工作。 |
dwDefinitionFlags |
定义若干标志以描述该已知文件夹更为精细的性态。这些标志可包括:KFDF_PERSONALIZE-用以显示该文件夹的人格化名;KFDF_LOCAL_REDIRECT_ONLY-可被重定向至本地磁盘;KFDF_ROAMABLE-可经由PC至PC sycn漫游。 |
参见图18,可以提供诸如RegisterFolder()参数1806和UnregisterFolder()参数1807的参数用以为系统创建或删除已知文件夹。RegisterFolder()参数1806可以请求用户或调用者指定有效的KnownFolder_Definition。UnregisterFolder()参数1808在请求时可以删除该KnownFolder_Definition定义。
还可以定义诸如GetEnumKnownFolders()参数1809和GetEnumKnownFoldersForUser()参数1810等额外参数用来与IKnownFolderManager API 1800一并使用。GetEnumKnownFolders()参数1809可以返回一指针来列举系统上所有的已知文件夹,而GetEnumKnownFoldersForUser()参数1810则为调用者提供列举与一特定用户有关的已知文件夹的能力。最后,FindFolderFromPath()参数1811可以返回一已知文件夹指针用来为提供的文件系统路径获取相关联的已知文件夹ID。
在本发明的另一方面,还可以提供IEnumKnownFolder()API。如图20所示,IEnumKnownFolder()API 2000可以提供列举已知文件夹的能力。GetEnumKnownFolders()参数1809和GetEnumKnownFoldersForUser()参数1810可以将一指针返回至IEnumKnownFolder()API 2000以得到该系统上所有已知文件夹的列举。IEnumKnownFolder()API 2000可以包括诸如Next()200l、Skip()2002、Reset()2003和Clone()2004之类的参数。Next()参数2001可以在该列举序列中检索项目标识符的指定编号并能通过这些检索出的项目编号由当前位置前进。Skip()参数2002可以跳过列举序列中指定编号的元素。Reset()参数2003可以将接口返回至该列举序列的开头。Clone()参数2004可以创建与当前对象的内容和状态相同的新列举对象。
在本发明的另一方面,可以提供IKnownFolderHandler()API。如图21所示,IKnownFolderHandler()API 2100可以向其他组件提供为已知文件夹的创建和/或删除添加特殊代码的能力。IknownFolderHandler()API 2100可以包括诸如GetDefaultLocation()2l0l、FolderCreated()2102和FolderRemoved()2103的参数。GetDefaultLocation()参数2101可以为一已知文件夹检索默认位置。FolderCreated()参数2102可以在指定已知文件夹被创建时启动一处理程序。此外,FolderRemoved()参数2103可以在指定已知文件夹被删除时启动一处理程序。这可以为应用程序提供在一已知文件夹由该应用程序创建或删除时运行自定义代码的能力。
图22示出了根据本发明的一个方面利用对一操作系统2202的程序接口调用的请求组件2201。在本发明的一个方面,请求组件2201是一应用程序,诸如在其他实施例中,请求组件2201可以集成在如图1所示的计算机110的外围硬件内。
请求组件2201,一旦由开发人员或用户安装,就可以决定在计算机110上创建、列举或管理现有的已知文件夹。例如,图22的应用程序2201在一应用程序被安装时可以通过将新的已知文件夹直接添加至登记表2203而在用户简档内创建新文件夹。此外,新的已知文件夹还可以通过诸如IKnownFolderManager API的KnownFolder APIs 2210添加。开发人员或用户通过应用程序2201可以调用2250诸如IKnownFolder Manager API 1800的API以创建新的已知文件夹。开发人员或用户可以通过该应用程序提供将会是用于该新已知文件夹的唯一标识符的GUID 2251。开发人员或用户还可以越过并超过与新已知文件夹相关联的标准属性来定义额外的属性2252。参见图22,应用程序2201发送调用2250,诸如对KnownFolder APIs 2210的调用。响应于输入2250,IKnownFolderManager API 1800使用操作系统2202在该操作系统2202的登记表2203中登记该新的已知文件夹。该操作系统则作为响应将该新的已知文件夹的路径2260发送给应用程序2201。
图22a示出了本发明的另一个方面。参见图22a,利用程序接口调用的应用程序2201可以经由已知文件夹API 2210发送请求,该请求带有关已知文件夹位置的标识2260。已知文件夹API 2210可以在登记表2203中搜索已知文件夹列表2280以及它们相应的存储位置。已知文件夹API 2210可以经由对该已知文件夹位于其内的一具体存储设备(诸如本地存储2255)的请求2261,来验证在登记表中指定的存储位置是否有效。一旦验证了该位置,KnownfolderAPI可以将被请求已知文件夹的路径返回给该应用程序。例如,“我的图片”2270已知文件夹可由应用程序2201经调用2260请求。已知文件夹API 2210通过检测登记表列表2280就可确定该图片2270的位置。已知文件夹API 2210可以经由向本地存储2255的请求来验证该位置的确存在并且一旦证实可以将通向本地存储2255上的图片位置2262的路径返回给应用程序2201。
“我的图片”已知文件夹2270可以从本地存储2255移动至网络存储2256。“我的图片”已知文件夹2270的重新定位改变了该“我的图片”已知文件夹2270的位置路径。“我的图片”已知文件夹2270的位置可以在登记表2203内得以更新。类似地,“我的图片”已知文件夹2270向诸如网站位置2257的另一位置的移动2295也可以启动登记表2203更新“我的图片”已知文件夹2270的新位置。
图23根据本发明的一个方面示出了一种创建新的已知文件夹的方法。参见图23,在步骤2301处,诸如操作系统的组件接收来自第一组件的具有GUID的调用。该第一组件可以包括由开发人员或用户安装或初始化的应用程序。一旦该调用由操作系统接收,则在步骤2302处,该操作系统就提取由该应用程序提供的GUID。该调用还可以包括额外信息,诸如用于新已知文件夹创建的属性。这些属性可以包括用于限定该新的已知文件夹的信息,诸如category、pszName、pszCreator、pszDescription、pfidParent、pszRelativePath、pszParsingName、pszTooltip、pszLocalizedName、pszIcon、pszSecurity、dwAttributes、pszLegacyPath、clsidHandler和kdfFlags。
基于提取的GUID和提供的额外信息,在步骤2303处可以创建新的已知文件夹。该新的已知文件夹如步骤2304所示可以包括在操作系统的登记表内。该操作系统在步骤2405中可以将该新的已知文件夹的路径发送给应用程序。该应用程序可以列举在本地或网络系统上现存的所有已知文件夹。
虽然已参考包括目前的本发明较佳实施方式在内的特定示例描述了本发明,但是本领域普通技术人员将会认识到存在上述系统和技术的各种变化和置换,它们仍位于所附权利要求书阐述的本发明的精神和范围内。