One of the reasons for using the now default, NON-Optional Windows Installer method for SolidWorks is to allow for rolling back to the previous Service Pack.
As far as I'm concerned, it's far easier and faster to just reinstall the program and then apply any SPs needed to update to the desired patch revision.
Anyway, in order for the WI rollback to function, there needs to be disk space clogged up with all the files required by SolidWorks to restore itself to the previous service pack. This is accomplished, as far as I can see, by the automatic creation of a new sub-directory for the SP under the Windows "Program Files" directory where SolidWorks is installed by default. (For example: The initial install would be to "Program Files\SolidWorks" and the first Service Pack then adds files to "Program Files\SolidWorks(2)"
Aside from wasting disk space just for the possibilty of a rollback that is (in my view) better accomplished by other means, the creation of incremental sub-directories introduces an awkward convention for pathnames.
With multiple versions of SolidWorks installed, it can really get confusing, for example, 2003 could be in "Program Files\SolidWorks",
2004 could be in "Program Files\SolidWorks(2)" and a 2004 service pack could add "Program Files\SolidWorks(3)"
I've always prefered to avoid installation to the default "Program Files" location and typically place SolidWorks in dedicated directories on a drive (or partition) separate from the Windows O/S. For example, D:\SolidWorks 2003 and D:\SolidWorks 2004 are where I currently have both versions available side-by-side.
It seems that avoiding the default installation location has the added benefit of preventing the Windows Installer from gobbling up disk space with the prior revision's backup files during service pack application.
Maybe it's just a coincidence but, while using a dedicated installation directory naming procedure, I have NOT found it necessary to deal with any undesired backups or automatically created program directories.
Per O. Hoel