You seem to have removed some content, so no quotes for those parts.
I highly doubt it.
Oh, but I do! I'm sorry for thinking that you can actually be smarter than a debugger. The "fancy operator" I used is being taught in one of the firsts classes of C (in case of bit logic and/or operator precedence, whichever comes first). From now on, I'll be sure to double-check if the provided data is in way you'd understand.
And about .NET (C# in your case) not having anything to do with spoiling people (can't quote you now) - it does. Microsoft had made a very successful attempt to provide people with a programming language where everything* can be done with a few lines of code. It spoils people in a way that they EXPECT that everything they need is out there, somewhere (in a C# and VB.NET version).
*everything - everything that they've thought you'd need
And, as far as I know the CPU just executes the code, the compiler makes all the optimizations, not the CPU. So it doesn't look like that, ever, except in your little delusional mind.
Right about the first sentence. Let's see what we've established:
CPU doesn't do optimization, just executes the code.If it looked like that anywhere, it would show up in IDA\Debugger, it doesn't.
IDA doesn't do that elsewhere, there are plenty of places where the code uses bit shifting, but you're right, just for this one function, it decided to change the code to be easier to read.
Second one (after removing the sarcasm):
IDA will not make any attempt at providing user with more-friendly data.Now let's produce some code with that famous opcode part. To the right you'd see a disassembled line, and to the left - actual machine code.
FF140D A0559000 CALL DWORD PTR DS:[ECX+9055A0]
FF144D A0559000 CALL DWORD PTR DS:[ECX*2+9055A0]
FF148D A0559000 CALL DWORD PTR DS:[ECX*4+9055A0]
FF14CD A0559000 CALL DWORD PTR DS:[ECX*8+9055A0]
The only byte that changes is the 3rd one (0x0D -> 0x4D -> 0x8D -> 0xCD). In binary:
00001101
01001101
10001101
11001101
You'd expect it to be 1, 2, 4 & 8, but that's actually 0, 1, 2 (SHL 2 equals *4 ) and 3 (SHL 3 equals *8 ), so it actually does a bit-shift. So, "just for this one function, it decided to change the code to be easier to read"? No way! (disclaimer: not saying that's bad).
(And how do you think IDA get's the code, it executes it, and reads what happened on the stack\registers, that's what it saw occur, so that's how the machine code really looks.)
LoL
No, Mister Ignorant
It interprets it, at it's best, parse maybe, but sure as hell does not execute it. That would be a big security hole if it just "oh, lets run it and see what it does, yay!". Machine code is the hex codes you see next to each disassembled line
I don't appreciate being confronted over bullsh*t, especially when it was your own mistake that caused the issue to begin with. Had you explained yourself clearly, in a straightforward manner, I would have used your info, you didn't, so I didn't, end of f*cking story.
---
Even if it does that at some low level, I've mentioned that bit shifting isn't something I understand well. What I asked for was accurate info, not math lessons. I'll figure that out on my own time, as it becomes necessary. So your excuse for doing so, ie, helping me out, is BS.
Regardless, everyone else managed to give me info that lined up with the debugger\disassembler, you didn't. That's why I used their info, and not yours.
In short:
The only mistake I did was assuming that you actually did understand the "thing" (no, it wasn't me who started explaning it to you) - I was giving you info in a manner I thought that you'd surely understand now. I stand corrected.