Re: huge array
- From: "Kevin Provance" <fu_bm@xxxxxxxxxxxxx>
- Date: Thu, 3 Sep 2009 17:51:59 -0400
Seriously Tom, no one gives a fu<k.
--
2025
If you do not believe in time travel,
your beliefs are about to be tempered.
http://www.facebook.com/group.php?gid=43606237254
"Tom Shelton" <tom_shelton@xxxxxxxxxxxxxxxxxx> wrote in message
news:uMVLymLLKHA.5864@xxxxxxxxxxxxxxxxxxxxxxx
| 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.
|
| --
| Tom Shelton
.
- Follow-Ups:
- Re: huge array
- From: Tom Shelton
- Re: huge array
- References:
- huge array
- From: Wolf Wendel
- Re: huge array
- From: Bill McCarthy
- Re: huge array
- From: Wolf Wendel
- Re: huge array
- From: Tom Shelton
- Re: huge array
- From: Wolf Wendel
- Re: huge array
- From: Tom Shelton
- huge array
- Prev by Date: Re: huge array
- Next by Date: Re: huge array
- Previous by thread: Re: huge array
- Next by thread: Re: huge array
- Index(es):
Relevant Pages
|
