Variables are not being store properly?

[BogdanOntanu]

As Bogdan is saying as as I said before. It is poor programming practice to do these type of things. You should not have one variable for two handles as I said before. How you code needs to be done in a logical way. Make separate variables for each specific usage and DO NOT share their usage. You will just confuse yourself and us. Same goes for strings.

Sorry to interrupt, Bogdan, but what he is doing is just wrong on too many levels.

Paul

Sure Paul, you are right...

Nobody can make that many mistakes in sequence unless he/she does it on purpose... I have suspected that much already ;)

However tonight Universe has chosen to express generosity by using me as a vehicle and it does not matter if there is nobody to receive this expression on the "other" side.

[unktehi]

You should not have one variable for two handles as I said before. How you code needs to be done in a logical way. Make separate variables for each specific usage and DO NOT share their usage.

Just FYI, I have changed the handles in the macros so that STD_OUTPUT_HANDLE are using stdOutHandle and all STD_OUTPUT_HANDLE are using stdInHandle.  If you are suggesting a different handle for each usage, then am I to assume that these invoke statements shouldn't even be in macros because every instance would need a different handle name?

[BogdanOntanu]

I think so, so if edx is returning the OFFSET of Buffer, then shouldn't I be able to derefence the edx by putting brackets around it. (According to the 'Introduction to Assembler' 'Addressing and Pointers' section, "Using square brackets around EAX gives access to the information at the address in EAX.") Then, by moving the derefenced value (the actual information) into either a variable name or another register, wouldn't it access the information at the new address of the new variable?

This is completely irrelevant. Where in this program are you using [] square brackets to dereference anything?

That issue is way too advanced for you. For now you seem to have huge problems with simple logic facts. For example the logical fact that you can not have the same glass full of water and full of oil at the very same time.

Once you had your buffer full with input1. In other words once you have your "glass" full of "watter".
Then you trow away the "watter" from your "glass" and fill your "glass" with "oil".
Or in other words you get your second input into the very same buffer.

