News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

A snag in the road

Started by MusicalMike, January 04, 2006, 03:04:30 AM

Previous topic - Next topic

MusicalMike

I am still working on the "disasm project", and I have hit a bit of a snag in the road. Everything I have done so far works, but one strange thing I notice is, when I disassemble files generated by a compiler like VC++, I get correct assembly listings (I varify my results with another disassembler every time for debugging purposes). However amoung those listings (particularly between functions and subroutines, I will get garbage data that consists mostly of useless code, some of which are illegal opcodes. Atfirst I figured I did something wrong, so I used another disassembler to disassemble the code at the memory location that the "problem" occured at, surprisingly, again, the results produced matched my results. So, now I am at the crux of the situation. I know a few algorythms that can be used to solve the problem. Most people would simply look at all the jump and call statements and pick out all the subroutines and functions and place those results in the output, but As you will probably notice, my source code has gotten very sloppy as I have gone on doing this, and trying to slap the code necessary for this algorithm will take a while, as such, I would like to know if there is any quick fix for this little problem. I included the source code and a compilation in the attachment.

[attachment deleted by admin]

zooba

You'll hate this answer, but take it on board anyway:

1. Delete all your code
2. Start again

The benefits are (should be) obvious. You've done it once, so it'll take less than half the time. You've got a better idea of how it could be arranged so it'll be neater. Chances are you'll comment stuff too. There's some good literature on this concept out there, (can't think of where ATM, I'll get back to you :U)

As for identifying junk commands, you've already suggested the optimum solution (short of a full run trace) as simply ignoring anything between 'retn' and 'push ebp' isn't going to work.

Cheers,

Zooba

Tedd

On the first point, I'll agree with zooba - scrap it and start again. There are many benefits - the main one being that now you know what you want to do, and more importantly, how to do it. I have been forced to rewrite some projects a few times, and while I didn't choose to do it, I was much happier with the result. And now I actually make a habit doing this!! You just have to be careful not to simply copy all your old stuff into a new file; in fact, try to avoid copy-paste altogether! It's annoying to retype many parts, but it makes you think about why those parts exist and allows you to improve them :U

Quote from: zooba on January 04, 2006, 10:21:57 AM
There's some good literature on this concept out there, (can't think of where ATM, I'll get back to you :U)
Search on "Extreme Programming"

Garbage between functions normally isn't a problem. Think about what happens when functions are aligned - there are gaps left between the functions! These gaps could be filled with NOPs, but they don't need to be, it depends entirely on the compiler. That said, there may well be meaningful data in these spaces (eg. jump tables for switch statements.)
The only good way to find out is actually follow the execution path of the code and see if it's ever used or referenced. But this suddenly turns your flat disassembler into a simulator.
No snowflake in an avalanche feels responsible.

MusicalMike

QuoteAs for identifying junk commands, you've already suggested the optimum solution (short of a full run trace) as simply ignoring anything between 'retn' and 'push ebp' isn't going to work.

Yes, I was thinking about how to get the latter to work for the longest time, however I kept comming back to the same problem... People don't always use the c-style format for functions, multiple ret instructions in the same subroutine (which I am embarased to say I have done before in my own assembly language programs), and worst of all; cases where people actually write code that my parser might mistake for garbage code, which I believe you eluded to.

QuoteOn the first point, I'll agree with zooba - scrap it and start again. There are many benefits - the main one being that now you know what you want to do, and more importantly, how to do it.
I started toying with the idea of having the user specify the addresses from which to start disassembling and the address to stop at.  But you're right, a complete rewrite will probably be for the best, but since I am going to be busy with high school for the next few months, I am going to have to put it on hold. Considering my age and experience, I am pleasently surprised that I even got this far, and had working code to show for it. Thanks for your input.

zooba

Quote from: MusicalMike on January 04, 2006, 11:57:29 PM
(which I am embarased to say I have done before in my own assembly language programs)

Nothing to be embarassed about there! It makes much more sense to get out when you want to rather than cluttering up the code with flags and other 'methods' proposed by OO supporters (it's actually a component of 'structural programming' rather than OO, but the OO guys are the ones who get all defensive about it  :wink).

I won't say any more, wouldn't want this post to get moved to the Collesseum... :bdg :U

gabor

#5
Hi!

Quote from: MusicalMike on January 04, 2006, 11:57:29 PM
(which I am embarased to say I have done before in my own assembly language programs)
Maybe this is not glorious to admit but starting over is one of my best working strategy when my code gets too complicated or needs a basic redesign. :U I do believe that in some cases as Zooba mentioned it is much more effective to create new code than to patch and improve the old one.
I work for a big company at developing (maintaining and some times inserting new codes) a small part of a telephon switch software. It is terrible!!! I am tortured with 20 year old badly designed and implemented code, and I have to live with it :'(... No thanks, that is not the way a real coder wants to walk. Here you have time and resources to start over. (Sorry this got a bit longer than I intended to be).

I agree with Tedd: the garbage in the memory should not be a problem. In the "big" Visual Studio in disassembly you can find garbage too... For me what really matters in a disassemler is the appropriate use of symbols!

Quote from: zooba on January 05, 2006, 03:34:39 AM
...flags and other 'methods' proposed by OO supporters (it's actually a component of 'structural programming' rather than OO, but the OO guys are the ones who get all defensive about it :wink).
I won't say any more, wouldn't want this post to get moved to the Collesseum... :bdg :U
I'd like to refer to this briefly (I hope we avoid the Colluseum). I do believe that OO is a very good and usefull method for development. I used some of its prciples in one of my asm projects, ok it is not a big thing. :bg So, I think using flags and such methods to save the existing code from throwing away and starting over is not a problem of the followed method or paradigm. It is rather the programer's problem I guess, the programer's bad behaviour. Normally, as I was thought at the uni and as I experienced a well designed and nearly fully specificated problem or task won't need such fixes (except some minor modifications). If it is impossible to continue the coding or to build in the next necessary features, modifications than there must be a big error in the designs and in the concept...

However, there must be some truth in Zooba's opinion, since many programers who state that they are using OOP are just scratching the top of the OO paradigm, they choose that way of development because it is succesful and is expected to be easy...That is a mistake, I guess.

Greets, Gábor

zooba

I know there's truth in it :P

I've been programming for 14 years and just 'enjoyed' my first year of university programming lectures on - you guessed it - object oriented programming. After fighting with my lecturers (who glossed over bit-wise operations as 'not relevant in computing') I've been left with no choice.

Interestingly, I questioned whether they actually taught a subject named "Programming Architectures" and they said no, it was a misprint - it should have been "Programming Architecture" (singular - ie. only OO will get any air time)  ::)  :P

NPNW

Zooba,

Quote(who glossed over bit-wise operations as 'not relevant in computing')
yeah, who cares about bit wise operators only the cpu uses such dumb things!  :U

While OO has its place. I do not believe it is a one solution fits all. My belief is that Assembly is the least restrictive of all programming languages and that it gives you more choices as well as allows you to have the most control. Anything that lessens that is not my first choice. Although it may well be useful in a limited way. However people then expect it to do everything simply and easily. They don't understand once you get outside of the prebuilt functions it can be difficult to implement code that is elegent and simple without huge effort.

I agree with most of what has been said. If you have time, see what the code in between functions is made of. The more knowledge you have the better off you are.


MusicalMike

The one real problem I have with OOP is that people misuse it. Classes were supposed to be used to represent datastructures in a real world context. However, everybody uses it now days to simplify windows programming. (Thinking that telling people to create and assemble objects is a lot easier than passing handles around, for instance The form class in .net, and the JFrame in java swing) I hate this. It makes for slow and inefficient code. Classes were meant to be used to impliment things like a client class with maybe a name, address, age, etc property, and maybe a few methods, not as a front end for GUI Programming. I could go on forever. Anyway, other OOP concepts will probably serve me well in the rewrite namely, abstraction (a lot of the code in my functions were was not reusable and a lot of redundancy had to be introduced to deal with it), and encapsolation (Beter representation of data would have probably made things easier). I will know better next time.

Writes 1000 times "I will not write sloppy code, I will not write cloppy code I wi..."  :boohoo:

NPNW

MusicalMike,

Okay, look at your code and see what can be made as a procedure. Then look and see what things inside a procedure can be made as macro's. Its been forever since I looked at 00P programming and I used to always translate other languages back to assembly. If I remember correctly the method's in OOP were pointers to functions in a data structure. That way when they changed a method or class, it did not change the way it was addressed. This goes back to Interrupt Vector Tables in Dos and probably to main frame programming. To get into more specifics I would need to re read my OOP and C++ books again. I remember reading somewhere the guy who developed C++( Straut?)  said that it was not exactly what he wanted because it was formed by committee to make a standard so there were compromises. I never did like inheritence not because it was a bad idea, just no one implemented it correctly. Stick with the assembly :U Sounds like your on the right road.  :thumbu


zooba

Quote from: NPNW on January 05, 2006, 10:10:17 PM
MusicalMike,

Okay, look at your code and see what can be made as a procedure. Then look and see what things inside a procedure can be made as macro's. Its been forever since I looked at 00P programming and I used to always translate other languages back to assembly. If I remember correctly the method's in OOP were pointers to functions in a data structure. That way when they changed a method or class, it did not change the way it was addressed. This goes back to Interrupt Vector Tables in Dos and probably to main frame programming. To get into more specifics I would need to re read my OOP and C++ books again. I remember reading somewhere the guy who developed C++( Straut?)  said that it was not exactly what he wanted because it was formed by committee to make a standard so there were compromises. I never did like inheritence not because it was a bad idea, just no one implemented it correctly. Stick with the assembly :U Sounds like your on the right road.  :thumbu

I don't think MusicalMike is using OOP in his code, we've just become sidetracked due to my own personal biases  :U :bg

Quote from: MusicalMike on January 05, 2006, 08:27:31 PM
However, everybody uses it now days to simplify windows [GUI] programming.

I actually have no problem with this. GUI coding is sloppy enough as it is (Windows uses a quasi-OO interface for its objects anyway) and performce is hardly an issue while you're waiting for the extremely slow keyboard-chair interface  :toothy  The problem is using OO because it exists and completely ignoring the fact that it's never proved to be any better than procedural. It's basically a buzzword that a few people ran with and it's caught on. I'm yet to see any empirical evidence that it's the 'best' or 'only' way to develop (I've been told both of these).

NPNW

#11
Zooba,

QuoteThe problem is using OO because it exists and completely ignoring the fact that it's never proved to be any better than procedural. It's basically a buzzword that a few people ran with and it's caught on. I'm yet to see any empirical evidence that it's the 'best' or 'only' way to develop (I've been told both of these).
Sounds like you have worked with a few Project Managers that love buzzwords. OOP, .NET, C++, LOL  :U God Bless them they couln't get a job as a used car salesmen, so they became a Project Manager :U

I agree that I have never liked the OOP programming paradiam. Things just don't fit neatly into this construct. Yet people who have no understanding think its great because you can do something in 10 seconds with it. They don't understand the limitations that are placed on the programmers ability to modify and create.

I think its terrible that the people who are in charge have no concept or technical expertise to understand what is going on at the programming level. I got out of software for some of these reasons. I have to laugh. Worked on a project a couple months ago that was suppose to be simple serial IO. We ended up trying to debug the  hardware. Then we were told by th project manager that he had someone who could do this in a day! Promises were made by the Project Manager blah, blah, blah... Basically its stalled and will never get done unless the company that owns the hardware opens up their specs to this guy. While talking to a friend who worked on the project he made the comment that I get my Masters in Programming I won't have to put up with these situations again. I laughted because in 20 years in the computer industry, networking, programming, consulting. 99% of the time this is what I run into. :bg So why getting my Masters Degree would change any of this sounds nice but I highly doubt it.

Maybe we can come up with some neat buzzwords that will circulate around the industry and we can hide everyting by using  Assembly.  That way Project Management can get a new buzzword, we can get something that works well? Maybe something like WizBang Programming Language. Why with WizBang I can do anytihing :bg  We can go from a fully functional department of 20 programmers down to 1 programmer and 19 Project Managers its so powerful :bg Just think of the capabilities we can bring to an IT department with WizBang Certification :green


zooba

Quote from: NPNW on January 05, 2006, 10:56:17 PM
Sounds like you have worked with a few Project Managers that love buzzwords. OOP, .NET, C++, LOL  :U God Bless them they couln't get a job as a used car salesmen, so they became a Project Manager :U

Hehe, actually, I've just suffered... I mean... enjoyed... my first year of 'software development' at uni (second year of my course). It's funny debating this stuff with some of the lecturers (especially the ones who can't back it up). Needless to say I get on quite well with the ones who acknowledge there's a world outside of OO :P

Quote from: NPNW on January 05, 2006, 10:56:17 PM
Maybe we can come up with some neat buzzwords that will circulate around the industry and we can hide everyting by using Assembly. That way Project Management can get a new buzzword, we can get something that works well? Maybe something like WizBang Programming Language. Why with WizBang I can do anytihing :bg We can go from a fully functional department of 20 programmers down to 1 programmer and 19 Project Managers its so powerful :bg Just think of the capabilities we can bring to an IT department with WizBang Certification :green

Since I've just come from suggesting Iapetus as a name for your new language (looks better in Italics I think :wink) I'm very impressed at your shameless self promotion :thumbu. Even more shameless than my own :bg :U

NPNW

Zooba,

QuoteHehe, actually, I've just suffered... I mean... enjoyed... my first year of 'software development' at uni (second year of my course). It's funny debating this stuff with some of the lecturers (especially the ones who can't back it up). Needless to say I get on quite well with the ones who acknowledge there's a world outside of OO Tongue

Yes finding people with an open mind is the fun part of college. Doesn't mean you can't have your beliefs. However I have found that if something makes sense I add it to my beliefs or ideals. If its a bunch of hokey B.S. to self promote someone elses ideals then I tend to let them think they know what they are doing. This saves me time and effort of educating them.  :bg

QuoteSince I've just come from suggesting Iapetus as a name for your new language (looks better in Italics I think wink) I'm very impressed at your shameless self promotion ThumbsUp. Even more shameless than my own BigGrin ThumbsUp
I like it with italics Iapetus and as with all great things presentation is everything Windows
Wonder if we need to patent this right away????



NPNW

Zooba,

QuoteI'm very impressed at your shameless self promotion ThumbsUp. Even more shameless than my own BigGrin ThumbsUp

Don't take me wrong. I am not the best or greatest programmer nor do I know everything!!!  I try and keep it as simple as possible. Don't memorize everything, remember where to find the answer. That way I can concentrate on the problem at hand instead of remembering way too much stuff. The only thing I'm promoting is FUN!