Reducing Dead Weight (UNIX utilities) Options

[Ed Voas]

Hi,

One of the biggest contributor to our Windows version download size is current the packaging of UNIX utilties (about 4.5M). Not only do these utilities take up a lot of space, but there have been some issues with compatibility on some Toshiba machines (zsh fun). Also, it seems that most people don't use the majority of them.

While these utilities were meant to help people bridge the gap from Mac to Windows, we would like to try to wean Widgets off of them so that we can eventually make them at best an optional part of the installation, or at most not include them at all. This is not something that would just happen overnight, but we would like to work with you Widget authors to help us towards this goal over the next few releases.

From our cursory inspection, it seems that most people are only using a few utilities of the dozens we ship with. Most notably curl. Since we have not one but two built-in facilities these days for fetching web data, we would urge people who are using curl to move to the URL or XMLHttpRequest object instead. If these objects do not meet your needs, please let us know why and we will work to fill in the gaps.

Also on the list are things such as mkdir and rm. We could very easily provide these in our filesystem object, but we are concerned about abuse. Can people who actually use these let us know how they are used. Perhaps we can sandbox their usage somewhat based on your responses.

My suggestion to Widget authors is to simply go into your installation folder and remove the bin directory from the UnixUtils folder and run your Widget. Then report what you no longer have that you'd need a replacement for. Alternatively, review your use of runCommand to see what unix utilities you might be calling. Report your findings here.

Thanks,

-- Ed

[g6auc]

These are the runCommands I currently use or have used:

cat could nearly always be replaced by filesystem.readFile() or include().
cd used in compound runCommands.
cmp used to compare image files.
cp used to copy files and directories ( often as cp -R ).
curl offered as alternative to URL object - may no longer be needed.
echo used to write strings to a file - could in some cases be replaced by filesystem.writefile, but not always.
head used to get a few lines of a file (generally to determine end-of-line type or file signature).
ls -1 could in many cases be replaced by filesystem.getDirectoryContents().
mkdir no alternative.
open no alternative to open -a application path.
rm no alternative ( often used as rm -r ).
sort used in a sorting widget only.
tr probably could sometimes use String.replace() instead.
file used on Macintosh to determine file types.

In addition to the above specific uses of runCommands, I make use of < > >> and | in compound runCommands.

For example, >> is very useful in writing log files (so that they are written out before a widget crashes).

Some of the Unix commands like cd, cp, echo, ls, tr are useful in compound runCommand sequences even if they could be replaced by native YWE commands in javascript.

Suggestions:
Provide an append mode in filesystem.writeFile().
Provide binary readFile and writeFile functions.
Provide ability (in both of the above) to specify starting position in a file and number of bytes to be read or written.

Even if native alternatives were to be provided, that would not entirely replace the versatility of being able to run shell commands.

I have a lot of problems on Windows trying to determine the type of downloaded files. You may try to load an image, but get a text or html page. It is much easier on the Macintosh (using the Unix file command) to check a file's type.

Here is a selection of runCommands from WebImages, World Clock Pro and Month Calendar:

CODE

runCommand("cp clock.js " + escapePath(system.widgetDataFolder + "/clock.js"));
runCommand('cp ' + escapePath(path) + ' ' + escapePath(memoFolderPath + '/Alarms'));
runCommand("cp -R Resources " + escapePath(system.widgetDataFolder + "/Resources"));
runCommand("cp -R Spawns " + escapePath(system.widgetDataFolder + "/Spawns"));
runCommand('cp -R ' + escapePath(memoFolderPath) + '/* ' + escapePath(path));
runCommand('cp -R ' + escapePath(oldPath) + '/* ' + escapePath(newPath));

var proxy = getProxy();
var command = "curl -s -S -m 120";
if (proxy !== "")   command  += " -x '" + proxy + "'";
if (referer !== "") command  += ' -H "Referer: ' + referer + '"';
command += " -o '" + outputFile + "' '" + url + "'";
return runCommand(command);

runCommand("echo '" + escapeData(contents) + "' >> " + escapeFilePath(path)); // appending to a log file

var result = runCommand('file ' + escapedPath);  // Mac only

var data = runCommand('head -n 1 ' + escapePath(path));

runCommand('mkdir ' + escapePath(path));
runCommand('mkdir ' + escapePath(destFolderPath));

