 | |
#41
 
| |||
| |||
|
Re: 2010: Essential Diffs? -
04-15-2010
, 01:40 PM
|
"David W. Fenton" <XXXusenet (AT) dfenton (DOT) 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: |
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/
#42
| |||
| |||
|
|
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. |
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/
#43
| |||
| |||
|
|
"David W. Fenton" <XXXusenet (AT) dfenton (DOT) 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. |
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
#44
| |||
| |||
|
#45
| |||
| |||
|
|
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). |
VSTO, as was the case since inception of VSTO. VSTO support has been
pretty much limited to Excel, Outlook, Word and maybe Powerpoint.
This is not to say you can't use .Net at all -- it is possible to write
a DLL that Access can then consume but you have to write for COM
interoperability which I would think require quite well grounded
understanding of boht .NET and COM worlds. You also could still write a
Shared Add-In, which Access (and any other Microsoft Office) can consume
and the template at least get you set up quickly.
There are also more ways to get Access work with .NET but it's same
bottom line - requires a good amount of effort and understanding.
#46
| ||||
| ||||
|
|
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. |
you're not using many of those, you won't have much to do. There
won't be any conditional compilation sprinkled throughout your
non-API code, seems to me.
Quote:
|
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. |
Quote:
|
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). |
little deal with 32- vs. 64-bit!
[]
Quote:
|
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. |
is? People often mention Virtual PC and VMWare, but I've never heard
of v-box. I'm not enamored of Sun products, myself (if I could get
rid of Java, I'd do so in a heartbeat, as it's a pile of crap that
can't keep its runtime from corrupting itself with each of its
updates, which happen about once every 20 minutes), and would not
like to depend on them. This may be unfair, but it's just the way it
is for me.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
#47
| |||
| |||
|
|
"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote in news:jssxn.56796$iu2.48699 (AT) newsfe15 (DOT) iad: "David W. Fenton" <XXXusenet (AT) dfenton (DOT) 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"? |
http://www.virtualbox.org/
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com
#48
| |||
| |||
|
|
sorry, using voice dictation here: so: ridden customize = ribbon customize right click on a Redmond = right click on a ribbon now ridden development is far faster = now ribbon... |
in my mind, though, how I'd "right click on a Redmond". <GRIN>
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.