Sysinternals Freeware - Mark Russinovich & Bryce Cogswell

Mark's Sysinternals Blog

Multi-platform Images

Single-image download and execution with no setup program has been a hallmark of almost all of the tools that Bryce and I write and distribute on Sysinternals. I think most visitors agree that it’s more convenient to download a 200 KB ZIP file, extract its contents and execute a utility than to download and execute a 2 MB installer, in the process adding more clutter to your Start menu, before you can gain access to the tool only by navigating through that cluttered start menu to find it. And in the unlikely event you don’t want to use a tool any longer uninstalling a Sysinternals tool usually means just deleting it. User-preferences in the user-profile portion of the Registry (HKCU) might get left behind, but a lot of uninstall programs leave behind more than a few hundred bytes of data.

Unfortunately, the requirements faced by many tools of supporting 3 major lines of Windows operating systems – Windows 9x (believe it or not, if I post a tool that breaks compatibility with Windows 95 by using an API introduced in a newer version of Windows I hear about it immediately), Windows NT and Windows 64-bit – and several minor variants of each line makes delivering a tool as a single universal executable a challenge. Besides finding backward-compatible ways to accomplish what newer Windows APIs might make trivial, the tools that require support from a device driver or that require a native 64-bit image in order to work on 64-bit Windows face the biggest single-image delivery hurdle.

When we released the original versions of tools like Filemon and Regmon back in 1996 there were two downloads: one for Windows 95 and one for Windows NT. Each download file included an executable and driver where the executable was identical to both, but the driver specific to the operating system since the driver architecture for most types of Sysinternals drivers is totally different for Windows 95 than Windows NT. I wasn’t totally pleased with this arrangement since the connection between the driver and executable files wasn’t obvious to most people and copying the tools between systems meant having to remember to copy both files.

Then in March 1998 I came across an interesting article by James Finnegan in Microsoft Systems Journal (now MSDN Magazine) that describes how to embed a driver as a resource in a host executable. When it starts the host executable extracts and installs the driver. I immediately began using the technique to pull the drivers into the executables. With James’ trick I could post one Filemon download consisting of a single executable that contained within it both the Windows 9x and Windows NT drivers. At runtime the executable detects the Windows version and extracts and installs the appropriate driver.

Over the last several years I’ve refined James’ code to be even more efficient, not even creating a Windows service to host the driver, but rather loading drivers directly using the undocumented NtLoadDriver API. To handle cases where you run the executable from removable media or a network share the tools try to extract their drivers to \Windows\System32\Drivers. If that directory is inaccessible, which would be the case if you booted Windows Preinstallation Environment (WinPE) off a CD, they fall back on extracting to the same directory in which the executable resides. A further refinement is made possible by the fact that Windows reads driver images entirely into memory and so never needs to reference driver images after loading them. Sysinternals tools take advantage of this by deleting their drivers immediately after loading them.

Here’s a Filemon trace of Regmon’s startup on Windows XP that shows Regmon extracting the driver to \Windows\System32\Drivers and then deleting it after it has installed the driver in memory:



As the years progressed the download executables for several tools grew to include more than two drivers. For example, the Registry monitoring architecture is different on Windows Server 2003 than on previous versions of the Windows NT line. That means that after Server 2003 released Regmon’s executable had three drivers stored within it.

Then with 64-bit Windows (the AMD64 variety of course – you might have noticed that there’s little support for Itanium, which reflects my belief, and I think that of others, including Microsoft and Dell, that Itanium has a limited future, one only guaranteed so long as there are no 64-way Opteron systems) I faced a new challenge: how could I continue to deliver single-image downloads for utilities like Filemon, Regmon, Process Explorer, and LiveKd, that require a native 64-bit executable in order to run on 64-bit Windows? Most 32-bit applications run fine on 64-bit Windows, but because of the pointer size difference it takes a 64-bit process to query the virtual memory of a 64-bit process.

The solution I came up with is to store a utility’s 64-bit version within its 32-bit image. When you run the 32-bit executable it detects the Windows version, and if it’s running on 64-bit Windows, extracts and executes the 64-bit image, waits for the 64-bit process to exit, and then deletes the 64-bit image. Here’s a Filemon trace of the 32-bit Process Explorer extracting the 64-bit version:



