能力值：
( LV9，RANK：170 )
|
-
-
2 楼
二进制与机器码相关联，比如intel机器可以装win和linux，但是系统不一样，文件格式约定不一样，加载、初始化方式肯定不同，简单举个例子：
win pe程序到了linux中，人家如何区分这一块01010101二进制哪里是数据哪里是程序代码，oep定位在哪里呢？
即使同样在win下，有时脱壳不对/更简单一点，同个程序，把eop搞错，不一样还是运行不起来？
乱说一气，为等大牛拍砖！！
|
能力值：
![]()
(RANK：1010 )
|
-
-
3 楼
可执行文件格式不同
1.因而在程序编译的时候需要用linux平台下的编译器，而不能在windows平台下编译完了直接移植。这里不包括java等脚本程序。
2.在执行时需要用特定加载器实现
|
能力值：
( LV2，RANK：10 )
在线值：
|
-
-
4 楼
我当初我也这样考虑过，但问题linux当初在什么样的编译器和平台下开发的，
我觉得这样的回答和理解不完全正确
编译后产生的.s级的汇编代码是否平台无关，产生的机器码又是否是无关的，最终产物的连接导致了平台相关性？
在这个上，我的思路有点乱
请高手给一个完整的解释，最好从编程实现的角度上考虑
两个不同的平台两种不同的文件格式
|
能力值：
( LV2，RANK：10 )
在线值：
|
-
-
5 楼
哥哥，你说话很逗，linux有EOP ,OEP我一直没仔细看，不知道有没，多少接触一点wine内核，没全搞懂，呵呵呵，确实如你所说，如何机器，计算机几乎都能装win,linux这正是我比较郁闷的地方，说什么编译器，加载器。。。。。。。。。。。有点石洞肥东的感觉，最好有个高手能给点什么能说明的资料看看，谢谢，molaichun@yahoo.cn，你可以带上纸片的砖头扔这里来。
|
能力值：
( LV2，RANK：10 )
在线值：
|
-
-
6 楼
楼主：
我也在想这个问题，而且在实际的操作中遇到了麻烦。
过程是这样的，首先在linux下用mips-gcc编译app.c得到了ELF格式的可执行文件app_elf，接着用工具把ELF格式的转换成PE格式的app_pe，然后加载到MIPS嵌入式板子执行（load也是自己写的），现在能够正确找到了app_pe的EntryPonit，出现了两种情况：
1 正确执行，无函数调用和全局变量；
2 如果app.c的main函数有子函数调用或者是访问了全局变量，程序就不能正常执行，或者说是找不到子函数，也找不到全局变量；
这是实际情况，大家一起讨论下。。。
|
能力值：
( LV2，RANK：10 )
在线值：
|
-
-
7 楼
我得想想你这个问题,但我不介意讨论,你加我的QQ:770308625
这个问题理论上比较复杂,不知道你有没有看过wine这样的东西
"首先在linux下用mips-gcc编译app.c得到了ELF格式的可执行文件app_elf，接着用工具把ELF格式的转换成PE格式的app_pe"
load从概念上将只是拷贝kernel到指定内存地址和elf,pe没有关系,(并初试硬件.....)理论上可执行文件的正确执行是加载器的问题
这个大家可以共同讨论
|
能力值：
( LV2，RANK：10 )
在线值：
|
-
-
8 楼
相同点：
如果都在intel的CPU上，那么他们的机器指令应当是相同的，也许这点让大家迷惑！
不同点：
1. 可执行文件的格式不同，因此跨平台装载时，不能正确载入。上面有人说过
2. 系统呼叫函数不一样，在DOS下，可以说成是中断不一样，这也可以说明为什么DOS的程序不能在LINUX上运行。
举个例子：
Windows下程序的退出一般用ExitProcess，但在linux下，就没有这个系统函数。所以Windows程序不能直接在Linux下运行。
如果能解决文件格式及载入问题（这个貌似好解决），还能解决系统呼叫函数的问题（这个难），就可以通用。
Wine是不是就是这么做的？
|
能力值：
( LV2，RANK：10 )
在线值：
|
-
-
9 楼
兄弟先说点不同的
dos好象也调用了bois好象在一些基层方面dos和bois是互相合作的
而linux几乎抛弃了dos和bois,因为引导是linux自己的bootloader 负责的
哎呀感觉头都大了
反正从上边诸位的讨论来看,一部分是正确的
linux只实现了相当的一部分intel cpu
实现不管linux的体系实现看,理论上window和linux在机器码方面是一致的,主要可能是elf,pe结构的不同而导致加载器的加载和读取执行上有些不同
|
能力值：
( LV2，RANK：10 )
在线值：
|
-
-
10 楼
“linux只实现了相当的一部分intel cpu” -- 这句有问题呀？不知道你指的是什么？或者说你概念不清楚
windows下import 函数，在Linux下也有，我叫它系统函数，即库函数，这部份完全不一样，你叫程序如何执行，文件格式是小事，外部的库函数是大事，无法解决的。
如
windows有kernel32.dll user.dll
Linux这有 libc.so libstd++.so ...
|
能力值：
( LV2，RANK：10 )
在线值：
|
-
-
11 楼
“如果能解决文件格式及载入问题（这个貌似好解决），还能解决系统呼叫函数的问题（这个难），就可以通用。
”
文件格式和载人都解决了，只是呼叫函数还没有，具体是这样的：
用mips-gcc编译得到的可执行文件的函数调用是绝对地址调用，而且没有.rel重定位段，所以转换为ＰＥ格式时，仍是绝对地址调用，这样在裸系统（嵌入式）下，此时的绝对地址就出现了问题，我想如果最初得到的函数调用如果是相对地址，或者是存在.rel段，那么在转换为PE格式时，就可以在重定位时把函数调用的地址转换正确了。
个人的想法，还没验证成功。。。
|
能力值：
( LV2，RANK：10 )
在线值：
|
-
-
12 楼
楼上的两位说的都不错，如果要实现的话，可以通过某种方式去实现，很难说的，有空加我QQ：770308625讨论下
|
能力值：
( LV2，RANK：10 )
在线值：
|
-
-
13 楼
调用操作系统的api不同，除非是纯asm并且没有操作系统的int调用，没有全局变量和类的地址空间的分配，这些与操作系统调用有关（或者说是dll文件之类）的调用，是可以跨平台执行。
程序的本质是二进制，执行也是根据二进制执行的，这些二进制的执行过程基本是与系统无关，可是一旦使用操作系统的loader加载器或者api或者int之类的话，就与操作系统就有关。
我之前写了一个os的boot loader这个是和系统无关的，并且是在系统启动之前运行的。这些代码的执行与操作系统无关的，也就是跨平台的代码。这些代码可以用masm也可以使用nasm或者其他的汇编语言的编译器连接生产二进制文件。代码的编写不受平台的限制，这类似dos下com格式。
以上是个人的简单看法，有不对的地方希望指正！
希望大牛们给与指正！！！
|
|
|
|