And now you cry that you can not "drink" "watter" from the "glass" anymore! (ie you can not "print" the original contents that you yourself have thrown away (overwritten) from your buffer.


A pointer might be pointing towards buffer1 or towards buffer2 or towards something else BUT you have to HAVE something to point at "Oblio". If you have nothing to point at OR if all of you pointers point to the exact same location THEN is is kind of pointless to use pointers so to speak. (FYI "Oblio" was a cartoon about "pointers" that aired when I was still young)

"Dereference" is not the magic wand that will automatically solve your problems and do what you want. It will do what it does regardless of what you "want".

And NO you can not store an full buffer inside a small register. A register is only 32 bits. At maximum it could eventually hold 4 x 8 bit ASCII characters but not a longer string or buffer.

That is the reason why whenever we need to read mor ethan 4 characters (almost always) from the input we humans usually read into a large buffer and that can not fit inside a register...

When we need to use that buffer we can use it's address directly or via the offset operator IF we know it's location at compile time OR we could use a pointer to it if it is dynamic or we want to move around it.

But those are the very basics that you have asked about before a long time ago.

And still after such a long time you have not learned the basics yet.  Now you are using macros when you have no clue what a variables is, what the address of a variable is, what the content of a variable is and what a pointer to a variable or a pointer to  a buffer is...

[BogdanOntanu]

Just FYI, I have changed the handles in the macros so that STD_OUTPUT_HANDLE are using stdOutHandle and all STD_OUTPUT_HANDLE are using stdInHandle.  If you are suggesting a different handle for each usage, then am I to assume that these invoke statements shouldn't even be in macros because every instance would need a different handle name?

I suggest that you think for yourself and when we give a hint please do not assume something other that exactly what we say. Most likely what you will assume will be in the wrong direction. Paul never said that you should need a variable for every instance... it is funny and childish to even consider this.

He just said that because programming (esp in ASM) requires precision and attention to details and ability to think for yourself THEN when somebody makes such a bad choice as to use the very same variable for input and output handles... then the next action such a human does will most likely be "catastrophic" so to say...

For example: you need one input handle and one output handle. There is no purpose to obtain them every time at each macro instance.

You can simple obtain the handles once at the start of your program and you can release them once at the end of your program when you do not need them anymore.

During your program you can use the handles stored into nicely named variables.

This would be logical ... however why you choose to do otherwise is beyond "normal" comprehension.

Sorry if I am too harsh on you but I think you should put more energy and honest work into understanding the basics if you want to have a solid base for future achievements.

[PBrennick]

I think that for the time being, the program should be totally rewritten assigning unique names for each thing and I STRONGLY feel that the macros should be totally removed. They are too complex for your knowledge level at this point and will just serve to confuse you more. Do all the tasks in mainline code, get the app working. Once the app is working, then you can, one step at a time, add a macro, observe the results, etc.

This is a logical progression in the development cycle of an app.

Once you rewrite the app, post the _complete_ source so we can see how you did - this is important.

Remember, our _only_ goal is to see you succeed.
Paul

[dedndave]

That's not the only goal Paul - lol
I wanna learn, too
- Dave

[donkey]

Hi dedndave,

As a rule I discourage the use of macros, the current collection of useless dribble that is offered is used mainly to try to make assembly language look and feel more like C in the mistaken belief that it will accelerate learning. To me they only obfuscate code by adding yet another layer of instructions and are of dubious value in making the finished product more readable. I tend to use only a few macros, mostly in debugging but a couple for release code (mainly CoInvoke & rgvarg) and I will only use macros that I have written myself or that I understand completely and are very predictable in the code they generate. From the standpoint of a beginner, Paul is correct, do not use macros except those that are intrinsic to your assembler, nothing at all third party or in the beginning not even those you have written yourself. It will help you to learn by doing things the long way at least at first, for example use cmp/jcc instead of .IF/.ENDIF and write your loop code manually instead of using the shortcuts (.WHILE/.ENDW). Once you understand what a loop or conditional block is doing then you can start to use macros to replace some of the more tedious coding, until then you are just learning to string together a bunch of bug injectors and calling it assembly language.

Edgar

[Mark Jones]

Unktehi, are macros this chapter's lesson? If not, like the others have said, avoid them for now.

P.S. Don't be alarmed by the "serious" tone of some of these replies. Yes, it is critical to be able to find bugs... but everything in due time. Rome wasn't built in a day...

Often, when faced with such an obscure bug, the best idea is to (follow Paul's advice) and re-write the code as simply as possible. Get one thing working at a time, then add each piece until either the issue re-appears, or is resolved. Often, the issue is something simple that was overlooked or not considered fully. Happens all the time.

If it STILL doesn't work properly, post the entire source and executable. One of us will take a look at it and give some hints.

[PBrennick]

Unktehi, are macros this chapter's lesson?

Let's be more specific, here. If macros _are_ this chapter's lession, you are not ready for that lesson. Go back and redo the previous lessons using the advice you have received here. The way you are approaching variables and strings tells me you are developing bad programming habits that will mean you will re-invent these problems everytime you write an app.

About macros, one of the most deceptive things I have seen them do when troubleshooting other's work is that they were not aware that if they call an API in the macro some registers (especially, almost always eax) get destroyed. This can cause problems in your mainline code if you are not aware of this and have not taken the appropriate precautions. As Donkey so well said, they should be avoided almost always. The other thing is that error reporting in respect to macros is very vague. The error report will only reference the line that called it leaving you with what could be a complicated macro with an error and no way of knowing where the error is. That is in the instance of a syntaxical error. Soft errors (errors in logic) will usually assemble without a hitch but fail at runtime leaving you scratching your head.

Strings are not static or constants and _can_ be modified at runtime but strings that are being used as labels should not be modified. It is bad form. Advanced users will sometimes do things like that to save on program size but you should not consider that as a goal at this point. Make a separate string for each usage or prompt.

There is a reason why the Hello World program is so simply made. Use that as an example and build from it. Make a Hello World Console app. Get it working and then start adding other stuff to it.

... and never modify a code posting. At this point I have no way of looking at your problem in depth as the code is lost.

Paul