DLLs and Vista? / 64 bit? / ...?

[Eric Pearson]

I recently received an email from a Graphics Tools licensee who is reporting a problem when using the 64-bit version of Vista. (I don't know whether or not that is the basis of the problem, but it's a starting point.)

If they place the Graphics Tools DLL in the same folder as their EXE, everything works fine.

If they place the Graphics Tools DLL in the C:\Windows\System32 folder the app fails.

I had them check the PATH and C:\Windows\System32 is included.

Has there been a recent (Vista? 64-bit?) Windows rule-change that I don't know about?

Is this likely to be a permissions/security issue, or...?

-- Eric Pearson, Perfect Sync Software

[Brice Manuel]

You are putting the DLL in the wrong directory for a 64 bit OS.

Only 64 bit DLLs can be in the system32 directory.

32 bit DLLs must be placed in C:\Windows\SysWOW64

[edit]
You need to remember that your app is running under emulation on a 64 bit OS, and the emulation layer redirects to 32 bit locations. Newer installers can check for a 32 bit or 64 bit OS and let you install files where they should be.

http://blogs.msdn.com/oldnewthing/archive/2008/12/22/9244582.aspx

http://msdn.microsoft.com/en-us/library/aa384187(VS.85).aspx

[/edit]

[Eric Pearson]

> Only 64 bit DLLs can be in the system32 directory.

Oh... well... um... that makes a lot of sense, doesn't it?

Thanks much! I'll pass that advice along to the customer.

It's time to order a new computer and OS for testing, I guess. Darn, I was hoping to avoid Vista completely.

-- Eric

[Brice Manuel]

Oh... well... um... that makes a lot of sense, doesn't it?

Well, we are talking about Microsoft

I was hoping to avoid Vista completely.

IMHO (others may disagree), you could skip Vista and go with 7. The special "rules" should be the same. Any "gotcha" on Vista should also cause a "gotcha" on 7 and the solution should be the same.

[Edwin Knoppert]

Are these shared dll's?
We put our dll's cin the app folder, i assume no change for that?
which dumbo is placing dll's in the Windows folder nowadays?

[Eric Pearson]

> Are these shared dll's?

Yes, they are "library" DLLs that can be used by many different programs.

> i assume no change for that?

Correct.

> which dumbo is placing dll's in the Windows folder nowadays?

I guess you can call me Dumbo, Edwin.

Perfect Sync's customers often use SQL Tools, Graphics Tools, etc. to create more than one PowerBASIC application.

If they distribute an app to their customers we do recommend that they place the DLL in their EXE's folder, but (especially) on a development machine we usually recommend System32.

-- Eric

[Michael Mattias]

Eric, you and your users can look at what I do re 'multiple use' DLLs and #INCLUDE files...

I have one folder which contains all my 'multiple use' DLLs and that folder is on my PATH.

That's especially handy when one of the DLL vendors (eg Perfect Sync were I a user) sends out a new release. You can test the new release by putting the new files directly in your 'development folder' (where the exe is located) and the program will use that, because that folder is earlier in the "hunt" sequence used by LoadLibrary().

Only when you are sure the new DLLs are 'solid' do you copy them to your current "DLLs" folder.

I also suggest you keep a log... here's mine..

_index.txt for C:\Utility\Dlls

4/08/03 Created folder and added to path
09/03/07 rearranged to put all entries for same file together like product version logs. 
02/26/08 Added entry for LIBHARU. Note that this file does not have a version resource 
         and you have to select by size. LIBHARU 2.0.8 size = 768K


DDOC.EXE and DDOC16/32. DLL

   04/19/03 Added ddoc.exe, ddoc32.dll, ddoc16.dll (v 1.9c)
   10/21/03 overwrote all ddoc with version 1.9E
   12/7/04  overwrote ddoc 1.9e with 1.9.5.1 (OEMVersion=Tal Systems (001)))
             fileversion="1.9e(1)"
   3.29.06  Overwrote ddoc.exe 1.9.5e1 with 1.9.5e2  (wider bookmark control)

TSIXML00.DLL and XMLPARSE (expat parser)

   05/10/03 Added TSIXML00.DLL v 1.1.0.1
   05/10/03 Added XMLPARSE.DLL (expat parser) No version info dated 7/12/02 size 126,976
   12.20.06 Changed tsixml00.dll to version 1.2.0 (handle encoding not supported by expat parser).

MODLIST.EXE   
    06/12/03  Added MODLIST.EXE v 1.0.0

