david/Repository
1
0
Fork 0
Code Releases Activity

Auto-commit: 2025-10-31 08:58:35

Browse Source
This commit is contained in:
David Wuibaille
2025-10-31 08:58:36 +01:00
parent 7d94414992
commit 7cc3011354
1088 changed files with 193455 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

340
Tools/UniExtractRC3/UniExtract/docs/third-party/jsmsix_readme.txt vendored Normal file
View File

@@ -0,0 +1,340 @@
MSI Unpacker from JSWare
_________________________________________________________
Introduction:
_________________________________________________________
jsMSIx.exe is a compiled executable version of the JSWare MSI
Unpacker tools. This version is designed for use by people who
want it simple... who may be intimidated by script and HTAs, or
who just don't want to deal with that complexity.
Also, jsMSIx.exe is designed to work on all Windows versions.
The scripted unpackers may require some editing of the code to
work on various Windows versions due to different folder
paths and other minor differences.
This version may also be the easiest for people using Linux.
It has minimal dependencies and is easy to use.
_________________________________________________________
Requirements:
_________________________________________________________
System files MSVBVM60.DLL, CABINET.DLL and MSI.DLL
Those 3 files are pre-installed on nearly all Windows PCs. jsMSIx.exe
should work as a standalone program on all Windows versions from
Win98 to Win10. But on Linux those 3 files might need to be installed
through WINE.
File restrictions:
Later Windows versions may present obstacles in connection with
file restrictions. You may need to give yourself "permission" in some
cases. On the bright side, the JSWare unpackers are not limited
by Windows Installer "Administrative installation", which is the
unpacking method used by some MSI unpackers. An Administrative
installation is very simple to do. It's a function offered by many
MSI files. But it is only a partial unpacking and can only be done
by an Administrator. Administrative installation is designed to
unpack specific files for install from a network in business settings.
Actual unpacking of an MSI unpacks the whole thing and does
not require any special permissions.
_________________________________________________________
How to use jsMSIx.exe:
_________________________________________________________
In the Unpacker window there is an option to select an MSI
or MSM file, as well as a folder path for unpacking.
Click "GetMSI Info" to see a list of files and Registry settings in
the MSI or MSM.
Click "Unpack MSI file" to fully unpack the MSI or MSM and write
a log file documenting the files and Registry settings.
** NOTE: With very large files an unpacking or info. retrieval
operation can take several minutes. For example, platform SDK
MSIs typically record information for dozens of CAB files, each
containing dozens of files. The program needs to be allowed to
finish without interruption, and without excessive CPU demand
from other software.
_________________________________________________________
Other MSI Unpacking options:
_________________________________________________________
In addition to jsMSIx there are three script options, which are less
polished but more flexible -- for people who might want to customize
the tools.
1) MSI Unpacker - An HTA (scripted webpage) tool to unpack MSIs
and MSMs. The MSI Unpacker also provides the ability to inspect
the components and features of an installer file.
2) One-click unpacker script - Like the MSI Unpacker, but with no
interface. It's just a VBScript that unpacks MSI and MSM files.
3) jsMSI.dll - A COM DLL that can be used by script or any COM-
compatible programming language. jsMSI.dll provides a full set of
easy functions to manage MSI/MSM files. Among the functions is
a function to unpack MSIs/MSMs. There are also dozens of functions
for editing the MSI database: Create tables and records. Change
values. etc. jsMSI.dll is a "wrapper". I wraps the clunky and confusing
MSI API, with its pseudo-SQL syntax, and provides simple functions
in their place.
jsMSIx.exe and the three options listed above all unpack an MSI in
basically the same way. They create folders to mirror the folder
structure used when the software is actually installed. They then
unpack the MSI files into their respective folders. They also write
an extensive log file that details all files in the package and lists Registry
settings that will be made when the MSI installation is run.
_________________________________________________________
Explanation of folder paths:
_________________________________________________________
An MSI stores information about the destination paths of files
in an installation. Those paths are often stored as variable names
for system folder paths that vary from one computer to another.
For example, "SystemFolder" refers to the system folder path, which
is usually *but not always* C:\Windows\System32. When an installer
is unpacked, files will typically end up in such folders, mimicking the
actual install as closely as possible.
Oddly, even among Microsoft MSIs, there is little standardization
of these names. The Program Files folder may show up as "ProgramFiles",
"ProgramFilesFolder", "Programs", or even "PFiles". Likewise, the
Windows folder may show up as "Windows", "WindowsFolder", or
even "Win". As long as you know about this quirk, however, it should
be fairly simple to figure out the paths.
Example: An unpacking results in folders named "PFiles", "SystemFolder"
and "Common". Those would represent C:\Program Files, C:\Windows\System32
and C:\Program Files\Common Files on a typical system. If, on the
other hand, an MSI for the Acme Editor unpacks to a folder named "Acme"
or "Acme Editor", that would be the program folder, which will typically be
installed to C:\Program Files.
_________________________________________________________
Explanation of Registry settings:
_________________________________________________________
The Registry settings are documented in the following manner, with
the intention that anyone who wants to design their own custom
installer from an MSI can easily "auto-parse" the unpacker's log file
-- using script or some other tool -- and write the Registry settings
themselves with minimal effort.
Each setting is on 1 line and goes like this:
Path<EFBFBD>Value<EFBFBD>Type
Path is the path in the Registry.
Value is the value to set.
Type is the type of value. (String, Binary, DWord, etc.)
Each part is separated by a bullet character. (ASCII Chr 149)
Example: HKCU\Software\AceAndAcme\Settings\Theme<6D>Traditional<61>SZ
_________________________________________________________
Troubleshooting:
_________________________________________________________
In general, any errors will be documented in the unpacking
log file.
* File locations:
Make sure any external CAB files that go with the MSI file to
be unpacked are in the same folder with the MSI file.
* Long paths:
Unpacking may fail if names of files, combined with
the folder path, exceed about 250 characters. If you have problems
extracting make sure the folder path of the unpack folder is not too
long.
* MSIs inside EXEs:
Note that some MSI files are put inside EXE files. jsMSIx.exe can
unpack those MSIs, but they must first be extracted from the
EXE. Usually a good way is to open the TEMP folder, run the installer
EXE, fish the MSI out of TEMP, then cancel the install.
* MSIs inside SFX CAB EXEs:
Another installer variation that is more recent is an MSI file that
unpacks its own files before running. The MSI is inside a self-
executing CAB file, which unpacks the files on its own, as part of
the CAB SFX extraction process, into a folder tree in the TEMP folder!
In those cases, jsMSIx.exe is still useful to document the files and
Registry settings, but it needs access to the MSI file inside the SFX
CAB.
* Permissions/Restrictions:
The default on most Windows systems is to restrict you
from writing/deleting files in most locations. That could interfere
with the unpacker. For example, most MSIs have a CAB stored
internally. The Unpacker must extract that to unpack it. The
extracting is done to the same location, in case you want later
access to the CAB file. But if you don't have full permission in
the folder that holds the MSI, the Unpacker may be unable to
write the CAB file to disk and as a result be unable to find the
CAB for unpacking.
_________________________________________________________
************* UPDATE HISTORY: **********************
_________________________________________________________
___________________ Update April, 2014 __________
Over the past few years, 3 fixes were required to handle problems
with faulty Directory tables in MSIs. (The Directory Table stores the
paths of folders in a program, so parsing it is required for unpacking
an installer's files into their destination folders.)
The Directory Table is very complex, often with numerous "dummy"
entries. (For example, the MSI for Adobe Flash is merely a container
for the EXE version of the installer. Yet the Flash MSI lists 11 folder
paths in its Directory Table!)
Faulty records in the Directory Table are not uncommon, even in
Microsoft installers. (See details in update listing below.) In an effort
to avoid future problems, this update involves a complete rewrite of
the code for parsing the Directory Table.
____________________ Update March, 2014 ________
This update includes 3 changes:
* Bugfix: An error would cause MSIs with external CABs to
fail when unpacked to a folder other than the folder containing
the MSI file. The unpacker was looking for the CAB in the
destination folder instead of the MSI parent folder.
* An adjustment to logging that makes sure missing external CABs
are reported missing in the log file.
* Like two earlier updates, this is a minor update to accomodate
a type of faulty Directory table. This faulty design was found in
a Garmin maps MSI. In this case the fault was a Directory table in
which two different records indicated the root folder, which is not
allowed under MSI rules. The result of the faulty table would be that
the unpacker would not sort files because no folder assignments
could be found. This update has a workaround for the faulty table.
____________________ Update April, 2013 ________
A very minor update adding a menu for convenience and a small bugfix:
In some situations copying Registry settings to the Clipboard was
not working.
____________________ Update January, 2013 ________
A tiny update that just adds drag-drop functionality so that
one can drop an MSI onto the path textbox rather than needing
to browse for a file.
____________________ Update July, 2011 ___________
A very minor update to fix a small bug: The program would
sometimes crash if an MSI had a Registry table, but that table
had no items.
___________________ Update January, 2011 _______
This is a minor update to deal with faulty MSIs. In rare cases the MSI
unpackers here may have trouble with a particular MSI due to its being
faulty. This update follows the discovery of such an MSI.
The technical explanation:
The MSI documentation states that the MSI Directory table, listing folders
in the install, has 3 columns:
Directory - unique ID of folder
Directory_Parent - unique ID of parent folder.
DefaultDir - name of folder when installed.
The docs further state that there can be only 1 root folder. That folder has
Directory property set to TARGETDIR and DefaultDir set to SourceDir. If
there is no TARGETDIR then the ROOTDRIVE property is used. The docs also
state that if the Directory_Parent property is the same as Directory, or if it
is blank, then that entry represents the root folder. Up until now we were
only aware of 1 case of a faulty MSI Directory table. It had two TARGETDIR
entries and, oddly enough, was authored by a very well-known Microsoft MVP.
More recently a second case has turned up, this time from Microsoft themselves.
The file name is NetworkMonitor_Parsers.msi. It comes packed inside the Network
MS Monitor software download. In NetworkMonitor_Parsers.msi Directory table
there is the following:
TARGETDIR NPLROOT PackDir|NetworkMonitor Parsers
Base SourceDir
TARGETDIR is a keyword that should denote the root folder but it is not the root
folder. "TARGETDIR" was just used as the alphanumeric ID of one of the folders! The
root folder was named Base. Without figuring out the root folder name, unpacking
ends up being partial at best, so this problem needed to be dealt with.
The update involves a rewrite of the function -- in all of the unpackers -- that
performs the job of sorting out installation folder paths. The new versions will
look for a valid entry that has "SourceDir" in the 3rd column, with a 2nd column
that is either blank or matches the first column. Only if no such match is found
will it then check for entries with TARGETDIR or ROOTDRIVE in the first column.
____________________________________________
__________________ Update 11-29-2010 _________
A minor update that allows for unpacking MSIs where there are
multiple CAB files with spanning. (Where 1 stored file is stored across
2 CAB files.)
____________________________________________
___________________ Update 11-21-2010 ________
This is a minor, single bug fix. There was a typo in the code
that could cause a crash in some cases when clicking "Get MSI Info."
That was fixed.
_________________________________________________________
License:
You use all script code and components from JSWare at your own risk.
The components (compiled DLL and EXE files) may be used for personal or
commercial purposes. No payment or attribution is required for either use.
The components may be redistributed if they are required as support files
for scripts or software that you have written.
Also, the script code may be used freely, in part or as whole scripts,
for any purpose, personal or commercial, without payment or attribution.
I ask only that you not redistribute these scripts and components, except
as required for your direct use. Instead, please direct others to obtain copies
of JSWare scripts and components directly from www.jsware.net.
Also, none of the code here may be redistributed under another license. If a
work using code from JSWare is distributed with restrictions of any kind
the code from JSWare must be kept exempt from those restrictions.
This includes, but is not limited to, code sold for profit, code with usage restrictions
and code distributed as so-called "Open Source" with redistribution restrictions.
Joe Priestley
JSWare
www.jsware.net
jsware@jsware.net
Please note: JSWare does not accept "webmail" from hotmail,
yahoo, facebook, or gmail. For further explanation see:
www.jsware.net/jsware/contact.php5