2010: Essential Diffs?
in [Help]
|
From: James A. Fortune on 15 Apr 2010 10:05 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 15 Apr 2010 14:40 "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 15 Apr 2010 14:41 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 15 Apr 2010 14:42 "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 16 Apr 2010 03:30
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 |