Thread: Ramdisk
View Single Post
  #17  
Old December 29th 19, 07:43 PM posted to alt.windows7.general,microsoft.public.windowsxp.general
Mayayana
external usenet poster
 
Posts: 6,438
Default Ramdisk

"Shadow" wrote

| I installed https://filehippo.com/download_ramdisk/4.0.0.5.-1/
| as recommended by Paul.
| Only thing that annoys me is I can't make it into a
| "removable" drive, i.e. I get RECYCLER and System Volume Information.
| No crashes so far.

I also found no problems at all and appreciate the
good docs. It's exactly what I wanted. The only
problem is the installer. The version you have is using
..Net, so it may be OK. But be warned. The author
doesn't seem to know anything about proper software
installation methods.


| You can use lessMSI to "look inside" the installer and even
| extract files:
|
| https://sourceforge.net/projects/lessmsi.mirror/files/
|

I'm familiar with that. It's actually one of the few MSI
unpackers that actually works. But I daresay my own
is arguably the best. (As Walter Brennan used to say
in an old 70s cowboy show, "No brag, just fact."

http://www.jsware.net/jsware/msicode.php5#unpackx

______________________________________________

* Lessmsi: A wrapper around the MS Wix libraries, which
are an unnecessary wrapper around the system file,
msi.dll, which has all the functionality for handling MSIs.
(MSIs are so poorly designed, and so monstrously
complicated, that few people can work with them. So
Microsoft actually created a software package called
Wix, to deal with their software package for making
installers. Wix is also made with .Net, so it's a bloated,
unnecessary wrapper around Microsoft's incredibly
bloated installer calamity.)

Lessmsi also requires .Net 4 or higher. That's OK if you
already need .Net 4. I don't. So I'd be installing a lot
of useless bloat to do a simple job. Lessmsi + Wix + .Net 4.
____________________________________________

* jsMSIx: My own version. Uses msi.dll functions directly
and incorporates functionality to unpack CAB files. It's a
total of 200 KB, with no extra dependencies and no need
to install.

jsMSIx not only unpacks an MSI but also writes a log
detailing the file list, Registry entries... basically everything
that the MSI will do when it's run.

For anyone who's interested, at my webpage there are
also VBScript versions, which also use msi.dll directly.
And there are various tools for working with MSIs, as
installers or as handy databases. (I use several. One is
a database to store all my old email in a searchable
format.)
I also have an MSI editor, made as an HTA, that allows
one to see the table view and add, delete, edit tables,
rows and columns.

I started working with MSIs in the early days because
I was working on text-to-speech software for a blind friend.
I needed SAPI5 speech support to do it. It turned out that
the only way to get that was to download 100 MB of SAPI
"merge modules" and then build an MSI installer that would
use about 6 MB of that slop. When I set about doing as
Microsoft advised I quickly realized that MSIs were a ridiculously
complex way to build a software installer. I would have spent
more time on the installer than on the software. But SAPI5
support wasn't available in a normal system update package.
So I had to figure out how MSIs worked, in order to get the
SAPI5 support separate from the MSI mess. That led to all the
tools I made. Included among those tools are also VBScript
tools to automate a non-MSI setup from an MSI installer.
I had to write that to get at sapi.dll and the handful of Registry
settings I needed for my own software.

Lessmsi has become well known because it's so-called
open source. But it you look at the code you'll see that
there's not actually much of it there. It just calls Wix
to do the job. But that doesn't stop the author from
adding a lot of legalese at the top of every file, claiming
that you can't use his code unless you include his
copyright notice and give him credit.

As you may have guessed, I don't have a lot of sympathy
for people who write a few lines of common wrapper code
and then make a big deal about how it's their personal
masterpiece. There are far too many people out there
hoarding code, and most of them hardly even know how
to write it.

It reminds me of the Monty Python skit about the scientist
who goes on TV to explain his new theory about dinosaurs.
The scientist clears his throat, repeatedly announces that he
has a theory, and generally wastes time with fanfare. Finally,
with the talk show host at the limit of his patience, the
scientist graces us with his amazing theory:

"The brontosaurus is small at one end, quite large in the middle,
then small again at the other end... That's my theory. Which is
mine. Which is my theory. Which belongs to me."

| It's written in VB6.(DataRam I mean).
| Maybe it installed old libraries?

I explained it already in my earlier post.
Using my own MSI unpacker I was able to see the
Registry settings that the installer changed. I'm not
sure that it used older controls but what it did do,
which is crazy, unacceptable behavior, was to change
only some CLSID keys for the specific functionality it
was using. Then it also wrote a bogus value so that
it could reverse the damage whem unistalled. It was
operating as though it were the only program that would
ever use ActiveX controls!

Example: The Microsoft common controls OCX is a
main system file that provides a number of GUI items:
listview, treeview, tabstrip, slider, progress bar, and
so on. The Dataram installer altered only the COM
settings for specific items it was using. For instance,
it might change the path of the tabstrip but leave the
path of the listview! That behavior is wrong and unstable
in numerous ways. The installer should have checked
whether the file was present, then checked whether
the present version was older, then installed the new
version *only* in that case and *only to the system folder*.
Then the file should have been registered. The whole thing.
It should have been told to register itself.
Instead, what Dataram did was to edit the registration
settings selectively in the Registry, without doing any
registration.

The way that works, in case anyone's curious and
doesn't know, is that COM libraries are self-registering.
If you call mscomctl.ocx to register itself then it will add
dozens, maybe hundreds, of settings into HKCR. Those
settings are necessary for it to work. Typically
there's a ProgID entry, like
HKEY_CLASSES_ROOT\MSComctlLib.TabStrip

That key then points to a key under HKCR\CLSID. That key
has numerous subkeys that point to such things as the
path of the file containing the tabstrip functionality,
as well as pointing to the path of the type library. It's
fairly complicated. The Dataram installer was going in
and changing only the file path, from system32 to the
Dataram folder. That was breaking things in other software.

I've never seen such a harebrained hack. Even just
registering the controls in its own folder would have been
against the rules of proper software installation. To essentially
hack the Registry settings for system libraries is worse.


Ads