锘??xml version="1.0" encoding="utf-8" standalone="yes"?>
鎭版伆鐩稿弽錛屾湁浜涘弽灝勭殑鐗規ф槸緇忓父浼氳浣跨敤鍒扮殑銆?/p>
鍙嶅皠鎬諱綋涓婂垎鎴愪袱澶х壒鎬э紝涓鏄嚜鐪侊紝浜屾槸鍙戝皠錛?/p>
鑷渷鐨勮兘鍔涙瀬涓洪噸瑕侊紝鑰屼笖鍑犱箮浼氬ぉ澶╃敤鍒幫紝寰堝皯瑙佸埌榪囧摢涓?net搴旂敤涓笉浣跨敤attribute鐨勶紝鑰宎ttribute鐗規у氨鏄痬etadata閫氳繃鍦ㄨ嚜鐪佽兘鍔涙敮鎾戜笅瀹炵幇鐨勶紱褰撶劧鑷渷涓嶅崟鍗曟槸attribute鐗規х殑榪愮敤錛屽彧瑕佹槸鍦ㄨ繍琛屾椂鍔ㄦ佹瑙嗙▼搴忚嚜韜殑鐗規ч兘瑕佺敱鍙嶅皠鐨勮嚜鐪佽兘鍔涙潵鏀寔錛屾瘮濡俈isual Studio鐨処DE錛堣繖涓泦鎴愬紑鍙戠幆澧冩湰韜氨鏄?net搴旂敤鐨勫ソ妗堜緥錛夊浜?net緇勪歡鐨勮嚜鍔ㄦ帰嫻嬪姛鑳斤紱鍚屾椂錛岃嚜鐪佺殑鑳藉姏涔熸槸鍩轟簬铏氭嫙鏈哄鉤鍙扮殑璇█錛屾瘮濡俢#鍜宩ava錛屽尯鍒簬浼犵粺璇█姣斿c鍜宑++鐨勯噸瑕佺壒鎬т箣涓錛岃繖鎻愪緵浜嗙▼搴忚璁″紑鍙戞洿涓轟究鍒╁拰瀹夊叏鐨勮繍琛屾椂鐜錛涚浉瀵硅岃█錛屽湪c++錛堝綋鐒舵槸native鑰屼笉鏄痬anaged錛夌殑鐜涓嬶紝闄や簡RTTI鏋佷負鍗曡杽鐨勮繍琛屾椂鑷渷錛屼篃灝辨槸QT榪欎釜搴撻氳繃meta-object system閮ㄥ垎妯℃嫙浜嗚嚜鐪佺殑鐗規э紱
鍙嶅皠鐨勫彟澶栦竴涓噸瑕佺壒鎬у氨鏄彂灝勶紝瀹冭“紼嬪簭鍙互鍐欑▼搴?#8221;浜嗭紝綆瑕佺殑璇村氨鏄湪榪愯鏃跺姩鎬佺敓鎴怣SIL騫跺姞杞借繍琛屼互鍙婃寔涔呭寲鍔ㄦ佺敓鎴愮殑MSIL鐨勮兘鍔涳紱鐢辮繖涓壒鎬х殑鏀寔錛岃鍘熷厛涓浜涚▼搴忚璁″拰寮鍙戦鍩熺浉瀵瑰洶闅懼拰綣佺悙鐨勫伐浣滐紝姣斿鍏冪紪紼媘eta programming錛屾瘮濡傚姩鎬佷唬鐞哾ynamic proxy錛屾瘮濡侫OP涓殑鍩虹璁炬柦weaver鐨勫疄鐜幫紝鍙樺緱鍙兘鎴栫浉瀵規槗浜庡疄鐜幫紱鍙嶅皠鐨勭壒鎬э紝涔熸槸鍩轟簬铏氭嫙鏈哄鉤鍙癈LR鐨勬敮鎸侊紝浠etadata涓哄熀紜鏉ュ疄鐜扮殑錛屾墍浠ヨ繖涔熸槸铏氭嫙鏈哄鉤鍙拌璦鐨勭壒鏈変紭鍔匡紝鑰屽湪浼犵粺璇█騫沖彴涓婏紝榪欐槸闅句互瀹炵幇鐨勶紱姣斿鍏充簬meta programming錛宑++灝辨槸閫氳繃妯℃澘鐗規у疄鐜扮殑緙栬瘧鏈焟eta programming錛岃繖涓庤櫄鎷熸満騫沖彴涓婂疄鐜扮殑榪愯鏃秏eta programming榪樻槸鏈夋瘮杈冨ぇ鐨勫樊璺濓紙姣斿鍓嶈呭浣曚繚璇佺敓鎴愮殑浠g爜鐨則ype-safe錛夛紱
浠ヤ笂榪欎袱涓壒鎬э紝鑷渷鍜屽彂灝勶紝閮芥湁涓叡鍚岀偣錛屼粬浠兘鏄洿緇曠潃metadata鏈哄埗錛屽茍鍦ㄨ櫄鎷熸満騫沖彴榪愯鏃剁幆澧僀LR鏀寔涓嬪疄鐜扮殑錛屽墠鑰呮槸榪愯鏃舵瑙嗙浉鍏崇殑metadata錛屽悗鑰呮槸榪愯鏃跺姩鎬佺敓鎴愮浉鍏崇殑metadata鍜孧SIL錛涗粠榪欑偣涔熷氨鍙互鐪嬪嚭錛岃鎯蟲繁鍏ョ悊瑙h繖浜涚壒鎬э紝灝遍渶瑕佺爺絀秏etadata鍜孧SIL鐨勫疄鐜幫紝浠ュ強铏氭嫙鏈鴻繍琛屾椂鐜鐨勫疄鐜幫紙鍦╦ava騫沖彴涓婏紝灝辨槸bytecode鍜孞VM錛夛紱
鎵浠ワ紝鍙嶅皠錛屽彲鑳芥槸铏氭嫙鏈哄鉤鍙版墍鎻愪緵鐨勭浉瀵規渶涓哄己鍔詫紝鏈涓哄鏉傦紝鍜屽鉤鍙拌繍琛屾椂鏈韓鍏崇郴鏈瀵嗗垏錛屼篃鏄尯鍒簬浼犵粺璇█鍜岃繍琛屾椂鏈椴滄槑鐨勭壒鎬с?/p>
铏界劧瀵逛簬鍏ㄦ柊鐨勫伐紼嬮」鐩紝鎺ㄨ崘閫氳繃.net瀹炵幇錛屼絾鏄紝鍙浣犲伐浣滃湪Windows騫沖彴涓婏紝蹇呯劧浼氶亣鍒板拰COM鐩稿叧鐨勬妧鏈拰鏈哄埗錛屾棤璁烘槸澶ч噺鐨刲egacy鐨勫伐紼嬪拰浠g爜錛岃繕鏄綔涓篛S閲嶈鍔熻兘浠ュ強native緇勪歡鐨勯閫変氦浜掑艦寮忓拰鎺ュ彛鏆撮湶鏂瑰紡錛屾瘮濡侱irectX API錛屾瘮濡備竴浜沇MI鐨凙PI錛涙渶鏈夎叮鐨勬槸錛屽嵆浣挎槸.net鐨勬牳蹇僀LR鏈韓涔熸槸涓涓狢OM緇勪歡錛屽彲浠ラ氳繃Host鐩稿叧鎺ュ彛璁﹏ative搴旂敤鏉ュ姞杞斤紝浠ュ湪褰撳墠榪涚▼涓惎鍔ㄦ暣涓狢LR鐨勮櫄鎷熸墽琛岀幆澧冩垨鑰呭彨鎵樼鎵ц鐜(managed executive environment)銆?/p>
鎶婃彙COM鏈変袱鐐瑰緢鍏抽敭錛?br>1錛塈nterface-based design錛屼粠璁捐鍜岀紪鐮佹濊礬涓婂氨鏄瀹屽叏鍩轟簬鎺ュ彛錛?br>2錛塚irtualTable-based binary compatibility, 瀹炵幇涓婃棤璁轟綍縐嶈璦鎴栬呮満鍒訛紝鍙絎﹀悎鍩轟簬铏氳〃鐨勪簩榪涘埗鍏煎瑙勮寖錛屽氨閮藉彲浠ュ疄鏂斤紱
COM浠呬粎鏄釜瑙勮寖錛屽熀浜嶤OM鐨勫叿浣撴妧鏈潪甯鎬箣澶氾紝OLE錛孉utomation錛孲tructural storage錛孉ctiveX...姹楃墰鍏呮爧錛岃繕鏈塁OM+錛岃繖涓槸鎻愪緵浼佷笟綰у紑鍙戝繀澶囩殑涓浜涘熀紜鍔熻兘鍜岃鏂斤紝姣斿錛屼簨鍔$鐞嗘満鍒訛紝瀵硅薄姹狅紝瀹夊叏綆$悊錛屾秷鎭槦鍒?..闇瑕佹寚鍑猴紝鐩墠鍗充究鏄?net Framework涔熸病鏈夊疄鐜癈OM+鎵鎻愪緵榪欎簺鏈哄埗錛屽彧鏄畝鍗曠殑灝佽浜嗗悗鑰呫?/p>
COM鎶鏈腑鍙兘鏈変竴浜涙瘮杈冨洶闅劇殑鍦版柟錛屾帴鍙g殑涓鑷存э紝瀵硅薄鐨勮仛鍚堝拰鐢熷懡鍛ㄦ湡錛屽闂達紝璺ㄥ闂寸殑鎺ュ彛璁塊棶錛屽悕瀛楀璞★紝絳夌瓑錛涜繖浜涘茍涓嶆槸COM瑙勮寖浜轟負鍒墮犵殑鍥伴毦錛岃屾槸涓轟簡璁捐鍜屾彁渚涳紝鍙互璺ㄨ繘紼嬪拰鏈哄櫒杈圭晫錛岃法寮傛瀯騫沖彴錛堝綋鐒跺繀欏誨疄鐜頒簡COM鎵瑙勫畾鐨勫熀紜鏈嶅姟錛夛紝閫忔槑鍖栧叿浣撳璞$被鍨嬪強瀵硅薄鐢熷懡鍛ㄦ湡錛屼究浜庣粺涓閮ㄧ講鍜岀増鏈鐞嗙殑緇勪歡鎶鏈紝鎵蹇呴』浠樺嚭鐨勪唬浠鳳紝榪欎釜浠d環浠庡紑鍙戜漢鍛樿搴︾湅鍏蜂綋琛ㄧ幇涓猴紝姒傚康鐞嗚В鐨勫洶闅句互鍙婂叿浣撲簩榪涘埗瀹炵幇鐨勫洶闅撅紱
涓嶈繃浠庡彟涓涓搴︾湅錛孋OM宸茬粡寰堝鏄撲簡錛?br>a) COM瑙勮寖宸叉妸瑕佽揪鑷磋繖浜涚洰鏍囩殑緋葷粺錛屾墍蹇呴』鎻愪緵鐨勬帴鍙e拰鐗規ф娊璞′簡鍑烘潵錛屽彧涓嶈繃涓轟簡琛ㄨ揪榪欎簺鎶借薄鐨勬蹇佃屾柊閫犵殑鏈鍚嶈瘝鏈変簺闄岀敓鍜岀獊鍏錛涘鏋滆閬囧埌鐩鎬技闂鐨勬瘡涓涓璁″拰寮鍙戜漢鍛橀兘鑷繁鏉ュ仛鎶借薄錛屾湭蹇呬細鐢熸垚鏇村ソ鐨勬柟妗堬紱
b) 涓轟簡甯姪璁捐鍜屽紑鍙戜漢鍛橈紝浜轟滑鎻愪緵浜嗗緢澶氱殑寮鍙戝簱錛屼互鎻愰珮COM寮鍙戠殑姝g‘鎬у拰鏁堢巼錛涙渶鏄捐憲鐨勫氨鏄疢FC涓叧浜嶤OM/OLE鐨勮緟鍔╃被鍜屽嚱鏁幫紝浠ュ強涓轟簡COM鑰岀敓鐨凙TL錛涗粠鏈川涓婄湅錛岃繖浜涚被搴撻兘鏄妸COM瑙勮寖涓繀欏誨疄鐜扮殑錛學indows騫沖彴鏈韓娌℃湁鎻愪緵錛屽叿浣撹璁″拰寮鍙戜漢鍛樺疄闄呭疄鏂芥椂浼氶噸澶嶅疄鐜扮殑錛屽悓鏃跺張闈炲父瀹規槗鍑洪敊鐨勯偅閮ㄥ垎鍔熻兘錛岄泦涓埌浜嗚繖浜涚被搴撻噷緇熶竴瀹炵幇錛岃鍏蜂綋璁捐鍜屽紑鍙戜漢鍛樹互浠g爜閲嶇敤鐨勫艦寮忔潵瀹炵幇COM瑙勮寖錛?/p>
褰撶劧浜轟滑涔熸剰璇嗗埌浜咰OM榪欐牱鐨勪竴浜涢棶棰橈紝鐗瑰埆鏄叿浣撳疄鐜版椂璁捐鍜屽紑鍙戜漢鍛樺繀欏昏鍏蟲敞鍑犱箮鎵鏈夌殑浜岃繘鍒剁粏鑺傦紝浜庢槸.net灝辮癁鐢熶簡錛屾妸榪欎簺瑙勮寖鐨勮澶氬鏉傛ч兘灝佽鍦ㄤ簡铏氭嫙鏈洪噷闈紝鎶婅繖浜涚洰鏍囧姛鑳斤紙璺ㄨ竟鐣屻侀忔槑鎬х瓑絳夛級閫氳繃涓鑷磋屽張騫蟲粦鐨勫鉤鍙版帴鍙e拰鑷弿榪扮殑meta data錛屼互涓縐嶈璁捐鍜屽紑鍙戜漢鍛樻洿鏄撴帴鍙楃殑椋庢牸寮鏀句簡鍑烘潵錛?/p>
COM鐨勫獎鍝嶆槸闈炲父騫垮ぇ鐨勶紝姣斿XPCOM 錛孎irefox涓婄殑涓縐嶆彃浠舵妧鏈爣鍑嗭紝灝辨槸鏍規嵁COM鐨勬濇兂鍜屽師鍒欏埗瀹氱殑錛涜澶氳瘎璁鴻錛孎irefox鐨勬垚鍔熸槸鍥犱負瀹冩彃浠舵槸濡傛鐨勬垚鍔燂紝榪欎篃綆楁槸COM鏈韓鎵鎰忔枡涓嶅埌鐨勮礎鐚箣涓銆?/p>
鍦?net鐨勫鉤鍙頒笂錛屽嵆浣挎槸.net CLR/SSCLI鐨勫叿浣撳疄鐜頒篃澶ч噺榪愮敤浜咰OM鐨勬濇兂鍜屾満鍒訛紝鍙互璇?net灝辨槸鎼緩鍦–OM浜岃繘鍒剁粍浠跺鉤鍙頒箣涓婄殑铏氭嫙鏈烘墭綆″鉤鍙般?/p>
鏈鍚庯紝.net寮濮嬫椂鐨勫唴閮ㄧ紪鍙鋒槸COM 2.0
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*) 鍏充簬“鍚嶈瘝澶”
榪欐槸瑕佸疄鐜板彲浠ヨ法榪涚▼鍜屾満鍣ㄨ竟鐣岋紝璺ㄥ紓鏋勫鉤鍙幫紙褰撶劧蹇呴』瀹炵幇浜咰OM鎵瑙勫畾鐨勫熀紜鏈嶅姟錛夛紝閫忔槑鍖栧叿浣撳璞$被鍨嬪強瀵硅薄鐢熷懡鍛ㄦ湡錛屼究浜庣粺涓閮ㄧ講鍜岀増鏈鐞嗙殑緇勪歡鎶鏈紝鎵蹇呴』浠樺嚭鐨勪唬浠楓?/p>
COM瑙勮寖宸叉妸瑕佽揪鑷磋繖浜涚洰鏍囩殑緋葷粺錛屾墍蹇呴』鎻愪緵鐨勬帴鍙e拰鐗規ф娊璞′簡鍑烘潵錛屽彧涓嶈繃涓轟簡琛ㄨ揪榪欎簺鎶借薄鐨勬蹇佃屾柊閫犵殑鏈鍚嶈瘝鏈変簺闄岀敓鍜岀獊鍏錛涘鏋滆閬囧埌鐩鎬技闂鐨勬瘡涓涓璁″拰寮鍙戜漢鍛橀兘鑷繁鏉ュ仛鎶借薄錛屾湭蹇呬細鐢熸垚鏇村ソ鐨勬柟妗堬紱
涓句釜渚嬪瓙錛宎partment錛屽闂達紝灝辨槸涓轟簡鎶借薄浼犵粺OS涓繘紼嬪拰綰跨▼鐨勫疄鐜拌屾柊閫犵殑鏈鍚嶈瘝鍜屾蹇碉紱浠諱綍浜鴻鎶借薄榪欐牱鐨勪竴浜涙蹇碉紝涓嶆柊閫犳湳璇紝鏄潪甯稿洶闅劇殑錛屽姣?net錛屽悗鑰呯敤浜咰LR铏氭嫙鏈烘潵灝佽浜嗗ぇ澶氭暟鐨勫疄鐜扮粏鑺傦紝騫剁敤璁╀漢鏇村鏄撴帴鍙楃殑椋庢牸鏉ュ紑鏀炬帴鍙o紝鍙簨瀹炰笂浠嶇劧鏂伴犱簡涓浜涘悕璇嶅拰姒傚康錛屽綾諱技鑼冪暣鐨凙ppDomain錛?/p>
*) 鍏充簬“鍩轟簬ATL鐨勫疄鐜版瘮杈冮毦鎳?#8221;
ATL涓昏浣跨敤浜唗emplate鎶鏈紝COM鎺ュ彛鏅鴻兘鎸囬拡錛岀敤闈欐佽漿鎹㈡潵妯℃嫙鍔ㄦ佺粦瀹氾紝絳夌瓑錛屽疄闄呭茍涓嶆槸寰堝鏉傦紝鍙兘綆梒++瀹炵幇鏈哄埗鐨勪腑絳夐毦搴︼紝涓昏娑夊強Modern C++ design涓涔︿腑涓浜涚浉鍏寵璁$悊蹇電殑榪愮敤銆傚姣擝oost涓煇浜涘簱鐨勫疄鐜幫紝ATL寰堜漢閬撲簡銆?/p>
*) 鍏充簬“榪欏茍涓嶆槸COM鏈韓澶嶆潅錛岃屾槸C++宸茬粡钀藉悗浜庢椂浠d簡”
棣栧厛COM鐨勮鑼冪殑紜槸澶嶆潅鐨勶紝涓哄暐錛熺涓鐐瑰凡緇忚浜嗭紝灝辨槸涓轟簡瑕佹娊璞″嚭璺ㄨ竟鐣屽拰瀵硅薄閫忔槑鐨勭粍浠舵妧鏈紱.net琛ㄨ薄涓婄湅姣旇緝“綆鍗曞鏄?#8221;錛岄鏍間翰榪戣璁″拰寮鍙戜漢鍛橈紝瀹為檯涓婂鏉備簨鍔″拰瀹炵幇緇嗚妭閮借鍒掑垎鍒癈LR閭d釜灞傞潰涓婂幓瀹炵幇浜嗭紱鍘葷湅涓涓婥LR鐨勫紑婧愬疄鐜癝SCLI錛屼綘浼氬彂鐜幫紝鏁翠釜铏氭嫙鏈哄鉤鍙扮殑瀹炵幇錛屽ぇ閲忚繍鐢ㄤ簡COM鐨勬濇兂鍜屾満鍒訛紝灝辨槸涓涓法鍨嬬郴緇熷鉤鍙扮駭鐨凜OM server錛?/p>
鍏舵錛孋OM瑙勮寖鏈韓鏄嫭绔嬩簬瀹炵幇璇█鐨勶紝鍙鏋勫緩鍑虹殑緇勪歡絎﹀悎瑙勮寖鍒跺畾鐨勪簩榪涘埗鍏煎錛岀郴緇熷氨鍙互榪愪綔錛岃繖鍜孋++鏄惁钀藉悗鏃朵唬娌℃湁鍏崇郴銆傚鏋滃紑鍙戜漢鍛樿涓猴紝.net鎵嶅鍏堣繘錛屼篃瀹屽叏鍙互鐢?net涓殑鎵樼璇█錛屽C#鏉ュ疄鐜癈OM緇勪歡錛?/p>
鏈鍚庯紝姣忕璇█閮芥湁鍏墮傜敤鐨勮寖鍥達紝鐜板湪鍙互榪欎箞璇?#8220;濡傛灉鏈変竴涓叏鏂扮殑欏圭洰闇姹傦紝瑕佽揪鑷磋法杈圭晫鍜屽璞¢忔槑緇勪歡錛屽茍涓旀病鏈夊お榪囦弗鑻涚殑鎬ц兘闇姹傦紝閭d箞.net騫沖彴鍙婂叾涓婄殑鎵樼璇█鏉ュ疄鐜幫紝姣旂敤C++鍙婄浉鍏寵緟鍔╃被搴撴潵浠OM緇勪歡褰㈠紡鏉ュ疄鐜幫紝瑕佹洿鍚堥傦紝涔熸洿蹇熶究鎹峰拰鑺傜渷棰勭畻銆?#8221;浣嗘槸錛屽湪榪欎釜鍒ゆ柇涓婃垜浠姞浜嗗緢澶氫弗鏍肩殑綰︽潫錛屼竴鏃﹂渶姹傚彉鏇達紝鐗瑰埆鏄」鐩殑闈炲姛鑳芥ч渶姹傦紝瑕佹眰楂樻ц兘榪愮畻鎴栬呮洿欏虹晠鐨勪笌legacy鐨刵ative緋葷粺鐩鎬簰錛岄偅涔?#8220;浣跨敤native璇█鏉ュ疄鐜版ц兘鍏抽敭浠ュ強legacy浜や簰鍔熻兘錛岄氳繃COM灝佽錛屽啀鐢盋OMInterop浜?net鎵樼搴旂敤璋冪敤”鍙兘鏄洿鐜板疄鐨勬柟妗堛侰++鏄竴闂ㄦ椿鐨勮璦錛屼笉鏂彂灞曠殑璇█錛屽嵆浣垮湪鏈鏂扮殑鎵樼鏃朵唬閲岋紝C#鎴愪負鏍囧噯涓繪祦錛屼絾C++/CLI浠嶇劧鏄墭綆¤璦閲屽姛鑳芥渶瀹屾暣鐨勮璦銆?/p>
In the fusion, or any other components or modules, how to retrieve the execution engine instance and how to generate such engine?
UtilExecutionEngine, implemented as COM object, support Queryinterface/AddRef/Release, and exposed via interface IExecutionEngine.
With SELF_NO_HOST defined,
BYTE g_ExecutionEngineInstance[sizeof(UtilExecutionEngine)];
g_ExecutionEngineInstance would be the singleton instance of current execution engine,
otherwise, without SELF_NO_HOST, the 'sscoree' dll would be loaded and try to get the exported function, which is named 'IEE' from such dll. Here, it is the well-known shim, in .net CLR, such module is named 'mscoree'. Further, if 'IEE' could not be found in such dll, system would try to locate another exported function, named 'LoadLibraryShim', and use such function to load the 'mscorwks' module, and try to locate the 'IEE' exportd functionin it.
It's very obvious that Rotor has implemented its own execution engine, but it also gives or make space for implementation of execution engine from 3rd party. Here, .net CLR is a good candidate definitely, Rotor might load the mscorwks.dll module for its usage.
PAL, PALAPI, for example, HeapAlloc, one famous WIN32 API, has been implemented as one PALAPI (defined in Heap.c), to make it possible that the CLI/Rotor be ported smoothly to other OS, such freebsd/mac os.
CRT routines are also reimplemented, such as memcpy, it has been implemented as GCSafeMemCpy
There're many macros in fuctions, such as SCAN_IGNORE_FAULT/STATIC_CONTRACT_NOTHROW/STATIC_CONTRACT_NOTRIGGER, they are for static analysis tool to scan, analyse and figour out the potential issues in code.
From view point of the execution model by CLI, the act of compiling (including JIT) high-level type descriptions would be separated from the act of turning these type descriptions into processor-specific code and memory structures.
And such executino model, in other word, the well-known 'managed execution', would defer the loading, verification and compilation of components until runtime really needs; At the same time, the type-loading is the key trigger that causes CLI's tool chain to be engaged at runtime. Deferred compilation(lead to JIT)/linking/loading would get better portability to different target platform and be ready for version change; The whole deferred process would driven by well-defined metadata and policy, and it would be very robust for building a virtual execution environment;
At the top of such CLI tool chain, fusion is reponsible for not only finding and binding related assemblies, which are via assembly reference defined in assembly, fusion also takes another important role, loader, and its part of functionality is implemented in PEAssembly, ClassLoader classes. For example, ClassLoader::LoadTypeHandleForTypeKey.
For types in virtual execution environment of CLI, rotor defines four kinds of elements for internal conducting,
ELEMENT_TYPE_CLASS for ordinary classes and generic instantiations(including value types);
ELEMENT_TYPE_ARRAY AND ELEMENT_TYPE_SZARRAY for array types
ELEMENT_TYPE_PRT and ELEMENT_TYPE_BYREF for pointer types
ELEMENT_TYPE_FNPTR for function pointer types
every type would be assigned unique ulong-typed token, and such token would be used to look up in m_TypeDefToMethodTableMap (Linear mapping from TypeDef token to MethodTable *)which is maintained by current module; If there it is, the pointer to method table of such type would be retrieved, or it would look up in the loader module, where the method table should exist in while it's JIT loaded, not launched from NGEN image;
And all the unresolved typed would be maintained in a hash table, PendingTypeLoadTable; Types and only those types that are needed, such as dependencies, including parent types, are loaded in runtime, such type is fully loaded and ready for further execution, and other unresolved types would be kept in the previous hash table.
棣栧厛錛屽唴鏍稿璞″彧鑳界敱鍦ㄥ唴鏍告佷笅鐨勪緥紼嬫墠鑳界洿鎺ヨ闂紝鍦ㄦ垜浠棩甯哥殑浠g爜涓紝鎵璋冪敤鐨刉indows API錛屾瘮濡侰reateFile, 錛堟敞鎰忚皟鐢ㄥ垰寮濮嬫椂鏄浜庣敤鎴鋒佷笅鐨勶級錛屼竴鑸兘浼氬湪ntdll.dll涓壘鍒板搴旂殑鍐呮牳鍑芥暟鎴栦緥紼嬶紝鎺ョ潃緋葷粺鍒囨崲鍒板唴鏍告侊紝寮濮嬭皟鐢ㄥ疄闄呭搴旂殑鍐呮牳鍑芥暟(KiCreateFile)錛岃繖涓椂鍊欐墠浼氬幓璁塊棶鍐呮牳瀵硅薄鐨勫疄闄呭湴鍧錛岀劧鍚庡緩绔嬩竴涓鍐呮牳瀵硅薄瀵瑰簲褰撳墠榪涚▼鐨凥andle錛屽茍鎶婂畠榪斿洖緇檆aller錛屽悓鏃跺垏鎹㈠洖鐢ㄦ埛鎬侊紱鍥犳錛屽浜庣敤鎴鋒佺▼搴忔潵璇達紝鍙涓斿彧鑳界煡閬撹鍐呮牳瀵硅薄鍦ㄥ綋鍓嶈繘紼嬩腑鐨勫搴旂殑Handle灝卞彲浠ュ鍏惰繘琛屾搷浣滀簡錛?/p>
鍏舵錛岃繖鏍風殑璁捐鏄嚭浜庡OS鏍稿績鏁版嵁緇撴瀯錛堝綋鐒跺寘鎷垜浠鍦ㄨ璁虹殑鍐呮牳瀵硅薄錛夌殑淇濇姢錛涘鏋滅敤鎴鋒佺▼搴忓彲浠ヨ交鏄撶殑鑾峰彇鍐呮牳鏁版嵁緇撴瀯鐨勫疄闄呭湴鍧錛岄偅涔堝浜庢暣涓狾S鐨勫畨鍏ㄥ拰紼沖畾鏄劇劧鏋勬垚寰堝ぇ鐨勯棶棰橈紱涓涓敤鎴鋒佺殑璇搷浣滃彲浠ヨ交鏄撶殑寮曡搗鏁翠釜OS鐨勫穿婧冿紝鑰屾湁浜嗚繖涓灞傜殑淇濇姢錛屽穿婧冪殑鍙槸褰撳墠榪涚▼鑰屼笉鏄暣涓郴緇燂紱
鎺ョ潃涓婇潰榪欑偣錛屼篃鍙互鐪嬪嚭錛屽唴鏍稿璞$殑濡傛璁捐杈懼埌浜嗘帴綰砄S鏈韓鐨勫鉤婊戞紨榪涚殑鐩殑銆備粠Windows 3.0鍒?5/98錛屼粠NT鍒癢in2k/XP錛屽啀鍒扮溂涓嬬殑Vista/Win7錛學indows鎿嶄綔緋葷粺鏈韓鍙戠敓浜嗗法澶х殑鍙樺寲鍜岃繘姝ワ紝閲囩撼浜嗘棤鏁扮殑鏂版妧鏈柊鏂規硶錛屼絾鏄畠鍩烘湰鐨勭郴緇熷簲鐢ㄧ紪紼嬫帴鍙o紝涔熷氨鏄垜浠墍鐔熺煡鐨剋indows API錛屽嵈騫舵病鏈夊彂鐢熷お澶х殑鏀瑰彉錛屽緢澶歐in 3.0 榪欎釜16浣峅S鏃朵唬鐨勭▼搴忎唬鐮佸彧瑕佸綋鍒濊璁¤鑼冪紪鐮佽鑼冿紝紼嶈淇敼灝卞彲浠ュ湪鏈鏂扮増鐨凮S涓婅繍琛屽椋烇紱鏄粈涔堝仛鍒頒簡榪欎簺錛熶篃灝辨槸鎵璋撶殑鏋佷負閲嶈鐨勫悜鍚庡吋瀹規э紝鎴戜釜浜鴻涓猴紝鎶婃搷浣滅郴緇熺殑閲嶈/涓昏鍔熻兘鎶借薄鎴愬唴鏍稿璞★紝騫墮氳繃涓濂楁瀬涓簊olid鐨凙PI鏆撮湶鍑烘潵錛岃揪鎴愪簡榪欎釜鐩爣銆?/p>
榪欐槸涓縐嶆洿楂樺眰嬈′笂鐨勯潰鍚戝璞★紝鎶婂疄鐜扮殑緇嗚妭錛屾妸緋葷粺鐨勫鏉傦紝綆鍗曡屼紭闆呯殑灝佽浜嗚搗鏉ャ備綘鍙璋冪敤CreateFile鍘誨緩涓枃浠舵垨綆¢亾鎴栭偖妲斤紝涓嶇敤鎷呭績褰撳墠OS鏄疻indows 3.0榪樻槸Win7錛岃幏寰楃殑Handle錛屼綘涔熶笉鐢ㄥ幓鍏沖績瀹冧互鍙婂畠鎵鎸囧悜鐨勫唴鏍稿璞℃槸Windows 3.0鐨勫疄鐜拌繕鏄疻in7鐨勫疄鐜般?/p>
Windows涓婃墍鏈夌殑綺懼僵鍑犱箮閮芥槸鍩轟簬榪欏閫氳繃鍐呮牳瀵硅薄姒傚康鎶借薄騫舵毚闇茬殑API鍩虹涔嬩笂錛孋OM/OLE錛岃繖涓簩鍗佸勾鍓嶉渿鎾兼х殑ABI鍜孖PC鑼冪暣鐨勬妧鏈鑼冿紝鍏朵腑寰堝鐨勮璁℃濊礬涔熸槸妞嶆牴浜庡唴鏍稿璞$殑璁捐鐞嗗康錛屽COM瀵硅薄鐨勫紩鐢ㄨ鏁板拰鍐呮牳瀵硅薄寮曠敤璁℃暟錛孖Unknown鍜學indows Handle(鍓嶈呮槸鎸囧悜鏌愪釜浜岃繘鍒跺吋瀹圭殑緇勪歡瀵硅薄錛屽悗鑰呭紩鐢ㄦ垨闂存帴鎸囧悜鏌愪釜鍐呮牳瀵硅薄錛岄兘鏄浜庢煇涓鏉傛蹇電殑涓鑷存ф娊璞¤〃榪?錛岀瓑絳夛紱
鍗佸勾鍓嶇殑.net錛屾湰鏉ユ槸浣滀負COM鐨勫崌綰х増鏈帹鍑猴紝鎶奀OM/OLE鐨勫疄鐜板鏉傛у皝瑁呭湪浜嗚櫄鎷熸満騫沖彴CLR閲岄潰錛岃屼粠榪欎釜铏氭嫙鏈虹殑寮婧愬疄鐜癝SCLI錛屾垜浠彲浠ョ湅鍒板ぇ閲忕殑COM鏈哄埗鍦?net鐨勫叿浣撳疄鐜伴噷闈㈣搗浜嗕婦瓚寵交閲嶇殑浣滅敤銆傚湪榪欎簺VM涓ぇ閲弒ymbol鏈夌潃COR鐨勫墠緙鎴栬呭悗緙錛孋OR鎸囦唬浠涔堬紵Common Object Runtime, 鍘熸潵CLR/SSCLI鐨勮璁℃濊礬涔熸槸鎶奜S閫氳繃铏氭嫙鏈篤M鐨勫艦寮忥紝騫墮氳繃common object鍚戝簲鐢ㄧ▼搴忔毚闇插姛鑳姐?/p>
灝忕粨涓涓嬶紝
OS鍐呮牳瀵硅薄API錛屼笁鍗佸勾鍓嶇郴緇熺駭鍒殑瀵硅薄鎶借薄錛?br>COM/OLE錛屼簩鍗佸勾鍓嶄簩榪涘埗緇勪歡綰у埆鐨勫璞℃娊璞★紱
.net/CLR, 鍗佸勾鍓嶈櫄鎷熸満騫沖彴綰у埆鐨勫璞℃娊璞★紱
鍐欏埌榪欓噷鍊掓槸寮曡搗浜嗘垜鍏朵粬鐨勪竴浜涙濊冿紝杞歡宸ヤ笟鐣屼竴鐩翠互鏉ュ闈㈠悜瀵硅薄OO鏄儹鐏湞澶╋紝鐗瑰埆鏄璦灞傞潰錛屼粠C++/Java/C#鍒癙ython/JScript錛屼笉涓鑰岃凍錛?/p>
浣嗘槸鎴戜滑鏈夋病鏈変粠鏍規湰鎬х殑璁捐鐞嗗康涓婂闈㈠悜瀵硅薄錛屽療綰抽泤璦浜嗗憿錛?/p>
濡傛灉鐜板湪璁捐Windows榪欏API鐨勪換鍔℃斁鍦ㄥぇ瀹墮潰鍓嶏紝浼氶噰鐢ㄥ唴鏍稿璞?Handle鏂規榪樻槸鐩存帴鎸囧悜OS鍐呴儴鏁版嵁緇撴瀯鐨勬柟寮忔潵鏆撮湶鍔熻兘錛?/p>
浠庝笁鍗佸勾鍓嶇殑榪欏API鐨勮璁′腑錛屾垜浠湡鐨勫彲浠ュ鍒板緢澶氥?/p>