7

In a proper installation of an average software, its executables would be in the program files folder; its user data in the user's application data folder; it's non user specific data in the all users application data folder; and it should usually be able to run under non-administrative privileges. These guidelines could easily be ignored on XP, but they are an issue on Vista and 7 due to UAC.

We're on the verge of releasing a major version of our software. It's a CMS, used by our clients as their main work tool, and their IT staff are well familiar with it. If we want to be fully compatible with Windows 7, we have to make quite a few changes, and we're already on a tight schedule.

Question is: we can easily have our clients install our software outside of program files, or have them run it as administrators. I think it's wrong, but I need some ammunition: why should we install on program files, with all the limitations that come with it?

EDIT:

  1. I'm asking this here because I'd like to get IT guys input. For programmers input I can just ask the guys next to me instead of stackoverflow. This is NOT a programming question.
  2. I'm asking this because we'd like to make our software better. Old installation habits go back about 15 years, when the software was first created. Fixing its installation is a matter of priorities, nothing else. Worse comes to worse, it'll be postponed to the next version.
eran
  • 267
  • 1
  • 6
  • 14
  • I see a couple votes to close; while this question may belong on StackOverflow as a problem related to the architecture of a program, I do think it's also sysadmin related because (in our situation at least) the sysadmins usually end up having to deal with the permissions and installation issues that crop up due to crappy and ignorant design by software makers...just my two cents, but I can't count the number of times I've had to alter permissions and change settings specifically because some developers were too lazy to follow the rules. – Bart Silverstrim Mar 09 '10 at 12:43

4 Answers4

2

Technically: Yes.

Logically: No

Business wise: I know a lot of companies that would throw you out based on obvious quality issues. Even if you do not certify for windows, you should not blatantly violate common sense and guidelines.

I personally would return the software as faulty and bill you for every minute we spent with it - due to gross neglect.

Someone on your end obviously messed up and never read how to program windows. Happy fixing ;)

So, at the end: It is going to cost you. ESPECIALLY in a CMS area - highly competitive.

Sirex
  • 5,447
  • 2
  • 32
  • 54
TomTom
  • 50,857
  • 7
  • 52
  • 134
  • 1
    Have you had any success in getting those bills paid? – Warner Mar 09 '10 at 14:13
  • yes, once. legally this is gross neglect and the sale of software obviously unfit. – TomTom Mar 09 '10 at 14:27
  • 2
    @Warner, @TomTom - please don't take this the wrong way, but I guess you guys are not the ones making the decisions when it comes to choosing a CMS. 20+ years in business, 1500+ customers of various sizes. Are you not being too judgmental here? Our development priorities rely heavily on customers feedback. Guess this is not that big an issue. Anyway, my goal is to improve, not justify faults. Constructive answers appreciated. – eran Mar 09 '10 at 14:37
  • @Warner - sorry, thought your remark was directed to me... – eran Mar 09 '10 at 14:39
  • Did you have a contract with the company who paid? – Warner Mar 09 '10 at 14:39
2

You should read ALL of the following reference material before making your decision. It's a lot, but then you wanted to write Windows apps so...

Windows User Experience Interaction Guidelines

Windows 7 and Windows Server 2008 R2 Application Quality Cookbook (Windows)

Certification requirements for Windows 8 desktop apps

John Homer
  • 1,293
  • 10
  • 10
  • Thanks for the answer, but this question is almost 3 years old... This was eventually acknowledged as an important issue by the decision makers, and the software was made compliant in its Win7 release. Was one of those cases I was happy I could make a change. – eran Jan 15 '13 at 20:38
1

15 years ago was when Windows 95 introduced "Program Files" to the world. A lot of installers back then failed because of the space in the path. I remember what a pain it was for us but after a week's work it was done and everyone was happy.

I'm with TomTom, you are really showing that you are not in touch with Windows standards. Lots of assumptions are made about "program files" in modern times, e.g. anti-virus programs assume that's where the applications are and treat apps outside of that as different. The new default security settings on directories will also start to cause you grief and phone calls. And what's the point of the customer upgrading to Windows 7 if you insist on bypassing the security?

BTW: never assume you are entrenched. If Windows 7 is more important to them than you are they will toss you out. Senior executives make the weirdest decisions, often based on the what you think are trivial issues but to them it's a sign to get rid of your app.

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
jqa
  • 451
  • 2
  • 7
0

This has nothing to do with system administration but quite frankly, this issue should never have cropped up in the first place. Had the software been built and packaged by someone familiar with Windows it would have been put in the right place in the beginning, making this a non-issue. Having to fix it now is the price to be paid for ignoring convention and good practice.

If it was up to me the software would be rebuilt and repackaged correctly, which should be a trivial job and I can only wonder why it's even being discussed.

Just one question. What limitations do you see in installing software where it is intended to be?

John Gardeniers
  • 27,262
  • 12
  • 53
  • 108
  • 1
    Please see my edit. The software was created in the days of MS-DOS, and converted to Windows over 15 years ago. I guess our 1500+ customers have never complained enough about this for it to be fixed. As for the limitations, they are mostly writing to files in the installation folder. Not a huge deal, just a non-trivial amount of work to fix. – eran Mar 09 '10 at 13:38
  • 2
    While it may be non-trivial to fix, the product has stayed with the same architecture 15 years. Proper programming practices under Windows have been out for quite awhile, so it's not like this is a surprise. And UAC effects have been hinted at since XP and enforced in Vista and related server launches and tuned in Windows 7. You might not like the criticisms here, but this site is filled with people that have to deal with managers that purchased your products and products like it...it's a pain in the arse at times. Many might have chosen a rewrite of the product by now. – Bart Silverstrim Mar 09 '10 at 14:35
  • 1
    Only problem I have with the criticism here is that it doesn't provide me any arguments once I'm asked the exact same question I asked above. I'm not a decision maker, but my opinion counts. I've been pushing towards fixing our installation for quite a while, because I know it's flawed. I was hoping to get answers specifying exactly why these flaws annoy IT guys. I'm not sure not being conventional is enough at this point of decision. But thanks for the answers anyway! – eran Mar 09 '10 at 14:51
  • The problem is that your product "works." If it doesn't, it can be made to work. From the usability standpoint, it pisses admins off, and it is one more reason someone may jump ship. But you said you have 1500+ customers who are entrenched in your product, so your higher ups won't really give a damn. That said, try looking at books like "don't make me think" and "why software sucks" (look through Amazon) which talk about usability and user-friendliness. You can argue all you want, but if your bosses are happy with the way things are, they're not going to care in all liklihood. – Bart Silverstrim Mar 09 '10 at 16:44
  • @eran, my criticism does in fact provide you with the arguments you require. It's a simple case of do it properly or put up with an increasing number of problems now and in the future. As Bart has said, none of this is a surprise and having ignored it so long has resulted in the mess you now have. Putting off longer yet will NOT make it go away. As admins we constantly have to find ways to work around poor programming or packaging practices and most of us are absolutely fed up with it. In many cases the workarounds weaken the security we need to protect our systems. – John Gardeniers Mar 09 '10 at 21:12