看了以纯API写的WIN32窗口程序  生成的EXE文件是很小  可是好像CPU利用绿大得不得了 如果按照这种逻辑,每个WIN32程序都至少有一个消息循环,那问题出来了
1.如果程序稍复杂一点消息循环结构就很长,假如消息循环在处理前一个消息还没有处理完, 而第二个消息产生了,这也是耍要处理的消息,可是由于第上一个消息处理模块太长还在运行中.那就就坐导致,第二个消息丢失,被忽略了,这怎么了得.而DELPHI生成的程序却没有这样的问题,难道VCL的底层实现机制不同
2.如果每一个程序都有一个消息循环的话,那就不可想像了,在程序退出前,这个程序可以看作一个死循环,而就这么一直循环前的程序是相当占CPU资源,那可以想像WINDOWS默认运行那么的程序,有多少个这样的循环,汗!!而事事并非如此,如果什么也不操作WINDOWS的CPU利用率是很低的,这就是问题,难道书上提供的那个WIN32有基础框架只是教程而已,而真正的WIN32程序,不是遵守那样的框架来写,我COPY了纯API写的WINDOWS程序可程序是正常,可是CPU占用比较大,哪怕只是一个窗口,而DELPHI生的一个并没占用多大资源,这让我联想到难道DELPHI底层不是用纯API那种框架写的,一想到一个小程序里面都有一个循环不停的跑,真不是滋味,哪位好心让给我讲讲啊
如果问得太弱智不要笑话

解决方案 »

  1.   

    关心一下啊,delphi的程序也是一个消息循环,你可以看一下tapplication的run过程。
      

  2.   

    1.可是由于第上一个消息处理模块太长还在运行中.那就就坐导致,第二个消息丢失,被忽略了,这怎么了得.
    windows有一个消息队列,如果上一个没有处理完又来了一个,那么第二个就会放入队列中。2.如果每一个程序都有一个消息循环的话,那就不可想像了,在程序退出前,这个程序可以看作一个死循环,
    这个对。》》就这么一直循环前的程序是相当占CPU资源,
    这个不对。一直循环不见得就占CPU,如果没有消息来,你调用GetMessage,系统发现你这个线程没有消息,直接就将这个线程置为等待状态,在下次消息到来前,根本不需要给它CPU时间。