runCommand('rm -r ' + escapePath(destFolderPath));
runCommand('rm ' + escapePath(memoFolderPath + '/Alarms/' + file));
runCommand('rm ' + escapePath(path));
runCommand("rm " + escapePath(userHome + "/Library/Preferences/" + appName31() + "/" + fileName + ".plist"));
runCommand("rm " + escapeChar(spawnPath + '/' + fileName + '.plist'));
runCommand("rm " + escapeChar(spawnPath + '/' + fileName));
runCommand("rm " + escapePath(spawnKonFile));
runCommand("rm -r " + escapePath(system.widgetDataFolder));
runCommand('rm -r ' + escapePath(oldPath) + '/*'));

Harry.

[g6auc]

From our cursory inspection, it seems that most people are only using a few utilities of the dozens we ship with. Most notably curl. Since we have not one but two built-in facilities these days for fetching web data, we would urge people who are using curl to move to the URL or XMLHttpRequest object instead. If these objects do not meet your needs, please let us know why and we will work to fill in the gaps.

I think I originally started to use curl because of limitations (in the early days of K) in the URL object. I still offer curl as an alternative to URL in some of my widgets, but I doubt that that is still necessary. Being able to set an abort timer (in curl) is useful. There also were problems with proxy servers at some stage (on Windows ?). It would be helpful if the Reference Manual gave more background on issues like proxy servers, as there is still some confusion (at least in my mind) about how (and if) URL handles these on Mac OS X and Windows.

Also on the list are things such as mkdir and rm. We could very easily provide these in our filesystem object, but we are concerned about abuse. Can people who actually use these let us know how they are used. Perhaps we can sandbox their usage somewhat based on your responses.

mkdir, rm, cp, etc., are still needed because there are no reasonable native commands. I use these to make, delete and copy files and folders. In particular, I often use the recursive forms to copy or delete folders and all there contents. For example, I use cp -R in widget spawning code. Because of the risks of errors in this area, I am extremely careful in how I construct pathnames for use with these commands. Very often, I am copying into the system.widgetDataFolder or (very recently) the system.userDocumentsFolder. Pathnames usually start with one of these. Using rm -r with * needs particular care. I have previously tried to restrict such operations to the system.widgetDataFolder as that should limit any damage to one's own widget. However, the recently threatened "improvements" to the un-installation of the widget engine have forced me to put user data into the system.userDocumentsFolder where it should be safer long-term.

The ability to read blocks from a file, rather than having to read the whole file, would obviate the need for head, and the ability to read files in binary mode would go some way to providing the equivalent of file on Windows.

I only use echo to achieve appending to text files (mainly for log files).

A more powerful filesystem.open() command would obviate the need for the Unix open command. The ability to specify the application to be used to open a file (rather than the default application) is important. For example, some developers associate kon files with their preferred text editor, which prevents filesystem.open() from starting them as widgets. This caused havoc with spawned widgets at one point.

Harry.

[Ed Voas]

I think I originally started to use curl because of limitations (in the early days of K) in the URL object. I still offer curl as an alternative to URL in some of my widgets, but I doubt that that is still necessary. Being able to set an abort timer (in curl) is useful. There also were problems with proxy servers at some stage (on Windows ?). It would be helpful if the Reference Manual gave more background on issues like proxy servers, as there is still some confusion (at least in my mind) about how (and if) URL handles these on Mac OS X and Windows.

At present, I'm not aware of any proxy issues on Windows. We should now be handling things like auto proxies correctly as per the internet settings, and we also have our own proxy server override in our preferences. On Mac OS X, it should 'just work'.

We do have a timeout facility in our URL object. That's the same as your abort timer, right? The XMLHttpRequest object does not have one, but we could always add it there (though it then falls outside of the 'standard').

mkdir, rm, cp, etc., are still needed because there are no reasonable native commands. I use these to make, delete and copy files and folders. In particular, I often use the recursive forms to copy or delete folders and all there contents. For example, I use cp -R in widget spawning code. Because of the risks of errors in this area, I am extremely careful in how I construct pathnames for use with these commands. Very often, I am copying into the system.widgetDataFolder or (very recently) the system.userDocumentsFolder. Pathnames usually start with one of these. Using rm -r with * needs particular care. I have previously tried to restrict such operations to the system.widgetDataFolder as that should limit any damage to one's own widget. However, the recently threatened "improvements" to the un-installation of the widget engine have forced me to put user data into the system.userDocumentsFolder where it should be safer long-term.

