程序移植linux

❶ 各位好，如何将VC++写的程序代码移植到linux

准确来说取决于程序类型吧，如果程序早期没有考虑考虑跨平台，做好适配层，那么移植到linux就有一定的难度。
有很多点需要注意，比如：
涉及到的windows专有API，全部得切换成跨平台的，
C++有一些语言特性只能在windows下支持，需要调整。
程序依赖的第三方库是否支持linux等。
太多了，写不完。。。。

❷ 有c#程序源码，是不是都能移植到linux

理论上C#的程序是平台无关的 就是可以移植到任何系统 这就是MICROSOFT设计C#使用中间代码的原因 实际操作上需要有对应的编译器 如果你研究过C#应该能看懂我说的

❸ 如何将OS/2应用程序移植到Linux操作系统

在转换到 Linux 之前注意一下，提早发现陷阱。LANDP 小组带领您了解 OS/2 和 Linux 之间的差别，以便您的移植工程才能更顺利地进行。本文是 LAN Distributed Platform（LANDP）for Linux 小组把 LANDP 从 OS/2 移植到 Linux 时所遇到的问题的概述。本文对其他正在把 OS/2 应用程序移植到 Linux 的小组应该是有帮助的。当决定了要把 OS/2 版本的 LANDP 移植到 Linux 时，小组已经有了从 OS/2 移植到 NT 的经验。NT 移植包含两个主要的途径： 映射层；抽象层。抽象层比映射层稍简单一点儿。抽象层是薄薄的一层软件抽象，它抽象了函数名、参数以及它们的返回码，而映射层则试图模仿 OS/2 的行为。对于Linux 移植，我们从开发抽象层开始。抽象层将需要许多附加功能，这是早就显而易见的。抽象层发展成了映射层。映射层是一个共享对象，有一个恰似 OS/2 接口的接口并且试图模仿 OS/2 的精确行为。然而，LANDP 需要的仅是 OS/2 功能的一个子集，因此，映射层不是一个完全实现。下面几节概述了两个操作系统在功能上大部分不同之处，并且提供了一些处理这些差别的建议。明显的差别系统调用是 OS/2 和 Linux 之间最明显的差别。一些调用容易被映射（例如，DosOpen），而其它的调用不容易被映射（例如，DosCreateQueue）。除了系统调用之外，返回值和返回值的含义也不同。同样，一些返回值能被精确匹配，像 File not found，但是其它的返回值需要近似匹配。类型是另一个产生差别的地方。因为 OS/2 重新命名了 C 的类型且使用函数参数的结构，所以就产生了差别。例如，在 OS/2 上类型 UINT 被定义为无符号整数。我们必须为 Linux 环境重定义这些类型中的大多数。操作上的差别最主要的区别在于概念的行为，这甚至比移植系统调用和重定义类型更为重要。大多数操作系统具有相同的概念、内存、文件、进程间通信（IPC）等等。OS/2 和 NT 有非常相似的概念且它们的差别不是大范围的（除了共享内存外）。然而，Linux 和 OS/2 显示了许多概念上的差别。下面这些子节概述了这些差别，并且为处理这些差别提供了一些解决方案。线程Linux 环境中的线程是一个特殊类型的进程。因此，要为您使用的每个线程都创建一个新进程。而且，通过使用 clone 函数或一个叫 pthread 的单独的库来实现线程。也存在其它形式的线程，但是 pthread 是一个 POSIX 定义的标准。因为对 Linux 而言线程是一个相对新的概念，所以这个操作系统不是和其它操作系统一样线程安全。因此，一些标准库并不是真正的线程安全。另外，线程会影响信号的行为。特定的线程将接收一个被发送到进程的信号，这个特定的线程是未知的。请注意，pthread 有它们自己在一个进程中的每个线程之间传送信号的方式。getpid 和 getppid 的使用将受到影响。例如，一个调用 getpid 的线程，它的进程标识（不是应用程序的进程标识）将被返回，因为线程被作为进程来实现。内存进程内存在 Linux 和其它操作系统中的使用非常类似，但在进程间共享内存的机制不同。Linux 提供了一组基于 System V IPC 机制的 API。在这组 API 中处理共享内存。共享内存机制为一个进程可以拥有的段数量以及整个系统的段数量定义了界限。遗憾的是，这个界限限制了一个应用程序能使用的共享内存段的数量。例如，如果一个 OS/2 应用程序创建了 500 个共享内存区域，您就无法使用到 System V 共享内存 API 的直接映射。尽管您可以重新编译内核并设置新的层次，但是必须考虑您的顾客们是否能接受这种改变。您可以分配一个巨大的共享内存段，然后在这段内分配小一些的块。然而，没有边界检查。没有边界检查，应用程序会损坏已分配给其它进程的段。实现一个与 OS/2 （它进行一些边界检查）类似的行为的另一个方法是使用文件映射。文件映射将一个文件映射到一个进程的内存空间内，以便允许把文件像内存一样来访问。没必要整个文件映射到内存，但可以把文件的一部分映射到一个内存区域。共享内存机制的另一个差别是：当一个段被加载到一个进程中时，Linux 不保证会使用相同的内存地址。在 OS/2 上，您可以分配一块内存并将这一块内存传送给另一个进程。内存位于每个进程中相同的地址处。在 Linux 上情况并不一定如此。另外，为了访问另一个进程已创建的一个共享内存段，您需要知道这个段的标识。标识是一个独一无二的数字，可以通过使用一个名称（如果该名称作为一个文件存在）来计算这个数字。OS/2 提供几个系统调用，使得进程能够给出且获得到基于名字或内存地址的共享内存段的访问。队列OS/2 队列是一个允许进程把内存指针传给另一个进程的机制。传送进程必须通过 DosGiveSharedMemory 给接受进程提供到内存段的访问，然后把内存在段中的位置传送给接收进程。像机制名暗示的一样，队列可以在等待另一个进程读取它们的同时保存大量的这些内存位置。Linux 没有这个概念。在可能的解决方案中，其中之一就是使用 System V 共享内存段。System V 共享内存段的问题是限制了被允许的段的数量。另一个方法是使用文件映射并使用控制结构，该结构设置元素（内存位置）的顺序和对文件的访问权限。信号量（Semaphore）OS/2 提供三种主要类型的信号量：事件、互斥和多等待。Linux 提供一个基于 System V IPC 的信号量机制并且支持信号量作为 pthread 库的一部分。OS/2 信号量是一个单独的实体，给您提供一个定义良好的行为。然而，可以将 System V 信号量定义成几组，这是可配置的。在不重新编译内核的情况下，每个组最多可以有 250 个信号量（2.4 内核）。这种系统在系统内只能有一定数量的信号量组（可以通过重编译内核来更改这个数量）。System V 信号量基本上是计数变量，您可以增加或减少这些变量，并且这为您模仿事件信号量和互斥信号量的行为提供了足够的功能。唯一的问题是执行定时等待。在 Linux 上，您只能尝试／等待或等待。不允许超时。为了模仿超时，您需要构建某种定时机制，该机制能发送一个信号来中断正在等待一个事件的线程。多等待信号量是一个已定义信号量的集合，这些信号量可以作为一组等待。System V 机制利用组，并且能等待许多与同一个组相关的操作。然而，只有应用程序仔细地规划了它对信号量（多等待中的所有信号量都来自于同一个信号量组）的使用，您才能得到期望的结果。我们实现了一个机制，它使线程能够等候这组内的每个信号量来模拟这一行为。pthread 库提供了能合理模仿 OS/2 行为的信号量和互斥（以及条件变量）。然而，还存在缺陷。请注意，pthread 信号量和互斥是不可共享的。换言之，仅在那个进程中保证它们。如果您的应用程序仅使用私有信号量，或者如果没有其它进程需要访问它的信号量，那么使用 pthread 互斥和信号量可能是最好的计划。但是，如果您的应用程序共享这些 IPC 机制，那么您需要用 System V 机制、共享内存和线程来实现这些机制。信号在OS/2 上，为了指明某些错误情况，要抛出异常。在 Linux 上，这些被称为信号。与异常一样，除了 SIGKILL 和 SIGSTOP 之外，信号都可以被捕获。在 OS/2 上，您可以定义一列在接收到异常时需要执行的函数。应用程序可以在 OS/2 上定义不止一个异常处理程序。在 Linux 上，因为函数被覆盖了，所以您只能定义一个异常处理程序。管道在OS/2 上，管道是双向的，而 Linux 上的管道是单向的。为了模仿 OS/2 管道的行为，您需要创建两个管道，通过一个文件句柄来索引。共享对象Linux 共享对象和 DLL 非常相似，但是需要注意几个陷阱。应用程序可以在一个共享对象中重写函数。如果一个共享对象有 print_hello 函数并且应用程序有一个叫作 print_hello 的函数，那么无论何时应用程序调用 print_hello，都使用应用程序的版本。您在共享对象中调用一个函数之前（例如，so_print 调用 print_hello），这可能听上去不像什么问题。这种情况中使用的 print_hello 是应用程序中定义的那个。感觉上的标准函数您在作关于标准 C 函数方面的假设时应该谨慎一些。例如，kbhit 和 strupr 不是标准函数。尽管它们可能是一个编译器的 C 标准库的一部分，但是假定这些函数和其它函数存在于所有平台上是不安全的。结束语前面所述的差别无论如何不包含一个确定的列表。这样一个列表中包含的信息足够写一本书了。然而，当您将一个应用程序从 OS/2 移植到 Linux 上时，这些差别应该使您可以提前找到需要解决问题的地方。LANDP for Linux 小组设计了一个映射层来帮助我们从 OS/2 向 Linux 移植。映射层是一个共享对象，用于从 OS/2 移植各个 LANDP 服务器。可能映射层将为其它项目提供一个起点，也许不会提供。关于作者Kevin Bowkett 是一名在 LANDP 开发组中工作的 IBM 软件工程师，在 Linux、Windows 和 OS/2 操作系统方面有很好的基础。在过去的一年中，Kevin 带领 LANDP 小组将 LANDP for Linux 投入了市场。Kevin 还是一名获 IBM 认证的 DB2 应用开发解决方案专家。

