windowless的致命缺点

[wylongg]

小弟最近研究界面实现技术，过年也没闲着，google了整个网络。弄界面也弄了几年了，做比较炫的界面，也没什么问题。最近公司年后要启动一个项目，项目非常复杂（一套卖几百万），要使用文档/视图结构，但一定要做深层次美化。以前一直用mfc做界面，使用gdi或gdi+贴图，用ini或xml配置界面。常用控件的美化也实现了好几年了，都比较稳定，个别特殊控件，实现一下也没什么问题，由于这个项目周期很长(两年多)，正好借新项目，好好总结一下目前比较常见的界面开发技术。今天先总结一下windowless的致命缺点，过两天总结它的优点，和其它技术的优缺点。再提一句，我们的项目是使用wpf开发，也是windowless，但与我下面所说的windowless是两回事。

windowless或者称handleless，也就是无句柄窗口，在设计和实现的时候，每个控件都自己实现，最后画到父窗口中。另一个伪windowless是用标准mfc控件，然后通过hook或其它远程线程注入等技术，让spy++等软件，看不到窗口句柄。这主要是为了防止盗号木马通过edit窗口句柄，盗取用户名和密码。好了，费话少说，下面是小弟总结的windowless的缺点，如果要使用这类界面开发技术，要么有源代码，要么是自己公司实现的，否则风险非常大。

1、无窗口句柄，所有您以前关于“窗口”概念的知识都白学了。您将不可能使用::ShowWindow(hWnd, SW_HIDE)来隐藏一个窗口，也不能使用::MoveWindow来移动一个窗口。
2、所有您以前学习的关于“消息”的知识也作废了。您不可能使用::SendMessage(m_hWnd, WM_SETTEXT, 0, (LPARAM)_T("Hello world"));来设置窗口标题。
3、如果您的程序已经写好，需要花费比开发程序还要长的时间来移值到DirectUI界面上。
4、重新学习一套系统接口和概念，如果不是国际知名的大公司的windowless产品、这些知识对您的职业生涯没有太多好处，反而浪费了您的时间。
5、如果不是国际知名公司的产品，产品的稳定性和可发展性无法保证。
6、如果您的功能层代码需要与UI层交互，例如，要向UI窗口发送消息，那么您的功能层代码也要做相应的修改，所以windowless类的界面库，不仅仅影响UI层，还影响功能层。
7、窗口的剪裁、激活、绘制、消息循环等等全部需要模拟。
8、除了极个别程序，全球几乎所有软件产品都使用win32布局方式，无论在技术储备，兼容性和获得帮助方面，标准窗口观念都有得天独厚的优势。
9、无法对编译好的exe进行后期汉化、编写插件等常规操作。运行中的程序也无法响应其它程序发来的标准消息，例如隐藏控件、设置控件文本等。
10、不支持MFC的文档/视图框架。
综上、windowless比传统win32窗口树形结构有很多局限性和不确定性。

[xblan]

游戏都是无句柄窗口。windowless这种技术，不新鲜吧。。。

[BruceZhaoZPZ]

[Quote=引用 209 楼 xblan 的回复:]
游戏都是无句柄窗口。windowless这种技术，不新鲜吧。。。
[/Quote]
我反问一句，绚丽而逼真的游戏界面用传统的界面技术能轻易做出来么？

[xblan]

[Quote=引用 210 楼 brucezhaozpz 的回复:]
引用 209 楼 xblan 的回复:
游戏都是无句柄窗口。windowless这种技术，不新鲜吧。。。

我反问一句，绚丽而逼真的游戏界面用传统的界面技术能轻易做出来么？
[/Quote]

为什么要这样问我呢？游戏界面的传统技术，是什么技术？
我只能回答你，绚丽是美工的事。
现在流行的directUI也就是把游戏中用到的技术，拿来到桌面软件上了。

[createhebe]

[Quote=引用 146 楼 jameshooo 的回复:]
有些人说我喜欢高高在上地批判别人，虽然我还算不上“高手”，不过我还真的喜欢批判一些人，这些人自己没做过却喜欢引经据典地评论某个东西（特别说明：楼主不属于这些人），如果拿不出自己的观点，建议还是问点技术问题更实在，或者顶顶楼主的帖。

很多人可能会觉得我思想守旧，抱着老东西不放，接受不了新事物，这个误解太深了。比如我很不喜欢.NET，不喜欢WPF，这是真的，打死我也不愿意做一个.NET程序给别人……
[/Quote]

