I'm not in the game industry, so I may say something that someone will consider wrong, so @guys feel free to correct me. But anyway, I'm a programmer, but will try to give you some more general version:

Each application on some low-level layer of the application call OS-specific code. As mirv said, it can be with graphics, audio, some system functions calls, etc.
Porting of the application is the process of making sure, that all the code that is one-platform specific, is rewritten to work for other platform as well (It can be OS-specific code, or code shared by both OS-s).

The problem is, that it sounds like a simple task, but in reality it isn't. Not every project has nice layered structure, not each module is easy to port, and what's most important - it is not always one to one function mapping from one OS to other OS.

And if you wonder about games port, you should keep in mind that all the middleware applies to what was said above. But there is other, very important part - Graphical API porting.
Regarding Graphical API there are 2 things you should keep in mind - most of the games those days are written in some game engines. Some of them are written in-house, some of them are 3rd party engines. Of course there are some indie games that are written without game engines, but I guess it's not so popular those days.
So having support of the game engine on the target platform as well is a very important step, and means that a port is much easier, but it does not mean the port will happen.

In order to successfully port a game, you need to have support on your platform for:
- graphical API / game engine
- all the code that calls OS-specific code written by game studio
- all the 3rd party middleware

The problem is, that game studios very often do not think about 3rd party software that they use, and at some point they realize that port is not possible because of the "used middleware" (which sounds like a very cheap excuse)

What mirv has mentioned as well is that it is possible to make a code OS-compliant without modyfing all the code (in extreme case without modyfing code at all). Such an approach is used by Virtual Programming - they add a layer (called wrapper) that uses the code that is one OS-compliant and translates it Just-in-time to other OS-specific code.
What Virtual Programming does is very similar to what Wine project does.

Hope I covered some topics that make it easier to understand how does the porting work.

What kind of work is involved making Wine 'ports' (like the recent Two Worlds port). For example, games that I played the hell of back in my Windows days like STALKER and EYE Divine Cybermancy run great in Wine, but I'm sure the devs aren't interested in doing any sort of real work to get them running on Linux.

I wonder if there could be some sort of community effort/project to make it easy for devs to wrap up older Windows-only games with Wine and ship them via Steam. The Two Worlds port just looks like it's a shell script, a specific Wine binary and some libs.

bump maybe?