UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> office 2010 x64 bit. Just a question ...    
 
   
Pleasure
post Dec 15 2009, 08:54 AM
Post#1



Posts: 269
Joined: 1-July 05
From: Greece


Hello my friends.
don't know if I have opened this thread at the correct section, but I would like to ask if you know any differences between Access 2010 x32 vs Access 2010 x64.
According to that seperation, our access applications (mdb or accb or mde or accde) will have 64 and 32 bit versions, aiming at specific machines ? Will this seperation enrole the runtime extension that will come ?
Also are the x64 bit version of access as well as the apps developed with this version faster that the x32 version of access or apps ?
Mess ...
Oalso have many questions but I think I have to wait.
But couldn't wait for the above questions, so if you have anything in mind, please share with us ...
Go to the top of the page
 
AlbertKallal
post Dec 15 2009, 11:39 AM
Post#2


UtterAccess VIP
Posts: 3,101
Joined: 12-April 07
From: Edmonton, Alberta Canada


VBA 7 for 2010 is a new code base, replacing the earlier version of VBA. VBA 7 exists for both the 32-bit and 64-bit versions of Office 2010

Keep in mind if you go to a 64 bit version of access, then all other office components better be 64 bit also, or you'll not be able to use any object automation ( you cannot mix and match different versions or parts of the office, for example an 32 bit version of access can not launched an 64 bit version of word).

This also means you can't use any 32 bit version of ActiveX in 64bit versiosn of office. This also explains why in access 2010 there's no version of the calendar control anymore. Is been dropped ( and that calendar controls been around for well over ten years, I think back to access 95 if not earlier).

Keep in mind that access 2007, and access 2010 does have a built in date picker now, so the loss of this control not that big of a deal, but if you're using any existing or third party ActiveX controls, you'll have to get new 64bit edditions, or stop using them as are not interchangeable or compatible between 32 and 64 bit versions of access.

Keep in mind access is the ONLY product in office with compiled VBA. This ability of ms-access presents a serious problem.

For mdb, and accDB, there not a problem. Note that for any windows api, you have to re-write your code for 64bit platforms. In fact it suggested that you use conditional compilation that is available in access to deal with this problem.

You have two new compiler options: VBA7 and win64

While conditional compiling will allow you to build and enabled compatible applications between 32 and 64 bit systems, if you use accDE (compiled applications), then you have to create two versions. One for 32 bit versions of office and one for 64 bit versions of office.

Not only that, you'll have to create/compile the 64 bit version on a 64 bit os. And you'll have to create/compile the 32 bit on a running 32 bit os.

Keep in mind that the 32 bit version of office will run fine and install correctly on a 64 bit version of windows. In this scenario, you'll not have to change your code are do anything at all.

The case where you'll need to change your code is if you're using any windows API, and using it in a 64 bit environment. In this case, if you're using an accDB, Then again you can resort to conditional compilation and this feature will/should allow you to have ONE version of your applciaon (if you don't use a compiled application (mde/accde).

The instant that you choose to use a compiled application is when you'll be forced to create the required version on the 32 or 6 bit box...

HAs for differences in performance, ? I can't say you'll likely see much these days, it's always been the speed of the hard disk and the network that slows MS access down anyway. It has been a good number of years that throwing more processing at access helps in terms of performance. So access hasn't been processing bound for very long time, it's been input/output bound.

Increasing the speed of your processing without increasing the speed of your networkor your hard drive will generally do very little if anything for performance in MS access.

I want post a PowerPoint presentation here I did about one month ago on the issues for 64 bit VBA. Other than the above considerations for MS access, the rest of the differences and the new features and VBA for 64 bit additions is outlined here:

http://msdn.microsoft.com/en-us/library/ee...office.14).aspx

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
Edited by: AlbertKallal on Tue Dec 15 11:42:35 EST 2009.
Go to the top of the page
 
Peter46
post Dec 15 2009, 11:47 AM
Post#3


