If you want to check it out, the new domain is: setupassistant.org.

In case you are too lazy to click (and for posterity sake) here is a screenshot of how the new site looks at the moment:

New webpage as of 1/28/13

Yes, I know – it’s standard Twitter bootstrap template. Cry me a riven. I’m actually fine with it looking as dozens of other websites out there. The standard buttons in the bootstrap are nice and sharp, and the grid layout just works. The page doesn’t need much more flourish beyond that. I’ll probably personalize it some more over time, but it is good enough for now.

Why the change? Well, first and foremost I have gotten sick of telling people to go to sa.maciak.net. For one, no one can spell my last name correctly, ever. Two, the subdomain sa is rather meaningless acronym that doesn’t really describe the tool in any meaningful way. And of course I felt like this tool deserved to have it’s own top level domain instead of piggybacking on my own last name.

Secondly, I got tired of Google Pages. Hosting the project there seemed like a pretty good idea at the time. It was quick and easy to set up and seemed reasonably easy to maintain. It turns out that the opposite was true. Updating the page via the web interface with it’s mandatory WYSIWYG editor was a chore. The fact that I had to go to one place to update the text on the page, and completely different place to upload the downloadable binary was kinda ridiculous. I’m used to either uploading files via command line SCP or pushing out content via Git. This sort of manual labor was grating and unpleasant.

Finally, the entire project was a mess. It was stretched all over the internet. The website was powered by Google Sites. The bug tracker was stand alone Lighthouse account. The code was hosted in a private git repository at BitBucket.

Now, everything is contained to BitBucket. The website is hosted using their static pages feature. It works much like the way Github does it: you have a repository which serves it’s contents as a webpage. This is actually really great because it allows me to just drop the compiled binary into my web directory from a build script, and then all I have to do is to tweak the version number and push it out to the web.

The BitBucket repository also comes with a bug tracker and a wiki. Much like at Github, the latter is actually implemented as it’s own repository with static markdown documents which I can use for things like my change log. As you can imagine, editing Markdown in Vim is infinitely faster, convinient and more pleasant than struggling with Google’s WYSIWIG interface.

The bug tracker integrates both with the code repository (I can close tickets via commit message for example) and with the wiki, where I can actually link to posted bug reports by simply using their ID number. It all works, it is all interconnected and my life has been improved for the better.

If you are currently using version 1.6 then hit the auto-update button and you will get upgraded to 1.8 immediately. This version is aware of the new domain name, so next time I release an update it will grab it from the correct place. I probably won’t be uploading any of the new binaries to the Google Sites page, so in the future, users with old versions will simply need to upgrade to 1.8 and then run the upgrade again to get the latest and greatest. Or they can simply download the new one, seeing how Setup Assistant always was, and probably always will be a stand-alone executable that does not require any installation.

If you installed version 1.6 via Chocolatey (mislabeled as version 1.7 which is why I skipped to 1.8 now) then you should just let Chocolatey handle the upgrade by doing the usual:

cinst Setup-Assistant

The in-app upgrade feature does not talk to Chocolatey package manager (because most people won’t have it) so if you upgrade it that way, you will be out of sync.

But, if you are interested I post that kind of stuff here. At the time I’m writing this, I just released version 0.9.7. You won’t read this until a week or weak and a half from now though. I’m queuing up bunch of posts in advance because there is a bachelor party that is going to blow my weekend productivity away. But that’s neither here nor there. The point is that there is a new version, and you can grab it from the usual place.

But that’s not necessarily what I wanted to talk about. You see, one of the things I just added to Setup Assistant is ability to handle zip files. It does not seem like a big thing, but it allows me to do two new types of actions:

1. Download zipped file, unzip it, and run the executable in one button click
2. Root through the file system, grab bunch of files and then zip them up for you

The first item is an obvious benefit. A lot of people ship their tools inside of zip files – I’m one of these people. Though I mostly do it because Google Pages won’t host executables. But it is something that people do, and now I can make it easy to download and run these tools.

Second item is less obvious, at least until you realize I’m talking about log files. Here is a potential scenario: a user complains of a recurring, but intermittent BSOD. They never write down the STOP message. How do you troubleshoot? Have them send you the minidump crash logs of course. But getting the user into right place might be difficult. So I made a button that does it in one click. And another one that does the same thing for Event Viewer logs. It grabs all that stuff, and creates zip files on the desktop.

Now, I did not actually write the zip support myself. I figured, why reinvent the wheel if I could use code that someone has already written. So I settled on DotNetZip library. It’s really easy to use (makes for a very clean code), it has lots of good features (for example, it supports AES encryption – and I might want to take advantage of that in the future) and it is free and distributed under MS-PL license. It is also very tiny, and ships as a single DLL file that you can redistribute with your project.