你看，你又来说教。中国最缺乏的就是脚踏实地的程序员。飞信做的烂不是因为.net，因为程序员代码写得烂的可以，在中国，程序员很多，靠谱的程序员很少，大部分都在网上抄抄代码，何其可悲，更正一下，飞信是基于Winform的，不是WPF。
Windows 8中将提供类Silverlight的UI子系统，Windows Phone采用类似SiverlightUI子系统如果你真的如你所说.net很了解，你就知道Silverlight和WPF的历史和渊源，既然微软敢于把最重要的两样东西押在这个上面，自然有他的道理，是否喜欢是你的个人爱好，但是你不应当带着偏见批判WPF。

WPF启动慢因为.net框架的问题，启动一次之后第二次启动速度就会加快，因为系统会缓存程序集。
WPF启动速度优化有很多方式，比如Lazy加载等等，或者自承载CLR，使用Windows API展示一些让用户不会厌烦等待的画面，当然，这也是权宜之计。
优化过的WPF程序CPU占用率在10%左右，包括降低默认帧速，减少BitmapEffect等。
WPF使用DirectX进行渲染，他给你提供呈现足够绚丽的界面的能力，平滑动画等等。然后你用WPF的效率问题来说WPF烂，那么你用一个效率高的框架来实现这些功能好吗？
WPF在效率和效果中做了权衡，没有人会因为一个游戏太炫自己的电脑跑不动就骂“什么JB游戏，烂游戏”，同样，你做出了之前难以企及的动态绚丽界面，发现运行慢，你为什么还要埋怨“什么JB WPF，烂框架”？

[createhebe]

[Quote=引用 158 楼 jameshooo 的回复:]
引用 157 楼 wylongg 的回复:

其实，微软出个非.net的wpf就好了。可惜了了。


对微软来说，做一个NATIVE-WPF易如反掌。蒋晟大大也说过，微软内部也讨论过这个问题，不过最终放弃了。这个可以理解，WPF是.NET的杀手锏，如果把这个杀手锏转交给非托管语言，对.NET战略是致命的。我还真想知道，如果没有WPF，还有多少人会选择.NET。讨论这个没有意义。

还……
[/Quote]

有Native WPF的，不过没有提供WPF封装得那么好的类库和框架，但是一切核心功能都有开放的C++接口，msn live 2011就是在此之上开发的。

[createhebe]

[Quote=引用 223 楼 xonln 的回复:]
WPF, WINFORM是用来学习的, 不适合用于商业开发,源代码可以相当的容易反编译的...
MFC是商业级的桌面开发, 比WPF,WINFORM功能强许多,只界面的是标准.不容易被反编译
[/Quote]

有种东西叫代码混淆，MFC比WPF，winform功能强很多？噗……不和你争了……

[wylongg]

[Quote=引用 229 楼 createhebe 的回复:]
引用 158 楼 jameshooo 的回复:
引用 157 楼 wylongg 的回复:

其实，微软出个非.net的wpf就好了。可惜了了。


对微软来说，做一个NATIVE-WPF易如反掌。蒋晟大大也说过，微软内部也讨论过这个问题，不过最终放弃了。这个可以理解，WPF是.NET的杀手锏，如果把这个杀手锏转交给非托管语言，对.NET战略是致命的。我还真想知道，如果没有WPF，还有……
[/Quote]

我是很看好wpf的。从代码风格，到编程习惯，都和mfc有很多区别。当初学wpf时（大约六七年前，那时还不叫wpf，也没有中文文档），就感觉非常吃力、与我固有思维完全不同，也比较排斥，后来越来越觉得wpf是非常先进的，国内一些做windowless界面库的，往往号称是微型wpf，基本是往自己身上贴金，与wpf完全粘不上边。

[hack517]

没有完美无缝的事物！总有缺点。重要的是总结缺点，解决缺点！

[dungeonsnd]

能否这样理解:

传统句柄式的窗口被OS层管理，而OS把这些看似一层层的窗口进行了Windowsless化，把按照Z-order进行计算得到一个bitmap，然后把这个数据发送给显卡驱动，让它把这个位图显示出来。

而现在比较流行的无句柄式的窗口，貌似要推翻微软从DOS之后一直延续到Win7的所谓"Windows"，也就是操作系统的GUI是许多的window来管理和操作。 对开发者来说就是把以前的由OS来做的事取出由自己完成。确实麻烦了一大堆！ 自己把无数的窗口和控件先绘制成位图送给OS，OS直接送给显卡驱动。

句柄时代一个控件对应一个类的实例，所以用很多时可以会多点内存吧。不过编程比较容易。无句柄式编程目前来说不开放，所以太麻烦，而且也许可能速度会慢点吧(猜测)，因为以前是由内核把位图数据计算出来，而现在由用户层来计算。

