Re: How to write Binary data using VBScript?

[Richard Mueller [MVP]]

Srinivas Koppisetti wrote:

> I need to dump some birary blogs into a biary file.
> How do I perform R/W operations on binary files using VB Script.
>
> - I checked FileSystemObject but it not supporting binary mode. (I may be
> wrong!)

Hi,

Check out the ADODB.Stream object:

http://support.microsoft.com/default.aspx?scid=kb;en-us;258038
http://support.microsoft.com/default.aspx?scid=kb;en-us;276488

--
Richard
Microsoft MVP Scripting and ADSI
Hilltop Lab web site - http://www.rlmueller.net
--

[D.R.]

Here's some code that reads and writes binary data. Not that it uses
process page space, so big files (i.e. bigger than free RAM) will cause a
lot of swapping and will take an absolute age to run. When the files are
small, it's quite quick.

Does anyone know how to handle very large files?

Cheers,
Dave.

Option Explicit
On Error Resume Next
'*************************************************************************************************************************
' Vers Date Who Description
' ---- ---- --- -----------
' v0.01 31-AUG-2004 DR First version.
'*************************************************************************************************************************

Const adTypeBinary = 1
Const adSaveCreateOverWrite = 2
Const c_title = "append parts v0.01"

Dim g_wsh, g_fso, g_inp, g_out
Dim o_folder, o_files, o_file
Dim l_folder, l_file, l_max, l_cnt, l_done, l_dum, l_default, l_output,
l_found, l_err

Set g_wsh = WScript.CreateObject( "WScript.Shell" )
Set g_fso = Wscript.CreateObject( "Scripting.FileSystemObject" )

l_default = g_wsh.CurrentDirectory

Select Case f_browse( c_title, l_folder )
Case vbOK
Case vbCancel
MsgBox "Script cancelled by user... quitting",, c_title
WScript.Quit
Case Else
MsgBox "Obscure return value from f_browse... quitting...",, c_title
Wscript.Quit
End Select

Set o_folder = g_fso.GetFolder( l_folder )
Set o_files = o_folder.Files

Set g_inp = WScript.CreateObject( "ADODB.Stream" )
Set g_out = WScript.CreateObject( "ADODB.Stream" )
g_inp.Type = adTypeBinary
g_out.Type = adTypeBinary

l_cnt = 0
l_max = 0
For Each o_file In o_files
l_file = o_file.Name
If Right( l_file, 5 ) = ".part" Then
If o_file.Size = 9728000 Then
l_cnt = l_cnt + 1
l_dum = Split( l_file, "." )
If IsNumber( l_dum( 1 ) ) Then
If CInt( l_dum( 1 ) ) > l_max Then
l_max = CInt( l_dum( 1 ) )
End If
End If
End If
End If
Next
If l_cnt = 0 Then
MsgBox "Did not find any files to append in folder path `" & l_folder &
"`",, c_title
WScript.Quit
End If
g_wsh.Popup "Found " & CStr( l_cnt ) & " files, max part number is " &
CStr( l_max ), 5, c_title

g_out.Open

l_found = 0
l_done = 0
For l_cnt = 1 To l_max
l_file = l_folder & "\1." & CStr( l_cnt ) & ".part"
If g_fso.FileExists( l_file ) Then
Set o_file = g_fso.GetFile( l_file )
If o_file.Size = 9728000 Then
l_found = l_found + 1
g_inp.Type = adTypeBinary

Err.Clear
g_inp.Open
If Err.Number <> 0 Then
l_err = CStr( Err.Number ) & " " & Err.Description
MsgBox "unexpected error" & vbCrlf & " " & l_err & vbCrlf & " for file
" & l_file,, c_title
Exit For
End If

Err.Clear
g_inp.LoadFromFile l_file
If Err.Number <> 0 Then
g_inp.Close
Else
g_inp.CopyTo g_out
g_inp.Close
l_done = l_done + 1
End If

End If
End If
Next

If l_done = 0 Then
g_out.Close
MsgBox "No files of the correct size were found, or they were all
locked.",, c_title
Else
l_output = l_default & "\z.z"
g_out.SaveToFile l_output, adSaveCreateOverWrite
g_out.Close
MsgBox "Done " & CStr( l_done ) & " files of " & CStr( l_found ) & ", and
created " & l_output,, c_title
End If

Set g_inp = Nothing
Set g_out = Nothing

WScript.Quit

