How to read VB source codes with only *.exes? 
Author Message
 How to read VB source codes with only *.exes?

Is there any way I can get to read the source codes of the executables?
alternate history



Sat, 05 Feb 2000 03:00:00 GMT  
 How to read VB source codes with only *.exes?

the EXE file is the machine code.  This is compiled from the source code
and the names of variables are removed and replaced with memory
locations.  What you might be looking for is what is called a
decompiler, and I am not sure if VB has one out.  Even so, you must
realize that the decompiler will not be able to show you exactly the
code that was used to generate the program, but should provide you with
a way to change the code without rewriting the program.  You should also
need to know how to work with machine code in order to better understand
the output from a decompiler.

Quote:
> ----------

> Posted At:         Tuesday, August 19, 1997 09:38 AM
> Posted To:         misc
> Conversation:      How to read VB source codes with only *.exes?
> Subject:   How to read VB source codes with only *.exes?

> Is there any way I can get to read the source codes of the
> executables?
> alternate history



Sat, 05 Feb 2000 03:00:00 GMT  
 How to read VB source codes with only *.exes?

Is your full name Dodi Al Fayed?  Do you personally know
Princess Diana?  Just could not help myself :-)   Ho

Quote:



> >Is there any way I can get to read the source codes of the executables?

> Have a look at http://members.aol.com/vbdis

> DoDi



Sun, 06 Feb 2000 03:00:00 GMT  
 How to read VB source codes with only *.exes?



Quote:
>Is there any way I can get to read the source codes of the executables?

Have a look at http://members.aol.com/vbdis

DoDi



Mon, 07 Feb 2000 03:00:00 GMT  
 How to read VB source codes with only *.exes?


Quote:
>Is your full name Dodi Al Fayed?  Do you personally know
>Princess Diana?

No, sorry, not yet. Perhaps you can arrange a meeting? ;-)

I am Doktor Diettrich, but because this is not very handy in international
mail, I truncated it to DoDi.

DoDi



Wed, 09 Feb 2000 03:00:00 GMT  
 How to read VB source codes with only *.exes?


Quote:
>Of course there are decompilers for VB, since MS has put half the source

        Where can I find one? :-?


Tue, 15 Feb 2000 03:00:00 GMT  
 How to read VB source codes with only *.exes?


Quote:
(VBDis) writes:
>Consider any executable code as the native language of a (possibly
>hypothetical) machine. Disassembling means to show the "instructions" in a
>readable form.

To some people machine codes/byte codes would constitute a 'readable
form', surely?

Anyway, would I be right in understanding the following:
    Visual Basic is NOT compiled to machine dependent machine code
instructions, like assembly language and C, it uses an interpreter, and has
byte codes reflecting the original code. This would be why VB is so
pathetically slow at many things, and why I get very erratic figures when I
try to measure the CPU hit caused by VB software. This is also why
disassemblers designed to return the assembly mnemonics don't return
anything meaningful, and why it would be a waste of time to write a machine
code optimiser in the hope of speeding VB programs up. This is why  the
visual Basic .DLL file must be present for VB programs to run, it contains
all the routines, which are accessed by byte codes. So does VB work as
follows: the VB executable file contains the interpreter stub, which calls
the DLL functions as it works it's way through the byte codes?
      I'm probably totally wrong, but it would explain why in the same
environment I can write an assembly language program to carry out about 250
screen fills per second, while VB struggles to do 5, using it's native
functions.

                    Shiva
--
"Information is Knowledge, Knowledge is Power, Power is Dangerous"
"Information Overload... I've a thousand pages on it..."
"Play with fire - burn your fingers"



Thu, 17 Feb 2000 03:00:00 GMT  
 How to read VB source codes with only *.exes?



Quote:
>To some people machine codes/byte codes would constitute a 'readable
>form', surely?

Of course it will. And writing a decompiler for VB, I have the dual
problem: first to know what the "language" is, and then to find out, what
the "meaning" of the sequence of tokens is.

Quote:
>>Visual Basic is NOT compiled to machine dependent machine code

instructions, like assembly language and C, it uses an interpreter, and has
byte codes reflecting the original code.<<

This is perfectly true for VB3 (and prior). Little has been done to make
the code execute faster than in the interpreter, like replacing the names
by addresses of variables and subroutines, or diversifying a simple "+"
into addition of integers, longs, doubles etc.

With VB4, the source code is converted into more primitive operations, a
bit closer to an efficient interpreter. But imagine your programm wants to
add two Variant variables, there must be taken a lot of decisions,
depending on the actual contents of both variables, before the operation
can be executed. Even to add Integers, you'll have a common subroutine,
that will do range checking, and possibly raise an exception. Such a
routine needs many machine instructions, so you can neglect the
interpretation of many tokens, the operations wouldn't become faster in
native code.

The only execution-time improvement with native code is at your own risk,
when you decide _not_ to perform any checks. Else you'll have exactly the
same subroutines called in native code, as are used in interpretation of
the token code.

Quote:
>>it would be a waste of time to write a machine

code optimiser in the hope of speeding VB programs up.<<

You could rewrite the VBRUN DLL, not to perform error checking, then you'd
really have a speed improvement.

Or use another compiler, that allows to translate selected parts of your
program into machine code, with no error checking, and call these
subroutines instead of the original VB code. I once considered to write
such a translator myself, putting the created code into the executable
itself, so you'd not need a separate DLL. But unfortunately I had no time
to implement this, and there was also no special demand for such a tool, so
I left it to Power Basic and other companies, to write real VB compilers.

Quote:
>>So does VB work as

follows: the VB executable file contains the interpreter stub, which calls
the DLL functions as it works it's way through the byte codes?<<

Not exactly, it works like the IDE: the exe file contains tokens, like the
binary source modules of VB3, and the interpreter resides in the runtime
DLL. It's similar to the old run-only interpreters, available with MSBASIC
or other Basic interpreters. A VB3 program contains exactly 1 machine
instruction, the call of the runtime interpreter.

Quote:
>> in the same

environment I can write an assembly language program to carry out about 250
screen fills per second, while VB struggles to do 5<<

Depending on the functions, you cannot optimize much in assembly. Imagine
InStr, and its C counterpart strstr(), in both cases subroutines must be
called, that should have the same performance. In VB3, you can do a lot of
optimization, avoiding Variant variables all the time. In VB4/5 this won't
help much, sometimes even result in degradation of speed, because there the
compiler uses almost only temporary variables of Variant type! That will
explain, why VB4 programs often execute slower than the same programs,
compiled with VB3. And with any VB/32, you'll have more speed penaltys, for
using double byte characters, whether you need them or (almost) not.

DoDi



Fri, 18 Feb 2000 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. VB 3.0 EXEs change without changing the sources

2. Reading web page source code in VB

3. Visual Basic source-code to C++ source-code

4. Visual Basic source-code to C++ source-code

5. Visual Basic source-code to C++ source-code

6. FREE VB Classes with source code and demo code

7. source code for reading wavs?

8. Read File Source Code

9. VB Controls and VB Source Code CDs?

10. VB source, read/write .WAV?

11. A great source-code-source

12. Reading web page's source w/VB/ActiveX

 

 
Powered by phpBB® Forum Software