I'd like to extract a dll from a cab file with VBScript. Here's the command
line equivalent that I could write to a file then execute the file, but I'd
rather just manipulate the CAB file natively if possible from VBScript:



Command Line equivalents:
extract /Y /E driver.cab halmacpi.dll

Thank you,

Brian Jester

There's no native VBS suppport for CAB files.
The command line might be best, if it works OK.
There's also a 3rd-party component here:

www.jsware.net/jsware/scripts.php5#jscab

A third option is to use a zip program. Many zip
programs have command line options for dealing
with CAB files. I've used Power Archiver for that
in the past.

> I'd like to extract a dll from a cab file with VBScript. Here's the

command

> line equivalent that I could write to a file then execute the file, but

I'd

> rather just manipulate the CAB file natively if possible from VBScript:
>
> Command Line equivalents:
> extract /Y /E driver.cab halmacpi.dll
>
> Thank you,
>
> Brian Jester

> There's no native VBS suppport for CAB files.

That's what I suspected. Writing commands to *.cmd files and executing them
from VBScript works OK. I realize VBScript is not a full-on language, but
it's still really handy from within my HTA. Cheers.

"brianjester" <brianjester@xxxxxx> wrote in message
news:06646F13-84B8-47B2-A64E-D14B0711C65C@xxxxxx

> > There's no native VBS suppport for CAB files.

>
> That's what I suspected. Writing commands to *.cmd files and executing

them

> from VBScript works OK. I realize VBScript is not a full-on language, but
> it's still really handy from within my HTA. Cheers.

What is the definition of a 'full-on' language?

Why would the inability for the language to provide native support for CABs
be a measure in any way?

--
Anthony Jones - MVP ASP/ASP.NET

On Wed, 20 Aug 2008 17:17:21 +0100, Anthony Jones wrote:

> What is the definition of a 'full-on' language?
>
> Why would the inability for the language to provide native support for CABs
> be a measure in any way?

and in my previous posting I've demonstrated that there is native
support
for CAB files, so the discussion is moot.

--Bruce.

"axtens" <Bruce.Axtens@xxxxxx> wrote in message
news:5be7f864-534f-4d51-95ac-a8726bd8f31d@xxxxxx

> On Wed, 20 Aug 2008 17:17:21 +0100, Anthony Jones wrote:

> > What is the definition of a 'full-on' language?
> >
> > Why would the inability for the language to provide native support for

CABs

> > be a measure in any way?

>
> and in my previous posting I've demonstrated that there is native
> support
> for CAB files, so the discussion is moot.

That depends on your definition of Native. VBScript as a language has no
constructs that handle CAB files.

It could be that what is considered Native is more than the language,
perhaps the typical COM objects that are known to be present and often used
in VBScript such as WScript, Scripting etc. Do these handle CAB files,
didn't see your previous posting so I don't know?

It could be that what is considered Native is anything known to be present
on a platform on which VBScript is installed such as ADODB, MSXML etc. That
would be a fairly wide set of COM components, do any of these handle CAB
files, I guess there must because this is the widest definition I would use
for 'Native'.


--
Anthony Jones - MVP ASP/ASP.NET

>

> That depends on your definition of Native. VBScript as a language has no
> constructs that handle CAB files.
>

The comment about not being "full-on" made sense
to me. If you were new to the topic and didn't know
that Microsoft's support for CAB operations is rather
funky and limited (cabinet.dll is cdecl-api-only, setupapi.dll
is useless and not scriptable, and extract.exe is primitive)
then it would be sensible to assume that MS had more
forethought and had provided some CAB operations in the
FSO or WScript.Shell (since a CAB is the standard Windows
storage medium) so that admins might be able to do things
like programmatically search CABs for a needed system file
and extract it.

But as axtens said, VBS is not really a
"full-on" language. It started as a browser scripting language
created to put a stick in the spokes of the Netscape
wheel. Later MS apparently assigned a handful of people
to write a limited library for scripting (scrrun.dll), which can't
even handle binary files without some acrobatics. MS clearly
didn't have a defined vision for scripting when they did that.

And there's an additional hodge podge of misc. functionality
available, depending on what one has installed in terms
of COM components. So "not full-on" may not be a technical
term but it strikes me as a pretty good description of VBS.

mayayana wrote:

> So "not full-on" may not be a technical term but it strikes me
> as a pretty good description of VBS.
>

I'm not sure what "full-on" means either, I suspect it is
(English or Canadian) English slang for "fully featured".

Well yes, vbs doesn't have everything. But it _DOES_ have
a fully functional COM capability. And, (at least ten years
ago) microsoft provided a (free) visual basic 5 control
creation edition. With that, and a rudimentary knowledge
of vb, one could add whatever features one wished to have
in vbs. ms is no longer offering vb5cce, but if one looks
carefully, one can still find it out there in
the ectosphere.

Unfortunately, ms has "deprecated" vb 5/6, and is now
promoting vb.net. With vb.net, you can also write a COM
object (read "interop"), but it ain't so easy any more.

I am sticking with vbs, and my library of ocx's, for now.
But the handwriting is on the wall. I am looking around.
And there are lots of other interesting languages
out there...

cheers, jw

> Unfortunately, ms has "deprecated" vb 5/6, and is now
> promoting vb.net

> I am sticking with vbs, and my library of ocx's, for now.
> But the handwriting is on the wall. I am looking around.
> And there are lots of other interesting languages
> out there...
>

I was looking into options a couple of years ago.
I ended up getting involved with WINE on Linux somewhat.
But it looks like Linux may never be more than an O.S.
geek project as far as mainstream usage goes.

As it stands now, VBS works on all Windows
versions and VB6 works on all Windows versions,
generally with no support files needing to be installed.
That's much better support than .Net has, with its
requirement of a 70+- MB runtime and the phasing out
of pre-XP support. What MS decides to "officially" support
is largely irrelevant, unless they do something extreme
like break VB via Windows Update.

On top of all that, I saw an article this week about
a study indicating that about 1/3 of Vista PCs bought
by business this year have been re-imaged with XP.
(That's not counting PCs that were actually bought
with XP.) So XP could become a universal standard for a
mini "golden age" of compatibility over the next few years.
Personally I'd prefer that people had stopped at Win2000
and rejected Product Activation, but I'll gladly settle for
the convenience of a landscape where virtually everyone
has XP.

After that, who knows. I have no desire to leave
Windows and VB, but I'd be *very* surprised to
find myself wanting to use any future Microsoft
products.

Look on the bright side: Steve Jobs could have taken
over the world and we'd then all be forced to pay 3
times what a PC is worth in exchange for a cartoon
GUI with very limited programmability and product
lock-in that makes Microsoft look generous.