Why VB 6.0??

Quote:

---

Originally Posted by WillAtwell

You didn't run into issues between 2003 and 2005? Are they installed where both are available at the same time?

---

VB 2003, 2005 and 2008 are installed on the same machine, and I can use anyone at any time :)

Quote:

---

Originally Posted by WillAtwell

So I am curious what configuration you have and if you have did anything with mobile devices Motorola and Symbol especially as those are the ones I ran into issues with.

---

To be honest, I haven't got much experience with the .NET Compact Framework, so I haven't dealt with mobile applications, apart from doing something with my Nokia - That's about it :)

Back on this debate about why VB 6:
I do agree that newbies should rather start with .NET ( even if it is just .NET 1.1 ), but, with old folk already experienced with VB 6 - if they choose to continue with VB 6, it's up to them - nothing said here in this thread would really convince them to change to .NET, or am I wrong ¿
And someone said that you cannot do everything in VB 6 which .NET can do, that's partly right, IMHO.
Why is VB 6 working on Vista then ¿
If you know your language well enough, you can do almost anything you need, isn't it ¿ I can do a program in .NET, and in VB 6, I can do the exact same, isn't that strange :p

Quote:

---

Originally Posted by HanneSThEGreaT

I can do a program in .NET, and in VB 6, I can do the exact same, isn't that strange :p

---

Do you have any experience coding with WPF?

I agree that new comers would be best served learning dot net.

For many of us VB6 is comfortable and we know many tricks so it is natural to want to use it where suitable. My first focus in dot net was the mobile devices where vb6 falls way short and in creating windows services as well. As for a standard exe that will run on the PC I am inclined to go with VB6 most of the time but am slowly moving more and more to dot net and begining to pile of some handy re-usable routines.

Quote:

---

Originally Posted by Arjay

Do you have any experience coding with WPF?

---

Yes I do, what sort of question is that ¿ :confused:

If you really want to get technical, obviously WPF is not supported in VB 6 ( that is general knowledge already isn't it ¿ )
What I meant ( I thought it was quite clear ) is that if you know your language well enough, you can do anything with it - agree ¿
WPF etc. aren't even supported in .NET Framework 1.1. We are talking about .NET in general.

I asked the question because without having experience coding in the later .Net frameworks a dev can't really understand what is being missed by staying with the 10 year old environment.

To me one of the best features of .Net (and let's just jump to 2.0, 3.0, 3.5 and beyond and forget talking about 1.0 or 1.1) is how integrated the programming environment is compared to programming with the 'technology islands' of the past.

By technology islands, I mean having to learn the various types of technologies in order to be able to produce a professional application - things like COM, DirectX, Network api's, Printing api's, GDI, and so on.

.Net just brings these disparate technologies into a more cohesive coding environment.

Unfortunately learning new technologies requires devs to step out of the comfort zone and pick up on new concepts and approaches.

Now look at a guy like TheCPUWizard who has been in business for 35 years and imagine if he didn't stay current with new technologies? Do you think he would still be in business today if he only knew the languages/techniques that he learned in the first 5 years?

IMO, as a developer you need to stay current with the latest technologies; otherwise you are going to find that work is harder to find.

Quote:

---

IMO, as a developer you need to stay current with the latest technologies; otherwise you are going to find that work is harder to find.

---

What do you mean that I won't beable to find work in c++ because it is older than me? really? All of you have mentioned was very small fragments about way the .net is better. I know it is 10 or so years old, but it seems to me it is pretty solid and can't be bashed very well besides that it is missing a few features. This is pointless. If a newbie wants to program in the .net, I don't mind that, but asking them not to use vb6 is just wrong. Oh and cpuwizard, your little code with asm put in doesn't mean it compiled to asm.

If you don't believe me, here are more post online in other places like msdn:
http://forums.msdn.microsoft.com/en-...-2b5d37c369c6/
http://www.physicsforums.com/archive.../t-204727.html
http://www.antionline.com/showthread.php?t=270787

After a bit of reading, that is enough proof you have a bigger and faster chance to decompile a .net app than c++.

See they put msil in the exe which this is so simple to convert back
http://msdn.microsoft.com/en-us/libr...k1(VS.80).aspx
look at that. microsoft allow you to get your original source code back and it uses their on tool.

Here is a more popular .net decompiler http://www.aisto.com/roeder/dotnet/

I could go on and on, but since you(cpuwizard) support microsoft from head to toe with your little badge from microsoft, I see no point in to say all the proven things over. Next time I will give you more links.

Quote:

---

By technology islands, I mean having to learn the various types of technologies in order to be able to produce a professional application - things like COM, DirectX, Network api's, Printing api's, GDI, and so on.

.Net just brings these disparate technologies into a more cohesive coding environment.

---

Vb6 has all of those. What are you talking about... and they are cohesive.

I had to learn VB6 for school last year, and I had a lot of fun with it as my first programming language.
These days I almost exclusively use C++, although the one thing I still do use VB6 for is the occassional.... 'proof of concept' I guess, for testing the basic logic of an algorithm.
Eg- Most of what I do is creating games purely as a hobbyist, and when I began creating a 2D collision detection system for my (C++) games, I started off (in VB6) by putting some shape controls on a form, setting them up to move with the keyboard, and using if statements in a timer, testing .Left .Width etc etc and turning them red when they collide.
Everything involved in that other than the actual if statements themselves is so mind-numbingly easy for anyone with the tiniest bit of VB6 experience, that you can focus on just the bit you're trying to get right. In a more complex system that uses C++ and DirectX, it's more difficult to create a system that you know is 100% bug free so that you can be 100% sure that if something is going wrong it's because of the exact few lines of code that you're implementing at that exact point in time.


TL;DR: I find that VB6 still has its uses, but only during development, not in a finished product.


metal
PS- having re-read that, I realise that vb.net and C# may well be just as good for the sort of thing I've described. Personally I haven't bothered to learn either of them (yet), so I wouldn't know.

Quote:

---

Originally Posted by HanneSThEGreaT

... aren't even supported in .NET Framework 1.1. We are talking about .NET in general.

---

Actually that was never my intent at all. If people said they were migrating to xxx from vendor yyy that would have been expected.

The real point was legacy (un-supported) vs. current (with good future suport). Note that .Net 1.x is rapidly approaching the former....I would be nearly as suprised to find people developing new products aimed at 1.1

Quote:

---

Originally Posted by Joeman

. Oh and cpuwizard, your little code with asm put in doesn't mean it compiled to asm.

---

You obvooiusly have never looked for yourself. That is the direct output from the debugger after hitting compile. Nothing was "put in" that is EXACTLY what executes for those C# lines.

Quote:

---

If you don't believe me, here are more post online in other places like msdn:
...After a bit of reading, that is enough proof you have a bigger and faster chance to decompile a .net app than c++....
See they put msil in the exe which this is so simple to conw: vert back
http://msdn.microsoft.com/en-us/libr...k1(VS.80).aspx
look at that. microsoft allow you to get your original source code back and it uses their on tool.

---

Yes, the FILE ON DISK contains MSIL (by default), but this is compiled to native code by JIT (Just In Time).

Even go back back and look at your post, and you acknolwedge that both C++ and .Net applications can be reverse engineered. Yes, by default it is easier to do this for a .Net application, but if there is motivation and skill then the differential is so small as to be insignificant in the hands of someone experienced (e.g. has logged over 100,000 hours developing software)


(btw: I have worked with and personally know many of the developers at Microsoft, I have also been published in MSDN (although it has been a few years - since before .Net in fact).

Quote:

---

Originally Posted by Arjay

Now look at a guy like TheCPUWizard who has been in business for 35 years and imagine if he didn't stay current with new technologies? Do you think he would still be in business today if he only knew the languages/techniques that he learned in the first 5 years?

IMO, as a developer you need to stay current with the latest technologies; otherwise you are going to find that work is harder to find.

---

:thumb: :thumb: :thumb:
Agreed 100% ..

Staying current is key to keeping in business..

To compare to the current discution. Imagine a Electrical engineer opening a factory store where he manufactures and sell's 486 or P1 systems. 10 years ago he could have made a killing if his prices were comparable to the market. However today i doubt he'd make more than 1 sale, if!!..

VB6 has that look and feel that is, well VB6. and some people want the new XP or Vista look and feel that is easier to get with .NET...

Quote:

---

Originally Posted by TheCPUWizard

Yes, the FILE ON DISK contains MSIL (by default), but this is compiled to native code by JIT (Just In Time).

---

That's just the point. What does it matter what's in memory, when the file contains MSIL? Change the file, and that changes what the compiler puts into memory.

Quote:

---

Originally Posted by TheCPUWizard

Even go back back and look at your post, and you acknolwedge that both C++ and .Net applications can be reverse engineered. Yes, by default it is easier to do this for a .Net application, but if there is motivation and skill then the differential is so small as to be insignificant in the hands of someone experienced (e.g. has logged over 100,000 hours developing software)

---

If a hacker spent 100,000 hours developing software, why would they resort to hacking someone else's work? Besides, MSIL is so much more vulnerable, just as Java is more vulnerable than C++. So with that ease of decompilation, any two-bit hacker will have a working copy of your source code far easier. It would no longer take such a dedicated effort.

Aside from your posts on this, everything I've read suggests .net is comparatively vulnerable. I'd think it would take a lot more proof than any person's statements on the forum to be convincing. Now, if you can post a .net file (not JIT output) which can't be decompiled by any of the various tools out there, that might be something.

Quote:

---

Originally Posted by WizBang

Change the file, and that changes what the compiler puts into memory.

---

Applies to any environment, which is why any secure program MUST run security checks on the program and constant data sections of memory and refuse to run if tampering is detected.

Quote:

---

If a hacker spent 100,000 hours developing software, why would they resort to hacking someone else's work?

---

Because it can pay extremely well. The 100K figure quoted is actually based on my own work journal (109,872 as of this morning - starting June 24th 1977). My current "Reverse Implementation" charges start at $250/hr (US), and are only offered when the client has provided legal proof that they have a right to do so.

Quote:

---

Besides, MSIL is so much more vulnerable, just as Java is more vulnerable than C++. So with that ease of decompilation, any two-bit hacker will have a working copy of your source code far easier. It would no longer take such a dedicated effort.

---

A working copy of the default output from a managed language, I agree. Information is put into the file to allow for things such as reflection to work. This information should be stripped if there is a desire to stop people form having access. For a fair comparision, distribute your native applications with full .PDB files...

Quote:

---

Aside from your posts on this, everything I've read suggests .net is comparatively vulnerable. I'd think it would take a lot more proof than any person's statements on the forum to be convincing. Now, if you can post a .net file (not JIT output) which can't be decompiled by any of the various tools out there, that might be something.

---

Again we are back to a matter of degrees, and not absolutes as some other posters have been ranting about. This weekend i will post some samples of the output using various simple techniques to minimize what
is exposed, along with some simple examples of what can quickly be reversed engineered from a native C++ implementation of the identical program.

But if you want to run an experiment in the meantime. Take ANY .Net executable, run it through ngen.exe (which ships with the runtime) and examine the resulting .EXE file...

I think it is also important to look at the many commercial programs out there which do use .NET are written by responsible companies, and evaluate their "risk assesment" of any additional exposure resulting from using .NET.

Also consider Microsoft itself. When they released SharePoint 2003, it was based on .NET and was obsfucated to minimize the information that could readily be viewed (these were the only .NET assemblies shipped by Microsoft to be encoded this way). After a very short period of time, they realized that the negative impact of obsfucation (eliminating capabilities inherent in .NET assemblies simply because of the visibility) outweighed any "protection" of either Intellectual Property (and we know how possessive MSFT is) or of tampering.....

So, I agree with you in not taking the word of ANYONE. Investigate it for yourself. Look to see what applications have been successfuly attacked, and compare the percentages.

Quote:

---

Originally Posted by TheCPUWizard

Because it can pay extremely well. The 100K figure quoted is actually based on my own work journal (109,872 as of this morning - starting June 24th 1977). My current "Reverse Implementation" charges start at $250/hr (US), and are only offered when the client has provided legal proof that they have a right to do so.

---

I'm sure "bootleg" copies which are being sold can be profitable, but what about the guys (who it seems have way too much free time on their hands) that hack a program, and upload it to any number of websites which more or less give the stuff away? Seems to me that's who we are mostly up against.

Quote:

---

Originally Posted by TheCPUWizard

A working copy of the default output from a managed language, I agree. Information is put into the file to allow for things such as reflection to work. This information should be stripped if there is a desire to stop people form having access. For a fair comparision, distribute your native applications with full .PDB files...

Again we are back to a matter of degrees, and not absolutes as some other posters have been ranting about. This weekend i will post some samples of the output using various simple techniques to minimize what
is exposed, along with some simple examples of what can quickly be reversed engineered from a native C++ implementation of the identical program.

---

Are you saying that the exe file can be compiled to a standalone executable, and not require the .net framework? Or are you saying that the exe file need not be MSIL at all?

As for reverse engineering a compiled C++ program, sure, we both know anything is possible, given enough time and resources, dedication and knowledge. But that doesn't make .net just as secure.

Quote:

---

Originally Posted by TheCPUWizard

But if you want to run an experiment in the meantime. Take ANY .Net executable, run it through ngen.exe (which ships with the runtime) and examine the resulting .EXE file...

---

Well, that I can't do on this machine, but it sounds like you're suggesting the exe would be "converted" in some way to native code, which to me should imply no longer needing the framework to run - a completely standalone exe. I'd be surprised if that's possible, and it would be news to me.

Quote:

---

Originally Posted by TheCPUWizard

I think it is also important to look at the many commercial programs out there which do use .NET are written by responsible companies, and evaluate their "risk assesment" of any additional exposure resulting from using .NET.

Also consider Microsoft itself. When they released SharePoint 2003, it was based on .NET and was obsfucated to minimize the information that could readily be viewed (these were the only .NET assemblies shipped by Microsoft to be encoded this way). After a very short period of time, they realized that the negative impact of obsfucation (eliminating capabilities inherent in .NET assemblies simply because of the visibility) outweighed any "protection" of either Intellectual Property (and we know how possessive MSFT is) or of tampering.....

So, I agree with you in not taking the word of ANYONE. Investigate it for yourself. Look to see what applications have been successfuly attacked, and compare the percentages.

---

If SharePoint was the only .net app distributed by ms, that tells me something. Plus it suggests they did it as an attempt to convince programmers to follow their "lead".

About looking at which .net apps have been attacked, successfully or not, just how would anyone do that?

But I will poke around to see if I can find something written in .net. However, if it requires the framework, that to me suggests it is MSIL, which wouldn't seem to be much proof of anything. I do see tons of programs claiming to protect .net apps though, which is highly suggestive.

To CpuWizard:

I sure can't wait to see someone that can decompile quake 4 since it was written in c or any other game, but this haven't happened yet and I know why. Native code doesn't go back to anything. If you can find out the decompiler, so what. With 35 years of working with code, I think you would know that native code is just that and nothing else. Not msil. When I say compile, I mean just that. 100% pure native code compiled to the exe. If you can decompile c or c++, it would be in assembly language and that is it unless you plan on writing a reverse compiler if that is even possible.Your post says "Why vb6.0" and not "Why would you learn vb6.0". To me you are being very unclear on your intentions. You want to say you can decompile c++, but I never once show this. If you want to show you can decompile a c++ app, use the gcc compiler. I want to see this one get used for your decompiling c++ act. Also when you decompile the .net app, I want to see all the available .net decompilers without protecting your code. After that I want to see the .net app with protection go threw the .net decompilers and 100% documented.

I even tell my cousin that works with c#, that has a paying job with it, he can decompile his work and he has. He lost his source code for his project and got most of it back. Good for him.

People do have a point that businesses use the .net, but most of it isn't in the public domain. Most of the stuff in the public domain, is not the .net. I only ran into a few that are .net apps. The most apps I use are made with c++, c, java, python, delphi and so forth. The last in the list is the .net.

There are way too many versions of the .net and way too many versions of the ide. This produces nothing useful unless you like giving your money away for free.

One more thing. the .net is slower than vb6. Each time the computers get faster, the languages that are made gets slower. End of story. I am getting tried of this post. It is getting boring and anyone using the .net hasn't given a value reason to use it.. besides that is easy to use and it collects garabage

Quote:

---

Originally Posted by WizBang

If SharePoint was the only .net app distributed by ms, that tells me something. Plus it suggests they did it as an attempt to convince programmers to follow their "lead".

---

Other MS applications have at least a portion of them written in .Net - Biztalk and SQL Server to name a couple.

Quote:

---

Originally Posted by WizBang

I do see tons of programs claiming to protect .net apps though, which is highly suggestive.

---

I see many programs out there that claim to speed up applications or clean the registry, but does that mean anything really?

To me, as a consultant/developer, I need to have the skills that enable me to bring in new work. The type of work that I do demands that I offer solid solutions that can be coded in a competitive amount of time. I can't (actually won't) offer a solution that has been coded with development tools that are no longer supported by Microsoft (such as VC6 or VB6). I would be embarassed to do so. It would be like recommending that my customer use Win95 or NT3.51 to run their critical software on.

Furthermore, many customers expect modern UI's or web interfaces. With Silverlight 2.0 you can get a modern UI, or RIA (Rich Internet Application), in the browser - in fact Silverlight 2.0 runs on many different browser and on non-Windows platforms such as the Mac and Linux. For those of you that don't know, Silverlight 2.0 is a subset of WPF (Windows Presentation Foundation). If you want to learn WPF or Silverlight, you need to learn .Net 3.0 or later.

If you can see the benefits that this new technology brings, understand you aren't going to be able to do this with 10 year old technology.