So I happily snagged it, wrote bunch of code around it and only after I was testing it for release did I realize that I needed the DLL file in the same directory as my executable. I mean, duh – that was to be expected, but for some reason I did not internalize this fact until after I had a slew of code, hanging off of it. So I was in a pickle. I really like this library and I did not want to scrap it. On the other hand, Setup Assistant has always been a self contained executable. I did not want to change that. I did not want to make an installer for it. And before you suggest the Click-Once installer built into .NET let me mention that it won’t work because of permissions. Because SA needs admin rights for… Well, for just about every single button my application manifest specifies that it always has to run as admin. For some reason this is a deal breaker for the Click-Once wizard in Visual Studio. There are apparently some ways around it, but I never really cared because I never actually wanted an installer.

Now however I had two files. My executable, and a dll that had to be with it. This was not optimal.

Fortunately, since this is a common pickle to be in, the internet provided me with a ready made solution named ILMERGE. It is a tiny command line tool from Microsoft that lets you merge several .NET assemblies into a single file. The syntax is very simple:

ilmerge /out:foobarbaz.exe foo.exe bar.dll baz.dll

The first file on the list, tells ilmerge what kind of assembly to create. If it is an executable, it will spit out an exe file, if it’s a dll, it will produce library and so on. The example above will merge foo.exe with the two library files. The resulting output file will include all of them, and work just as if these files were simply sitting in the same directory.

The neat thing about this method is that it does not require any changes in your code. For all intents and purposes the DLL files are still external files. They are not embedded in the project, and you don’t have to change the way you reference them. And since this is something you do after compiling you code, you can easily have both – a version of your program merged with all the external libraries, and one that is not. You don’t need to commit to one way or the other.

Finally, since it is a command line app, you can easily add a line to the post-build command box in Visual studio and have it called after every successful build.

Anyways, this is what I wanted to share. It’s a nice little tool, and I did not know about it until I had to figure out how to keep Setup Assistant as a self contained, single file application. Perhaps you will find it useful as well.

Thirdly, Setup Assistant 0.8 is out. Actually there are not many changes to the tool. I mostly cleaned it up (I noticed that a lot of the links from the Malware tab were mirrored in the Misc tab) added some quick Winsock fix commands and fixed one annoying typo in the license. So Setup Assistant is now Freeware instead of Feeware. Sorry to all the feeware enthusiasts out there, I just couldn’t keep it under that license any longer.

I also revamped the project web page which is now considerably less ugly. It’s still Google Sites but I actually managed to make the URL more readable. You can now access it by going to:

http://sa.maciak.net

SA of course stands for Setup Assistant. But if it helps, you can try remembering it as “Shaved Artichokes”. It’s almost the same thing.

Finally, I have realized that Apple already has a OSX tool known as Setup Assistant, which means that there is just no way for me to actually get my crappy little tool on the front page of Google when someone tries searching for it’s name. So I’m going to refer to it as “Luke’s Setup Assistant” (which is actually a fairly unique phrase) from now on. If you link to the tool anywhere (thank you), could you please update the link with that phrase so Google can get the hint?

I added the link to the page in the sidebar under My Pages, mostly for Google Juice. Also, someone asked me to do this at some point. I should probably make the link more visible but it will do for now, since Dragon Age 2 is calling my name now.

Setup Assistant 0.7

You can probably also see that I added printer related buttons where malware stuff used to be. This was pure usability trick. I noticed that I have been troubleshooting printer issues much more frequently than infections. Previously i had these buttons spread across two tabs, which made un-sticking the printer queue rather cumbersome. In fact the printer queue issues on XP are so prevalent I decided to write a tool to resolve them.

Fix My Printer Tool

I opted for an external tool rather than a built in SetupAssistant feature because… Well, user friendliness. Fix My Printer tool has a single button. Setup Assistant has like a million, and frankly can be intimidating to an end user. In fact, using it without supervision can actually break things. All I really needed was a batch script that would stop the print spooler, delete bunch of files in the spooler directory, and restart it. But I made a neat GUI because I know users get scared any time they see the “black screen” (aka the terminal window) pop up.

But once I had it done, I sort of wanted it in Setup Assistant as well. I didn’t feel like building it into the application itself, because it was simple, self contained and neat as it was. I just needed to put it online somewhere so that SA could download it just like it downloads all the other third party tools. So I got a crazy idea of setting up maciak.org as a little repository for my various small tools, scripts and apps I make on the side. There is not much there yet, but I will add stuff as I go. If you are interested, please go check it out.

Oh, and Quick System Info in Setup Assistant is still broken on some systems. I will figure it out eventually one day.

Well, with one exception. The Quick Info tool, which uses WMI to collect hardware information bugs out on certain machines. I would have fixed it a long time ago, but I just can’t seem to replicate the issue on any computer that I own. I only saw it die on 2 or 3 random machines I was working on. So I don’t have reliable environment to debug it. Does that feature work on your machine?

Anyways, here is how the new version looks:

Setup Assistant 5.0 with tabbed interface

