Xref: utzoo comp.compilers:1937 comp.lang.c:38732
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!world!iecc!compilers-sender
From: carter@cs.wisc.edu (Gregory Carter)
Newsgroups: comp.compilers,comp.lang.c
Subject: Re: MS-DOS EXE-to-C Decompiler testers wanted
Keywords: MSDOS, C, decompile
Message-ID: <1991Apr25.183946.5064@daffy.cs.wisc.edu>
Date: 25 Apr 91 18:39:46 GMT
References: <50.UUL1.3#913@acw.com>
Sender: compilers-sender@iecc.cambridge.ma.us
Reply-To: carter@cs.wisc.edu (Gregory Carter)
Organization: U of Wisconsin CS Dept
Lines: 31
Approved: compilers@iecc.cambridge.ma.us

I had a decompiler for my old machine made by Microsoft, (don't ask how I
got it please), it seemed NICE for small programs but for larger programs
I would like to make a suggestion(s):

1) Tag the machine program input in such a way so that one can see what
   parts of the C source are related to what, and how.  
   (Machine registers, memory models, code blocks relevant to source out)

2) Make it reverse engineered compatible with code view...now thats a
   challenge...so that you can watch that source and machine code side
   by side. (It must run both ways and yield EXACTLY the same machine code)

3) Document source code block pertaining to relevant system calls...
   (Interupt IRQ calls (maybe even the level code?), bios, etc.)

4) try not to drink too much Jolt while trying to do this...OK?

5) Of course, try like hell not to get sued from releasing such a product
   by everyone who applies in C.  (I know if you use that thing on my
   system software I would sue you till you thought you were a TYME machine
   out of control)
   
When you get it done, make me a beta tester!

Greg Carter
Digital Communications Research/Engineering
2726 West Point Road
Green Bay, WI  54304
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.