And here’s Process Explorer showing the process tree that graphically shows the relationship between its own 32-bit and 64-bit images:



As a result of all the different Windows versions we support the Regmon executable now has the following images embedded within it:
  • The 32-bit executable
  • The 64-bit executable
  • The 64-bit driver
  • The Server 2003 driver
  • The Windows NT, 2000, XP driver
  • The Windows 9x driver
Even with all that Regmon weighs in at only 415 KB: the 32-bit image by itself is only about 150 KB in size and each driver version is under 50 KB in size.

I think most of you will agree that a 180 KB zipped download of Regmon that requires no installation and that can be simply copied from system to system is preferable to the “best practices” alternative: a 2 MB MSI download that takes up to a minute to install just to get a 150 KB executable and 50 KB driver onto a system.

posted by Mark Russinovich @ 7:24 PM

Comments:
Ahh... This article makes me happy.
 
I don't know what others think, but I wish you did have a traditional Windows installer. Not one per tool, but a master installer. I configure a lot of systems and I always find myself going to your web site and pulling down 4 or 5 tools, extracting them, etc. I even think a program group is useful!
 
Yeah a zip file of all your tools combined would be great ;)

Nice post. Thanks
 
We find the tools so valuable that we package them in a GPO deployable MSI with Wise Package Studio. Our techs can't be without these.
 
Having read the terms of use in your products readme files, I don't package and deploy them. However I do have a copy on CD I carry with me for my own use. And I try and keep it more or less up to date.

"You may not distribute %application name here% in any form without express written
permission of Mark Russinovich. "

I agree that no installer is neccessary, if someone volunteers their time and resources to supplying this service for you then fine. But I for one don't want to add any time load to you at all as I would prefer the time is spent adding whatever you want to add next.

Thanks for showing us how you did the driver. I don't understand it, but its very interesting nonetheless.
 
I use a lot of your tools and I really do like the lack of any need for registration (like when I want to not install something on a productionmachine) etc, but I'd still prefer an MSI, the 150K download you mention might be 300K as an MSI not 2 meg! It is also quicker to install an MSI than a zip (and installation is easier to automate).
The shortcuts (or lack of) are a killer. It taked me time to do and I always lose them!
It is possible to do an administrative install of the MSI to extract contents or as both MSI and zip versions could be automatically generated in a make file, why not do both!

Someone (rivet) mentioned helping create installer(s), my guess is that's not the issue but I can set them up if thats what you want..

My 2 cents worth,
Dennis
 
Can we have a little bit more information about undocumented NtLoadDriver() ?
 
I also find the current installation system (single executable) cumbersome.

Instead of an installer launching automatically, I have to unpack the ZIP file.

Instead of the installer creating a shortcut somewhere that I can access easily, I have to launch a Run window each time and type in the location of the executable manually.

