Vb Classic Stability Issues

Discussion of VbClassic stability issues.

Actually, VbClassic can compile, too, but most of the time you're using it as an interpreter. So how come when my program crashes, it crashes the IDE? That sucks. Certainly I should write good error code. I should never write bugs at all. But when I do - we all do - a good IDE will explain just where and how the error occurred. VB just crashes.

Another PilotError?

Again, if it's pilot error, it's one that MS** qualified staff spending many hours poring over MSDN couldn't fix. Every other IDE in my experience is robust enough to catch code exceptions and give you the ability to debug the error. VB just crashes along with the app. Sad.

It is a compiler. Use VB5 or VB6. Compiles to native code as fast as C++. C2.exe is what compiles the 32 bit machine language. Do you know what else that application is used for. Does VC++ ring a bell?

You're right here, VB will compile if you ask it to. But why is the result so much slower than C++?

Too often, I see code compared that is not apples to apples, ie a skilled Java programmer will write optimal Java code and compare it to some spaghetti they hacked in another language that they do not understand; let's not only see a matrix of your benchmarks, but your source in both languages, before we answer the speed question. Without scientific methods, we would only babble about performance, no? My testing has revealed that VB, comparing optimized code to optimized code, isn't much slower. Math ops are the same speed; strings ops, due to the use of the latest Unicode standard for text exchange, are slower, yet more robust. Remember to learn and use compiler optimizations when running your tests. Sometimes, when VB's advanced 32 bit compiler optimizations are not known or understood, benchmarks are skewed dramatically. Math and collection reference pointers with lag behind, if you do not have an expert at the VB IDE wheel.

Also, does anyone here know how to set the base memory address of a VB DLL?, does anyone here know why you do it? Let's learn these things before spouting off performance issues that we do not understand.

''On first call to a VB COM server, you will notice a hit (measured in thousandths of ms - .005 maybe) as the internal language reference library loads, much the same as the VC++ language (runtime), if the VC++ runtime is not statically linked (a static linked runtime causes slight overhead *every time* you make a call to a C++ COM server, not just the first time!).

As to the size of the VB runtime, which is likely to be the next topic, the VB runtime keeps getting larger for backward compatibility - there are many functions that are left over from Basic in the runtime. I do not like this, but it is a trade-off that proves to be acceptable most of the time. I am hoping the MS VB team will separate or sub-divide this functionality more in the future so that only what is needed, or a smaller superset of runtime support needed will be able to be included with the projects...

I'll concede that with the right tweaks, it ought to be possible to get a fair amount of speed out of VB. I'll also agree that it requires expertise that I'm beginning to think the group I worked with was lacking, despite a good amount of MS letters after their names. Most of my gripes are on maintainability, not performance; I believe any real performance problems could be licked by means of AlternateHardAndSoftLayers anyway. -- PM

I don't understand what tweaks you are talking about. Any component Windowsprogrammer should be able to get the performance provided they compile to machine code, optimized for speed.

Just the tweaks Charlie mentioned. I think we're in agreement here. -- PM

Well, I have never experienced a VB IDE crash. Are you running on NT with at least Service Pack 5 installed and at least 64Mb of memory? If you are developing on Windows 95 or 98 you're crazy. Have you installed Service Pack 3 for Visual Studio 6.0 that fixes many such bugs? Do you write good code that doesn't blow things to heck? Do you check for errors? Again, I have never experienced anything like this and I am currently using VB 6.0 12-14 hours a day. I have never lost a reference.

Sam, I've been trying to be gentle to you, but sometimes you just hang yourself with your own words. "12-14 hours a day"? is that supposed to be bragging?? -- PhlIp

