I was wondering how a computer patch works. How do you add code to already compiled code? Or are the patches a .exe that is run the same time that the other program is run and everytime you hit the “bug” the patch takes over for an instance.
I think a patch contains a program that simply overwrites data (code data not database data - but just 1’s and 0’s) with the new code data. Some patches fully replace an executable (the old exe file is deleted).
In the early days of more rigid release controls and smaller file sizes, some patches did do “cut and paste” of binary code. This is not practical anymore, and most all of them overwrite the entire file - which is much safer, IMO.
a patch overwrites a file that contains bugs with a file that does exactly the same, but without the bug.
in your example, if the file a.exe contains an error, a patch simply copies a newer version of a.exe over the old one.
In the current era of program and library interdependance, it is very improtant that the structure of the in- and output is remains the same for patched files.
It almost sounds as if patches act alot like a virus. Would patches be written in assembly. If so, that’s good news because it gives me a reason to actually try and sit through the lectures and actually learn the friggen language.
who uses assembly these days? Basically, you just alter the code and then recompile.
nope, it’s not a virus, although to a certain extent, virusses do work in the same way. Biggest difference? A virus doesn’t ask for the user’s permission.
Note that there are two types of patches: binary and source code. It appears that cykrider is asking about binary patches.
There are several reasons to patch part of an executable (which includes .exe, .com, .dll and a host of other types in MS-DOS land.) I don’t like the key associations in doskey, so I went into a binary editor, found the key codes and changed them. I saved the info on what I did so that I made the same changes as I upgraded from Win95 to Win98 to Win98SE. (Each came with a slightly different version of doskey.) I have done similar things to a lot of programs over the years. I just like customizing things.
Gamers might want to patch a game to give more lives or other attributes. Lot’s of sites out there that give such patches. (Seems like just cheating to me.) My kids used to play SimCity and I patched it so it would stop the annoying copy protection Q&A. A legal copy mind you, just hated the nuisance.
Similarly, some people modify programs that have a builtin limitation to remove that limitation.
In most of these cases, the patches are done manually using a hexeditor. Just a few bytes need to be changed in most cases. It’s possible to run some as scripts to a patch editor but that’s less safe.
Note that changing a few bytes doesn’t create a virus or some such.
Many EULAs forbid such changes, but are probably not legally enforcable regarding what you do with your own personal copy. Distribution of such changes are a whole 'nother matter.
“Crackers” that break a sophisticated copy protection scheme will provide a cracked copy of the program/dll. But who knows what else they did to it. You get what you deserve when you enter that world.
It’s inconceivable that a person could consider themselves a computer programmer and not know assemby. May as well not learn binary arithmetic while you’re not at it. Just because you might not use it directly doesn’t mean that you won’t need to apply the concepts.
No it’s not. I took assembly in college. I’ve never used it, I don’t remember it. The concepts can be learned in a higher level language and it will translate to other languages easier.
There are two kinds of software patches: the kind that modifies the target software on your hard disk itself, and the kind that modifies the code structure in RAM alone (and therefore has to load each time after the original software code loads so as to patch it).
An example of the first type would be the upgrade patch that FileMaker released that changes FmPro version 5.0v1 to 5.0v3. The program file itself on your hard drive is modified with resources that were originally in the patch file, while other parts of the program file remain as they were. (The patch is considerably smaller than the original program file it modifies). After patching, you could throw the patch away, it’s done its job.
An example of the second type would be a Macintosh System Extension. As the OS boots up, after it loads the code from the System File and the ROM, it loads all the patching codes from files located in the Extensions and Control Panels folder. An extension called “MacLink Plus”, for example, prompts the OS to pop up a translation options menu when you double-click a file document for which you lack the regular program to open it natively, or if you do a contextual click on any file that can be translated. If you disable this extension by removing it from the Extensions folder (or boot up with all extensions off by holding down the shift key), the patch does not occur and the OS lacks these additional instructions on what to do when you click on a file.
There are different types of software patches. At our company, we generally release a “patch” that is the entire .exe file. To install the patch you simply replace the older .exe (or other file type, it’s not always an exe that has the bug).
I have also seen software that will modify one .exe file and make it into another .exe file. These types of patches were more popular when people were much more concerned with file sizes, since the software that modifies the .exe only needs to contain the changes and a list of where the changes to the binary file occur, it can be much smaller than a replacement .exe. This also allows you to place a patch on a freely available site (such as a web page) without releasing your entire executable code to the public.
Another type of patch is where you modify the binary itself, not the source code. This is more difficult since you don’t have a compiler and linker to automatically move code around for you if you add something. Hackers will often do this sort of thing to go into the code and bypass the serial number or license check. It does have some uses for legitimate software as well.
ftg - FYI, assembly language programmers tend to make very poor object oriented (C++ windows type of code) programmers, and vice versa. It is not at all uncommon for a C++ programmer to know very little, if any, assembly code.
I’m not terribly fluent in assembly, but I have to agree with ftg. You don’t necessarily need to know it to actually code in it, but it does help you make the most of a higher-level language.
Optimization is a prime example: if you know what high-level sytnax translates to in assembly, then you can really optimize certain operations by doing things that would seem non-intuitive if you only consider the high-level language. Your programs will work just fine without considering the implications of what the assembly version looks like, but that’s the difference between “works” and “damn that works”.
I guess I’m failing to see why I would need to know (or remember) assembly to know how to optimize my programs. I already realize that certain functions work better than others. It may be more complicated to code, and work fine on the small scale, but when that code is called 1000’s of time during the course of a day then the savings in speed is worth the obscurity in coding. After all, if it’s commented properly it doesn’t matter that the function of the code is not readily transparent.
This is OT, so I don’t mean to belabor the issue, but…
When you’re optimizing, you can either remember a bunch of rules about optimal methods, or you can rely on a knowledge of assembly to make up the rules as you go along. Someone who’s good at assembly can just look at higher-level code and see that this loop or that operation is going to be convoluted when it’s reduced to assembly, but if you write it some other way it will be better, faster, stronger. For example, in this thread Punoqllads pointed out that you could speed up a loop by using addition instead of multiplication. I don’t think that’s obvious if you only know the higher-level language.
A lot of optimization, things like unrolling loops, can be done at the higher language level. However, a lot of it relies on either an intuition about assembly or a rote knowledge of checklists made by someone with that intuition. I’d rather know than memorize, so I lean toward figuring out what the assembly constructs look like for any given operation.
Having worked in a compiler group for many years, many (most) user written optimizations are inferior to what a good compiler can do with the code. Compilers these days (I worked on the DEC/Compaq/HP Unix C/C++ compilers) do so much behind the scenes that your best bet is to write ANSI code and let the compiler do the rest. It’s really amazing what goes on between the silicon and the compiler, and no human can keep track of it all.
And while I did study assembler, I haven’t used it much in the past 15 years. I know plenty of excellent programmers who don’t know assembler and won’t ever need it.
BTW, we also did “paper patches”, English instructions for users to go into a hex editor and make changes to the executables. I’m amazed we got that one through release engineering, but it was much safer than a re-build since it only affected about 6 people in the world.
Agreed, so I’ll just add one thing. Apparently I remember the underlying concepts of how things work without realizing it, because I don’t memorize, I understand. Hmm… I like salt with my foot thanks.