As you can see the width of the window shrunk by about half and the damn thing grew tabs. This is a slight departure from my original idea of a single window with useful buttons all in one place but it had to be done. One day I was working on an older machine and I realized that the Setup Assistant window did not fit on my screen. The resolution was simply too low. I could have said “screw it” but seeing how I’m the primary user of the tool, having it work semi-reliably on older machines with shitty resolution was important. Also, I wanted to keep adding buttons to it, but that would mean making the window even bigger, or resizing all the existing buttons. So I made a tabbed interface. I briefly considered scroll bars, but I decided that I would hate it. So now we have tabs, and plenty of space at the cost of convenience and simplicity.

The problem with this setup is that as I keep adding new buttons and commands, I need to find place for them. It means adding new tabs, breaking the features into groups and organizing them according to function. The more I do this, the more more complex it is to navigate, and particular features harder and harder. This basically brings me back to the same problem that I was trying to solve in the first place.

This is actually a fairly interesting UI design problem: if your app needs to do 100 things, how do you expose these things to the user without having a crazy-cluttered interface. The simplistic answer of course is not to make an app that does 100 things. Make 100 apps that do one thing and let the user pick and choose one he likes. This is Unix philosophy, and most of the time this is solid advice. It does help to create robust systems but giving the user a directory full of exacutables is not necessarily a user friendly thing to do. Instead of having one app with million buttons, the user now has a truck full of smaller apps, which are only marginally easier to search through. Eventually you will still need a way of categorizing and organizing these tools in some logical way, and then you get back to the initial problem of having a complex user interface.

I guess the only logical way of dealing with this endless loop is making your application context sensitive. Display only the features that make sense in a given context. Or if your application is a catch all tool like SetupAssistant, instead of listing all the features, use search. Do something like this:

Search based SetupAssistant mockup

Naturally, this is just a basic mock-up. The idea is to allow the user to type queries, and then populate the application box with tools and links as he types. Of course the problem with search based tools like this one is that the user needs to know what he is looking for. You can use the Start Menu search box in the same way – if you want to run device manager, you just start typing “devmgmt.msc” and before you finish, a shortcut for it will pop up. So our tool would have to be smarter than that.

That said, I’m not planning to implement it yet. Maybe at some point in the future I will toy with this idea, but for now SetupAssistant is still not at the point where it would need search based interface.

So anyways, go grab the new version from here.

First off, I got tired having to jump through hoops when configuring newly re-imaged machines or troubleshooting computer issues. Windows has dozens of special folders that you sometimes need to check or clean out, and bunch of useful tools hidden away in various places. Some are in control panel, some are in the accessories menu, and etc.. Getting to these things is rather tedious but thankfully there is a shortcut for most of them. You just hit the windows key and R, and then type the name of your tool/folder into the Run dialog. You type in devmgmt.msc for the device manager, appwiz.cpl to get to the Add/Remove Programs app, minidump to open the folder where windows stores memory dump files left after BSOD crashes, %appdata% to get to the Application Data folder for the current user, and so on. And no, I didn’t look any of these up – I know these things by heart, which is why I got a crazy idea of putting shortcuts to all these things in a single folder for easy access. So I did that, and then decided that I could probably do much better – which is related to my second reason.

I getting tired of trying to talk users through simple troubleshooting diagnostics over the phone. Have you ever tried to get a user to ping your server over the phone? You would think that getting someone to spell a 4 letter word such as ping properly would be easy but I can’t tell you how often users type in something among the lines of:

fimgspacegoogledofcom

Yes, F as in Peter, I as in Indiana, M as in Nancy, G and in George, space, google dot com. Honestly, I don’t know how can you get this wrong but I assume that since we are talking about technology, users assume that I’m using some moon language that defies laws of grammar and common sense. So I got a crazy idea of creating a visual tool that will let a user ping a server, run ipconfig, nslookup or traceroute by just pushing a button.

This idea combined with my first “shortcut folder” innovation gave birth to Setup Assistant:

Click for full size screenshot

Granted, this is as simplistic as tools go. It’s basically a step beyond a shortcut folder. There is a little bit of interesting code that grabs the system information, but the rest of it is basically “start a process and maybe capture output” type of a deal. But, a few people saw me using it and asked where they could download it, to which I usually replied “this thumbdrive”. So I figured, what the hell, I’m going to make it a bit prettier with some icons and then put it online.

I was about to dump it in Google Code but then I realized that:

1. This app is basically just Process.Start repeated over and over again (except a few bits where it is not)
2. It grew organically, with me adding new launchers and new features and never bothering to clean up the code

The code is simplistic, and at the same time incredibly ugly and unorganized because… Well, this was initially just a quick hack. So I opted to not release the code just yet – at least not until I have a chance to clean it up a bit. Unless of course someone wants it or wants to contribute.

For now, it is located here: Setup Assistant Home Page. There is a download link, and some more screen shots there and far less of my aimless rambling.

Hopefully some of you will find this tiny little tool useful. As usual, if you have any suggestions (especially what else I could put onto it) let me know in the comments.