Hello Peter,
QED ? Just because you say so ? Weak argument dude.
The only "exception" you stated to the highly unusual nature of needing to
know the specifics was "looking at the .NET program-block at byte-level".
Since that is in and of itself highly unusual, it's not a real exception.
It simply reinforces what I already said.
If you think that it's not highly unusual to want to do that, you might
consider presenting your question to the apparent multitudes of people who
are doing the same thing as you. They seem not to be reading this
newsgroup, but they must be somewhere.
I admit, I am not among those multitudes. I practically never need to look
at the byte code. I look at .NET IL byte code even less than I've looked
the processor machine code over these past few decades or so, and since the
90's that has not been that often either. (I will grant that prior to that,
it was more common...but then our tools got better).
Where you hope to find these multitudes, I have no idea. I'm clearly out of
the loop, having overlooked the vast community of .NET programmers who
regularly inspect the IL byte-code as part of their daily work.
[...]
Still, you have not yet shared _why_ it is you feel you need
to look at your program.
Why do you think that is important in regard to what I'm after ?
Because, all too often someone poses a question asking how to do X, when
what they really want to know is how to do Y. They only _think_ they need
to do X because they don't know enough about Y to know there are better
alternatives to accomplishing it than by doing X.
[...]
But to humor you: I just want to see how it works on that level. Thats all.
Knowledge.
See? Was that all that hard?
Now, I note that many people successfully gain knowledge through a process
known as "reverse-engineering". It is not as efficient as reading
documentation, I grant you. But it does work, and would in this case as
well.
I'm not sure what you mean with that "higher-level problem" ... Ment as in
a .NET language programming-problem ? Or ment in a more general way ?
I mean you have asked to do X. I was asking you to explain the Y that led
you to X.
In your case, it seems you simply want to do X for the sake of doing X,
which is fine. But it's useful for you to clarify that. Without stating
that explicitly, there's always the possibility that what you really need
is a different solution to Y than X.
In the first case: no such problem exists. I do not even have .NET
source-code or compiler here.
In the second case: As above, I just want to get a thorough understanding
of it.
To be quite honest, that need for knowledge is fed by seeing .NET
executables and DLLs on my machine that currently are fully opaque to
me.
If they are opaque, it is only because you apparently don't want to use
tools that would render them transparent. Yes, one way to decipher a .NET
program is to learn the IL byte-code yourself. But a decompiler (like
ildasm, dotPeek, etc.) essentially encodes precisely the information you're
asking for, simply in a different format.
This is not unlike your video card presenting images to you in a format
that is easier to understand than trying to interpret the millions of byte
values that are used to actually describe each frame of video. Or for that
matter, retrieving each individual byte of the .NET program you're
interested in one at a time by directly querying the disk or other storage
in which it resides.
(I'm assuming here that you have used some kind of binary editor/display
program to look at the individual bytes, and are trusting that its
abstraction of the actual raw data stored in your computer system is an
accurate representation. My apologies if in this case also you have gone
"straight to the source", so to speak).
Of course, every person will decide for themselves to what level of
abtsraction they are comfortable with in their computer systems. There's
nothing wrong with wanting to know more about the fine details of what's
inside a .NET program.
But it's fallacious to assume that the _only_ way to achieve this
understanding is through direct inspection of the individual bytes of the
program.
In any case, the bottom line here remains the same: if you want perfect
knowledge of the .NET IL byte code, you need the specification.
It's not being hidden from you. I know it exists, and I know you can find
it if you spend enough time and effort.
Consider that to simply be part of the puzzle you're working on. It's like
the need to actually _open_ the box containing the jigsaw puzzle pieces
before you start working on the puzzle. It may not seem like it's actually
part of working on the puzzle, but it is a prerequisite nevertheless.
If you don't have the specification, then you are necessarily trusting
someone else to represent the information contained within as an
abstraction of some sort. And if you're going to do that, you might as well
trust Microsoft, JetBrains, etc. to do it for you and present the
information in a more readily-consumable fashion.
Find the spec. And for good measure, when you do find the spec, post a
message here with the URL so anyone else looking for it has a better chance
of finding it themselves.
Pete
" (to be sure I would not miss anything) and it did not turn up