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 19 Dec 2008 20:28 "expvb" <nobody(a)cox.net> escribi� en el mensaje news:eByGU%23jYJHA.5520(a)TK2MSFTNGP02.phx.gbl... > "Eduardo" <mm(a)mm.com> wrote in message > news:gihc2j$ot5$1(a)news.motzarella.org... >> "Karl E. Peterson" <karl(a)mvps.org> escribi� en el mensaje >> news:e83hj8iYJHA.552(a)TK2MSFTNGP06.phx.gbl... >> >> I have to say that I didn't understand this phrase: >> >>> you're pretty danged well off forcing the creation of the folder when >>> you first create the INI file, otherwise you might have some real >>> difficulties later when you come back to look for it. > > It's a good habit to check if the folder exists and create it if > necessary. For example, GetTempPath() returns the temp folder, but the > folder does not necessarily exist. See the remarks section for Windows > NT/2000/XP. > > If you are using CSIDL vales, add CSIDL_FLAG_CREATE. To check if a folder > exists, you can use the following VB6 function: > > http://vbnet.mvps.org/code/fileapi/folderexists.htm Well, but if I just use APPDATA in NT + Shell version >= 5, do you still think that it's necessary to check for the existence of the folder? [...] >> The other question is: do you think that now or in some future time it >> can be any trouble with it? I mean, do you think that some firewalls >> programs could do the same "nanny" work as Vista does on itself, but on >> 95/98/ME and disallow to write to "Programs files\appname" or >> "Windows\appname" or wherever? > > Applications that secure a system, maybe. Then the more secure way to avoid any trouble would be to try to retrieve CSIDL_APPDATA in any OS and/or Shell version, then if it returned an error or if it returned nothing, use another location (like App.Path), but if it returned something, check if the folder already exists, if it doesn't exist, then create the folder with the full path if it's necessary. A lot of work.... but what do you think? > If you have a Windows 9x that has shell version 5.00, maybe if you use the > CSIDL, there might be an advantage if the user later upgraded to XP or > later, the setting could be moved to the proper location, so the user > doesn't have to reinstall your application. I am not sure if the upgrade > wizards even support this, I am just guessing at what the advantages of > using CSIDL in Windows 9x might be. Yes.. that's another problem. Also apply when they are upgrading your application. You need to move the data from where it was before to where it will be now.
From: Karl E. Peterson on 19 Dec 2008 20:32 C Kevin Provance wrote: > Did you install those Powertoys individually or from one package. I seem to > recall the powertoys package having a shell update for Win95. Pretty sure those were the old .INF file driven installs, which were downloaded together but installable one at a time. Dir listing below. As you can see, most are very old, and the ones I installed I'm sure it was by just right-clicking the INF and choosing Install... H:\Common\Setups\Patches\PowerToys\Windows>dir Volume in drive H is work groups Volume Serial Number is 0C74-38DA Directory of H:\Common\Setups\Patches\PowerToys\Windows 09/01/2005 04:21 PM <DIR> . 09/01/2005 04:21 PM <DIR> .. 08/08/1995 02:53 PM 25,088 APLAYEXT.DLL 08/08/1995 03:47 PM 2,257 APLAYEXT.INF 10/11/1995 01:40 PM 61,440 CABVIEW.DLL 08/03/1995 09:10 AM 1,588 CABVIEW.INF 10/20/1994 11:29 AM 16,336 CLOCK.EXE 08/04/1995 05:46 PM 13,824 CONTENT.DLL 11/14/1995 04:45 PM 1,517 CONTENT.INF 08/01/1996 10:36 AM 18,432 DESKMENU.EXE 07/01/1996 03:08 PM 1,676 DESKMENU.INF 11/16/1996 10:34 PM 1,710 DOSHERE.INF 08/09/1995 12:13 PM 1,046 EXPLORE.INF 09/01/1996 01:22 PM 13,824 FINDX.DLL 08/31/1996 11:09 PM 3,063 FINDX.INF 08/13/1995 02:42 PM 35,328 FLEXICD.EXE 03/07/1996 07:12 PM 3,328 FLEXICD.INF 08/26/1996 11:58 PM 970 INSTALL.INF 12/12/1996 08:36 AM 209,241 POWERTOY.EXE 10/19/1995 03:11 PM 19,392 QUICKRES.EXE 11/14/1995 04:53 PM 1,012 QUICKRES.INF 11/17/1996 10:32 PM 9,732 README.TXT 09/01/1996 01:28 PM 33,792 SENDTOX.DLL 06/30/1996 08:13 PM 5,005 SENDTOX.INF 08/07/1995 03:19 PM 8,192 SHELLFIX.DLL 08/07/1995 04:48 PM 977 SHELLFIX.INF 10/25/1995 05:41 PM 8,704 TAPITNA.EXE 11/17/1996 01:26 PM 24,064 TARGET.DLL 11/17/1996 12:12 AM 1,829 TARGET.INF 04/15/2000 10:05 AM 5,825 TWEAKUI.CNT 06/18/2000 02:03 PM 106,544 TWEAKUI.CPL 04/15/2000 10:13 AM 51,238 TWEAKUI.HLP 11/22/1999 04:28 PM 2,991 TWEAKUI.INF 10/04/2001 07:56 AM 113,040 tweakui.zip 09/01/2005 04:21 PM 150,192 TweakUiPowertoySetup.exe 02/26/1996 11:38 PM 4,512 XMOUSE.EXE 34 File(s) 957,709 bytes 2 Dir(s) 489,165,684,736 bytes free H:\Common\Setups\Patches\PowerToys\Windows> -- ..NET: It's About Trust! http://vfred.mvps.org
From: Bill McCarthy on 19 Dec 2008 20:31 "Karl E. Peterson" <karl(a)mvps.org> wrote in message news:%23GerdCkYJHA.1528(a)TK2MSFTNGP03.phx.gbl... > Bill McCarthy wrote: >> "Karl E. Peterson" <karl(a)mvps.org> wrote ... >>> Well, no, I don't have a totally "clean" Win95 machine to verify that >>> on. >> >> If you're using VPC you should look at using differencing discs. Makes it >> easy to rollback. > > Differencing disks (coming to terms with) have been on my TODO list for > too long now! > I use to use them. The idea is you have two .vhd's. One is the pure one form the install. You create a differencing disk from it and mark the original as read-only. This is best suited to quick tests such as build and deployment tests. If you are using it over time, I find/think (no metrics on it) performance degrades as the differencing disc gets larger. You also have the problem of updating the original OS will be on the differencing disc not the main disc. >> Admittedly these days hard disc space is so cheap I tend to just copy >> entire >> VPCs as soon as I create them. > > Yep. That's what I'm doing now, too. Store a clean one, then store a > couple more with various common scenarios, and build from there as needed. > -- That's what I do if I'm working on betas or the like where I want to use the VPC a lot, I make a complete copy. But if you are doing a lot of deployment tests during the day, using differencing discs and just copying them is a lot less disc thrashing.
From: Karl E. Peterson on 19 Dec 2008 20:40 Eduardo wrote: > I have to say that I didn't understand this phrase: > >> you're pretty danged well off forcing the creation of the folder when you >> first create the INI file, otherwise you might have some real difficulties >> later when you come back to look for it. The problem I foresaw was if you were to query the OS for LOCAL_APPDATA and were told it was the same as APPDATA. You might just go ahead and create your *local* INI file there. Later, for whatever reason (shell update?), the LOCAL_APPDATA path is reset to some new location. At this point, your app won't be able to find that original INI file. > On other hand: > I decided not to use the APPDATA folder in not NT systems (95/98/ME), and > just to write to somewhere else on those O.S. versions as I used to do in > the past. I think that's generally a safe bet. Probably only the *tiniest* fraction of 9x systems still in use are setup for robust multi-user work patterns. > The other question is: do you think that now or in some future time it can > be any trouble with it? I mean, do you think that some firewalls programs > could do the same "nanny" work as Vista does on itself, but on 95/98/ME and > disallow to write to "Programs files\appname" or "Windows\appname" or > wherever? Nope. 9x isn't going to all of a sudden "get" multiuser. Very safe bet. > 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. > 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> -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 19 Dec 2008 20:54
Bill McCarthy wrote: > "Karl E. Peterson" <karl(a)mvps.org> wrote ... >> Bill McCarthy wrote: >>> "Karl E. Peterson" <karl(a)mvps.org> wrote ... >>>> Well, no, I don't have a totally "clean" Win95 machine to verify that >>>> on. >>> >>> If you're using VPC you should look at using differencing discs. Makes it >>> easy to rollback. >> >> Differencing disks (coming to terms with) have been on my TODO list for >> too long now! > > I use to use them. The idea is you have two .vhd's. One is the pure one > form the install. You create a differencing disk from it and mark the > original as read-only. > This is best suited to quick tests such as build and deployment tests. If > you are using it over time, I find/think (no metrics on it) performance > degrades as the differencing disc gets larger. You also have the problem of > updating the original OS will be on the differencing disc not the main disc. I do something similar, though it may be more frustrating at times. I just turn on the Undo disk thingie, so that after doing a bunch of tests I can just click the [X] and tell it to Close and Discard Changes. Occassionally, if I want to make permanent changes, I'll disable the Undo, do the change, then re-enable Undo. Seems to work pretty well. >>> Admittedly these days hard disc space is so cheap I tend to just copy >>> entire VPCs as soon as I create them. >> >> Yep. That's what I'm doing now, too. Store a clean one, then store a >> couple more with various common scenarios, and build from there as needed. > > That's what I do if I'm working on betas or the like where I want to use the > VPC a lot, I make a complete copy. But if you are doing a lot of deployment > tests during the day, using differencing discs and just copying them is a > lot less disc thrashing. I should probably take the time to try them out, sometime. -- ..NET: It's About Trust! http://vfred.mvps.org |