Forum Home
PC World Chat
Thread ID: 68228	2006-04-21 23:17:00	Source code, compliers and all that jazz.....	Billy T (70)	PC World Chat

Post ID	Timestamp	Content	User
448302	2006-04-21 23:17:00	Hi Team I am working on a technical problem with a group of clients in the US and need to get some terminological accuracy sorted out. I am no whiz on the deeper workings of computers so best I ask the experts. The issue relates to a machine controlled by a Z80 processor, and there are arguments about whether the programming is appropriate for the purpose. My clients have been arguing via the courts to get access to the source code, but their attempts to obtain it have been frustrated by denials of control, i.e. the other party says they don't have ownership or access to the source code. I think that those statements could well be true, because I suspect that the defending company was probably smart enough to insert a "chinese wall" between the writers and owners of the source code, and the compiled version that they as the end user install in their machines. My gut feeling is that my clients are on the wrong track chasing the source code anyway, because it is my understanding that source code is assembly language, and has to be compiled to become useable by the Z80. If I am correct, then it logically follows that once compiled the other party must have access to it because they need to load it into Eproms for the machine to operate. I also believe that once compiled, it is readily possible for a person with the appropriate skills to read the code and see what the Z80 is being asked to do. If this is true, then the issue over the appropriateness of the programming should be relatively easy to sort out. It doesn't much matter whether I am right or wrong, we just need to get some finality here so that we know whether to chase the dog or the rabbit. Cheers Billy 8-{) :confused:	Billy T (70)
448303	2006-04-21 23:34:00	I have written and compiled much Z80 code in ancient history. What you imply is the running source code through a decompiler will produce the instruction set and allow you to reverse engineer the code. While in theory this is true, in practice it is anything but true in my experience. If a "buffer area" is assigned in the code, for scratchpad or storage use for instance, it could be filled with anything initially. But the "anything" will be interpreted as instructions by the decompiler and the entirely wrong outcome will result. That's but one of the many scenarios that would frustrate a reverse engineering attempt, any embedded values for use elsewhere in the program (storage of constants for instance) would also result in the wrong rendering of pseudo source code. The deliberate use of dummy data strings (which are not used for anything) would also guarantee a bad result for decompiling. However I would agree that given the expertise and time (lots of both), it can be done. It requires the use of flowcharting as one analyses the logic, which eventually reveals such "red herrings" as isolated strings that are never referenced.	godfather (25)
448304	2006-04-22 00:17:00	I have written and compiled much Z80 code in ancient history. What you imply is the running source code through a decompiler will produce the instruction set and allow you to reverse engineer the code. No, there is neither desire nor intention to reverse-engineer the code, and personally speaking I don't think the true interest lies in the source code at all. What is really needed is the actual compiled? instruction set that is loaded into the eproms. As I said, I think they have been chasing the dog instead of the rabbit In actual fact there is no problem accessing the eproms and reading out the code, I have some here right now and can obtain as many as I could ever want, but that would not be legal and the information gained would be unusable. So, what I am attempting to clarify is the wider picture of the terminology necessary in disclosure documents to obtain the required programming information. At this point all I am looking for is a broad direction, after that it will be up to others to refine the disclosure request and pursue it through the US Courts. They have virtually unlimited finds to pursue this matter, but they won't get anywhere unless they ask the right questions and IMHO they may have been asking the wrong ones for many years. Cheers Billy 8-{)	Billy T (70)
448305	2006-04-22 00:52:00	The required programming info for disclosure documents would have to be the source code in my view, as the object code (which you/they have) is of limited or no use as above. Source code usually has the (good) programmers notations describing how each step works as well, stock example below. With this information the code can be modified or recomplied, not really the case with anything else. Uncommented code is bad practice. If its for Intellectual Property or protection of patent or licence rights, or guarantee of performance, I think the source code is all that you should be looking at. .ORG $100 CALL INIT_PIO ; program the PIO LD A,0 OUT (PIO1B),A ; ALL BITS OFF LD BC,10000 CALL PAUSE LD A,255 OUT (PIO1B),A ; ALL BITS ON FOR 1 SEC.. LD BC,10000 CALL PAUSE LD A,0 OUT (PIO1B),A ; CALL INIT_UART ; INITIALISE - TEST UART ; ONLY CALL THIS IF UART MOUNTED! EI ; Start INT COUNTER MAIN_LOOP: LD A,(INT_COUNTER) ; GET COUNTER OUT (PIO1B),A ; OUTPUT IT TO LEDS JP MAIN_LOOP ;...etc	godfather (25)
448306	2006-04-22 01:51:00	In a word: Bugger! :( That means that we are into the chinese wall argument. The "defendant" should have that information but is claiming that they don't, which means that the ownership/stewardship/rights have probably been assigned to an obscure shell company somewhere off-shore where US law does not apply. Unless, of course, they are perjuring themselves, which I rather doubt. That now begs the question as to how they access that programming information and incorporate it into their machines without materially taking possession of it in some way. I take it then, that what is in the Eproms is unintelligble without decompiling and lacks the vital notes as you first suggested? Cheers Billy 8-{) Edit: It is a proof and analysis of performance matter rather than Intellectual Property or protection of patent or licence rights.	Billy T (70)
448307	2006-04-22 01:54:00	lol what on earth are we talking about :p seems too technical for me :D	Prescott (11)
448308	2006-04-22 02:16:00	Are they disputing that the Z80 program does not control the machine as intended or that the cost of development has been too high and therefore there must be code in there that is not required for the purposes of controlling the machine. Companies will protect source code like anything so the legal bills could get very high to get them to cough up.	dolby digital (5073)
448309	2006-04-22 02:43:00	That now begs the question as to how they access that programming information and incorporate it into their machines without materially taking possession of it in some way. Either the programmers had a full and detailed understanding of the machine construction and function (and simply provided a "turnkey solution" coded eprom) or the machine maker had the detailed knowledge of the source code and built the machine to suit. They could not (in my opinion) have operated in total isolation of each other. The eprom contents will be unintelligible as suggested, they will have no notes or comments that would help. Simply a series of hexadecimal numbers. You cannot assume that the first eprom memory location is the CPU process entry point either, hence decompiling can generate complete rubbish.	godfather (25)
448310	2006-04-22 02:52:00	. . . You cannot assume that the first eprom memory location is the CPU process entry point either, hence decompiling can generate complete rubbish . It's not that bad . . . there are Z80 standard interrupt vectors, so you do have very good clues . But disassembling is not easy . The main problems are text strings and (much worse) variable length instructions . Once the disassembler gets out of step, it's all over for that scan . I used to be able to do it by eye, rather than using a programme . But then I was fresh from hand-assembling a 2k byte EPROM's worth . ( And I used octal radix, which makes it much easier . ) By the way, one of the standard steps in working on someone else's code is to remove all the comments . They are worse than useless because they are never kept up to date, when they are not merely useless: INC AX ; add 1 to AX I've seen that . :groan: At best comments indicate what the programmer [b]hopes[/b[ the code does . There's a nasty way of protecting object code I came across about the same time: other people were using 6800s, and they bought an arithmetic package . Unfortunately it was made to be used with the manufactuirer's hardware, and they used non standard addressing for the EPROM it came in . :( If you've got access to the hardware holding the CPU that's relatively easy protection to break .	Graham L (2)
448311	2006-04-22 08:08:00	All of this is proving very helpful indeed guys. I admit my total ignorance of programming of any sort, but as a peripheral bit-player in the dispute I have an interest in keeping it on track. I am learning more than enough to know that I need to keep my nose right out of it. Are they disputing that the Z80 program does not control the machine as intended or that the cost of development has been too high and therefore there must be code in there that is not required for the purposes of controlling the machine. No, the issue is whether the machine performs in the manner the manufacturer claims. There are many human elements involved, so the precise instructions given to the machine are extremely relevant and important to interpreting the results. Companies will protect source code like anything so the legal bills could get very high to get them to cough up. Cost will not be a factor, resources are not unlimited, but are more than adequate to pursue the disclosure vigorously through appeals processes at various levels for some years if necessary. The issue has been in litigation for several years already. Cheers Billy 8-{)	Billy T (70)
1