Xp Security and VB6 Applications

  • Thread starter Thread starter Carl
  • Start date Start date
Windows Installer? You gotta be joking! There are too many issues with that
software. None of the versions seem to be compatible with each other. Can't
comment on ORCA. I'm just gonna look it up.
 
The problem was generated first on a friends machine, who happens to be a
Microsoft MVP. He was unable to work with me to solve the problem until
yesterday afternoon, which was really an imposition on my part since
Saturday is usually a down day for him. But together, we discovered what we
thought was going on, with the help of people in these newsgroups, and found
the workaround.
I suspect the problem can be more correctly solved by modifying the code
in either setup1.exe or in the Package and Deployment Wizard. I have a gut
feeling (not even an educated guess), that the change to the Package and
Deployment Wizard may be a little easier to make.
The last I talked to my friend yesterday, he was in the process of
filing a bug report or what ever the MVP's do when they find a
problem. -Carl
 
Or, download the sdk and use the windows installer 2 or 3 or use the NET
2003 setup wizard. And of course, ORCA.
Jamie
Click to expand...

Yes. Then all he'll need to do is to make a Rube
Goldberg-style installer package and ship the latest
Windows Installer runtime with it....but at least he
can probably avoid the annoying job of understanding
what he's packing into his installer. :)
 
Hi Lindsay,

I've not really messed with Orca too much, but this is one way it
can be used:

1) Download and install it from Microsoft. It appears to be a part
of the Microsoft Platform SDK.
http://msdn.microsoft.com/library/en-us/msi/setup/orca_exe.asp
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/downlevel.htm

2) It might already be installed on your system. I think it normally
installs into: C:\Program Files\Orca\. The executable filename is
orca.exe.

3) Open Orca.exe.
4) Download any Microsoft .msi package.
5) Click on File, Open, then type in the path and filename of the
..msi file.

As far as can tell, it's alot like the ISTool editor. The column on
the left represents a host of different things used within that part-
cular installation. The Tables column presents a couple of neat
tables to take notice of:
File
'appears to be a list of installed files
'in the right side, the Sequence column appears to be important
InstallExecuteSequence
'appears to be something important, see Sequence numbers
InstallUISequence
'appears to be important, see Sequence numbers in right table

I haven't explored it fully. I don't quite understand the Sequence
numbers, but they seem to be related between the various tables
presented in the right-hand table. And clicking on the Sequence
column header arranges the list.

The other items in the left-hand list seem to be lists of resources
involved.

I don't quite know what a merge module is, but I've seen some
folks mention the term at various times.

Perhaps someone that knows a little more about it can help out
and provide some comments.

Hope that helps.
 
It's a simple editor for Windows Installer.

--
_____________________________

(e-mail address removed)
For return email remove XX and YY.
_____________________________
 
Maybe more than anyone wants to know...
but here goes...

I haven't used Orca, except to look it over, but I
think it's a basic MSI editor for Windows Installer,
to write the MSI database tables, with functionality to
test finished packages.

The tables are the 80+ tables that can potentially
be in an MSI package's database. The MSI file itself
includes a database, usually with the actual program file
CAB also packaged inside, unless it's a very large
program.

The database is an extremely complex, cross-
referenced system that documents what files,
Registry settings, and optional details (example:
files only installed on 9x) are part of the program.

The entire MSI package is broken down into Features
and Components, for which there are MSI tables.
A Feature is something like Word or its spellchecker
in MS Office. A component is one or more files and/or
Registry settings that goes with a Feature.

All of that is packaged into the MSI file. It's possible
to entirely unpack the MSI and document every bit of
it, including Registry settings for each component, but
it's a complex procedure.

