Problem VisualBasic exe file to project and form data....
in [Visual Studio]
|
From: Tomika on 1 Dec 2009 07:57 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! Tom
From: Ralph on 1 Dec 2009 09:52 "Tomika" <tomika(a)email.t-com.hr> wrote in message news:hf33nd$3om$1(a)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! > Tom > 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
From: Auric__ on 1 Dec 2009 10:29 On Tue, 01 Dec 2009 14:52:06 GMT, Ralph wrote: > "Tomika" <tomika(a)email.t-com.hr> wrote in message > news:hf33nd$3om$1(a)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.
From: Ralph on 1 Dec 2009 23:35 "Auric__" <not.my.real(a)email.address> wrote in message news:Xns9CD4562CDCB42auricauricauricauric(a)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
From: Mike Williams on 2 Dec 2009 09:07
On 2 Dec, 04:35, "Ralph" <nt_consultin...(a)yahoo.com> wrote: > 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 |