If I don't want to launch it manually, I have to open Windows Explorer, find the executable, and create the shortcut manually. It's a pain, and it needs to be done on every system I use Sysinternals tools on. (Don't get me wrong - the tools themselves are wonderful. :) )

It's possible to combine the two approaches. Create a simple custom installer which will contain the payload executable as a resource. It should ask for an installation directory to unpack into (a default should be provided so that most people will just have to click OK). It should have a checkbox whether to create shortcuts in Programs (should be checked by default). That's it.
 
I forgot to mention that another reason we don't go with MSI's is that the installer service is not natively present on older versions of Windows.

Here's the prototype for NtLoadDriver.
 
I find it irritating that people would whine about a break from Windows 95.
 
I like the simple way of downloading a ZIP an extracting it where I want. On my work we have a Shared Directory on the network which contains all kind of tools and utillities, like MS Rescource Kits, Sysinternals tools, and so on.

Trough the logon script we add this directory to the path and when I need a tool I just press Winddows Key+R and type the name of the executable.
 
I'm frensh, sorry for my English.

People complains about having to unzip files instead of launching an installer.

I just do a simple thing : I have a folder on my USB key where my favorites sysinternals tools are unzipped.

So, I plug the key on a machine, and just have to navigate to the folder an launch the .exe
No need for Winzip or other archive tool ...
So simple ...
 
Thank you for the article, Mark!

A month ago I thought about writing a letter to explain that technique. Until last week ... I had some free time and peeked into Process Explorer to see what's happening there and … I found it. The only point that looked to me strange was the call to IsWow64Process(). That gives you the answer whether we are running on 64bit OS or not, but will embedded image run on Itanium? I’d like to see your comment about this.

In addition to the above discussion: The Sysinternals Tools are GREAT with no doubt at all!!! Should they have installers or not? It depends… On my computer I prefer to install them, and from time to time to update all of them with one click. But if I have to troubleshoot my friend’s computer I prefer not to leave anything because he would wonder what is this and why it wasn’t there before.
Looking at lightweight MSI package creation you can consider WIX toolset http://sourceforge.net/projects/wix/ I can help with it, if you like. Of course there is no native support on Win95/98 for MSI, but could use the zipped version or probably have Office on the computer that already installed MSI.
 
Sometimes installation saves a lot of trouble, Mark :)
If you have installed Paint Shop Pro on your computer you would not get those Explorer hangs :)
 
Mark,

How exactly are you packing everything up in the .exe?
 
Simple, see LoadResource and related functions in MSDN Library.
 
Mark,

I have your tools in my general util dirs and I'm using them daily. Upgrading them is a snap from the .zip files (I use Far Manager). Moving them to other computers or network shares is way easier then having to use an installer on every computer. So I totally agree with the current approach.

Installers cover things, you never know what gets put where, and it's especially impractical for command-line tools. Still if someone needs it, there are free tools to create (non-distributed) custom installers (NSIS, Innosetup, WIX) quite easily.
 
Keeping it simple is best.

The lightest footprint on my client machines, the better. If it's going to mess with the configuration of the install target - particularly in a Configuration-Managed environment, then that's not good.

I much prefer to keep these tools on a CD, or floppy, to bring to my target machines when there's an issue that needs to be looked into.
 
>>I don't know what others think, but I wish you did have a traditional Windows installer....

>>Yeah a zip file of all your tools combined would be great...

what stops you from doing that your selves?
 
I can see some downsides. What's the cost of this in terms of loading time and memory footprint?

Certainly the process of extracting/installing/deleting takes extra time; time the user has to incur every load time. (vs a longer install/download time)

The 64bit scheme is a bit worse - load 32 bit exe, extract 64 bit exe, load 64 bit exe, extract drivers, install driver, delete driver, wait for shutdown, delete 64bit exe.

If you're jumping from machine to machine this is well worth it! If you are constantly reloading a tool on one PC, maybe it's not the best idea? (Process Explorer, for example, could fall into that category).
 
One thing that bothers me (slightly) is that the zip file for each tool contains a README.TXT. It would have been easier if it was named after the tool itself, because now I have to rename all the README's if I want them in the same place.

Thanks!
 
With an MSI, doesn't windows need to keep a copy of the original msi around? If you get around to deleting it from the local settings (or wherever), woe be unto you who wants to uninstall that software.
 
Okay maybe an installer option might be nice. But definately, positively, absolutely, do not stop offerring standalone EXEs!!!!
The lighter the foottprint, the better - the only thing better and lighter would be assembly but that takes too long to code. Your tools are the greatest - I knew they loaded drivers and now I know how. Thanks for the insight into the internals of systinternals tools!
Attendee of your class in Bellevue, last year.
Keep up the good work.

Mike
 
Mark,

I don't suppose you would want
to post the code you use to extract
and run .exe and .sys files from resources.

This seems straight forward, but copy and paste is easier.
 
{believe it or not, if I post a tool that breaks compatibility with Windows 95 by using an API introduced in a newer version of Windows I hear about it immediately}

He-he autoruns.exe v8.13 no starting up on windows 95
(may be not OSR2 his...) OS tell no ws2_32.dll present :)

i know need upgrade winsock but...
 