There's a good CHM file that comes with the SDK,
which explains how each table works. But it's very
convoluted, with all sorts of quirky rules and interrelation
-ships between the tables, so it's not an easy system to
figure out. Each table has its own rules. File and folder
names are encrypted and have to be looked up by
referencing one or more other tables. It's really
breathtaking how complex they've made it. And it's
easy to have errors because of that complexity.
(Example: I downloaded code awhile back from
Eduardo Morcillo's site. For some reason he's using
MSI files to package his code samples. Whatever
method he's using is faulty and produces MSIs with an
error in the Directory table due to a specific rule for that
specific table that he didn't follow.)

An MSM file, or merge module, is essentially the same
as an MSI but it contains the things needed for a given
feature and is only used by programmers building an installer,
as a way to include specific features into the installation
as a single collection of files and Registry settings..
I ended up exploring all of this one time when
I wanted to pack SAPI 5.1 with a program and
discovered that Microsoft had no way to do that except
by using Windows Installer with 100+MB of merge modules!
(I finally found someone who had made their own SAPI
installer, which can be done as small as 6 MB.)

The main drawbacks of Windows Installer are clear
in the details above. Although it can be handy for
sys. admins to better track installed software, it requires
the installation of the right version of the WI runtime. It
also unnecessarily obscures the content of an install,
making it difficult for the end user to know what's being
put onto their machine. It's *WAY* more complex than it needs
to be. But worst of all, Microsoft is using the WI system
to take the process out of the hands of programmers.
With the SAPI files, for instance, it's very difficult to find
out exactly what comprises SAPI and to know what files
you actually need to support it. And if you do it Microsoft's
way you can only ship SAPI 5 in a giant MSI installer.
So the whole thing leaves programmers once removed
from the libraries that they're using.

(If anyone is interested, I have a package of VBScripts
that comprise a webpage-GUI utility for completely dissecting
the features and components of an MSI file. It unpacks the file,
translates the encrypted file names, and "installs" the whole
program to generated folders that represent the destination
folders where the files would go in an actual install. I ended
up writing the utility in the process of trying to figure out how
to make a SAPI 5 installer. It's a handy way to check what a
program will put onto your machine before you install it.)


The following VBScript can be used to extract all of
the tables from an MSI file. Drop the MSI onto it and
it will create a folder of 80+ text files for the MSI. Each
file is one of the database tables. (That's an easy way
to see how the tables are structured.) The script also writes
a Summary Info file that outlines the main details of
what software is in the MSI.


'---------------------------------------------------------------------------
-----
'--export all tables in MSI database by dropping MSI file on this script.

Dim FSO, Pt1, s, s1, WI, DB, View, Rec, sTable, oFol
Set FSO = CreateObject("Scripting.FileSystemObject")
On Error Resume Next
s = WScript.Arguments(0)
If (FSO.FileExists(s) = False) Then
MsgBox "Drop an MSI file on script.", 64
WScript.Quit
End If
Pt1 = instrrev(s, "\")
s1 = left(s, Pt1) & "export" '--"export" folder to write files.
If (FSO.FolderExists(s1) = False) Then
Set oFol = FSO.CreateFolder(s1)
Set oFol = Nothing
End If


Set WI = CreateObject("WindowsInstaller.Installer")
Set DB = WI.OpenDatabase(s, 0) '--open read-only
' if ucase(right(s, 1)) = "I" then '--msi
GetSummary '--get summary information first.
' end if
Set View = DB.OpenView("SELECT `Name` FROM _Tables")
View.Execute
Do
Set Rec = View.Fetch
If Rec Is Nothing Then Exit Do
sTable = Rec.StringData(1)
DB.Export sTable, s1, sTable & ".txt"
Loop
Set Rec = Nothing
Set View = Nothing
Set DB = Nothing
Set WI = Nothing
WScript.Quit

Sub GetSummary() '--Get summary info from database.
Dim SI, sSummary, TS
On Error Resume Next
Set SI = DB.SummaryInformation(0)
sSummary = "Title: " & SI.Property(2) & vbcrlf
sSummary = sSummary & "Subject: " & SI.Property(3) & vbcrlf
sSummary = sSummary & "Author: " & SI.Property(4) & vbcrlf
sSummary = sSummary & "Program Name: " & SI.Property(18) & vbcrlf
sSummary = sSummary & "Creation Date: " & CStr(SI.Property(12)) &
vbcrlf
Set SI = Nothing
Set TS = FSO.CreateTextfile(s1 & "\Summary Info.txt", True)
TS.Write sSummary
TS.Close
Set TS = Nothing
End Sub



--
_____________________________

(e-mail address removed)
For return email remove XX and YY.
_____________________________
 
Jim,

A merge module is in many ways just another form of a setup application. It
allows you to create an installation program and merge it with one that was
written by someone who (hopefully) has more knowledge about installation
that you or myself. Instead of msi as a file type, you'll see it listed as
an msm file type. You can also look into msp file types, aka patches.

You can't fully put the Windows Installer to its full use without ORCA.
Generally sequencing is done to maintain flow when you implement a custom
action which you may or may not want to be applied after the installation is
completed. Remember than using an msi to install a product generally means
that when a file that is a part of the installation is deleted, the msi will
search for the file and replace it. This helps to insure that an
installation doesn't fail when it is simply missing a file. You can get
better information up on the NetFramework newsgroups for this information.
I only mention this as I believe that vb6 and most definitely the setup1.exe
/ setup.exe installation method that came with vb6 is no longer supported.

Jamie
 
Mayayana,

You have the right idea. ORCA is actually like a window into the database
that runs the msi installation process. You can add and remove data, but
primarily, resequence it.

There are some good white papers on installing the msde using ORCA on
Microsoft.

The msi can actually be queried nearly the same as you would query any
database thus, if you know a bit of vbscript, you can write some fancy
custom actions and add them to your installer package. Finally ORCA allows
you to insulate them from the final installation process if needed. Phil
Wilson wrote a great book on it.

http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/102-3258387-2184114?v=glance

Jamie
 
Ken Halter said:
Apress... BAH! FUBAR! <g> Amazon has it for 5 bucks cheaper.

Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/t...11-1/ref=sr_11_1/102-0284397-9045742?v=glance
Click to expand...


The publisher is Apress wherever you get it from. If you purchase a book,
claiming to be that book, from anywhere at any price that is not published
by Apress, then it is a fake.

Are you aware of any publisher that shows a price for a book that is less
than what Amazon's price is?

I usually post just the vital data; that is, title, author, publisher and
ISBN. I have a table (in an Access database) of books with that data, so I
gather that data for myself. It is then easy for me to post the data for the
benefit of others. Using that data, it is possible to compare prices. It is
even possible to find copies in libraries. I usually get that data from the
United States Library of Congress's catalog data. This book, however, is not
in the LOC; I assume due to being published outside the USA. Therefore I
searched for the book and found the publisher's site so I posted the
publisher's page.
 
Got the book for Xmas this year. Dunno from where. I suspect my wife
probably paid retail less discount in her bookstore. I didn't ask her. It
is very well written though challenging to say the least.
 
mayayana said:
I haven't used Orca, except to look it over, but I think it's a basic
MSI editor for Windows Installer, to write the MSI database tables,
with functionality to test finished packages.
Click to expand...

Yes, I'm seeing it as an editor for msi files. Thank you much for the time
you've taken to explain it.
(If anyone is interested, I have a package of VBScripts
that comprise a webpage-GUI utility for completely dissecting
the features and components of an MSI file. It unpacks the
file, translates the encrypted file names, and "installs" the
whole program to generated folders that represent the
destination folders where the files would go in an actual
install. I ended up writing the utility in the process of
trying to figure out how to make a SAPI 5 installer. It's a
handy way to check what a program will put onto your machine
before you install it.)
Click to expand...

<g> I'll take you up on that... How big are they? Small enough to post
here? The script you've already included, below was formatted to look
and read a little better, indenting the If's and Do ... Loop. :-)

Thanks goes to Jamie as well. I remember someone named Jamie
once in Illinois in Elementary school (1970s). Very weird... I don't know
why that popped into my head.

--
Jim Carlock
Please post replies to newsgroup.

mayayana said:
The tables are the 80+ tables that can potentially
be in an MSI package's database. The MSI file itself
includes a database, usually with the actual program file
CAB also packaged inside, unless it's a very large
program.

The database is an extremely complex, cross-
referenced system that documents what files,
Registry settings, and optional details (example:
files only installed on 9x) are part of the program.

The entire MSI package is broken down into Features
and Components, for which there are MSI tables.
A Feature is something like Word or its spellchecker
in MS Office. A component is one or more files and/or
Registry settings that goes with a Feature.

All of that is packaged into the MSI file. It's
possible to entirely unpack the MSI and document every
bit of it, including Registry settings for each
component, but it's a complex procedure.

There's a good CHM file that comes with the SDK,
which explains how each table works. But it's very
convoluted, with all sorts of quirky rules and
interrelationships between the tables, so it's not an
easy system to figure out. Each table has its own
rules. File and folder names are encrypted and have to
be looked up by referencing one or more other tables.
It's really breathtaking how complex they've made it.
And it's easy to have errors because of that
complexity.

(Example: I downloaded code awhile back from
Eduardo Morcillo's site. For some reason he's using
MSI files to package his code samples. Whatever
method he's using is faulty and produces MSIs with
an error in the Directory table due to a specific
rule for that specific table that he didn't follow.)

An MSM file, or merge module, is essentially the same
as an MSI but it contains the things needed for a
given feature and is only used by programmers
building an installer, as a way to include specific
features into the installation as a single collection
of files and Registry settings...

I ended up exploring all of this one time when I wanted
to pack SAPI 5.1 with a program and discovered that
Microsoft had no way to do that except by using Windows
Installer with 100+MB of merge modules! (I finally
found someone who had made their own SAPI installer,
which can be done as small as 6 MB.)

The main drawbacks of Windows Installer are clear
in the details above. Although it can be handy for
sys. admins to better track installed software, it
requires the installation of the right version of the
WI runtime. It also unnecessarily obscures the content
of an install, making it difficult for the end user to
know what's being put onto their machine. It's *WAY*
more complex than it needs to be. But worst of all,
Microsoft is using the WI system to take the process
out of the hands of programmers.

With the SAPI files, for instance, it's difficult to
find out exactly what comprises SAPI and to know what
files you actually need to support it. And if you do it
Microsoft's way you can only ship SAPI 5 in a giant MSI
installer. So the whole thing leaves programmers once
removed from the libraries that they're using.

(If anyone is interested, I have a package of VBScripts
that comprise a webpage-GUI utility for completely dissecting
the features and components of an MSI file. It unpacks the
file, translates the encrypted file names, and "installs" the
whole program to generated folders that represent the
destination folders where the files would go in an actual
install. I ended up writing the utility in the process of
trying to figure out how to make a SAPI 5 installer. It's a
handy way to check what a program will put onto your machine
before you install it.)


The following VBScript can be used to extract all of
the tables from an MSI file. Drop the MSI onto it and
it will create a folder of 80+ text files for the MSI. Each
file is one of the database tables. (That's an easy way
to see how the tables are structured.) The script also writes
a Summary Info file that outlines the main details of
what software is in the MSI.
Click to expand...

'--------------------------------------------------------------------------
'--export all tables in MSI database by dropping MSI file on this script.
Dim FSO, Pt1, s, s1, WI, DB, View, Rec, sTable, oFol
Set FSO = CreateObject("Scripting.FileSystemObject")
On Error Resume Next
s = WScript.Arguments(0)
If (FSO.FileExists(s) = False) Then
MsgBox "Drop an MSI file on script.", 64
WScript.Quit
End If

Pt1 = instrrev(s, "\")
s1 = left(s, Pt1) & "export" '--"export" folder to write files.
If (FSO.FolderExists(s1) = False) Then
Set oFol = FSO.CreateFolder(s1)
Set oFol = Nothing
End If

Set WI = CreateObject("WindowsInstaller.Installer")
Set DB = WI.OpenDatabase(s, 0) '--open read-only
'if ucase(right(s, 1)) = "I" then '--msi
GetSummary '--get summary information first.
'end if
Set View = DB.OpenView("SELECT `Name` FROM _Tables")
View.Execute
Do
Set Rec = View.Fetch
If Rec Is Nothing Then Exit Do
sTable = Rec.StringData(1)
DB.Export sTable, s1, sTable & ".txt"
Loop
Set Rec = Nothing
Set View = Nothing
Set DB = Nothing
Set WI = Nothing
WScript.Quit

Sub GetSummary() '--Get summary info from database.
Dim SI, sSummary, TS
On Error Resume Next
Set SI = DB.SummaryInformation(0)
sSummary = "Title: " & SI.Property(2) & vbcrlf
sSummary = sSummary & "Subject: " & SI.Property(3) & vbcrlf
sSummary = sSummary & "Author: " & SI.Property(4) & vbcrlf
sSummary = sSummary & "Program Name: " & SI.Property(18) & vbcrlf
sSummary = sSummary & "Creation Date: " & CStr(SI.Property(12)) & vbcrlf
Set SI = Nothing
Set TS = FSO.CreateTextfile(s1 & "\Summary Info.txt", True)
TS.Write sSummary
TS.Close
Set TS = Nothing
End Sub

--
_____________________________

(e-mail address removed)
For return email remove XX and YY.
_____________________________
 
<g> I'll take you up on that... How big are they? Small enough to post
here?
Click to expand...

I don't know what the protocol is for posting
attachments to newsgroups. It's about 100 KB.
I hope that's OK to post. I'll attach it to a follow-up
message so that people won't get stuck downloading
it with this one.

The package includes a help file and general
info. There are three things worth mentioning in
advance:

1) The utility uses Power Archiver to unpack MSI
CAB files. If you use another zip program you need
to change a line or two of code. (It's explained in
the help. The command line for unpacking the CAB
must be a valid command line for an installed zip
program.)

2) A surprising number of programs, for reasons I
don't know, come in EXEs that unload MSIs to the
TEMP folder. The utility can unpack those MSIs
but you might not know they're MSIs unless you
check TEMP while installing. I installed the Java
SDK/runtime awhile back, for instance, and it was
packed as a somewhat bizarre, multiple-level encasing
of MSIs and EXEs.

3) The utility was written before Windows Installer
v. 3 was released, but it should work fine with MSI v. 3
files. From what I could gather reading the docs, the
changes in MSI v. 3 are minimal. In fact, even though
each version of Windows Installer refuses to open
later-version packages, the general system does not
seem to have changed significantly since the original
version. I wrote the utility using a Windows Installer
v. 1.1 CHM file with v. 2 installed and had no problems.
In fact, with v. 1.5 it was possible to just edit the MSI file
version number i order to force it to install with only
the v. 1.1 runtime installed.


Other than those points, the utility is straightforward.
It has an IE webpage interface, driven by VBScript, that
will process an MSI and let you inspect each feature
and component in terms of finding what files and/or
Registry settings are included. It also unpacks the
MSI, writing a log to document the contents. There
are also scripts included to:

- Do a dump of all the database tables.

- Create an installer VBScript to write the required
Registry settings for a given portion of an MSI
install without having to install the whole thing.
(As in the SAPI 5 example mentioned earlier.)

That script is meant mainly as a demo of how
one can take advantage of the methods in the
Windows Installer COM object to get the information
necessary to include needed support files into a
program installer, even though Microsoft may only
release those particular support files in merge
module (MSM) form.

In other words, if you want
to ship support files that only come in MSM files -
without being forced to use an MSI install and the
astronomical bloat that that may, in some cases,
entail - the demo script shows the basics of how to
do it.
 
mayayana said:
I don't know what the protocol is for posting
attachments to newsgroups. It's about 100 KB.
I hope that's OK to post. I'll attach it to a follow-up
message so that people won't get stuck downloading
it with this one.
Click to expand...

The best thing would be to post either to a binary group (I'm not sure if
Microsoft provides a binary group) or even better, would be to post to
a website. 100K isn't all that bad, as many pictures on various websites
are 100K in size. But if you look at the stuff here in this newsgroup and
sort it by size, there's a 37K post (has a picture). There might be some
others that are bigger but I haven't figured out how to expand all threads
using Outlook Express. I'd personally hesitate before posting something
that big (maybe). <g>

I this might be okay to post to though:
nntp://microsoft.public.office.developer.binary.file_format
 
The best thing would be to post either to a binary group (I'm not sure if
Microsoft provides a binary group) or even better, would be to post to
a website. 100K isn't all that bad, as many pictures on various websites
are 100K in size. But if you look at the stuff here in this newsgroup and
sort it by size, there's a 37K post (has a picture). There might be some
others that are bigger but I haven't figured out how to expand all threads
using Outlook Express. I'd personally hesitate before posting something
that big (maybe). <g>
Click to expand...
Too late. I guess you didn't see the next post.
It came through as 151 KB. I suppose I can't
avoid bloat from Base64 encoding.
I know it's not polite to post large messages,
and I avoid opening them myself when there's
a big code dump that will take awhile to download,
but now I'm curious about what the actual edicate
is. It's not clear to me even who provides the
bandwidth for these groups. I suppose this one
must be hosted by Microsoft, but then I wonder
about comp.lang.basic.visual.misc.
 
mayayana said:
Too late. I guess you didn't see the next post.
It came through as 151 KB. I suppose I can't
avoid bloat from Base64 encoding.
Click to expand...

I don't see it. Not in:
microsoft.public.vb.general.discussion
microsoft.public.vb.api

Do you see it? Outlook Express has been horid for me recently.
I've got a feeling Outlook Express's "folders.dbx" is corrupt on this system.
 
Yes, I see it right below this conversation.
(In microsoft.public.vb.winapi)
I'm also using OE, though mine is v. 5.00.

I don't know whether it will make a difference to
do anything with the DBX files, but I do know that
at least in v. 5 the DBX system is very funky.

I have to periodically delete my folders.dbx because
it gets so big. I do the same thing with the individual
folder DBXs. They seem to hold a copy of everything
that has ever been in them. When you delete something
it gets marked as deleted but it doesn't get removed!
That's also true for the Deleted.DBX file. I have to delete
everytnig twice just to have it show as deleted....then it's
still not deleted - just inaccessible.
It shrinks the total OE folder size by several MB every time
I clean it.

About once per month I back up the whole OE folder.
One at a time I copy all mail to a TEMP OE folder
that I made for the purpose. Then I close OE and delete
the bloated DBX for the given account. Then I open OE
so that it will generate a new account DBX. Then I move
all the mail back into the new folder.

I also periodically have to delete the newsgroup DBXs.
(Best to do just after reading them because all messages
will show as unread on the first reload.)

A note about folders.dbx: If you delete it be sure to check
your mail rules, if you have any. They may need to be reset.

Reading what I just wrote it's hard to believe that
I'm still using OE! I've got Thunderbird, and it even
copied in all of my DBXs without a hitch, but I've been
too lazy to get around to actually switching over.
 
I am not sure what "it" is but the usual "it" is not appropriate here. If
"it" is a really big attachment, or even a mediun-sized one, then I don't
see it and I am looking at microsoft.public.vb.winapi. I also use OE. When I
change my Current View so that "Group Messages by Conversation" is off and
when I sort by message size, the biggest message is 59KB.

As for OE problems, I have gotten some folders that became quite large but
the only possible problem for me has been performance, but even that seems
to be solved by defragmentation. Perhaps if you ask in an OE user's forum
you will get help with OE problems.
 
You must log in or register to reply here.

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

VB6 on XP - won't initiate 4
Windows XP sp2 and Mcafee internet security suite Version 6 1
Problems uninstalling McAfee 3
which of my required system files shipped with a new XP install 1
How recover XP without losing data or applications 11
User accounts not working 2
Bootable XP Flash Drive? 22
MFC71.dll issue - new twist 1

Back
Top