UtterAccess VIP
Posts: 7,489
Joined: 3-October 05
From: Oadby Leics, UK


"While conditional copulation will allow you to..."
think you should keep your mind on the job Albert - whichever job you're on that is...
Go to the top of the page
 
BananaRepublic
post Dec 15 2009, 12:01 PM
Post#4


Dungeon Cleaner
Posts: 1,520
Joined: 16-June 07
From: Banana Republic


I thought all Office could compile VBA projects as well? I suppose it's accurate to say that Access is by far the heaviest user of VBA in the whole Office but one surely can write VBA procedures for Excel and Word & save it as a part of the document, no?
For mdb, and accDB, there not a problem. Note that for any windows api, you have to re-write your code for 64bit platforms. In fact it suggested that you use conditional compilation that is available in access to deal with this problem.
You have two new compiler options: VBA7 and win64
One interesting addition they made was to require PtrSafe declaration when making an API Call. Here's an example from the help file:
CODE
' In Microsoft Windows (16-bit):
Declare Sub MessageBeep Lib "User" (ByVal N As Integer)
' Assume SomeBeep is an alias for the procedure name.
Declare Sub MessageBeep Lib "User" Alias "SomeBeep"(ByVal N As Integer)
' Use an ordinal in the Alias clause to call GetWinFlags.
Declare Function GetWinFlags Lib "Kernel" Alias "#132"() As Long
' In 32-bit Microsoft Windows systems, specify the library USER32.DLL,
' rather than USER.DLL. You can use conditional compilation to write
' code that can run on either Win32 or Win16.
#If Win32 Then
    Declare Sub MessageBeep Lib "User32" (ByVal N As Long)
#Else
    Declare Sub MessageBeep Lib "User" (ByVal N As Integer)
#End If
' 64-bit Declare statement example:
Declare PtrSafe Function GetActiveWindow Lib "User32" () As LongPtr
' Conditional Compilation Example
#If Vba7 Then
     ' Code is running in the VBA7 editor.
     #If Win64 Then
          ' Code is running in 64-bit development environment.
     #Else
          ' Code is not running in 64-bit development environment.
     #End If
#Else
     ' Code is not running in the VBA7 editor.
#End If

With PtrSafe, you still can reference to 32-bit API calls even in a 64-bit OS. There's also new datatypes, LongLong and LongPtr. We should use LongPtr because it's either 64-bit or 32-bit depend on where the code is running, so this is important when we want to use API calls. LongLong are just like Long, 64-bit integers.
So when working with VBA 7, we have to be more conscious of the pointer's size more than was the case, I think. (I missed out on 16/32 bit transition and do wonder why PtrSafe didn't exist back then???)
Oagree with all other points, BTW.
Go to the top of the page
 
AlbertKallal
post Dec 15 2009, 12:26 PM
Post#5


UtterAccess VIP
Posts: 3,101
Joined: 12-April 07
From: Edmonton, Alberta Canada


Sure, I should clear this up a bit…
While other office parts like Excel etc. do compile the code, they all have the source VBA available. When you attempt to run/use that Excel or even ms-access on a 64 bit box, it forces a re-compile.
With an mde (accde) you don't have the source code, so that re-compile cannot occur. So, I should not really say access is not the only office app with a compiler but is the only one that allows one to force and save a version of the VBA in a compiled state WITHOUT the source VBA code. There simply was no way to keep the compiled code compatable between 32 and 64 bit versions...so, we have to deploy two versions if you using the mde (accde) option..
Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
Go to the top of the page
 
Pleasure
post Dec 15 2009, 12:26 PM
Post#6



Posts: 269
Joined: 1-July 05
From: Greece


Thanks a lot you guys but ...
crazy.gif crazy.gif crazy.gif
Changing all the APIs, seeking for 64 bit of ActiveX controls and ... without any significant speed improvement then I don't want to mess with the 64 bit for developing, but just for testing.
Thanks a lot everyone once again for your help ...
Go to the top of the page
 
