First Published 16 Dec 2023                                               Difficulty level :   Easy


In the first article in this series on 32 to 64-bit conversion, I started with the following comments:

I have been working with both 32-bit and 64-bit Access since 2014 and almost all of my applications are designed to work in both bitnesses.
From version 2010 onwards, Microsoft Office programs have been available in both 32-bit and 64-bit versions. VBA was updated to version 7 to handle 64-bit declarations.
Users with 32-bit Windows can only install 32-bit Office. However, most users now have 64-bit Windows and can choose which bitness of Office to install

For many years, the default installation was 32-bit and for most users there was little benefit in installing the 64-bit version, with the exception of users with large and complex Excel spreadsheets or highly demanding Access databases.

Gradually the proportion of 64-bit Office users has increased, particularly since the default installation changed to 64-bit a couple of years ago.



My Future Plans

The process of writing this series of articles has led me to make a decision about all applications and code samples that I will be creating from now on.

It is now over 13 years after the introduction of 64-bit with Office 2010 and the vast majority of users are now running newer Office versions based on VBA7.
In addition, all versions of Office/Access prior to 2016 are no longer supported, so this trend will continue.
So I have decided it is finally time to pull the plug on creating new apps for those still using 2007 or earlier.

What (in practice) does this decision mean for me, my code and my client/user base?

1.   My use of API declarations will be simplified as it will no longer include conditional compilation - see the second article for more details.

2.   My code will continue to be compatible for all users with VBA7 - whether 32-bit or 64-bit.

3.   Where apps are distributed as ACCDE files, I will continue to release both 32-bit and 64-bit version that will run in Access 2010 or later

4.   Newly written code will no longer run in versions prior to 2007. In practice, this was often the case anyway due to other differences between e.g. Access 2007 and 2010

5.   Users with A2007 or earlier can if they wish 'reverse engineer' any future code thast depends on VBA7 API declarations by:
      a)   Removing all instances of PtrSafe
      b)   Replacing all instances of LongPtr with Long

      NOTE:   In principle, I could do the retro conversion on request as a service, but doing so would be a chargeable service based on the time taken.

6.   Existing apps will continue to work in the same versions as they do now.

      This particularly applies to apps such as my Access/Office/Windows Version Checker utility that are designed to work in all versions from Access 2000 onwards.

In other words, for the vast majority of my clients/users, this decision won't make any difference at all.
For that reason, I feel it is finally the right time to do so.



Feedback

Please use the contact form below to let me know whether you found this article interesting/useful or if you have any questions/comments.

Please also consider making a donation towards the costs of maintaining this website. Thank you



Colin Riddington           Mendip Data Systems                 Last Updated 16 Dec 2023



Return to Access Articles Page Page 5 of 5 1 2 3 4 5 Return To Top