From: James A. Fortune on
On Apr 15, 5:10 am, The Frog <mr.frog.to....(a)googlemail.com> wrote:
> So we are effectively having to build two versions of the app -
> independantly. This is going to be a PITA by the sound of it. Still,
> like most things we are sure to get used to it in time.
>
> The Frog

Part of my plan for how to use Access in the future is to replace API
calls in Access with equivalent calls to the .NET Framework. IIRC, a
single copy of Visual Studio 2010 can target either 32-bit or 64-bit
versions. That's still not perfect, but it makes having two versions
of the app a little easier to manage.

James A. Fortune
CDMAPoster(a)FortuneJames.com

Most or all of the Win32 functions are now available as .NET BCL [Base
Class Library] functions. -- C# Core Language Little Black Book, Bill
Wagner, p. 276
From: David W. Fenton on
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in
news:kQsxn.98311$NH1.39393(a)newsfe14.iad:

> "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message
>
>>
>> I think the Office Watch folks are clever enough to know about
>> that already. They are clearly saying you can't have 64-bit
>> Office installed on a system with any 32-bit version of Office. I
>> can't read what they are saying the way you're interpreting it.
>>
>
> Ok, I will have to double check on this, but that was the way it
> was explained to me. Unless the windows os prevents installing of
> access 97 or excel 2000, I can't see those 32 bit versions of
> office not being allowed to be installed.
>
>>> True, while it is 4 variations, the office(32) runs equally well
>>> on 32 or 64 bit machines and that is only thus one accDE(32) and
>>> one setup to supply for office(32).
>>> I will not matter if the os is 32 or 64, it only matters about
>>> the version of office being 32 or 64. So, it is 4 variations,
>>> but it is only two versions of the accDE needed to cover those 4
>>> cases..
>>
>> Hmm. What about ACCDE/MDE that has API calls to Windows DLLs?
>> Won't that be a problem? Or is that entirely "late bound" so that
>> it doesn't change the compiled result?
>
> Yes, it is a issue because your memory pointers and SOME values
> are now 64 bits in length.
>
> So, you have to use conditional compiling to solve these issues:

Wrong issue entirely, since, as you point out, with conditional
compilation, you can have one codebase to compile for all
combinations.

My question is:

Does an ACCDE/MDE compiled FOR a target version of Access (32- or
64-bit) compiled ON a particular version of Windows (say, 32-bit
Access compiled on 64-bit Windows) work on the other combination?
that would be:

32-bit Access compiled on 64-bit Windows

Will it work on 32-bit Windows (with 32-bit Access, naturally)?

I have a feeling that it won't. Conditional compilation means at
compile time the p-code chooses one of the choices and when the
ACCDE/MDE creation processes strips the canonical code, you're left
with only one of the compilation options.

Now, the issue is, I guess, what DLLs the 32-bit version of Access
uses for compilation on 64-bit Windows. Obviously, that's going to
be 32-bit components, so I guess there shouldn't be an issue of
compiling on 32-bit Access on 64-bit Windows for distribution on
either 32- or 64-bit Windows.

[all the information about conditional compilation and new pointer
types deleted, as I already knew all of that and it wasn't germane
to the question]

So, basically, you need only 2 ACCDE/MDE versions, compiled in
32-bit Access and compiled in 64-bit.

Earlier, I'd said there were 4 variations, but while there are
theoretically 4 permutations of Access 32/64 and Windows 32/64, only
3 of them actually work -- you can't run 64-bit on 32-bit Windows.
So, these combinations are valid:

32-bit Access compiling on 32-bit Windows
32-bit Access compiling on 64-bit Windows
64-bit Access compiling on 64-bit Windows

This combination is invalid:

64-bit Access compiling on 32-bit Windows

So, given that 32-bit Access compiling on 64-bit Windows will link
to the 32-bit versions of the DLLs, you really only need to compile
in 32-bit Access and 64-bit Access. So, if you have to support both,
you need 64-bit Office, and at least one virtual machine, with the
other version of Access installed. I suspect I'll not have any users
on 64-bit Office, so this won't be an issue for me, but if I did,
I'm pretty sure my setup would be that my default Office would be
32-bit (running on 64-bit Windows) and I'd have 64-bit Access
installed in a VM for compiling for 64-bit Access when I needed it
(which is probably not going to be the case for a very long time).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on
The Frog <mr.frog.to.you(a)googlemail.com> wrote in
news:37f7bc54-f76c-4ccd-b448-cdb575131cf7(a)x3g2000yqd.googlegroups.com
:

> So we are effectively having to build two versions of the app -
> independantly. This is going to be a PITA by the sound of it.
> Still, like most things we are sure to get used to it in time.

No, you don't have to build two versions of the app. You write one
version with the conditional compilation that Albert outlined, and
then you have to compile for your target version of Access, 32-bit
or 64-bit. That is really not all that different than it ever was
(though there was some forward compatibility in the past).

And if your users are not using 64-bit Office, you won't need to
compile twice at all. If they follow the defaults that MS has
implemented, they will be using 32-bit Access, so you won't need to
compile two versions of your ACCDEs/MDEs.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on
"Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in
news:jssxn.56796$iu2.48699(a)newsfe15.iad:

> "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message
>
>> I would assume that you would start with a 64-bit Windows and
>> install Office 32-bit, and run a virtual machine with 64-bit
>> Windows on which you'd install the 64-bit Office. I believe this
>> is something that one of the Office Watch articles suggests
>> explicitly.
>
> Unfortunately, there is no 64 bit support in Virtual PC for guest
> os.
>
> So, you have use the free v-box, or something like vmware.

What's a "free v-box"?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: The Frog on
Hi again,

I think I was not clear in my earlier post about developing 2 apps at
the same time. I am referring to the 2 code versions at the same time
with the conditional compilation. As I see it we are going to end up
with a lot of double coding. Conditional compilation makes maintaining
the app a little easier (like code in the same place), but there is
still potentially a lot of extra work and debugging. To me that's a
PITA, but I would rather move forward and have the option of 64bit
than stagnate on 32bit.

The use of .Net for some things will make life easier, hence my
earlier question about native .Net support in A 2010. Looks like VSTO
is the way to go for this (or whatever the version for Office 2010 is
called).

I am, despite the concerned nature of my questions and posts, quite
looking forward to A2010 once it hits market. It sounds to me like a
great step in the right direction. I am awaiting it with eager
anticipation.

A V-Box is a virtual machine tool from Sun Microsystems (Oracle now?).
It is quite advanced in its implementation, very stable, and totally
free. I believe that it also supports hardware virtualisation at the
hardware level - or whatver it is called when you have the ability to
use the native hardware inside the VM. MS Virtual machine is not bad,
V-Box is better, and VMWare is still my preferred. For most things V-
Box is perfect, for server environments I would go with VMWare.

Cheers

The Frog
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10
Prev: Problem with query
Next: Append Query error with apostrophe