I prefer ZIP files over MSI installers. It's very easy to unzip them to the %windir% directory and they can be executed anywhere (no need to tweak the PATH variable)

I hate it when microsoft releases their resource kit tools in MSI packages!

If you ever decide to offer MSI files, please keep also the ZIP files available!
 
Great tools by Sysinternals, I just put them in a directory that is in my searchpath so I can run them from the command line or Run option from the Start Menu. But for everybody that wants easy clickable shortcuts in the Start Menu for these tools: I have put together a little utility that can do just that. Based on entries in an INI file the utility creates shortcuts. Download MakeShortcuts. Steve
 
I use NSIS for all my installers. Has a very small footprint, which it sounds like you'd appreciate Mark. :) And it works with Windows 95. ;)

http://nsis.sourceforge.net/
 
The tools from Sysinternals are second to none. Any complaints about lack of installers should be left at the door. It seems many people don't read (or probably abide) by the 'no redistribution' license that the tools are released under.
 
I like the single EXE format - good for running from a share. There's definitely something to be said for applications that don't need to be installed/uninstalled, especially if you're going to use them to debug slightly dodgy machines.

If .exe size gets too bad you could pack them with UPX or similar. Actually, you could make the distributed EXE file a shell that just inflates the bits it needs to a temporary directory with zlib.
 
Mark,

I appreciate your justification for the simple approach, but count me in the installer lovers crowd. I appreciate the manageability and discoverability over the 2Mb difference in file size and delayed gratification of having to go through a set of installer screems before running the utility. Any chance we could convince you to offer an MSI as an option?

In any case, thank you for making these available!!!
 
I love the tools, and I do prefer the non-installer option.
This is what I try to do for all the small tools I write. And for settings I use .ini files in the same folder with the application. This way I do not leave traces in the Registry and I can also carry my preferred configuration with me.
 
Nice article, I only superficially understand it, but very clever workings.

I find the sysinternals tool invaluable and really appreciate the lightness of the single .exe

I tend to have the ones I use in a single directory and add that directory to my patch, then create a keyboard shortcut to open up a command window - even to launch the gui based tools

keep 'em light, keep 'em single .exe's

nice one :)
 
"add that directory to my patch"

obviously I mean path, dunno how the 'c' got in there :)
 
technically... you could probably embed a dos stub too ;)
 
How about a download manager to keep them all up to date :) With connections being as they are these days, it wouldn't take long to download the whole lot.
 
The driver installation technique is very neat... but... Why doesn't Windows complain about the driver "not being signed"?

Or, are the drivers signed?

I thought that every driver installed would force Windows to display the "Driver information dialog" and the user needs to agree for the driver to be installed.

Thanks for the great tools, keep up the great work guys!
 
If anyone wants to create installers using the free, open source WiX toolset, see my post of 3 months ago on the Forums...

http://www.sysinternals.com/forum/forum_posts.asp?TID=188&KW=n00dles
 
Please keep your wonderful tools in ZIP files no matter what you decide about MSI. Hundreds of our customers have policies preventing from running any kind of installers for "unplanned" products on their servers. Moreover, some of them have equipment in areas where the difference between 0.5 MB and 2 MB to download is still very noticeable.
Thanks!
 
Kudos for the tools and these are simply the best :-) With such a small size, I dont mind to download it as many times directly from your site. It will not take much time and certainly MSI is always not the best.

Thanks again,
Athif
WESUS Blog: http://msmvps.com/Athif
 
Kudos for the tools and these are simply the best :-) With such a small size, I dont mind to download it as many times directly from your site. It will not take much time and certainly MSI is always not the best.

Thanks again,
Athif
WSUS Blog: http://msmvps.com/Athif
 
yall are nuts with this installer stuff

i keep them on a usb key and a folder/share included in my set path variable
 
Context plays an important part as well.

Almost every time I need these tools, It's on some test or prod system somewhere that I need to take a look at. It's way, way easier to just grab the file and unzip it, run it off the desktop, and then delete it, then it would be with an MSI.

Because these tools get installed/removed so often, it makes complete sense to minimize the overhead of install.
 