❹ 如何把程序从windows平台移植到linux平台

需要用到的技术有：
1. 抽取其中用到的 Win32API, 分为通信类， 多线程类，时间字符串等函数类， 逐一封装成 Linux 的函数；
2. 调试移植后的整个代码库， 并作必要的调整和修正；
3. 需要 C++11/14 的经验；
4. 需要 Windows 和 Linux 高性能多线程 C++服务器程序开发和调试的经验，
5. 需要 boost 及 zeromq, 以及异步通信库， 异步日志库等方面的经验；

❺ 把应用程序移植到PowerLinux容易吗

：难易取决于应用程序的特点，但通常来说移植很简单容易。移植后，真正的工作可能是优化那些性能敏感的程序，特别包含了编译器和不可移植，平台依赖的代码，这两种特性增加移植时间。

看更特殊的，作为答案，我们可以把应用程序分组和深入描述它们移植的可能性，如下：

· Java和开源结构的程序可以“直接运行”在PowerLinux上。

o 不论用Java还是脚本语言比如PHP或者Perl写的程序可以“直接运行“在PowerLinux上。Java调试指南已经发布用于给这些程序有效地运行在Power系统上提供帮助。

o RedHat和SUSE为Power发布的版本中最流行的开源应用程序如Apache，Tomcat，MySQL，Squid，Postfix，等，可“直接运行”于PowerLinux。

