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

edited November 2022 in OpenInsight
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
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Revsoft



What is the criteria for
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Revsoft

Comments

  • edited November 2022
    @BarryStevens

    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.





  • @BarryStevens - Are you really interested in OECGI3.exe or OECGI4.exe? I ask because OECGI3.exe does not have a 64bit version AFAIK.
  • @BarryStevens,

    @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.
  • @DonBakke
    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
  • @BarryStevens
    We have a web app developed by someone else that has hardcoded oecgi3.exe in the web pages.

    A little bit of me just died when I read that...
    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

    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.
  • I sympathise. Unfortunately one can't control the legacy Technical Debt they have to pay down :(
  • But is anybody actually paying down that technical debt? If not, why not? I encounter technical debt issues constantly and it becomes very irksome to me when I see this used as an excuse for not moving forward.

    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.
  • One line at a time @DonBakke, and hoping it is not just covering the Vig!

    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....
  • change the port 8088 to 18088 in the wow6432 registry entry under oecgi3


    That worked - stopped the oengineserver (OI9) and started the oengineserverV10 (debug mode) and can see the expected activity and webpage fills.
  • 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
    I have not needed to physically rename OECGI4 to OECGI3 in my apps because this is never hardcoded.

    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.
  • @BarryStevens
    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.

    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.
    Can you output a logfile for the oengineservers for both OI9 and OI10 that captures what you see when you run in debug mode.

    I would assume so.
  • Notes on Renaming OECGI4.exe to OECGI3.exe
    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.
  • @JaredBratu

    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!
Sign In or Register to comment.