I usually unzipped all of the tools need to the same directory, say "C:\SysInternals", and put the path into environment variable PATH. But I found it difficult to find and update the tools to their latest version.
 
the only advantage of an 'installer' would be to allow non-admins to be able to run the various sysint tools.

To install the drivers and run these tools (I assume (am I wrong??)) you need to be an admin. What if I want to give a non-admin user rights to a sysint tool?

It might in this case be helpful to have a "driver pre-install" option that gets the 'admin operations' out of the way & would subsequently let non-admin users use the tools.

Problem is that Mark usually loads the driver and then deletes it from disk. For a 'non-admin preinstall' he'd have to likely keep the file around on disk for future loads.

Or, I'm sure, we could all buy Winternals Protection Manager to elevate privileges on the fly, right Mark?
 
totally agree, installers suck.

ps: the 4th ed book is great, good job on it, lots of new info and goodies
 
All these folk complaining about not having a .MSI, and worse, b*tching and moaning about the lack of "shortcuts" (WTF are they?? 8-) ), are clearly too stupid to know about things like PATH environment variables and intelligent system configuration. It surprises me that such a level of retardation is commensurate with understanding the point and function of most SysInternals tools...

The only change I'd suggest (to make finding updates easier) would be to include the version number in the .ZIP file's name on the server.
 
As much as I love the tools, and like the fact that they don't require "installation", I often find myself wanting to use the tools on systems that don't have an unzip tool. It would be very convenient to just publish an unzipping EXE or the individual programs as EXEs (not self-extracting; just the program without the README).
 
You seemed to imply in the article that everything was packed inside the 32 bit executable in a flat manner, however (at least in the case of Process Explorer) I've been running the extracted version of the 64 bit binary for a while without an issue (I copied it out while it was running).

Is this working just because I haven't rebooted my machine in a while and the driver is still loaded, or is the driver actually embedded in the 64 bit version, which in turn is embedded in the 32 bit version? Running "strings" on the 64 bit version seems to imply this is the case - just curious.
 
I think you could drop the zip and use some exe compression which does the uncompress phases to memory directly. This would remove the need for unzip and possibly make the loading faster if you could avoid touching disk after the initial exe decompression to memory.

Also if the machine is on the Net, all the tools could inform about newer version and offer to update the exe on disk, but not inform about it with a popup, but some inobtrusive way, perhaps in the application tittle bar.
 
Hey Mark,

Your tools are fucking great. Even my dog use them!
 
Sorry, just kidding. I was too excited :P
 
Thanks for the feedback!
 
Mark,

I would love to hear your reply to (ANY!) these posted comments. Especially the developer oriented comments.

A great articles, yes, but it seems that all these folks are all speaking into the wind. Why do they bother then? Posting a comment in search of a reply seems resonable. Yes?
 
I'm not sure what kind of reply you're looking for. My views are unchanged from those I presented in the posting and I think supported by the vast majority of sysinternals tools users: I plan on continuing a policy of setup-less applications.
 
I love the 'cleanliness' in this solution. Its awesome.

Reading some of the other comments where people wanted to automate installation, I guess they are looking at avoiding to use zip file, one way to do that would probably be a self extracting exe? ;-).

However, keeping your EULA in view, you probably don't want people to be automating and distributing your tools across their company without licensing properly.

Please keep up the good work.
 
The current registry based options arrangement would seem to contradict the theory of setup less install...

It would be great if options could be XML or INI based, the tool could look for a config file of the same name...

Love the tools, even without installers...

Thanks for making these available,
Dennis
 
Um, the 64-bit scheme suggests a problem to me. What if the user running the program does not have write permission to the folder containing the 32-bit exe? (Which describes how I use your tools on my network mostly -- except that I have no 64-bit kit yet)

Will the 32-bit stub write the 64-bit image into %USERPROFILE%\Local Settings\Temp, perhaps? Or maybe just into %TEMP%?
 
Mark,
What has changed in 2003 that forced you to write a seperate driver for 2003 server? I thought that it is simillar to XP. Can you shed some light on how this stuff works? Thanks.
 
