2010: Essential Diffs?
in [Help]
|
From: David W. Fenton on 12 Apr 2010 14:18 The Frog <mr.frog.to.you(a)googlemail.com> wrote in news:18782241-4cf8-4692-b236-84cbe9d4af41(a)q15g2000yqj.googlegroups.co m: > I am a little concerned at the hesitation surrounding peoples > adoption of the 64bit version. I would have thought that there > were significant advantages to having the 64bit version, > especially when it comes to performance. I posted these elsewhere, but here they are again: Office 2010 - about the 64-bit version - Office Watch http://news.office-watch.com/t/n.aspx?a=1403 Installing Office 2010 64-bit - Office Watch http://news.office-watch.com/t/n.aspx?a=1404 Office 32-bit or 64-bit - which version is installed? - Office Watch http://news.office-watch.com/t/n.aspx?a=1405 Office 32 and 64 bit on the same machine - Office Watch http://news.office-watch.com/t/n.aspx?a=1406 Preparing for Office 2010 64-bit - Office Watch http://news.office-watch.com/t/n.aspx?a=1407 Adding this one: Excel � a history of rows and columns http://news.office-watch.com/t/n.aspx?a=1408 > Native 64bit code runs seemingly much faster than 32bit > code on 64bit processors. As Banana explains, this is not always the case -- the extra overhead needed for managing larger memory structures could make it slower. Think Jet vs. SQL Server -- Jet can outperform SQL Server in some situations because it doesn't have all the overhead, though there are plenty of circumstances in which SQL Server will run circles around Jet (mostly having to do with large data sets and intensive operations). > I can understand that Windows API code would > need refactoring, but to be able to take VBA and run it as native > 64bit code I thought would have been a real boon. Hmm. I'm not sure that's what's happening. VBA is p-code, so it's neither 32-bit nor 64-bit. That is, the data format isn't changing at all. What is changing is that the VBA DLLs in the 64-bit version are compiled for 64-bit so that they can take advantage of the larger address space and be managed appropriately by the OS's memory manager. > I would imagine even > more so for heavy data analytical applications (where most of my > time goes these days.....). See the Excel article. It makes the point that most people won't get any advantage from 64-bit Excel, but that spreadsheets with large numbers of worksheets likely will. Those are pretty rare, in my experience. > Am I mistaken in thinking 64bit is a plus here? Microsoft sees it as an issue they want to avoid for a while and are making it hard to install 64-bit Office (see the cited articles for instructions). > Or is this just the same adoption scare that took place when > shifting from 16bit to 32bit code - or perhaps more of the Win > 95/98/Me to 2K 'scare' (OMG - I dont have DOS > anymore......whatever will I do.....Oh wait, it actually is > there......but I'm still scared.....). I don't recall any kind of "scare", I do recall that it took a very long time after we were running 32-bit CPUs until we had 32-bit software (at least 5 years). We're still very early in the transition to 64-bit Windows, with a lot of machines still selling that aren't 64-bit capable. For the 32-bit transition, I think the main stumbling block was changing the developers' mindset to avoid going direct to hardware. Thus, the problem wasn't strictly a matter of 32-bitness as opposed to 16-bitness so much as it was a matter of Microsoft's implementation of Win32 vs. Win16 (MS did the right thing, of course, in prohibiting direct hardware access). It was also happening at the same time as the conversion from DOS to Windows, so there were a lot of different issues adding baggage to help maintain the 16-bit tradition. > I would > like to think that moving to 64bit is the way to go, but perhaps I > am just wishful thinking. I think it's early. When I'm doing quotes for clients' new PCs, I'm specifying 64-bit Windows, but not 64-bit software. This has two benefits: 1. future-proof -- when 64-bit software becomes the norm, they'll be ready. 2. performance -- 64-bit Windows can still take advantage of the software by using more than 4GBs of RAM, even though each individual 32-bit app can't. In short, the OS can allocate the equivalent of the maximum RAM to each 32-bit app, which is something that can't happen on 32-bit Windows. The other thing is to make sure you don't buy a PC that is limited to less than 8GBs of RAM (though that's still common for laptops), since you may want to go 64-bit later in the life cycle of the machine. I'm not big on major OS upgrades, but Win7 is changing my opinion on that, being the first Windows version I've ever seen that performs better than its predecessors (faster than both Vista *and* WinXP on the exact same hardware). The problem with upgrading an existing machine to 64-bit Windows is more likely to be legacy hardware that lacks 64-bit drivers. So, I'd be very unlikely to recommend that anybody buy a new PC that is 64-bit Windows capable but that has 32-bit Windows installed. 64-bit Windows is the same price and so far as I know, absolutely no compatibility issues with properly-written 32-bit software. And if it does, you can use Win XP Mode or some other virtual machine to skirt the issue. So, basically: 64-bit Windows -- YES, right now, no exceptions. 64-bit applications -- NO, not yet, unless you have specific requirements where you can identify concrete benefits from using the 64-bit version. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Albert D. Kallal on 12 Apr 2010 19:00 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9D58918DE8CAEf99a49ed1d0c49c5bbb2(a)74.209.136.82... > >> I can understand that Windows API code would >> need refactoring, but to be able to take VBA and run it as native >> 64bit code I thought would have been a real boon. > Unfortunately, for AccDE it is compiled code, and some word and byte aliments problems occur with an accDE(32) as opposed to accDE(64). The choice we were given was to loose accDE (compiled VBA), or have to deal with 32 or 64 bit versions. We SCREAMED that we MUST keep the accDE ability when they asked do we really need this ability. Access is the only wart dog in office with compiled VBA. Indeed, even some of the Excel users jumped in and said that they often choose access over some excel applications because we had that mde or accDE ability to build applications that hide up the UI and code. So, this means: Access(64) accDE will not run on access(32), and access(32) accDE's will not run on access(64). You have to re-compile for the given version. mdb, or accDB don't have this problem, and the rest of office don't have this problem because with source code available, then VBA is smart enough to re-compile on demand...it can't do that with accDE... So, not only will one have to provide a 64 bit version of the runtime for those that run office(64), but we also have to provide a accDE compiled on a 64 bit box for them. Note that you can't mix Excel(32) and power-point(64) on the same version of office (VBA, spell checking and a WHOLE whack of libraries are shared between the office suite, so installer will PREVENT this mix+match). You can install previous versions of office(32) and then install office 64, but for office 2010, you can NOT mix parts or 32/64. So, you can't install excel 32 and then install excel 64 from the same version of office. If you deploying accDB, or mdb, then it should run find on access(32) or 64 (even for runtime). However, for a accDE, you have to pre-compile it and you have to do so on the correct os version of 32 or 64 bits. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: kgander on 13 Apr 2010 10:37 On Apr 12, 1:18 pm, "David W. Fenton" <XXXuse...(a)dfenton.com.invalid> wrote: <snip> > The other thing is to make sure you don't buy a PC that is limited > to less than 8GBs of RAM (though that's still common for laptops), > since you may want to go 64-bit later in the life cycle of the > machine. I'm not big on major OS upgrades, but Win7 is changing my > opinion on that, being the first Windows version I've ever seen that > performs better than its predecessors (faster than both Vista *and* > WinXP on the exact same hardware). The problem with upgrading an > existing machine to 64-bit Windows is more likely to be legacy > hardware that lacks 64-bit drivers. So, I'd be very unlikely to > recommend that anybody buy a new PC that is 64-bit Windows capable > but that has 32-bit Windows installed. 64-bit Windows is the same > price and so far as I know, absolutely no compatibility issues with > properly-written 32-bit software. And if it does, you can use Win XP > Mode or some other virtual machine to skirt the issue. 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. Kevin Anderson
From: David W. Fenton on 13 Apr 2010 15:20 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:lCNwn.101730$mn6.24043(a)newsfe07.iad: > "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message > news:Xns9D58918DE8CAEf99a49ed1d0c49c5bbb2(a)74.209.136.82... No, I didn't write what you're quoting. >>> I can understand that Windows API code would >>> need refactoring, but to be able to take VBA and run it as >>> native 64bit code I thought would have been a real boon. > > Unfortunately, for AccDE it is compiled code, and some word and > byte aliments problems occur with an accDE(32) as opposed to > accDE(64). Yes, but only with dependencies on outside DLLs, which in the case of API calls are 64-bit Windows DLLs. VBA itself is no different, it's only the outside dependencies that are different (and the linking involved in that). > The choice we were given was to loose accDE (compiled VBA), or > have to deal with 32 or 64 bit versions. We SCREAMED that we MUST > keep the accDE ability when they asked do we really need this > ability. Thank you and your companions for screaming. You forced them to make the right decision. > Access is the only wart dog > in office with compiled VBA. Indeed, even some of the Excel users > jumped in and said that they often choose access over some excel > applications because we had that mde or accDE ability to build > applications that hide up the UI and code. > > So, this means: > > Access(64) accDE will not run on access(32), and access(32) > accDE's will not run on access(64). Regular ACCDB and MDB files are not version specific, right? They will be recompiled on-the-fly for the target Access versions/OS version when run there, right? That is, an ACCDB created on 32-bit Access 2010 in 32-bit Windows if run on 64-bit Access in 64-bit Windows will be recompiled when you run any of its VBA code. Right? > You have to re-compile for the given version. mdb, or > accDB don't have this problem, and the rest of office don't have > this problem because with source code available, then VBA is smart > enough to re-compile on demand...it can't do that with accDE... Exactly. It's only the ACCDE and MDB that have an issue, because they are compiled and don't have the source code to recompile in context. Thinking about this, it seems very wise to deliver an ACCDB/MDB front end to users in a decompiled state, with no compilation. That is, decompile before distribution (and compact to clear out the discarded data pages), but don't recompile, since the recompiled code will have to be discarded and recompiled if the target system is not the same as the system on which you compiled. It's not a blocking issue, just one of "neatness," to me. > So, not only will one have to provide a 64 bit version of the > runtime for those that run office(64), but we also have to provide > a accDE compiled on a 64 bit box for them. Hmm. Makes for a new challenge for Tony. Tony? Are you working on this? It also makes me glad I've almost never distributed MDEs -- that allows me to basically avoid this problem. > Note that you can't mix Excel(32) and power-point(64) on the same > version of office (VBA, spell checking and a WHOLE whack of > libraries are shared between the office suite, so installer will > PREVENT this mix+match). You can install previous versions of > office(32) and then install office 64, but for office 2010, you > can NOT mix parts or 32/64. So, you can't install excel 32 and > then install excel 64 from the same version of office. Hmm. That's not what Office Watch is saying: Installing Office 2010 64-bit http://news.office-watch.com/t/n.aspx?a=1404 Make sure any Office add-ins, connectors, COM DLL�s etc that you rely on are explicitly stated as being Office 2010 and 64-bit compatible. You have to uninstall any 32-bit version of Office that�s on the computer. The 64-bit installer won�t convert or upgrade an existing Office installation. > If you deploying accDB, or mdb, then it should run find on > access(32) or 64 (even for runtime). However, for a accDE, you > have to pre-compile it and you have to do so on the correct os > version of 32 or 64 bits. This means 4 variations if you are supporting both 32/64-bit Windows and 32/64-bit Access. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 13 Apr 2010 15:23
kgander <kgander42(a)gmail.com> wrote in news:2acc278d-cade-49a3-9154-e6021fbacc2d(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. 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. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |