要解决操作系统的垄断问题,首先要开放API

不同视角、不同观点、深度探讨,禁止人品和道德攻击
头像
ving
帖子: 3741
注册时间: 2007-07-29 16:47
来自: 地精魔法学院
送出感谢: 0
接收感谢: 0

#31

帖子 ving » 2007-09-09 10:32

晕,又顶上来了。
猛将兄可能是因为API说这句话的吧。因为win32 API要依赖系统来解释,比如说转换为native API 通过SSDT指向服务函数来执行实际操作。不过我觉得exe文件里面应该还算是机器码吧。
我所希望的其实是23楼描述的情景,其他的争执就免了吧
头像
猛将兄
帖子: 2052
注册时间: 2005-10-19 17:33
送出感谢: 0
接收感谢: 0

#32

帖子 猛将兄 » 2007-09-09 10:55

vupiggy 写了:
猛将兄 写了: 我想楼主可能不太懂可执行文件是怎么回事。其实现代操作系统支持的可执行文件,都是一个中间介质,不包含直接的机器码。由OS解释之后执行。微软用的是PE格式,Unix是ELF格式。格式都是公开的,就看你拿到之后怎么执行了
您就别急着说别人不懂了,您说的也不咋对,甚至可以说是谬之千里。

可执行文件不包含直接的机器码?大错特错!java的.class文件才是像你说的那样不包含机器码,其行为由jvm解释执行,PE和ELF都包含了完整的机器码!用objdump工具dump一个可执行文件出来,看到的那些什么push %epb...不是机器汇编指令是啥?这是objdump将机器码翻成汇编语言的结果,在可执行文件里就是如假包换的机器码0x55(objdump的输出中的一栏里就有机器码)。内核解释,还要把它们解释成什么?

而且解释ELF头部的也不是什么内核,是loader!当loader将可执行文件装载入内存之后(也就是execve之后,也就是jump到正文段的第一条指令之后),程序的执行也没loader什么事儿了,ELF头部无非就是为了记录一些诸如这个程序是静态链接还是动态链接一类为创建程序执行环境以及虚存布局的信息,可执行文件余下的那些text段的内容不是机器码是什么?这些可都是可以被cpu从内存中装载进来而直接执行的,何来内核解释和执行?应用程序和内核交互的地方就是系统调用,这只是说这个时候cpu执行内核的一段代码于当前进程上下文上,也谈不上是内核执行了应用程序。内核说白了就是个调度器和中断处理器,让它去解释这个解释那个,把应该是用户空间程序做的是强加给内核,想累死它呀:P

开放所有的api当然是有意义的,这样有利于开发可移植性强的应用程序,当然不是一次编写,到处执行,而是一次编写到处编译。想当年酷爱抄袭的瘟到死的开发者们照抄了苹果的几乎所有窗口系统的API,诸如创建窗口等等函数,连参数个数和类型,语法语义都一模一样,一个结果是,微软的office可以几乎不作改动就在苹果系统上编译过,略加改动就可以跑。

另外一层意义就是开放了全部的api(当然不止是系统调用,还有窗口系统,网络组件的),看清楚是全部的,目前你能看到的根本不是全部的,否则怎么会有诸如undocumented windows nt这样的书存在?大大有利于其它应用程序开发商开发更好的基于瘟到死的软件而不怕被微软捏着脖子,避免了微软利用操作系统开放商和应用程序开发商双重身份来进行不正当竞争。楼主的提议很对!!!不过对于这种善于钻法律空子的公司,也许只有拆分了它才可能实现吧,吼吼。
谬以千里你个头。
push xxx这种东西就是可执行的机器代码了?用PEViewer可以看到的应该是push DWORD xxxx这种东西。的确和汇编很像,但又不完全是汇编。因为PE的作用就是Portable,所以这只是一个中间格式。任何嵌入汇编的系统都在进入汇编的时候,把入口地址设置好,现场保护好,就交给内核去执行了。你解析java的class的时候,照样能看到push xxx,这就是机器代码么?呵呵。
可以说很接近机器代码,但还不是机器代码。真正的机器码是dos时代的com文件,那是机器代码的精确映射了。
争这个有什么意义?通过PE还是可以看到一些没有说明的syscall,也能猜出来微软做什么。这样对于毛德操老先生的兼容内核是有很大意义的。可是如果我们只要兼容win32 API,那么其实只要实现MSDN上所有描述的接口就可以了。而兼容内核的重要意义在于可以实用无数只支持windows的驱动了,也就是通过DDK开发的驱动程序。其他的我就不懂了,就不来胡乱放蹶词了。
vupiggy
帖子: 89
注册时间: 2006-03-19 18:25
来自: FZ->TJ->PEK->AMS->MTL
送出感谢: 0
接收感谢: 0

#33

帖子 vupiggy » 2007-09-09 13:17

偶可从来没说ELF全部都是机器码,只是包含了无须内核再去解释的机器码,反编译出来的java class的里的push XXX是jvm的指令,相应的二进制是jvm的byte code(machine code? ;)), 但是用hexedit看一个可执行文件的正文段部分,对应push %ebp的一段码可是货真价实的intel指令0x55,其它的不说了,我去年crack一个mac底下一个软件就是先反汇编出来查看而后用hexedit打开可执行文件同时对照ppc的手册找到并修改某些字节完成的,那不是机器码是啥?os的byte code?别逗了,如果是os解释的,那么这个软件在intel的linux上根本就可以像java那样直接执行,但是这可能不?

man objdump
...
-d
--disassemble
Display the assembler mnemonics for the machine instructions from objfile.
...
不是operting system instructions

从解释ELF,生成进程映像到加载到内存里去全过程压根没内核什么事儿,至于内核怎么调度一个进程,懒得再多说什么,睡觉去了。
回复

回到 “深度PK版”