PB ZIP & Vista..

[Tyrone W. Lee]

I have noticed that WindowVista doesn't seem to like ZLIB.DLL. I have seen a few threads online reporting how zlib.dll fails on vista. Has anyone else noticed this problem? Is there a solution?

I have been getting errors when I zip a .ini file used by by application. Does Vista "protect" .ini files? - I am getting permission errors when reading my own files.

Any suggestions on Vista/PB migration would be appreciated.

[Mel Bishop]

...Is there a solution?...

Vista doesn't like a lot of things.

[opinion]
Best bet would be to upgrade to xp.
[/opinion]

[Michael Mattias]

Does Vista "protect" .ini files? - I am getting permission errors when reading my own files.

UAC - not Vista - protects Folders. If that INI file is in a restricted folder (eg Program Files) that would be the expected behavior with the UAC enabled if you were writing... but I don't know you should get an error when reading.

I think if you 'run as' something important you can get total access to those folders anyway.

[William Burns]

Is the INI file still in use? How are you opening/reading the file?

I assume you also get an error when trying to copy the file in windows explorer too, right? What does the error say?

[Kev Peel]

ZLIB and INI files work perfectly fine in Vista, never had a problem. You may get write errors if you try to save files in protected folders under UAC or XP/Vista's "limited account" mode. This usually means anywhere in Program Files or the Windows directory.

[Tyrone W. Lee]

Open..

Simply trying to Open the file and read it. The file is zipped... So the app unzips and starts reading the contents.. Error 70 Permission Denied..

This has worked fine for Win2K & XP for many years.. I only recently started having problems on Vista.

The File is located under the Program Files\Explorations\INI folder.

I also have a \TEMP folder that is getting permission errors.

Whats the alternative to saving instance data for you app? or temporary area to build/parse and compile data?


For the record,
I don't use Vista.. I am and forever will be Windows 2000Pro. This is an error that the software is reporting to my server from one of my customers..

Tye

[Tyrone W. Lee]

Hello any one there?

So how do you handle reading/writing your own .INIs and other files under Vista? If the OS is locking you program folder and all sub-folders, where are we supposed to read/write special files? - Registry? - (I have ALOT of files.)

Any help would be appreciated.

Tye

[Kev Peel]

It has been a recurring subject on the forum for at least 2 years now

Here's what I use: Multi-User Support in Your Applications

[Michael Mattias]

> Here's what I use...

In that post you have ...

" function to obtain a user-specific folder to store data files and settings for your applications. If the system cannot get a user-specific folder, then the application path is used instead."

If the user-specific folder is not found, you are right back at trying to write in verboten territory with UAC enabled and the EXE in the 'usual place', namely somewhere under "Program Files"

This demo here..
Move That INI File! and Get That Ini File Name!

.. uses the same system functions, but also offers automatic "create folder" if not found.

It's what I used to migrate my applications from "old way" with the INI file in the same path as the EXE to the "new way" with the INI file in either APPDATA or COMMONAPPDATA.

At startup, if I can't find the INI file in the "new " location, I look for it in the old. When found there, I copy it to the new location. After that the program will always find and use the INI file in the 'new' location. If UAC is enabled, you cannot delete the INI from the "old" location (where the EXE is located), so that's another problem you have to deal with; however, because your application is now doing it's INI thing in a folder where it does have write permissions, it will run instead of erroring out every time you try to write to the INI file.

MCM

[Kev Peel]

If the user-specific folder is not found, you are right back at trying to write in verboten territory with UAC enabled and the EXE in the 'usual place', namely somewhere under "Program Files"

Not quite. All it means if the OS is does not support SHGetSpecialFolderPath then the application path is used. If the OS does not support SHGetSpecialFolderPath then it most certainly will not support UAC.

Is you cared to look at the code you will see it also creates the required subfolders automatically. The INI file handling is pretty simple: either use the szDefault parameter of each GetPrivateProfileString, or supply a pre-written INI in the program folder and copy it over when required. My INI wrapper code is located here

This code is tried and tested on systems world-wide for almost 4 years now. I have never had a problem with it, nor do I expect to.

[Michael Mattias]

I see now that it creates one level of subfolder. (I could not do that because I always use two levels... company name and application name)

However, the problem is not that the function returns the application path... it's that with UAC enabled you can't write in the application path. That is, you can FIND your INI file and READ from it, but WRITING in a 'protected' folder is not allowed.

If this is a new installation or done during an upgrade this is usually not a problem, as the 'installer' perforce has the permissions required to create the (new) folder and deposit the default or existing INI file there.

[Kev Peel]

But the point is SHGetSpecialFolderPath will not fail on Vista (and XP which also has folder protection on "limited" accounts, it's not just UAC which presents a problem). The "return app path" feature essentially is a safety net for old systems where SHGetSpecialFolderPath is not present, note the dynamic load-on-call. I read all about support for this function on MSDN several years back.

If SHGetSpecialFolderPath fails on Windows 2000, XP or Vista, then there is something very wrong with the Windows installation. Period.


Aside from that, one thing some (many?) programmers do not know is that their apps will fail on Windows XP if they try to write to "Program Files" on a limited user account. UAC doesn't come into it, this was happening way before UAC.

The days of safely opening a file for read/write under Program Files died when XP was released - 2001.

[Michael Mattias]

Then again....

If ShGetSpecialFolderPath DOES return "application path" I guess you could detect that and 'do something' at that time.... like tell the user his installation is corrupt... ???

[Kev Peel]

If that function ever failed, the user would most probably find that out pretty quickly as no apps would work

[Michael Mattias]

If that function ever failed, the user would most probably find that out pretty quickly as no apps would work

If it FAILED, yes; but if it returned the application folder? All his other applications would be working just fine.

My concern was with never again spending all the support time screwing around with users who told me, "Oh, I didn't use the supplied update program to update, or my install disk to re-install on my new computer, I just used Explorer to move the files to a new location. It was lots faster to do it that way."

Kind of makes you long for a really good "New Feature Suggestion":

     SENDVOLTSTOUSER  [i]volts&[/i] [,[i]repeatcount&[/i]]

MCM