Is it possible to have Windows specific code in a program that is run on UNIX/Linux Appserver? - Forum - OpenEdge Development - Progress Community

Is it possible to have Windows specific code in a program that is run on UNIX/Linux Appserver?

 Forum

Is it possible to have Windows specific code in a program that is run on UNIX/Linux Appserver?

This question is not answered

I need to run a program (.p) on both client (Windows) and appserver (UNIX). We compile code on Windows environment. If I can condition the program to not run the block of code with Windows specific code (ex. .NET Framework reference, Win32 API) when running on the appserver, will it work? 

All Replies
  • Why would you not compile it separately for the two platforms?   Perhaps using preprocessors to omit the Windows specific part?

    Or, why not parse the program into two programs?  One is run in both environments and the other is a persistent procedure or class or whatever that is only substantiated and accessed in a Windows environment.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Just wondering if it is possible before I go about creating separate program files.

  • Yes, this is fine.  R-code is not platform dependent. See KB for full explanation:

    "6: R-code is NOT platform dependent" here:

    https://knowledgebase.progress.com/articles/Article/20922

    (As a side, we also compile on Windows and ship the R-code to HP-UX-IA64.  Those are about as different as two platforms can be.  Thank goodness that HP-UX won't be a consideration very much longer...)

    Insofar as running platform-specific code, you just check the result of OPSYS and do a different thing if you are on a non-windows platform.  (Oddly the identifier for windows is "WIN32" even if your stuff is all 64 bit.)

    CASE OPSYS:
    WHEN "unix" THEN OS-COMMAND ls.
    WHEN "win32" THEN OS-COMMAND dir.
    OTHERWISE MESSAGE OPSYS "is an unsupported operating system".
    END CASE.
    

    I'd highly recommend reading this documentation if you do development that targets multiple platforms.

    "Coding for Portability" here:

    https://community.progress.com/community_groups/openedge_general/w/openedgegeneral/2911.openedge-11-7-product-documentation

    Hope this helps, David

  • There’s also the OPSYS pre-processor.
  • dbeavon

    Yes, this is fine.  R-code is not platform dependent. See KB for full explanation:

    "6: R-code is NOT platform dependent" here:

    https://knowledgebase.progress.com/articles/Article/20922

    (As a side, we also compile on Windows and ship the R-code to HP-UX-IA64.  Those are about as different as two platforms can be.  Thank goodness that HP-UX won't be a consideration very much longer...)

    Insofar as running platform-specific code, you just check the result of OPSYS and do a different thing if you are on a non-windows platform.  (Oddly the identifier for windows is "WIN32" even if your stuff is all 64 bit.)

    1
    2
    3
    4
    5
    CASE OPSYS:
    WHEN "unix" THEN OS-COMMAND ls.
    WHEN "win32" THEN OS-COMMAND dir.
    OTHERWISE MESSAGE OPSYS "is an unsupported operating system".
    END CASE.

    I'd highly recommend reading this documentation if you do development that targets multiple platforms.

    "Coding for Portability" here:

    https://community.progress.com/community_groups/openedge_general/w/openedgegeneral/2911.openedge-11-7-product-documentation

    Hope this helps, David

    Thanks. What's really throwing me off are the Windows specific variable definitions (ex. AS System.Object). I'm not sure if those are seen early on by the platform the r-code is running on, or only when the variable is finally hit/run during run-time.

  • It's my experience, that any .NET Variable definition etc. in r-code kills AppServer agents on Unix.

    We use conditional compilation to keep those out of the r-code.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • As Thomas mentioned, you are probably better off to not get anywhere near those variables at runtime (in linux).  

    Those variables can be isolated into separate programs/classes.  (eg. into some derived subclass that is windows-specific and never gets loaded into the AVM on the linux side).

  • Also, consider this:

    community.progress.com/.../6963

    On version 11, if you run a .r file with interface in Windows and Linux, it's ok if in Windows you run with _progres. If you plan to run with prowin32 and _progres, it does not work.

  • We just tested this scenario on the appserver. Windows specific variable definition does work as long as no code runs that references the variable.