If you can compile C code in Linux, and C code in Windows, then how come you can''t just recompile C code to a Windows application in Linux, and have it run on Linux? I know there would be minor changes, but not THAT much (I thought). It seems like every company would want to port their applications to linux as well -- assuming this were the case (why not?). I''m sure there is a perfectly good reason; I just don''t know what it is. Just curious.

I have never done any porting, so don''t take my word too seriously. But this is what I think is the reason.

If a program are made for windows ( or linux ), then I belive the code will include alot of windows specific code in it, and that could be alot. To make a program portable, you would have to rewrite all the code, where there are used windows specific code, and create linux specific code. To do this fast, you would need the code to be organised in a way that make it simple to change the gui code, file handling code, etc... and I belive this could be difficult to do.

So if a code should be easy to port, then the code will have to be made in a way that makes it easy to port.

Right on DarkSlayer, and just to add to what he said, windows uses the Win32 API for creating windows. For an example, I run FreeBSD as my OS. Although *BSD and Linux are alike, they are not exactly alike. If I want some code to work on my system, I will need to make changes to the source.

When it comes to porting a windows application, the best thing to have is of course the source code for the application. *nix and *BSD normally use X-server, which is used to render your display. A "CreateWindow" Win32 call is not the same as an "XCreateSimpleWindow" call. What is happening right now is modules that allow for "CreateWindow" to function as the "XCreateSimpleWindow" through the use of wine. I don''t want to get into to much detail, but I hope this helps give you an understanding of what is going on.

-brad

Thats basicly it. If the developer does not take steps to avoid windows dependant code or features that only exist on windows, then they have to rewrite the dependant code for it to work. Depending on the situation that may be simple or be one hell of a undertaking. Have a look at the first part of any windows program. Its a nightmare to just get a window up on screen. Plugging in values that have nothing at all to do with what linux expects to see. If you tried to use windows window creation methods linux would wonder what the hell you were talking about. Making a DX game? Wont work under linux, the DX funtions dont exist there. Toss in diffrent sound systems and a whole slew of other windows only funtions and you can end up with a tangled mess that will always be OS dependant.

The fact is that DirectX is the main culprit, most OpenGL games can (and have been) ported to Linux, e.g. Unreal Tournament, Quake, RTC Wolfenstein, Tribes 2 etc.

You just found out why DirectX is the root of all evil. Also, MFC and Win32 API.

Every OS outside of windows works nearly alike. DirectX is windows-only. MFC/Win32 API is windows only. VB is windows only. C# is pretty much windows only.

Get addicted to those, and guess what. YOU''RE windows only.

quote: Peon If you can compile C code in Linux, and C code in Windows, then how come you can''t just recompile C code to a Windows application in Linux, and have it run on Linux? I know there would be minor changes, but not THAT much (I thought). It seems like every company would want to port their applications to linux as well -- assuming this were the case (why not?). I''m sure there is a perfectly good reason; I just don''t know what it is.

Just curious.

You can! The problem is, C (nor C++) does not specific enough requirements to write a program today. You need more than just some memory mangagement and console IO. You need networking, a graphical UI, and multi-threading. The libraries for those things are different between platforms.

If you are careful, and use portable wrapper libraries, you can write code that compiles and runs on many platforms. Examples are boost, ACE, & wxWindows. I didn''t like any of the threading libraries; most drop functionality down to posix. ACE does not, but it''s a bit more complicated than what is needed for more case (I use ACE for portable socket code).

IMNSHO, the corresponding parts of the Win32 API are hands-down superior to posix.

- Magmai Kai Holmlor

Not For Rent

[Look for information | GDNet Start Here | GDNet Search Tool | GDNet FAQ | MSDN RTF[L] | SGI STL Docs | STFW | Asking Smart Questions ]
[Free C++ Libraries | Boost | ACE | Loki | MTL | Blitz++ | wxWindows| Spirit(xBNF)]
[Free C Libraries | zlib ]

I think you guys are putting in more then what it is.. First of all how many days would it take to add in support for files to another OS ?? maybe 2 days.. How long does it take to make a window to work with in any OS ?? few hours if that.. It comes down to, is it worth spending more money for support for more OS other then windows. As you noticed I used "spending money" and "support" which is turn is money. Will the programmers some or all need training how to use linux and program for it. Also will they need training to use openGL, SDL, openAL ? how much will that cost? how long will it delay the game? These are questions that corp guys are asking. Will adding support bring in more money or lose money for all the related examples I gave above. Its really not the programmers choice but the guys that just look at the money... Which is sad and will not gain *nix support and growth.

Because if you really think about it, it wouldnt be that much of a problem to add support for other OS other then windows. Since opengl, sdl, openAl and winsock are used just about the same on *nix then windows.

But it''s not just a few days total. It''s a few days, to a few weeks for each thing. Months to write a comprehensive portable GUI.

Just using a serial port in a typically fashion under posix is silly. It''s still defaults for terminals - dumb serial terminals to log into the server. You have to wade through pages of docs and disable about two dozen options to get a serial port to send out the bytes you tell it to, without fiddling with them. Win32 defaults to binary IO, but all of the com port code examples in MSDN contain subtle bugs.
Going either way is going to be painful. Nothing is ever easy.

File support you say. Well, C has file support, so if all you need to do is open, read, write, & close, you''re set. Now, let''s open a file. Ut oh raggy. Windows is different than *nix is different than Mac is different than VMS. Luckily some poor souls already figured most of this out in the boost::filesystem library.

Supporting multiple platforms take a lot of time. You have to test everything mutliples times. If you don''t test, it won''t work.

Then, let''s say you are using a cross-platform library. They are rarely complete and comprehensive. I was using boost::date_time, and at one point needed a microsecond clock. Many posix implementations have a high resolution gettimeofday call, which is used to implement a microsec_clock. I had to write the Win32 counter-part (it was easy, but it was missing).

After becoming a little fed up with linux (rmap bugs making the system unstable), we went to build everything on QNX. ACE doesn''t compile...

I am not saying I know a lot or anything for that matter.

I read 1 book on network programming for games using winsock. Now they are both the same for win/linux/unix but a few functions names are different but have the same effect. Now if the companies design there game for 3 operating systems then there isnt that much time added to the development time. I could understand if they ported there win32 game only to linux, which is what most of them do. They have to hit deadlines and dont have the option to port most of the time. For example. New companies, low profit companies tent to push games out. Where as popular game companies tent to make there games cross platform. Bioware did this with never winter nights, UT.

I agree a GUI can take a while to build, but how much more time is added if they said in the design stage they wanted to build it for win and linux? From what I know game companies are breaking even or losing. So this goes back to my first post, money. Its just not worth it to spend another 3+ months making this game if they are going to sell an extra xxx copies, because most linux users run windows for there games. Windows play''s games better, sound is a big problem. My audigy didnt or doesnt have 3d support.. Why creative doesnt make drivers for it, which is lowering the attractiveness of making portable games for linux. Linux needs more driver support with the same quality is windows. But me personally I think creative is doing a very poor job making drivers. They hardly release drivers for there 2nd newest released products or older. But anyway.