Me too. VB paid the bills around here from about 1994 to 2000. (That and a whole bunch of C++ hidden behind a COM interface to do the real work.)
I still use VB6 frequently to create test harnesses for COM objects. It's faster to load than yet-another-instance of VS 2005, and I can't deny the "comfort" of an interface that I lived in for so many years. And I really like the object browser that came with VB6; it's much better than OLEVIEW or the mostly useless ActiveX test container that came with VS 6.
I was under the impression that.Net compiled at install-time.
Nope, it's normally just-in-time compiled. You can pre-JIT the code, but Microsoft strongly cautions against the practice. I also believe it can cache the JITted code, so that subsequent executions can run without penalty (if the environment doesn't change.)
However, since I got beat bloody for making the mistake of saying the word "interpreted" I'm not going to state that's an absolute fact.
Sorry, I totally misspoke. I know full well that both Java and.net are JIT compiled languages.
I also know that they take a non-inconsequential amount of horsepower to run -- read the minimum system requirements for.net, for example, and you'll find a 400MHz processor is listed. While that's not a challenge for today's desktops or laptops, it's a serious question whether or not a ten-year-old computer will be able to run it. And there are plenty of embedded processors that are nowhere near capable of running it.
We have a large number of 233MHz machines that we have to keep around for another few years. Until we get all of them replaced,.net isn't even an option for our client software. (Microsoft is annoyed that we haven't locked ourselves into.net yet because of this.) At that time, I suppose I'll stop thinking of them as interpreted, and maybe I'll even stop referring to Java and.net as GW-BASIC.:-)
Nope. True, VB produces an.exe file, but you can't run it without the VB interpreter.
That's sort-of technically correct, but not right. You don't need the interpreter, but you do need the VB6 runtime libraries. And they're both located in the same dynamically loaded module, msvbvm60.dll. While it still contains the "Visual Basic Virtual Machine" required to run the p-code, if you natively compile the program it simply is used as a container of the resources VB programs require. The p-code executor is not used.
The knowledge base has this article which doesn't describe it very well, but kind of hints at how it works.
Untrue. VB6 compiles into native x86 executables by default. The option is there to compile to P-code (the old VB4 stuff) but that hasn't been a requirement for at least eight years and probably more. And it's not on unless you explicitly choose to use it. I have never found a reason to do so.
Any app can devolve into kludginess unless there's a strong approach to coding shared by every single one of the maintainers. VB6 isn't magic that attracts crud any more than C++ or Java (other than increasing the number of potential idiots who think they know how to program in VB.)
Any user interface, regardless of language, should be usability tested at every major release. A lot of developers are horrible at adding interface widgets because they're too wrapped up in the solution rather than the problem. How often have you heard someone do something like this: "I just solved the corrupt index problem by adding a StackWalkAndRebuildAllIndexes() routine. I stuck this big ol' "WALK THE STACK" button right on the front screen so JohnsonCo. will quit calling me at 5:00 on Friday afternoons." And the product ships with a stupid WALK THE STACK button right on the front screen.
Strong design is the best cure. Failing that, rigid and annoying development processes will at least delay the implementation of the cruft, along with your valuable modifications.:-)
A fair argument against VB6 is that it's at end-of-life. Microsoft has dropped support. You find a bug in it and it's all yours. But honestly, there just aren't that many bugs left in VB6 that aren't already known.
There's a different point of view you need to seriously consider: who's signing your paycheck? It's not Microsoft, is it? I thought not.
Consider meeting your boss in the middle. It's possible your boss is set on VB6 because he can read it fluently. Perhaps you could convince him to port it to VB.net. VB.net might not be so different that it would scare him. The GUI isn't all that different. And the.net framework would allow you to gradually expose him to other languages (C# or C++/CLI.) And it would allow you the opportunity to use a language with better libraries than VB6.
Have you dug a bit to find out why he's so pro-VB6? Maybe he's biased against.net because it's an interpreted language (like Java)? Perhaps half of his client base is all still running Windows 95 on 90 MHz pentiums, and.net is not an option for them. Maybe he'd be OK with C or C++ compiled to native executables, as long as there are no.net requirements. Microsoft's latest version of C/C++ has a strong push towards safer coding with bounds-checked versions of all the standard library functions. That might be good enough for him.
Or maybe he just has only two or three long-term clients that are stuck on Windows 3.1, but they've been with him for 25 years so he feels he has to support them into the far future. Consider buying them a few cheapo PCs to run your software: $400 each for a few bottom-feeder Dells would go a long way with customer goodwill, and would allow the rest of you to move into the 21st century of tools. And a $1200 hardware investment is much less money than your time spent struggling with old tools.
If he built a successful business around a piece of software, the chances are good he's smart enough to listen to rational arguments. So don't be irrational by kicking in your heels and saying "no! no! no!" unless you really enjoy job hunting.
My hardware is definitely up to the task of running Vista without spending more money, but I'm not upgrading for the simple reason of "Treacherous Computing". I will not be a party to the erosion of my rights to do whatever I want with my own computer. It's not that I'm a pirate: I do not download movies or music simply because I think it's wrong to do so. However, I do not agree with the latest EULA that came with Windows Media Player because it's too onerous, and so I have not ever clicked "I agree" to the install package. (Winamp and VLC continue to serve me just fine.)
If this means no more software is available to me because I won't upgrade, then I guess I won't be buying any of it. At $50 USD / video game, producers will need to think long and hard before releasing any "Vista Only" titles. (Hell, some are still releasing titles that can work on Windows 98.) Would you risk the revenue of a ten million dollar title betting on Microsoft's ability to pimp their newest OS? Are you going to be the one to explain to your boss "It only sold 200,000 copies because the guys who pirate software won't move to Vista."
OS lock-in can work both ways. Let's play this one to our advantage. Boycott Vista.
Just because someone is multibooting between Ubuntu, Mandriva and Xandros doesn't mean that Okopipi will be... uhh,... confused... oh, never mind.
OK, so maybe they should have stuck with Black Frog. It'd probably be even better if it were followed by a parenthetical "of Doom", as in "Black Frog (of Doom)". Now that sounds more like something people should be afraid of.
Well, I read the spec and it's filled with detail regarding the file format. If DRM were a consideration, I would have expected to see some implementation notes in here. There is none.
They seem to have gone to great lengths to maintain TIFF compatibility, though, and I kind of wondered why this wasn't just implemented as another codec inside TIFF. (A rational explanation could be that the format is completely "little endian" which would be TIFF-incompatible.)
Anyway, nowhere in the spec does it mention DRM, and the word "rights" is only used in conjunction with Microsoft reserving their rights to the document and to the spec. This is not a DRM-encumbered format.
wouldn't it be a whole lot easier with OS features
That's where you make the same mistake as the Windows fanbois. It should not the job of the OS to mix audio streams. That's an application problem, and it deserves an application solution.
If you think it should be handled by the computer, acquire or write a userland mixer application. But don't make the mistake of calling that an OS function. The mixer can even be provided by the OS provider (in order to create a standard,) but it shouldn't be considered an OS function.
Then, if you want to mix 400, 300 or even just two audio streams, you load the mixer. If you have a low end system that can't handle audio mixing, well at least your OS isn't bloated to the point where it's dragging in extra crap that you cannot use.
The more you pack into the OS, the more of a problem the OS bloat becomes. Windows has proven that beyond any shadow of a doubt.
Maybe if enough people do it, then the next time they upgrade their site they will ask only for information that they absolutely need to have instead of every little detail.
Heh-heh. You've never worked for a large company, have you?
Employee: "Hey, boss, this data's no good. Most people are just typing a-s-d-f for their names and addresses and registering fake info!"
Manager: "Yeah, but it's really important that we find out what they think of our site. Let's get them to take a customer survey after registering."
Oh, I know it doesn't. For example, I know our Exchange server doesn't put any headers on my email differentiating mail originating on an inside SMTP port vs what comes from the outside (unless you look closely at the Received chain.) It's just that in "most" cases, it really is spam.
And I'm the opposite. I saw a giant blob of advertising, with some line claiming to be "you are receiving this because you are subscribed to blah-blah.com's mailing list." Looked like spam to me, but the filters thought otherwise.
Sure, the ci-al'is messages are "classic" spam, but a lot of the mailing list crap is just as spammy. I don't spend a lot of time distingsuishing between the various sources of advertising. And as far as I'm concerned, I'm "right". A message containing an unreadable buttload of advertising text is spam, whether asked-for or not.
One final complaint, and that's about outlook/exchange: why the hell doesn't it treat "internally" sourced messages differently than "external"? If I worked at X-Corp, and got an exchange message from another X-Corp employee, why are the filters even looking at these messages (other than to build up a "valid email corpus"?) If a message from randomname@x-corp.com came in through the external SMTP gateway, sure, it's probably forged and/or spam. As a matter of fact, it's one of the most obvious indicators of spam -- so why doesn't Exchange understand this and take advantage of this?
Currently, there is no way to close a tab without first selecting it.
I used to think this too, which is why I used to use the TabX extension. However, since at least Firefox 1.5 I've been able to "middle-click" a tab to close it (without giving it focus.) Once I learned that, TabX was gone.
Re:SQL is a standard. Is it?
on
SQL Cookbook
·
· Score: 1
Well, remember how a standard is created. It's put together by a committee of people all of whom have a vested interest in using the standards process to give them some advantage.
The Microsoft rep says "hey, we have to support language extensions for row locking this way, because that's how our engine works." Oracle says "Well, let's just agree to call row locking an 'extension' but not define it because we do it differently." The DB2 guy says "Everybody needs to be able to DROP TABLE, so that should be in the standard."
Even representatives from the various users' groups have biases towards their preferred languages. And while it might be in the best interests of DBAs everywhere to have a completely common language, it's not going to happen because the Oracle users' group is going to have a different opinion of what's right than the MS SQL users' group.
The point is they all want the language to go exactly their way for patent reasons, for ease-of-maintenance reasons, and for the ability to cripple their competitors who are unable to comply. And for the most part, these special little provisions find their way into the standard, mostly because all the vendors benefit from the vendor lock-in resulting from the fractures.
It's not fair to say "don't blame ANSI" because the process producing these so-called standards really is to blame. Nobody from ANSI ensures that the meetings are attended by user groups, or that the users themselves have more or less voting authority than the manufacturers. If ANSI really cared about standardization, they'd say "no extensions." But that doesn't serve us well either, as there'd be no room for progress in the language.
Slashdot Mirror
Are you sure that's not just a close-up view of a region of the Mandelbrot set?
I still use VB6 frequently to create test harnesses for COM objects. It's faster to load than yet-another-instance of VS 2005, and I can't deny the "comfort" of an interface that I lived in for so many years. And I really like the object browser that came with VB6; it's much better than OLEVIEW or the mostly useless ActiveX test container that came with VS 6.
Nope, it's normally just-in-time compiled. You can pre-JIT the code, but Microsoft strongly cautions against the practice. I also believe it can cache the JITted code, so that subsequent executions can run without penalty (if the environment doesn't change.)
However, since I got beat bloody for making the mistake of saying the word "interpreted" I'm not going to state that's an absolute fact.
Yeah, I already apologized for the .net/Java error, and it has been beaten to death already by at least a dozen previous commenters. Try to keep up.
I also know that they take a non-inconsequential amount of horsepower to run -- read the minimum system requirements for .net, for example, and you'll find a 400MHz processor is listed. While that's not a challenge for today's desktops or laptops, it's a serious question whether or not a ten-year-old computer will be able to run it. And there are plenty of embedded processors that are nowhere near capable of running it.
We have a large number of 233MHz machines that we have to keep around for another few years. Until we get all of them replaced, .net isn't even an option for our client software. (Microsoft is annoyed that we haven't locked ourselves into .net yet because of this.) At that time, I suppose I'll stop thinking of them as interpreted, and maybe I'll even stop referring to Java and .net as GW-BASIC. :-)
That's sort-of technically correct, but not right. You don't need the interpreter, but you do need the VB6 runtime libraries. And they're both located in the same dynamically loaded module, msvbvm60.dll. While it still contains the "Visual Basic Virtual Machine" required to run the p-code, if you natively compile the program it simply is used as a container of the resources VB programs require. The p-code executor is not used.
The knowledge base has this article which doesn't describe it very well, but kind of hints at how it works.
Untrue. VB6 compiles into native x86 executables by default. The option is there to compile to P-code (the old VB4 stuff) but that hasn't been a requirement for at least eight years and probably more. And it's not on unless you explicitly choose to use it. I have never found a reason to do so.
I used to think so, too.
Try this.
Who's your buddy now? :-)
Any user interface, regardless of language, should be usability tested at every major release. A lot of developers are horrible at adding interface widgets because they're too wrapped up in the solution rather than the problem. How often have you heard someone do something like this: "I just solved the corrupt index problem by adding a StackWalkAndRebuildAllIndexes() routine. I stuck this big ol' "WALK THE STACK" button right on the front screen so JohnsonCo. will quit calling me at 5:00 on Friday afternoons." And the product ships with a stupid WALK THE STACK button right on the front screen.
Strong design is the best cure. Failing that, rigid and annoying development processes will at least delay the implementation of the cruft, along with your valuable modifications. :-)
There's a different point of view you need to seriously consider: who's signing your paycheck? It's not Microsoft, is it? I thought not.
Consider meeting your boss in the middle. It's possible your boss is set on VB6 because he can read it fluently. Perhaps you could convince him to port it to VB.net. VB.net might not be so different that it would scare him. The GUI isn't all that different. And the .net framework would allow you to gradually expose him to other languages (C# or C++/CLI.) And it would allow you the opportunity to use a language with better libraries than VB6.
Have you dug a bit to find out why he's so pro-VB6? Maybe he's biased against .net because it's an interpreted language (like Java)? Perhaps half of his client base is all still running Windows 95 on 90 MHz pentiums, and .net is not an option for them. Maybe he'd be OK with C or C++ compiled to native executables, as long as there are no .net requirements. Microsoft's latest version of C/C++ has a strong push towards safer coding with bounds-checked versions of all the standard library functions. That might be good enough for him.
Or maybe he just has only two or three long-term clients that are stuck on Windows 3.1, but they've been with him for 25 years so he feels he has to support them into the far future. Consider buying them a few cheapo PCs to run your software: $400 each for a few bottom-feeder Dells would go a long way with customer goodwill, and would allow the rest of you to move into the 21st century of tools. And a $1200 hardware investment is much less money than your time spent struggling with old tools.
If he built a successful business around a piece of software, the chances are good he's smart enough to listen to rational arguments. So don't be irrational by kicking in your heels and saying "no! no! no!" unless you really enjoy job hunting.
If this means no more software is available to me because I won't upgrade, then I guess I won't be buying any of it. At $50 USD / video game, producers will need to think long and hard before releasing any "Vista Only" titles. (Hell, some are still releasing titles that can work on Windows 98.) Would you risk the revenue of a ten million dollar title betting on Microsoft's ability to pimp their newest OS? Are you going to be the one to explain to your boss "It only sold 200,000 copies because the guys who pirate software won't move to Vista."
OS lock-in can work both ways. Let's play this one to our advantage. Boycott Vista.
OK, so maybe they should have stuck with Black Frog. It'd probably be even better if it were followed by a parenthetical "of Doom", as in "Black Frog (of Doom)". Now that sounds more like something people should be afraid of.
They seem to have gone to great lengths to maintain TIFF compatibility, though, and I kind of wondered why this wasn't just implemented as another codec inside TIFF. (A rational explanation could be that the format is completely "little endian" which would be TIFF-incompatible.)
Anyway, nowhere in the spec does it mention DRM, and the word "rights" is only used in conjunction with Microsoft reserving their rights to the document and to the spec. This is not a DRM-encumbered format.
There's a reason the DEC guys were called Field Circus Engineers. This incident was probably high on the list.
That's where you make the same mistake as the Windows fanbois. It should not the job of the OS to mix audio streams. That's an application problem, and it deserves an application solution.
If you think it should be handled by the computer, acquire or write a userland mixer application. But don't make the mistake of calling that an OS function. The mixer can even be provided by the OS provider (in order to create a standard,) but it shouldn't be considered an OS function.
Then, if you want to mix 400, 300 or even just two audio streams, you load the mixer. If you have a low end system that can't handle audio mixing, well at least your OS isn't bloated to the point where it's dragging in extra crap that you cannot use.
The more you pack into the OS, the more of a problem the OS bloat becomes. Windows has proven that beyond any shadow of a doubt.
Heh-heh. You've never worked for a large company, have you?
Employee: "Hey, boss, this data's no good. Most people are just typing a-s-d-f for their names and addresses and registering fake info!"
Manager: "Yeah, but it's really important that we find out what they think of our site. Let's get them to take a customer survey after registering."
Employee: "???"
Oh, I know it doesn't. For example, I know our Exchange server doesn't put any headers on my email differentiating mail originating on an inside SMTP port vs what comes from the outside (unless you look closely at the Received chain.) It's just that in "most" cases, it really is spam.
Sure, the ci-al'is messages are "classic" spam, but a lot of the mailing list crap is just as spammy. I don't spend a lot of time distingsuishing between the various sources of advertising. And as far as I'm concerned, I'm "right". A message containing an unreadable buttload of advertising text is spam, whether asked-for or not.
One final complaint, and that's about outlook/exchange: why the hell doesn't it treat "internally" sourced messages differently than "external"? If I worked at X-Corp, and got an exchange message from another X-Corp employee, why are the filters even looking at these messages (other than to build up a "valid email corpus"?) If a message from randomname@x-corp.com came in through the external SMTP gateway, sure, it's probably forged and/or spam. As a matter of fact, it's one of the most obvious indicators of spam -- so why doesn't Exchange understand this and take advantage of this?
Never attribute to bad hardware that which can be adequately explained by buggy software. - Motorola RAZR
I used to think this too, which is why I used to use the TabX extension. However, since at least Firefox 1.5 I've been able to "middle-click" a tab to close it (without giving it focus.) Once I learned that, TabX was gone.
The Microsoft rep says "hey, we have to support language extensions for row locking this way, because that's how our engine works." Oracle says "Well, let's just agree to call row locking an 'extension' but not define it because we do it differently." The DB2 guy says "Everybody needs to be able to DROP TABLE, so that should be in the standard."
Even representatives from the various users' groups have biases towards their preferred languages. And while it might be in the best interests of DBAs everywhere to have a completely common language, it's not going to happen because the Oracle users' group is going to have a different opinion of what's right than the MS SQL users' group.
The point is they all want the language to go exactly their way for patent reasons, for ease-of-maintenance reasons, and for the ability to cripple their competitors who are unable to comply. And for the most part, these special little provisions find their way into the standard, mostly because all the vendors benefit from the vendor lock-in resulting from the fractures.
It's not fair to say "don't blame ANSI" because the process producing these so-called standards really is to blame. Nobody from ANSI ensures that the meetings are attended by user groups, or that the users themselves have more or less voting authority than the manufacturers. If ANSI really cared about standardization, they'd say "no extensions." But that doesn't serve us well either, as there'd be no room for progress in the language.
"That's no moon!"
But try telling that to kids these days, and they just won't believe you.
Yes, I am older than dirt.
Does the blinking amber light on a LifeDrive count? :-)
OK, I'll quit now.
Happy Birthday, Rob! From someone far older than you!