Disassembler
in [Cobol]
|
From: on 28 Feb 2006 10:53 In article <irq80217of9dtubreb3fclfq3789d9r71d(a)4ax.com>, Howard Brazee <howard(a)brazee.net> wrote: >On Tue, 28 Feb 2006 14:48:50 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>>I worked in a place where an operator dropped a whole tray of punched >>>jcl cards (and successfully mixed them quicker than a poker dealer >>>could have done). >> >>Oh, I *cannot* resist... >> >>000100 AND WITH THESE AND OTHER INSTANCES IN MIND WE SHOULD, THEREFORE, >>000200 MAKE SURE THAT ALL CODE IS BACKWARDSLY-COMPATIBLE WITH SUCH >>000300 LIMITATIONS... JUST BECAUSE I HAVEN'T WORKED WITH A PUNCHED DECK >>000400 IN DECADES IS NO REASON NOT TO 'JUST IN CASE' THINGS, RIGHT? > >Belts and suspenders. Put sequence numbers in columns 1-6 and in >73-80 just to be safe. Sorry, positions 73-80 are for MODCODE notation, in the format xxYYMMDD, where 'xx' are the initials of the programmer... which, of course, makes for Big Fun when someone copies-n-pastes a chunk of your code into another part of the program. >You never know when you might spill your >hard drive. .... and lose all 10Mb of data? That's a frightening thought! DD
From: CG on 28 Feb 2006 19:17 Howard Brazee wrote: > On Mon, 27 Feb 2006 14:24:13 -0500, CG > <carl.gehr.RemoveThis(a)ThisToo.attglobal.net> wrote: > >>>> If you prefer, call it a DisCOBOLER instead of a DisASSEMBLER. >>> I think the term traditionally used is "decompiler". >> Yeh! I thought about that, but Pete seemed so hung up on the specific >> language, that seemed more to the point. > > I suppose you could decompile code into just about any language you > want. The more optimized the code, the more useless the decompiled > results. You seem to insist on ignoring [or just being ignorant of] the fact that this technology guarantees to create COBOL code that will produce exactly the same output as the object code. In fact, I believe that the new COBOL source, when compiled, will normally produce exactly the same object code _assuming_ you have the same version/release/level/etc. of the compiler that produced the original. If the code was optimized before _and_ you indicate that the re-compile is to optimize the new code, it will be the same. Therefore, the decompiled COBOL code is exactly as useful or useless as it would be if you had the original source code. If you still consider this code to be useless, then I assume your process is always to trash every source program as soon as you compile it. That is the essence of what you are proposing. I really cannot understand your logic!
From: Howard Brazee on 1 Mar 2006 09:35 On Tue, 28 Feb 2006 19:17:03 -0500, CG <carl.gehr.RemoveThis(a)ThisToo.attglobal.net> wrote: >> I suppose you could decompile code into just about any language you >> want. The more optimized the code, the more useless the decompiled >> results. >You seem to insist on ignoring [or just being ignorant of] the fact that >this technology guarantees to create COBOL code that will produce >exactly the same output as the object code. I seem this way? Interesting. At any rate, it doesn't matter which language you decompile the object code to - you could say the same thing - that recompiling it should create the exact same object code. I don't know if this is true - the optimizing compiler might not make the exact same decisions that the decompiler did. But I also don't know if that makes any difference. >In fact, I believe that the >new COBOL source, when compiled, will normally produce exactly the same >object code _assuming_ you have the same version/release/level/etc. of >the compiler that produced the original. If the code was optimized >before _and_ you indicate that the re-compile is to optimize the new >code, it will be the same. Again, I don't know if this is true, but I really don't care. But I am sure that the decompiled code doesn't look at all like the original code that was structured for easy maintenance, with meaningful field names, and comments. >Therefore, the decompiled COBOL code is >exactly as useful or useless as it would be if you had the original >source code. So you don't believe meaningful names are useful? So you don't believe structure designed for maintenance is useful? Interesting. > If you still consider this code to be useless, then I >assume your process is always to trash every source program as soon as >you compile it. That is the essence of what you are proposing. I >really cannot understand your logic! Odd. If I considered this code to be useless, then the *last* thing I would do would be to trash every source program as soon as I compile it. Only if I considered it to be as useful as the original source code would I do that. While I haven't found that I proposed anything in this thread, this would be way down upon the lists of things that I might propose. I suppose the main reason you can't understand my logic is that you made a bunch of assumptions about stuff that wasn't stated.
From: Oliver Wong on 1 Mar 2006 09:40 "CG" <carl.gehr.RemoveThis(a)ThisToo.attglobal.net> wrote in message news:41d3d$4404e7ff$453db2dd$1883(a)FUSE.NET... > Howard Brazee wrote: >> >> I suppose you could decompile code into just about any language you >> want. The more optimized the code, the more useless the decompiled >> results. > > You seem to insist on ignoring [or just being ignorant of] the fact that > this technology guarantees to create COBOL code that will produce exactly > the same output as the object code. In fact, I believe that the new COBOL > source, when compiled, will normally produce exactly the same object code > _assuming_ you have the same version/release/level/etc. of the compiler > that produced the original. If the code was optimized before _and_ you > indicate that the re-compile is to optimize the new code, it will be the > same. Therefore, the decompiled COBOL code is exactly as useful or > useless as it would be if you had the original source code. If you still > consider this code to be useless, then I assume your process is always to > trash every source program as soon as you compile it. That is the essence > of what you are proposing. I really cannot understand your logic! Source code exists not for the benefit of computers, but for the benefit of humans. Computer would be just as happy if source code never existed, and everything was written directly in machine code. But to give humans an understanding of the behaviour of a program, source code is very helpful. For a given program behaviour, there exists multiple source codes which will produce that exact same behaviour. Some of these source codes are more difficult for humans to understand than others. Howard (and others) are making the claim that if you decompile a program, the source code you are likely to get will be very difficult for humans to understand. In that sense, the source code is "useless" because the main use of source code is to give understanding to humans. See http://groups.google.ca/group/comp.lang.cobol/msg/c9afd03ff070610a for example; this program outputs the fibbonacci sequence, but it is difficult for a human to understand it, and thus to safely modify it. Let's say you had a program which printed out the first 20 fibbonacci numbers, and you wanted to update the program to print out the first 40 fibbonacci numbers instead. If you decompiled the program and got something like the above, it'd almost be easier just to start over from scratch. But if you had the original source code for the 20-fibbonacci program, and assuming it was "properly" written, it should be a relatively simple task to modify it so it prints the first 40 fibbonacci numbers instead. That's an example of how the original source can be useful while the decompiled source be useless. - Oliver
From: CG on 1 Mar 2006 12:46
Howard Brazee wrote: > On Tue, 28 Feb 2006 19:17:03 -0500, CG > <carl.gehr.RemoveThis(a)ThisToo.attglobal.net> wrote: > >>> I suppose you could decompile code into just about any language you >>> want. The more optimized the code, the more useless the decompiled >>> results. >> You seem to insist on ignoring [or just being ignorant of] the fact that >> this technology guarantees to create COBOL code that will produce >> exactly the same output as the object code. > > I seem this way? Interesting. YES! > > At any rate, it doesn't matter which language you decompile the object > code to - you could say the same thing - that recompiling it should > create the exact same object code. It does! > > I don't know if this is true - the optimizing compiler might not make > the exact same decisions that the decompiler did. But I also don't > know if that makes any difference. Please re-read what I said: Given the same compiler at the same level, with the same options, the compiler will generate the same code. > >> In fact, I believe that the >> new COBOL source, when compiled, will normally produce exactly the same >> object code _assuming_ you have the same version/release/level/etc. of >> the compiler that produced the original. If the code was optimized >> before _and_ you indicate that the re-compile is to optimize the new >> code, it will be the same. > > Again, I don't know if this is true, but I really don't care. But I > am sure that the decompiled code doesn't look at all like the original > code that was structured for easy maintenance, with meaningful field > names, and comments. > >> Therefore, the decompiled COBOL code is >> exactly as useful or useless as it would be if you had the original >> source code. > > So you don't believe meaningful names are useful? So you don't > believe structure designed for maintenance is useful? I never mentioned structured design! And, I already said the technology would PRODUCE meaningful names if you can simply give it the names to use for known fields. > > Interesting. > >> If you still consider this code to be useless, then I >> assume your process is always to trash every source program as soon as >> you compile it. That is the essence of what you are proposing. I >> really cannot understand your logic! > > Odd. If I considered this code to be useless, then the *last* thing > I would do would be to trash every source program as soon as I compile > it. Only if I considered it to be as useful as the original source > code would I do that. While I haven't found that I proposed > anything in this thread, this would be way down upon the lists of > things that I might propose. > > I suppose the main reason you can't understand my logic is that you > made a bunch of assumptions about stuff that wasn't stated. And, YOU have made a bunch of assumptions about the technology that started this discussion when you appear to have no knowledge of it. So, while your generalizations about decompilers may be true IN GENERAL, this technology is far more than just a 'decompiler' it is 'source recovery' technology. And, as I mentioned very early in the thread, if you happen to have record layouts for files, etc., that are used by the program, the resulting program WILL have meaningful names. I find it rather amazing that so many people like to discuss a specific technology without having any knowledge of that technology. And, worse, they have so many negative views about the resulting code, but have never seen any of the results. I have not heard these complaints from any of the companies that have had their source recovered. If anyone has, please be specific instead of condemning generalities. This discussion has deteriorated to to the point of absurdity. When the attitude appears to be, "My mind's made up, do not confuse me with facts." it is time to quit! I'm done! |