#### Archived

This topic is now archived and is closed to further replies.

# Why aren't there more Linux ports of Windows applications?

This topic is 5180 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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.

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites
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 ]

##### Share on other sites
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.

##### Share on other sites
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...

##### Share on other sites
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.

##### Share on other sites
Linux isn't seen as a game platform now.. so not alot of game companies bother with it.

Windows owns the desktop market.

Edit: Forgot to mention that not alot of application companies bother with it either .

[edited by - Maega on October 12, 2003 2:35:25 AM]

##### Share on other sites
quote:
Original post by Dalik
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.

I started porting my game engine to linux, and I made sure I kept the OS dependancies in a SINGLE (relatively small) class. I converted it to linux, no problems, ran it... and it crashed. Found out it''s crashing when I load the second texture up. Check online, seems to be a problem a few others have encountered and never solved. Playing around a bit more, I can get it to crash at a few different GL calls, reversing the order of which the 2 textures (was trying it with a minimum app at this point, just font and mouse), and it loaded them properly, but then the window got screwy. Double checked my code a lot, re-wrote it from scratch, same results. Downloaded some nehe tuts for linux, ran fine with multiple textures... until I switched it to store GL_RGBA textures internally, then it all the sudden broke, which leads me to beleive it must be a driver issue. And, that leads me to the reason so little people like to convert their windows apps to linux. Graphics drivers have always been... well, not the best. 3d support was all but non-existant until very recently, and it''s still shaky (although getting better). I will probably install mesa and run it as software to see if that crashes also, if it doesn''t crash and works flawlessly, I can pretty much hands down blame crappy drivers.

The thing is, the part that''s crashing was the NON windows specific code, all my linux specific stuff was fine, but the non-os specific stuff didn''t work properly under linux, but worked fine under windows (and the code itself is fine, no reason it shouldn''t have worked under linux). I pretty much put off the linux conversion until I have a bunch of spare time, and possibly a linux guru there to help. In theory, converting to another OS (if written in GL and using multi platform libraries) should be extremely non-painfull and not take a long time, but in practice, it''s not so pretty of a picture.

##### Share on other sites
I went through a simmilar thing just using SDL. I started making a simple game that I could run under linux. I first made it under Windows. What I had was running I would guess over 100fps. Under Linux it was about 5fps. Searched around and never found any real reason for it. Some O''yeah change this and run it as root(horrrrrrrible thing to be required). I managed to double the speed maybe. Thats still less than 1/10th using the same code under windows. This is across several systems and its totaly unplayable and I stopped making it. Looks like I would have to learn to mix OGL and SDL and use 3D to do what I should be able to do in 2D with the super easy SDL setup. I''ve used DX but right now I haven''t the intrest to learn a new API that I don''t need at all under windows as programing is back seat to other intrest. SDL is short, sweet, simple, and under linux for me useless.

##### Share on other sites
Goober:
did you install your drivers for linux? If you are using the default drivers that X uses then thats not surprising that you got 5fps. If you got nvidia or ati card then install there drivers and you should get 100fps or more under linux.

I am not trying to be an ass but you would have to find another way. Because Unreal seems to be doing everything correct. Along with other companies. But again it could be driver support which is much better now with nvidia, just heard ATI released there own drivers for it also.

Consider this, OpenGL was ment to run on linux just as much as windows. So its most likely a driver problem more then anything.

##### Share on other sites
If supposedly portable code crashes on one platform, but not on the other, it''s obviously not correct code. Most of the time, this is because somebody didn''t read the documentation carefully...

For example, SDL programmers often forget to lock surfaces before accessing the pixel data directly. On some platforms, this works (because the surfaces are software surfaces). Then, when they go to the other platform, the program crashes, because the lock was missing.

In your case, it''s basically impossible to tell what the problem is without you giving more information.

cu,
Prefect