BananaRepublic
post Dec 15 2009, 12:36 PM
Post#7


Dungeon Cleaner
Posts: 1,520
Joined: 16-June 07
From: Banana Republic


Wait, wait, wait.
You don't have to change the APIs! At worst, you need to update the declaration to include the PtrSafe directive and use LongPtr where Long was used when you need to deploy for both 64-bit and 32-bit. When you're using Access 2010, both should work either way.
It's only the ActiveX that you have to replace entirely, probably because it's not so easy to "fool" a control that is to be laid down in a form as we could with an API declaration.
While it is true that there aren't going to be significant speed improvement, it should not escape our notice that 64-bitness removes the 4GB ceiling that was present in the 32-bit world so the computer can run with 8 or 16 GB. I do think 64-bit will become the norm even if we don't actually need it, much like we ended up with color monitor when we were doing just fine with green monitor.
Albert -
Thanks for the clarification. Makes perfect sense now.
Go to the top of the page
 
Pleasure
post Dec 15 2009, 12:48 PM
Post#8



Posts: 269
Joined: 1-July 05
From: Greece


Alber I think you are absolutely correct.
nyway we will give it a try and help each other ...
Thanks again.
Go to the top of the page
 
BananaRepublic
post Dec 15 2009, 12:55 PM
Post#9


Dungeon Cleaner
Posts: 1,520
Joined: 16-June 07
From: Banana Republic


A bit off topic, but I have to confess a slight puzzlement that VBA 7 has LongLong but as far as I can tell, ACE doesn't have it....
Go to the top of the page
 
AlbertKallal
post Dec 15 2009, 03:19 PM
Post#10


UtterAccess VIP
Posts: 3,101
Joined: 12-April 07
From: Edmonton, Alberta Canada


Yes…. good of you to point this out.
did not mean that you have to replace the api, but you do have to change where the pointers are used.
And, if you do require any 64 bit values, then yes you do have to use conditional compiling.
So, sure, longPtr does change for you automatic when using 32 or 64 bit versions. Using ptrSafe should work for most of the api's. Thus after the declare is modified then it should work on both platforms.

