2010: Essential Diffs?
in [Help]
|
From: David W. Fenton on 14 Apr 2010 13:40 kgander <kgander42(a)gmail.com> wrote in news:e9793495-9341-4794-981b-c8d8a377680e(a)g30g2000yqc.googlegroups.co m: > On Apr 13, 2:23�pm, "David W. Fenton" > <XXXuse...(a)dfenton.com.invalid> wrote: >> kgander <kgande...(a)gmail.com> wrote >> innews:2acc278d-cade-49a3-9154-e6021f > bacc2d(a)z11g2000yqz.googlegroups.co >> m: >> >> > For a new 64-bit PC where you'll regularly run software in XP >> > Mode, it's best to make sure it supports hardware >> > virtualization. Hardware virtualization isn't required, but it >> > should run XP Mode substantially faster. �My guess the same is >> > true for WOW64 (Windows7's 32-bit emulation layer). >> >> > Microsoft has a free Hardware-Assisted Virtualization (HAV) >> > Detection Tool you can download from their website. >> >> I would assume that all new hardware is going to support it. It's >> rather hard to run a tool on a computer you don't have in front >> of you, of course. > > True, but there will be plenty of non-HAV PCs for a while, so it's > good to know how to avoid them. And if I were specing machines > out for a client, I'd make sure they knew about this limitation in > advance. It's not something PC sales people will point out. Salespeople? When buying a PC, I haven't dealt with a salesperson in a store in, oh, I don't know, 15 years? How do you tell if a machine is HAV-capable? Are certain CPUs required? Is there a list somewhere? >> I'm not big on upgrading Windows, but Win7 is the first in a long >> time that I'd recommend it. I've done it for a 7-year-old >> Thinkpad laptop and it's been a huge win, faster than the >> previous WinXP, in fact. But, of course, that's 32-bit, not >> 64-bit, and the memory recommendations are irrelevant, and it has >> only 1.5GBs of RAM, so I don't think running a virtual machine is >> a practical option. > > That's very encouraging to hear. I was stunned at this result, though on the original upgrade it had only 512MBs of RAM (I added 1GB to it for $50), it still ran just fine (though I wasn't testing it with anything particularly heavy-duty). I'm a HUGE Win7 fan. I'm trying to get all my clients to buy new PCs so they can get the benefits of it, certainly in terms of performance, but also in UI. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Albert D. Kallal on 14 Apr 2010 19:42 "The Frog" <mr.frog.to.you(a)googlemail.com> wrote in message news:019e6cae-ed43-4360-b512-\ > > The question then becomes - assuming Win7 64 bit OS and Office 2010 32 > bit - how does one compile an accDE 64bit for a 64bit client? You > would need to have another machine with a separate install of Access >uld seem. You are 100% correct. You will need to compile that accDE on a 64 bit box for your customers that are running office 64. > Or just ship the app uncompiled. I prefer to compile, > but that is just a preference of mine. Yes, but you can't do that with a accDE. > > Does anyone know if you could install a 32bit runtime on a system that > has 64bit Office? That would eliminate most of the hassles right > there. No, as the runtime not any different and has always been much the same install as the full version (including the same bugs and problems). As mentioned, the issue is shared parts like spell checker etc. However, I suspect that sagekey might not have this issue as they keep the office parts separate and thus I certainly is a possibility here, but not likely with the runtime package wizard we have... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 14 Apr 2010 19:44 "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. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 14 Apr 2010 20:09 "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: eg: #if Win64 then Declare PtrSafe Function MyMathFunc Lib "User32" (ByVal N As LongLong) As LongLong #else Declare Function MyMathFunc Lib "User32" (ByVal N As Long) As Long #end if Note the 64 bit word size being used in the above (LongLong). Most values even from 64 bit api ARE long, but the memory pointers MUST be 64 bits in length. If VBA had a true pointer data type, then the change over would be less painful. However, we used long for both values and pointers...and that hurts us. And, for code to run/work in PREVIOUS versions of office, you can go: #if VBA7 then Declare PtrSafe Sub MessageBeep Lib "User32" (ByVal N AS Long) #else Declare Sub MessageBeep Lib "User32" (ByVal N AS Long) #end if link here: http://msdn.microsoft.com/en-us/library/ee691831(office.14).aspx So, any com or activeX that is 32 bits such as a treeview can't be used with office 64 And, for automation you can't mix in-process 32 and 64 bit applications. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: The Frog on 15 Apr 2010 05:10
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 |