Function f_browse( p_title, p_folder )
On Error Resume Next

Const BIF_ReturnOnlyFsDirs = &H0001
Const BIF_DontGoBelowDomain = &H0002
Const BIF_StatusText = &H0004
Const BIF_ReturnFsAncestors = &H0008
Const BIF_EditBox = &H0010
Const BIF_Validate = &H0020
Const BIF_NewDialogStyle = &H0040
Const BIF_NoNewFolder = &H0200
Const BIF_BrowseForComputer = &H1000
Const BIF_BrowseForPrinter = &H2000
Const BIF_BrowseIncludeFiles = &H4000

Const BSF_desktop = 0 'With BIF_returnonlyfsdirs circumvents problem with
OK-button
Const BSF_internetexplorer = 1 'Internet Explorer is the root
Const BSF_programs = 2 'Programs folder of the start menu is the root
Const BSF_controlpanel = 3 'Control Panel is the root Needs
BIF_browseincludefiles
Const BSF_printers = 4 'Printers folder is the root Needs
BIF_browseincludefiles
Const BSF_documents = 5 'Documentsfolder is the root
Const BSF_favorites = 6 'Favorites is the root
Const BSF_startup = 7 'Startup-folder of the startmenu is the root. Needs
BIF_browseincludefiles
Const BSF_recent = 8 'Recentfolder is the root Needs
BIF_browseincludefiles
Const BSF_sendto = 9 'Sendto-folder is the root Needs
BIF_browseincludefiles
Const BSF_recyclebin = 10 'Recycle Bin is the root Needs
BIF_browseincludefiles
Const BSF_startmenu = 11 'Start Menu is the root
Const BSF_desktopdirectory = 16 'The desktop directory is the root directory
Const BSF_drives = 17 'The drives (My computer) folder is the root
Const BSF_network = 18 'The network neighbourhood is the root
Const BSF_nethood = 19 'The nethood folder is the root
Const BSF_fonts = 20 'The fonts folder is the root
Const BSF_templates = 21 'The templates folder is the root
Const BSF_commonprograms = 22
Const BSF_commonstartup = 23
Const BSF_commondesktopdir = 24
Const BSF_appdata = 26
Const BSF_printhood = 27
Const BSF_localappdata = 28
Const BSF_altstartup = 29
Const BSF_commonaltstartup = 30
Const BSF_commonfavorites = 31
Const BSF_internetcache = 32
Const BSF_cookies = 33
Const BSF_history = 34
Const BSF_commonappdata = 35
Const BSF_windows = 36
Const BSF_system = 37
Const BSF_programfiles = 38
Const BSF_mypictures = 39
Const BSF_profile = 40

Dim o_app, o_wsh, o_fso
Dim o_folder, o_path, l_bif, l_folder, l_done, l_err, l_debug

l_debug = False
p_folder = ""
f_browse = vbCancel

Set o_wsh = WScript.CreateObject( "WScript.Shell" )
Set o_fso = Wscript.CreateObject( "Scripting.FileSystemObject" )
Set o_app = WScript.CreateObject( "Shell.Application" )

l_bif = 0
l_bif = l_bif Or BIF_EditBox Or BIF_NewDialogStyle Or BIF_NoNewFolder Or
BIF_Validate Or BIF_ReturnOnlyFsDirs
l_bif = l_bif Or BIF_StatusText

l_done = False
Do
Err.Clear
Set o_folder = o_app.BrowseForFolder( 0, p_title, l_bif, BSF_Drives )
l_err = Err.Number
If l_err <> 0 Then
MsgBox "f_browse:a: unexpected error " & CStr( l_err ),, p_title
Exit Function
Elseif IsNull( o_folder ) Then
If l_debug Then MsgBox "f_browse: null returned",, p_title
Exit Function
Elseif o_folder = Null Then
If l_debug Then MsgBox "f_browse: result = null",, p_title
Exit Function
Elseif Not( IsObject( o_folder ) ) Then
If l_debug Then MsgBox "f_browse: not an object",, p_title
Exit Function
Else
Err.Clear
Set o_path = o_folder.Items.Item
l_err = Err.Number
If l_err <> 0 Then
MsgBox "f_browse:b: unexpected error " & CStr( l_err ),, p_title
Exit Function
Else
l_folder = o_path.Path
If Not( o_fso.FolderExists( l_folder ) ) Then
MsgBox "An invalid folder was selected. Try again or hit
`Cancel`.",, p_title
Else
l_done = True
End If
End If
End if
Loop Until l_done
p_folder = l_folder
f_browse = vbOK
If l_debug Then MsgBox "f_browse: normal exit from function, selection is `"
& l_folder & "`",, p_title
End Function

