FWD » Core Development » Base Language

See #3257-15:

SESSION:CPSTREAM
NO-MAP stream output option
BINARY (in OUTPUT TO)

I propagated the binary attribute from RemoteStream to actual FileStream that does the string encodings. The preliminary tests work fine.

One question: I don't know exactly whether FileStream is a client side only or it can be used on server side too. I need this in order to correctly detect the OS we are emulating - so I either need access directly to registry or use the ThinClient instance.

Instances of FileStream are only ever constructed and used on the client side.

Code Review Task branch 3292a Revision

I did check in some minor changes for code formatting.

1. My only concern with the basic approach is just that it adds an extra trip to the client side when running on Windows and a CR is encountered. I guess this is not that much overhead in the common case of a file where the text to CR ratio is high. We can probably leave this as is.

2. The import com.goldencode.p2j.ui.chui.*; in FileStream is not a dependency we want to have. We have two ways to handle this:

• The result returned by TC.isUnderWindows() comes from EnvironmentOps.isUnderWindowsFamily() (either directly when TC is running on the server, or indirectly through an up-call to ServerPropertiesInspector.isUnderWindowsFamily()). The EnvironmentOps.isUnderWindowsFamily() will first try to lookup if we have an OS name override in the directory. If that doesn't exist, it will downcall to the client to lookup the os.name Java system property.
• The result from PlatformHelper.isUnderWindowsFamily() simply bases its result on the os.name Java system property of the local system (in this case the client).

The up-call to ServerPropertiesInspector.isUnderWindowsFamily() would be used if we need to allow the customer to configure our output to match the original 4GL system instead of the current client runtime system (the original system was Windows but they are running FWD on Linux). This is useful if the output would be incompatible or broken if we don't honor this.

The PlatformHelper.isUnderWindowsFamily() would be used if the original system doesn't matter and we just always need to operate with the current platform in mind.

output to be written directly without any conversion or interpretation. I don't know what else conversion and interpretation could mean

I believe this may reference the various ways that codepage conversion may occur.

If you set SESSION:CPSTREAM to a value that is different from SESSION:CPINTERNAL, then there is supposed to be some amount of implicit/automatic codepage conversion that occurs.

One can also specify the CONVERT [SOURCE codepage] [TARGET codepage] which can manually override the implicit behavior.

I think it is important to test both these cases and implement any modification of the implicit/explicit codepage conversion that actually occurs based on BINARY being set. Today FWD does not implement much in this area. But we do have the basic implementation in a skeleton form. We do track if conversion is needed (e.g. NO-CONVERT option), but we don't modify this decision based on the BINARY flag.

Considering this is checked in multiple places, it would be important to know if BINARY has the same affect everywhere.

From what I see, branch 3292a has been rebased from trunk 11157, but otherwise is not changed from my previous code review. Correct?

Greg Shah wrote:

From what I see, branch 3292a has been rebased from trunk 11157, but otherwise is not changed from my previous code review. Correct?

Right. I did not apply change(s) from note 6 yet.

From what I see, branch 3292a has been rebased from trunk 11157, but otherwise is not changed from my previous code review. Correct?

Right. I did not apply change(s) from note 6 yet.

OK, no problem. The runtime changes can be made later, in another branch.

I have chosen the EnvironmentOps.isUnderWindowsFamily() instead of TC.isUnderWindows(). The returned value can be configured in registry and defaulting to host OS JVM runs on.

Regarding the connection between BINARY and CP conversion. I did a few tests (well, there are a lot of code pages in convmap.cp and I cannot test all combinations) but I could not find any difference in converted and binary output except for the extra 0x0D character that doubles 0x0A when in non binary. I guess the ABL Reference is not really exact for this option, too.

I created a new branch (3292b) for this work but since the changes are limited to 3 LoC in FileStream, I will merge it into 1830b.