· 用GNU工具编译的客户程序（C/C++等）通常需要在PowerLinux服务器上简单地从新编译一下。如果这些程序避免含有特殊代码比如汇编语言，那么它们同样可以“直接运行”

o 我们最新的Eclipse基于PowerLinux 软件开发工具包 (SDK) 提供给X86 Linux开发者一个非常熟悉的环境。很多用户报告重新编译非常快，也就几分钟。源于IBM花费数年来研发开发工具。

o SDK也提供移植工具（比如IBM的Chiphopper program）来帮助移植过程和性能调优工具用于移植后工作。

o 另外，SDK也提供最新和最快的GNU工具和库文件套装，称为PowerLinux高级工具链

o Porting to Linux on Power wiki网页是开始这个过程的最佳地方。

· IBM SWG可用于PowerLinux的应用程序每月都在增加。这些程序可以用于多平台和操作系统，包括PowerLinux.

o SWG维护下面的网站，以提供SWG平台支持的产品的最新列表。比如如何搜索Power上的RHEL或者SUSE版本和在软件产品兼容报告网站上生成能支持的应用程序的PDF列表

o 使用软件产品兼容报告的更多细节请参阅PowerLinux定位程序 wiki网页。

· PowerLinux第三方ISV程序集每月也在增加，主要围绕跟大数据量程序，工业程序和开源结构有关的ISV。