[dungeonsnd]

推动窗口时，
QQ2010反应把08版慢多了。
迅雷最新版更是慢了一大截，所以一直使用thunder 5.
Kugou也比08版的有点慢。

windows下有用速度来换取美观的嫌疑。

[niatguomin]

最近有个项目，界面也是使用windowless，很复杂，很繁琐。

[xiaosa98]

空战游戏1945源码空战游戏1945源码空战游戏1945源码空战游戏1945源码空战游戏1945源码空战游戏1945源码空战游戏1945源码空战游戏1945源码空战游戏1945源码空战游戏1945源码空战游戏1945源码

[wyx100]

学习一下，还没接触过windowless技术

[xuweiibm]

这个技术文档不错。我测试了。确实是很好

[蒋晟]

首先我说一下，所有基于CPU的绘图方式，比如GDI、GDI+，统统都要被淘汰。目前CPU的频率已经到瓶颈了，受工艺限制，GPU频率的增长速度大大多于CPU频率的增长速度，而且GPU有个好处是访问显存不用走龟速总线，所以不用视频加速的程序会有越来越大的劣势。

MFC 10 SP1增加的Direct2D类就是为基于GPU的界面而设计的。

[jameshooo]

[Quote=引用 243 楼 jiangsheng 的回复:]

首先我说一下，所有基于CPU的绘图方式，比如GDI、GDI+，统统都要被淘汰。目前CPU的频率已经到瓶颈了，受工艺限制，GPU频率的增长速度大大多于CPU频率的增长速度，而且GPU有个好处是访问显存不用走龟速总线，所以不用视频加速的程序会有越来越大的劣势。

MFC 10 SP1增加的Direct2D类就是为基于GPU的界面而设计的。
[/Quote]

蒋大侠难得现身，可惜帖子已经结了，怕是没多少人看了。

GPU确实是个好东西，要不然也设计不出WPF来。WPF也真的是一个好东西，很多类库的组织方式都成为我模仿的对象，少走好多设计弯路。看它的3D、动画类库，马上能猜测出它的设计思想和实现方法，照葫芦画瓢再实现一次，其实代码量很小的。当初很希望微软开放milcore，发现没希望，干脆自己设计3D框架，其实没有任何难度，重要的是设计思路要合理，中间的难点估计是如何把整个3D体系对象化，以及如何把2D/3D完全混合在一起。

Direct2D早出来就好了，现在还不能广泛地推广它，毕竟平台限制很严格，所以暂时还不太敢用。估计大众型软件都不敢用它，也是因为平台适应性问题，DX10、DX11也是一样的。

不知道蒋大侠对于用跟WPF相同的技术实现一套微框架有何看法。当然SILVERLIGHT本身也是一套简化版的WPF，无需.NET环境，自身大小不到10M，但运行性能有点差强人意，稍复杂一点的3D场景或者动画都不够平滑，比FLASH还差得远。

[Dnkuni]

[Quote=引用 233 楼 dungeonsnd 的回复:]

能否这样理解:

传统句柄式的窗口被OS层管理，而OS把这些看似一层层的窗口进行了Windowsless化，把按照Z-order进行计算得到一个bitmap，然后把这个数据发送给显卡驱动，让它把这个位图显示出来。

而现在比较流行的无句柄式的窗口，貌似要推翻微软从DOS之后一直延续到Win7的所谓"Windows"，也就是操作系统的GUI是许多的window来管理和操作。 对开发者来……
[/Quote]
就是这样子了。
windowless和传统的窗口的区别其实就两点：
1.传统的窗口可以使用系统的消息机制对“窗口”进行操作。
2.传统的窗口中各个“窗口”的覆盖关系由操作系统计算，而windowless则自己计算。
windowless的价值只在于提高安全性而已，至于界面好不好看跟是不是windowless有个屁关系。

[蒋晟]

>不知道蒋大侠对于用跟WPF相同的技术实现一套微框架有何看法
市场很小，毕竟，不支持WPF而必须使用本地代码的场合，大部分是在游戏行业，而这个行业里面的DirectX引擎已经很多了。

[hj_ddvo]

我觉得windowless前面要加个MFC，WPF也是有自己的“WINDOW“，只不过跟MFC里定义的WINDOW的概念不同而已，自己实现的界面库也可以选择兼容目前已经广泛使用的MFC界面开发习惯，在自己开发的界面库里实现SHOWWINDOW，SENDMESSAGE等MFC标准函数也绝非难事，我目前就正在做这事。

[guxingyun]

我将搞一个directui出来 拭目以待