Announcement

Collapse
No announcement yet.

PB ZIP & Vista..

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • PB ZIP & Vista..

    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.
    Explorations v9.10 RPG Development System
    http://www.explore-rpg.com

  • #2
    Originally posted by Tyrone W. Lee View Post
    ...Is there a solution?...
    Vista doesn't like a lot of things.

    [opinion]
    Best bet would be to upgrade to xp.
    [/opinion]
    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.

    Comment


    • #3
      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.
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        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?
        "I haven't lost my mind... its backed up on tape... I think??" :D

        Comment


        • #5
          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.
          kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

          Comment


          • #6
            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
            Explorations v9.10 RPG Development System
            http://www.explore-rpg.com

            Comment


            • #7
              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
              Explorations v9.10 RPG Development System
              http://www.explore-rpg.com

              Comment


              • #8
                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
                kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

                Comment


                • #9
                  > 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
                  Michael Mattias
                  Tal Systems Inc. (retired)
                  Racine WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    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.
                    Last edited by Kev Peel; 11 May 2009, 10:52 AM.
                    kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

                    Comment


                    • #11
                      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.
                      Michael Mattias
                      Tal Systems Inc. (retired)
                      Racine WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        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.
                        Last edited by Kev Peel; 11 May 2009, 12:25 PM.
                        kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

                        Comment


                        • #13
                          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... ???
                          Michael Mattias
                          Tal Systems Inc. (retired)
                          Racine WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            If that function ever failed, the user would most probably find that out pretty quickly as no apps would work
                            kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

                            Comment


                            • #15
                              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":
                              Code:
                                   SENDVOLTSTOUSER  volts& [,repeatcount&]
                              MCM
                              Michael Mattias
                              Tal Systems Inc. (retired)
                              Racine WI USA
                              [email protected]
                              http://www.talsystems.com

                              Comment

                              Working...
                              X