##### Share on other sites
Yes the drivers are installed and working quite well. I run a great many games like UT2003, RTCW, and anything I can get to run under Winex. As for accessing the pixel data I never went so far. All I ever needed was load bitmap into hardware surface, show bitmap. Thats as deep as it got. I just didn''t seam to be getting actual hardware surfaces under linux. Anyway thats not importaint. I wasn''t looking for a resolution because that would be off topic and only ended in failure in the past. Just showing that even simple things can end up complicated. If I was a better programer It might be fixed easily but dosn''t really matter as I have lost all intrest in finnishing the project.

##### Share on other sites
quote:
Original post by Prefect
If supposedly portable code crashes on one platform, but not on the other, it's obviously not correct code. Most of the time, this is because somebody didn't read the documentation carefully...

For example, SDL programmers often forget to lock surfaces before accessing the pixel data directly. On some platforms, this works (because the surfaces are software surfaces). Then, when they go to the other platform, the program crashes, because the lock was missing.

In your case, it's basically impossible to tell what the problem is without you giving more information.

cu,
Prefect

It's portable opengl code. There is nothing out of the ordinary going on, and I even changed the order things where called just in case it made a difference, which it didn't. It was a few calls to load a texture in opengl:

unsigned int tID;
glGenTextures(1,&tID);
glBindTexture(GL_TEXTURE_2D,tID);

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, SizeX, SizeY, 0, GL_RGBA, GL_UNSIGNED_BYTE, img);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_NEAREST);
glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);

This crashes under linux, and not windows. If I load the textures in one order it crashes at the BindTexture, otherwise it crashes at the glTexImage2D call.

--- Edit ---
By the way, I have an ati card (radeon 9100) and the standard drivers that it installs for it, the ati drivers don't support the 9100 with 3d acceleration.

[edited by - Ready4Dis on October 12, 2003 11:10:36 AM]

##### Share on other sites
The majority of the Linux users I know prefer to get the source code and compile it their self. Most companies are not keen on the idea of releasing their source code to the general public. Any doubts, look at Loki. Beautiful ports for a community that could not/would not support them. As long as Linux is seen as a super users domain, that is all it will ever be.

Open Source Programmer

##### Share on other sites
actually, my not so very humble opinion on this matter is that blaming on linux that a program crashes is just a lame excuse for not learning to program deacently. It is a major concern i computer science to write portable code and separeate GUI from network and core etc. Okay, i know that linux have problems with graphics drivers, in fact i get lousy fps values with my intel740 card, but the solution is not to give up linux as a gaming platform. We have right now very good 3d driver both from nvidia and ATI is working a great deal on it. DRI is doing a really good job too. Also WINE and WINEX makes it possible to play dx games on linux..at least some of them so actually i agree with peon: why arent there more programs ported to linux.....

thank you

--Spencer

"Relax, this dragon is sleeping..."

##### Share on other sites
Why not?

The same reason why people don't make games for the Mac.

There are hundreds of millions of Windows users. Selling a million copies of your game is hopefully a good return on investment.

With the costs of games, companies are afraid to invest in something like a porting project that might not see a return on investment.

Now, if more companies would realize that porting WHILE in development might show them they have improper code that just happens to work, then they save on patches and bug fixing later.

Spend more now to release a game with less bugs. If your game crashes, some people will return it or stop playing it. That means less word of mouth for you, or worse, your game being bad mouthed as buggy. If you make it so that your code works on a few different platforms, there is a greater chance it will be bulletproof. Not everyone remembers to patch their games. You just saved your current sales and possibly improved future sales.

But people don't see that. They see, "If only 10% of all Windows users buy it, we're fine. 10% of all Mac/Linux users doesn't nearly cover our expenses for putting this game out...We'll stick with Windows only since the expense doesn't justify porting."

What does that mean? It means smaller fries, like shareware companies, can take advantage of the small Linux/Mac gamers market. Create a good game and get not only revenue from Windows users, but Mac and Linux users as well.

