Screensaver: Install fails when "/program files/" doesn't exist

[pointwood]

It's only a little problem, especially since I don't think many people use the screensaver version.

I tried to install it on a PC that doesn't have a "/program files/ " folder and that made it fail to create it's own folder. The reason there aren't a "/program files/" folder, is because this is using a Danish version of Windows 2000.

[wirthi]

I haven't used/installed the Screensaver since May or so, but it worked perfectly. I have the German version of win2k, the "/program files/" directory is called "/programme/" here. Didn't happen to be a problem ...

[pointwood]

Maybe you had it already? I case you have installed some applications before that installed inside that folder?

[wirthi]

Yes, the /Programme/ folder already existed (but not the /program files/.

I mean the bug doesn't have anything to do with the fact that it is an Englisch/German/Dutch/etc version of windows that is missing the "/program files/" or "/Programme/" or whatever directory, BUT that this direcory is missing however it is called.

I assume the Program "asks" windows how to call that directory (thus it is working with my version), but if that directory is missing, the program doesn't generate it.

I hope I could clarify my point ...

[pointwood]

What I was trying to say was that maybe you already had /program files/ besides /programme/ (it's called /programmer/ in danish).

I tried to install it using the default setting which is "/program files/something" and I got an error saying that it couldn't create that folder. When I changed "/program files/" to "/programmer/", it worked.

[Brian the Fist]

Well obviously it won't work if you're trying to create two levels of subdirectory at the same time. It is up to you to specify a valid location to install to, the default install location will not work if no c:\Program Files already exists.

[pointwood]

Howard,

If it doesn't exist, why not create it then ;)

I know other programs must do that since otherwise I would have had this problem a lot of times before, but I haven't :)

But, as I said, it's not a big problem. You could argue whether it is a bug or not, but that I don't think that matter in this case. It's about how to make it as easy as possible for the person installing it - if the user wants to get it installed in "/this/is/my/preferred/location/for/the/client/", then the client should install it there, no matter what. Well, actually it should say that the "path" doesn't exist and ask the user whether he really wants to install it there - I believe that is how a lot of applications does.

I just reported it because I got the error and thought you would like to know about it and maybe fix it sometime :)

[Brian the Fist]

Yup, the prblem is you were trying to create two levels of subdirectories at a time. Most program will barf if you try that. You can only create a new directory if the directory you are trying to creare it IN already exists, that was my point. It is a 'feature' of the OS and really has little to do with what I tell it to do. Anyways, I don't consider that somthing that needs 'fixing' but thanks for pointing it out anyways, as you never know.

[pointwood]

Well, as I wrote, other programs seem to handle exactly that fine, otherwise I would have had that problem several times, but I have never experienced this problem before. How others avoid the problem, I don't know.

And yes, it is of course completely up to you whether it is worth fixing or not. I would actually agree that it is not worth fixing. Still, it is nice to know when the next person "complains" :)

[runestar]

Howard,


Was just thinking... I don't know if this would work, but if you specify the 8.3 filename for Program Files, which would be PROGRA~1 <ugh...tildes>, it might work regardless of which region OS they have.

Even though 2000 doesn't show the tilde names anymore, apparently you can still switch to that directory using that name. (To MS: just kill the old 8.3 filename format already!)

As long as the first 6 letter are the same in the different region OS, it should still work (as long as the total length is longer than 8 characters). I only mention this because I'm seen install programs do this before, oddly enough.

(I can just hear the Linux and Unix people laughing at this ridiculous naming conventions.)

Just a thought... take it or leave it. =)

TTFN,

RS

[wirthi]

Originally posted by runestar½
Was just thinking... I don't know if this would work, but if you specify the 8.3 filename for Program Files, which would be PROGRA~1 <ugh...tildes>, it might work regardless of which region OS they have.

The idea is quite good, but it would not work for example on my PC; I have a directory "Programmieren" (coding), that seems to be Progra~1 in DOS. Ok, the screensaver would work then, but I wouldn't want it be save its data in my coding folder ....

To solve all those problems Howard would have to do two things:

1. I am quite sure there is a windows-API-call that returns the localized path of the "program files" directory. The Programm should use that one instead of /program files/, what is not correct for non-englisch versions.

2. If you specify more than one subdirectory that doesn't exist, the program would have to create them one after another.

But I don't know if it's worth while implementing that ...

[bwkaz]

It sort of depends on whether or not he's using his own code to do the installation or some other toolkit, like InstallShield or whatnot.