[Christoph Basedau]

27.05.2005 01:10, Srinivas Koppisetti schrieb:
>
> I need to dump some birary blogs into a biary file.
> How do I perform R/W operations on binary files using VB Script.
>
> - I checked FileSystemObject but it not supporting binary mode. (I may be
> wrong!)

You can write binary files with fso if you write them byte by byte,
one 'char' only for one call of the textstream.Write method.
For example you can write an exe-file like that.
Using RegExp, String Functions like Instr, Replace, Mid, .. and the &-op may
fail with binary data (Ascii-Nulls truncate strings).

Set fs = CreateObject("Scripting.FileSystemObject")
windir = fs.GetSpecialFolder(0).path
strFile1 = windir & "\notepad.exe"
strFile2 = "C:\np.exe"

Set reader = fs.OpenTextFile(strFile1, 1, false)
Set writer = fs.OpenTextFile(strFile2, 2, true)

while reader.AtEndOfStream <> true
writer.write reader.read(1)
wend

writer.close
reader.close
'show this script with new copy of notepad.exe
CreateObject("WScript.Shell").Run _
strFile2 & " """ & WScript.ScriptFullName & """"

--
Gruesse, Christoph

Rio Riay Riayo - Gordon Sumner, 1979

[mayayana]

It doesn't have to be done 1 byte at a time.
If you use a specific read length you'll get a string
that can be rewritten or otherwise processed as
binary data. Nulls are the only issue. A text file is,
after all, a binary file.

Example demo:

'-- A zip file has been renamed to test.dat.
'-- The following script successfully reads the binary data in test.dat
'-- and writes it to a new file, test.zip. Success can be confirmed
'-- by the fact that the new zip file is uncorrupted and contains
'-- the same files as were in the original zip.

Dim FSO, TS, s, oFil, L
Set FSO = CreateObject("Scripting.FileSystemObject")

'-- get length of file because ReadAll may fail with
'-- binary data that contains nulls.
Set oFil = FSO.GetFile("C:\windows\desktop\test.dat")
L = oFil.Size
Set oFil = Nothing

Set TS = FSO.OpenTextFile("C:\windows\desktop\test.dat")
s = TS.Read(L)
TS.Close
Set TS = Nothing

Set TS = FSO.CreateTextFile("C:\windows\desktop\test.zip", True)
TS.write s
TS.Close
Set TS = Nothing

--
--
Christoph Basedau <e_t...@hotmail.com> wrote in message
news:42990a57$0$14737$9b4e...@newsread4.arcor-online.net...

[Christoph Basedau]

29.05.2005 04:26, mayayana schrieb:

> It doesn't have to be done 1 byte at a time.
> If you use a specific read length you'll get a string
> that can be rewritten or otherwise processed as
> binary data. Nulls are the only issue. A text file is,
> after all, a binary file.

Hi mayayana,

Thanks for your advice.
It's quite amazing (but true) that:
stream.Read(fullSizeOfFile)
seems to build a different kind of string then:
stream.ReadAll()
although both buffers have the same size and derive from the same
source. Probably has somthing to do with ReadAll stop reading properly
when encountering the first Null.

set fs = createobject("scripting.filesystemobject")
set np = fs.GetSpecialFolder(0).files("notepad.exe")
str1 = np.OpenAsTextStream(0).ReadAll()
str2 = np.OpenAsTextStream(0).Read(np.size)
wscript.echo Len(str1), Len(str2), np.size, strcomp(str1, str2, 0)

[mayayana]

> It's quite amazing (but true) that:
> stream.Read(fullSizeOfFile)
> seems to build a different kind of string then:
> stream.ReadAll()
> although both buffers have the same size and derive from the same
> source. Probably has somthing to do with ReadAll stop reading properly
> when encountering the first Null.
>

Yes. I just happened to discover that one time.
I think it is as you say: Apparently ReadAll is calling
something else to do the work, then it just looks for a
null marker in the string it gets back. I suppose that
the Read function is equally primitive, but that ends
up being an advantage - it doesn't interfere when you
try to read nulls because it's just blindly counting the
bytes requested.

[Joe Earnest]

Hi

"mayayana" <mayaXX...@mindYYspring.com> wrote in message
news:83Nne.12006$uR4....@newsread2.news.atl.earthlink.net...
...

On the off chance that you haven't seen this, thought you might find it
interesting.

http://blogs.msdn.com/ericlippert/archive/2005/04/20/410127.aspx

Regards,
Joe Earnest

[mayayana]

Thanks Joe, I hadn't seen that. (I often find those
"scripting guys" to have interesting information,
but I have a hard time concentrating on their articles
given the odd mix of highly technical talk with their
hammy and glib conversational style of writing.)

I guess I should drop by and catch up on their latest
posts once in a while.

If I understood that piece correctly, he's saying
that there will be limitations handling some 128+ bytes
on any system that's using 2-byte ANSI characters in
their default code page. (Japan, China and Korea?)
It doesn't sound like enough of an issue to worry
about in normal usage, but it's an interesting
aspect that I never would have thought of.

(Though even in Japan the problem would only be with
using something like Chr(224). A 224 byte within
a string wouldn't cause a problem, since TextStream
is clearly not looking at the bytes in the string that it
writes.)

I assume the ADODB.Stream doesn't have that
limitation, but that question was never answered in
the article. I've avoided ADODB myself because I
try to avoid anything that's not on all systems. (In fact
I don't even have the version with Stream (2.6?) installed
myself. I've just never needed it for anything and it's
not on 98SE by default.)

--
--
Joe Earnest <jearnes...@earthlink.net> wrote in message
news:uUMbJK9Z...@TK2MSFTNGP10.phx.gbl...

[Joe Earnest]

Hi Joe,

[interlineated]

"mayayana" <mayaXX...@mindYYspring.com> wrote in message

news:YxOne.12064$uR4....@newsread2.news.atl.earthlink.net...

> Thanks Joe, I hadn't seen that. (I often find those
> "scripting guys" to have interesting information,
> but I have a hard time concentrating on their articles
> given the odd mix of highly technical talk with their
> hammy and glib conversational style of writing.)

I'm glad someone else here finds this trait annoying, too. There's actually
a philosophical and psychological approach to this type of jargon, that
switches frequently between narrow logic and almost meaningless cliche that
has social, but no intellectual, significance (self-masking, defensive,
defeats conversation, etc.), but I won't go into that now. One can still
pull bits of information out of it.

>
> I guess I should drop by and catch up on their latest
> posts once in a while.
>

This one is Eric Lippert's Blog: Fabulous Adventures In Coding. I find it
more useful than most.

http://blogs.msdn.com/ericlippert/

Like the other blogs, it's often unfocused or just plain "curious". But
when it's on target, it can be very informative. The earlier blogs tended
to be more informative than some of the later ones. Very useful, sometimes,
to get the perspective of the person who wrote much of the underlying VBS
code. Very thorough explanation of syntax issues.

> If I understood that piece correctly, he's saying
> that there will be limitations handling some 128+ bytes
> on any system that's using 2-byte ANSI characters in
> their default code page. (Japan, China and Korea?)
> It doesn't sound like enough of an issue to worry
> about in normal usage, but it's an interesting
> aspect that I never would have thought of.
>
> (Though even in Japan the problem would only be with
> using something like Chr(224). A 224 byte within
> a string wouldn't cause a problem, since TextStream
> is clearly not looking at the bytes in the string that it
> writes.)

It certainly arises with any 2-byte ANSI or unicode text.

The impression I had was that the issue arises with some code pages, even
with single-byte 128+ characters, because of the way the code page handles
the character. Lippert's main point was that, with text techniques, you
can't avoid code-page handling issues.

>
> I assume the ADODB.Stream doesn't have that
> limitation, but that question was never answered in
> the article. I've avoided ADODB myself because I
> try to avoid anything that's not on all systems. (In fact
> I don't even have the version with Stream (2.6?) installed
> myself. I've just never needed it for anything and it's
> not on 98SE by default.)
>

And, as the blog points out, ADODB is now considered by some as a security
risk suppressed through IE on some systems.

Regards,
Joe Earnest

[mayayana]

> [interlineated]

Oooh. That's a nice word. I've never seen it before.

>
> It certainly arises with any 2-byte ANSI or unicode text.
>
> The impression I had was that the issue arises with some code pages, even
> with single-byte 128+ characters, because of the way the code page handles
> the character. Lippert's main point was that, with text techniques, you
> can't avoid code-page handling issues.
>

He specifically referred to it as a DBCS problem, though.
I'm no expert on programming for different languages, but I think
the way it works is that for Western Hemisphere languages,
in general, 1 byte is enough to get all the characters, and as
long as it's one byte ANSI there should be no problems. The
Chr function will deal with it. His example was only showing that
in some cases on a DBCS system, a single byte is actually
functioning as a kind of operator rather than as a character,
and that therefore the Chr function will produce unexpected
results. Aside from that kind of issue, text still is just bytes, after
all.

I was realizing after my last post, though, that part of what
was bugging me about the writing style of that article is that Eric
Lippert is writing from an emotional point of view. It's understandable
that he identifies with VBS as "his baby", but it's nevertheless
problematic as well. His piece on FSO for binary had a
protective and possessive attitude at its root, using screwball
statements like "Please don't do it." (a moral directive!) and "it
doesn't work" (false), instead of just clearly explaining the issue.

(Isn't this the same guy who got inexplicably worked up
over the issue of "Set x = Nothing" a couple of months ago,
saying adamantly that it *shouldn't* be used? I remember
having a debate about that here.)

By the end of his piece it's clear that using FSO for binary
bothers him, but it's not clear exactly what the limitations are.
I would expect that it won't be a problem in any European language.
It may even only require minimal workarounds in Japanese, but I
suspect that Eric is not going to tell us if that's the case. :)

It would be interesting to hear from people using other languages.
On the other hand, can a Japanese system even use a script
written in English? Do they use Anglicized characters to write
out FileSystemObject, or do they have a Japanese version
of SCRRUN.DLL? Can an English script run on a German or
French system without editing? I don't know. Another interesting
question (for which I have no idea of the answer) is what percentage
of foreign language Windows users are using an English code page
for convenience?

I have several scripts on my site that use Textstream binary
to get File Version information and extract icons, among other
things. So far I haven't heard from anyone who's had trouble with
them, but I don't know how many of my visitors are actually
scripting in something other than English.

[mayayana]

There was an interesting article linked from Eric
Lippert's article, about the history of character
encoding:

http://www.joelonsoftware.com/articles/Unicode.html

(Joel Spolsky. He's another one from the Dave Barry
school of technical writing.)

It explains a lot about the variations in encoding
but doesn't get into much detail about specific
languages.
In VB and VBA in a Nutshell, under Chr, it says that
"Chr returns the character associated with an ASCII or ANSI
character code." Chr seems to have no problem with
unused values, like 141 through 144 in English.
So it seems that having an internationalized version
of Textstream binary would only require creating
workarounds for operator characters on DBCS systems -
recognizing when those numeric values come through
and dealing with them accordingly.

Of course it would be much easier to just use a component,
but the ability to use Textstream for binary adds lots of
new abilities that are then universal to WSH, rather than
just shared between a few people.

[Joe Earnest]

Hi Joe,

Well, if you liked the last one, how about ....

[interspersed]

"mayayana" <mayaXX...@mindYYspring.com> wrote in message

news:JM6oe.13465$M36....@newsread1.news.atl.earthlink.net...

>
>
>> [interlineated]
>
> Oooh. That's a nice word. I've never seen it before.

Habit, not necessarily vocabulary. Used a lot in editing.

>
>>
>> It certainly arises with any 2-byte ANSI or unicode text.
>>
>> The impression I had was that the issue arises with some code pages, even
>> with single-byte 128+ characters, because of the way the code page
>> handles
>> the character. Lippert's main point was that, with text techniques, you
>> can't avoid code-page handling issues.
>>
> He specifically referred to it as a DBCS problem, though.
> I'm no expert on programming for different languages, but I think
> the way it works is that for Western Hemisphere languages,
> in general, 1 byte is enough to get all the characters, and as
> long as it's one byte ANSI there should be no problems. The
> Chr function will deal with it. His example was only showing that
> in some cases on a DBCS system, a single byte is actually
> functioning as a kind of operator rather than as a character,
> and that therefore the Chr function will produce unexpected
> results. Aside from that kind of issue, text still is just bytes, after
> all.
>

I concur.

> I was realizing after my last post, though, that part of what
> was bugging me about the writing style of that article is that Eric
> Lippert is writing from an emotional point of view. It's understandable
> that he identifies with VBS as "his baby", but it's nevertheless
> problematic as well. His piece on FSO for binary had a
> protective and possessive attitude at its root, using screwball
> statements like "Please don't do it." (a moral directive!) and "it
> doesn't work" (false), instead of just clearly explaining the issue.
>

Nice catch.

One of my favorite areas. Human written language is a lot richer and more
fun than computer "languages", and face-to-face spoken language is even
richer, with all the inflections and facial and body gestures. We tell each
other what is really important to us, by gestures, inflections, phrases, and
implicit or explicit metaphors, even while discoursing on another level or
within logical strictures. The fatal problem for all the curious strain of
logicians who have tried to turn language into tokenized logic, is that the
primary use of language is *not* to convey abstract information, but to
establish social ties and recognition of boundaries, need and trust.
Language wasn't created (50,000 years ago or so) for conveying abstract
information, and has never been used primarily for that reason. Ambiguity
is good -- it's the only way that a personal view of one person can be
adopted by another person with a different perspective. Conveyance of
abstract information is a tiny fraction of the use of language -- of course,
when communication of abstract information is required, it needs to be done
well.

You'd enjoy philosophical linguistic analysis. Here's a biggie word --
"Hermeneutics". Don't expect a decent dictionary definition. Began in the
18th century as scriptural analysis. Developed in Germany in France in the
19th and early 20th centuries as a way of philosophically analyzing historic
data, and by the latter part of that period, modern philosophical argument.
It's a cornerstone of post-modernism, and has been there merged with the
English-Austrian analytic linguistic philosophy of Wittgenstein, Ayers, et
al. and psychological concepts (unfortunately, primarily either Freudian or
Jungian, not Jamesian or modern pragmatic).

In areas that have meaning (philosophy, science, social concerns, theology,
etc.), the modern analytic linguistic (or much more so, and with a twist,
post-modern) approach is first to analyze the "presentation" or "document"
in the course of the "conversation" for the unstated presumptions, needs,
goals, etc., or more fundamentally, the bedrock "origin" concepts, on the
basis that all speech is *human* speech involving *human* aspects, even when
abstracted or guided by logic. The trick at this level is to balance the
unstated (or, more correctly, not explicitly stated, which in post-modernism
can be obtained through historical sources outside the "document") versus
the stated. This is the point where much of the controversy over the
alleged "absolute relativism" of post-modernism occurs (which the new Pope
has recently raised again on the world stage with regard to scriptural
interpretation).

Ah, but I might have digressed a bit.

I have no concept of what it's like to work inside MS. One could conjecture
that the fact that VBS is not going forward, could, from a purely MS
corporate approach, not be a feather in Lippert's cap, however unfair or
misguided that may be. At the very least, he no longer has the opportunity
to correct things that he sees as potentially leading to problems.

> (Isn't this the same guy who got inexplicably worked up
> over the issue of "Set x = Nothing" a couple of months ago,
> saying adamantly that it *shouldn't* be used? I remember
> having a debate about that here.)
>

I missed that one. (I was away from the NG for about 9 months or so.) I'll
go back and look for it. Of couse, the "Nothing" keyword(?) is thoroughly
unnecessary, but I can't imagine why it could cause a problem. That should
be an interesting thread.

> By the end of his piece it's clear that using FSO for binary
> bothers him, but it's not clear exactly what the limitations are.
> I would expect that it won't be a problem in any European language.
> It may even only require minimal workarounds in Japanese, but I
> suspect that Eric is not going to tell us if that's the case. :)
>
> It would be interesting to hear from people using other languages.
> On the other hand, can a Japanese system even use a script
> written in English? Do they use Anglicized characters to write
> out FileSystemObject, or do they have a Japanese version
> of SCRRUN.DLL? Can an English script run on a German or
> French system without editing? I don't know. Another interesting
> question (for which I have no idea of the answer) is what percentage
> of foreign language Windows users are using an English code page
> for convenience?
>
> I have several scripts on my site that use Textstream binary
> to get File Version information and extract icons, among other
> things. So far I haven't heard from anyone who's had trouble with
> them, but I don't know how many of my visitors are actually
> scripting in something other than English.
>
>

From Lippert's broad-MS perspective (I further dangerously presume), VBS is
used on websites that might well be accessed by people using other code
pages, or for far-flung networks. When used one place, it's copied and
imported into another place, and so on ... It would be far nicer, from that
perspective, to not have local code-page issues.

Regards,
Joe Earnest

[Joe Earnest]

Hi again,

[interlineated]

"mayayana" <mayaXX...@mindYYspring.com> wrote in message

news:itioe.13737$M36....@newsread1.news.atl.earthlink.net...

>
> There was an interesting article linked from Eric
> Lippert's article, about the history of character
> encoding:
>
> http://www.joelonsoftware.com/articles/Unicode.html
>
> (Joel Spolsky. He's another one from the Dave Barry
> school of technical writing.)

Actually, the "stuff" at the outset is just commercial "screaming". In the
marketplace, it's common to "scream" for attention with terribly
over-emphasized remarks, whether dire or humorous.

Once past that, a remarkably good article -- thanks for the reference. It's
goes beyond my prior understanding of how unicode developed.

BTW, did you notice from the that the little resume on the left that the
author was the "keynote speaker at ... the Cold Fusion developer
conference." ;-)

>
> It explains a lot about the variations in encoding
> but doesn't get into much detail about specific
> languages.
> In VB and VBA in a Nutshell, under Chr, it says that
> "Chr returns the character associated with an ASCII or ANSI
> character code." Chr seems to have no problem with
> unused values, like 141 through 144 in English.
> So it seems that having an internationalized version
> of Textstream binary would only require creating
> workarounds for operator characters on DBCS systems -
> recognizing when those numeric values come through
> and dealing with them accordingly.
>

Yes, but -- all string values in VB and VBS are internally stored in 2-byte
unicode, based on the page code. This creates a pitfall for non-English
128+ characters, so storage in a string (even a transitory string) needs to
be avoided. I believe that the Chr function has to create a transitory
string to hand the character back to the calling script.

> Of course it would be much easier to just use a component,
> but the ability to use Textstream for binary adds lots of
> new abilities that are then universal to WSH, rather than
> just shared between a few people.
>
>

Works for me in my local scripts. Again, however, I think that Lippert
would say that American English code pages are not "universal".

Regards,
Joe Earnest

[Joe Earnest]

> Yes, but -- all string values in VB and VBS are internally stored in
> 2-byte unicode, based on the page code. This creates a pitfall for
> non-English 128+ characters, so storage in a string (even a transitory
> string) needs to be avoided. I believe that the Chr function has to
> create a transitory string to hand the character back to the calling
> script.
>

To clarify, I think you're correct, so long as both

(1) the full transaction takes place under the same or similar code page
(i.e., string data is not being transferred or stored so that string data
derived from one code page may be misinterpreted under another code page);
and

(2) the transaction occurs on a code page with single-byte ANSI values.

Regards,
Joe Earnest

[mayayana]

> BTW, did you notice from the that the little resume on the left that the
> author was the "keynote speaker at ... the Cold Fusion developer
> conference." ;-)
>

He does seem to be well known, but I don't
know the significance of the Cold Fusion
connection. (I don't know what Cold Fusion is. I
would have guessed that it was a WYSIWYG
HTML editor, but I actually have no idea.)

> Yes, but -- all string values in VB and VBS are internally stored in
2-byte
> unicode, based on the page code. This creates a pitfall for non-English
> 128+ characters, so storage in a string (even a transitory string) needs
to
> be avoided. I believe that the Chr function has to create a transitory
> string to hand the character back to the calling script.
>

I'm not too clear on that part. In English, Unicode
characters are just ANSI characters with null bytes.
Maybe that's not true in other languages? I got the impression
from Splosky's piece that all known characters have been
assigned a unicode code point. So I guess that something
like particular Greek or Russian characters might be, say,
55 in the local ANSI codepage but maybe 1242 in unicode.

I'm not certain but I don't think that would matter for binary,
since it's being treated as all ASCII characters (and the
unicode translation would then still be to add a null since
44 in unicode is still 44....and therefore the VB internal translation
back to ANSI would not alter anything). Maybe that's what you're
implying in your follow-up post.

[mayayana]

>
> Well, if you liked the last one, how about ....
>
> [interspersed]

Ah, that one's old hat. :)

Isn't this kind of analysis that you describe still another
version of what you refer to as reducing language to
"tokenized logic"? Fully analyzing the meaning, leaving
nothing to "unscientific" intuition, is necessarily a reduction
to mechanics, with the interpretation of unstated assumptions
being, itself, based upon unstated assumptions. (I guess
that's the fatal flaw of science: It has no way of knowing what it
can't know, always presuming to be perceiving "objectively",
and therefore ends up wandering into areas like psychology,
philosophy and ontology where it has no business going and
has nothing to offer.)

In any case, I'm not familiar with hermeneutics. If you're referring to
something other than the nihilistic materialist masturbations of the
Derrida/Deconstructionist cult then I'd be interested in a list of
names/books to look into. (I'm not familiar with Wittgenstein and
Ayers. You seem to be familiar with some kind of vaguely defined
philosophical school here that I don't know about.)

> I missed that one. (I was away from the NG for about 9 months or so.)
I'll
> go back and look for it. Of couse, the "Nothing" keyword(?) is thoroughly
> unnecessary, but I can't imagine why it could cause a problem. That
should
> be an interesting thread.
>

It was quite lively. It might be in the m.p.s.wsh group rather
than the m.p.s.vbscript group.

[Joe Earnest]

Hi,

"mayayana" <mayaXX...@mindYYspring.com> wrote in message

news:iAtoe.14018$M36....@newsread1.news.atl.earthlink.net...
>

{snipped]

>
> I'm not too clear on that part. In English, Unicode
> characters are just ANSI characters with null bytes.
> Maybe that's not true in other languages? I got the impression
> from Splosky's piece that all known characters have been
> assigned a unicode code point. So I guess that something
> like particular Greek or Russian characters might be, say,
> 55 in the local ANSI codepage but maybe 1242 in unicode.
>

Per the article, Asian languages required a DBCS double-byte assignment, in
lieu of ANSI, which Windows accesses through ANSIPrev and ANSINext. Any
attempt to use a Chr-based ANSI binary code would seem hopeless there (on
those code pages), unless VBS has the ability to produce a single-byte
character, somehow, in that context.

> I'm not certain but I don't think that would matter for binary,
> since it's being treated as all ASCII characters (and the
> unicode translation would then still be to add a null since
> 44 in unicode is still 44....and therefore the VB internal translation
> back to ANSI would not alter anything). Maybe that's what you're
> implying in your follow-up post.
>

Ok, my best take --

The Chr-based binary write should work (I presume), for single-byte ANSI
code pages. So long as the code page is consistent, the method should work.
If the code page changes, however, either because the string data is
accessed across different code pages, or the data is stored and interpreted
as string data (not stored as binary data that is re-interpreted as string
data later on the new code page, when needed), then the change in code pages
would affect 128+ characters, even in single-byte ANSI countries.

Regards,
Joe Earnest

[Torgeir Bakken (MVP)]

mayayana wrote:

> Joe Earnest wrote:
>
>> I missed that one. (I was away from the NG for about 9 months
>> or so.) I'll go back and look for it. Of couse, the "Nothing"
>> keyword(?) is thoroughly unnecessary, but I can't imagine why
>> it could cause a problem. That should be an interesting thread.
>
> It was quite lively. It might be in the m.p.s.wsh group rather
> than the m.p.s.vbscript group.

Hi,

The article

When Are You Required To Set Objects To Nothing? (Eric Lippert)
http://blogs.msdn.com/ericlippert/archive/2004/04/28/122259.aspx

Was discussed in this thread in microsoft.public.scripting.wsh:

Subject: object=nothing question
Start Date: Wed, 24 Nov 2004 17:39:07 -0800
http://groups.google.co.uk/group/microsoft.public.scripting.wsh/browse_frm/thread/c2b95fd7f4350aab

--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scriptcenter/default.mspx

[Joe Earnest]

Hi Torgeir,

[snipped]

"Torgeir Bakken (MVP)" <Torgeir.B...@hydro.com> wrote in message
news:%23ZWh8Ye...@TK2MSFTNGP12.phx.gbl...

> Hi,
>
> The article
>
> When Are You Required To Set Objects To Nothing? (Eric Lippert)
> http://blogs.msdn.com/ericlippert/archive/2004/04/28/122259.aspx
>
> Was discussed in this thread in microsoft.public.scripting.wsh:
>
> Subject: object=nothing question
> Start Date: Wed, 24 Nov 2004 17:39:07 -0800
> http://groups.google.co.uk/group/microsoft.public.scripting.wsh/browse_frm/thread/c2b95fd7f4350aab
>

Thanks for the reference. I did find both the thread and Lippert's blog
last night. Lippert's only participation in the thread was apparently by
proxy, by MH's reference to his blog. Others provided the numerous animated
posts in the thread. Lippert's blog and the remarkably numerous posts in
response to it were quite nice. I tend to forget about the ADO issues and
the API call issues.

Thanks again,
Joe Earnest