VB

[LeStat]

Why arent VB apps considered portable? With all dependency files inside the folder with the executable, nothing has to be installed. (ie: mscomctl, winsck.ocx, etc.)

[stumpii]

VB does require a number of runtime files to be installed, like MSVBVM60.dll. I don't know if they can be in the programs folder.

[Kaonashi]

I think they can. Like LeStat said. I've made an application portable this way a while ago, so at least it works for some apps.

[Darkbee]

But if you need the same dll in the folder of each app that requires it, potentially you could end up with dozens of copies of the same dll. Doesn't that seem rather inefficient?

A solution, of course, would be to have all VB apps in one folder with the dll/s present but that is a question of organization and whether people can live with that or not. I could live with it if I really had to but I prefer not to. I like to keep my apps separate and distinct.

[LeStat]

Very true DarkBee, and I took that inefficiency into consideration for a while. Then, I noticed all of these apps being considered portable that need the gdi+ dll in each folder that has an app that needs it... So I really dont see a difference, do you?

[Darkbee]

Very true DarkBee, and I took that inefficiency into consideration for a while. Then, I noticed all of these apps being considered portable that need the gdi+ dll in each folder that has an app that needs it... So I really dont see a difference, do you?

No, I do not and that is why I tend to steer clear of those apps as well. In my experience there are only a very small number of VB apps that I might consider using and in most cases I can find alternatives that are not written in VB.

I think everyone can agree that the best case scenario is that an app has no dependancies at all and relies purely on system calls (typically apps written in C++).

Naturally, the most important thing to remember is that what apps you choose to use and why, is completely your choice. Just because a website like Portable Freeware won't accept certain applications doesn't mean you can't use them. If you find a VB app that works from you then use it.

[Andrew Lee]

I will be adding apps that depends only on MSVBVM60.DLL. Like LeStat mentioned, there is no difference between that and having GDIPLUS.DLL in the application folder.

However, apps that depend on mscomctl.ocx, winsock.ocx etc. are not portable AFAIK. These are ActiveX controls that needs to be registered on the target machine either manually or by the app. If it is the latter, then admin rights is required.

[LzBy1]

Essentially it is possible to have VB applications that are portable, however, Microsoft VB is now VB.NET and most applications require MS .NET framework to run. I figure it will be safer to stay away from VB programs for this reason. C++ Applications are safer because the end user only deals with pre-compiled applications while the VB.NET applications are, for lack of a better term, compiled at the runtime. That's where the .NET runtime environment comes in. Here's how I had it explained. With the .NET framework, VB.NET builds a set of instructions that tells the end user's computer what to do. The application is still compiled and runs the same as non runtime languages, however, it is dependent on the .NET framework. This framework does nifty little things like handle exceptions and clean up to memory during runtime. So even if you could configure a .NET application to run without the framework, I wouldn't advise it. This process takes up more resources, even if they aren't significant. With other languages such as C++, the application is compiled before it's distributed. The code the programmer writes is the set of instruction that tells his compiler what to build. So for the end user, the difference is like buying a new car (C++) or buying a car kit and putting the car together yourself (VB.NET). The end result is the same, so essentially it is up to the programmer which method he choices.

With all that said I would recommend to programmers out there that you just learn Visual C++. The syntax my be more difficult but the concepts are the same. Microsoft has also done a great job in the newer revisions of visual studio in improving the 'intella-sense' so making the transition from VB to C++ isn't hard.