Wow! You never saw the IDE crash? Sam, I'm extremely interested in knowing what hardware you're using there. For the 8 months my team was suffering with this tool, every developer saw crashes every day. We were developing on NT with SP4 (SP5 caused other stability problems) and VS6 SP2 (I think SP3 wasn't out yet).

I don't know what you mean by "do you write good code that doesn't blow things to heck" though; I've never met anyone who never writes bad code that does blow things to heck. I don't believe it is humanly possible for anyone to code without writing bad code that blows things to heck. Good tools are tolerant of use by regular humans. Tools that are billed as being good for unskilled workers ought to be doubly tolerant. -- PM

Sam -- please explain -- you say you have developed large enterprise apps in VB and have not experienced problems with the IDE crashing? Do you have any suggestions for me. My team is developing a medium-sized enterprise app. We have one executable and four dlls which we load in one Project Group so we can debug freely into any of the code. When we close the project group (which unfortunately we have to close and reopen it any time we check out one of the project files -- I wish we didn't have to do this), about 25% of the time the IDE will crash. I am running NT sp 5 and VB6 sp 3 with 128M of RAM.

It also bothers me that VB uses so much RAM to run. By the time I run SQL Server and VB and run our app from the VB environment, I am past 240M on the Windows Task Manager memory usage report; since I only have 128M I am thrashing big time. By not running SQL Server I can save about 20M, but that isn't significant. Perhaps the fault lies with my application for doing a poor job of managing memory. In C++ I would know how to profile for this but I am totally a newbie at VB. Can anyone point me to information that would help me discover and fix such wasteful memory habits in my VB application?

-- KayJohansen

PM and Kay, I would like to help you be successful with this tool. There is in fact profiling and memory tools available from NuMega for VisualBasic. There are about 5 of them I think. I have used them very well to check my code for possible bad parameters to the API, memory leaks, and performance/speed/memory problems. Check them out. As to the memory issue. I'm sure Charlie would agree, you should NEVER ever run SQL Server on the same machine as you are developing on. That's how we do it at ToySmart?. We have about 40 developers developing in VisualBasic and Visual C++, and we have only what we need on our development machines. We run SQL Server and Site Server on separate distinct servers. And we use top of the line hardware from Compaq. I know it's hard to believe but I rarely see my IDE crash. Charlie talked about how you can make it happen, passing a bad parameter to the Windows API, but in the last month and a half of developing Server Side VB COM components, and test applications, I have not had one single VisualBasic crash. No NT crashes either. Very stable.

Sam -- thank you for your reply. I really appreciate the tip on NuMega's tools. I will look into those. As for the memory issue, I will take your advice when you say it's not a good idea to run SQL Server on my development machine. Makes sense; it was just a convenience because part of our team is developing to SQL Server 6.5, part to 7.0, and we have one server which is set up with 7.0. But that's an easy problem to solve. I'll let you know if that helps my memory problem, but I am doubtful, because as I said running SQL Server seems to only take up 20M. It is when I run VB and my app that I lose the other 150M.

Thanks,

-- KayJohansen

Likewise, Sam, thanks. What you and Charlie have said suggests strongly to me that the problems I encountered came from running VB on the same box as other apps - not SQL Server, but a couple of Oracle browsers, the Cygnus tools, Vim and other odds and ends. Next time I have occasion to use VB I'll be extremely careful to run nothing else on the box. Perhaps needless to say, though, I'd have appreciated it if advice like yours had been available from MS up front, and this inability of the tool to interoperate with others is another one of those ThingsWeHateAboutVbClassic ... -- PeterMerel

Peter, it's not that VB does not interoperate with other things. SQL Server is an enterprise level database server requiring enterprise level memory and resources. It belongs on a stand-alone machine, not on a development machine. In terms of your case, I'm not sure of what you are running, but I can run VB, VC++ (2 copies), CodeWright, IE, MSDN, and other things at the same time.

Perhaps some people have a stable way of using it. I just haven't seen it, and I expect others to strike the same difficulties I struck before they achieve the stability you've achieved. -- PM

Apparently, installing the right versions of service packs and the right version of Windows NT on a sufficiently powerful computer gives you a stable VB installation. See also ServicePackHokeyCokey.

Thank You! What version of the DAO/ADO/ODBC/MDAC/DBwhatchmacallit dlls do you use and when do you install them? -- PM

Thanks again Sam. Next time I do VB I'll start right there. -- PM

Bloody Hell! Do I have to wave a dead chicken as well? Why do I have to reapply ServicePacks?, or apply them in some mysterious order? That's incredibly broken. Saying thankyou to Sam for this (nothing personal, Sam) is like saying how good it feels when you stop beating your head against the wall. -- MartinPool

Sam shared some very deep expertise here, Martin, and I appreciate that greatly. I have a lot of respect for someone who can do productive work in VB. Of course it's not terribly likely I'll want to do VB again, or have my fingernails torn out by the roots, or crawl a mile on my belly over broken glass, but it's most reassuring to know that once upon a time there was a page hidden deep within a description of an unrelated product I never ran that contained the secret knowledge I'd need in order to use VB again.

But then again VisualBasicDotNet sounds so nice maybe it really will tempt me to go back to VB land one day. If they're true to their words ... -- PM

I've read with amazement most of the VB IDE is unstable and crap stuff. Crap - well, I quite like it but that's a subjective judgement so no argument from me. But unstable? Not that I've seen over the last 5 or so years. Yes, I've had it crash on me, but it's not a common thing. I've also never worried about the order of installing things and have upgraded often, with no problems. As far as getting MCSE or whatever after your name - my personal experience of such people has been statistically insignificant but so far I can honestly say that it makes no positive impact on any of my hiring decisions. So I'm not at all surprised that 'MS** qualified staff spending many hours poring over MSDN couldn't fix it'. After thinking about it for quite some time, I've come to two tentative conclusions:

1) Because of its accessibility as a language, it can easily be misused.

2) If used 'properly' it is easy to write large-ish (200kloc) applications which support complex business functionality, look good and are easy to use, can run 24/7, and are scalable.

