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?
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.
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:
Hope this helps, David
[quote user="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:
Hope this helps, David
[/quote]
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.
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.