I got curious after reading your question and I took a look at the drivers that came with regmon.exe; the main difference that I've found is that the old NT driver imports KeServiceDescriptorTable to hook a couple of functions and the 2K3 driver doesn't import it but it imports two functions to 'hook' and 'unhook' the registry provided by Microsoft: CmRegisterCallback and CmUnRegisterCallback.

After this discovering I went to the MSDN and found that these functions are available from XP so I got confused again.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Kernel_r/hh/Kernel_r/k102_ec214e13-1342-48b5-9a31-8c6c9da57cd6.xml.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Kernel_r/hh/Kernel_r/k102_13cbc14e-4652-4a3d-a87e-f6eef883f912.xml.asp

I'm not sure but maybe this fact is the one that hit the target:

"For Windows XP, the system only makes post-notification calls only when a registry key is created or opened. For Microsoft Windows Server 2003 and later operating systems, the system makes post-notification calls for every registry operation"

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Kernel_r/hh/Kernel_r/DrvrRtns_988f8f3d-4ee8-4351-8fc0-703a88bd8421.xml.asp

Anyway, all that I have said is pure speculation :=)
 
DUDE!! YOU ROCK!! HEHEHEHE. KICK ASS!!

Well done!! Thanks for your efforts and time spent! Your knowledge is worty of envy :P

Rock on! My comment is probably gonna be lost in the crowd, but one day when you see this, know that you made a difference.
 
From http://news.bbc.co.uk/1/hi/technology/4424254.stm:

"Mr Russinovich has continued his investigation of the XCP software and has confirmed that when installed it can make a Windows computer more unreliable."

Gotta love that "more"...
 
Hello, just to advice that a trojan is already using the Sony DRM rootkit:

See it here
 
More info on the trojan here
 
This whole episode should be considered as much Microsoft's fault as Sony's. It's absolutely ridiculous to setup a system where you have to be running with administrator (i.e. full system) privileges in order to install application level software.

I was an IBM mainframe software developer for many years (I worked in assembler), and I can tell you that no software, other than system level utilities, was allowed to run on the mainframe with full system privileges (it was called APF authorized in IBM speak). You could install all application software without those privileges.

Microsoft really screwed up when they bundled everything into the registry, whose hives all except CURRENT_USER require administrator privileges to update. This forces all software installs to be done from and administrator level account, and effectively gives complete control of the machine to any installation program. The user has no idea what might be modified by the installation program, including the kernel and interrupt routines. This is the root (pardon the pun) of the vast majority of problems with malware that we have today.

I sure as hell hope that the next version of Windows changes the rules so that you can install software without having administrator privileges. They also need far more granularity on how system privileges are granted. The core OS files and in-memory structures should be completely protected from manipulation by outside programs unless an administrator level user has given explicit permission to allow this activity (e.g. when you install anti-virus or firewall software).
 
I guess that your worked in assembly language, that's great but it doesn't have anything to do with multiplatform images, right?

Come on all of you this is not an entry about the Sony rootkit!
 
Hi Mark
It's been a longe time since last Amsterdam.

The sony story seams to get a nasty tail. there is a news article on CNN some hackers now use similair hiding filenames in combination with sony's protection.

I think now sony has made it easy for hackers to hide their viral software.
 
Again:

Come on all of you this is not an entry about the Sony rootkit!!!
 
With regard to someone's comment that the responses aren't on topic to "Multi-platform Images", the reason the comments are here is that the blog entry regarding the Sony rootkit has a link to this thread as a place to post comments.

One other thought regarding this rootkit business. I'd be concerned at this point about buying a Sony laptop computer, DVRs, cameras, or even a DVD player. Who is to say what software, or “special BIOS code” they may have pre-installed on the machine that they aren't telling you about. I get the feeling that Sony's business model is moving from selling equipment as a primary business, to one of licensing of content (music, movies, games, etc.); and that the selling of equipment (laptops, DVD players, TVs) is morphing into more of a means of getting people to license content rather than an end in and of itself. If that's true, then this event makes it look like Sony lacks the scruples to avoid surreptitiously placing whatever DRM or phone home code they think is in their own best interests into any hardware you buy from them, including laptops. If they are willing to put a rootkit on your system from a music CD, what is stopping them from putting one on when you attach a digital camera via the USB port? There are all kinds of ways to introduce rogue code into your system when you plug in a USB device. I was toying with the idea of buying a Sony laptop (the new small one with the wide screen), but not anymore. From now on I’ll be very careful about buying anything from Sony that has the potential to talk to the rest of my home network or the internet, or interact with any of my PCs, including digital cameras.
 
