> VanguardLH wrote:
>> Sometimes I can find old versions at oldversions.com
. KenW mentioned a
>> site with old versions.
> Most of old versions of a software can still be retrieved from the Internet
> Archive's Wayback Machine.
The archived copy of a web page will have the hyperlink, but it's
useless unless it points to a still-existing page or file to do the
download. I've used web.archive.org
a lot to see old docs, but too
often the URLs to files are dead. The site didn't just remove the web
page. They also removed the index to the file or the file itself. I'ts
one of those it-might-work-but-it-might-not. Depends on how well a site
admin does the cleanup.
> Though, the older version [of SysInternals' Process Monitor] may
> freeze the system sometimes.
I only had that if I left ProcMon running. I'd forget about it, and it
kept adding to its log. ProcMon records everything. You can filter the
log to see what you want, but everything is still getting recorded (so,
for example, you could change the filter for a different view of the
log). As the log kept getting bigger, eventually it gets so big that
the constant updating slows the OS perhaps due to I/O throttling. I'd
go into ProcMon, disable the logging, and, voila, the OS became
responsive again. It's great for monitoring, but not for long periods.
>> The exports indicate the methods that a process can call from the DLL.
>> Nothing pops out as relative to what AutoRuns does.
> The new API function which is used by the new version of Autoruns is
> Decompressor related functions. e.g. `CreateDecompressor()`.
Yet Autoruns is just telling which are the startup programs, and from
where. It's not reading into those files, so why would a decompressor
function be needed? Yeah, cabinet files are compressed, but not the
startup programs themselves, and certainly not their filenames. Maybe
reading into a file used as a startup program is a feature that I've
never used in AutoRuns, but I wouldn't use it, anyway. If I see Joe is
starting up, I don't care if Joe is a guy, gal, straight, gay, tall,
short, or what he was, just that Joe is starting up. If I wanted to
look inside a startup program, I'd use WordPad (still useful to see
strings), HxD (hex editor), or something else to look inside the file.
> I know what those functions are for, but I don't know what it's used
> for in Autoruns, cause AFAIK, Autoruns don't need to look into CAB
A .cab file is not a startable program, so it cannot be a startup
program. It's not like a .dll that could be startable if it has a
main() method. I know rundll32.exe can be used to fall a method from a
DLL, but I don't remember seeing a similar trick of calling an
exectuable from within a CAB file, but that doesn't mean there isn't
one, and I'm not much into Powershell to see if that could be used to
extract and run an .exe from within a .cab, but a script could be made
to do that.
> If it's
> used to support the new Win10 NTFS compression, the decompression should
> already be transparently done by the NTFS driver.
That's what I figured. If you enable NTFS compression, it's on the file
system, and should be transparent.
> There's a possibility that a file listed in Autoruns is stored in a
> drive which came from Win10 system and the file uses the new Win10
> compression, but why would the file be part of autorun
> application/module when the (Win8 and older) NTFS driver itself isn't
> capable of decompressing the file in the first place? That one more
> question for Microsoft.
More likely Microsoft created the dependency in autoruns.exe to
cabinet.dll without any real dependency. They could add a call to
CreateDecompressor() without actually using it; i.e., dummy code. That
would force their tools to demand a version of Windows that was still
supported, or, at least, not support a version of Windows that was too
old to bundle the DLL. However, you'd think they simply check for the
OS version, and puke out a bogus error saying the tool wouldn't work
under a version older than, say, Win8.
Or, since this is a new version of AutoRuns, could be a developer fucked
up the code, was going to add something, but never got to whatever he
was going to add. I've seen this in Dev when programmers get some free
time, and when they get dangerous. They start adding stuff that was not
in either the Functional or Engineering specs, QA finds it and has to
allocate time to test the new feature (that no customer requested, and
adds no value), or QA talks to the Dev manager why something was added
that wasn't in the specs, so it gets removed (revert back to a code
branch). New code can fix old problems, but it can introduce new
problems, too. That's why I don't update hardware drivers unless a new
version really does fix an old problem that I actually encounter, or
adds a feature that I really do want; else, a driver that is working
doesn't need to get replaced.