Please don't do that. The expectation is always that with uninstall, you go back to square one. That's why we are considering that change... at present, uninstall and reinstall doesn't cause Welcome to run, which is what users expect. I also think it is more correct to wipe as much of our existence as is possible if you uninstall. It would be considered bad form to put things where we don't know about and ultimately we can't remove on an uninstall. Please keep in mind that an upgrade will not have this behavior. Trying to get around what is the standard Windows uninstall behavior is bad style.

On the topic of rm/mkdir, etc. it sounds like in your case sandboxing is certainly possible (i.e. you aren't writing files in random places), which is good to hear.

The ability to read blocks from a file, rather than having to read the whole file, would obviate the need for head, and the ability to read files in binary mode would go some way to providing the equivalent of file on Windows.

Can you give me an example of how one would use a binary file reader? I ask because we don't really have a good way to express data like that. One could use a string (and I imagine you are if you are already doing this) but the encoding would be wacky. I know for example when we get strings from the JS environment we'll ensure they are proper utf8 and if not, we complain. So for example if we read part of a file and converted it ourselves into a string, it might not make the conversion.

That said, for sockets, I had considered a binary data object you could pass around and add or extract information from. Of course the trouble with such an object is that you need to know how the data is packed and in what endianness. The same really does apply to reading a binary file.

A more powerful filesystem.open() command would obviate the need for the Unix open command. The ability to specify the application to be used to open a file (rather than the default application) is important. For example, some developers associate kon files with their preferred text editor, which prevents filesystem.open() from starting them as widgets. This caused havoc with spawned widgets at one point.

OK. That one seems easy enough. At present I imagine you supply a full path to the application?

[g6auc]

We do have a timeout facility in our URL object. That's the same as your abort timer, right?

Yes, but I've just searched for it in the Reference Manual and did not find it.

Please don't do that. The expectation is always that with uninstall, you go back to square one. That's why we are considering that change... at present, uninstall and reinstall doesn't cause Welcome to run, which is what users expect. I also think it is more correct to wipe as much of our existence as is possible if you uninstall. It would be considered bad form to put things where we don't know about and ultimately we can't remove on an uninstall. Please keep in mind that an upgrade will not have this behavior. Trying to get around what is the standard Windows uninstall behavior is bad style.

I have recently changed my Month Calendar widget to use the userDocumentsFolder instead of the widgetDataFolder. There are three reasons for this. 1) I see that a lot of Windows' users have been having installation problems. The recommended fix is often to un-install and re-install. If that deleted the widgetDataFolder, users would lose what I regard as their data. 2) Month Calendar allows the user to make memos which are stored in files. I regard this behavior much as I would that of a text editor. Just because they cease to use my widget, is not a reason to delete their data. 3) A little while ago, defective releases of the Macintosh Widget Engine (3.1 and 3.1.1) were deleting the system.widgetDataFolder. Whilst this was probably a once off aberration, it did not do anything for my confidence or that of users of my widget. Many of my widgets use the system.widgetDataFolder. I have not changed their behavior because I do not regard the stored data as that critical.