If he's using InstallShield, like we do at work for some things, and like a lot of places do actually, these kinds of things should be in place in the IS code already. On top of that, he doesn't have access to that code, so if it's not there, he can't change it anyway.

If he's writing his own installer, then yes, these points are probably valid (that there is an API, and that it could be called during install). I've never installed the screen saver client, so I don't know how its install works...

[wirthi]

Originally posted by bwkaz
If he's writing his own installer, then yes, these points are probably valid (that there is an API, and that it could be called during install). I've never installed the screen saver client, so I don't know how its install works...

AFAIK he's using Winzip Self Extractor combined with a self-written installer.

[runestar]

You can specify DOS names in WinZip, but this would have the unfortunate effect of screwing around with ALL the filenames and directories. However, this only works if the path is created from WinZip and not the install, if does a manual compression, he can type in the PROGRA~1.

Of course, he'd still need to check the various international versions to make sure the equivalent "DOS name" matches up.


Oh...I just realized why 8.3 names still are available...I think...I'm running on FAT(32). But I wonder if it still works under NTFS?

TTFN,

RS½

[Brian the Fist]

WinZip self extractor simply packages the files. The setup is written by me. I have complete control over it - mwu-hahahah.
If there's an API call to get the local equivalent of 'Program Files', I'd be glad to add it but I know of no such thing...
You could argue assuming C is the boot drive is not always a valid assumption either, at least with Win 2000 and up - I should probably get that from systemdrive(). But it IS only the default so I still don't see the big deal with browsing to pick a new dir to install to. Its not like you HAVE to install it there, though I could see where some people might be scared to.. :scared:

[bwkaz]

You can grab the program files directory's name using (on 2K or later natively; on 95/98/NT4 if you include the ShFolder.dll file in the directory that setup runs from) the SHGetFolderPath function. It takes a CSIDL value (which are predefined constants in shlobj.h) that specifies which folder you want the path to.

Details here (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shgetfolderpath.asp).

Synopsis:



char sPath[MAX_PATH+1];

SHGetFolderPath(NULL, /* no window owner */
CSIDL_PROGRAM_FILES, /* program files directory */
NULL, /* no specific user context */
SHGFP_TYPE_CURRENT, /* get current value, not default */
sPath); /* output variable */

[beefdart]

of course this brings up the question...

why the hell are you using windows??

Sorry, but someone had to do it.

FreeBSD.org

[wirthi]

because the nice Distributed-folding screensave only exists for Windows :rotfl:

[pointwood]

Originally posted by Brian the Fist
WinZip self extractor simply packages the files. The setup is written by me. I have complete control over it - mwu-hahahah. :D

...But it IS only the default so I still don't see the big deal with browsing to pick a new dir to install to. Its not like you HAVE to install it there, though I could see where some people might be scared to.. :scared: Well, this install is supposed to be for the clueless users out there isn't it ;)

beefdart: Trolling is not cool.

[Brian the Fist]

Ok, thanks. Ill look into it when I have time. I'd prefer a method that doesn't require distribution of extra DLLs.

[bwkaz]

Hmm... there's an alternate function for older versions of Windows that doesn't require that .dll (the .dll will be in the system directory for 2K/XP), but it won't support CSIDL_PROGRAM_FILES unless the machine has shell32.dll, version >= 5.00 (version 5.00 gets installed with IE 5). So if that's already a requirement (IE 5, that is), then go with SHGetSpecialFolderPath on non-2K and non-XP platforms. This function is linked off the SHGetFolderPath reference page. Windows 98, ME, and NT would be the only platforms affected, and IIRC, 98 installs with IE 5 already on the system. So NT with IE<5 would be the only platform to give you problems, and there might be an environment variable in that case (%programfilesdir%, I think)...

Or you could just go with SHGetFolderPath, and put one extra .dll in the setup directory. You'll only need it during installation anyway, so you don't even have to copy it to the user's windows\system directory. Or you could ignore all of this completely. It is your program, after all... ;)

[Brian the Fist]

Microsoft just has a knack for making things complicated don't they? I already implemented what you said above. Now I just gotta test it on our Win98SE machine and WinNT machine to see if it works and if so Ill commit the change.

[runestar]

KISS...

C:\Distributed_Folding\

Heh... No Program Files directory to worry about across different versions....heh. =) Its just a supposedly convenient place to put things that a lot of programs like to ignore anyways ... ever have a missing DLL... somewhere under the Windows folder? or find files in strange places like your root directory or some obscure directory like down 2 empty directories?


Best,

RS½