So another "can I port" thread ended badly, many responders in which had words to the effect of "no lol you fool you can't" which is not strictly true. Everything mentioned here is not theoretical and has seen practical use in games and general software engineering.
On we go
Introduction
Most games are programmed such that they run on a given system (most consoles) or a given class of systems (PC architecture on Windows being a common one), though as anybody that has ever had to update their graphics drivers to play a game will know the latter is not a flawless concept and even the former has its moments -- want to do link cable GBA games on a DS, aww.
On older systems this usually meant people writing raw code and maybe having images converted but more likely drawing them as they would appear on screen in the end.
Later systems made coding easier by allowing high level languages which turned easier to read and write code into the raw stuff as it would go into the CPU. This easier to read stuff is known as source code, and the act of turning it from high level to low level is known as compiling and for many intents and purposes is considered a one way process but more on that later.
There is a third class in interpreted languages. A very popular example is the SCUMM engine, popularised in the "emulator" known as SCUMMVM. More on this later as well.
Many take the position that without source code, or something like SCUMM, then you will not be able to port the game across. For most demonstrable practical purposes this is true enough. It is not however the whole story, not a by a long shot and that is ignoring pure emulation entirely.
Source code
Source code comes in one of two forms
1) A developer releases it.
2) It is leaked somehow.
Sometimes a developer releases it and ultimately has to retract it for various reasons. Popular ones include them using libraries they are not allowed to release code to (many games using the rad/bink video codec which devs have or have wanted to release have fallen foul of this).
In any case it is often observed that such sources do NOT come with a release of art, levels, music, names and concepts. Or if you prefer this is why though Doom has been released as source ( https://github.com/id-Software/DOOM ) you still have to provide your own WAD file.
Leaks and retractions make things tricky. Legally speaking you would be unlikely to be able to do much publicly with it, behind closed doors and by more covert means is a different matter entirely. That said being able to share the results of your work is nice so don't expect too much movement on leaked and retracted releases for source code, with a few minor exceptions if some of the troubles can be worked around.
Anyway list of once commercial games with some flavour of source release
https://en.wikipedia.org/wiki/List_of_commercial_video_games_with_available_source_code
Ground up remakes without source
1) Clean room style
Fighting games at the high end have been likened to chess by some people, up to you what you think there. Either way though you may have seen people able to recount stats for enemies, frame counter levels of positioning, move lists, hit boxes and so forth. Combine that with something like game camera types ( https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true ) and you have the rules for a game. The list of rules is very long compared to most card, board and physical games but it is ultimately a finite/quantifiable list of rules.
With this you can then get someone to program a game to replicate this.
Theoretically you could also have people redo art and music but no intellectual property judge in the world is going to believe your 700 odd sprites and 40 minutes of music are identical. On the other hand you could make your own, as was done with Open Transport Tycoon deluxe.
You need not do all the rules either and may even improve things, however this is not the place for creative vs interpreted debate take 4000 (this week). That said games are not sacred immoveable goal posts and while I like rampart the idea of making a castle with tetris pieces while my mate does and then proceeding to pummel each other before doing it all again is great fun too.
Not many games have been remade in this manner, however it is far from unknown in general software development. It should also be noted that developers often release level editors and the like. These can help figure out how things are made.
2) Peek behind the curtain.
Hopefully some of you are familiar with rudimentary action replay style cheat finding. That is to say run a game, do a search, use one ammo, do a search, one more ammo, search... congratulations you have found where the ammo count is in memory.
Most stop there and have a cheat made to hold it steady or something. The would be game porter goes further and find the code that subtracts one and sees what happened before then. Before long you have rules of ammo consumption as the game itself has written down in probably immutable code (it is called Read Only Memory for a reason). To then use this knowledge to make a new program is considered illegal, and indeed if you are trying clean room from before it is held that anybody which has seen source, disassembly or in some cases even a leaked SDK (software development kit) for a console can not be allowed to contribute.
The basic tool to turn a ROM into assembly is called a disassembler, it is rare for one to be able to put it back together afterwards. There are very few games which have had this done, though pokemon red and blue are noted examples https://github.com/pret/pokered
It should also be noted you do not have to recreate things "bug for bug here"; if the end result is that the thing is multiplied by 4 then you don't have to copy two logical shifts and can just multiply straight by 4.
Lines can get blurry here --> no judge would likely begrudge you a capture card and a right arrow key, where peering into simple memory (but not code) gets you is a different debate. http://jolt.law.harvard.edu/digest/software/mdy-v-blizzard being one such example, for the other side the action replay and the like have been ruled legal on a few occasions, most notably http://www.darkshire.net/jhkim/rpg/copyright/cases/galoob_vs_nintendo.html
Going more modern then although compiling is still held to be a one way process, thanks to a concept known as the halting problem, http://www.cgl.uwaterloo.ca/csk/halt/
The walls are however coming down. Branch prediction means you can decompile a lot of C code and maybe even some C++ ( https://www.hex-rays.com/products/decompiler/ ), again much like assembly not in any means you might recompile or understand much from. Equally things like DLL function exporting is a thing. http://www.nirsoft.net/utils/dll_export_viewer.html
Java, covered a bit later in interpreted languages, has means to have code peeked at.
.NET/C# uses an awful lot of premade libraries. To that end it is more prone to being able to be decompiled than a lot of other theoretically lower level in the spectrum languages. https://www.jetbrains.com/decompiler/
For various things here you may also like http://www.radare.org/r/ which is free where some others are not.
3) Partial/game specific emulation.
Actually seen on the DS very early on
http://dl.qj.net/nintendo-ds/homebrew-games/international-karate-ds.html
The sega megadrive quite notably featured two processors, a 68K and a Z80. Aside from some clever demos the z80 was intended to handle the sound chips where the 68K did everything else. If you can do sound another way then you can lose the z80 from your emulator and have the game still run. This might save you a lot of headaches.
For an example of things coming the other way and timing needing to be ultra tight instead of the more relaxed approach some take elsewhere then http://arstechnica.com/gaming/2011/...-3ghz-quest-to-build-a-perfect-snes-emulator/ makes for a good read.
4) Interpreted games. Assembly coding (writing code to appear on the processor) is a pain for a lot of reasons. To that end very early on developers took to making things, possibly more limited than what might be achieved writing pure code ( http://www.catb.org/jargon/html/story-of-mel.html ) but still making things people wanted to play.
SCUMM, Sierra AGI/SGI and ZZT are examples of such thing, though some might argue they are engines more than interpreted languages.
Speaking of interpreted languages then the modern world sees a few. In games one of the more notable would be lua, which is also seen in some emulators to bring it around to those for a brief moment, which has seen many interesting games made in it. Java is a huge one here as well and is designed to be ported between platforms, give or take what happens with Oracle and Google in the coming months.
A modern twist on this might be the unreal engine or unity being used as a base. If a game is programmed in a known engine and that engine is available you might be able to tweak the known/available engine hard enough that you can run. Not many have attempted this for truly modern games, however older ones like Star Wars Dark Forces, a game which was highly regarded and has not seen a source release unlike many of its contemporaries, have seen some attempts to both crowbar into other similar engines or remake the engine.
Emulation.
Emulation for these purposes is boring. You can have usual rules of thumb like "the device wants to be 10 times as powerful as the thing it is emulating" if you like, though that is modified depending upon how close the host device is to the original, and the status of techniques like dynamic recompilation (dynarec) on the host system.
It was noted that on the DS you can have flash carts with their own hardware, and indeed the concept is also seen on the NES and SNES which frequently had extra chips and things on the cart to boost storage and processing power. Said own hardware on DS flash carts saw them easily far exceed in weeks what even some of the most talented developers on the DS did in years. In the end the person asking "can you port" might well mean "can I play one day", in which case that is a path that can be taken.
In the spirit of the enhanced flash carts question of the DS it should also be said that it is not impossible that you could run a game on a remote device and stream video and music and controller commands in the relevant directions.
You can modify games to do extra things in emulators, as anybody seeing things like 16:9 mods for gamecube games might have seen, as anybody seeing high resolution texture replacements might have seen, and as anybody seeing crazy things like texture replacement driven translation where people replace textures containing text with image edited (and presumably translated along the way) versions rather than more traditional ROM hacking https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ , or less crazy but still very cool things like lua enhancements.
You can also come at it the other way and mod games to work better in emulators. Most examples are things like the NES emulators on the GBA where tiles might have been cropped to achieve full screen on the GBA (which had a lower resolution than the NES) and thus made default text hard to read.
PC emulation is also a thing. The most obvious start for some would be the likes of dosbox which emulates old PCs pretty well, however it should be noted that virtual machines (as an end user you might be familiar with virtualbox https://www.virtualbox.org/ and the various vmware offerings http://www.vmware.com/products/fusion.html ) also feature the means to run a full machine and tap into it almost like any other emulator. They have long been considered useful for cheating purposes as the game would only be able to tell it is in a virtual machine (not inherently illegal) and not jump outside it to see if it was being debugged (part of most anti hack protections will scan a system for known debuggers which are active).
On we go
Introduction
Most games are programmed such that they run on a given system (most consoles) or a given class of systems (PC architecture on Windows being a common one), though as anybody that has ever had to update their graphics drivers to play a game will know the latter is not a flawless concept and even the former has its moments -- want to do link cable GBA games on a DS, aww.
On older systems this usually meant people writing raw code and maybe having images converted but more likely drawing them as they would appear on screen in the end.
Later systems made coding easier by allowing high level languages which turned easier to read and write code into the raw stuff as it would go into the CPU. This easier to read stuff is known as source code, and the act of turning it from high level to low level is known as compiling and for many intents and purposes is considered a one way process but more on that later.
There is a third class in interpreted languages. A very popular example is the SCUMM engine, popularised in the "emulator" known as SCUMMVM. More on this later as well.
Many take the position that without source code, or something like SCUMM, then you will not be able to port the game across. For most demonstrable practical purposes this is true enough. It is not however the whole story, not a by a long shot and that is ignoring pure emulation entirely.
Source code
Source code comes in one of two forms
1) A developer releases it.
2) It is leaked somehow.
Sometimes a developer releases it and ultimately has to retract it for various reasons. Popular ones include them using libraries they are not allowed to release code to (many games using the rad/bink video codec which devs have or have wanted to release have fallen foul of this).
In any case it is often observed that such sources do NOT come with a release of art, levels, music, names and concepts. Or if you prefer this is why though Doom has been released as source ( https://github.com/id-Software/DOOM ) you still have to provide your own WAD file.
Leaks and retractions make things tricky. Legally speaking you would be unlikely to be able to do much publicly with it, behind closed doors and by more covert means is a different matter entirely. That said being able to share the results of your work is nice so don't expect too much movement on leaked and retracted releases for source code, with a few minor exceptions if some of the troubles can be worked around.
Anyway list of once commercial games with some flavour of source release
https://en.wikipedia.org/wiki/List_of_commercial_video_games_with_available_source_code
Ground up remakes without source
1) Clean room style
Fighting games at the high end have been likened to chess by some people, up to you what you think there. Either way though you may have seen people able to recount stats for enemies, frame counter levels of positioning, move lists, hit boxes and so forth. Combine that with something like game camera types ( https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true ) and you have the rules for a game. The list of rules is very long compared to most card, board and physical games but it is ultimately a finite/quantifiable list of rules.
With this you can then get someone to program a game to replicate this.
Theoretically you could also have people redo art and music but no intellectual property judge in the world is going to believe your 700 odd sprites and 40 minutes of music are identical. On the other hand you could make your own, as was done with Open Transport Tycoon deluxe.
You need not do all the rules either and may even improve things, however this is not the place for creative vs interpreted debate take 4000 (this week). That said games are not sacred immoveable goal posts and while I like rampart the idea of making a castle with tetris pieces while my mate does and then proceeding to pummel each other before doing it all again is great fun too.
Not many games have been remade in this manner, however it is far from unknown in general software development. It should also be noted that developers often release level editors and the like. These can help figure out how things are made.
2) Peek behind the curtain.
Hopefully some of you are familiar with rudimentary action replay style cheat finding. That is to say run a game, do a search, use one ammo, do a search, one more ammo, search... congratulations you have found where the ammo count is in memory.
Most stop there and have a cheat made to hold it steady or something. The would be game porter goes further and find the code that subtracts one and sees what happened before then. Before long you have rules of ammo consumption as the game itself has written down in probably immutable code (it is called Read Only Memory for a reason). To then use this knowledge to make a new program is considered illegal, and indeed if you are trying clean room from before it is held that anybody which has seen source, disassembly or in some cases even a leaked SDK (software development kit) for a console can not be allowed to contribute.
The basic tool to turn a ROM into assembly is called a disassembler, it is rare for one to be able to put it back together afterwards. There are very few games which have had this done, though pokemon red and blue are noted examples https://github.com/pret/pokered
It should also be noted you do not have to recreate things "bug for bug here"; if the end result is that the thing is multiplied by 4 then you don't have to copy two logical shifts and can just multiply straight by 4.
Lines can get blurry here --> no judge would likely begrudge you a capture card and a right arrow key, where peering into simple memory (but not code) gets you is a different debate. http://jolt.law.harvard.edu/digest/software/mdy-v-blizzard being one such example, for the other side the action replay and the like have been ruled legal on a few occasions, most notably http://www.darkshire.net/jhkim/rpg/copyright/cases/galoob_vs_nintendo.html
Going more modern then although compiling is still held to be a one way process, thanks to a concept known as the halting problem, http://www.cgl.uwaterloo.ca/csk/halt/
The walls are however coming down. Branch prediction means you can decompile a lot of C code and maybe even some C++ ( https://www.hex-rays.com/products/decompiler/ ), again much like assembly not in any means you might recompile or understand much from. Equally things like DLL function exporting is a thing. http://www.nirsoft.net/utils/dll_export_viewer.html
Java, covered a bit later in interpreted languages, has means to have code peeked at.
.NET/C# uses an awful lot of premade libraries. To that end it is more prone to being able to be decompiled than a lot of other theoretically lower level in the spectrum languages. https://www.jetbrains.com/decompiler/
For various things here you may also like http://www.radare.org/r/ which is free where some others are not.
3) Partial/game specific emulation.
Actually seen on the DS very early on
http://dl.qj.net/nintendo-ds/homebrew-games/international-karate-ds.html
The sega megadrive quite notably featured two processors, a 68K and a Z80. Aside from some clever demos the z80 was intended to handle the sound chips where the 68K did everything else. If you can do sound another way then you can lose the z80 from your emulator and have the game still run. This might save you a lot of headaches.
For an example of things coming the other way and timing needing to be ultra tight instead of the more relaxed approach some take elsewhere then http://arstechnica.com/gaming/2011/...-3ghz-quest-to-build-a-perfect-snes-emulator/ makes for a good read.
4) Interpreted games. Assembly coding (writing code to appear on the processor) is a pain for a lot of reasons. To that end very early on developers took to making things, possibly more limited than what might be achieved writing pure code ( http://www.catb.org/jargon/html/story-of-mel.html ) but still making things people wanted to play.
SCUMM, Sierra AGI/SGI and ZZT are examples of such thing, though some might argue they are engines more than interpreted languages.
Speaking of interpreted languages then the modern world sees a few. In games one of the more notable would be lua, which is also seen in some emulators to bring it around to those for a brief moment, which has seen many interesting games made in it. Java is a huge one here as well and is designed to be ported between platforms, give or take what happens with Oracle and Google in the coming months.
A modern twist on this might be the unreal engine or unity being used as a base. If a game is programmed in a known engine and that engine is available you might be able to tweak the known/available engine hard enough that you can run. Not many have attempted this for truly modern games, however older ones like Star Wars Dark Forces, a game which was highly regarded and has not seen a source release unlike many of its contemporaries, have seen some attempts to both crowbar into other similar engines or remake the engine.
Emulation.
Emulation for these purposes is boring. You can have usual rules of thumb like "the device wants to be 10 times as powerful as the thing it is emulating" if you like, though that is modified depending upon how close the host device is to the original, and the status of techniques like dynamic recompilation (dynarec) on the host system.
It was noted that on the DS you can have flash carts with their own hardware, and indeed the concept is also seen on the NES and SNES which frequently had extra chips and things on the cart to boost storage and processing power. Said own hardware on DS flash carts saw them easily far exceed in weeks what even some of the most talented developers on the DS did in years. In the end the person asking "can you port" might well mean "can I play one day", in which case that is a path that can be taken.
In the spirit of the enhanced flash carts question of the DS it should also be said that it is not impossible that you could run a game on a remote device and stream video and music and controller commands in the relevant directions.
You can modify games to do extra things in emulators, as anybody seeing things like 16:9 mods for gamecube games might have seen, as anybody seeing high resolution texture replacements might have seen, and as anybody seeing crazy things like texture replacement driven translation where people replace textures containing text with image edited (and presumably translated along the way) versions rather than more traditional ROM hacking https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ , or less crazy but still very cool things like lua enhancements.
You can also come at it the other way and mod games to work better in emulators. Most examples are things like the NES emulators on the GBA where tiles might have been cropped to achieve full screen on the GBA (which had a lower resolution than the NES) and thus made default text hard to read.
PC emulation is also a thing. The most obvious start for some would be the likes of dosbox which emulates old PCs pretty well, however it should be noted that virtual machines (as an end user you might be familiar with virtualbox https://www.virtualbox.org/ and the various vmware offerings http://www.vmware.com/products/fusion.html ) also feature the means to run a full machine and tap into it almost like any other emulator. They have long been considered useful for cheating purposes as the game would only be able to tell it is in a virtual machine (not inherently illegal) and not jump outside it to see if it was being debugged (part of most anti hack protections will scan a system for known debuggers which are active).