TSEDIAPI.DLL
   04/08/03 installed tsEDIAPI.DLL  v 3.0.0
   6/20/03  Updated TSEDIAPI.DLL to v 3.0.1
   6/23/03  Updated TSEDIAPI.DLL to v 3.0.2
   1/03/04  Updated TSEDIAPI.DLL to v 3.1.0
   11/13/06 Updated TSEDIAPI.DLL to v 3.1.1
   09/03/07 Updated TSEDIAPI.DLL to v 3.1.2 
   05/22/09 updated              to v 3.2.1 (better error detection) 
   06/03/09 updated              to v 3.2.2 (added error literal, fixed another compiler-induced bug!) 
   08/20/09 updated              to v 3.2.3 (add test for length of segment file name when valid address passed)(only occurs with PPPS)

USNCRYPT.DLL
   8/8/03   Added usncrypt.dll (product serializer)
   6.24.05   Updated usnCrypt.dll to version 1.5
   5.00.07   Now at version 1.8.0 

TSIUPGRADE.DLL
   1.04.06   Add tsiupgrade.dll version 1.0.2 for use with Inno Setup.
   3.15.06   tsiupgrade.dll V 1.1.0 (handles EDI Pal 23==>2.5, 2.5 update)
   8.16.05   tsiupgrade.dll v 1.2.0 (PPPS 3x upgrade support) (3.0 to 3.0)
   11.13.06  tsiupgrade.dll v 1.4.0 (had been in Utilities production for a while).
   05.11.07  tsiupgrade.dll v 1.7.0 
  


X096A1API.DLL, X096A1API.DLL and TSIIG022.DLL and TSIIG031.DLL parsers

    06.21.05  Added 837 API files X096A1API.DLL X098A1API.DLL TSIIG022.DLL TSIIG031.DLL
          versions 1.2.2 both APIs
    7.29.05   Updated X096A1API.DLL  to version 1.2.5 (bug fixes over 1.2.4)

    8.12.05   Add X096A1API.DLL version 2.0
    3.06.06   Changed tsiig031.dll (X098A1) to version 2.1.1

    03.19.07  Updated TSIIG022.DLL and TSIIG031.DLL to version 2.7.0 (not yet released to public) 
               Did this to test Microport Export stuff.
    08.15.07   Upgraded X096A1API.DLL to 2.3.1
    08.15.07   Upgraded X098A1API.DLL to 2.3.0
    05.19.08   Updgraded X098A1API.DLL to 2.3.1 
    02.26.09   Upgraded X096A1API.DLL  to 2.3.2 
    02.26.09   Upgraded X098A1API.DLL  to 2.3.2 
    05.01.09   Upgraded X098A1API.DLL  to 2.4.0 

    05.07.09   Upgraded X098A1API.DLL  to 2.4.1 
    05.07.09   Upgraded X096A1API.DLL  to 2.3.3 
    08.22.09   upgraded X098A1API.DLL  to 2.4.4 

PTREE32.DLL   PowerBASIC PowerTree RTL
    06.21.06  Add ptree32.dll v 1.10 (required by X096/X098A1API DLLs)


UNICOWS.DLL    MICROSOFT LAYER FOR UNICODE
     1.04.06   Add unicows.dll    version 1.0.3703 also for use with Inno Setup.


EGRIDPRO32.DLL
   02.06.07  Added EGRID32PRO.DLL v 3.28.4
   02.14.07  Updated EGRID32PRO.DLL to v 3.28.10

LIBHARU.DLL
 ** FILE DOES NOT HAVE A VERSION RESOURCE!!! **  (maybe I should try to add?) 
   02.26,09  Replaced whatever was here size 596K with 2.0.8 size 768 Kb 
 



// ENDS //

For finished applications, you can look at at AppPath settings in the registry to eliminate multiple installs of the same third-party DLLs.

#INCLUDEs is a little more work, in that you have to create a common folder for your third party tools, and then modify your IDE's #INCLUDE path to use it. BUt the same principle applies: you can easily test new versions of header files by putting with your *.bas source, only updating your master #INCLUDE file folder when you know the new file is good.

(Idea courtesy Big Blue.. $PROCLIB directive in JCL.. multiple libs are searched IN ORDER so you can keep old versions in place until you know the new version is good )

MCM
PS: Not sure where that DLL is loading from?
Use this:
Show Loaded modules and path from which loaded June 12 2003
Show Loaded Modules Source and Executable package for PB and VB
Visual Basic include files/demo code by Balthasar Indermuehle. (PB code by YT.)

I am told this can be especially handy for VB users, who often have no clue from where VB is loading something