My 2p worth! - SimonSmith

Our recent experience with VB 5.0 and VB 6.0 on NT 4.0 has been that the integrated SourceSafe addin causes problems. We've concluded that you should never check modules back in through the VB IDE -- it fails and/or crashes on a regular basis. Fortunately, check files out (for modification by the programmer) is pretty reliable and safe.

Yes, some of our developers still spend hours doing development in a single run of the application, and sometimes they really pay for it, sometimes more than once a week. The IDE shouldn't crash, but it does. I've learned to be wary, never making more than a few changes before killing the run so I can save. It's not the "extreme way," but I >>> really hate it <<< when the system loses my work. -- JeffGrigg

I really don't know what you guys do. I have never seen this.

Put this in your VisualBasic program, and run it under the IDE: 

   While True
      MsgBox "I've got you now!!!"
   Wend
You're trapped: The IDE is dead whenever a MsgBox is up, so the only way to terminate this program is to bring up the Windows TaskManager? and kill the program. (Doing this makes you lose all changes you made while running the program, just like an IDE crash.) -- AnonymousCoward

While the msgbox is displayed, press Ctl-Break. Then click OK on the message box. What happens then, eh? Sorry to be a bit testy, but this example and most of the others above are, while maybe not Pilot error, sheer Pilot Ignorance. If you were developing something you were being paid for, I hope the rate was low. The note about Novices above applies to every language. If you really are developing in VB professionally (and this is how it gets its bad reputation amongst 'professionals'), get yourself on one of the VB mailing lists; some of them are of the highest quality. -- SimonSmith

<FLAME> Yeah, you heard me. Step one toe into the wonderful world of MicrosoftCorporation and you're back to Basic. Perhaps the last time you touched it you were still in short pants, but there it is - all the hooraw over structured programming, logic programming, functional programming, OO programming was for nothing. Concurrency, Exception handling, and any architecture that ain't 3-tier - come on, who are you fooling, you don't need that stuff. Basic, that was the answer all along. That was always the answer. </FLAME> -- moved from VisualBasic page

True story. About four yeas ago at a job fair, I went to the Northrup-Gruman booth. The lady was occupied by someone else. He was extremely well dressed.

She told him that they were looking for ADA and C++, but not VB. VB wasn't good enough for the controlling software on an airplane. He asked her to clarify. She explained that new features on F14's were implemented in the controller software and that they never modified the hardware. "No way", he exclaimed and walked away with a look of total disbelief on his face.

My experience with VB programmers is that most fall into this category. -- ThaddeusOlczyk

I was burned trying to debug someone's VBScript code that did something like this: 

option explicit
on error resume next


while i < 10
WScript.Echo "loop"
i = i + 1
wend
The on error resume next takes precedence over option explicit. Each reference to i cases an error, which then moves to the next line. The result is an infinite loop. This was on an ASP page, no wonder it was taking so long to come up.

The moral? on error resume next can be set in functions or subs to limit it's scope. Use it in the smallest scope possible.

The On Error Go To structure is completely flawed in VB. It will be totally replaced in VisualBasicDotNet with the correct exception processing (try catch). Yes, limit the scope. Also see the excellent chapter "OnError GoTo Hell" in the book "Advanced Visual Basic 6." Great Guy. Great book.

Try this trivial, repeatable crash scenario: open a project in VisualBasicSix?, open a code module, press Ctrl-F to open the Find dialog box, specify text to find, click to Find Next, close ALL code modules, press F3 to Repeat Find, watch VB completely crash.

I tried it (as of Aug 30, 2002) with a fresh VB6 sp5 install on Win2k sp3 -- ThomasEyde. I should probably add that it did not crash.

Also, I have often seen VB crash while using third-party controls (even "high-quality" ones) or while accessing the Windows API, even on Windows NT. That is simply not acceptable based upon the expectations encouraged by Microsoft and third-party marketing. I can understand a C/C++ application crashing, and maybe even a C/C++ IDE crash (due to the application crash). But a VB crash is inexcusable, especially when it is not the direct result of my application crashing.

CategoryVbClassic

EditText of this page (last edited February 2, 2009) or FindPage with title or text search