spaceOS能运行windows和linux的软件，这样设计的利弊是什么。
玉兔号的 SPACEos 操作系统，系统架构是怎么设计的？
SPACEos和Linux和Windows的架构关系是什么样的？兼容Windows和Linux软件软件是否有可能么？怎么实现的？
–
航天五院的人敢不敢站出来说SpaceOS没抄一行VxWorks的代码？不管是GPP/MSP还是653或者Cert或者551，敢说一点没抄？三个字：不要脸。
传说SpaceOS第一版只有8000行代码，这点货就想兼容Windows和Linux？POSIX兼容都不止这么多代码。
完整兼容Windows需要支持所有Windows API，ReactOS多少行？都不敢说完全兼容Windows。Linux内核又有多少行？
一个完整的OS至少要有个调度器，有硬件管理，有内存管理，还得有一个基本的BSP，可以不要文件系统，可以不要libC，甚至可以不要时钟，但谁 敢说这样的系统兼容Windows和Linux？难道兼容的意思是只支持malloc和free吗？就这俩函数实现出来也得几百行呢！
听说SpaceOS是在天宫一号上运行过，天宫一号上用的SPARC，主频也就10-20MHz的水平，这硬件能跑Windows？恩，也许能，Windows3.2也许可以，但可惜不支持SPARC这个指令集。
吹牛的、不懂技术就乱说的记者退散吧，搞出这玩意一点都不值得骄傲，不要让人看笑话就好了。
最后，请自行百度/google ReactOS和Linux内核，知道这些玩意做的多大了再来说兼容的问题。
——————-问题被修改了，那么我继续补充——————-
SpaceOS跟Windows或者Linux没有太大关系。航天器用的系统是最重要的指标是实时性，而Windows和Linux都不是实时操作系统（RTOS）。
实时操作系统重要的指标包括：对中断响应速度（一般要求是ns级），Windows和Linux关中断的时间都太长了（都达到ms级的水平），不适合航天器使用。
实时操作系统调度策略都是抢占式的，Windows和Linux都不是抢占式的系统（补充：Windows是不完全抢占式系统，有防饥饿机制，Linux在2.4之前不是，2.6以后据说已经是抢占式的）。
跟SpaceOS同类的系统大多数人平时很难接触到，比如ucos，nucleus，threadX，以及VxWorks，这些系统一般用在工控的领域比较多。
另外，航天器的CPU一般都很弱，也不是intel或者amd的，甚至也不是arm的，见过最多的是SPARC，然后还有PPC/MIPS的，这是 因为太空中有辐射，要抗干扰。主频一般是10MHz到几百MHz之间，超过100MHz的都和NB，天宫一号好像是20MHz的水平。
内存和外存基本上都是KB-MB之间的，NASA能弄到上GB，已经很厉害了。天宫一号外存是256K-ROM，这个配置想跑Windows是不可能的，Linux应该也不行吧，我没试过Linux能不能裁到这么小。但前面我说的那几个不知名的系统都可以做到。
我说SpaceOS有极大的可能是抄VxWorks的，这是很可能的，毕竟VxWorks是最成熟的，航天器上用的最多的系统（另外，从歼十，到东风系列导弹，基本上也是VxWorks的天下），不要以为中国人写操作系统的能力很强，其实很弱，这是事实。
要不然，有谁是航天五院的人站出来，咱们可以拿源码对比一下差异度。
所以SpaceOS跟Windows和Linux没什么关系，应用场景不同，没办法对比。
—————–再说兼容Windows和Linux的问题—————–
首先，看什么级别的兼容：
1、代码-应用级，就是说代码拿到两边都可以正常编译，生成可执行文件并正常执行；
2、二进制-应用级，就是说一个二进制包（Java的那种不算），不管Windows或者Linux都可以执行，不需要任何改动。
3、脚本-应用级，就像Java这种，还有perl脚本什么的，这种很简单，不讨论。
4、代码-驱动/内核级，就是驱动可以跨平台编译并正常执行。
5、二进制-驱动/内核级，就是驱动的二进制包可以直接正常使用。
6、虚拟化技术的兼容。
一条一条的说：
第一类：比较容易，用宏隔离或者使用POSIX兼容的代码就可以，不少开源软件都是这么做的，困难程度一般。
第二类：非常困难，我见过有人讨论过，主要问题是Windows的可执行文件结构是PE结构，而Linux是ELF结构，两者差异太大，但是似乎有大牛实现过（记忆不是很清楚），困难程度非常高。多数人也不会这么做。
第三类：非常容易，没有讨论价值，大多数跨平台软件都是这么实现的。
第四类：有一定困难，因为Windows内核驱动和Linux内核驱动的API差异非常大，运行模式、内存模型、中断处理……都不一样，很少见到有人做这些都兼容的代码，一般开发都是分别开发两个驱动。
第五类：非常困难，这不仅仅是要克服PE结构和ELF结构的差异，还要克服两个系统的内核API差异，几乎可以说是做不到的。
第六类：常见的有hyperviser这种技术，但实际上是两个不同的系统，从道理上谈不上兼容，只是两个系统运行在一个平台上，类似虚拟机技术，同时这种技术会有硬件资源的损耗。
以上是六种方式的分析，跨平台兼容比较容易，但代价一般都是规模比较大，在航天器的低硬件配置下，基本没人会搞跨平台，因为紧张的硬件资源根本不够跑那么复杂的东西，再说架构都不同啊。
以上说的跨平台都指在同一个硬件架构下，一般都是x86架构，想要跨硬件架构的还是不要想了，代码级、脚本级有可能，二进制没有可能。
最后再次强调一下，航天器用SPARC/MIPS/PPC的CPU比较多，基本没见过用x86平台的（也就是intel和AMD）
——————继续说OS兼容性——————
有人说了用Linux+wine，其实Windows+cygwin也勉强算，ReactOS也算兼容WINNT内核，但应该归属于独立的OS，另外，众多的虚拟机算不算？还有硬件虚拟化？我觉得可以算，也可以不算。
Windows里也有子系统的概念，理论上说，在应用层设计一个完全兼容Linux的子系统是有可能的，无非是工作量的问题，但是不管是Linux on Windows 还是Windows on Linux，效率是一个问题，毕竟API都是虚拟化的，不是系统原生接口，效率比原生接口差。
更多的软件是使用JVM这种非硬件编码来实现跨平台。
最后，强调一点，RTOS里跑Windows或者Linux的软件意义不太大，并且航天器的配置太低了，根本跑不动虚拟机（或者虚拟化）软件。
—-
问题改拉。。原问题是spaceOS能运行windows和linux的软件，这样设计的利弊是什么。
以下是修改后的答案，我以民科的身份回答，非正宗专业人士。
spaceOS查不到什么公开的信息，没办法评价架构的区别。如@时国怀所说，很可能是个RTOS，这和Windows/Linux完全不是一类操作系 统。通俗来说就是RTOS需要的是在一个确定的时间范围内必须对信号给予相应。否则会发生探月器遇到个坑，但是因为后台在下a片拖慢了相应速度没有及时调 整体位，于是探月器被坑了。
spaceOS这样的环境下想要兼容linux和windows，唯一的可能是有些代码希望重用，不希望自己重新写。我猜测这样的系统，至少也会有一套某 语言的编译环境（很可能是C），因为直接写汇编是很费力不讨好的开发方式。这种情况下，假设希望重用的是个库，比如视频图像压缩库，用来拍照之类的软件可 能会用到视频压缩解压。最经济的选择不是让这个库的二进制代码直接copy到spaceOS就能用，而是选择把源代码重新以spaceOS为目标平台编译 一遍。另外的可能是实现某些语言的运行环境（比如JVM或者动态语言的虚拟机）。这样这些语言对应的软件有可能可以直接运行（但稍稍复杂的也很难直接拿来 就跑）。
这些情况下，spaceOS即便能运行上述软件，也不能说和spaceOS能兼容运行windows/linux软件。因为windows/linux本 身也都能做到上面说的事情，但是我们从来不会说他们能互相兼容。而且这种案例在spaceOS的环境下也适用与很少的一部分软件，因为跨平台本身就是一个 很不稳定的因素，探月器需要的稳定程度不可能允许引入多少不稳定。顶多是一些经典的与硬件和系统功能无关的算法库被重用。如果你想要跑迅雷（哪怕是迅雷迷 你）？那sorry了。
再说一个可执行文件拷贝来直接能运行的情况，这是很难的。举例来说，linux上有一套wine系统，能运行windows程序。但是wine背后重新实 现了大多数windows的核心库，并重新在linux上实现了一套windows的程序载入机制，比如程序的头部格式不同需要特殊处理，linux没有 windows的dll，需要特殊处理，注册表在linux上没有需要模拟（也许还实现了COM相关的基础架构，毕竟COM在windows上无处不 在）。这里的工作量无法统计，而且很多软件无法正确运行，毕竟wine不是windows。且不说是否在RTOS上能否做相同的事情，对于spaceOS 的情况这种工作毫无意义，毕竟我们不会在spaceOS上跑QQ和迅雷，花这些时间不如多测试系统的稳定性保证探月器不掉坑里。
兼容其他平台的程序最大的动机是重用代码而不需要软件开发商重新开发一套对应操作系统的版本。以spaceOS的情况，探月器并没有多少通用的需要重用的程序（一切都是为探月工作特别制定开发的），花功夫去搞兼容，意义可以忽略不计。
–
RTOS是肯定的.估计是类似vxWorks之类的,搞不好是抄一遍把函数名改得高大上.至于windows和linux,实时性不过关,估计不能
这种宇宙级的控制设备实时性要求多高啊…
工业控制领域的操作系统很多哦,别老把眼光放在win和linux上
–
操作系统肯定是rtos,不会去兼容什么windows, 抄没抄
vxworks不确定，rtos 本身并不难写，有些甚至连虚拟地址空间都不支持，windows和linux才复杂，我相信中科院那些搞龙芯的写一个出来并不难。现在国产的rtos也很 多，当然多少都有开源rtos的影子。另外听说vxworks并不是最强的，美国国防部用的greenhill rtos才最牛逼。
玉兔号的 SPACEos 操作系统，系统架构是怎么设计的？
SPACEos和Linux和Windows的架构关系是什么样的？兼容Windows和Linux软件软件是否有可能么？怎么实现的？
–
航天五院的人敢不敢站出来说SpaceOS没抄一行VxWorks的代码？不管是GPP/MSP还是653或者Cert或者551，敢说一点没抄？三个字：不要脸。
传说SpaceOS第一版只有8000行代码，这点货就想兼容Windows和Linux？POSIX兼容都不止这么多代码。
完整兼容Windows需要支持所有Windows API，ReactOS多少行？都不敢说完全兼容Windows。Linux内核又有多少行？
一个完整的OS至少要有个调度器，有硬件管理，有内存管理，还得有一个基本的BSP，可以不要文件系统，可以不要libC，甚至可以不要时钟，但谁 敢说这样的系统兼容Windows和Linux？难道兼容的意思是只支持malloc和free吗？就这俩函数实现出来也得几百行呢！
听说SpaceOS是在天宫一号上运行过，天宫一号上用的SPARC，主频也就10-20MHz的水平，这硬件能跑Windows？恩，也许能，Windows3.2也许可以，但可惜不支持SPARC这个指令集。
吹牛的、不懂技术就乱说的记者退散吧，搞出这玩意一点都不值得骄傲，不要让人看笑话就好了。
最后，请自行百度/google ReactOS和Linux内核，知道这些玩意做的多大了再来说兼容的问题。
——————-问题被修改了，那么我继续补充——————-
SpaceOS跟Windows或者Linux没有太大关系。航天器用的系统是最重要的指标是实时性，而Windows和Linux都不是实时操作系统（RTOS）。
实时操作系统重要的指标包括：对中断响应速度（一般要求是ns级），Windows和Linux关中断的时间都太长了（都达到ms级的水平），不适合航天器使用。
实时操作系统调度策略都是抢占式的，Windows和Linux都不是抢占式的系统（补充：Windows是不完全抢占式系统，有防饥饿机制，Linux在2.4之前不是，2.6以后据说已经是抢占式的）。
跟SpaceOS同类的系统大多数人平时很难接触到，比如ucos，nucleus，threadX，以及VxWorks，这些系统一般用在工控的领域比较多。
另外，航天器的CPU一般都很弱，也不是intel或者amd的，甚至也不是arm的，见过最多的是SPARC，然后还有PPC/MIPS的，这是 因为太空中有辐射，要抗干扰。主频一般是10MHz到几百MHz之间，超过100MHz的都和NB，天宫一号好像是20MHz的水平。
内存和外存基本上都是KB-MB之间的，NASA能弄到上GB，已经很厉害了。天宫一号外存是256K-ROM，这个配置想跑Windows是不可能的，Linux应该也不行吧，我没试过Linux能不能裁到这么小。但前面我说的那几个不知名的系统都可以做到。
我说SpaceOS有极大的可能是抄VxWorks的，这是很可能的，毕竟VxWorks是最成熟的，航天器上用的最多的系统（另外，从歼十，到东风系列导弹，基本上也是VxWorks的天下），不要以为中国人写操作系统的能力很强，其实很弱，这是事实。
要不然，有谁是航天五院的人站出来，咱们可以拿源码对比一下差异度。
所以SpaceOS跟Windows和Linux没什么关系，应用场景不同，没办法对比。
—————–再说兼容Windows和Linux的问题—————–
首先，看什么级别的兼容：
1、代码-应用级，就是说代码拿到两边都可以正常编译，生成可执行文件并正常执行；
2、二进制-应用级，就是说一个二进制包（Java的那种不算），不管Windows或者Linux都可以执行，不需要任何改动。
3、脚本-应用级，就像Java这种，还有perl脚本什么的，这种很简单，不讨论。
4、代码-驱动/内核级，就是驱动可以跨平台编译并正常执行。
5、二进制-驱动/内核级，就是驱动的二进制包可以直接正常使用。
6、虚拟化技术的兼容。
一条一条的说：
第一类：比较容易，用宏隔离或者使用POSIX兼容的代码就可以，不少开源软件都是这么做的，困难程度一般。
第二类：非常困难，我见过有人讨论过，主要问题是Windows的可执行文件结构是PE结构，而Linux是ELF结构，两者差异太大，但是似乎有大牛实现过（记忆不是很清楚），困难程度非常高。多数人也不会这么做。
第三类：非常容易，没有讨论价值，大多数跨平台软件都是这么实现的。
第四类：有一定困难，因为Windows内核驱动和Linux内核驱动的API差异非常大，运行模式、内存模型、中断处理……都不一样，很少见到有人做这些都兼容的代码，一般开发都是分别开发两个驱动。
第五类：非常困难，这不仅仅是要克服PE结构和ELF结构的差异，还要克服两个系统的内核API差异，几乎可以说是做不到的。
第六类：常见的有hyperviser这种技术，但实际上是两个不同的系统，从道理上谈不上兼容，只是两个系统运行在一个平台上，类似虚拟机技术，同时这种技术会有硬件资源的损耗。
以上是六种方式的分析，跨平台兼容比较容易，但代价一般都是规模比较大，在航天器的低硬件配置下，基本没人会搞跨平台，因为紧张的硬件资源根本不够跑那么复杂的东西，再说架构都不同啊。
以上说的跨平台都指在同一个硬件架构下，一般都是x86架构，想要跨硬件架构的还是不要想了，代码级、脚本级有可能，二进制没有可能。
最后再次强调一下，航天器用SPARC/MIPS/PPC的CPU比较多，基本没见过用x86平台的（也就是intel和AMD）
——————继续说OS兼容性——————
有人说了用Linux+wine，其实Windows+cygwin也勉强算，ReactOS也算兼容WINNT内核，但应该归属于独立的OS，另外，众多的虚拟机算不算？还有硬件虚拟化？我觉得可以算，也可以不算。
Windows里也有子系统的概念，理论上说，在应用层设计一个完全兼容Linux的子系统是有可能的，无非是工作量的问题，但是不管是Linux on Windows 还是Windows on Linux，效率是一个问题，毕竟API都是虚拟化的，不是系统原生接口，效率比原生接口差。
更多的软件是使用JVM这种非硬件编码来实现跨平台。
最后，强调一点，RTOS里跑Windows或者Linux的软件意义不太大，并且航天器的配置太低了，根本跑不动虚拟机（或者虚拟化）软件。
—-
问题改拉。。原问题是spaceOS能运行windows和linux的软件，这样设计的利弊是什么。
以下是修改后的答案，我以民科的身份回答，非正宗专业人士。
spaceOS查不到什么公开的信息，没办法评价架构的区别。如@时国怀所说，很可能是个RTOS，这和Windows/Linux完全不是一类操作系 统。通俗来说就是RTOS需要的是在一个确定的时间范围内必须对信号给予相应。否则会发生探月器遇到个坑，但是因为后台在下a片拖慢了相应速度没有及时调 整体位，于是探月器被坑了。
spaceOS这样的环境下想要兼容linux和windows，唯一的可能是有些代码希望重用，不希望自己重新写。我猜测这样的系统，至少也会有一套某 语言的编译环境（很可能是C），因为直接写汇编是很费力不讨好的开发方式。这种情况下，假设希望重用的是个库，比如视频图像压缩库，用来拍照之类的软件可 能会用到视频压缩解压。最经济的选择不是让这个库的二进制代码直接copy到spaceOS就能用，而是选择把源代码重新以spaceOS为目标平台编译 一遍。另外的可能是实现某些语言的运行环境（比如JVM或者动态语言的虚拟机）。这样这些语言对应的软件有可能可以直接运行（但稍稍复杂的也很难直接拿来 就跑）。
这些情况下，spaceOS即便能运行上述软件，也不能说和spaceOS能兼容运行windows/linux软件。因为windows/linux本 身也都能做到上面说的事情，但是我们从来不会说他们能互相兼容。而且这种案例在spaceOS的环境下也适用与很少的一部分软件，因为跨平台本身就是一个 很不稳定的因素，探月器需要的稳定程度不可能允许引入多少不稳定。顶多是一些经典的与硬件和系统功能无关的算法库被重用。如果你想要跑迅雷（哪怕是迅雷迷 你）？那sorry了。
再说一个可执行文件拷贝来直接能运行的情况，这是很难的。举例来说，linux上有一套wine系统，能运行windows程序。但是wine背后重新实 现了大多数windows的核心库，并重新在linux上实现了一套windows的程序载入机制，比如程序的头部格式不同需要特殊处理，linux没有 windows的dll，需要特殊处理，注册表在linux上没有需要模拟（也许还实现了COM相关的基础架构，毕竟COM在windows上无处不 在）。这里的工作量无法统计，而且很多软件无法正确运行，毕竟wine不是windows。且不说是否在RTOS上能否做相同的事情，对于spaceOS 的情况这种工作毫无意义，毕竟我们不会在spaceOS上跑QQ和迅雷，花这些时间不如多测试系统的稳定性保证探月器不掉坑里。
兼容其他平台的程序最大的动机是重用代码而不需要软件开发商重新开发一套对应操作系统的版本。以spaceOS的情况，探月器并没有多少通用的需要重用的程序（一切都是为探月工作特别制定开发的），花功夫去搞兼容，意义可以忽略不计。
–
RTOS是肯定的.估计是类似vxWorks之类的,搞不好是抄一遍把函数名改得高大上.至于windows和linux,实时性不过关,估计不能
这种宇宙级的控制设备实时性要求多高啊…
工业控制领域的操作系统很多哦,别老把眼光放在win和linux上
–
操作系统肯定是rtos,不会去兼容什么windows, 抄没抄
vxworks不确定，rtos 本身并不难写，有些甚至连虚拟地址空间都不支持，windows和linux才复杂，我相信中科院那些搞龙芯的写一个出来并不难。现在国产的rtos也很 多，当然多少都有开源rtos的影子。另外听说vxworks并不是最强的，美国国防部用的greenhill rtos才最牛逼。
