Quick question. I've asked this before but not directly.
First, I should say that we run OE on a couple of platforms, HP-UX and Windows (for PDSOE development). Occasionally we run into an OE bug on one that doesn't apply to the other. For example, right now I have an open support case about a problem where the AVM client hits an "access violation" when running a procedure having an OUTPUT BIND dataset.
Having said that, does anyone know which is the platform that the Progress developers use who are actually *building* the OE products (ie the "AVM")? Does their preliminary software development work start on Windows or Linux (eg CentOS)? What dev tools and IDE's do they use (c/c++ compilers)?
It would be helpful to know. Even if we put actual bugs aside, there are also performance challenges that cause OE to behave in one way on a certain platform and in another way somewhere else. But I imagine things start on a platform where the software is first developed, and the other platforms are measured against it.
The standard thing we always hear is that Progress supports all its platforms equally (AIX, Solaris, HP-UX, Linux, and Windows) but this is not a support question. So I'm not asking a support question, but inquiring which platform is the place where new ABL enhancements are born (eg. like the ongoing work in OO ABL).
Hopefully this is not top secret information and someone has an idea. If we can find out where Progress does its development of the ABL language, it will be an attractive platform for our own development work as well (building ABL-based applications ).
The OpenEdge development environment is cross platform. We can access the codebase and the build and test environments from machines running any of the OS's we support. Developers are free to develop new code on any platform. Some developers choose to use Windows for most development work, while some choose a flavor of Unix (Solaris is probably the most popular) or Linux (CentOS, SuSE, and Red Hat are available). I don't have data about which is most popular. I use Windows. A lot of other developers use Unix or Linux.
The process for building the AVM on Windows and building it on Unix or Linux is the exact same because our tools hide the details such as what compiler and linker is used. We use Microsoft Visual Studio on Windows. I don't pay too much attention to what is used on Unix/Linux because it's fairly transparent.
Build platforms and compilers are listed in the Platform and Product Availability Guide. It answers some of your questions.
Thank you that is helpful; I see that there is a version of the OS designated as the "build platform" and they even show the compilers that are used on each..
But I was also hoping someone might know which platform is used for the actual development work of new features in the AVM. (ie. where the OE developers at Progress do their day-to-day programming as they make changes to OpenEdge).
The OpenEdge development environment is cross platform. We can access the codebase and the build and test environments from machines running any of the OS's we support. Developers are free to develop new code on any platform. Some developers choose to use Windows for most development work, while some choose a flavor of Unix (Solaris is probably the most popular) or Linux (CentOS, SuSE, and Red Hat are available). I don't have data about which is most popular. I use Windows. A lot of other developers use Unix or Linux.
The process for building the AVM on Windows and building it on Unix or Linux is the exact same because our tools hide the details such as what compiler and linker is used. We use Microsoft Visual Studio on Windows. I don't pay too much attention to what is used on Unix/Linux because it's fairly transparent.
I can certainly understand the platform-specific concerns that a developer would need to take into account. But in the case of OUTPUT BIND datasets, even my support tech didn't think there would be much difference from one platform to another. It doesn't seem like this stuff would interface with the OS in a totally different way from one platform to another (or if there were differences then they would be buried pretty deep in memory management calls, which are probably abstracted).
However, I understand that there are always differences in play. I think HP-UX uses a different endianness than Windows/Linux so maybe that could be a factor. And generally Windows/Linux run on the same chips so maybe there is some common hardware reason for the difference in behavior.
Anyway, OUTPUT BIND datasets are just the current example of a difference in behavior that we've seen between platforms.
By build platform, it means the operating system and compilers, etc. that are used to be the release version for a particular version. For example, there are multiple certified Linux operating system variants that are supported but there is only one 32 bit linux build and one 64 bit linux build for all of them.
same for windows - there is not a separate build for every windows version that is supported.
on the "build platform”, the products are compiled, linked, packed and tested. this is done by automated scripts and various tools on a regular basis. when a release is imminent, testing is a bit more rigorous and automated tests are supplemented by more manual testing (e.g. install testing).
as others have pointed out, the systems used by developers on any given day have little to do with the build platform and vary from person to person.
I mostly used either Solaris or Linux.
> I think you are thinking too much on this stuff.
Maybe. My previous "platform-specific" issue (about 5 weeks ago) wasn't even a coding issue that Progress would fix. It was a "DEP" issue in Windows.
Apparently OE isn't yet compatible with Windows "Data Execution Prevention (DEP)", and that can cause a whole variety of issues on Windows that don't happen on HP-UX. In fact, "DEP" would have been my first guess at the reason behind the current "access violations", assuming I hadn't already turned it off. (And the current problem happens in Linux too)
As a side, it is unfortunate that Progress doesn't detect the fact that DEP is turned on (as it is by default) and prevent the installation of OE products by its installers. As it is, I suspect most new OE customers on Windows learn about this stuff the hard way.
My support tech closed the case after we turned off DEP and the problem went away (it had been causing memory violations on a daily basis). I run OE 11.6 on Windows 2012 R2.
He said pretty clearly that having DEP turned on was a misconfiguration.
Here are the KB's that I was pointed to :
knowledgebase.progress.com/.../P160813
knowledgebase.progress.com/.../P119884
If OE became DEP compliant at some point, then we should probably get the KB updated. The KB doesn't specifically name the version of Windows that I'm running (Windows 2012 R2) but it does say that DEP causes problems in all supported versions of OE. It also says the problems *started* when DEP was introduced in Windows 2003 SP1, and doesn't say that the problems ever went away. All the searching I've had done about this indicate that OE won't work with DEP turned on. And my support tech certainly didn't think DEP was supported since this was his "goto" fix for access violations and it ended up working.
Having said this, I must admit that I got pretty far with DEP turned on. I didn't start seeing failures until I started using the ABL adapter for Sonic. That is the piece that worked fine for us in HP-UX. and only worked fine in Windows after disabling DEP.