Selecting 64bit vs 32bit Dll's at runtime....

Good heavens, it feels like it's been age's since i last checked in... Work has me buzzing, and the new house, well I think i've just about redone everything you can think of, Plumming, Electrical, Construction, etc....

Ok why i'm posting now! ...

We've picked up a driver issue with some software on some new Windows 8 systems.. Major problem is that we currently support everything from XP to 8.1 in a single package, Project is way to big to support multiple builds..

First some explaining... the software is a POS (point of sale) app, that use's some external hardware connected via Serial and/or USB depending on the install.. So a single site could have multiple POS workstations, and also some Administrative stations in the back office.. Currently the largest install is 15 workstations.. One key note: this is not a till type app, like in a supermarket... the software actually does Pre-Paid Credit sales to a variety of monetary tokens..

The software is also always in development, because as the hardware is further developed, the POS has to support the features, so we do software upgrades every 6 or so months.. (I'm off to Namibia next month to install and do training on the upgraded software and hardware)..

K background done... Back to the problem... the project was developed when 64bit systems were not in the mainstream PC market yet.. so only 32bit driver DLL's were available, and as such was fully developed with 32bit in mind... For years this has been OK, and even on some of the 64bit machine's the 32bit drivers have worked (through WoW64) .. however, there are more and more systems that we need to install that appear not to fully support 32bit drivers on 64bit OS.. (also specified on this MS windows page).. So now we need to detect the OS type (Easy, got code to do that, but still untested) and call on the right version of driver(difficult part)..

This is a sample block of how the project access's the driver...

Code:

---

Module Declarations

    'Initializes the Port for 1-Wire access
    Declare Function TMSetup Lib "IBFS32.DLL" (ByVal session_handle As UInteger) As Integer
    'One byte communication to 1-Wire network
    Declare Function TMTouchByte Lib "IBFS32.DLL" (ByVal session_handle As UInteger, ByVal outbyte As Integer) As Integer
    'Reset all devices on 1-Wire Network
    Declare Function TMTouchReset Lib "IBFS32.DLL" (ByVal session_handle As UInteger) As Integer
    'One bit communication on 1-Wire Network
    Declare Function TMTouchBit Lib "IBFS32.DLL" (ByVal session_handle As UInteger, ByVal outbit As Integer) As Integer
    'Read the version string of the main TMEX driver
    Declare Function Get_Version Lib "IBFS32.DLL" (ByVal ID_buf As String) As Integer
    'Read the version string of the hardware specific driver
    Declare Function TMGetTypeVersion Lib "IBFS32.DLL" (ByVal HSType As Integer, ByVal ID_buf As String) As Integer
    'Check to see if the 1-Wire network port session is still valid
    Declare Function TMValidSession Lib "IBFS32.DLL" (ByVal session_handle As UInteger) As Integer
    'Request a 1-Wire Nwetwork Port
    Declare Function TMExtendedStartSession Lib "IBFS32.DLL" (ByVal PortNum As Integer, ByVal PortType As Integer, ByVal Reserved As String) As Integer
    'Relinquish a 1-Wire Network port
    Declare Function TMEndSession Lib "IBFS32.DLL" (ByVal session_handle As UInteger) As Integer

End Module

---

And for the 64bit driver, the reference is

Code:

---

    'Initializes the Port for 1-Wire access
    Declare Function TMSetup Lib "IBFS64.DLL" (ByVal session_handle As UInteger) As Integer
    'One byte communication to 1-Wire network
    Declare Function TMTouchByte Lib "IBFS64.DLL" (ByVal session_handle As UInteger, ByVal outbyte As Integer) As
    ''Etc, etc,etc

---

The main issue here is that a single site has multiple versions on window's running at multiple locations, and it is impractical to send the local 'IT' guy two upgrade build's, and expect him to know which one to load where.... (trust me, some of these IT guy's dont even know how to load a USB driver of our supplied CD's)....

Thanks.....

Don't know if you're still working on this, but you would want to look at dynamically loading the dll's.

See the links below:

https://www.google.com/#q=vb.net+dyn...dll+at+runtime

https://www.google.com/#q=vb.net+dyn...dll+at+runtime

Thanks Craig..

You Google Foo is better than mine.. well actually you used better search terms...

I'll be following up on these soon, other progects currently have taken over my time.. We have devices going for SABS testing so most other stuff is put to the side for now...