Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
whento use WOW6432Node
I cant remember what the criteria is for OECGI3 related apps - which registry entry they go under. (On a server with related IIS entries))
What is the criteria for
What is the criteria for
What is the criteria for
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Revsoft
What is the criteria for
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Revsoft
Comments
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Revsoft should be the x64 OECGI path.
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Revsoft should be the x32 OECGI path.
That default location becomes a 'fallback' if the system is setup to have more specific entires (as I do running several instances on the same box)
e.g.
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Revsoft\OECGI4\Opto1
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Revsoft\OECGI4\Opto2
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Revsoft\WOW6432Node\OECGI3\OptoOld
If IIS is setup correctly, then the relevant OECGI will know to look for in its specific subfolder.
An interesting point that I have utilised, I have run an OECGI4 as an OECGI3 (just renamed because it was hardcoded throughout an old web application). The OECGI4 will look for, and use, an OECGI4 entry in the registry if it exists. Otherwise it will fallback to looking for OECGI3 entries, which is what I wanted. This works as long as you have no need to have OECGI4 entires as well. In those cases an actual OECGI3 must be used.
@DonBakke is right. My example above was a copy/paste job where I forgot to put in the WOW6432Node subpath for my OECGI3 entry to identify it as 32-bit. I have corrected that.
I didn't know that OECGI3 didn't have a 64-bit counterpart as I have never tried to use it. Good to know though. I only keep the v3 around because I am forced to for compatibility. I use 4.0.1.0 everywhere I can.
This leads me on to a question.
We have a web app developed by someone else that has hardcoded oecgi3.exe in the web pages.
When we convert the client to OI10 will it still work in OI10 and all we need to do is change the port 8088 to 18088 in the wow6432 registry entry under oecgi3
A little bit of me just died when I read that...
Probably, but you'll have to test. I have not needed to physically rename OECGI4 to OECGI3 in my apps because this is never hardcoded.
Don't get me wrong. This is not aimed at you (i.e., the developer). It is mostly a criticism against the stakeholders, managers, and decision makers who want to stand still rather that actually do anything that will create long term benefits. One cannot blame the technical debt and at the same time refuse to do anything about it.
In my opinion, most decisions based on the 'here and now' end up costing more in the long run. I think most of that is foreseeable as well....
That worked - stopped the oengineserver (OI9) and started the oengineserverV10 (debug mode) and can see the expected activity and webpage fills.
STOP PRESS - No it didnt!!!
@DonBakke
Are you suggesting that I need to rename OECGI4.exe to OECGI3.exe for it to work with OI10, or, will OECGI3.EXE still work under OI10. I have no need to use the extra features that are in OECGI4.exe.
Can you output a logfile for the oengineservers for both OI9 and OI10 that captures what you see when you run in debug mode.
That wasn't what I was suggesting, but I can see how that was inferred. My main point was that I've never had to worry about renaming the OECGIx.exe file.
OECGI3.exe might work because it doesn't talk to OI directly. It talks to the OEngineServer. This is done through TCP/IP, so I think it should work.
I would assume so.
This will work but OECGI will look in the registry path for the version it was compiled against. So if you rename OECGI4.exe to OECGI3.exe you'll have to setup the registry as if it were OECGI4 because when OECGI4 executes it's going to look for the OECGI4 registry paths even though it was renamed to OECGI3.
Notes on Legacy Issues
While renaming is a valid approach a better approach is to use REWRITE rules so that OECGI4 can be abstracted from the URL altogether and URLs that expect oecgi3.exe can be rewritten to the current oecgi version. A few times over the years I've seen oecgi3.exe and been confused because the registry changes weren't working only to find the client had renamed the EXE for the exact reason you're describing. Rewrite rules are a little more complicated to set up but establish a better path forward.
Thanks for the correction. It has been a bit since I have had to do this and I incorreclty described the registry side of how that worked.
Thanks for the tip about the rewrite rule. I agree, that is a better option and one I had not thought of!