Announcement

Collapse
No announcement yet.

Program independency

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

  • Program independency

    Are other developers now avoiding making entries
    in the registry and placing all required DLL's
    in the application folder?
    I use third party products and hope that other
    PB developers are doing the same.

    How long is an idea? Write it down.

  • #2
    Mike;

    I read something on the web about Microsofts new "view" on DLLs and the registry, with Windows 2000 apps.

    If I understand it correctly, now they want you to put your DLLs in the Apps folder and not in the Windows\system folder. The registry and windows\system folder should only be used for system DLLs (and a few universal type DLLs that need Registry access).

    I think with the largeer hard drives today, redundant copies of DLLs is not a big problem anymore. I think the Registry has been "over" used for stuff today. MS is encouraging the use of your own configuration files now as well. Most PCs have their Registry bloated with stuff and many ininstall programs don't remove Registry entries properly, so a bunch of left over entries exist in the registry.

    Chris Boss
    Computer Workshop
    Developer of "EZGUI"
    http://cwsof.com
    http://twitter.com/EZGUIProGuy

    Comment


    • #3
      Thanks, Chris. I hope other developers read this.
      How long is an idea? Write it down.

      Comment


      • #4
        This is good news. Being an old hand in this game I refused from day 1 to deploy entire applications anywhere but their own directory (when possible even the .ini files). The argument about disk storage has never been a strong one.

        However, the saving of memory through the use of DLLs is a valid argument. What Microsoft should really do in addition to this guideline is to come up with a naming convention for DLLs (JAVA components have this option.)

        With unique names and everything in the same directory installing / un-installing apps would be foolproof and the OS will remain clean and a lot more stable.

        The hidden cost of support for the current mess must have run into hundred of millions (if not billions) over the years.

        I hope too that the developer community would take notice.

        Siamack

        Comment


        • #5
          If it's a 3rd party dll, it's not necessarily a good idea to put it in your own directory. If you have more than one program on the machine using the DLL it can cause confusion. I don't know if the following holds true in the 32-bit land, but it does in 16. When a program needs a dll it searches in this order:
          1. Memory
          2. Application directory
          2. Windows
          3. Windows\System
          4. The path

          This can lead to obvious problems - if two programs are using vbrun300.dll for example. And they have different versions and both are in the application directory. If you run both applications simultaneously, the 2nd program will use the 1st programs copy of vbrun300.dll because it's already in memory. I don't know if this applies to 32-bit programs or not.

          --Don
          Don Dickinson
          www.greatwebdivide.com

          Comment


          • #6
            This is from the SDK information, search path for a DLL as follows:

            1. The directory from which the application loaded.
            2. The current directory.
            3.

            Windows 95: The Windows system directory. Use the GetSystemDirectory function to get the path of this directory.

            Windows NT: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32.

            4.

            Windows NT: The 16-bit Windows system directory. There is no Win32 function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM.


            5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.


            6. The directories that are listed in the PATH environment variable.
            -------------
            Kev G Peel
            KGP Software
            Bridgwater, UK.
            mailto:[email protected][email protected]</A>

            Comment


            • #7
              Thanks for the info Kev. I did verify on my own that Win32 does not make copies of dlls already in memory when a new program launches. It will grab the version of the DLL that's in the application directory and use that instead of the one that's already loaded. This is a big improvement over 16-bit windows. There is still one question, though, what about and OCX? I wonder if an OCX (it's an inprocess server, I think) will grab the dll from the application's directory or if it will go from windows system. I know the OCX itself is loaded from where it's registered, but I don't know where a DLL needed by the OCX gets pulled from.
              --Don
              Don Dickinson
              www.greatwebdivide.com

              Comment


              • #8
                OCXs are a different animal, I think !

                I think the Registry comes into play with OCXs (the actual location is placed in the registry) and the above arguments may not apply.

                This is one reason, I prefer DLLs over OCXs. While, the basic concept of components isn't so bad, the "implimentation" of components has inherent problems. I think MS went a little too far with OCXs. Too much much overhead !

                Chris Boss
                Computer Workshop
                Developer of "EZGUI"
                http://cwsof.com
                http://twitter.com/EZGUIProGuy

                Comment


                • #9
                  What I prefer to do is get the windows(or winnt) directory and have a directory of my own in the common folder. Put all my common stuff like dll's, ocx's ini's.....
                  That way i try to follow the all original concept of sharing and yet not colghup the system....

                  ------------------
                  Niraj Bhatt

                  Comment


                  • #10
                    Chris, my question isn't where the OCX comes from (it comes from where ever the registry says it should), but where an OCX that calls a DLL pulls the dll from. No big deal because I don't use OCXs very often, just a curiosity.
                    Best Regards,
                    Don

                    ------------------
                    Don Dickinson
                    www.greatwebdivide.com

                    Comment


                    • #11
                      Hi Mike,

                      I hope people here don't mind me pointing to my own product -
                      but I think it addresses this problem exactly. I created
                      a system that allows developers to deploy applications that
                      use 3rd party libraries as a single file. You can don't need
                      to worry about extracting files, and the system registry never
                      needs to be modified. It works on the idea of a virtual file system
                      and virtual registry being available to your application. This
                      permits application to use 3rd party COM/ActiveX controls without
                      no installation at all – just download and run. Examples are for VB,
                      but it supports PowerBasic. I realize that most people here are probably
                      hobby programmers and can't afford it, but thought I'd mention
                      anyway:
                      http://thinstall.com/help/index.html...imelinking.htm

                      The closest thing I’ve heard to this are 2 products called VB Powerwrap
                      and “Fusion”. Both of these must install components in the background –
                      and I don’t think they support PowerBasic.

                      Jonathan Clark


                      ------------------

                      Comment


                      • #12
                        I will need to study it. This is Thin Ininstall, right?
                        Does it use alot of memory? Compatibility?

                        ------------------
                        How long is an idea? Write it down.

                        Comment


                        • #13
                          Yes, it's Thinstall. This page describes the additional overhead of running in this system: http://thinstall.com/help/runtimeresourceussage.htm

                          and this page describes compatability: http://thinstall.com/help/supportedexes.htm


                          ------------------

                          Comment


                          • #14
                            Yes, i recommend the app dir.
                            We even do it with our 16bit VB3 apps since ~1.5 year or so.
                            At least we gave the option to place them in the same dir.
                            For 16bit's this was a conflicting situation like for graph.vbx which loaded dll's from the system dir instead.
                            We simply took this road since this 16bits sofware was becomming obsolete anyway.

                            OCX's are single install components, it doesn't care where it's being installed.
                            We have an ocx on a NW drive for intranet usage.

                            That's the biggest problems with OCX's, there registry mess.


                            ------------------
                            http://www.hellobasic.com
                            hellobasic

                            Comment


                            • #15
                              First I need to say that I never used myself such a packager, but I closely follow intense discussions about those types of applications and the outcome was never really statisfying..one way or another.

                              The problem with these type of packagers is that there's no guarantee that they're "clean up the mess" 100%. What if the machine/application crashes?

                              The web site states:
                              Can be run from any user account, even if system registry access is denied.
                              There might be good reasons why registry access is denied and therefore applications can't be installed/started. Circumventing such company policies might cause heavy security issues.

                              Knuth

                              ------------------
                              http://www.softAware.de

                              Comment


                              • #16
                                Tal Systems' products ...

                                1. All exe, application DLLs, INI file and 'system' support files go in folder with main EXE(s).
                                2. User-maintainable data (transactions, master files, etc) go in user-specified folders/files (folder/file names held as INI file parameters).
                                3. I design so that I do not ever need to replace a "system" DLL. When necessary (rare) I check the version of said system DLL. (Usually the Common Controls). (It helps that I use an older machine for main development: I'll know right away if I'm using an API call which has a minimum system requirement>Win98). (*)
                                4. I have (I think) only two or three customers who have purchased more than one product with any common DLLs. For the 200K or so disk space, I just install said file in two places.
                                5. All EXEs and DLLs provided include a version resource. (VERY MUCH RECOMMENDED).

                                All these products are low-cost, limited purpose applications directed at 'Suzy User,' who is, shall we say, <U>many</U> credit-hours short of her Masters' degree, if you get my drift.

                                I only recently started storing in the registry the name of the install folder. From there I can find everything, and it's more reliable than Suzy remembering in which folder she originally installed.

                                MCM
                                * Currently updating The Provider Payment Partner(tm) System to support database connection under ODBC-2 as well as ODBC-3. Now I know why they considered ODBC-2==>ODBC-3 an upgrade. Sheesh, using only ODBC-2 is really the 'long way' to do certain things. (Tough to find ODBC-3 drivers for "brand O", a very popular DBMS, that's why).


                                [This message has been edited by Michael Mattias (edited October 22, 2003).]
                                Michael Mattias
                                Tal Systems Inc. (retired)
                                Racine WI USA
                                [email protected]
                                http://www.talsystems.com

                                Comment


                                • #17
                                  Hi Knuth,

                                  Yes, it's a very complex piece of software and it does not work in
                                  100% of cases. In the cases where it doesn't work we can look
                                  into the problem and solve it. It's pretty easy to tell if it will work
                                  or not by running your application on a clean version of Windows
                                  95/98 and 2k with no components registered or DLLs installed.

                                  The reason system administrators restrict access to the system registry
                                  is to prevent other installers from modifying registry keys that
                                  will cause previous software installations to fail. By restricting
                                  registry access, they lower their support cost because the users
                                  can't mess up the machine as easily. When they have one IT person
                                  for 100 users this becomes very important. So many large companies
                                  and universities do this.

                                  However, this is bad for you - if you want someone at the company
                                  to try a demo of your software, they will have to get the IT person
                                  to install it - which he/she may not do if they don't trust your
                                  installation methodology.

                                  Thinstall makes it so VB programs & their controls don't need to modify
                                  the system registry - it simulates a virtual registry for your application
                                  and the OCX controls it uses. It does not acquire any special system
                                  permissions to do this - you could do the same thing if you rewrote
                                  the program in C and used libraries instead of ActiveX OCX files.
                                  So it's not circumventing any system policy - and it helps keep your
                                  support cost down as well as theirs because other installers can't
                                  cause your application to fail any more (for example if DLLs, OCX files
                                  are deleted or unregistered).

                                  There are a huge number of problems that can occur when using OCX files,
                                  during installation, during running, and during uninstall. For a discussion
                                  on this topic see this page:
                                  http://thinstall.com/help/comactivexinstallationhel.htm

                                  Jonathan


                                  ------------------

                                  Comment


                                  • #18
                                    It's really hard for shareware / freeware developers to
                                    buy a license for thinstall (imho).
                                    Alternative you could look at http://www.collakesoftware.com/
                                    and get pebundle.

                                    ------------------

                                    Comment


                                    • #19
                                      Another thing to look at is the latest release (4.x) of Inno Setup. I think: http://www.jrsoftware.org

                                      They've added a place where you can add Pascal code which gets executed during the install, and if you return false (or maybe you return true), the install stops.

                                      That kind of capability would let you check the currently isntalled versions of these various shared DLLs and only install if necessary, or abort the install with an appropriate message.

                                      (Note that Inno Setup will already automatically check version numbers, and not replace a file of same or higher version unless you tell it to ignore the version).

                                      No sense installing something already installed which is of sufficient version to run your application.

                                      It's a thought.

                                      MCM

                                      Michael Mattias
                                      Tal Systems Inc. (retired)
                                      Racine WI USA
                                      [email protected]
                                      http://www.talsystems.com

                                      Comment


                                      • #20
                                        As I'm both developer *and* admin...

                                        Originally posted by Jonathan Clark:
                                        The reason system administrators restrict access to the system registry
                                        is to prevent other installers from modifying registry keys that
                                        will cause previous software installations to fail. By restricting
                                        registry access, they lower their support cost because the users
                                        can't mess up the machine as easily. When they have one IT person
                                        for 100 users this becomes very important. So many large companies
                                        and universities do this.
                                        No, the reason is that users shouldn't install/run unauthorized software.

                                        However, this is bad for you - if you want someone at the company
                                        to try a demo of your software, they will have to get the IT person
                                        to install it - which he/she may not do if they don't trust your
                                        installation methodology.
                                        That's exactly it. No one should run any software without permission (inlcuding my applications).

                                        As I said: I consider this to be a real security issue.

                                        Knuth


                                        ------------------
                                        http://www.softAware.de

                                        Comment

                                        Working...
                                        X