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/200..._coming_in_201
0/

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

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

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?
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


"David W. Fenton" <(E-Mail Removed)> wrote in message
news:Xns9BEFB50138EEDf99a49ed1d0c49c5bbb2@74.209.136.95...
>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/200..._coming_in_201
> 0/
>
> What does this mean for Access given that Jet/ACE is not 64-bit?
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/

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)

"David W. Fenton" <(E-Mail Removed)> wrote in message
news:Xns9BEFB50138EEDf99a49ed1d0c49c5bbb2@74.209.136.95...
>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/200..._coming_in_201
> 0/
>
> What does this mean for Access given that Jet/ACE is not 64-bit?
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/

"David W. Fenton" <(E-Mail Removed)> wrote:

>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/

"Tony Toews [MVP]" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> "David W. Fenton" <(E-Mail Removed)> wrote:
>
>>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?

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.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

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.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


"David W. Fenton" <(E-Mail Removed)> wrote in message
news:Xns9BF0B8B911536f99a49ed1d0c49c5bbb2@74.209.136.95...
> "Tony Toews [MVP]" <(E-Mail Removed)> wrote in
> news:(E-Mail Removed):
>
>> "David W. Fenton" <(E-Mail Removed)> wrote:
>>
>>>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?
>
> 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.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/

"Arvin Meyer MVP" <(E-Mail Removed)> wrote:

>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/

"Arvin Meyer MVP" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> 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 http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"Tony Toews [MVP]" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> "Arvin Meyer MVP" <(E-Mail Removed)> wrote:
>
>>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.

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.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"David W. Fenton" <(E-Mail Removed)> wrote in message
news:Xns9BF1E623156CCf99a49ed1d0c49c5bbb2@74.209.136.82...

> 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.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com