http://news.ninemsn.com.au/article.aspx?id=71751

Sony has ceased production of copy protected cds!!
 
Got Sony's Email to remove the rootkit, ran it, and guess what - it's not removed.
This process is still running:
O16 - DPF: {4EA7C4C5-C5C0-4F5C-A008-8293505F71CC} (CodeSupport Control) - http://www.xcp-aurora.com/clients/SoftwareUpdate.cab
Media Jam folder is still there and Unicows.dll is still present. What next?
 
I recently stumbled on the whole SonyBMG malware issue! The whole thing makes me unbelievably angry! It is quite enough to have hackers invade your home thru whatever creeping means they can come up with it. It is completely different to hold the door open and unwittingly invite them in. It is a breech of trust, most particularly when the invasion comes in the form of a well known and trusted entity. SonyBMG has jumped off the pedestal created by the music industry. They've negated any sympathy factor that may have been their due because of the issues of CD piracy. They gave up their entitlement to righteous indignation when they stooped to imbedding malware in their CD's. What makes their actions most heinous is the fact that we purchase the malware from them and pop it right into the computer! They aren't coming in under the cover of a malicious or tricky email, they trick the consumer into PAYING them good money for their malware!
As I sat and read Mark's post's I envisioned Superman engaged in battle with the evil Lex Luthor. I am greatful you're there doing battle for the little people. (read: computer illerati) It is quite thrilling to watch as you expose their lies and demand an explanation.
My first action was to end my membership to BMG music club. (Formerly Columbiahouse) A truly small thing considering how little I actually purchase, but it did fill me with all kinds of warm fuzzy's for having taken some action. The one final word that comes to mind? BOYCOTT.
 
I find it irritating that people would whine about a break from Windows 95.
 
Yes, I remeber seeing this in those executables you download from sysinternals. I remember some tester had needed to do a COM port monitor a few years back so I suggested to stop the deleteion of this driver and copy it. I then just debugged the interface between the application and the driver. They were then able to use the driver to cut down on their work load and provide a test case for COM port verification.
 
I don't know the technical issues, but isn't it exactly the same problem that the Apple guys solved in the days of NeXT with "Fat Binaries". Today Apple call them the "Universal Binaries" which comprises a single application package with multiple binaries for many different architectures where the operating system is able to choose which one to execute. It is very clever and transparent for the user.
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?

RSS Feed

RSS
    2.0

Index

Full Blog Index

Recent Posts

The Case of the Intermittent (and Annoying) Explorer Hangs
Unkillable Processes
Running Windows with No Services
The Case of the Periodic System Hangs
Popup Blocker? What Popup Blocker?
An Explosion of Audit Records
Buffer Overflows in Regmon Traces
Buffer Overflows
Running Everyday on 64-bit Windows
Circumventing Group Policy Settings

Archives

03/01/2005 - 03/31/2005
04/01/2005 - 04/30/2005
05/01/2005 - 05/31/2005
06/01/2005 - 06/30/2005
07/01/2005 - 07/31/2005
08/01/2005 - 08/31/2005
09/01/2005 - 09/30/2005
10/01/2005 - 10/31/2005
11/01/2005 - 11/30/2005
12/01/2005 - 12/31/2005
01/01/2006 - 01/31/2006
02/01/2006 - 02/28/2006
03/01/2006 - 03/31/2006
04/01/2006 - 04/30/2006
05/01/2006 - 05/31/2006
07/01/2006 - 07/31/2006

Other Blogs

Raymond Chen
Dana Epp
Aaron Margosis
Wes Miller
Larry Osterman
Bruce Schneier
Larry Seltzer