Access 2010 -- 64-bit Version

[David W. Fenton]

I see on The Register that MS is planning on releasing the next
version of Office in 32- and 64-bit versions:

http://www.channelregister.co.uk/2009/04/15/office_2010_coming_in_201
0/

What does this mean for Access given that Jet/ACE is not 64-bit?

 

[Arvin Meyer MVP]

Without revealing NDA information, what do you think given that VBA is not
64 bit, so none of the current apps would work on 64 bit either?

 

[david]

Since Win64 uses the same file system as Win32, no reason
not to just re-compile ACE as 64-bit.

OLE extends to 64 bit (it was built to handle 32/16), so no
need for complete re-write of office OLE.

However, to the extent that OLE is replaced by .NET, no
reason to expect 64-bit OLE objects.

So probably no 64-bit DAO, and 64-bit ACE may be
only .NET, if office allows you to link to NET assemblies
instead of OLE references.

Don't imagine they want to continue to distribute VBA engine,
but they need something. Could further extend macro language...
could add .NET. Could replace VBA with PowerShell runtime
engine. That runs in a hosting application and has an extensible
architecture that would allow addition of data objects.

(david)

 

[Tony Toews [MVP]]

What does this mean for Access given that Jet/ACE is not 64-bit?

How do we know Jet/ACE can't be recompiled into 64 bit?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[David W. Fenton]

How do we know Jet/ACE can't be recompiled into 64 bit?

If it can, then it's quite a good thing.

But there are major issues in Jet that have existed for a long time
(not multi-threaded, not threadsafe) that I think would have been
fixed if they had been easy to fix. I suspect that just recompiling
for 64-bit is not something that can be done without major
revisions.

 

[Arvin Meyer MVP]

Seems to me, again without revealing any NDA, that some of the same issues
that occurred when moving to 32 bit from 16 bit might be present. But since
16 bit Office was installable on 32 bit Windows, some issues didn't have to
be dealt with.

 

[Tony Toews [MVP]]

Seems to me, again without revealing any NDA, that some of the same issues
that occurred when moving to 32 bit from 16 bit might be present. But since
16 bit Office was installable on 32 bit Windows, some issues didn't have to
be dealt with.

Indeed. A couple of years ago someone was having a problem with the
Access 2.0 runtime and the Auto FE Updater. So he emailed me his
setup. It worked just fine in Windows XP and I figured out the
problem.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[David W. Fenton]

Seems to me, again without revealing any NDA, that some of the
same issues that occurred when moving to 32 bit from 16 bit might
be present. But since 16 bit Office was installable on 32 bit
Windows, some issues didn't have to be dealt with.

Well, that's how it runs on 64-bit Windows now, by hooking into the
32-bit subsystems that are there for backward compatibility.

But a fully 64-bit app can't have any 32-bit components, as I
understand it. If you do, you sacrifice security and stability, just
as you did with 16-bit components of Win9x (i.e., 32-bit software
ran on Win9x, but certain 16-bit subsystems made it less stable than
when running in a full 32-bit context; e.g., when fully 32-bit, full
pre-emptive multi-tasking in its own virtual machine; when dependent
on 16-bit, cooperative multi-tasking for all 16-bit apps in a shared
virtual machine).

I don't know what the future is of Jet as part of Windows (it's
still in Vista, and I assume it's still in Windows 7), but I can't
imagine that MS would want to have a component of a 64-bit OS be
32-bit (except for legacy support). I really don't quite understand
the role that Jet plays in Windows, in any event (there seems to be
confusion about the Red vs. Blue Jet engines and Active Directory,
which is the supposed reason for Jet being an OS component), and I
also don't know if that role is changing.

Anyway, just a bunch of speculation on my part, I guess.

 

[David W. Fenton]

Indeed. A couple of years ago someone was having a problem with
the Access 2.0 runtime and the Auto FE Updater. So he emailed me
his setup. It worked just fine in Windows XP and I figured out
the problem.

This doesn't really address the original question, though. The fact
that a 16-bit app runs on 32-bit Windows is wonderful, of course.
But it does so by sacrificing stability.

It's also an old, unsupported Office application.

We're talking about the newest version of Office here, not some old,
out-dated one that's no longer even supported.

Why would MS want to run it non-natively on 64-bit Windows? It would
really go against the whole security focus of C# and managed code,
seems to me.

 

[Arvin Meyer MVP]

Anyway, just a bunch of speculation on my part, I guess.

Those who might have a bit more knowledge are under NDA and won't discuss
anything that's non public. If you are looking for an early look, it might
be a good idea to try and get on the beta test team.

 

[David W. Fenton]

Those who might have a bit more knowledge are under NDA and won't
discuss anything that's non public. If you are looking for an
early look, it might be a good idea to try and get on the beta
test team.

Well, *that's* not going to happen as I'm not about to run 64-bit
Windows!

I think that the Access dev team ought to want clarify this as soon
as there's an actual announcement (remember, what prompted my post
was not an official MS statement). Based on what I've seen on
Stackoverflow.com, there's already a lot of people running into
problems trying to use Jet/ACE in 64-bit apps using C# who can't. I
am surprised that C# programmers want to use Jet, but glad they see
its virtues and want to see it continue to be widely available to
all developers on all Windows platforms.

 

[Arvin Meyer MVP]

I
am surprised that C# programmers want to use Jet, but glad they see
its virtues and want to see it continue to be widely available to
all developers on all Windows platforms.

It's not just C# programmers. Many different language programmers often use
Jet engine databases.

 

[Tony Toews [MVP]]

This doesn't really address the original question, though. The fact
that a 16-bit app runs on 32-bit Windows is wonderful, of course.
But it does so by sacrificing stability.

What instability? It worked.

It's also an old, unsupported Office application.

We're talking about the newest version of Office here, not some old,
out-dated one that's no longer even supported.

Why would MS want to run it non-natively on 64-bit Windows? It would
really go against the whole security focus of C# and managed code,
seems to me.

I don't see what 64 bit Jet/Ace/Access has to do with security, C# and
managed code.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Jeff Conrad [MSFT]]

Hi David,

I'd love to answer some of your questions, but of course I'm unable to at
this time. The best place to watch is the Access Team Blog for any
information on this topic.

It would be great if you were able to do some Beta testing on the next
release.

--
Jeff Conrad - Access Junkie - MVP Alumnus
SDET - XAS Services - Microsoft Corporation

Co-author - Microsoft Office Access 2007 Inside Out
Presenter - Microsoft Access 2007 Essentials
http://www.accessmvp.com/JConrad/accessjunkie.html
Access 2007 Info: http://www.AccessJunkie.com

 

[David W. Fenton]

What instability? It worked.

Well, if you're running multiple 16-bit apps, they run in a single
virtual machine using cooperative multi-tasking. Thus, if one of
them dies, it may take the others with it.

I don't see what 64 bit Jet/Ace/Access has to do with security, C#
and managed code.

32-bit code cannot use the more advanced code protection services
offered in the 64-bit version of Windows. COM components cannot be
used with managed code, which is less secure (because more
vulnerable to buffer overflows, etc.). At least, that's how the need
for all 64-bit components was explained to me on Stackoverflow by
people who were using C# and writing 64-bit apps.