DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 8 of 8

Thread: DLL **** !

  1. #1
    Abdel K. Belkasri Guest

    DLL **** !


    Hi all,

    I have written an application that is supposed to always be run from the
    CD-ROM. so I put all the DLLs and the support files in the root directory
    of the CD-ROM where the exe of the application is located. It worked fine
    on win98, win2000. But on some win95 we got the following error:

    "OLEAUT32.DLL file is out of date"

    I don't understand ! it's supposed to look for the any DLL at the current
    directory, and only if it doesn't find it, then it should look in Windows\system

    How to fix that?

    --Abdel.

  2. #2
    Shelly Rosenfeld Guest

    Re: DLL **** !


    Win 95 2nd edition has the right version (OLE Automation) dll.

    Copy to a floppy, and then to the bad machine.

    Sheldon

    Abdel K. Belkasri <abdelb@riseintl.com> wrote in message
    news:394a83e4$1@news.devx.com...
    >
    > Hi all,
    >
    > I have written an application that is supposed to always be run from the
    > CD-ROM. so I put all the DLLs and the support files in the root directory
    > of the CD-ROM where the exe of the application is located. It worked fine
    > on win98, win2000. But on some win95 we got the following error:
    >
    > "OLEAUT32.DLL file is out of date"
    >
    > I don't understand ! it's supposed to look for the any DLL at the current
    > directory, and only if it doesn't find it, then it should look in

    Windows\system
    >
    > How to fix that?
    >
    > --Abdel.




  3. #3
    Douglas J. Steele Guest

    Re: DLL **** !

    While what you're saying about where it looks for DLLs (current directory,
    then the system directory) was true in the 16-bit world, it isn't
    necessarily so in the 32-bit world. COM objects need to registered: what's
    in the registry tells the program where to find the relevant object.

    --

    Doug Steele, Microsoft Access MVP
    Beer, Wine and Database Programming. What could be better?
    Visit "Doug Steele's Beer and Programming Emporium"
    http://I.Am/DougSteele/


    Abdel K. Belkasri <abdelb@riseintl.com> wrote in message
    news:394a83e4$1@news.devx.com...
    >
    > Hi all,
    >
    > I have written an application that is supposed to always be run from the
    > CD-ROM. so I put all the DLLs and the support files in the root directory
    > of the CD-ROM where the exe of the application is located. It worked fine
    > on win98, win2000. But on some win95 we got the following error:
    >
    > "OLEAUT32.DLL file is out of date"
    >
    > I don't understand ! it's supposed to look for the any DLL at the current
    > directory, and only if it doesn't find it, then it should look in

    Windows\system
    >
    > How to fix that?
    >
    > --Abdel.




  4. #4
    Jose Guest

    Re: DLL **** !


    "Abdel K. Belkasri" <abdelb@riseintl.com> wrote:
    >
    >Hi all,
    >
    > I have written an application that is supposed to always be run from the
    >CD-ROM. so I put all the DLLs and the support files in the root directory
    >of the CD-ROM where the exe of the application is located. It worked fine
    >on win98, win2000. But on some win95 we got the following error:
    >
    > "OLEAUT32.DLL file is out of date"
    >
    >I don't understand ! it's supposed to look for the any DLL at the current
    >directory, and only if it doesn't find it, then it should look in Windows\system
    >
    >How to fix that?
    >
    >--Abdel.



    I've had the same problem many times, and in most of the cases I found a
    mismatched set of dlls (usually comcat.dll, oleaut32.dll olepro32.dll, stdole2.tlb,
    and msvbvm60.dll) on the target machine. (less common you have to check under
    which version of Visual Basic you have compiled your project, so that you
    know whar versions of dlls you have to distribute with your applications).


    I usually avoid replacing/copying directly dlls to the target machine, specially
    when dealing with VB run-time related DLLs.

    My recommendation in this case is to download Visual Basic's runtime dlls
    from Microsoft's website and install it on the machines where you have the
    oleaut32.dll problem.

    You may find VB Runtime SP3 at
    http://support.microsoft.com/support.../Q235/4/20.asp

    A brief description of what each dll is for is at:
    http://support.microsoft.com/support.../Q190/1/30.asp

    Hope this helps...

  5. #5
    Shelly Rosenfeld Guest

    Re: DLL **** !


    Sorry, just that I once experienced this problem at a user,
    and a search of MSDN revealed that a new OLEAUTIL was
    in order.

    Sheldon

    Douglas J. Steele <djsteele@idirect.com> wrote in message
    news:394aa3c3$1@news.devx.com...
    > While what you're saying about where it looks for DLLs (current directory,
    > then the system directory) was true in the 16-bit world, it isn't
    > necessarily so in the 32-bit world. COM objects need to registered: what's
    > in the registry tells the program where to find the relevant object.
    >
    > --
    >
    > Doug Steele, Microsoft Access MVP
    > Beer, Wine and Database Programming. What could be better?
    > Visit "Doug Steele's Beer and Programming Emporium"
    > http://I.Am/DougSteele/
    >
    >
    > Abdel K. Belkasri <abdelb@riseintl.com> wrote in message
    > news:394a83e4$1@news.devx.com...
    > >
    > > Hi all,
    > >
    > > I have written an application that is supposed to always be run from

    the
    > > CD-ROM. so I put all the DLLs and the support files in the root

    directory
    > > of the CD-ROM where the exe of the application is located. It worked

    fine
    > > on win98, win2000. But on some win95 we got the following error:
    > >
    > > "OLEAUT32.DLL file is out of date"
    > >
    > > I don't understand ! it's supposed to look for the any DLL at the

    current
    > > directory, and only if it doesn't find it, then it should look in

    > Windows\system
    > >
    > > How to fix that?
    > >
    > > --Abdel.

    >
    >




  6. #6
    Abdel K. Belkasri Guest

    Re: DLL **** !


    Hi Doug,
    So, how can I make sure that any target machine will use my dlls not the
    ones in the system directory?
    Knowing that I don't have an installer, I want the app to run straight from
    the CD!

    Thanks for your help.

    --Abdel.

    "Douglas J. Steele" <djsteele@idirect.com> wrote:
    >While what you're saying about where it looks for DLLs (current directory,
    >then the system directory) was true in the 16-bit world, it isn't
    >necessarily so in the 32-bit world. COM objects need to registered: what's
    >in the registry tells the program where to find the relevant object.
    >
    >--
    >
    >Doug Steele, Microsoft Access MVP
    >Beer, Wine and Database Programming. What could be better?
    >Visit "Doug Steele's Beer and Programming Emporium"
    >http://I.Am/DougSteele/
    >
    >
    >Abdel K. Belkasri <abdelb@riseintl.com> wrote in message
    >news:394a83e4$1@news.devx.com...
    >>
    >> Hi all,
    >>
    >> I have written an application that is supposed to always be run from

    the
    >> CD-ROM. so I put all the DLLs and the support files in the root directory
    >> of the CD-ROM where the exe of the application is located. It worked fine
    >> on win98, win2000. But on some win95 we got the following error:
    >>
    >> "OLEAUT32.DLL file is out of date"
    >>
    >> I don't understand ! it's supposed to look for the any DLL at the current
    >> directory, and only if it doesn't find it, then it should look in

    >Windows\system
    >>
    >> How to fix that?
    >>
    >> --Abdel.

    >
    >



  7. #7
    Dennis Nagel Guest

    Re: DLL **** !


    I would suggest programatically locating the 'known' library and keeping a
    note of the install path to it for future reference (for when your app is
    ending) (Theres a key in the registry that will give you the DLL's local
    path)

    (RegSvr32 needs to be included in the softwares installer, it is not commonly
    found on a users machine. You can alternately call regsvr32 from a known
    server path in your local network as long as all users will have access to
    that shared directory.)

    regsvr32 -u dllName.DLL will unregister a DLL. Use it in your code to unregister
    the old DLL.

    Then use the regsvr32 g:\path\dllName.DLL command to register your version
    of the control.

    You need to do this from the (startup) Main Routine in a module so that there
    are no existing hooks on the DLL that you are working with.

    Do not create any objects or call any functions from the DLL until this process
    has been done.

    Then when the app closes use regsvr32 -u c:\OldPath\dllName.DLL
    to register the pre-existing version of the DLL.

    I use a similar technique to ensure that my COM Business rule DLLs are always
    up to date on a users machine, and if not I copy and register them to the
    users box using very much the same methods as described above. But, I did
    not need to keep the OLD DLL around after installing a new one.

    "Abdel K. Belkasri" <abdelb@riseintl.com> wrote:
    >
    >Hi Doug,
    > So, how can I make sure that any target machine will use my dlls not the
    >ones in the system directory?
    >Knowing that I don't have an installer, I want the app to run straight from
    >the CD!
    >
    >Thanks for your help.
    >
    >--Abdel.
    >
    >"Douglas J. Steele" <djsteele@idirect.com> wrote:
    >>While what you're saying about where it looks for DLLs (current directory,
    >>then the system directory) was true in the 16-bit world, it isn't
    >>necessarily so in the 32-bit world. COM objects need to registered: what's
    >>in the registry tells the program where to find the relevant object.
    >>
    >>--
    >>
    >>Doug Steele, Microsoft Access MVP
    >>Beer, Wine and Database Programming. What could be better?
    >>Visit "Doug Steele's Beer and Programming Emporium"
    >>http://I.Am/DougSteele/
    >>
    >>
    >>Abdel K. Belkasri <abdelb@riseintl.com> wrote in message
    >>news:394a83e4$1@news.devx.com...
    >>>
    >>> Hi all,
    >>>
    >>> I have written an application that is supposed to always be run from

    >the
    >>> CD-ROM. so I put all the DLLs and the support files in the root directory
    >>> of the CD-ROM where the exe of the application is located. It worked

    fine
    >>> on win98, win2000. But on some win95 we got the following error:
    >>>
    >>> "OLEAUT32.DLL file is out of date"
    >>>
    >>> I don't understand ! it's supposed to look for the any DLL at the current
    >>> directory, and only if it doesn't find it, then it should look in

    >>Windows\system
    >>>
    >>> How to fix that?
    >>>
    >>> --Abdel.

    >>
    >>

    >



  8. #8
    Abdel K. Belkasri Guest

    Re: DLL **** !


    Dennis,
    I also thought of that solution. But it's not adequate for my case. The
    app will never install anything to the target machine. It's just a demo disc
    that you put into your CD-ROM drive, it plays the app, tell people about
    our business and what we do and that's it.

    If I start registring and unregistring and the app crashes in the middle,
    like the user pop-up the CD, well, now he will have some unregistred dlls
    or worse some which are registred to a dll on my CD !!!

    "Dennis Nagel" <dnagel@egghead.com> wrote:
    >
    >I would suggest programatically locating the 'known' library and keeping

    a
    >note of the install path to it for future reference (for when your app is
    >ending) (Theres a key in the registry that will give you the DLL's local
    >path)
    >
    >(RegSvr32 needs to be included in the softwares installer, it is not commonly
    >found on a users machine. You can alternately call regsvr32 from a known
    >server path in your local network as long as all users will have access

    to
    >that shared directory.)
    >
    >regsvr32 -u dllName.DLL will unregister a DLL. Use it in your code to unregister
    >the old DLL.
    >
    >Then use the regsvr32 g:\path\dllName.DLL command to register your version
    >of the control.
    >
    >You need to do this from the (startup) Main Routine in a module so that

    there
    >are no existing hooks on the DLL that you are working with.
    >
    >Do not create any objects or call any functions from the DLL until this

    process
    >has been done.
    >
    >Then when the app closes use regsvr32 -u c:\OldPath\dllName.DLL
    >to register the pre-existing version of the DLL.
    >
    >I use a similar technique to ensure that my COM Business rule DLLs are always
    >up to date on a users machine, and if not I copy and register them to the
    >users box using very much the same methods as described above. But, I did
    >not need to keep the OLD DLL around after installing a new one.
    >
    >"Abdel K. Belkasri" <abdelb@riseintl.com> wrote:
    >>
    >>Hi Doug,
    >> So, how can I make sure that any target machine will use my dlls not

    the
    >>ones in the system directory?
    >>Knowing that I don't have an installer, I want the app to run straight

    from
    >>the CD!
    >>
    >>Thanks for your help.
    >>
    >>--Abdel.
    >>
    >>"Douglas J. Steele" <djsteele@idirect.com> wrote:
    >>>While what you're saying about where it looks for DLLs (current directory,
    >>>then the system directory) was true in the 16-bit world, it isn't
    >>>necessarily so in the 32-bit world. COM objects need to registered: what's
    >>>in the registry tells the program where to find the relevant object.
    >>>
    >>>--
    >>>
    >>>Doug Steele, Microsoft Access MVP
    >>>Beer, Wine and Database Programming. What could be better?
    >>>Visit "Doug Steele's Beer and Programming Emporium"
    >>>http://I.Am/DougSteele/
    >>>
    >>>
    >>>Abdel K. Belkasri <abdelb@riseintl.com> wrote in message
    >>>news:394a83e4$1@news.devx.com...
    >>>>
    >>>> Hi all,
    >>>>
    >>>> I have written an application that is supposed to always be run from

    >>the
    >>>> CD-ROM. so I put all the DLLs and the support files in the root directory
    >>>> of the CD-ROM where the exe of the application is located. It worked

    >fine
    >>>> on win98, win2000. But on some win95 we got the following error:
    >>>>
    >>>> "OLEAUT32.DLL file is out of date"
    >>>>
    >>>> I don't understand ! it's supposed to look for the any DLL at the current
    >>>> directory, and only if it doesn't find it, then it should look in
    >>>Windows\system
    >>>>
    >>>> How to fix that?
    >>>>
    >>>> --Abdel.
    >>>
    >>>

    >>

    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center