|
It’s About Trust!
"The List"
Language Spec
Deprecation
Exec Bios
Google VFred
Classic VB
|
|
UniMess Uncovered
The following thread is taken from the VB4 beta forum on CompuServe, and demonstrates the beginning of the current problem. A
fundamental datatype, String in this case, was redefined. The uproar was tremendous. After much wrangling, Microsoft, personified
by Drew Fletcher, told "us" in a pre-VB5 alpha get together that they "got it" and wouldn't pull this sort of
stunt again.
Fool me once, shame on you. Fool me twice, shame on me!
.NET: It's About Trust!
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Tuesday, January 31, 1995 10:36:01 PM
From: Dan Barclay, 72560,2354 #15852
Chris,
AAAAGGGGGHHHHH!!!!!!
You've been very polite and helpful here, so pardon that I've addressed this flame to you. Please pass it along to wherever it belongs. I'm mad as hell. I'm not even sure I can explain how I feel. Frustrated, crushed, tired of complaining to people who don't care and don't "get it".
I'm new to the beta, relative to others here, having arrived just before you. Some of the things I'm just discovering may be old news but I've just run across another issue that I consider a FUNDAMENTAL departure from the Basic language that's been defined over the years.
THE DEFINITION OF THE BASIC "STRING" DATATYPE HAS BEEN CHANGED WITH VB4!!!!
This is totally unacceptable as far as I'm concerned. I don't understand the reason behind this... I can't even *imagine* a good one. Basic Strings have been used to contain binary data, one byte per character, since Day1.
This definition was retained with the 8bit to 16bit transition and should be retained with the 16 to 32bit transition. The only thing that has changed, with regard to the programmer, is that the length was extended from 8 bits to 16bits. Frankly that's *exactly* what I would expect with this transition... the length should be extended from 16bits to 32bits. NOTHING ELSE!!!
Now I see statements like:
"Note: When passing binary data toa DLL procedure, pass a variable as an array of the Byte data type, instead of a String variable. Strings are assumed to contain characters, and binary data may not be properly read in external procedures if passed as a String Variable"
If you wanted to add a new "character" datatype, or "character string" data type you should have done so. The Basic String was one of the PRIMARY STRENGTHS of the language!!! In fact, the lack of native variable length, dynamic, binary strings was what cooled me off to the notion of Delphi for my own work. Frankly, using Delphi class with OLE BSTRs might take care of it for me better than the new Basic String.
I use arrays of strings containing binary data, and a lot of others do also.
Simply put, VB4 IS NOT USABLE for my applications if this is the new "definition" of String.
You can ignore this if you wish, but I've been doing Basic programming and hanging out with Basic programmers since the late 70's. I don't know who the heck has changed this definition, but they don't understand the Basic language!
You're going to catch hell with this when people realize what's happened. The "new definition" apparently doesn't really change program results with 8bit code. My personal testing has not shown corrupted data, but the definition says it will when I start on 32bits (this week I had hoped). It sounds like I can just put that on hold. When people start complaining that their 32bit apps are blowing up it'll be my pleasure to explain why.
You know, even if the data weren't corrupted, I can't imagine what a performance hit there must be when I pass moderate or large arrays of strings to DLL's and OLE objects and they have to be converted and deconverted from UNICODE to ANSI.
I'd really like to see some of the OLE tools VB4 brings to the table, but right now I really don't think very much of VB4. This is really sad.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Wednesday, February 01, 1995 1:50:16 AM
From: Zane Thomas, 72060,3327 #15859
Dan,
There's no doubt that the changing definition of 'string' in Windows (and VB) is going to cause a *lot* of trouble. Perhaps an Option AnsiStrings could be used to get around the problem while programs port, get maintenance, and go obsolete.
Given the convenience of a$ = b$ there are a lot of cases where I'll put just about anything in a string.
Unfortunatly this doesn't work:
Option Explicit
Private Sub Form_Load()
Dim a() As Byte
Dim b(1000) As Byte
a = b <--- Woops can't assign to array, what's a mother to do?
End Sub
If MS is going to change the defition of VB strings they ought to compensate by allowing array assignment. Then MID,LEFT, and most of the usual suspects should be modified so they work with arrays OR strings.
Would that get you from here to there?
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Wednesday, February 01, 1995 10:59:26 AM
From: michiel de bruijn, 100021,1061 #15887
Hi Zane!
>> If MS is going to change the defition of VB strings they ought to compensate by allowing array assignment. Then MID,LEFT, and most of the usual suspects should be modified so they work with arrays OR strings. <<
The easiest way out would IMHO be to make string translation on calls optional. This could be by allowing an Option statement, like you suggested, or by introducing a cousin to 'ByVal' that indicates the string should/should not be touched.
//mdb
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: michiel de bruijn, 100021,1061 Wednesday, February 01, 1995 11:20:30 AM
From: Zane Thomas, 72060,3327 #15894
Michiel,
Yep, sure looks like they're going to have to do *something*.
Looks, like it's time for A Call to Arms II !!!
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Wednesday, February 01, 1995 12:38:11 PM
From: michiel de bruijn, 100021,1061 #15900
Hi Zane!
>> Looks, like it's time for A Call to Arms II !!! <<
Let's rename the current petition to 'People Who Want the Cruelty to Variables to STOP'
...<g> But seriously, the ANSI vs. Unicode stuff, the implicit type conversions and the unwanted string modifications start to paint a picture that's not exactly pretty. Let's hope 'someone' has some answers Real Soon Now.
//mdb
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Wednesday, February 01, 1995 4:48:05 PM
From: Chris Dias [MSFT], 74441,137 #15943
Zane!
>>>Looks, like it's time for A Call to Arms II !!!
<<<
Not another one, please.... I spend all day closing "yup - me too" and "I'm
in" messages <g>.
Chris
- Microsoft Developer Support
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Wednesday, February 01, 1995 5:00:28 PM
From: Zane Thomas, 72060,3327 #15945
Chris,
<<<
Not another one, please.... I spend all day closing "yup - me too" and "I'm in" messages <g>.
>>>
Well ... if we got a speedy "Woops ... yes we can see how that's a problem, let's see if there's anything we can do about it." then we wouldn't feel the need to resort to peasant-uprising tactics!
Zane (Never speechless, but no Thomas Paine)
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Wednesday, February 01, 1995 10:12:30 PM
From: Dan Barclay, 72560,2354 #15966
Zan(ie) <g>
>>Well ... if we got a speedy "Woops ... yes we can see how that's a problem, let's see if there's anything we can do about it." then we wouldn't feel the need to resort to peasant-uprising tactics!<<
Woahhhh... what a revolutionary idea!!!
Apparently it hasn't crossed anyone's mind in the Great Northwest. Of course, none of us could possibly have a clue what's important and what's not. Nevermind the fact that we've been doing Basic since "before Basic was cool" and making a damn good living at it.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Wednesday, February 01, 1995 10:47:24 PM
From: Zane Thomas, 72060,3327 #15969
Dan,
<<<
Woahhhh... what a revolutionary idea!!!
Apparently it hasn't crossed anyone's mind in the Great Northwest.
>>>
Hey, Karl and I live in the Great Northwest and it crossed our minds. But then we live in the part of the Great Northwest that intersects with reality! :-)
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Thursday, February 02, 1995 12:17:22 AM
From: Dan Barclay, 72560,2354 #15975
Zane
>>Hey, Karl and I live in the Great Northwest<<
Well, fortunately it doesn't show <g>.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Thursday, February 02, 1995 8:43:02 AM
From: michiel de bruijn, 100021,1061 #15985
Hi Chris!
>> Not another one, please.... I spend all day closing "yup - me too" and "I'm in" messages <g>. <<
You should be glad you're not in MSBASI. Over there you get flooded in "please also send *me* a free copy of your magazine" messages. At least the me-toos you see here have some relevancy...<g>
//mdb
- michiel de bruijn a.k.a. 100021,1061 @ 02-Feb-1995, 16:39:26 +0100
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Wednesday, February 01, 1995 11:05:07 AM
From: Karl Peterson, 72302,3707 #15892
Hi Zane --
>>If MS is going to change the defition of VB strings they ought to compensate by allowing array assignment. Then MID,LEFT, and most of the usual suspects should be modified so they work with arrays OR strings.<<
That's the whole problem! We got a new paradigm, but the old tools were simply tossed by the wayside. There's just no convenient way to work with binary data anymore. Really a bummer.
Later... Karl
PS -- I'd "vote" for Option Ansi!!!
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Karl Peterson, 72302,3707 Wednesday, February 01, 1995 11:20:00 AM
From: Zane Thomas, 72060,3327 #15895
Karl,
It looks like the VB4 language designers haven't actually had to write a lot of (any?) significant programs using VB or they'd realize what some of the problems are.
I would suggest as an exercise that they write a VB4 compiler/interpreter in VB! That would provide some valuable insight into what's required, and would help them focus on performance problems too!
I've always had this same sort of gripe about people who design cars. Noone should be allowed anywhere near a drawing board until they've spent six months fixing cars! Then it wouldn't take 2 hours and 3 special tools to change a starter-motor.
Zane
PS. The VW Rabbit had the best starter-motor position I've ever seen, and the easiest replacement. Right up front, one socket wrench. I took one out in the parking lot of a parts store, got the replacement, and put it in in about 10 minutes once!
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Wednesday, February 01, 1995 4:39:13 PM
From: Karl Peterson, 72302,3707 #15935
Hi Zane --
>>It looks like the VB4 language designers haven't actually had to write a lot of (any?) significant programs using VB or they'd realize what some of the problems are.<<
Sometimes I get the feeling that the designers are just that. That they've never programmed in *anything*, and simply draw "pictures".
>>I would suggest as an exercise that they write a VB4 compiler/interpreter in VB!<<
<ROFLMAO>
Later... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Karl Peterson, 72302,3707 Wednesday, February 01, 1995 5:12:14 PM
From: Zane Thomas, 72060,3327 #15947
Karl,
<<<
Sometimes I get the feeling that the designers are just that.
>>>
I had the pleasure of working as a consultant at MS a few years ago. They have the highest percentage of excellent programmers/designers that I've ever seen anywhere.
Unfortunately along with this comes a "We're the greatest, and we can do no wrong" sort of attitude.
Everybody makes mistakes, they made a mistake this time, and they should fix it.
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Wednesday, February 01, 1995 5:36:21 PM
From: Karl Peterson, 72302,3707 #15954
Hi Zane --
>>I had the pleasure of working as a consultant at MS a few years ago. They have the highest percentage of excellent programmers/designers that I've ever seen anywhere.<<
For all the flaming, I'm still sure you're right.
>>Unfortunately along with this comes a "We're the greatest, and we can do no wrong" sort of attitude.<<
Ugly, no matter where it is! (Yes, even when *I* exhibit it. <g>)
>>Everybody makes mistakes, they made a mistake this time, and they should fix it.<<
Yep! (Sorry, Chris <bg>)
Later... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Wednesday, February 01, 1995 10:12:02 PM
From: Dan Barclay, 72560,2354 #15967
Zane,
>>I had the pleasure of working as a consultant at MS a few years ago. They have the highest percentage of excellent programmers/designers that I've ever seen anywhere.<<
I've never worked there, but I have had the pleasure of visiting with several of them... some of the Basic developers (preVB) to boot. Great guys and super sharp. More recently I've met with others and have the same reaction to them.
One problem, it seems, is that there are also a lot of "evangelist" or "cheerleader" types that *think* they understand things. They're sharp but they just don't have enough experience to know what's been shown (over and over and over) to be important. They have far more influence than they should on product development. Some have had little experience with Basic and only a couple of years with MS.
Another problem is that it seems that you can take these great, extremely sharp guys and put them together in a room in Redmond. All of a sudden they begin to act like Dumb and Dumber. Kind of a "group" effect I suppose. I used to work for a (very) large chemical company and I've seen Design By Committee at it's "best" but nothing like this. I don't understand it but...
Well, reading this over it sounds like I may belittling the developers. I don't mean to. I'm just trying to understand how the heck we got here and nothing seems to fit. They guys I've met are too smart for this craziness.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Wednesday, February 01, 1995 10:47:27 PM
From: Zane Thomas, 72060,3327 #15970
Dan,
I know your remarks weren't intended to belittle, and I hope no one takes them that way. It's difficult to say *exactly* what you mean in e-mail, but I think you and I are groking this thing in about the same way.
It's true that MS has some really, really sharp people. And it's also true that some of them are not very experienced. What I remember was that the less-experienced, bright programmers *usually* had someone with many years experience watching over them. This is as it should be, IMHO.
But even the best and the brightest can head off in the wrong direction. I saw this happen in the languages group before the first c++ was released, I probably can't get very specific because I'm sure I signed something that would condemn me to hell if I did.
Anyway, it's tough to admit a mistake, and especially tough when you're used to being right all the time. And, when a judgement-call is involved and you *know* you're right it's hard to give in to your customers. But sometimes it has to be done. This is one of those times MS!
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Wednesday, February 01, 1995 11:09:06 PM
From: John Craig, 71330,1520 #15972
>> I had the pleasure of working as a consultant at MS a few years ago. They have the highest percentage of excellent programmers/designers that I've ever seen anywhere. <<
I get the feeling the problems are not with these folks, but more with the marketing types and product managers. I'd guess VB was put under the wings of some people with vested interest in Office products, and VB as a product is suffering because of it.
Zane,
Disclaimer: This is not a flame, just my opinion...
>> I had the pleasure of working as a consultant at MS a few years ago. >> Great programers / unfortunately along with this comes a "we're the >> greatest, and we can do no wrong" sort of attitude.
As a current contractor, (and contractor for the last year or so), I have never noticed this attitude from anyone that I have worked with. This includes many developers/programmers and program/product managers in several groups. I have only dealt with hard working and intelligent people who strive *and* commit to make the best product possible. I actually have found the lack of attitudes from the people I have dealt with as a refreshing change. . I have had much more problems with contracts outside of Microsoft (attitudes of management, etc.) One thing I have noticed, and this is about all the product groups I have done contracting for, is the they really do listen. They listen to their contractor, and they listen to their beta testers. Don't for a moment think that one thing that has been said by a beta tester has not gone in front of management.
Just my two cents worth ;-)
Sam
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Sam Patterson/Gold Leaf , 72000,1751Thursday, February 02, 1995 9:04:31 AM
From: Zane Thomas, 72060,3327 #15990
Sam,
No flame taken!
Seriously I think it's a mistake to discuss the people instead of the issues. So ... I'm getting back to basics <g>:
VB4 needs either:
1. Option Ansi --- with conversion functions like CUni(str); or
2. A major change in the use of arrays ie. array assignment.
The second choice would work for new code, but it leaves hundereds of thousands (millions) of lines of code hanging because of conversion problems. I don't think Dan would like this. <g>
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Thursday, February 02, 1995 11:29:28 AM
From: Dan Barclay, 72560,2354 #16013
Zane,
>>I don't think Dan would like this. <g><<
Right, but that's not the real point <g>.
MS wants VB to become the new "corporate choice" for systems development... even if it's at a glue level apparently. At the same time they don't seem to hesitate to change code behavior in *major* ways.
VB will be sumarily tossed aside if MIS directors detect there is a lack of continuity in the product. They are looking for a "New Legacy" platform to replace their "Old Legacy" stuff. If they think they're going to have to redo what the codeded this year every couple of years because someone "redefined strings" or some other aspect VB doesn't have a chance in that market.
How long will it be before some clever dude decides truth is really -1 instead of nonzero? After all, the constant True=-1, no? What does it matter that the definition has been otherwise since CP/M versions of MS Basic.
I work with large companies (banks and data processors for banks). If I explain to them that redefinition of these things has even been considered they're going to laugh their asses off. Can you imagine the reaction they would have to redifinition of some fundamental behavior of COBOL?? Most of the programmers would go off and recode everything. Their bosses (who hafta pay for it out of their budgets) are going to be really pissed.
If VB is released with fundamental redefinitions I'm going to explain it to them as clearly as I know how. The time to stop this foolishness is NOW. If "the powers that be" don't think this issue is important they can take their chances and release it.
Again, when a new feature or capability must be added just add it. Don't change some existing feature in an attempt to fit it.
What's next??
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Thursday, February 02, 1995 1:04:22 PM
From: Zane Thomas, 72060,3327 #16022
Dan,
You've presented a powerful argument, I hope Chris is listening. This goes way beyond specific 'code samples', this is about language design and maintenance.
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Friday, February 03, 1995 8:23:16 PM
From: Donald English, 73404,264 #16170
<<MS wants VB to become the new "corporate choice" for systems development>>
Ain't gonna happen! I have been putting off learning PowerBuilder as long as I can, but you have to admit one thing. It can sure talk to SQL Server better than VB. If only MS would:
1) Make VB a REAL language and not a toy
2) Provide EZ database access for SQL Server as they do for Access, dBase, Paradox, etc. (ODBC doesn't cut it!)
this might happen.
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Friday, February 03, 1995 11:44:12 PM
From: Pete Roberts, 76060,2006 #16180
Zane -
>> ... VB4 strings have changed ...<<
The problem we're seeing has very little to do with Basic, programming, or any other specific topic. The problem, as we all know, is an example of a general type of error made by people who have no concept of systems or correct design rules. Specifically, when augmenting a system new features must be _added_ to existing features, not _replace_ them.
Unfortunately, in this glorious new age we live in, it its every person's right to claim that they are an expert in whatever field they want. And, if you are a manager or work in marketing/sales/finance, well then, you know everything there is to know, even before you know that you know it.
All these new goodies in VB4 are great, but the fact that so many of the existing features of VB1/2/3 are broke "by design", makes me realize that we have a totally new product on our hands. If we start to think about it as "VNB4" (Visual New Basic 4), and not as an upgrade to VB3, we'll all be a lot happier.
If a programmer wants the standard Basic features, use VB3. If the new features are wanted, use VNB4, and realize that lots of the code of existing applications will have to be re-written.
Let's face it - this is not an upgrade, but a totally new product.
Pete
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Pete Roberts, 76060,2006 Saturday, February 04, 1995 3:52:00 AM
From: Zane Thomas, 72060,3327 #16184
Pete,
<<<
If we start to think about it as "VNB4" (Visual New Basic 4), and not as an upgrade to VB3, we'll all be a lot happier.
>>>
No we won't!!!
You make an interesting point though.
However still remaining, even starting fresh with a 'new language', are the problems with automorphic type conversions and the total lack of any reasonable way to deal with chunks of binary data.
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Saturday, February 04, 1995 6:37:22 AM
From: Charles Gallo, 74020,3224 #16189
Zane,
Besides, If I want to learn a new lang, there is always Pascal
Charlie
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Charles Gallo, 74020,3224 Saturday, February 04, 1995 10:44:26 AM
From: Zane Thomas, 72060,3327 #16192
Charles,
<<<
Besides, If I want to learn a new lang, there is always Pascal
>>>
I hear you talkin!
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Pete Roberts, 76060,2006 Saturday, February 04, 1995 6:38:17 PM
From: Dan Barclay, 72560,2354 #16206
Pete,
>>If we start to think about it as "VNB4" (Visual New Basic 4), and not as an upgrade to VB3, we'll all be a lot happier.<<
1. Absolutely. It's not an upgrade to VB3, but I prefer to call it V?4 because without real binary strings it simply ain't Basic as far as I'm concerned.
2. Nope, I won't be a lot happer with VB3 because it'll be as dead as VBDOS.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Wednesday, February 01, 1995 11:41:21 AM
From: Dan Barclay, 72560,2354 #15898
Zane,
>>Would that get you from here to there?<<
No, not even close. I have somewhere between 50,000 and 75,000 lines of Basic code (I haven't run them thru a counter lately) I share between environments. That code is *full* of strings and *arrays* of strings, many of which need to manage binary data.
Even if I weren't sharing the code with another environment and were more free to do a "one time conversion", my standard for string naming includes the "$" suffix. Can you imagine the task???
If they have as little regard for the language definition as this, and data typing, and performance, etc... why the hell would I convert that much code to VB4. VB4 is "another language" IMHO and if I'm going to do a conversion I'll carefully consider what language I convert to.
I'm not looking for a kludge or workaround. I want the damn thing to work the way it's supposed to. If they wanted a new native data type they should have added it.
So far as I'm concerned, the 32bit version of VB (where this new string definition seems to kick in) is *not* Basic. I feel *very* strongly about this and if it's released this way I intend to say so with the strongest of conviction. I've put off a couple of invitations to write "opinion" articles for mags because I didn't want to take the time but enough is enough. What's worse is the question "what's next???"!!
If someone wants to start a new "signup list" I'll gladly be the first one on it. Who knows, maybe I'm the only one but I do think this is a crock.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Wednesday, February 01, 1995 12:54:01 PM
From: Zane Thomas, 72060,3327 #15901
Dan,
I see where you're coming from, MS has clearly not done you a favor.
How would the Option Ansi idea work for you?
How about Option VB4 Strings NOT!
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Wednesday, February 01, 1995 11:05:13 AM
From: Karl Peterson, 72302,3707 #15893
Hi Dan --
>>I'd really like to see some of the OLE tools VB4 brings to the table, but right now I really don't think very much of VB4. This is really sad.<<
Welcome to Win32. It's gonna be one of the harshest transitions ever, I think. I really tend to fall into agreement with the above from time-to-time. And, indeed it makes me very sad too.
Zane nailed it. MS simply forgot to provide the same tools for handling binary data as were previously available. Hell, I've yet to see a decent way to grab a 32K buffer from a file! It's really ridiculous. What're ya gonna do? Read *one* byte at a time??? Nope, definitely not cool.
Meanwhile, check out threads with names such as "Unicode<->ANSI headaches", etc. I wish I could say differently, but it only gets worse the more you consider it. Yep, very, very sad indeed.
Later... Karl
============================
Hi Chris (I know you're following this <g>) --
>>You've been very polite and helpful here, so pardon that I've addressed this flame to you.<<
My feelings exactly! Just wanted you to know.
Later... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Thursday, February 02, 1995 11:48:07 AM
From: GREGG IRWIN, 72450,676 #16019
Dan,
<AAAAGGGGGHHHHH!!!!!!>
My sentiments exactly.
--Gregg (will work for workarounds)
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Thursday, February 02, 1995 1:12:06 PM
From: Chris Dias [MSFT], 74441,137 #16023
Hi Dan -
>>>THE DEFINITION OF THE BASIC "STRING" DATATYPE HAS BEEN CHANGED WITH
VB4!!!!
<<<
BStrs or the fact that everything is UNICODE internally? There is nothing
magic about BSTrs - still pointers to strings. UNICODE is a different story.
Why UNICODE you ask? Well, if you want to write 32bit applications you use
UNICODE. OLE is UNICODE so in order for us to work well with OLE then we
need to be UNICODE internally. NT is UNICODE internally and while Win95 is
not all UNICODE, I imagine that a later release will become that way.
Now, as far as passing strings to DLLs - you can pass either ANSI or UNICODE
strings. VB will automatically convert its internal UNICODE strings to ANSI
strings and then back when calling DLLs. This is why you call the ANSI
version of the functions.
If you want to call DLLs with UNICODE strings you set up a typelib and
declare the parameter as a BStr. A UNICODE string is passed.
If you are calling a DLL to get binary data then, yes, use a byte array.
What are you doing with the binary data in your program? I see where there
is a problem converting your code to 32bit and byte arrays since you have the
"$" reference everywhere. I was once burned by that with an upgrade to
spread20.vbx and all the rows/columns were changed from integers to longs.
>>>This is totally unacceptable as far as I'm concerned. I don't understand
the reason behind this... I can't even *imagine* a good one. Basic Strings
have been used to contain binary data, one byte per character, since Day1.
<<<
This was *not* dictated by us. Its a result of the operating systems and the
interaction with other components, namely OLE. When VB4 first went to beta
we were not UNICODE and we did not have the byte array. We were forced to go
in this direction and this was the result.
>>>This definition was retained with the 8bit to 16bit transition and should
be retained with the 16 to 32bit transition. The only thing that has
changed, with regard to the programmer, is that the length was extended from
8 bits to 16bits. Frankly that's *exactly* what I would expect with this
transition... the length should be extended from 16bits to 32bits. NOTHING
ELSE!!!
<<<
Not with strings though. In order to have DBCS everyone needs to move to a
globally accepted standard - UNICODE (capital letters not for emphasis, just
for the name).
>>>If you wanted to add a new "character" datatype, or "character string"
data type you should have done so.
<<<
A UNICODE character is two bytes. This allows VB and all the other
applications to work globally, not just in English. What you are suggesting
is a single byte data type which is what we added.
>>>...Frankly, using Delphi class with OLE BSTRs might take care of it for
me better than the new Basic String.
<<<
I don't understand this one...we are BStrs.
Comments, flames welcome as always.
Chris
- Microsoft Developer Support
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Thursday, February 02, 1995 3:04:25 PM
From: Sunil Shah, 71051,3315 #16034
Chris:
It looks like some of them took a little longer to get burned by
UNICODE/ANSI problem than I did. I can see lots of Tech Support calls
on the horizon after 32-BIT VB4 ships. Like C/C++ UDT packing must be
user controlled and String Type should be user selectable (ANSI/UNICODE).
I think this is lot more imortant than the 'other' major problem lot of
people are excited about.
You know, there is a money making oppertunity in all these for MS.
1. Don't fix any of there problems now.
2. Make Tech Support a 900 number.
3. Make lots of money on UNICODE/ANSI and Type Mismatch problem calls.
4. Fix them in Version 5 of VB and show the world that MS cares.
Sunil.
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Sunil Shah, 71051,3315 Friday, February 03, 1995 11:08:15 AM
From: Dan Barclay, 72560,2354 #16134
Sunil,
>> It looks like some of them took a little longer to get burned by UNICODE/ANSI problem than I did. I can see lots of Tech Support calls on the horizon after 32-BIT VB4 ships. Like C/C++ UDT packing must be user controlled and String Type should be user selectable (ANSI/UNICODE). I think this is lot more imortant than the 'other' major problem lot of people are excited about.<<
Actually I haven't been bit yet. I just read the docs and saw that I was going to be hosed. I don't think they get the point.
I've been complaining about the generic problem of binary data in strings, but the UDT packing issue will be a serious problem for me also.
Do you think they understand how many serious VB users are now looking for relief elsewhere?? Most of the people I know wouldn't spend their time even looking if they felt comfortable with where VB was going.
This is incredible.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Friday, February 03, 1995 1:56:13 PM
From: Sunil Shah, 71051,3315 #16143
Dan:
There is an easy way out. Just don't use 32-BIT VB4. I don't think 32-BIT
VB4 is any faster than 16-BIT VB4 both running under WinNT or Win95.
Sunil.
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Sunil Shah, 71051,3315 Friday, February 03, 1995 2:48:08 PM
From: michiel de bruijn, 100021,1061 #16150
Hi Sunil!
>> There is an easy way out. Just don't use 32-BIT VB4. I don't think 32-BIT
VB4 is any faster than 16-BIT VB4 both running under WinNT or Win95. <<
Might work. The only snag is that 16-bit apps won't be eligible for the Windows Logo program. I just *love* corporate politics...
//mdb
- michiel de bruijn a.k.a. 100021,1061 @ 03-Feb-1995, 23:40:52 +0100
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Sunil Shah, 71051,3315 Friday, February 03, 1995 4:34:08 PM
From: Dan Barclay, 72560,2354 #16159
Sunil,
As Michiel pointed out, 32bitness is as much political as anything. In addition, a couple of the plans I had for my application included unattended server-type apps (more than one) running on a machine.
It would be nice to have them a little more isolated from each other and from a potential user than the 16bit OS's would give me. To tell you the truth, I'm still waiting on my NT disks so I don't have it up yet. Since finding how incompatible V?4 is going to be I've put it at pretty low priority for now.
As far as I'm concerned, 32bit V?4 can be sent back to the SpecShop. You've been on enough betas to know it's not likely they'll change *anything* featurewise once it's in beta... which means that, if we're lucky, they'll scrap the 32bit release and redo it. Something tells me, though, that they'll forge ahead and have it blow up in their faces. It should be interesting, but I doubt you'll find any of my code released with it. This is a "showstopper" problem.
The most change I've seen at betatime was when they changed the list of controls they included with Rawhide... no change in the controls themselves, just reboxed them.
Which brings the question... why didn't they seek broader input at spectime? I can't imagine they discussed this binary string issue with a serious programmer and it didn't come up... unless they just didn't say anything about it. The answer is so obvious I wouldn't have even thought to *ask* about it!
Now the question is: If I can't go 32bit V?4 and we're not going to have a compiler, should I spend my time redesigning my app to use OLE in 16bit VB4 or look elsewhere? I'm good at questions, but I don't have the answer yet; <oops; my finger slipped on the key>;
Later; Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Saturday, February 04, 1995 11:08:16 PM
From: Jonathan Wood, 72134,263 #16215
Hi Dan:
>>As far as I'm concerned, 32bit V?4 can be sent back to the SpecShop.<<
As always Dan, don't hold back. Tell them what you really feel.<g>
I'm curious. Were there other concerns you have with VB/Win32 beyond the new string type?
Jonathan Wood
SoftCircuits
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Jonathan Wood, 72134,263 Sunday, February 05, 1995 12:10:05 AM
From: Karl Peterson, 72302,3707 #16227
Hi Jonathan --
>>I'm curious. Were there other concerns you have with VB/Win32 beyond the new string type?<<
Let's start a list! <g>
* No thread support.
* There's no way to do binary "stuff".
* No support for NT controls (textboxes>32K).
* Purely Unicode-based, while Win9x is ANSI-based -- wonder what the next explosion will be when folks actually start running in Win9x??? <bg>
* While Unicode-based, no (native) way to call Unicode API functions.
* The above means a(nother) performance penalty due to every string being converted twice when calling and returning from APIs.
* Oh, yeah, no compiler. <g>
The above are purely (well, except the last) 32-bit concerns. I left out more general concerns that affect both the 16- and 32-bit versions (since that list could go on for quite some length). Looks like we've just about got a top ten list there. Who'd like to add a few more?
Later... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Jonathan Wood, 72134,263 Sunday, February 05, 1995 5:08:14 PM
From: Dan Barclay, 72560,2354 #16263
Jonathan,
Yes I have more concerns about VB4. In fact, my primary concern as been performance, code size, the inability to build a statically linked (standalone) EXE, native compilation... the list is long and contains important (missing) features and capabilities.
However, this issue of changing core language specs is a real showstopper. The others are irrelevant if I can't use it. Beyond that is the approach MS is taking with VB, and the resultant (mis)direction.
Query: Is it a glue language??? Yes, we say. Do we really believe most "office gluers" are going to create automation objects? Creating and maintaining OLE automation objects is something you really need to have a serious developer involved in...
So, they must intend it to be for fairly serious developers. Yea, that's it. Now, where is the compiler... how do I link multilanguage code? I can call DLL's, but the DLL can't call a function I wrote in V?.
I like a *lot* of things I see in V?4 and I'd really like to use them. However, breaking the core language and ignoring the need for a real optimized compiler is something I just can't go along with for something that's supposed to be a serious development environment.
Also, you asked specifically about 32bits. FWIW, I don't yet have the 32bit version up and running so I can't say about "hands on". My beef with the 32bit version is that the definition of strings has changed and the definition kicks in with 32bits. It's actually redefined for 16bits also, but it seems to behave the same as VB3 (by accident?) from my tests.
I want a VB4 that will let me kick some butt. This one won't even let me run.
Dan
PS: It's been nice knowing ya. I have it on good authority that raising hell about issues like lack of a compiler resulted in a "if you don't like it here just leave the beta" response from The Powers some months back. I may disappear any (#$mmfff)&#*...
<<\\disconnected...//??>>
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Monday, February 06, 1995 12:43:31 PM
From: Jonathan Wood, 72134,263 #16335
Hi Dan:
>>PS: It's been nice knowing ya. I have it on good authority that raising hell about issues like lack of a compiler resulted in a "if you don't like it here just leave the beta" response from The Powers some months back.<<
Well, that's never stopped you before.<g> But remember, there's always VC++ or Delphi. Whoops! Did I just say something sacrilegious?
Jonathan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Saturday, February 04, 1995 11:28:04 PM
From: Karl Peterson, 72302,3707 #16220
Hi Dan --
>>I can't imagine they discussed this binary string issue with a serious programmer and it didn't come up... unless they just didn't say anything about it. The answer is so obvious I wouldn't have even thought to *ask* about it!<<
Yep, the first night I got the manuals, I stumbled upon this. Gregg and I talked about it back and forth for a couple months, but never came to any good conclusions. Don't know why we didn't fly the issue earlier, except maybe it was because the marketing beta was/is a *total* joke (which is where we were both dumped initially, and where they probably wish we still were! <bg>).
Later... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Thursday, February 02, 1995 3:40:22 PM
From: Dan Barclay, 72560,2354 #16039
Chris,
>>Well, if you want to write 32bit applications you use UNICODE.<<
So, the 32bit apps we will first see on Win95 aren't really 32bit apps? I realize it's desirable and a direction you'd like us to go but clearly it's not a *requirement*.
>>I was once burned by that with an upgrade to spread20.vbx and all the rows/columns were changed from integers to longs.<<
If you think you can relate your "inconvenience" with a change like that in spread20.VBX to a change in a language like Basic. Think for a minute about the number of users who'll be affected in the two cases. Also consider the fact that a number of the users WON'T REALIZE THEY'RE GOING TO BE AFFECTED UNTIL THEY NOTICE THEIR DATABASES ARE CORRUPT.
Basic strings consist of a single binary byte per character. That is, and has been, the definition of a Basic String data type. Period. I've been using MS Basic since CP/M and TRSDOS (read: 8bit versions). That basic data type doesn't know about and cannot contain UNICODE.
Not only has it been that way all this time, examples in MS documentation support this usage. I refer you to examples of reading files AS BINARY or RANDOM in any MS Basic manual. In addition, all documentation I've seen anywhere on MS Basic regarding usage of strings to pass data outside the language (to external subs, TSR's, etc) support the fact that the string is untouched between the external code and Basic code. If I choose to pass a large string to a DLL (say, a Btrieve DLL or module) it fills the string with binary data. Now I can concant, separate, rearrange the string all I want and pass it back to the DLL to write and it is saved uncorrupted. I handle a huge amount of binary string data from for BLOB databases, encrypted scripts and expression evaluators. From what I read, this code will break.
It doesn't matter to me (or to Basic) one whit that NT uses UNICODE internally. I don't care if it uses Sweedish internally. Since it uses UNICODE internally does that mean you'll be keeping Doubles as UNICODE??? How about Integers???
I'm programming in Basic. By definition I shouldn't care what's under it.
>>This was *not* dictated by us. Its a result of the operating systems and the interaction with other components, namely OLE. When VB4 first went to beta we were not UNICODE and we did not have the byte array. We were forced to go in this direction and this was the result.<<
BULL!! MS controls the action of this language. Again, if you need a CharacterString data type *that's* what you should have created. You have *TOTAL CONTROL* over this. Someone made the wrong decision on this. It's that simple. You were not FORCED to do anything to Basic Strings.
>>Not with strings though. In order to have DBCS everyone needs to move to a globally accepted standard - UNICODE (capital letters not for emphasis, just for the name).<<
Yes, with strings. Strings are, and have been forever, 1 byte per character. UNICODE is a new feature and, as such, will require some transition for those (few) who need to use it. I think it would be a good idea to provide them with a method to do so, but not at the expense of breaking everyone else's code. I'd like to have the ability to take advantage of UNICODE in the event that I someday need it and I support the concept of the *added feature*.
>>A UNICODE character is two bytes. This allows VB and all the other applications to work globally, not just in English. What you are suggesting is a single byte data type which is what we added.<<
ABSOLUTELY NOT!!! What I am suggesting is a double byte data type which is what you *should* have added!
I do not (yet) understand all the "under the hood" goings on with VB4, especially on NT but I will eventually. Whether BSTR's can only be used for UNICODE under NT I don't understand clearly. On the surface it seems to me that a BSTR can contain any binary data you wish to put in it... only the recipient applications care what that data is. It sure looks to me like it could be UNICODE or anything else and that the usage context determines what counts. However, I *do* understand what the reaction to this coersion of a fundamental data type will be in the marketplace. I hope your marketing people begin to understand it real soon.
You should be aware that I'm not just flaming on this issue because of general lack of caring by MS. This is a serious issue and I don't intend to back off on it.
What's next?? I've brought this up in another message, but how long will it be before you redefine truth? Do NT functions use something other than 0=flase, nonzero =true??? If so, when will you break my code of:
if len(a$) then
' a$ is not nul
end if
The issue here is language definition and it's far more important than compile time type checking, compilers, or anything else. I'll repeat myself by saying that this issue of *language consistency* will absolutely explode when it is opened to the rest of the world.
I've been in this biz a long time... probably as long or longer than any of your policy makers. I don't know everything, but there are a few things I'm pretty sure about and this is one of them. If you don't believe me, just give me permission to discuss it in public and let's see.
Look, I *care* about VB. I'm not just trying to make someone's life difficult. This is a serious problem that will affect VB for a long time. I'm not smiling or grinning over this in case you haven't noticed.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Thursday, February 02, 1995 5:13:13 PM
From: Chris Dias [MSFT], 74441,137 #16052
Dan -
How much would you pay in performance for ANSI strings?? 25%? 50%?
We >went< to UNICODE strings so that we could work with all of our
components. That means OLE, DAO, Controls, etc. So, if we didn't go UNICODE
then where would performance be you ask? 7x slower. Yep.
So, the implications of converting UNICODE-ANSI-UNICODE in calling DLLs and
the performance lost there is minimal compared to being ANSI and working with
the other components of VB.
Yes, We (Microsoft) can be ANSI but we chose not to be because of
performance. We shielded the pains of migrating to 32bit as much as possible
- imagine if you were writing C applications and the work that you would need
to do to move to 32bits... its enormous.
Also, VB is in countries that use Double Byte OSs - if we didn't do this then
applications could not be localized... think of how many applications you
could sell all over the world.
We could have stayed ANSI but we decided to go UNICODE. We tried to make it
as painless as possible for developers to port their applications to 32bit
but in a lot of situations its NOT as easy as recompiling. Ask anyone who
has moved their C apps to 32bit. You can write code in 32bit, its just going
to take a little work to get there.
There isn't anything else I can (or will) add about this. These are the
reasons why - we've provided the byte data type for all single byte
processing.
Chris
- Microsoft Developer Support
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Thursday, February 02, 1995 5:27:03 PM
From: Zane Thomas, 72060,3327 #16055
Chris,
<<<
There isn't anything else I can (or will) add about this. These are the reasons why - we've provided the byte data type for all single byte processing.
>>>
I think that the (one of the many) point(s) that Dan is making here is that instead of introducing Byte, VB4 should instead introduce something like UNIString, or whatever. I have to agree with him that what has been done will be very unpleasant for many VB programmers.
The other thing to recall is that although Byte arrays are possible they're practically worthless as substitutes for strings since Mid, &, InStr, etc. don't work with Byte arrays. The addition of Byte arrays was an ill-conceived kludge.
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Monday, February 06, 1995 5:56:11 PM
From: Chris Dias [MSFT], 74441,137 #16386
Hi Zane -
>>>I think that the (one of the many) point(s) that Dan is making here is
that instead of introducing Byte, VB4 should instead introduce something like
UNIString, or whatever. I have to agree with him that what has been done will
be very unpleasant for many VB programmers.
The other thing to recall is that although Byte arrays are possible they're
practically worthless as substitutes for strings since Mid, &, InStr, etc.
don't work with Byte arrays. The addition of Byte arrays was an
ill-conceived kludge.
<<<
I think that there are messages later in this thread that do state that there
needs to be better support for the byte data type and (byte) arrays in
general. I (personally) think the byte data type is the best all around
solution but I also agree there needs to be supporting functions. We didn't
just think it up one day without considering all the implications... we also
took into consideration all of the problems of having UNICODE/ANSI strings
and this was the best solution.
So, submit a WinBug.
Chris
- Microsoft Developer Support
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Monday, February 06, 1995 10:15:16 PM
From: Zane Thomas, 72060,3327 #16397
Chris,
<<<
I (personally) think the byte data type is the best all around
solution but I also agree there needs to be supporting functions. We didn't just think it up one day without considering all the implications...
>>>
Regarding the Unicode/Ansi business I'm sure it was considered carefully. I'm still having trouble accepting that the "Byte Array" solution was carefully considered, otherwise there would already be supporting functions. That would work for me, but I know Dan's not going to be at all happy with the Byte Array solution. You should consider that Dan is probably more typical of VB programmers than I am.
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Monday, February 06, 1995 10:20:22 PM
From: Zane Thomas, 72060,3327 #16398
Chris,
Well I think I've had my say on this issue and on type-conversions. So unless something else comes up this will be my last message on this topic.
Besides, I'm too busy porting my code back to VB3 to deal with this issue any longer.
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Tuesday, February 07, 1995 10:35:16 AM
From: Karl Peterson, 72302,3707 #16436
Hi Chris --
>>I (personally) think the byte data type is the best all around solution but I also agree there needs to be supporting functions.<<
Bingo! 100% in agreement! I'd only state that "needs" is a little weak. I'd substitute "MUST" if you want a shippable product.
Later... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Karl Peterson, 72302,3707 Tuesday, February 07, 1995 12:40:11 PM
From: Dan Barclay, 72560,2354 #16442
Karl,
>>> >>I (personally) think the byte data type is the best all around solution but I also agree there needs to be supporting functions.<<
Bingo! 100% in agreement! I'd only state that "needs" is a little weak. I'd substitute "MUST" if you want a shippable product. <<<
You can look at that way for new code, but even if you get the byte data type doing what you need the change is going to break a lot of code. Other users are not going to be happy.
Your point about saving support calls is on the mark, but I wish you hadn't reminded them of the potential additional revenue <g>. It's probably locked in for good now...
BTW, I'll be out of the office until Friday or so. I may or maynot be online between now and then. If I left a thread open with someone and they start looking for me to respond... I ain't here.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Tuesday, February 07, 1995 3:32:09 PM
From: Karl Peterson, 72302,3707 #16455
Hi Dan --
>>You can look at that way for new code, but even if you get the byte data type doing what you need the change is going to break a lot of code. Other users are not going to be happy.<<
Nope. They're gonna catch hell! But, in the end, they're right. Apps *should* be rewritten for 32-bit. MS doesn't have the gonads to say this, but it's the truth. <g> If I'm rewriting, I want to use the most efficient methods possible. I think Byte arrays are a great idea which should have appeared long ago! But, they certainly need all the supporting binary operators for them to ever be an acceptable substitute for strings.
>>Your point about saving support calls is on the mark, but I wish you hadn't reminded them of the potential additional revenue <g>. It's probably locked in for good now...<<
:-(
Later... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Thursday, February 02, 1995 7:43:24 PM
From: John Craig, 71330,1520 #16071
Chris,
Trying to provide a positive suggestion here... If we're expected to use the Byte arrays to do the things we used to do with strings, then we need functions to match, like Instr, Mid, etc.
My pet peeve is I've still been unable to find a way to do a binary GET of a file into a dynamically allocated byte array in one call. (I don't want to read from the file one byte at a time.)
Solid code example to follow. Here's how I'd do it with a string...
Open "SomeFile" for binary as #1
A$ = space$(LOF(1))
get #1,,A$
If anyone knows yet of a way to load a byte array as efficiently as this I'd love to know about it.
The solution would be to provide functions for Byte arrays that parallel the string functions. (Still feels kludgy to me though.)
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: John Craig, 71330,1520 Thursday, February 02, 1995 8:26:15 PM
From: Zane Thomas, 72060,3327 #16075
John,
<<<
If anyone knows yet of a way to load a byte array as efficiently as this I'd love to know about it.
>>>
Well ... you *could* use API calls like _lopen and _lread for that kind of thing, guess that's what MS must have had in mind when they did this. <g>
Zane (By Design ... NOT)
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: John Craig, 71330,1520 Thursday, February 02, 1995 11:35:31 PM
From: Dan Barclay, 72560,2354 #16087
John,
>>The solution would be to provide functions for Byte arrays that parallel the string functions. (Still feels kludgy to me though.)<<
FWIW, I'm not going to be satisfied with a kludge. They can either fix this thing right or face the flak at release as far as I'm concerned.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Thursday, February 02, 1995 7:44:12 PM
From: Dan Barclay, 72560,2354 #16073
Chris,
>>How much would you pay in performance for ANSI strings?? 25%? 50%?<<
Come on. Don't start throwing up the smoke screen. I've worked in your environment and I know the kind of "redirection" that will come from the powers. There is *no* technical reason that we can't have Basic strings and UNICODE character strings side by side with comparable performance. In fact the half size of ANSI strings should allow them to be a bit faster for a number of things.
I realize that passing ANSI that must be converted will give some performance hit in some cases... so give us a UNIString that we can use in those cases. It's silly to argue the performance merits of one over the other. You know full well we need both and so do the keepers of the spec. They're just trying to take the easy way out at our expense and I'm tired of that attitude.
I'm afraid I've failed to make my point. Let me put it more bluntly:
MS IS GOING TO CATCH HELL BECAUSE THEY'RE GOING TO BREAK A LOT OF CODE.
It's not going to be from little 'ol Dan. This will be changed, I have no doubt about it. It may be after it's thrown back from the marketplace, but it will be changed. Put this message in a folder and pull it out 6 months from release of 32bit VB4 and see if I'm right or wrong. There is, according to the docs, a major incompatibility in the behavior of strings. The only solution to that is to restore the compatibility. You can do that by (1) ignoring UNICODE, (2) providing a new, but different, UNICODE data type, (3) provide special handling such that "UNICODE under the hood" doesn't matter... there are probably other solutions as well. In any case, if a solution isn't found before release then 32bit VB4 is seriously broken.
It's clear from your response that you've "run it up the flagpole" and the response was to choose to ignore it. I've been on a number of betas before and had serious discussions over more than one unreleased product. Frankly I've never seen the lack of understanding (or is a blinding arrogance) being displayed over these developer issues. It's going to hurt VB big time and it's not going to help *anyone's* career (including VB users).
I consider VB4 to be V?4. It's not Basic.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Thursday, February 02, 1995 10:17:31 PM
From: Zane Thomas, 72060,3327 #16082
Dan the Fan,
<<<
Don't start throwing up the smoke screen.
>>>
Ditto dude!
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Thursday, February 02, 1995 11:35:01 PM
From: Dan Barclay, 72560,2354 #16088
Zane,
>>Ditto dude!<<
In my crowd, that's "MegaDittos <mostly>"... but you probably don't want to hear about that so I won't agitate you with it <grin>.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Friday, February 03, 1995 1:52:00 AM
From: Zane Thomas, 72060,3327 #16091
Dan,
Speaking of agitation, have you ever heard Jim Hightower's radio show? You might try finding the local radio station by calling 1-800-AGITATE, really.
Sounds like you could use some varied sources of information. <g>
Zane (refers to 'them' as MegaDumbos!)
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Zane Thomas, 72060,3327 Friday, February 03, 1995 11:08:12 AM
From: Dan Barclay, 72560,2354 #16133
Zane,
Hightower? Yup. I'm a Texan and most of us have heard of him at one time or another <g>. He's now in Austin, where I went to school.
Actually I do get varied sources of information, and I find it very entertaining (from all directions). I agree with about 80% of Rush's drivvel but that other 20% is *really* hard to take.
I don't think that anyone can argue that he's (errr.... ) entertaining <g>.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Friday, February 03, 1995 1:52:03 AM
From: Zane Thomas, 72060,3327 #16093
Dan,
<<<
"MegaDittos <mostly>"... I won't agitate you with it
>>>
Yeah, right.
Now look what you've gone and done. I'd forgotten all about that Fat-Headded Blowhard for a couple days.
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Monday, February 06, 1995 6:42:03 PM
From: Chris Dias [MSFT], 74441,137 #16392
Hi Dan -
Before you continue to flame on this thread, you should probably install
32bit and see if your fears are founded. I have read all of your comments
and you do not even have proof that there is a problem.
VB strings are UNICODE. That means they are stored internally as two bytes.
You access the string in the same manner - a *character* at a time, not a
byte at a time. So, if you are looking in a string using Instr, Mid, etc.
the results will be the same.
Dim x As String
x = "Hello"
Print InStr(x, "ll")
If you want to look at things a byte of a time, all the functions have a "B"
counterpart (ie InStrB, MidB, LenB, etc.).
Take a look at what you need your code to do and see if the "B" versions work
for you.
Chris
- Microsoft Developer Support
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Monday, February 06, 1995 10:23:13 PM
From: Dan Barclay, 72560,2354 #16399
Chris,
>>Before you continue to flame on this thread, you should probably install 32bit and see if your fears are founded. I have read all of your comments and you do not even have proof that there is a problem.<<
*Prove* it??? Hold on a minute! I know you're trying to catch up from being out but I think you missed some important points in my messages.
What I've said is that you've *changed the definition* of strings and, ACCORDING TO THE DOCS, it will CORRUPT data in the 32bit version or some future version.
That is a correct statement and I submitted a winbug immediately on finding it stating it is EITHER
1. a major design flaw or,
2. serious documenation error.
The *proof* is in the manual! Take a close look at the messages I've posted and at the winbug.
FWIW, I do plan to test on 32bits (still waiting on my MSDN CD's) and I put together a machine just for that. HOWEVER, even if I don't find the corruption my comment stands on its own. There are even warnings about it in the "compatibility" comments from previous versions. How can I trust it to work correctly when I'm *plainly warned it won't*?
I said in an eariler note, I don't care how this problem is solved. It can be UNICODE under the hood so long as it still behaves correctly for binary data. According to the docs, and comments from Sunil's testing, it doesn't. If it's changed to behave properly and the docs are revised to reflect it I'll be a happy camper on that issue. If not, I'm going to be very UNhappy and I'll react to it because it's going to break a lot of code, including mine. What's more, if it's left the way it is I don't have a lot of confidence you won't change some other fundamental feature in the next release and cause me to recode everything again.
Frankly, the kludge of byte arrays is not worth the effort for me to change to. If my app won't work with strings and string arrays it'll be a long time before I screw with 32bit apps. I'm not going to rewrite 50k lines of code every couple of years. Changing to byte arrays is just not an acceptable alternative.
Someone still needs to get the attention of ByDesign on this kind of thing though. This *never* should have made it to spec and documentation! Now *that* has me steamed. I was interested in the beta because I wanted to work with some of the performance issues, but this blatant incompatibility has floored me.
Look, I'm not flaming for the fun of it. I want VB4 to be a success and I'd *much* rather be working on performance issues. I've said in plain English I want something I can kick some butt with. I'm just telling you it's going to be a *serious* problem if these issues aren't attended to and if MS doesn't start paying attention to the hard core developer issues (type checking, compiler, etc, etc).
I'm going to shut up on this one for a while. Partly because I'll be out of the office for a couple of days <g> but I'll be quiet nevertheless. To Flame or Not To Flame. I don't know how else to get attention on this without waiting until release. I've flamed on it and I'm done unless you indicate you need more clarification on what I've said.
Please believe me! It's going to break a *lot* of code and the mere change will turn off the corporate types looking for the New Legacy environment. I work with these guys and I know what I'm talking about. I have legacy code of my own and I have the same view of it, as do others here.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Tuesday, February 07, 1995 6:57:15 PM
From: Chris Dias [MSFT], 74441,137 #16477
Hi Dan -
>>>What I've said is that you've *changed the definition* of strings and,
ACCORDING TO THE DOCS, it will CORRUPT data in the 32bit version or some
future version.
<<<
What the docs are stating is that if you pass a string to a DLL and you
expect to fill it with binary data, the string, upon return will not have
each and every byte filled as you would under 16bits.
Internally the string is UNICODE so the 'A' takes up two bytes. You pass
this to a DLL and its converted to one byte. Upon return from the DLL its
converted back to two bytes. Now, with binary data there may not be a way to
convert back to UNICODE and this is where your problems will arise.
Now, I am still trying to find a situation where this is a problem with text
- if I read a binary file with text the strings return ok. There are a
number of other data types which I would like to look at as well. Now, if I
do find something that is corrupt then we can document how this works and
why. As of right now I have no proof of corruption (from me or anyone else).
A couple of issues Sunil and I discussed earlier...
When you try to pass fixed length UNICODE strings within UDTs to DLLs that
are not expecting the UDTs to be DWORD aligned then you will have problems.
32 bit DLLs should assume DWORD alignment because under 32bit operating
systems it is a huge performance hit if parms are not aligned correctly on
the stack.
The second issue we saw was attempting to LSet from byte arrays to UDTs with
fixed length strings (or any length for that matter). Essentially the LSet
is a memcpy (RtlMoveMemory under Win32). VB will start copying bytes and
does not look at the underlying structure - strings or numerics. So, if you
try to copy a byte array to a string using LSet and UDTs then you will fill
in every byte of the string where in the UDT every other byte should have
been filled.
You can copy strings and byte arrays using the StrConv function.
>>>That is a correct statement and I submitted a winbug immediately on
finding it stating it is EITHER
1. a major design flaw or,
2. serious documenation error.
The *proof* is in the manual! Take a close look at the messages I've posted
and at the winbug.
<<<
Thanks, we received the WinBug.
>>>I said in an eariler note, I don't care how this problem is solved. It
can be UNICODE under the hood so long as it still behaves correctly for
binary data. According to the docs, and comments from Sunil's testing, it
doesn't. If it's changed to behave properly and the docs are revised to
reflect it I'll be a happy camper on that issue. If not, I'm going to be
very UNhappy and I'll react to it because it's going to break a lot of code,
including mine. What's more, if it's left the way it is I don't have a lot
of confidence you won't change some other fundamental feature in the next
release and cause me to recode everything again.
<<<
Its not going to change. Its how VB handles strings under 32bit. I am sorry
to be the bearer of the news but the only thing we can do is try to get more
functions for byte arrays.
I understand the frustration and I can see how the move to 32bit could be
difficult. I don't know what you are doing with binary data and strings so I
cannot say "hey Dan don't do that... do this". If you can give me some
insight into your code then we can see whats up. Moving to 32bit is no
trivial task - there will be many tricks that were pulled in 16bit that will
not work in 32bit. I'm not saying what you were doing was a trick - I am
just trying to make a point. When I discussed the performance issues before
it was not a smokescreen, it was the truth. The whole byte data type
issue was also thought out for quite a while
I have relayed the information onto development/program management so this is
not falling on deaf ears. Just give me some examples and we'll work from
there.
Chris
- Microsoft Developer Support
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Tuesday, February 07, 1995 9:05:12 AM
From: Sunil Shah, 71051,3315 #16425
Chris:
I have given you ample proof how UNICODE strings are causing problems.
But that's not the main point of this message. From all your messages
I have concluded that:
1. In 32-BIT VB4 UNICODE is going to stay. If you run into problems
(like I did with Btrieve files) then tough luck. Don't use Btrieve
or rewrite all the VB3 code, discard all the existing Btrieve files,
create new btrieve files and forget about sharing these files from
workstations running VB3 and workstations running 32-BIT VB4.
2. Relexed type checking when arguments are passed by value is going
to stay. Just be more careful in the way you program. If your EXE
fails in the field then you didn't do a thorough checking of your
VB program. You pay for it.
3. 32-BIT VB4 will always do DWORD alignment in UDT's. If you get
screwed because of this, well tough luck again. Don't use 32-BIT
VB4 or rewrite your application.
I'll leave the 2nd issue aside for now.
So far as the UNICODE strings are concerned I think we must
have MID$, INSTR, LEFT$, RIGHT$, LTRIM$, RTRIM$ and TRIM$ for
Byte Arrays.
Thanks, Sunil.
Hi Chris --
>>If you want to look at things a byte of a time, all the functions have a "B"
counterpart (ie InStrB, MidB, LenB, etc.).<<
Well, these functions are strange. Check out this code:
Private Sub Form_Click()
Dim t$, i%
t = "0123456789"
Debug.Print "B-functions", "LenB(t)=" & LenB(t)
For i = 1 To LenB(t)
Debug.Print MidB(t, i, 1);
Next i
Debug.Print
Debug.Print "Std Functions", "Len(t)=" & Len(t)
For i = 1 To Len(t)
Debug.Print Mid(t, i, 1);
Next i
Debug.Print
End Sub
Which produces this output (note *no* output for first loop):
B-functions LenB(t)=20
Std Functions Len(t)=10
0123456789
Now, trying to get the *byte* value from the strings, I used:
Debug.Print Asc(MidB(t, i, 1));
Guess what? I got an "Invalid Procedure Call" on the first iteration of the first loop! Highlighting "Mid(t, i, 1)", and pressing the eyeglasses, it showed "0". Of course, entering "?Asc("0")" in the debug window correctly returns 48. But, this loop choked.
>>Take a look at what you need your code to do and see if the "B" versions work
for you.<<
So, I guess I need to ask, what's the use of these B-functions? And, is there any better documentation on using them than the sentence at the bottom of their related function help page?
Thanks... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Friday, February 03, 1995 10:06:31 AM
From: GREGG IRWIN, 72450,676 #16122
Chris,
<There isn't anything else I can (or will) add about this. These are the reasons why - we've provided the byte data type for all single byte processing.>
I don't have a problem with supporting UNICODE and DBCS and I applaud all the efforts you guys have made to shield us from the chores of porting...HOWEVER
These changes can't be made in such a way that they break hundreds of thousands of lines of existing code! Dan's example about possible data corruption is great! I use lots of strings in nested types and encode all *kinds* of stuff in there. Is that going to port? Will everything be fine until some wise guy on the net installs NT and runs the app, trashing everything in one fell swoop? Dropping byte arrays in where strings are used today is no small task and others have already mentioned the lack of equivalent string operations to work on Byte arrays. Can we have a BString data type that just works like the old strings we know and love? Does BillG know what's been done to BASIC?<g>
--Gregg
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: GREGG IRWIN, 72450,676 Monday, February 06, 1995 7:02:02 PM
From: Chris Dias [MSFT], 74441,137 #16393
Hi Gregg-
>>>These changes can't be made in such a way that they break hundreds of
thousands of lines of existing code! Dan's example about possible data
corruption is great! I use lots of strings in nested types and encode all
*kinds* of stuff in there. Is that going to port? Will everything be fine
until some wise guy on the net installs NT and runs the app, trashing
everything in one fell swoop? Dropping byte arrays in where strings are used
today is no small task and others have already mentioned the lack of
equivalent string operations to work on Byte arrays. Can we have a BString
data type that just works like the old strings we know and love? Does BillG
know what's been done to BASIC?<g>
<<<
The strings will work the same! The only difficulty I have seen is Suni's
attempting to LSet strings into Byte Arrays. Since this is documented (in
previous versions of VB, too) its no surprise that it didn't work as
expected.
You guys need to check this out before raising all these flags that it does
not work.
Chris
- Microsoft Developer Support
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Monday, February 06, 1995 10:23:18 PM
From: Dan Barclay, 72560,2354 #16400
Chris,
I've already replied to another message, but to respond specifically to your comment:
>>>====from your message:
The strings will work the same! The only difficulty I have seen is Suni's attempting to LSet strings into Byte Arrays. Since this is documented (in previous versions of VB, too) its no surprise that it didn't work as expected.
You guys need to check this out before raising all these flags that it does not work.
>>>====
He're what the VB4 manual has to say about that (ref Appendix C, Compatibility with other versions):
================================= quoting manual:
BINARY DATA
Applications written using older versions of Visual Basic typically store binary data in String variables. As long as these variables are only used within the application or in 16-bit applications, this may not cause compatibility problems. However, when using the 32-bit version of Visual Basic, String variables are automatically converted from Unicode characters to ANSI characters when passed to a DLL procedure or written to a file. Binary data stored as String variables will become unintelligibile by this conversion.
================================= endquote
I generally interpret "unintelligible" is meaning "corrupted".
Clearly strings WILL NOT work the same! What else is there to check out??? If you were told the above and found that things still *appeared* to work the same, would you count on it??
I thought Sunil was LSetting strings into UDTyped data. This is commonplace, but I haven't been able to test the byte alignment issue so I'll reserve judgement on that. I do know that I can, correctly, use the following in VB2 and all previous versions (including DOS Basics):
Type ConvType
datastuff as string*17
End Type
Type TheDataType
AByte as string*1 ' any number, alignment isn't an issue...
Double1 as double
Double2 as double
End Type
dim ConvData as ConvType
dim TheData as TheDataType
DataBuffer$=space$(5000)
' call btrieve or Get from AsBinary file to fill DataBuffer$
ConvData.DataStuff=mid$(DataBuffer$,StartData%,17)
lset TheData=ConvData
This sequence, while it moves more data than I'd like, works well. I hope it continues to work in VB4 because my customers have a lot of data already in their files. Converting to nice, clean, word aligned data types is not an option for files already on the ground.
We're not raising flags before checking it out! The people here know what the hell they're talking about!
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Thursday, February 09, 1995 4:50:02 PM
From: Chris Dias [MSFT], 74441,137 #16762
Hi Dan -
>>>I thought Sunil was LSetting strings into UDTyped data. This is
commonplace, but I haven't been able to test the byte alignment issue so I'll
reserve judgement on that. I do know that I can, correctly, use the
following in VB2 and all previous versions (including DOS Basics):
<<<
Sunil is running into two problems - ANSI/UNICODE conversions and the DWORD
alignment of structures.
>>>
Type ConvType
datastuff as string*17
End Type
Type TheDataType
AByte as string*1 ' any number, alignment isn't an issue...
Double1 as double
Double2 as double
End Type
dim ConvData as ConvType
dim TheData as TheDataType
DataBuffer$=space$(5000)
' call btrieve or Get from AsBinary file to fill DataBuffer$
ConvData.DataStuff=mid$(DataBuffer$,StartData%,17)
lset TheData=ConvData
<<<
This code is somewhat incorrect but essentially it will not work as is. The
string returned from the DLL 'DataBuffer' will be UNICODE and all the data
you put in there will be split into two byte chunks. When you LSet into the
structure the bytes will be offset meaning the string portion will be ok
since its at the beginning of the structure but the Double elements will not
work.
There are ways to convert strings to and from UNICODE using StrConv as well
as passing to and from Byte arrays using StrConv. Its going to take a little
work to get this code to work under 32bit.
Chris
- Microsoft Developer Support
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Sunil Shah, 71051,3315 Friday, February 10, 1995 7:22:22 PM
From: Chris Dias [MSFT], 74441,137 #16873
Hi Sunil -
>>>
1. In 32-BIT VB4 UNICODE is going to stay. If you run into problems
(like I did with Btrieve files) then tough luck. Don't use Btrieve
or rewrite all the VB3 code, discard all the existing Btrieve files,
create new btrieve files and forget about sharing these files from
workstations running VB3 and workstations running 32-BIT VB4.
<<<
The UNICODE will stay but I am looking into getting additional support for
byte arrays which would make this process a lot easier.
>>>
2. Relexed type checking when arguments are passed by value is going
to stay. Just be more careful in the way you program. If your EXE
fails in the field then you didn't do a thorough checking of your
VB program. You pay for it.
<<<
Again, I am still working on this one. I don't see it as an extremely
serious situation because I don't see that you would pass by value that
often. Granted, you can pass byval without knowing it but its pretty rare.
I'm still working this one.
>>>
3. 32-BIT VB4 will always do DWORD alignment in UDT's. If you get
screwed because of this, well tough luck again. Don't use 32-BIT
VB4 or rewrite your application.
<<<
Yes.
>>>
So far as the UNICODE strings are concerned I think we must
have MID$, INSTR, LEFT$, RIGHT$, LTRIM$, RTRIM$ and TRIM$ for
Byte Arrays.
<<<
Karl Peterson submitted a bug on this and I'm chasing that one as well. I'll
keep everyone posted.
Chris
- Microsoft Developer Support
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Friday, February 10, 1995 10:19:19 PM
From: Dan Barclay, 72560,2354 #16883
Chris,
>>The UNICODE will stay but I am looking into getting additional support for byte arrays which would make this process a lot easier.<<
It's unfortunate that's the response on this. I'll try to get you more hard data, but I'm afraid someone just doesn't get the point on changing the behavior of this data type. You have made a new data type, plain and simple, and replaced an old data type with it. Apparently I haven't explained this clearly enough but I don't know any other way to say it.
It will be dumped on and cursed, big time. Count on it.
Dan.
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Saturday, February 11, 1995 11:08:18 AM
From: Dan Barclay, 72560,2354 #16897
Yo, Chris,
With the need to change to 16 bit (two byte, double byte, whatever) characters in NT, I assume all other languages will be following suit with their respective character data types.
Oooops! I just checked the VC2 docs again and they seemed to have *missed* that one! I assume you'll make the announcement soon that the char is double byte and you've introduced a new Byte data type??
If not, why not? After all, the char is "officially" supposed to be a character and not a binary byte. Should I go ahead and make that announcement over in MSLANG and check the response? After all, I could be wrong about it.
*Think* about the pleasant reception that news will receive and you'll begin to get the picture of what is going to happen. And, yes, I know the CString will change but it's not a fundamental data type, it's relatively new, and I have the class library source for it if I want to retain it's definition. Also, as I recall, the UNICODE feature of CStrings is *optional*.
Yes, it *is* the same thing.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Karl Peterson, 72302,3707 Friday, February 10, 1995 7:22:26 PM
From: Chris Dias [MSFT], 74441,137 #16874
Hi Karl -
>>>
So, I guess I need to ask, what's the use of these B-functions? And, is
there any better documentation on using them than the sentence at the bottom
of their related function help page?
<<<
The "B" functions are behaving a little strange. I tried them out myself and
received pretty much the same results as you. It looks as though my
impression of their functionality is the same as yours is so I am trying to
chase these down and see if they are bugs or if the functionality is
different than I expect.
Chris
- Microsoft Developer Support
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Sunday, February 12, 1995 1:28:14 AM
From: Karl Peterson, 72302,3707 #16926
Hi Chris --
>>It looks as though my impression of their functionality is the same as yours is so I am trying to chase these down and see if they are bugs or if the functionality is
different than I expect.<<
Good idea, poorly implemented? I'll be curious to hear what you find. Like I said, the docs on them are extremely limited. In fact, I had no idea they existed til you pointed them out. Let me know, okay?
Thanks... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Karl Peterson, 72302,3707 Sunday, February 12, 1995 2:49:24 PM
From: Tim Paterson, 72740,2456 #16961
There has been a great deal of confusion over the effects of Unicode strings in 32-bit VB4 that I think I can shed some light on. If you haven't seen my message on univesal coercion (a.k.a. "ETC"), I am a VBA developer. I was responsible for the compiler and execution engine for QB4.0, QB4.5, VB1, VB2, and Access Basic 1, and just the execution engine in VBA1(Excel) and VB4.
First some background on how we got here. (If you want, you can jump ahead to "**** Start of useful stuff ****".)
Microsoft ships software products in more countries than anyone else. It seems like just about every national language has certain peculiarities in its alphabet, meaning they each have their own "code page" -- the mapping of character code to printed symbol. In some locales, including much of the Far East, the problem is much worse than that: they have more symbols than fit on a 256-character code page. For those languages we use the Double Byte Character Set (DBCS).
This is a royal pain, and the Windows NT group decided there was a better way: from the beginning they were committed to using Unicode instead of ANSI characters. The beauty of Unicode is that with its 16-bit character, it has enough character codes to represent the characters in all languages without multiple code pages.
Without going into the pros and cons of that issue any deeper, that's what got this started. So why did Basic follow Windows NT and switch to Unicode? I wasn't part of the decision process, but I would guess for two reasons:
1. One of VBA's targets is to be the automation glue tying together OLE-enabled applications. As such, VBA and OLE Automation data types have been kept closely in sync because OLE-managed communication requires it to understand and manipulate the data being passed. String data can only be passed with BSTR's, which are Unicode. Basic uses the BSTR as its String data type so that no conversion is needed every time a string is passed to or from an object.
2. Because of the decision of the Windows NT group, the future is Unicode. There is some pain to the transition but it is inevitable. Windows 95 is not fully Unicode yet, but from what I've heard, it will be eventually. OLE Automation in Windows 95 is fully Unicode.
Why did we change the existing String data type instead of creating a new one? If String is accepted to be a character string, not a byte string, we didn't change it. In the U.S., there has been no way to distinguish characters from bytes except by closely reading the documentation. For example, my QB4.0 manual from 1987 says of the LEN function: "Returns the number of characters in a string or the number of bytes required by a variable."
In Japan, on the other hand, this distinction has been important from the beginning. DBCS is used in the products we sell there, so a character can be either one or two bytes. The LEN function scans the string to determine the actual character count, not byte count. Years ago we introduced the functions LenB, LeftB, RightB, etc. in our Japanese products so that strings could be accessed by byte as well as by character.
**** Start of useful stuff ****
Let's move on to figuring out what this means to binary data. I will be making some suggestions and it would be very helpful to get feedback on how well they actually work in real programs, and what holes are still there.
Within Basic, you should be able to use strings for binary data (almost) exactly the same way you always have! All you have to do is use LenB, LeftB, MidB, RightB, and InstrB instead of the character functions.
OK, so Chris said that already and he was proven wrong with following code (reduced case):
Private Sub Form_Click()
Dim t$, i%
t = "0123456789"
Debug.Print "B-functions", "LenB(t)=" & LenB(t)
For i = 1 To LenB(t)
Debug.Print Asc(MidB(t, i, 1)); 'Invalid Procedure Call!!!
Next i
End Sub
The Asc function gives Invalid Procedure Call at runtime. The problem here is a bug in Asc() that is fixed for TR5. Asc() fails on 1-byte strings.
Another problem you could have is that there is no AscB(). For TR5, Asc() of a 1-byte string will return the byte. But if it is more than one byte, it will convert the Unicode characters to ANSI and return that result.
You can create your own AscB function that always works correctly. Yes, you can pass a string to this function:
Function AscB(x() as Byte) as Byte
AscB = x(LBound(x))
End Function
With the addition of this artificial AscB, I would think that we have all functions needed to do byte manipulation of strings. Functions like LTrim and UCase shouldn't need binary counterparts because they make sense only in a character context.
I think the main remaining problem is transferring binary data outside of Basic -- either through file I/O or as parameters to Declared external functions. In either case, using a String will cause a conversion from Unicode to ANSI, destroying the binary data. This is where byte arrays come in.
Unfortunately, in TR4 you cannot do file I/O on arrays, so I think we're stuck on this one until TR5 is out. Currently (TR4 and TR5), the only way to convert a string to a byte array is to pass the string to a byte array parameter, as in the AscB function above. Converting a byte array to a string is much easier: all you have to do is pass it through a Variant. For example:
s$ = CVar( b() ) 'Dim b() as Byte
This implies, by the way, that you can use byte arrays as arguments to Left/LeftB, etc. The result is string, however, not an array.
Obviously this is not a very consistent way to expose these conversions. I have suggested changes but it is getting very late to expect new features.
Transferring binary data with a Declared DLL function, on the other hand, is handled easily with byte arrays. Dim/Redim the byte array for the desired buffer size, then pass the first element of the array by reference. If needed, convert to/from String using the techniques mentioned above.
When using an external function declared in a type library, the problem is gone. The type library specifies whether the function uses Unicode or ANSI strings.
I hope this helps.
Tim Paterson
VBA Development
Microsoft
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Tim Paterson, 72740,2456 Sunday, February 12, 1995 4:19:27 PM
From: Sunil Shah, 71051,3315 #16979
Tim:
Thanks for the wonderful insight into UNICODE issues.
My major problem is accessing hundreds of EXISTING Btrieve files. I am
able to access these files from WFW 3.11, Win95 and WinNT as long as
I use VB3 or 16-BIT VB4.
In 32-BIT VB4 as you stated I have to change all the FIXED LENGTH STRING
type FILEDs in all my UDTs to Byte arrays to be able to access these
files. But the problem doesn't end there. In 32-BIT VB4 running under
WinNT 3.5 some strange (Chris calls it DWORD) alignemt happens inside
UDT type variables and practically every Btrieve file I have, I can't
access them (EVEN AFTER CHANGING OVER TO BYTE ARRAYS) because of this
so called DWORD alignment.
Even if DWORD alignment didn't exist (or was not a problem) it is not
easy (the way VB4 supports Byte type now) to access these Byte Array
fields like the old Byte Strings used to be. You can understand this
only when you start real coding and see how much extra code you have to
write in 32-BIT VB4.
Moreover the Lset function used to work (and was THE MOST USEFUL feature)
wonders in VB3 and 16-BIT VB4 is totally broken in 32-BIT VB4 assuming
one doesn't go through and lots of StrConv all over the code.
To date I haven't found any answers to the above problems and to tell
you the truth I don't have very high hopes of finding them either.
Thanks, Sunil.
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Tim Paterson, 72740,2456 Monday, February 13, 1995 10:15:25 AM
From: Dan Barclay, 72560,2354 #17055
Tim,
What I'm concerned about is code portability between environments. The primary influence on this is consistency in the language definition which, to date, has been excellent.
>>Why did we change the existing String data type instead of creating a new one? If String is accepted to be a character string, not a byte string, we didn't change it.<<
It is NOT accepted as a character string. But you knew that. As you know, the string in MSBASIC has been used for binary data since day 1 since it is *the only way to handle binary data* in Basic. To accept it as a character string implies that Basic has no way to handle binary data! So, let's forget that premise. It is invalid and will be viewed as such by anyone handling binary data in Basic (have you seen the joke about how many 'Softies it takes to change a lightbulb?).
Regardless of what the reasons are, and how good they sound, when you make changes to the language behavior there are very serious consequences. The key word here is "behavior". It doesn't matter, from a language standpoint, what's under the hood so I have no beef about Unicode vs Ansi internally.
I haven't had time to sit down with your message and understand the details, but a scan of it says "we should be able to use strings for binary data (almost) exactly the same way you always have".
I need to know (clearly and explicitly) what the exceptions are. Defining how the conversion works internally is going to be important. I think I know, but documenting it is important.
Recoding applications is not an option here, in my opinion. We need to identify which cases the Unicode strings misbehave with binary data and determine what options are available to fix (not workaround) those cases. Recoding a bazillion apps to use AscB, etc is going to be very unpleasant when it appears that using plain 'ol Asc, Mid, etc should work fine. The more I think about it I believe nearly all exceptions can be eliminated so that binary data handling is undisturbed at the language level.
Remember, *all* applications that handle binary data are potentially affected by this issue.
As for my own testing, I'm fairly limited in the amount I can do on NT. My app requires several 3rd party libs that aren't available yet as 32bit DLL's so I can only test with miniapps. In the little I've done in the last couple of days I haven't identified a problem, but that's not saying much.
I'll try to provide more info as I have time to dig into this. Unfortunately I'll only be here a couple of days then out until next Monday.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Tim Paterson, 72740,2456 Monday, February 13, 1995 12:17:08 PM
From: Dan Barclay, 72560,2354 #17061
Tim,
I do not see the need to change from Asc/Len/Mid to some version explicitly looking for bytes (AscB/LenB/MidB). How about leaving those alone (they *appear* to work properly. When I read/write binary data from a file these functions set or return data as I'd expect.
If we're going to change behavior, how about making new AscU/LenU/MidU functions instead??
When I say "handle binary data" with Unicode, I mean handling it so that the *behavior* is the same as previous versions. I *don't* mean that we need to handle/store it internally the same. If the binary data is stored as lowbyte Unicode with highbyte zero, I don't care and (from a compatibility s tandpoint) I don't need to access the highbyte (it wasn't even avialable in previous versions). I *do* care that I read (GET) binary data to a string from a file, access the data and swap it around a bit using Mid$,Left$,Asc, Chr$, etc. then write it back to the file the same as if I were executing in VB3. Same goes for DLL calls.
I *don't* mean that binary data should be read into the string data area and, necessarily, have adjacent binary bytes. That would be handy, a bit faster and use half the memory, but it's an implementation detail that isn't important at the language level. The fact that you're using underlying OLE routines to handle the strings, I agree, outweighs the advantage of genuine binary strings. Nothing I've seen discussed here outweighs the need to keep *behavior* consistent with previous versions.
If you provide access to the high byte, that's *new* functionality and could be treated as such.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Tim Paterson, 72740,2456 Monday, February 13, 1995 3:55:30 PM
From: Karl Peterson, 72302,3707 #17083
Hi Tim!
>>I was responsible for the compiler and execution engine for QB4.0, QB4.5, VB1, VB2, and Access Basic 1, and just the execution engine in VBA1(Excel) and VB4.<<
Alright, I think bringing the developers into this discussion is exactly what's needed!
>>First some background on how we got here.<<
I think I pretty much understand the situation as it exists, and can even relate to the troubles. I'm actually a Unicode proponent! But, at the same time, we still need to be able to operate on binary data. Thanks anyway for the inside view of this process, though.
>>Within Basic, you should be able to use strings for binary data (almost) exactly the same way you always have! All you have to do is use LenB, LeftB, MidB, RightB, and InstrB instead of the character functions.<<
Okay, but... <g> There seems to be a great deal of confusion here. At what point would the second byte of a Unicode "character" get filled in? If I'm reading 32K data from a file directly into a "string", I should only need a "16K" buffer? I mean, do I need to set aside 16K characters, assuming each consists of two bytes? If this is the case, and these other functions work as advertised, then things are starting to look a little better. Until, of course, other DLLs come into play. Than *kapow*, eh?
And, if the buffer still needs to reserve 32K characters, then what's the need for the "B" functions? Will all binary file I/O just use that first byte? This is *very* fuzzy! As far as I can tell, that's what's happening. Modifying that snippet you refered to:
hFile = FreeFile
Open "c:\autoexec.bat" For Binary As hFile
Buffer = Space(LOF(hFile))
Get hFile, , Buffer
Close hFile
Debug.Print "B-functions", "LenB(t)=" & LenB(Buffer)
For i = 1 To LenB(Buffer)
Debug.Print AscB(MidB(Buffer, i, 1)); 'Invalid Procedure Call!!!
If i Mod 20 = 0 Then Debug.Print
Next i
Gives me:
B-functions LenB(t)=1572
105 0 102 0 32 0 110 0 111 0 116 0 32 0 37 0 49 0 33 0
61 0 61 0 85 0 80 0 68 0 65 0 84 0 69 0 33 0 32 0
105 0 102 0 32 0 110 0 111 0 116 0 32 0 37 0 49 0 33 0
61 0 61 0 117 0 112 0 100 0 97 0 116 0 101 0 33 0 32 0
(etc.)
So, again, I think the critical piece of missing information is *when* will those second bytes be used? Ever?
>>With the addition of this artificial AscB, I would think that we have all functions needed to do byte manipulation of strings.<<
It's starting to sound as if it isn't wise to do byte ops with strings. Can't that just massively horse things up? I'd *really* rather have all the functions necessary to do byte manipulations on *byte* arrays! Sorta makes sense, don't it? <g>
>>I think the main remaining problem is transferring binary data outside of Basic -- either through file I/O or as parameters to Declared external functions. In either case, using a String will cause a conversion from Unicode to ANSI, destroying the binary data. This is where byte arrays come in.<<
In the previous example, there was no corruption of the binary data (other than the nulls being inserted! <g>). The string still read/displayed appropriately. But, you're right, if processing this byte-by-byte, it would be next to impossible.
>>Unfortunately, in TR4 you cannot do file I/O on arrays, so I think we're stuck on this one until TR5 is out.<<
I'll wait. But, it's simply *gotta* be there! I'd really rather work with Byte arrays. I think that's a much cleaner approach when the object is byte manipulation! <g>
>>Currently (TR4 and TR5), the only way to convert a string to a byte array is to pass the string to a byte array parameter, as in the AscB function above.<<
That's okay, if that routine is the only place you need to operate on it like that. But, it looks like it's not all that cool if you want to do byte manipulations on file data, at least until the Get/Put work with Byte arrays, at which point there's no need, eh?
>>Converting a byte array to a string is much easier: all you have to do is pass it through a Variant.<<
Yeah, that'll work. As long as you don't want to *display* that data! Doing this packs the second byte, and returns a string 1/2 as "long" as expected.
>>Obviously this is not a very consistent way to expose these conversions. I have suggested changes but it is getting very late to expect new features.<<
No, they're all good ideas, but they simply don't cut it. And, these really aren't "new" features. They've been there all along, and now are gone! The native Byte type is a great idea! But, it's virtually useless. The string data type is also virtually rendered useless for byte-by-byte work. I shudder to think about data types that span several bytes. The required gynastics are ridiculous.
Now, if Get/Put, Instr, LSet, and Mid worked with Byte arrays, then there would be no problem. We could all get past this. I *need* direct assignment to Byte arrays! As long as Byte arrays need to be converted to strings for some operations, and strings to Byte arrays for others, it's *not* Basic. It's nothing but a slimey hack. And, a pretty crude one at that. I say, concentrate on making Byte arrays work for binary data operations, and leave strings to handle text situations. Don't blur the distinction anymore. Make it clear, and make it work!
Thanks... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Karl Peterson, 72302,3707 Monday, February 13, 1995 4:57:05 PM
From: Rune Bivrin, 100126,2737 #17098
>>Thanks... Karl
Are we by this to assume that you do not want it later, but now? <g>
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Rune Bivrin, 100126,2737 Monday, February 13, 1995 11:09:17 PM
From: Karl Peterson, 72302,3707 #17136
Hi Rune --
>>Are we by this to assume that you do not want it later, but now? <g><<
Hey, I can wait til March. <g>
Later... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Karl Peterson, 72302,3707 Tuesday, February 14, 1995 6:57:16 PM
From: Chris Dias [MSFT], 74441,137 #17220
Karl - Tim asked me to post this reply to msg #17083.
Chris
- Microsoft Developer Support
Karl:
I can see you're trying to understand what's going on with Unicode strings,
so let me clarify some things for you. There are three categories: file
I/O, parameters to Declared procedures, and strings used within Basic.
In order to make text files transferable between 16-bit and 32-bit products,
we always read/write characters as ANSI, as the 16-bit products have always
done. Since the strings are stored internally as Unicode in the 32-bit
product, this means we have to do a translation from one character set to the
other.
If you are writing a string to a file, we take each 2 bytes, assume they
represent a valid Unicode character, and map it to the closest ANSI character
for the current code page. Likewise, on reading from the file into a string,
we take each byte and map it to the 16-bit Unicode character the code page
dictates.
If you try this out with valid text strings, of course you'll find the data
was preserved. But obviously if the string data were actually binary bytes,
there is no way to reconstitute each original 16-bit quantity from the 8-bit
character we map it to (or possibly two 8-bit characters for DBCS code
pages). As it turns out, the first 128 Unicode characters are the same as
the first 128 ANSI characters; for these characters (the only ones commonly
used in English), the mapping just zero-extends the 8-bit value to 16 bits.
But don't be fooled into thinking that random binary data will survive the
translation.
This is where the work-around of using byte arrays comes in. By copying the
string into a byte array and writing that (when TR5 is available), there is
no translation and the binary image of the string is preserved.
For DLL procedures with Declare statements, the story is much the same.
String parameters and return values are translated so that the DLL sees only
ANSI strings, never Unicode. The work-around for binary data is essentially
the same: use byte arrays instead of strings. Typically, a ByVal String has
been used as a data buffer; instead, make it a Byte (by reference) and pass
the first element of a byte array.
Once you have a string that contains binary data, operating on it within
Basic should be the same as ever, as long as you use th "B" versions of the
string functions (assuming AscB exists for now). I do not understand this
statementat all:
| The string
| data type is also virtually rendered useless for byte-by-byte work. I shudder
| to think about data types that span several bytes. The required gynastics are
| ridiculous.
It should be no less useful than it ever was, within the constraints I have
mentioned. If there is some difficulty handling binary data within Basic
(excluding file I/O and DLL parameters), I do want to hear about specific
problems. Grabbing a byte or group of bytes would be done by MidB, just like
always. If a group of bytes represented an ANSI string, you can extract it
with MidB and use StrConv to convert it to Unicode for display.
Tim Paterson
VBA Development
Microsoft
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Wednesday, February 15, 1995 1:21:08 AM
From: Dan Barclay, 72560,2354 #17234
Chris,
Please pass along:
>>If you try this out with valid text strings, of course you'll find the data was preserved. But obviously if the string data were actually binary bytes, there is no way to reconstitute each original 16-bit quantity from the 8-bit character we map it to (or possibly two 8-bit characters for DBCS code pages).<<
If this were true it is unacceptable. Plain and simple. As I've said before, this would break *every* Basic program that handles binary data. Remember, there is no other way to handle binary data in Basic so the idea that the Basic string is a Character string is simply incorrect... it's *both* a character and binary string.
A couple of simple tests indicate that some of this may work in spite of what's going on... but it has to work correctly *on purpose* and not by accident.
I haven't had much time to work on it, but consider this example:
Fill a string with chr$(0) to chr$(255). Save the string to a file As Binary. Looking at the file, it is indeed the correct data. Now read the file back and compare each character with Asc(Mid$()) and we find that each Asc returns the expected 0 to 255. If this works for the short string using every possible 8bit character why wouldn't it work for all strings?
Now, maybe I have the "correct" code page set or whatever... what makes it *not* work correctly??
There is *NO REASON* to break Basic strings. The byte array workaround is *not* the answer. It may be worthwhile if someone wants to recode to avoid the processing required for ANSI/UNICODE conversion, but if you break standard string functionality it's going to blow up in your face. I *promise* you it will.
Again, can you give an example of where the Unicode strings don't function (at the Basic language level as shown above) the way they always have?? If so, why can't that case be corrected to work properly?
>>It should be no less useful than it ever was, within the constraints I have mentioned.<<
With all due respect for your background (seriously) you're wrong about this. If developers can't take existing code and have it work unmodified in a high level language like Basic then the language is broken. If this were C or Asm the issue would be straightforward: recode. It isn't. It would be silly to expect consistency with external code (VBX's, DLL's, etc) but consistency of the language is a requirement.
Dan
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Dan Barclay, 72560,2354 Wednesday, February 15, 1995 11:24:18 AM
From: Karl Peterson, 72302,3707 #17260
Hi Dan --
>>Remember, there is no other way to handle binary data in Basic so the idea that the Basic string is a Character string is simply incorrect... it's *both* a character and binary string.<<
But, but, but, haven't you been on the bandwagon with all the rest of us for years over the need for a Byte data type? Isn't this exactly why we wanted it? I think it's high-time this desperate need is filled. Let Strings be what they should be, and let Bytes be fully supported for binary operations. This makes the most sense in the end.
I don't think Unicode is ever gonna go away. It's obviously the way of the future. So, any solution that works around this goliath will at some point, if not immediately, break down. It's time for the switch. I feel that no matter what they do, there's gonna be some sort of special considerations under Win32. Do you really want to maintain seperate code bases for Win16 and Win32?
>>Fill a string with chr$(0) to chr$(255). Save the string to a file As Binary. Looking at the file, it is indeed the correct data. Now read the file back and compare each character with Asc(Mid$()) and we find that each Asc returns the expected 0 to 255.<<
But, the true length of that string is 512! Every other byte is a null. Try converting a multi-byte "field" into a number. You'd need one of Sunil's (excellent!) functions. How many VB'ers are gonna have the wherewithal to come up with those from instinct or memory?
>>There is *NO REASON* to break Basic strings.<<
I think they're broken, perhaps beyond repair. Let's join sides and fight for the *correct* solution!
>>The byte array workaround is *not* the answer.<<
Not as long as that's what it is -- a work-around! If it's put forward as the complete solution, with full support, then it's a panacea!
>>It may be worthwhile if someone wants to recode to avoid the processing required for ANSI/UNICODE conversion,<<
Lead, follow, or get out of the way! <g>
>>if you break standard string functionality it's going to blow up in your face. I *promise* you it will.<<
It certainly will! Right now, it's a gawd-awful mess. The need to maintain seperate parallel function libraries for Win16 and Win32 is unforgivable! But, if Strings are only used for text, and Bytes are only used for binary data, this constriction is gone. This is the way it should be.
>>If developers can't take existing code and have it work unmodified in a high level language like Basic then the language is broken.<<
This goes beyond Basic. The *world* has changed. It's a global village. We need Unicode. Trite? Probably. But, true, nonetheless. And, all the bitchin and moanin in the world is not gonna do anything to change it. A proper solution is very close to being there. It just needs complete implementation.
Later... Karl (not flaming! just trying to reason <g>)
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Karl Peterson, 72302,3707 Wednesday, February 15, 1995 3:00:27 PM
From: Rune Bivrin, 100126,2737 #17271
Karl,
>>
This goes beyond Basic. The *world* has changed. It's a global village. We need Unicode. Trite? Probably. But, true, nonetheless. And, all the bitchin and moanin in the world is not gonna do anything to change it. A proper solution is very close to being there. It just needs complete implementation.
<<
Marvellous!
I've been spending the last ten years trying to work with those "funny" characters above 127. The ONLY language that will allow me to use them for variable names, function names and handles upper/lower case correctly is VB. The problem is that third party VBX:s and DLL:s have this uncanny tendency to mask every damn character with 127, as if the eigth bit hurts.
UNICODE should at long last let this be a thing of the past. Then characters will be characters, and bytes will be bytes. In my opinion the Byte type is one of the best ideas to ever enter the minds of Microsoft.
An additional argument:
If you have "legacy" code that you bring into VB 4, you do it to add functionality not available in previous versions. A few Edit/Replace from String to Byte will be a small effort compared to implementing classes or OCX:s, given that Byte is supported in a rich and consistent way by the language.
åäöÅÖÄ
Rune
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Wednesday, February 15, 1995 11:24:12 AM
From: Karl Peterson, 72302,3707 #17259
Hi Tim --
(Thanks, Chris, for being the pipeline!)
>>I can see you're trying to understand what's going on with Unicode strings, so let me clarify some things for you.<<
Thanks! I *really* do appreciate your participating here. In fact, I'm somewhat humbled to be "arguing" this issue with you.
>>If you try this out with valid text strings, of course you'll find the data was preserved.<<
Yes, I've found this to be generally true. But, of course, the issue isn't really with text, per se. The problem is with *efficient* binary handling. (Please keep in mind that term, efficient, as you read the rest of this message.)
>>But obviously if the string data were actually binary bytes, there is no way to reconstitute each original 16-bit quantity from the 8-bit character we map it to (or possibly two 8-bit characters for DBCS code pages).<<
This is the kind of statement that just leaves me shaking my head. While this is obvious to you, consider that it'll blow away the "average" user. Folks use languages like Basic to avoid thinking about this sort of problem. This is why I keep coming back to stating that the Byte data type needs to be a full-fledged replacement, not a work-around, for handling and processing binary I/O streams.
>>But don't be fooled into thinking that random binary data will survive the translation.<<
While I think I'm coming at this heads up, isn't that a pretty large trap just waiting to be sprung on the unsuspecting? This is the core of the debate. For decades, using the String data type has been the work-around for doing binary. Now, we (finally) have the Byte. I'm just asking that it fulfill its destiny to be the true solution to the hacks we've all grown to know and love. <g>
>>This is where the work-around of using byte arrays comes in. By copying the string into a byte array and writing that (when TR5 is available), there is no translation and the binary image of the string is preserved.<<
It shouldn't be a work-around! Supporting Get/Put in TR5 is wonderful! Now, let's just drop the need entirely to ever have to convert to or from a string except for purposes of display. Doesn't this make sense?
Lacking this sort of support, at the very least, what's needed is a native function to move a string into a byte array. Assignment via parameter coercion is a neat trick, but not practical in "real" apps. Playing with the CVar idea of yours, I like it! I'd like to see a similar method to directly assign a string to a Byte array. The only potential problem I can foresee is the need to preallocate enough storage. But, this is simple enough, and something that's readily graspable. There would be the issue of Unicode/ANSI and which type to consider the source string before assignment. But, again, I think that could work out okay given the StrConv function.
>>Once you have a string that contains binary data, operating on it within Basic should be the same as ever, as long as you use th "B" versions of the string functions (assuming AscB exists for now).<<
Your use of "should" *scares* me. It's gonna make a lot of folks nervous enough to avoid the issue entirely. But, the strongest argument I can mount against this line of reasoning is that there will be absolutely no code-compatibility between the 16- and 32- bit versions! Not only does it break *every* line of code ever written in Basic to handle binary data, but it precludes the use of common routines in Win16 and Win32. Now, we're not talking stuff where this could be expected, such as API/DLL calls. No, this is BASIC, pure and simple.
Who's gonna code for both with this sort of maintenance nightmare? And, for those who do, consider the liklihood of keeping parallel routines functioning the same! My initial understanding of VB4 was that one of the highest priorities was maintaining "code compatability" between 16- and 32-bit versions. This was the reason originally offered by Microsoft (Erick Smith) for not supporting threads in the 32-bit version.
But, consider if Byte arrays supported all the string ops required for binary processing! Now, you're back to one routine for both versions!!! This is how it should be. I say, alter the "B" functions to work with Byte arrays. Or, as Dan predicts <g>, this thing will be the downfall of the language. You're most of the way there. The "correct" data type now exists. Please, *please*, just support it for what it was designed to do.
>>I do not understand this statementat all:
| The string data type is also virtually rendered useless for byte-by-byte work.
| I shudder to think about data types that span several bytes. The required
| gynastics are ridiculous.<<
This was said thinking about reading and writing with strings; having every other byte be 0. Consider the xBase file header. The number of records is stored at offsets 5-8. Reading this into a string buffer would (as you pointed out) corrupt it horribly. We could use StrConv, I suppose, to pack it down from 8 to 4 bytes. But, it sounds from this latest message of yours that I shouldn't "be fooled" into thinking this would work. I dunno. Guess it's just gonna take a *lot* of playing around to really get a feel for it. But, that shouldn't be required for something as basic as this by someone who's used the language for 20 years.
>>It should be no less useful than it ever was, within the constraints I have
mentioned.<<
Those constraints wouldn't exist if the string functions operated on Byte arrays.
>>If there is some difficulty handling binary data within Basic (excluding file I/O and DLL parameters), I do want to hear about specific problems.<<
I'll see what I can discover. You obviously have the advantage on me, as I don't have the most recent software. But, FWIW, I see *major* difficulties ahead in maintaining parallel function libraries for Win16 and Win32. Maybe MS has just given up on Win16? If so, why not just admit it, and drop the 16-bit version? If not, let's do this right!
Again, thank you *very* much for taking the time to listen! I hope we can work this out.
Later... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Tim Paterson, 72740,2456 Tuesday, February 14, 1995 10:08:22 PM
From: Ron Schwarz, 71043,3651 #17231
Tim,
>> I am a VBA developer. I was responsible for the compiler and execution engine for QB4.0, QB4.5, VB1, VB2, and Access Basic 1, and just the execution engine in VBA1(Excel) and VB4. <<
You are much too humble.
You are also responsible for the Falcon/Paterson BIOS (I was a licensee, way back when). You also designed the Paterson HDC (I sold lots of them).
Oh, yeah -- you also wrote MSDOS.
I always wondered where you disappeared to! <g>
Glad to have your input here. Stick around!
Ron
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Tuesday, February 07, 1995 4:37:30 PM
From: GREGG IRWIN, 72450,676 #16462
Hi Chris,
<You guys need to check this out before raising all these flags that it does not work.>
I think our point is that MS says it doesn't work. Since I assume the docs to be correct most of the time I take it to mean that I should change all my code to use Byte arrays instead of strings. If it *does* work correctly, and the docs are wrong, then I'm relying on undocumented behavior. No client I know is going to base mission ciritcal apps on *that*! Do you, as a VB developer, consider this an acceptable solution? Even a viable one considering the tradeoffs? I don't.
I think we need to raise all the flags we can now, before VB hits the streets and it's too late.
Concrete examples of the exact behavior would be great. I think a lot of us (OK, me) may be confused. If there are diagrams that can show us exactly what the formats are (UNI vs ANSI vs DBCS), when they change, and how intrinsic functions "see" the data, that might clear a lot of this up. Or I could be wildy wrong.
--Gregg
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Tuesday, February 07, 1995 11:45:02 PM
From: Paul Cohen, 71076,517 #16500
I don't want to get in the middle of the very interesting discussion but I do have a related question. How do I read the Text into the BYTE array and if I read a TEXT file into a BYTE array how do I get it moved into a String without moving it a character at a time?
In VB3 I used Get to read binary data into the UDT below what happens in VB4?
Type CRD_Record_type
Reserved As String * 6
Position As Long
Flag As String * 1
Index As String * 40
EndOfRecord As String * 1
End Type
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Paul Cohen, 71076,517 Wednesday, February 08, 1995 1:20:08 AM
From: Zane Thomas, 72060,3327 #16506
Paul,
<<<
if I read a TEXT file into a BYTE array how do I get it moved into a String
>>>
Don't worry, MS has decreed that concurrent with the release of Win95 all TEXT files shall be immediately converted to Unicode. <g>
Zane
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Thursday, February 02, 1995 3:55:07 PM
From: Karl Peterson, 72302,3707 #16041
Hi Chris --
>>Comments, flames welcome as always.<<
And, as always, happy to oblige! <g>
>>A UNICODE character is two bytes. This allows VB and all the other
applications to work globally, not just in English. What you are suggesting
is a single byte data type which is what we added.<<
The core problem is that none of the old string functions work with this new data type. How is MS proposing we load a 32K buffer of data from a file? Why weren't Get and Put set up to work with byte arrays? Should a WinBug be submitted? Is there really any use?
What MS *must* do is provide all the string manipulation tools that were once available for this new data type. Instr() should return the index of the first byte that matches. Mid() should be able to replace or return a series of bytes. We've lost one of the most powerful tools we had. In one sense, strings are what made Basic great! Now, they're gone. :-(
Later... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Karl Peterson, 72302,3707 Thursday, February 02, 1995 5:13:25 PM
From: Chris Dias [MSFT], 74441,137 #16053
Hi Karl -
This is the same mail I sent Dan...
-----------------------------------------------------------------------------
How much would you pay in performance for ANSI strings?? 25%? 50%?
We >went< to UNICODE strings so that we could work with all of our
components. That means OLE, DAO, Controls, etc. So, if we didn't go UNICODE
then where would performance be you ask? 7x slower. Yep.
So, the implications of converting UNICODE-ANSI-UNICODE in calling DLLs and
the performance lost there is minimal compared to being ANSI and working with
the other components of VB.
Yes, We (Microsoft) can be ANSI but we chose not to be because of
performance. We shielded the pains of migrating to 32bit as much as possible
- imagine if you were writing C applications and the work that you would need
to do to move to 32bits... its enormous.
Also, VB is in countries that use Double Byte OSs - if we didn't do this then
applications could not be localized... think of how many applications you
could sell all over the world.
We could have stayed ANSI but we decided to go UNICODE. We tried to make it
as painless as possible for developers to port their applications to 32bit
but in a lot of situations its NOT as easy as recompiling. Ask anyone who
has moved their C apps to 32bit. You can write code in 32bit, its just going
to take a little work to get there.
There isn't anything else I can (or will) add about this. These are the
reasons why - we've provided the byte data type for all single byte
processing.
Chris
- Microsoft Developer Support
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Friday, February 03, 1995 10:56:04 AM
From: Karl Peterson, 72302,3707 #16128
Hi Chris --
>>This is the same mail I sent Dan...<<
Saw it. <g>
>>There isn't anything else I can (or will) add about this. These are the reasons why - we've provided the byte data type for all single byte processing.<<
I sincerely understand the "reasons why". What I don't understand is why the issue of the byte data type being a non-solution aren't being addressed. I don't care if they're called bytes or strings or unistrings. What I care about is I have no way to fill a byte array other than one byte at a time!
Broken record time. WHY don't Instr, Mid, Get, Put work with Byte arrays?????? This is a BUG. You can't say that this data type has been provided for binary processing if you don't provide binary operators! C'mon, Chris, I'm being *constructive* here. Please address this issue. Is it MS' intent that we resort to the API to load a binary buffer? Will there be no replacement for this stolen functionality?
I see now why everything is being named XX95. The number 4 is truly cursed for MS, isn't it? You've got a DOS 4 on your hands here. Ain't *no one* gonna buy it, because it's broke beyond belief if binary processing is gone. The *only* way Byte arrays will be accepted as a replacement for strings is if they're made functionally compatible. Period.
Later... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Karl Peterson, 72302,3707 Monday, February 06, 1995 7:02:09 PM
From: Chris Dias [MSFT], 74441,137 #16394
Hi Karl -
>>>I sincerely understand the "reasons why". What I don't understand is why
the issue of the byte data type being a non-solution aren't being addressed.
I don't care if they're called bytes or strings or unistrings. What I care
about is I have no way to fill a byte array other than one byte at a time!
<<<
Yep, its a problem and I'm looking into it.
>>>Broken record time. WHY don't Instr, Mid, Get, Put work with Byte
arrays?????? This is a BUG. You can't say that this data type has been
provided for binary processing if you don't provide binary operators! C'mon,
Chris, I'm being *constructive* here. Please address this issue. Is it MS'
intent that we resort to the API to load a binary buffer? Will there be no
replacement for this stolen functionality?
<<<
Submit a WinBug report on this and I'll submit it.
Chris
- Microsoft Developer Support
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Tuesday, February 07, 1995 5:46:11 AM
From: Tom Kiehl, 73215,427 #16413
Chris,
Here's some food for thought. (I haven't tried it... I've gotta make room on one of these machines for 32 bit).
First I'm assuming that both 16 and 32 bit versions will be able to speak with the *same* database in all formats i.e Access, xBase, etc. (as one must assume they must).
What gets read to/written from text fields?
If strings are unicode in 32 bit, they'd need to be saved as unicode, right?
If so, what does the 16 bit program see when it reads (and writes) this unicode field?
With a 255 max length for a text field, is this 255 characters or 255 bytes.
Tom
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Tuesday, February 07, 1995 10:35:21 AM
From: Karl Peterson, 72302,3707 #16438
Hi Chris --
>>Yep, its a problem and I'm looking into it.<<
Hey! Now we're getting somewhere! I never expected the transition to 32-bit to be painless. In fact, I've grown to expect it to be *more* painful than the transition from DOS to Windows. But, at the least we need these operators. I'm sorry that a lot of code will most likely be broken, but I sort of tend to feel that apps *should* be rewritten for the transition to take maximum advantage of the new environment. BTW, that brings up the subject of threads... <g>
>>Submit a WinBug report on this and I'll submit it.<<
Comin' at ya!
Later... Karl
Subj: THEY'RE NOT STRINGS!!! Section: VBA/Prog. Issues
To: Chris Dias [MSFT], 74441,137 Saturday, February 04, 1995 12:01:29 AM
From: Pete Roberts, 76060,2006 #16181
Chris -
If VB4 is an upgrade to VB3, MS can NOT change how the String datatype works. Since the new 32-bit OSs require UNICODE data, define a new datatype called 'Unicode', which works exactly how the VB4 String datatype works NOW, and make the String datatype work as it did in VB3.
Any other decision causes VB4 to be a new language, not an upgrade to VB3. Just because there have been bad 'upgrade' decisions in the past, which required you, me, and others a lot of heartache and lots of extra work, doesn't mean that these bad decisions were good decisions.
Isn't it possible for us to learn from history? "I did X in the past and it hurt, so maybe I won't do X again."
The only rational decision for MS to make is for VB4 to be an upgrade to VB3. This is not now the case, and steps must be taken to get VB4 back on track.
Pete Roberts
|
