<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/