On the topic of rm/mkdir, etc. it sounds like in your case sandboxing is certainly possible (i.e. you aren't writing files in random places), which is good to hear.

I always try to do that, but I do have widgets (like my DropMover widget) that can be set up by the users to copy files to places they choose. I suspect you will not be able to sandbox these calls without limiting what widgets can do, which would be a pity.

Can you give me an example of how one would use a binary file reader? I ask because we don't really have a good way to express data like that. One could use a string (and I imagine you are if you are already doing this) but the encoding would be wacky. I know for example when we get strings from the JS environment we'll ensure they are proper utf8 and if not, we complain. So for example if we read part of a file and converted it ourselves into a string, it might not make the conversion.

I'll email you some sample code. I have binary file I/O running on the Macintosh. I have used it to read image files to determine their type. One could. for example, use binary output to write a jpeg file, etc. As far as encoding goes, there are two points: The functions return data in blocks, not a whole file at a time, and they return the data as an array of bytes (0..255). This gets around encoding and endian issues.

That said, for sockets, I had considered a binary data object you could pass around and add or extract information from. Of course the trouble with such an object is that you need to know how the data is packed and in what endianness. The same really does apply to reading a binary file.

I am prepared to handle such issues myself, providing I can read the data!

OK. That one seems easy enough. At present I imagine you supply a full path to the application?

Sometimes, but it is better not to have to know where the application is stored. For example:

CODE

function appName() {
   var Yahoo = parseFloat(konfabulatorVersion()) > 2.5;
   if (Yahoo) { return 'Yahoo! Widget Engine'; }    // Yahoo! Widget Engine
   return 'Konfabulator';
}
runCommand("open -a " + escapePath(appName()) + " " + escapePath(spawnPath + "/" + konFile));

I don't really want to have to know where the Widget Engine has been installed.

Harry.

[Ed Voas]

Yes, but I've just searched for it in the Reference Manual and did not find it.

OK, I'll make sure it's added.

I have recently changed my Month Calendar widget to use the userDocumentsFolder instead of the widgetDataFolder. There are three reasons for this. 1) I see that a lot of Windows' users have been having installation problems. The recommended fix is often to un-install and re-install. If that deleted the widgetDataFolder, users would lose what I regard as their data. 2) Month Calendar allows the user to make memos which are stored in files. I regard this behavior much as I would that of a text editor. Just because they cease to use my widget, is not a reason to delete their data. 3)  A little while ago, defective releases of the Macintosh Widget Engine (3.1 and 3.1.1) were deleting the system.widgetDataFolder. Whilst this was probably a once off aberration, it did not do anything for my confidence or that of users of my widget. Many of my widgets use the system.widgetDataFolder. I have not changed their behavior because I do not regard the stored data as that critical.

Indeed, anything like a document should be saved someplace. I guess my point is just those things that are necessary for the Widget to function, etc. should be removed with the product.

I always try to do that, but I do have widgets (like my DropMover widget) that can be set up by the users to copy files to  places they choose. I suspect you will not be able to sandbox these calls without limiting what widgets can do, which would be a pity.

Well, my tentative plan (which is currently only in my head) is to sandbox all those calls unless called out in a new <security> entry. This way, users can be alerted that you are going to manipulate the filesystem outside of that box. If you don't call it out, we'll warn the user (once).

I'll email you some sample code. I have binary file I/O running on the Macintosh. I have used it to read image files to determine their type. One could. for example, use binary output to write a jpeg file, etc. As far as encoding goes, there are two points: The functions return data in blocks, not a whole file at a time, and they return the data as an array of bytes (0..255). This gets around encoding and endian issues.

While you could do this magic all on your own, I think we still want to provide a much better abstraction so that people don't have to think about it. I actually wrote this abstraction and we use it internally for several things at this point, so it works pretty well. Trick would now be to expose it via JS.

Sometimes, but it is better not to have to know where the application is stored. For example:

CODE

function appName() {
   var Yahoo = parseFloat(konfabulatorVersion()) > 2.5;
   if (Yahoo) { return 'Yahoo! Widget Engine'; }    // Yahoo! Widget Engine
   return 'Konfabulator';
}
runCommand("open -a " + escapePath(appName()) + " " + escapePath(spawnPath + "/" + konFile));

I don't really want to have to know where the Widget Engine has been installed.

And in fact, we don't want to necessarily tell you. One thought is to provide a simple openWidget call to guarantee things always open as a Widget. But to be honest, we are also working on some stuff right now that might make spawing very simple (basically, I have finally cleaned things up - on Windows at least - to the point that we can launch multiple Widgets in one process space). The only trick would be to figure out how to store prefs. I have some thoughts in my head about how to do this that haven't been proven they'd work yet, but it's a start.

[g6auc]

While you could do this magic all on your own, I think we still want to provide a much better abstraction so that people don't have to think about it. I actually wrote this abstraction and we use it internally for several things at this point, so it works pretty well. Trick would now be to expose it via JS.

I would, of course, be very happy to use a high-level abstraction. It's just that, in the meantime, a low-level method is better than no method.

And in fact, we don't want to necessarily tell you. One thought is to provide a simple openWidget call to guarantee things always open as a Widget. But to be honest, we are also working on some stuff right now that might make spawing very simple (basically, I have finally cleaned things up - on Windows at least - to the point that we can launch multiple Widgets in one process space). The only trick would be to figure out how to store prefs. I have some thoughts in my head about how to do this that haven't been proven they'd work yet, but it's a start.

I'll look forward to seeing what you come up with.

Harry.

[FineWolf]

My InfoLabel widget uses echo to extract some Environment data, such as the hostname of the computer. whoami is also used to get the name of the user.