o 这些程序在合作伙伴全球解决方案目录链接中维护更新。更多使用全球解决方案目录的细节可为PowerLinux定位程序 wiki网页找到。

o 如果应用程序不可用于PowerLinux，IBM有一些程序帮助ISV迁移他们的程序，包括：

§ 有销售前景的快速移植

§ Chiphopper提供免费科技协助和X86 Linux到PowerLinux的移植工具

§ 为远程访问PowerLinux服务器的虚拟租赁程序（ Virtual Loaner Program），移植工具和技术支持资源

§ IBM为本地，在线访问上述资源的创新中心

❻ 在windows下,用c标准库开发的程序代码，如何移植到linux下用

当然可以，把代码放到LINUX环境下，用GCC来编译，如果不使用线程等需要特别指定链接的库，只要有标准的C，C＋＋库，就可以gcc -o obj obj.c
这样来编译，如果你标准库都没有，就从网上下标准库的包，解到/usr/lib下，一般这是默认的路径

❼ 将VC程序移植到Linux系统的几点经验心得

经验心得：

有时我需要制作LINUX与WINDOWS下都可以运行的程序。在一般情况下，我会选择在WINDOWS平台下完成初始的开发。因为VC提供的图形化的编辑与调试界面的确较GCC要高产得多。在完成了测试之后，就开始把它向LINUX移植，移植的过程会有一些需要注意的地方。下面就是我的一些心得。

1.文件名
由于ext2文件系统对文件名是大小写敏感的，当你在这种文件系统上进行编译的时候，源文件中出现的#include 语句必须小心了。因为在VC环境下，由IDE自动生成的#include 语句，其中的文件名全部是小写的。所以，你需要在一开始就注意这个问题，严格的使用大小写敏感的文件名格式，避免在LINUX下编译时出现找不到头文件的错误。

2.数据类型
千万不要使用VC独有的数据类型，象__int16, __int32 和__int64 等等，你无法保证其它的编译器能否支持它们。特别是__int64，它确实简化了编程工作，但是当你的逻辑里充满了这样的数据类型的时候，改动就变得无比困难了。还有一个问题就是，我们经常在VC中使用WORD,DWORD，INT，UINT这样的扩展数据类型，不直接使用编译器的数据类型有助于提高在不同平台之间的可移植性。但是LINUX下没有定义这样的类型啊？其实只需要将windows.h和basetypes.h中对这些数据进行定义的语句复制到一个头文件中，再在linux下包括进来就行了。


3.关键字
关键字是比较好处理的东西，凡是VC中带两个下划线的关键字，比方__asm都是VC独有的。尽量不使用它们，如果实在无法避免，就用#ifdef 和#endif为LINUX和WINDOWS编写两个版本。


4.MAKEFILE的编写
你可以先用VC导出一个makefile，然后对其进行修改，但我倾向于从中拷贝出一段来生成GCC的makefile，比起手工编写要快许多。


5.程序设计结构
这绝对是移植过程中问题最大的一个部分。应用程序难免要用到操作系统的服务，如果完全使用标准的C/C++编写，这将不是一个问题，但是当我们使用到多进/线程，管道，或者对WINDOWS图形界面的程序进行移植的时候，这个问题就变得突出了。我们应当从设计上就为程序的移植打好基础。

解决这个问题首先必须搞清楚应用程序的逻辑模块。对于这个模块必须使用标准的C/C++进行编写。同时将应用程序使用的线程数最小化，线程越多越难移植。将输入输出模块独立出来。最后划分出控制模块，这个模块与用户进行交互。

最后，我建议你网络一下《Linux就该这么学》来进一步了解更多相关知识~