APPDATA folder question
in [Visual Basic]
|
Prev: VB6 and SQLite: Instructions on how to insert a blob into a new record
Next: Wondering how this is possible
From: Eduardo on 20 Dec 2008 22:46 "Karl E. Peterson" <karl(a)mvps.org> escribi� en el mensaje news:evIjF7sYJHA.2084(a)TK2MSFTNGP06.phx.gbl... > Eduardo wrote: >> "Karl E. Peterson" <karl(a)mvps.org> escribi� ... >> >>>> PS: I see that every time it is more difficult to keep an application >>>> compatible with all Win32 O.S. versions. >>> >>> Yep. That's why MSFT doesn't even try anymore. >> >> In the case of components I can't say: "it will work only on these >> scenarios >> and on these O.S. versions but if they have this Shell version >> installed". >> They already have a lot of problems with compatibility issues, I can't >> add >> more with a component. > > I understand. I wish MSFT had your same scruples. They simply say 9x is > "no longer supported." Even with XP, they virtually (totally?) require a > minimum of SP2, or you're on your own. Like I said, the situation is *so* > difficult, it's beyond their apparent capabilities. Woe be the indy dev, > huh? I think that something else is involved here. They are not going to sell new licenses of Win95/98/ME/etc. They already sold what they could sell of them in the past. But... if the people see that things don't work on their Win98/ME/etc, then they have to upgrade and purchase a Vista license. So... I think that at least in many cases, it's not the case that they can't make the programs compatible with old O.S. versions, or that it's too difficult (it may be true sometimes), it is that they just don't want to do it. My situation is different: I don't sell Windows's licenses. >>>> PS2: This should be a so usual necessity (to know where to write for >>>> all >>>> O.S. versions), that I'm amazed that we are discussing it just now. >>> >>> It only really started getting enforced in XP, and wasn't even that >>> rigid >>> until Vista. So, we could be sloppy for years, ignoring the Best >>> Practices. <shrug> >> >> I see that the "best practice" was to write to a folder that in some >> cases >> it didn't exist and in some other cases the O.S. wouldn't even tell me >> where >> I must create it. > > I'm firmly coming around to "screw that" for platforms MSFT doesn't > support anymore. In particular, 9x. Just stick the INI with the EXE, and > be done with it. How many of those systems are seriously used for > multi-users? It's not an INI file, but for the case it doesn't matter. Thank you very much Karl and also expvb for your help. You probably won't see me around here the next days because I'll travel tomorow and I think I'll come back next year. So, to all you: merry Chrismas and happy new year.
From: Karl E. Peterson on 21 Dec 2008 15:24 Eduardo wrote: >> I understand. I wish MSFT had your same scruples. They simply say 9x is >> "no longer supported." Even with XP, they virtually (totally?) require a >> minimum of SP2, or you're on your own. Like I said, the situation is *so* >> difficult, it's beyond their apparent capabilities. Woe be the indy dev, >> huh? > > I think that something else is involved here. > They are not going to sell new licenses of Win95/98/ME/etc. They already > sold what they could sell of them in the past. > But... if the people see that things don't work on their Win98/ME/etc, then > they have to upgrade and purchase a Vista license. Heh, ya think so? <g> Yeah, without question. > Thank you very much Karl and also expvb for your help. > > You probably won't see me around here the next days because I'll travel > tomorow and I think I'll come back next year. > So, to all you: merry Chrismas and happy new year. You're welcome. Happy holidays... -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 22 Dec 2008 15:44 expvb wrote: > "Karl E. Peterson" <karl(a)mvps.org> wrote ... >> For curiosity sake, I just fired up a Win95 (950b; build 1111) VM that's >> *almost* pure. The API returns these folders: >> >> CSIDL_APPDATA: C:\WINDOWS\Application Data >> CSIDL_LOCAL_APPDATA: C:\WINDOWS\Local Settings\Application Data >> CSIDL_COMMON_APPDATA: C:\WINDOWS\All Users\Application Data > > You must have installed something that updated the shell, or you are using a > different function. Decided to clean up my code and post it. http://vb.mvps.org/samples/SysFolders Be interested in any reactions, positive or otherwise <g>, from the folks following this thread. Thanks... -- ..NET: It's About Trust! http://vfred.mvps.org
From: expvb on 22 Dec 2008 17:29 "Karl E. Peterson" <karl(a)mvps.org> wrote in message news:um1HUYHZJHA.4456(a)TK2MSFTNGP04.phx.gbl... > expvb wrote: >> "Karl E. Peterson" <karl(a)mvps.org> wrote ... >>> For curiosity sake, I just fired up a Win95 (950b; build 1111) VM that's >>> *almost* pure. The API returns these folders: >>> >>> CSIDL_APPDATA: C:\WINDOWS\Application Data >>> CSIDL_LOCAL_APPDATA: C:\WINDOWS\Local Settings\Application Data >>> CSIDL_COMMON_APPDATA: C:\WINDOWS\All Users\Application Data >> >> You must have installed something that updated the shell, or you are >> using a >> different function. > > Decided to clean up my code and post it. > http://vb.mvps.org/samples/SysFolders > > Be interested in any reactions, positive or otherwise <g>, from the folks > following this thread. It looks fine, I have the following comments and suggestions: - Some constants require checking for the shell version number, although this is perhaps needed only for SHGetSpecialFolderLocation. See GetShellVersion() function here: http://news.jrsoftware.org/news/innosetup/msg69444.html See also these articles: How To Retrieve Language and Code Page id Using VerQueryValue http://support.microsoft.com/kb/160042 How to Use Functions in VERSION.DLL -- A 32-bit Sample App http://support.microsoft.com/kb/139491 - GetWindowsDirectory() could return per user folder under some OS variations, like Terminal Servers. I tested with Windows 2000 Server, and I got a folder under "C:\Documents and Settings\<UserID>\...". I don't remember the exact folder name, but I think it was like this: C:\Documents and Settings\<UserID>\WINDOWS In XP Pro, it returns "C:\WINDOWS\". In Windows 2000 Server, I think this is done because some applications store their INI file there, and Windows 2000 Server returns a per user folder so terminal services users don't overwrite each other's settings. I recommend leaving it as it is. To always get the real Windows folder, one could use CSIDL_WINDOWS. - TmpDir() does not check for the existence of the folder. In GetTempPath() remarks, it says for NT, the returned folder doesn't necessarily exist, so use IsDirectory() function and call MkDir as needed. - You may want to append "\" to the path if doesn't end with "\". Some users relocate their folders to another drive or partition, such as "D:\". Adding another backslash leads to errors for those who are unaware that users can do this. - You may want to make ForceCreation True by default. It's easy for others to test and find out that the folder was created already(in their machines), but if they forget that flag, some percentage of their users may not have the folder created, and get tech support calls. I recommend that you use CSIDL_FLAG_CREATE instead of using MkDir, just in case Windows creates the folder with specific permissions. I am not sure at which situations result in the folders not being created, perhaps if the admin just created a new user, and your program starts up from the Run key in the registry, I don't know.
From: Karl E. Peterson on 23 Dec 2008 17:49
Wow, that's some good feedback! I'll probably take ya up on most of it. Will go through piece by piece, as soon as time allows. Thanks! expvb wrote: > "Karl E. Peterson" <karl(a)mvps.org> wrote in message > news:um1HUYHZJHA.4456(a)TK2MSFTNGP04.phx.gbl... >> expvb wrote: >>> "Karl E. Peterson" <karl(a)mvps.org> wrote ... >>>> For curiosity sake, I just fired up a Win95 (950b; build 1111) VM that's >>>> *almost* pure. The API returns these folders: >>>> >>>> CSIDL_APPDATA: C:\WINDOWS\Application Data >>>> CSIDL_LOCAL_APPDATA: C:\WINDOWS\Local Settings\Application Data >>>> CSIDL_COMMON_APPDATA: C:\WINDOWS\All Users\Application Data >>> >>> You must have installed something that updated the shell, or you are >>> using a >>> different function. >> >> Decided to clean up my code and post it. >> http://vb.mvps.org/samples/SysFolders >> >> Be interested in any reactions, positive or otherwise <g>, from the folks >> following this thread. > > It looks fine, I have the following comments and suggestions: > > - Some constants require checking for the shell version number, although > this is perhaps needed only for SHGetSpecialFolderLocation. See > GetShellVersion() function here: > > http://news.jrsoftware.org/news/innosetup/msg69444.html > > See also these articles: > > How To Retrieve Language and Code Page id Using VerQueryValue > http://support.microsoft.com/kb/160042 > > How to Use Functions in VERSION.DLL -- A 32-bit Sample App > http://support.microsoft.com/kb/139491 > > - GetWindowsDirectory() could return per user folder under some OS > variations, like Terminal Servers. I tested with Windows 2000 Server, and I > got a folder under "C:\Documents and Settings\<UserID>\...". I don't > remember the exact folder name, but I think it was like this: > > C:\Documents and Settings\<UserID>\WINDOWS > > In XP Pro, it returns "C:\WINDOWS\". In Windows 2000 Server, I think this is > done because some applications store their INI file there, and Windows 2000 > Server returns a per user folder so terminal services users don't overwrite > each other's settings. I recommend leaving it as it is. To always get the > real Windows folder, one could use CSIDL_WINDOWS. > > - TmpDir() does not check for the existence of the folder. In GetTempPath() > remarks, it says for NT, the returned folder doesn't necessarily exist, so > use IsDirectory() function and call MkDir as needed. > > - You may want to append "\" to the path if doesn't end with "\". Some users > relocate their folders to another drive or partition, such as "D:\". Adding > another backslash leads to errors for those who are unaware that users can > do this. > > - You may want to make ForceCreation True by default. It's easy for others > to test and find out that the folder was created already(in their machines), > but if they forget that flag, some percentage of their users may not have > the folder created, and get tech support calls. I recommend that you use > CSIDL_FLAG_CREATE instead of using MkDir, just in case Windows creates the > folder with specific permissions. > > I am not sure at which situations result in the folders not being created, > perhaps if the admin just created a new user, and your program starts up > from the Run key in the registry, I don't know. -- ..NET: It's About Trust! http://vfred.mvps.org |