However there is no automated way of doing the above. So if you have 5 long values in that windows api, you don't change them all, but just the one parameter that is the memory pointer.
In any case where the api needs to return 64 bit values, then you have to use conditional compile options in code to make this work. (can't use longlong in 32 bit version).
To be honest, I don't think many (if any) the api's I used would return a 64 bit values (longlong).
If any of the common api's we use do have any 64 bit values returned, then this would be somewhat more of an problem.
Now that you made me think more clear about this issue, then I don't think we will need to use conditional compiling nearly as much as I had first thought…
Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
Go to the top of the page
 
BananaRepublic
post Dec 15 2009, 03:43 PM
Post#11


Dungeon Cleaner
Posts: 1,520
Joined: 16-June 07
From: Banana Republic


Unfortunately, you're right. It's not automated, but who knows- maybe someone will come up with a 3rd party tool to do this.
hooting from the hip here, but my guts say just go ahead and change all Longs to LongPtrs even if they're not actually memory pointers as to be "safe" because sometime the API documentation can be obscure on what is a pointer and what isn't, and it shouldn't hurt to use LongPtr which will always be dimensioned correctly and even updated should the API changed at a future point. I could be dead wrong here, though....
HAs I said earlier, I do have to wonder why now? The concepts of PtrSafe and LongPtr didn't exist back then when we moved from 16 bits to 32 bits...
Go to the top of the page
 
robcooper
post Jan 14 2010, 02:59 AM
Post#12


Microsoft Corp UtterAccess VIP
Posts: 1,839
Joined: 3-October 03
From: Bellevue, WA


Very interesting thread... It's nice to see people getting into this. Just want to expand on a few things. Sorry for jumping in late.
The LongPtr data type is scalable between 32-bit and 64-bit platforms. As a result, if you look at a LongPtr variable in the Locals or Watch windows while debugging, you will see it coerced to a Long (4-bytes) on x86 and to a LongLong (8-bytes) on x64. The IntPtr data type in .NET has this same behavior where it scales from 4-bytes to 8-bytes.
HAs BananaRepublic points out, you may run into a case where API documentation refers to something that is not being a pointer that actually is a pointer or vice versa. If it really is a pointer, you should use the LongPtr data type in order to work across platforms. If however, it is not a pointer/handle, you should continue to use the Long data type, not LongPtr.
In addition to Declare statements, several APIs use user-defined types (structs in C/C++) that may contain members that are pointers or handles. These members will also need to be updated to use LongPtr where appropriate.
The LongLong data type is a true 64-bit integer and is only available in 64-bit VBA. The Double data type in ACE is 8-bytes of storage, but of course it is not an integer.
One note on conditional compilation. It turns out that the PtrSafe keyword is optional on 32-bit platforms in Office 2010. This is really convenient. As a result, the code for 32-bit is the same for Office 2007 and Office 2010 which may simplify the API declarations. Here is the pattern I've been using:
CODE
#If Win64 = 1 And VBA7 = 1 Then
' // 64-bit APIs go here...
#Else
' // 32-bit APIs go here...
#End If

Conditional compilation can be used in other places where you might want to share code between versions or platforms. For example variable definitions or function signatures:
CODE
#If Win64 = 1 And VBA7 = 1 Then
    Dim hWndMyWindow As LongPtr
#Else
    Dim hWndMyWindow as Long
#End If

Here's one I wrote earlier today for working with Registry APIs. The differences here are in the function signature and variable declaration.
CODE
' Returns the handle to the specified registry key
#If Win64 = 1 And VBA7 = 1 Then
Public Function OpenKey(lngRootKey As Long, _
    strKeyName As String, _
    Optional lngKeyAccess As Long = KEY_READ) As LongPtr
    
    Dim hKey As LongPtr
    
#Else
Public Function OpenKey(lngRootKey As Long, _
    strKeyName As String, _
    Optional lngKeyAccess As Long = KEY_READ) As Long
    Dim hKey As Long
    
#End If
    ' open the registry key
    lngReturn = RegOpenKeyEx(lngRootKey, strKeyName, 0, lngKeyAccess, hKey)
    
    ' return the handle to the specified key
    ' callers should call the CloseKey API to close the handle
    OpenKey = hKey
End Function

Admittedly, this might be a little harder to read. You could include the entire procedure (Function...End Function) in the conditional compilation block.
Odidn't work on the conversion between 16-bit and 32-bit, but the VBA language at the time already had support for a 4-byte integer: the Long data type. Also, it turns out that the scalable type shows up in a few other places. For example, Windows API functions as discussed here. In Windows, pointers and handles are 4-bytes on x86 and 8 bytes on x64. Also, the ADO object model has a data type called ADO_LONGPTR which is used as the return type for the Recordset.RecordCount property. This is also a scalable type.
Lastly, there are also new conversion functions to force type coercion: CLngPtr and CLngLng.
I hope everyone is enjoying Office 2010!
Thanks,
Go to the top of the page
 
BananaRepublic
post Jan 14 2010, 01:16 PM
Post#13


Dungeon Cleaner
Posts: 1,520
Joined: 16-June 07
From: Banana Republic


Rob,
Thanks for sharing. That was very helpful.
A concern though, I earlier asserted that if you were not sure whether the variable in question could later be used as a pointer, it should be harmless to use LongPtr even though you may not actually need scalable type. Your response seem to suggest that this is likely to be actually worse than if we tried to use non-scalable types for non-pointer variables (and finding out the hard way when it does flop at runtime...)?
Go to the top of the page
 
robcooper
post Jan 14 2010, 08:50 PM
Post#14


Microsoft Corp UtterAccess VIP
Posts: 1,839
Joined: 3-October 03
From: Bellevue, WA


Good question. Using LongPtr for Long may be harmless for 32-but, but not for 64-bit. As a result, you should try to use LongPtr where it is really needed.
For 32-bit VBA, LongPtr and Long are effectively interchangeable because they are both 4 bytes. However, on 64-bit, the type will be coerced to a LongLong at 8 bytes.
Where this becomes a problem more noticeably is with UDTs. Many structures in Windows have a member (often called cbSize) that is used to specify the size of the structure. In VBA today we calculate this using the Len function. The Len function adds up the sizes of the data types for the Type as we'll see in a moment.
One example of such a structure might be the SHELLEXECUTEINFO type which is defined as follows in 32-bit VBA:
CODE
    Public Type SHELLEXECUTEINFO
        cbSize       As Long
        fMask        As Long
        Hwnd         As Long
        lpVerb       As String
        lpFile       As String
        lpParameters As String
        lpDirectory  As String
        nShow        As Long
        hInstApp     As Long
        lpIDList     As Long
        lpClass      As String
        hkeyClass    As Long
        dwHotKey     As Long
        hIcon        As Long
        hProcess     As Long
    End Type

This type is used with the ShellExecuteEx API function.
The size of this type as returned by the Len function on 32-bit Windows is 60 bytes. This is because Long variables are 4 bytes each and internally String data types are also passed as pointers, making them 4 bytes as well. When passing the UDT to an API, the size of the structure must match or the function usually fails.
If LongPtr were used for each of the Long types, the size would still be 60 when running in 32-bit Office, but it would now be 120 on 64-bit Office. If each member of the type were scalable, this would be ok. However, the definition of cbSize in the structure is a DWORD which is always 4 bytes. As a result, LongPtr cannot be used here.
THere is the declaration as it should appear for 64-bit Office 2010:
CODE
    Public Type SHELLEXECUTEINFO
        cbSize       As Long
        fMask        As Long
        Hwnd         As LongPtr
        lpVerb       As String
        lpFile       As String
        lpParameters As String
        lpDirectory  As String
        nShow        As Long
        hInstApp     As LongPtr
        lpIDList     As LongPtr
        lpClass      As String
        hkeyClass    As LongPtr
        dwHotKey     As Long
        hIcon        As LongPtr
        hProcess     As LongPtr
    End Type

The size of the Type on 64-bit Ofifce is now 104. Unfortunately, it turns out that this is not correct. The reason for this is that on 64-bit Windows, variables are aligned on 8-byte boundaries. As a result, since there is a Long followed by a LongPtr in the structure, Windows will add 4-bytes of padding to the end of the Long variables. Since this happens twice in this structure, we need an extra 8 bytes, meaning that the correct size on 64-bit Windows is actually 112. Turns out that the Len function does not calculate the padding. As a result, in addition to changing the definition of the structure, you must also use the LenB function instead of Len. The LenB function calculates the total size in bytes needed, and will also include the padding. In this case, LenB of the type will return 112 which is correct.
Hope this helps,
Go to the top of the page
 
BananaRepublic
post Jan 14 2010, 09:10 PM
Post#15


Dungeon Cleaner
Posts: 1,520
Joined: 16-June 07
From: Banana Republic


Rob, thanks so much for taking the time to explain things- I'm glad to know now that my preconception of using scalable types where not appropriate may be actually worse.
do worry, though, that the transition from 32-bit to 64-bit is a bit more closer to the metal... one thing about VBA (well, the VB family, actually) was that it was expected that you don't have to know anything about pointers to program, so API declaration are usually challenging for non-programmers and 64-bit transition will make it more so because we must be now more aware of the pointers, a consideration we didn't have to deal with (I suppose that was somehow already true even in 32-bit only world, as there has been cases of people running into problems of Visual Basic playing fast and loose with implicit type conversion that would be a no-no in more pedantic world of C/C++). That was partially why I was wondering about how the 16/32 transition went down which happened long before I was in the racket.
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    4th July 2020 - 08:13 PM