Problem VisualBasic exe file to project and form data....
Tomika
namely, ten years ago, when I was still involved in programming in VB,
I made
a small gadget for billing and material goods, etc., not to
longer, the original project file-I "lost" :-((.
Now I need to make some changes and now interested in whether the "exe"
unpack the files to back seasons of the original forms and projects in VB?
Please advise if there are good souls who ...... :)
Thanks in advance, and regards!
Tom
Ralph
"Tomika" <tom...@email.t-com.hr> wrote in message
news:hf33nd$3om$1...@ss408.t-com.hr...
If your app is VB3 or earlier - depending on the changes - you got a shot,
otherwise probably not.
This question is like the old classic:
"How much do the tires cost for a Lamborghini?"
The answer:
"If you have to ask then you can't afford them."
Due to the fact that VB4-VB6 are built from a semi-known framework ("Ruby")
and wrap a semi-known runtime, a knowledgeable seeker can retrieve forms,
objects, and routines into a malleable disassembled collection that can then
be documented, modified, and recompiled. BUT you would have to use C and
Assembly to do it as there is no direct or practical way to decompile back
into VB code or a VB project.
[Even with VB1-3 that have available pcode decompilers, the result would
only be a reasonable transcription and not an exact reproduction.]
Since you asked, I'm assuming you are not that "knowledgeable", so the
answer is probably "no".
Even if you were, I don't believe you'll find the exercise worth it. Like
most re-engineering efforts - It may be useful to take a peek to see how
some particular routine works, but in general you will find you can rewrite
a new application from scratch much faster and easier.
-ralph
Auric__
> "Tomika" <tom...@email.t-com.hr> wrote in message
> news:hf33nd$3om$1...@ss408.t-com.hr...
>> E follows ....
>> namely, ten years ago, when I was still involved in programming in VB,
>> I made
>> a small gadget for billing and material goods, etc., not to
>> longer, the original project file-I "lost" :-((.
>> Now I need to make some changes and now interested in whether the "exe"
>> unpack the files to back seasons of the original forms and projects in
>> VB?
>>
>> Please advise if there are good souls who ...... :)
>> Thanks in advance, and regards!
>
> If your app is VB3 or earlier - depending on the changes - you got a
> shot, otherwise probably not.
>
> This question is like the old classic:
> "How much do the tires cost for a Lamborghini?"
> The answer:
> "If you have to ask then you can't afford them."
It's more like "I have some bacon here, but I'd really like to turn it back
into a pig."
> Due to the fact that VB4-VB6 are built from a semi-known framework
> ("Ruby") and wrap a semi-known runtime, a knowledgeable seeker can
> retrieve forms, objects, and routines into a malleable disassembled
> collection that can then be documented, modified, and recompiled. BUT
> you would have to use C and Assembly to do it as there is no direct or
> practical way to decompile back into VB code or a VB project.
There *is* an option to compile projects into pcode in VB5 & VB6. (Not sure
about VB4... I rather think that 4 was still compiling to pcode only, but
not going to reinstall just to check.) I compile to pcode myself, since my
apps don't run any slower (at least, not so a human could tell), the
resulting .exe is smaller, and the compile time is mucho faster.
> [Even with VB1-3 that have available pcode decompilers, the result would
> only be a reasonable transcription and not an exact reproduction.]
>
> Since you asked, I'm assuming you are not that "knowledgeable", so the
> answer is probably "no".
>
> Even if you were, I don't believe you'll find the exercise worth it.
> Like most re-engineering efforts - It may be useful to take a peek to
> see how some particular routine works, but in general you will find you
> can rewrite a new application from scratch much faster and easier.
I'll second that, from personal experience.
--
Swear I never gave up on you.
Ralph
"Auric__" <not.m...@email.address> wrote in message
news:Xns9CD4562CDCB42au...@69.16.185.247...
>
> > Due to the fact that VB4-VB6 are built from a semi-known framework
> > ("Ruby") and wrap a semi-known runtime, a knowledgeable seeker can
> > retrieve forms, objects, and routines into a malleable disassembled
> > collection that can then be documented, modified, and recompiled. BUT
> > you would have to use C and Assembly to do it as there is no direct or
> > practical way to decompile back into VB code or a VB project.
>
> There *is* an option to compile projects into pcode in VB5 & VB6. (Not
sure
> about VB4... I rather think that 4 was still compiling to pcode only, but
> not going to reinstall just to check.) I compile to pcode myself, since my
> apps don't run any slower (at least, not so a human could tell), the
> resulting .exe is smaller, and the compile time is mucho faster.
>
The issue isn't just pcode. VB1-VB3 not only compiled to pcode but that
pcode contained an amazing amount of 'intermediate' structs and symbols.
Combined with a debug symbols file for the VBRuntiime, and the resulting
pcode was essentially readable without any additional decompiling.
That changed with VB4, it still only compiled to pcode (or more properly -
excode), but most of the symbols and structs were removed. MS also
drastically changed the VBRuntime.
Pcode is one of those "dirty little secrets" - unless an application is
doing a lot of processing where the optimizing compiler can help - most VB
apps written will perform better if compiled to pcode.
-ralph
Mike Williams
> Pcode is one of those "dirty little secrets" - unless an
> application is doing a lot of processing where the optimizing
> compiler can help - most VB apps written will perform better
> if compiled to pcode.
I think I'd have to take issue with you on that one, Ralph. Although
there are always exceptions, the general case is that native code is
usually as fast as, and often very much faster than, pcode. It all
depends on what your app is doing and on how much actual work is done
"under the hood" in response to each line of your source code (whether
a specific block of code is what I would personally call "top heavy"
or "bottom heavy").
There will be exceptions of course, but in general if you are
performing blitting or other drawing functions or disk access or
anything else of a "bottom heavy" nature then the performance of
native code and pcode will generally be about the same, but if you are
performing medium to "top heavy" stuff then native code is definitely
faster. For example, when sorting an array of strings native code will
only be about about 20 per cent faster than pcode, but if you are
sorting an array of Singles or Longs, or otherwise working with such
data, then native code is very much faster, typically about 500 per
cent faster than pcode, and that's without any specific compiler
optimizations.
Mike
Ralph
"Mike Williams" <gaga...@yahoo.co.uk> wrote in message
news:a2872a02-8c23-4197...@d10g2000yqh.googlegroups.com...
Though I find it difficult to believe you actually get a 500x faster sort
without compiler optimization - I won't quibble. As I totally agree with
much of what you say.
With any performance issue one has to test. All the scenarios you described
are processes that can benefit from an optimizing compiler.
What I meant by "dirty little secret" was simply to point out that many
VBers compile to native code - taking it for granted that it will be
faster - when in fact the vast majority of VB programs are not doing any of
the processes you mentioned and can benefit from a pcode compile.
A simple click on an Options dialog is all it takes to find out.
-ralph
Gutless Umbrella Carrying Sissy
news:nXyRm.12854$y%5.1...@newsfe03.iad:
Since he didn't say 500*x* faster, you shouldn't quibble. 500 *%*
faster is 5*x* faster.
--
Terry Austin
"Terry Austin: like the polio vaccine, only with more asshole."
-- David Bilek
Jesus forgives sinners, not criminals.
Ralph
"Gutless Umbrella Carrying Sissy" <taus...@gmail.com> wrote in message
news:Xns9CD58739393...@69.16.186.7...
> >> then native code is very much faster, typically about 500 per
> >> cent faster than pcode, and that's without any specific
> >> compiler optimizations.
> >>
> >
> > Though I find it difficult to believe you actually get a 500x
> > faster sort without compiler optimization - I won't quibble.
>
> Since he didn't say 500*x* faster, you shouldn't quibble. 500 *%*
> faster is 5*x* faster.
>
lol
Yeah, five 'times' faster seems a tad more probable - but still pretty darn
quick.
-ralph
Mike Williams
> "Gutless Umbrella Carrying Sissy" <tausti...@gmail.com> wrote in
> >
> > Since he didn't say 500*x* faster, you shouldn't quibble.
> > 500 *%* faster is 5*x* faster.
>
> lol
> Yeah, five 'times' faster seems a tad more probable - but
> still pretty darn quick.
Well it /is/ pretty darn quick. The "five times faster" that I quoted
for the specific kinds of code that I mentioned was just a ball park
figure of course, but I've since performed an actual test of sorting
an array of 50000 Singles using a standard ShellSort algorithm and the
timings are as follows (on this specific machine):
130 milliseconds PCode
59 milliseconds Native Code with all optimization turned off
25 milliseconds Native Code with standard default "Opt for fast code"
15 milliseconds Native Code with "Opt for fast" and "Remove Array
Bounds checks"
So, in this particular test native code is twice as fast as PCode with
no compiler optimizations whatsoever (not even the default "opt for
fast code), five times as fast as PCode with the standard "Opt for
fast code" optimization, and more than eight times as fast as PCode
with both "Opt for fast code" and "Remove array bounds checks"
optimization. So, my ball park figure of "five times as fast as PCode"
is not so far out when you consider that for these specific tests the
actual speed is between two and eight times as fast :-)
Mike
Gutless Umbrella Carrying Sissy
news:4wBRm.35838$cX4....@newsfe10.iad:
I offer no comment on that, since I have never written anything
that is complicated enough to make any difference detectable by
human senses either way. Just pointing out he didn't say what you
seem to have thought he said.
Ralph
"Auric__" <not.m...@email.address> wrote in message
news:Xns9CD4562CDCB42au...@69.16.185.247...
>
> > ("Ruby") and wrap a semi-known runtime, a knowledgeable seeker can
> > retrieve forms, objects, and routines into a malleable disassembled
> > collection that can then be documented, modified, and recompiled. BUT
> > you would have to use C and Assembly to do it as there is no direct or
> > practical way to decompile back into VB code or a VB project.
>
> There *is* an option to compile projects into pcode in VB5 & VB6. (Not
sure
> about VB4... I rather think that 4 was still compiling to pcode only, but
> not going to reinstall just to check.) I compile to pcode myself, since my
> apps don't run any slower (at least, not so a human could tell), the
> resulting .exe is smaller, and the compile time is mucho faster.
>
The issue isn't just pcode. VB1-VB3 not only compiled to pcode but that
pcode contained an amazing amount of 'intermediate' structs and symbols.
Combined with a debug symbols file for the VBRuntiime, and the resulting
pcode was essentially readable without any additional decompiling.
That changed with VB4, it still only compiled to pcode (or more properly -
excode), but most of the symbols and structs were removed. MS also
drastically changed the VBRuntime.
Pcode is one of those "dirty little secrets" - unless an application is
doing a lot of processing where the optimizing compiler can help - most VB
apps written will perform better if compiled to pcode.
-ralph