We now have two problems showing up in the 4.0 beta that can only be classified as beyond bizarre and both seem to point to problems with the _read() function in the C runtime library. I'm not sure I have any good solutions at this point.
In 3.2.0, the stream library was implemented using the higher-level stdio functions. A fairly large amount of the stream library was devoted to getting around differences in the different system and essentially using the stdio functions as if they were the low level IO routines in the first place. In 4.0, each platform provides a SysFile class that encapsulates the I/O functions and provides many of the functions of C runtime higher level I/O routines, but in a fashion that is more tightly tuned to ooRexx's needs. All I/O access is done using the low-level functions (open() vs. fopen(), read() rather than fread(), etc.). Both problem give the symptom that the _read() function appears to be picking up data from someplace other than the opened data stream. I have tried all sorts of solutions to this, but in the end, it all boils down to "this should work". I'm not sure where to go from here. One potential solution would be to "go native" and try bypassing the C runtime functions and use the Native Windows APIs in the SysFile implementation. This is not too terribly hard to do (I think), though performing the mappings for things like open will be a bit of a pain to implement. I have a sandbox branch already where I sort of started doing this, but have generally been tied up with other fixes to make much progress with it. I'm hesitant to really go this route for a couple of reasons. 1) What do we do if it doesn't fix the problems, and 2) This is a fairly big change to introduce in the beta. But then, we might not really have much choice. Note that going back to the old stream library is definitely not an option. That had some serious issues of its own, and would still need to be completely reworked for the new APIs and 64-bit support. That would be an even larger change than bypassing the C runtime (and would impact the unix systems as well as Windows). Anybody else have any ideas on how to approach this? Moving to a dynamically linked C runtime looks like a dead end for a lot of reasons. I wish I could figure out what the root cause for these problems. Rick ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
