DOS ain't dead

JWasm 2.01 (Announce)

posted by Arjay, 13.12.2009, 15:12
(edited by Arjay on 13.12.2009, 16:34)

[Note: this response was to Ninho but written in a way to help others also]

> but I was stunned at the very sight of that bugfix list !
I'm not. What I am please about is that he's picked up on these things as it shows that his work and own coding skills are maturing further. From what I have seen of his work so far he is a damn good coder. Concerning these bugs, well it is easy to introduce even very basic bugs if changing the base code to accommodate new features, e.g. adding 64 bit or replace previously written established code due to later learnings. Thus many err on the side of caution with "if ain't broke don't fix it" but how would things ever move forward if we all took that approach in life all the time? So it is best to realize there are times when that approach is good and times when it is not.

> Out of mere curiosity, what sort of source program sample and test
> tools/method do you use for checking correctness ?
I expect that he is doing at least the following:

1) Reverse engineering the outputted code to check if it is as expected
2) Compiling known code with other compilers and comparing the binary output

The problem with always using your own debugging/code analysis tools to check your own code is that often your own tools may contain bugs that cause you to miss bugs in the software which you are checking. Obviously this applies to other peoples tool as well, thus often good to do several checks with different software rather than just relying on the output of just one tool.

However even binary comparisons of different compilers output aren't straight due to compiler/linker code signatures etc. An example of what I mean by this is different compilers often use different opcodes which may do the same function (or almost the same function) or use a different order of opcodes, e.g. speed/size optimization. Thus when binaries of the same code produced by different compilers are compared even if they are of the exactly the same filesize they often do not necessarily match. This can also be deliberate as using specific opcodes over others and order of instruction and other techniques are used as a hidden clever way of digital code signatures. Which is why most compiler authors can identify if you have used their tools (or their code), obviously these techniques aren't just used by compilers either!

As what tools does he use, well no doubt he is using his own debugger as well as other internal / experimental tools (e.g. he might have a custom experimental debugger say a v2 that he is testing). Along with a collection of the usual Reverse engineering tools and debuggers available, e.g. IDA pro.

If you want to learn more about code analysis a good place to start is probably Wikibooks: X86 Disassembly Analysis Tools. There are many other references on the net, but I would say a good way to learn is from simply reading posts of experts such as Ilfak Guilfanov and as you already know http://www.GeoffChappell.com/

Complete thread:

• JWasm 2.01 - Rugxulo, 13.12.2009, 10:48 (Announce)
  • JWasm 2.01 - Ninho, 13.12.2009, 11:09
    • JWasm 2.01 - Arjay, 13.12.2009, 15:12
      • JWasm 2.01 - Ninho, 13.12.2009, 15:41
        • JWasm 2.01 - Arjay, 13.12.2009, 16:14
          • JWasm 2.01 - Rugxulo, 14.12.2009, 00:02
          • JWasm 2.01 - Ninho, 14.12.2009, 10:55
    • JWasm 2.01 - Japheth, 13.12.2009, 16:52
      • JWasm 2.01 - Ninho, 14.12.2009, 11:05