The Early Release of OpenEdge 11.3 on Windows includes a 64-bit GUI client. Most new Windows machines ship with 64-bit operating systems, so it seems to make sense that you would want a 64-bit version of OpenEdge to run on your 64-bit OS. That's not necessarily so. 64-bit versions of Windows can run 32-bit applications. You don't need to update all of your applications to 64-bit versions. So when does it make sense to do so and what are the trade-offs?
The main advantage of running a native 64-bit application is that 64-bit applications can address a lot more memory than 32-bit applications (8TB for a 64-bit application versus a maximum of 4GB for a 32-bit application). That sounds like a great advantage right there. But is it? Most applications don't use enough memory to need the extra address space. If your application never uses more than 500MB of memory it won't benefit from being a 64-bit application. A 32-bit application can easily access 500MB of memory, or even 2GB. Due to the way memory virtualization works, you won't run out of address space even if you run 10 copies of the application. You only run into the need for 64 bits of address space when a single application needs to access several GB of memory. If your application needs to use a lot of memory the 64-bit client will address that need, but you don't need to move to 64 bits just because you're running a 64-bit OS.
64-bit applications are also generally larger than the 32-bit versions. This is because 64-bit applications use 64-bit pointers and those larger pointers take up space. The 64-bit GUI client is about 25% larger than the 32-bit GUI client, mostly due to the larger pointers. This isn't much of a concern since everyone has large hard drives and a couple of megabytes won't be noticed, but it's another of the trade-offs that are made when you move to 64 bits. One thing that doesn't get bigger is the size of your r-code -- r-code compiled in a 32-bit version of OpenEdge is compatible with r-code compiled in a 64-bit version (leaving aside the usual things such as r-code version number changes and GUI/character mode incompatibility).
It is commonly believed that native 64-bit applications are faster than 32-bit applications, but that's not always the case. In fact, some 64-bit applications are slower because data structures tend to be larger in 64-bit applications (again, due to the larger pointers) and moving them around can slow things down. An application that is optimized for 64-bit Windows is likely to be faster than the 32-bit version, but many applications are I/O bound and are unlikely to see any performance gains.
I'm not trying to discourage anyone from using the 64-bit OpenEdge GUI client. I just want to make it clear that you don't need to use it just because your application is running on 64-bit Windows. Moving an application to 64 bits generally requires some development work, which I'll start talking about in another post. Some applications are a good fit for the 64-bit client and we're happy to bring it to you and we'll help you with any issues you run into. On the other hand, some applications won't be a good fit, but fortunately support for the 32-bit client will be around for a long time.
Can 32 & 64 bit co-exist on the same windows machine ? I know it was promised for 11.2 but I have not been able to test this yet.
If they can't co-exist 64bit client might be needed to allow for 64bit server.
We sometimes have small installations where database server and terminal server are the same .
The installer currently prevents you from installing both the 32-bit and 64-bit versions of the same release on a single machine. We are looking into removing this restriction but it will probably still be an issue when 11.3 ships.
If you have a situation that requires a 64-bit database server and 32-bit clients on the same machine you may be able to work around the restriction by manually installing the components you need instead of using the OpenEdge installer.
If you have a situation that requires a 64-bit database server and 32-bit clients on the same machine you may be able to work around the restriction by manually installing the components you need instead of using the OpenEdge installer.
Will there be documentation/tech support for that?
I threw that idea out there as a potential workaround for the issue Carl raised. I didn't mean it as an official statement. I know that some partners do install OpenEdge manually but we don't document how to do that. I can't comment on the supportability of such an installation, at least not without getting myself into even more trouble.
Installing both 32- and 64-bit on the same machine was an idea for a workaround for not having a 64-bit client. With a 64- bit client, what is the real use case for a joint installation? Is it only a migration issue? If you are delivering a 64-bit product, shouldn't all the pieces be 64-bit? (at least that is what many customers have been asking of OpenEdge ;-)
> With a 64- bit client, what is the real use case for a joint installation?
Testing.
As we may need to change our code (references to Windows DLL's) we can't just rely on OpenEdge to guarantee that the 32 bit and 64 bit clients behave the same. We need to test our own code as well, with as little as possible overhead.
> With a 64- bit client, what is the real use case for a joint installation?
1. Testing
2. As a work-around if certain features don't work in the 64 bit client.
As the 64bit client will be brand new chances are that certain things don't work. This is not necessarily Progress fault, it could be 3rd party components that don't function in 64 bit.
In the beginning of Linux 64 bit we also had to install 32 bit. I 'm not sure for which feature, I think it was for web services.