[g6auc]

That said, for sockets, I had considered a binary data object you could pass around and add or extract information from. Of course the trouble with such an object is that you need to know how the data is packed and in what endianness. The same really does apply to reading a binary file.

I have a faint memory that sockets are supposed to deliver in "Network Byte Order" and that you then have functions to convert the data to local byte order (when that matters). I tend to think of binary files as sequences of single bytes. Clearly the same issue of byte order arises, but, for example, for graphic formats, this should be defined in the graphics standard.

On a slightly OT issue, but not a hundred miles from filesystem.readFile, etc., I would like to have a reasonable way of reading from and writing to serial ports (either old-style RS232 or via USB connected converters). I do this with my RS232 Client widget by running a local web server (on the Mac) that handles the serial ports and makes the data available to clients via http. This is very cumbersome and currently not cross-platform. However, I see no reason why this could not be done natively in YWE, which would open up a whole new area of widget application. Here I am thinking of widgets that would monitor or interact with NMEA navigation devices, like GPS receivers, etc. There are also numerous devices like radio transceivers, measuring instruments, etc., that are still made with and are routinely controlled from computers via RS232 serial interfaces.

Harry.

[Ed Voas]

I have a faint memory that sockets are supposed to deliver in "Network Byte Order" and that you then have functions to convert the data to local byte order (when that matters). I tend to think of binary files as sequences of single bytes. Clearly the same issue of byte order arises, but, for example, for graphic formats, this should be defined in the graphics standard.

I know of a specific example where the data comes in little endian, which is largely why I was headed down that path. I wrote a php module which would deal with it and display the data from a UDP socket. So yes, the data comes as it comes, but you need to know the format so you can decide whether it requires flipping.

On a slightly OT issue, but not a hundred miles from filesystem.readFile, etc., I would like to have a reasonable way of reading from and writing to serial ports (either old-style RS232 or via USB connected converters). I do this with my RS232 Client widget by running a local web server (on the Mac) that handles the serial ports and makes the data available to clients via http. This is very cumbersome and currently not cross-platform. However, I see no reason why this could not be done natively in YWE, which would open up a whole new area of widget application. Here I am thinking of widgets that would monitor or interact with NMEA  navigation devices, like GPS receivers, etc. There are also numerous devices like radio transceivers, measuring instruments, etc., that are still made with and are routinely controlled from computers via RS232 serial interfaces.

Hmm. Interesting.

[g6auc]

Another thought came to mind while I was looking at the code of one of my widgets with the intention of getting rid of rm. I converted a couple of rms to filesystem.moveToTrash() where I was deleting files that were the user's files, but I did not find it appropriate to do that where the files had been created by my widget in the system.widgetDataFolder. In that case, a delete function (like rm) that does not go via the Trash folder, is more appropriate.

Harry.

[aforsyth]

Ed - a question. Assuming that you remove the Unix tool suite eventually, would it still be possible (using the newer widget format) to include specific open-source executable tools (such as cURL) inside the widget itself to provide specific functionality?

As a case in point, I have an LDAP directory widget that queries and returns results from a corporate or public LDAP server. Neither the YWE! URL or xmlHTTP functions, nor even the current YWE! bundled version of cURL provided ldap:// protocol functionality, so I needed to include an updated version of cURL (actually along with openSSL) in the widget. The widget now runs immediately without any extra/separate expansion or installation required.

Is this scenario something that would therefore be supported in the future (again, assuming that the source of the bundled tool(s) can be verified)? Are you planning to include such protocol addressing in the URL function?

... And will we one day see safe yet functional sockets functionality in YWE! ??? :-)

Thanks,

Alan

[bjbk]

Another thought came to mind while I was looking at the code of one of my widgets with the intention of getting rid of rm. I converted a couple of rms to filesystem.moveToTrash() where I was deleting files that were the user's files, but I did not find it appropriate to do that where the files had been created by my widget in the system.widgetDataFolder. In that case, a delete function (like rm) that does not go via the Trash folder, is more appropriate.

Harry.

I would love to keep an rm function aswell. I use it in a widget of mine which downloads images in sets of 10, sometimes getting a complete new set of 10 every ten minutes. So to keep space down, i delete any images that arent being used. It would be stupid to put these into the trash, as if the user doesnt keep an eye on their trash it will just get out of control.

[Ed Voas]

Ed - a question. Assuming that you remove the Unix tool suite eventually, would it still be possible (using the newer widget format) to include specific open-source executable tools (such as cURL) inside the widget itself to provide specific functionality?

Absolutely, you'd just extract them and use them from your widget data folder. Of course, we tend to want to see source for binaries that get put into the gallery.

Is this scenario something that would therefore be supported in the future (again, assuming that the source of the bundled tool(s) can be verified)? Are you planning to include such protocol addressing in the URL function?

What is it about ldap that it doesn't work with curl... that tells me it's not http based?

... And will we one day see safe yet functional sockets functionality in YWE! ??? :-)

Someday. I hope. Oft-requested feature, and for good reason.

[aforsyth]

What is it about ldap that it doesn't work with curl... that tells me it's not http based?

LDAP is a protocol running over TCP on port 389 (whereas HTTP runs on port 80, of course). Although the default Y!WE bundled version of cURL purports to support LDAP, I never got it to work. However, the latest cURL version does run LDAP queries, hence the need to bundle it with the widget.

Hope that helps - and thanks for your speed response, Ed!

Alan

[BradC]

I use "unzip" on a personal Widget I have (i.e. not one that I've uploaded to the gallery.) It's a Widget that gets updates for AdAware. For some reason the proxy at work doesn't allow me to update by clicking on the "Update Definitions" button inside the program, so this little Widget goes to their website and downloads the zip file of the latest update, then unzips it to it's current location.

I'm not sure how many other people use it, but I can't imagine it being very commonplace.

[nniico]

~ interlude ~

Well, I just wondered why you want to remove those utilities from the YWE package?
You mentioned a compatibility problem with zsh and a too big footprint. There is a recurrent debates in this forum about memory consumption by widgets, memory leaks and other funny things. The development environment for widgets does not make is easy for developers to monitor memory usage and track leakages, and I know they can be really tricky to locate and fix. But one of the solution often given (even by developers) is : "why do you care about a leakage of 24MB a day when computers nowadays are commonly shipped with 1GB of RAM?"
I don't like this philosophy, but a lot of people rely on this fact instead of optimizing their code.

So, here is my silly question : when today's computers have 100Gb or more disk space, why bother about some megabytes to spare?

[Ed Voas]

~ interlude ~

Well, I just wondered why you want to remove those utilities from the YWE package?
You mentioned a compatibility problem with zsh and a too big footprint. There is a recurrent debates in this forum about memory consumption by widgets, memory leaks and other funny things. The development environment for widgets does not make is easy for developers to monitor memory usage and track leakages, and I know they can be really tricky to locate and fix. But one of the solution often given (even by developers) is : "why do you care about a leakage of 24MB a day when computers nowadays are commonly shipped with 1GB of RAM?"
I don't like this philosophy, but a lot of people rely on this fact instead of optimizing their code.

So, here is my silly question : when today's computers have 100Gb or more disk space, why bother about some megabytes to spare?

It isn't about disk space. It's about download time. For many people, 11M is a bit much (yes, even today). And almost half of that is for stuff very few people use.

[Drevor]

In times of 120MB video and 45MB mouse drivers and keeping in mind that Y!WE potentially adds a infinite number of new functions to your system, I wouldnt consider 11MB allot. buuuuut ... it surely wouldnt hurt if you'd move some of the functionality right into the engine. (Im still waiting on a way to delete [not move to trash] my gazillions of cache files generated by my rss reader without invoking the a external application for every single file )

[Ed Voas]

In times of 120MB video and 45MB mouse drivers and keeping in mind that Y!WE potentially adds a infinite number of new functions to your system, I wouldnt consider 11MB allot. buuuuut ... it surely wouldnt hurt if you'd move some of the functionality right into the engine. (Im still waiting on a way to delete [not move to trash] my gazillions of cache files generated by my rss reader without invoking the a external application for every single file )

I agree with the sentiments about download size, but unfortunately you and I are not at the top of the bell curve on our overall customer base.

In some ways, this all might become moot as we will be moving towards an incremental update model, so the big 11M hit might only be the first time for most users. Corporate users will still want a full installer of course.

As for deleting things... where are these cache files put that you are creating?

My InfoLabel widget uses echo to extract some Environment data, such as the hostname of the computer. whoami is also used to get the name of the user.

Sounds like this stuff could be gotten from a normal windows shell though, right? In other words, you could probably get this with runCommand just speaking DOS (no unix involved).