So let the big companies ignore the benefits of porting their games. While users aren't winning out here, at least some enterprising indie developers or shareware authors can. I understand that most Mac users are big shareware fans. Maybe the same can be said of Linux users. Loki went out of business because of the bad business deals it made ("Sure we can port your game...but you want us to guarantee 100,000 licenses? Uh, sure." I think this is oversimplifying it, but I think this is the general idea of what happened). This doesn't have to be the case for Linux development.

[edited by - GBGames on October 12, 2003 6:59:27 PM]

##### Share on other sites
quote:
Original post by Spencer
actually, my not so very humble opinion on this matter is that blaming on linux that a program crashes is just a lame excuse for not learning to program deacently. It is a major concern i computer science to write portable code and separeate GUI from network and core etc. Okay, i know that linux have problems with graphics drivers, in fact i get lousy fps values with my intel740 card, but the solution is not to give up linux as a gaming platform. We have right now very good 3d driver both from nvidia and ATI is working a great deal on it. DRI is doing a really good job too. Also WINE and WINEX makes it possible to play dx games on linux..at least some of them so actually i agree with peon: why arent there more programs ported to linux.....

thank you

--Spencer

"Relax, this dragon is sleeping..."

I know how to program decently, and I know that there are no errors in my code that should be causing the crash. I have tried changing many things and there are others with the same issue, so it''s not just me (and I didn''t copy their code either, so multiple people coming upon the exact same issue with a driver call... hmm, must be all of us can''t code). Learn not to disrespect people when you know nothing about me, or my coding style. My network code, gui, etc are ALL seperated, and all OS specific code is in a single class like I said, so by replacing this class (inherit a base class, and fill in required functions), I can run my engine under any OS, or at least that was the plan. I wrote a linux version, and the class works fine, but the other code that was OS independant (plain old opengl calls, etc) were the ones having problems. I''m positive it''s not my code, because I can compile code from other people and it does the exact same thing (nehe code for example).

##### Share on other sites
I had several problems converting my "cross-platform" SDL game into Linux. Most of them were related to incompatibilities in the compilers. Try the following code in MSVC:
int main() {	for (int i=0;i<5;i++){}	for (int i=0;i<5;i++){}	return 0;}

In MSVC 6 (at least the version I have), it came up with some error about redefinition of ''i''. I can''t tell you the exact error because I''m not in Windows now. In g++, it compiled fine. But if you remove the second int, it works find in MSVC, while g++ says:
g++ error.cc
error.cc: In function int main()'':
error.cc:3: error: name lookup of i'' changed for new ISO for'' scoping
error.cc:2: error: using obsolete binding at i''

That''s with the following output from g++ --version:
g++ (GCC) 3.3 20030226 (prerelease) (SuSE Linux)

And for non-games, its even harder. Have you ever made a GUI in C for Windows or XWindows? No matter how much design you put into it, its not fun. And Java is just plain ugly.

##### Share on other sites
Ready4Dis: If I remember your situation correctly, you posted a stack trace of the crash at some point, right? It did look like a driver problem from the quick glance I gave it. Did you bother to report it to the people responsible for writing the driver? If you''re using proprietary drivers, report it to whoever supplied them. If it looks like it was DRI, report it to them. If you want them to pay attention, give them a minimal recreation of the problem. It''ll probably get fixed if it''s as serious as you try to make it sound.

Clum: That''s because MSVC 6.0 is a horrible compiler. Generally, stick to standard and learn the quirks of compilers you''re targeting. Once you have more experience, avoiding such issues isn''t something you have to worry about, it just comes naturally.

##### Share on other sites
I actually resorted to:

#ifdef WIN32
#define I i
#else
#define I int i //prevent ANSI scope warnings which MSVC doesn''t support
#endif

and then using for (I=0;...;...)...

and making sure that I don''t use any variables called I in my program.