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: Karl E. Peterson on 19 Dec 2008 21:36 C Kevin Provance wrote: > Looks like I posted a little too late. Good call tho, eh? <g> Nailed it. (Note, I had my suspicions as well, hence the test! <bg>) -- ..NET: It's About Trust! http://vfred.mvps.org
From: Eduardo on 19 Dec 2008 21:40 "Karl E. Peterson" <karl(a)mvps.org> escribi� en el mensaje news:OVLIsPkYJHA.2572(a)TK2MSFTNGP05.phx.gbl... >> 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. >> 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.
From: expvb on 19 Dec 2008 22:00 "Karl E. Peterson" <karl(a)mvps.org> wrote in message news:%23aHQSjkYJHA.552(a)TK2MSFTNGP06.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. > > Found it. I built a brand spanking new OSR2 VM, and *none* of the three > above folders were present. > > Installed the "Virtual Machine Additions" that came with VPC2004, and *all > three* of the above folders appeared. In my copy, the only thing in Add/Remove Programs is "Virtual Machine Additions". I have the folders, but SHGetSpecialFolderLocation() returns errors for these constants as I posted in this thread previously.
From: Karl E. Peterson on 20 Dec 2008 13:14 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? >>> 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? -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 20 Dec 2008 13:20
expvb wrote: > "Karl E. Peterson" <karl(a)mvps.org> wrote ... >> 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. >> >> Found it. I built a brand spanking new OSR2 VM, and *none* of the three >> above folders were present. >> >> Installed the "Virtual Machine Additions" that came with VPC2004, and *all >> three* of the above folders appeared. > > In my copy, the only thing in Add/Remove Programs is "Virtual Machine > Additions". I have the folders, but SHGetSpecialFolderLocation() returns > errors for these constants as I posted in this thread previously. What about SHGetFolderPath? That's what I use, when it's available. Which it should be, if you installed the VMAs, as they put shfolder.dll into the system folder. -- ..NET: It's About Trust! http://vfred.mvps.org |