Re: huge array

Tech-Archive recommends: Fix windows errors by optimizing your registry

On 2009-09-03, DanS <t.h.i.s.n.t.h.a.t@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Tom Shelton <tom_shelton@xxxxxxxxxxxxxxxxxx> wrote in
news:uMVLymLLKHA.5864@xxxxxxxxxxxxxxxxxxxx:

On 2009-09-03, Wolf Wendel <wowe@xxxxxxxxxxxxxx> wrote:
I don't want to start a new pseudo code versus native code disussion
but your friendly suggestion needs to get an answer:

.NET code is NOT interpreted. It alwasy has been run as native
code.

Of course is always any code executing on a CPU a native code which
has been transformed from plain VB code or from any other language,
or do you know a CPU which can handle something like "FOR I = 1 TO
10" ?

The dot net JIT compilers *do* interpret pseudo code (or whatever
name you want to use for it) at run time, and the pseudo code is
generated out of VB code or C# code or others when the IDE is told to
'compile'.

Please correct me, if MS changed anything at this since .NET started.


There is a huge difference between interpeted code and native code.

In an interpreted system, parsing and execution are the same step -
and both are handled by the runtime system. Basically, token is read
and parsed and is mapped to a call in the runtime system.

In a compiled system, parsing and execution are two separate steps.
The input is parsed into native machine code and then executed
directly by the cpu. Traditionally, the machine code has been stored
in a separate file for execution at a latter point.

.NET is a COMPILED system. It's just that:
1) compilation happens in two phases
stage 1: statically compile to IL by language specific
compiler stage 2: compiled to target machines cpu specific
native code by runtime.

2) the native machine code is not stored in the executable.

It was a decision of MS's business concept to produce and maintain
only ONE piece of software which transforms programmer's code into
CPU applicable code instead of having and supporting an individual
native code compiler for each language. There has never been any
technical need to make programmers distribute pseudo code instead of
native code. As we know all MS itself supported individual compilers
at times before.


They still do. Each .NET language has it's own compiler, that
represents the first stage of compilation - which is the generation of
IL (a binary, platform independant language).

Stage 2 happens on the target system - the runtime scans the il to
verify security and saftey, and then compiles the il into native code.
From that point forward - execution is passed to the cpu like any
other native executable.

This is what is refered to as JIT compilation (JIT = Just In Time).
The reason for JIT compilation is mainly portability - it allows the
executable to be converted to the target processor on the fly. Which
is one reason that the same .NET executable can run in 32-bit mode on
a 32-bit system, 64-bit mode on a 64-bit system, or on a completly
different hardware architecture (such as mobile applications, or
XBox). Try that with VB.CLASSIC or even statically compiled C++
(they have JIT compilers for C++ - JIT does not imply managed, it
simply referes to when the actual conversion to native code happens).

JIT is also what makes it possible for projects like mono to binary
compatible with .NET. It's why I can take my app written and compiled
in VS, transfer the exe to my Linux system and execute it. Or the
other way as well... Writen and compiled on my linux box and then run
on windows under .net.

IL and JIT is also what makes language independance possilbe. In
other words, I can use a class written in VB in my C# code - even
inherit from it and extend its functionality.

The reason why programmers like me don't like dot net is that the
pseudo code can be translated back into readable VB code, so f.e. any
business rules coded in a dot net language are almost completely
open, readable as VB code, for the rest of the world - in my eyes an
undiscutable financial and security risk.

If you say so, yet I work for a company that is in the top 50 of the
fortune 500 and they sure do a lot of stuff using Java and .NET.

I wouldn't pretend to say that .NET is right for everyone or
everything. But, this decompilation idea is usually misguided -
especially with the obfuscation tools available.

At least at former VB3 times and probably also for VB.NET
code the pseudo code not only included the nescessary information to
create the native code but included also more things, f.e. code
formating information like spaces and tabs, needed and meaningful
only for decompiling purposes. That looks for me that decompiling
other people's software is or at least was fully intended.


The decompilers out there are reading the IL and making a guess as to
what the VB or C# code would look like - it does not return the
original code. There are no comments, no formating clues, any
original code of any kind. Obfuscation makes it even harder to get any
meaninful results from these tools.

Therefore our decision not to use pseudo code based dot net
languages.

If you think "native code" executables are a barrier to people reverse
engineering your code, then you are mistaken.


Have you seen this ?

http://www.remotesoft.com/salamander/ .....a .net decompiler ?


Yes. I've seen it. They also sell an obfusctor and exe encrypter.

On this page, you can browse to a .net exe file, it will upload it,
decompile it, and show you the results. (It requires Java)

This is far more sophisticated than any VB6 decompiler I have seen. I
tried it with a Lantronix exe..and it produced some quite usable code.

Quite possibly. Not sure if they have used obfuscation or encryption.

--
Tom Shelton
.

Relevant Pages

  • Re: huge array
    ... Of course is always any code executing on a CPU a native code which has been ... There is a huge difference between interpeted code and native code. ... parsing and execution are two separate steps. ... stage of compilation - which is the generation of IL (a binary, ...
    (microsoft.public.vb.general.discussion)
  • Re: huge array
    ... It alwasy has been run as native code. ... |> transformed from plain VB code or from any other language, ... parsing and execution are two separate steps. ... | stage of compilation - which is the generation of IL (a binary, ...
    (microsoft.public.vb.general.discussion)
  • Re: huge array
    ... or do you know a CPU which can handle something like "FOR I = 1 TO ... The dot net JIT compilers *do* interpret pseudo code (or whatever ... parsing and execution are two separate steps. ... compilation happens in two phases ...
    (microsoft.public.vb.general.discussion)
  • Re: ANN: CLPython
    ... or interpreted by a CL Python interpreter? ... It's all compiled to native code. ... And of course compilation is for efficiency. ... so execution time is reduced. ...
    (comp.lang.lisp)
  • Re: cxx performance
    ... > Yes, the real performance lies in execution, but when executing the TDD ... > grand total of much lost productivity over a day. ... I assume that you are being sarcastic about comparing ... > me - I was looking for ways to speed up the compilation in the current ...
    (comp.os.vms)