Announcement

Collapse
No announcement yet.

CHDIR/CHDRIVE misbehaving?

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

  • #21
    Prob. the same error as always.
    DO:

    1) Chdir( "d:\temp" )
    2) THEN CHdrive D:

    Your target path might be lost..


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

    Comment


    • #22
      Inno Setup (freeware, terrific)
      .. includes option to "start program" after install...

      MCM

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

      Comment


      • #23
        Lance, Eric
        now things are getting a little clearer in this dense old forest.
        The easy thing is to load everything onto the HD and run from
        there. The problem is that anybody can copy the program and
        that is undesirable. The floppy gives a modicum of protection
        (Yes, yes, I know, but it is better than nothing -- and so far
        so good, but that will change considerably in the near future).

        That Windows wants to keep the A: drive to load more program
        segments is fine. That is actually good. I just don't want the
        program to waste time looking for a DLL on the floppy when the
        "fast" version of it sits on the HD.

        What I cannot find out, though, is if the DLL is actually loaded
        from the floppy (the slow way) or if it just looks to see if the
        floppy is in the drive and then goes to the HD to do the loading
        (the fast way)? The DLL is some 130 KB and that should take some
        time but it all goes so fast that I sit here wondering.
        If the DLL is always loaded from the floppy then I should not
        waste launch time by copying to the HD? Can anyone shed some
        light on this?

        Michael -- thanks for telling about the Inno Setup. That should
        come handy later.

        Edwin -- I read your notice before. What is the logic here?
        Should one not specify a drive letter before specifying the
        path for the file? If one gives the full path then actually
        the drive letter should be superfluous?
        Nice talking to everyone. Thanks, Rolf



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

        Comment


        • #24
          The path search order for DLLs is not the same for different versions
          of Windows. If you must have a given version of a DLL, you should provide
          a full path in the ALIAS, or load dynamically with LoadLibrary. I think
          this is not a guarantee either, if the DLL is already loaded by another
          program (or another copy of the same program).


          ------------------
          Tom Hanlin
          PowerBASIC Staff

          Comment


          • #25
            Hi Tom,
            intriguing thought. Gave it a try. No difference.
            Then I thought if only one could put the path into the LIB name.
            The book does not say so, but you did. So I tried that too.
            Sorry, same difference. It would not have helped anyhow because
            that early in the program the working HD is not known.

            Then I took the system to the test to find out from where the
            DLL is loaded. It turns out the DLL is loaded from the HD!
            Excellent! That means the floppy only gets a curtesy buzz.
            Even better since I don't want the user to remove the floppy.
            So that is the end of this long inquiry. Many thanks, everyone.

            My congrats to Bob Zale.
            Had the occasion to generate one million random strings with
            20 A/N characters each. That took about 50 seconds.

            Then those strings were sorted with ARRAY SORT -- 5 seconds.

            Then the sorted one million strings were compared to see if
            there were any duplicates (none) -- less than one second. WOW!
            That is performance POWER! 1.2 GHz AMD Duron, DDR 2000.
            Rolf



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

            Comment


            • #26
              Rolf --

              > What I cannot find out, though, is if the DLL is actually loaded
              > from the floppy (the slow way) or if it just looks to see if the
              > floppy is in the drive and then goes to the HD to do the loading
              > (the fast way)?

              Remember, the DLL in question is being loaded dynamically. The first time the DLL is needed it is loaded in its entirety from the floppy (assuming that it is located there). The next time it is needed Windows simply checks the floppy, finds the DLL, and sees that the file is exactly the same one it loaded before. So it probably uses the copy that it has in its cache. That's probably why it is so fast. But even if you deleted the DLL from the floppy (or made it unfindable by putting it in a subdirectory on the floppy) Windows would always run the drive at least momentarily, to see if the DLL is there. As I have said, Windows always checks the directory where the EXE is located.

              > It turns out the DLL is loaded from the HD!

              How did you determine that? It seems unlikely, if I understand what you have said about this problem. If Windows "buzzes" the floppy drive it isn't a courtesy, it is looking for the DLL. And if it is there, it will be loaded from the floppy (or from the cached copy of the file on the floppy.)


              Tom --

              > The path search order for DLLs is not the same for different
              > versions of Windows.

              True, but the first place that is checked is always the EXE's location.

              > If you must have a given version of a DLL, you should provide
              > a full path in the ALIAS, or load dynamically with LoadLibrary. I think
              > this is not a guarantee either, if the DLL is already loaded by another
              > program (or another copy of the same program).

              Unless I am mistaken, it is a guarantee. If you specify a path in an ALIAS, or dynamically load a DLL using a full fath, Windows will always load exactly the file you specify. The only time it will use a copy of the DLL that is already in memory is if that exact file (based on location, not file contents) has already been loaded.

              Back to Rolf --

              It really seems like you are chasing your tail on this problem. I don't understand why you feel that placing the EXE on a floppy disk provides any measure of security for you. If somebody wants to steal your software, copying files from a floppy is not a big hurdle for them to overcome. IMO it would be much, much easier for you to add some simple security to your program than to change the way Windows looks for DLLs.

              -- Eric


              ------------------
              Perfect Sync Development Tools
              Perfect Sync Web Site
              Contact Us: mailto:[email protected][email protected]</A>



              [This message has been edited by Eric Pearson (edited May 22, 2003).]
              "Not my circus, not my monkeys."

              Comment


              • #27
                Unless I am mistaken, it is a guarantee. If you specify a path in an ALIAS, or dynamically load a DLL using a full fath, Windows will always load exactly the file you specify. The only time it will use a copy of the DLL that is already in memory is if that exact file (based on location, not file contents) has already been loaded
                You are not "mistaken," Eric, although the way you worded this, it sounds a tad funky.

                When a DLL - or any file - is "loaded" it is loaded by the operating system. All your program gets is a handle - its personal "key" to access the functions and/or resources in that DLL.

                Whether you specify load-time linking - that is, you use a DECLARE with a LIB statement - or dynamic linking (LoadLibary), the process is the same: Windows looks to see if the file is already loaded by the O/S; if it is, it gives you a handle to the already-loaded DLL. If it's not loaded, Windows loads it and returns a handle to the now-loaded version.

                In this case, when windows is asked to load "a:\foo.dll" at load time (DECLARE/LIB), that DLL remains loaded until all processes using that specific DLL are terminated - i.e, until the EXE ends.

                If the program now asks for "C:\foo.dll" with a dynamic call, that is loaded by the O/S separately and is subject to the same rules as above.

                In this case, if "a:\foo.dll" appears in the module list even before any LoadLibrary call, it is because the import table of the EXE said it needs the file, which is because the EXE file used a procedure for which LIB was DECLAREd.

                That is, if "A:\foo.dll" is loaded, it's because the program asked for it. When the program later explicitly asks for "C:\foo.dll" the OS loads that, too and returns a unique handle.

                For the curious to test for themselves?

                DECLARE a function with a LIB clause. When program starts, use GetModuleHandle and save handle.
                Now explictly load a DLL of the same name from a different folder. Compare the handle with the handle from GetModuleHandle. (will be different).
                Do another LoadLibrary on either file and compare handle - it will be the same.

                You can also test this using Lance Edmonds' code to "show processes and loaded modules" program which is available here (somewhere).


                MCM



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

                Comment


                • #28

                  CAN SetCurrentDirectory BE USED TO UPDIR
                  CHDIR "..\DATA2" USES THIS TO GO UP ONE DIRECTORY

                  wILL THIS SetCurrentDirectory ("..\DATA2") WORK TO GO UP ONE LEVEL DIRECTORY?
                  THANKS

                  Comment


                  • #29
                    SetCurrentDirectory function (winbase.h) - Win32 apps | Microsoft Docs
                    Dale

                    Comment


                    • #30
                      wILL THIS SetCurrentDirectory ("..\DATA2") WORK TO GO UP ONE LEVEL DIRECTORY?
                      What happened when you TRIED IT ????

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

                      Comment


                      • #31
                        Dale

                        Comment


                        • #32
                          Hello
                          Code:
                          GetCurrentDirectory(%MAX_PATH, ATXT)
                          
                          
                          TmpName = ATXT
                          SetCurrentDirectory "..\"' + TmpName
                          
                          
                          GetCurrentDirectory(%MAX_PATH, ATXT)
                          UP ONE LEVEL DIRCETORY
                          THANKS

                          Comment


                          • #33
                            Originally posted by James C Morgan View Post
                            Hello
                            Code:
                            GetCurrentDirectory(%MAX_PATH, ATXT)
                            
                            
                            TmpName = ATXT
                            SetCurrentDirectory "..\"' + TmpName
                            
                            
                            GetCurrentDirectory(%MAX_PATH, ATXT)
                            UP ONE LEVEL DIRCETORY
                            THANKS
                            Are you using PowerBASIC? If so, what's wrong with
                            '
                            Code:
                                ? CURDIR$
                                CHDIR "..\"
                                ? CURDIR$
                            '

                            Comment


                            • #34
                              Hello Stuart

                              YES POWER BASIC
                              NOTHING WRONG WITH CURDIR$
                              JUST ME SEEMS FASTER, AND MORE CONTROL, MOST CODE IS PORTABLE
                              A LEARNING EXPERIENCE
                              THIS IS WHAT MAKES POWER BASIC GREAT
                              A LOT OF THESE API GIVE A RETURN VALUE, ONCE I GET IT TO WORK
                              I MAKE A FILE AND ADD A SUB IT SIMPLIFY S THE THE USE
                              I WROTE THE PROGRAM IN POWER BASIC AND I AM CONVERTING IT TO SDK
                              THANKS FOR ASKING

                              Comment


                              • #35
                                James,

                                Two things, when you want to find out something, do a test on it like all of us have to do to try out a new idea. You get instant results and you don't have to wait for someone to make a comment. The other is a consideration for those of us who have older eyesight, the all UPPER CASE is really hard to read and humerously, it looks like you are shouting.

                                While both Get and Set current directory work fine, the intrinsic ones do as well. Converting to SDK style function calls is a good idea in the long term as you end up with a more portable skill.
                                hutch at movsd dot com
                                The MASM Forum

                                www.masm32.com

                                Comment


                                • #36
                                  do a test on it like all of us have to do to try out a new idea.
                                  Um, this idea does not seem to have been universally accepted.

                                  There may be some fear that "trying it" may cause damage to your hardware, software or data. But since the advent of Win/32, the WORST that can happen is a GPF in the test program.. which under Win/32 is no big deal like it was under Win/16.

                                  Assuming of course, your test program isn't updating files or databases. But learning to write test programs is a required skill anyway.

                                  Another required skill is making "How will I test this program?" part of of your design process. You usually learn to do that after you write a particularly brilliant program and then have to find a bug in it.. and discover your program has not been design to make testing easier and it takes longer than writing the program in the first place.

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

                                  Comment

                                  Working...
                                  X