> I had to find names that would allow the variables to appear in the correct order. So after some trial and error, I wrote a small throw-away program that generated a bunch of variables with random names and ran that list of variables through the Turbo C++ compiler. Disassembling the generated .OBJ file showed me which order these variable names would produce
Nice puzzle!
Is the ordering the only thing that can be recovered from the binary? If the hash is available anywhere, it should be possible to brute force the exact original names.
If you throw away the debug info, and don't use any generated introspection magic, there's nothing preserved normally. Compiled C code doesn't need to know the names after all. There are various leaks though - for example asserts and other debug macros/prints often end up revealing the names.
Looking through the readme, it seems this is a "matching decomp" type project which does not bundle assets (i.e. those get pulled from your local copy during the build).
I'm no lawyer, and this is no claim that it is/isn't one way or the other, but Super Mario 64 had a CC0 1.0 licensed decomp in 2019 with PC port in 2020 and Nintendo vehemently chased compiled copies of the game being shared and videos of the ports on YouTube but never went after the actual source code repo for either the decomp or port (which do not contain any of the assets). Of course there is nothing saying Nintendo can't wait 6 years and then issue action (just look how long they put up with Yuzu/Ryujinx before going after the decryption and other arguments just before the Switch 2 launched), but they were certainly aware of it when they took action against the resulting binaries/videos and didn't try to touch the code repo yet for one reason or another.
I expect some big court case to happen about this style of project within the next decade. Maybe not as big as Google LLC v. Oracle America, Inc., but still one that makes the news a fews times and gives direct precedent rather than comparisons to similarish cases.
It's not legal unless the person had the rights to begin with. It may be legal for a clean room reimplementation, but not a decompilation project like this. iD/Apogee can totally request a takedown, so I wouldn't recommend republishing that...
Copyright violation. If you write a book and I translate it to a different language you own the copyright on my translation. (except poetry which is artistic enough that it cannot be translated and so your version inspires me but I can't just translate it ). Decompilation doesn't have enough creative work to call it anything other than a translation.
I'm not a lawyer. I'm reasonably sure I'm right so the above is good enough for discussion, but if you need legal advice see a lawyer.
Actually you should look up the info there, you actually don’t which is what a lot of fansubs rely on, they mostly only will own your translation if they chose to formally translate and publish commercially a translation in that country. If they don’t, you can distribute your translation for free. There is a lot of variability on this per country too, with very interesting laws in greece and germany in particular.
> They used the same routines they wrote for their day jobs at Softdisk in the Keen code. [...] Most of the IDLIB.C code must have come directly from the PC version of Dangerous Dave. [...] there is some extremely strong evidence showing that the id founders used Softdisk's code in their own game. Sure, it's not the code responsible for the smooth scrolling, but it is code they probably didn't have the rights to use.
Huh, this is interesting. Is someone able to provide more detail?
The pace at which Id produced games has always been an inspiration for me. Large amounts of code reuse seems like an important clue as to how they were able to do that.[1] But how were they able to reuse code effectively to such a degree?
[1]: The other clues I have so far are Romero's legendary tool-making abilities, and Carmack's tendency to produce code that gets computers to do things they couldn't before.
Id Software very much skirted the edge of legality by making Commander Keen outside of office hours while still employed by SoftDisk and using SoftDisk computers, and SoftDisk could have easily sued them if they wanted to. They managed to avoid that by striking a deal where the Id guys would continue to make games for SoftDisk while working on Keen and later Wolfenstein 3D.
There was a lot of code reuse between games. John Carmack is on record somewhere that the enemy navigation code from Doom and Quake still has its origins in some of the earliest 8-bit games he wrote in the 1980's.
I'm pretty sure that it's not exactly about the code, it's a case of having honed skills and techniques from multiple different sources - John Romero was bouncing around the industry and working on both larger and smaller productions, multiplatform ports, and different approaches to engine/content(he got his hands on both Origin's and Infocom's stuff, as well as a few other places) - the number of references he brought to the table could not be underestimated. John Carmack didn't have that same experience but would have been able to take a description from Romero of "at Origin we did it like this" and aim to make a very efficient version of it - his growth into borrowing academic research for inspiration came a little later. And there was also the early influence of Tom Hall who was older, able to communicate what he wanted as a producer and probably steered the programming team away from wrong turns a few times.
When you have the experience, you already know how long it takes to implement the majority of the game, when we're speaking of these early 2D games using bitmaps, tiles, small animations and some monospace text. The gameplay code is game-jam sized in most instances, so a majority of it was I/O code and asset pipelines. You can chart a safe course to get through one tiny project, and then another, and another, and build a best-of the routines that worked. The coding style would be assembly-like at this time even if they were using C - no deep callstacks, mostly imperative "load and store", which allows for a lower level form of reuse than is typical these days by breaking down the larger algorithm into "load", "mutate", "mutate", "mutate", "store" each as separate routines. So you end up with some tight code when you get to run it through a lot of projects. Softdisk provided the opportunity for building that and getting paid.
In Masters of Doom they are depicted as taking work computers out of the office to go work on their side project. I doubt IP would be the thing they’d stand on.
To some degree this is amusing. For a decade or so, we people would talk about the “borrowed” PCs. Now hacker forums talk about who owns the IP. In my childhood I never would have guessed this culture shift towards IP maximalism but I imagine the lesson that copyleft licenses only work in a copyright enforced environment finally took!
Yes, interesting shift in perspective that hackers now kind of use blackhat-techniques to do forensic analysis in regards to ownership. In the earlier days we cracked games to hypocritical free them of their perceived handcuffs. Hence "Free Software". Code was free and can be used and reused by anybody.
Of course due to litigation and legal implications the statements in Masters of Doom are intentionally vague. The same goes for the founder's talks. No one lied or portrayed themselves in a ubermensch fashion, it was just talking in corporate language speak when you are not allowed to provide more details in public. There seems to be serious legal risk and maybe it got solved or not, but judging from the book's perspective, I believe that they solved the issue in combination with a non-disclosure agreement.
I think that the "Great artists steal" mantra is especially applicable to ID's early days. And code reuse is simply a variance - stealing from yourself.
In no way does the usage of third party libraries damage the ID myths. For example, owning IP and authorship is not the same. Also: one can use a programming framework for a below average app while another one builds an awesome app.
And this is what's MoD underlying theme: going your own way because you see a chance while staying in the current context. In the end, ID did what Softdisk did: developing and publishing games. One only with moderate success while the other conquered the world.
Latin alphabet epitomizes this day by day. 26 letters which seem laughable, but a fool with a great tool is still a fool. ;)
https://forums.gentoo.org/
Nice puzzle!
Is the ordering the only thing that can be recovered from the binary? If the hash is available anywhere, it should be possible to brute force the exact original names.
This is released under GPL.
I wonder, who is K1n9_Duk3? Does he have the rights to actually release this, and put it under GPL?
What does "reconstructed" mean? Is this disassembled? And if so, is it really ok to put this under GPL then?
I'm no lawyer, and this is no claim that it is/isn't one way or the other, but Super Mario 64 had a CC0 1.0 licensed decomp in 2019 with PC port in 2020 and Nintendo vehemently chased compiled copies of the game being shared and videos of the ports on YouTube but never went after the actual source code repo for either the decomp or port (which do not contain any of the assets). Of course there is nothing saying Nintendo can't wait 6 years and then issue action (just look how long they put up with Yuzu/Ryujinx before going after the decryption and other arguments just before the Switch 2 launched), but they were certainly aware of it when they took action against the resulting binaries/videos and didn't try to touch the code repo yet for one reason or another.
I expect some big court case to happen about this style of project within the next decade. Maybe not as big as Google LLC v. Oracle America, Inc., but still one that makes the news a fews times and gives direct precedent rather than comparisons to similarish cases.
Based on what? Afaik decompilation is a grey area and projects that enforce clean-room design do it to stay out of this grey area.
I'm not a lawyer. I'm reasonably sure I'm right so the above is good enough for discussion, but if you need legal advice see a lawyer.
Not quite true. You and I both own the copyright to your translation. Neither of us can publish it without the other's permission.
Huh, this is interesting. Is someone able to provide more detail?
The pace at which Id produced games has always been an inspiration for me. Large amounts of code reuse seems like an important clue as to how they were able to do that.[1] But how were they able to reuse code effectively to such a degree?
[1]: The other clues I have so far are Romero's legendary tool-making abilities, and Carmack's tendency to produce code that gets computers to do things they couldn't before.
There was a lot of code reuse between games. John Carmack is on record somewhere that the enemy navigation code from Doom and Quake still has its origins in some of the earliest 8-bit games he wrote in the 1980's.
When you have the experience, you already know how long it takes to implement the majority of the game, when we're speaking of these early 2D games using bitmaps, tiles, small animations and some monospace text. The gameplay code is game-jam sized in most instances, so a majority of it was I/O code and asset pipelines. You can chart a safe course to get through one tiny project, and then another, and another, and build a best-of the routines that worked. The coding style would be assembly-like at this time even if they were using C - no deep callstacks, mostly imperative "load and store", which allows for a lower level form of reuse than is typical these days by breaking down the larger algorithm into "load", "mutate", "mutate", "mutate", "store" each as separate routines. So you end up with some tight code when you get to run it through a lot of projects. Softdisk provided the opportunity for building that and getting paid.
To some degree this is amusing. For a decade or so, we people would talk about the “borrowed” PCs. Now hacker forums talk about who owns the IP. In my childhood I never would have guessed this culture shift towards IP maximalism but I imagine the lesson that copyleft licenses only work in a copyright enforced environment finally took!
But carrying your full-size tower computers and CRT monitors home from the office at night/weekends sounds crazy.
Of course due to litigation and legal implications the statements in Masters of Doom are intentionally vague. The same goes for the founder's talks. No one lied or portrayed themselves in a ubermensch fashion, it was just talking in corporate language speak when you are not allowed to provide more details in public. There seems to be serious legal risk and maybe it got solved or not, but judging from the book's perspective, I believe that they solved the issue in combination with a non-disclosure agreement.
I think that the "Great artists steal" mantra is especially applicable to ID's early days. And code reuse is simply a variance - stealing from yourself.
In no way does the usage of third party libraries damage the ID myths. For example, owning IP and authorship is not the same. Also: one can use a programming framework for a below average app while another one builds an awesome app.
And this is what's MoD underlying theme: going your own way because you see a chance while staying in the current context. In the end, ID did what Softdisk did: developing and publishing games. One only with moderate success while the other conquered the world.
Latin alphabet epitomizes this day by day. 26 letters which seem laughable, but a fool with a great tool is still a fool. ;)
Carmack was a genius.