RE: [U2] Deciphering Pick UniBasic statement
Caleb's. It could take days to unravel the code by hand versus the few minutes needed to send it out to www.srs4uv.com. From one horror story I read on the site about a programmer that had sabotaged source code: The company used the SRS on the object code they were running. In addition, they compiled the suspect source code and used the SRS on that set. By comparing the two source code result sets they figured out which programs had been sabotaged. Why not simply compare the binaries ? Unix has a small program called: cmp that can compare two files and Windows has comp. You can tell which ones have been changed that way. You can also know when the files were last compiled by looking at the dates with ls -al on the binary. Still I think the decompiler can be a useful tool. I've worked with a client who purchased a package some years back and they only have the binaries. If the supplier ever goes out of business they are in trouble. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Comparing object code [Was: Deciphering Pick UniBasic statement]
Hello, Jacques. Jacques G. wrote... From one horror story I read on the site about a programmer that had sabotaged source code: The company used the SRS on the object code they were running. In addition, they compiled the suspect source code and used the SRS on that set. By comparing the two source code result sets they figured out which programs had been sabotaged. Why not simply compare the binaries ? Unix has a small program called: cmp that can compare two files and Windows has comp. You can tell which ones have been changed that way. There are several challenges with binary comparison of object code. Different releases of a compiler may generate slightly different object code. The code will execute properly, but the differences foil the comparison. Here are some of the most frequent differences encountered: 1) The way the UV compiler allocates temporary registers has changed many times over the releases. 2) The way the UV compiler issues NOP instructions to maintain alignment has changed from release to release. 3) Newer op-codes may be used by later compilers. 4) The flavor of the account, the $OPTIONS that are set, or the compiler command line options may cause the use of different op-codes. 5) The path to the original source code, stored in the object code may be different and cause the comparison to fail otherwise identical object code. I have been developing a program that analyzes all of the source code, object code and cataloged programs on a system, trying to determine if any of the object code or cataloged programs are missing their source code. For the reasons listed above, this is not a trivial exercise. If any end-users are interested in being an alpha site come February 2006, drop me a note off-list. You can also know when the files were last compiled by looking at the dates with ls -al on the binary. That works as long as the files have not been touched. Still I think the decompiler can be a useful tool. I've worked with a client who purchased a package some years back and they only have the binaries. If the supplier ever goes out of business they are in trouble. We provide the source recovery service to help end-users when their application supplier is unable, for whatever reason. Some of our customers are actually application suppliers. They bring us in when they are unable to help the client. They work with us to help the customer become whole or self-sufficient. Best regards, Gyle www.srs4uv.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Deciphering Pick UniBasic statement
snip I've worked with a client who purchased a package some years back and they only have the binaries. If the supplier ever goes out of business they are in trouble. /snip I must offer my opinion here on VAR-delivered object-code only systems. If I had any say in such a situation, I would require that the VAR place the source code that matches my purchased (licensed) system in escrow or some 3rd party place. I've run into a few prospective client situations that I could not turn into actual clients as I had nothing to work with. When the relationship is active or current, it's a nice deal for both the VAR and the client. The client gets current updates etc and the VAR has a locked in client. But when the VAR goes out of business, the client has a system with no source code and eventually it screws the entire MV community as in all of my examples, the replacement system wasn't MV-based. I don't want to digress into a debate on the merits of software licensing etc. That gets too out of hand. But when a VAR goes out of business and leaves no source code behind. No-one wins. Perhaps anyone in this current situation should re-negotiate the terms of their relationship with an application VAR who doesn't provide the source code. Otherwise, if the VAR folds, you're screwed. One VAR pulling a similar deceitful move removed from all of the dictionaries those dict items that weren't part of any English reports or Select statements. Think about it, if field 39 is used only in data/basic programs, it really doesn't need to have a dict item to work. I've spent many hours (and my client's $) backfilling missing dict items from source code. Likewise for source code with comments removed. If this were 1984 we would all have to play it a little closer. But it's 2005 and we should stick together because it really is MV versus other databases and not UD versus UV or MCD vs ULT or ADDS vs Sanyo etc. United we stand.. My 2 cents. Mark Johnson - Original Message - From: Jacques G. [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Sunday, December 11, 2005 11:31 AM Subject: RE: [U2] Deciphering Pick UniBasic statement Caleb's. It could take days to unravel the code by hand versus the few minutes needed to send it out to www.srs4uv.com. From one horror story I read on the site about a programmer that had sabotaged source code: The company used the SRS on the object code they were running. In addition, they compiled the suspect source code and used the SRS on that set. By comparing the two source code result sets they figured out which programs had been sabotaged. Why not simply compare the binaries ? Unix has a small program called: cmp that can compare two files and Windows has comp. You can tell which ones have been changed that way. You can also know when the files were last compiled by looking at the dates with ls -al on the binary. Still I think the decompiler can be a useful tool. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
