Fextread32 fails in Tux 9.0 on Win XP Pro SP 2

Question

I have been checking out the new Tuxedo 9.0 release with a small test setup that worked fine with 8.1 on Win XP Pro, but gives a problem running on 9.0 - a native client crashes on a Fextread32 resulting in the message:
"<clientprogramname>.exe has encountered a problem and needs to close. We are sorry for the inconvenience."
(followed by an invitation to submit the problem to Microsoft!).
The only OS difference is that I am now using XP pro SP2. Does anyone have any words of wisdom regarding this before I open a case with Support? (It appears that the server also crashes on a Fwrite32 - can't say for sure as I haven't researched this yet).
(I am aware that the reference docs for these functions state that they may not be used in a /WS client, but I have used a native client. There seems to be a certain similarity with an earlier problem described in the thread "10 minute delay on Windows XP" - in a response Todd Little mentioned that XP Pro is not certified to run as a Tuxedo node executing BBL, etc. If this is the reason for the above problem then it is a bit unfortunate - I'm sure I am not alone in using the Windows XP Pro platform (which is our company standard for a laptop) for prototyping Tuxedo solutions!)
Thanks & best regards,
Malcolm.

Answer 1

The version of the Microsoft compiler supported by Tuxedo has changed
between Tuxedo 8.1 and Tuxedo 9.0.
The original Tuxedo 8.1 release on Windows 2000 required Visual C/C++ 6.0
SP4 or compatible. Libraries compatible with VC.net were provided as
downloads at a later date.
Tuxedo 9.0 on Windows 2003 and on Windows XP requires VC.net 2003
Professional.
This is important because Microsoft has changed the implementation of the
stdio library between compiler versions. The two APIs in which your program
is crashing both use FILE pointers that are allocated in the application and
then referenced in Tuxedo. The FILE structure has changed in newer
Microsoft compiler versions, and a FILE pointer allocated in one compiler
version cannot be used by a library linked with another compiler version.
BEA wrote the following compatibility description some time ago:
All existing Tuxedo Windows product binaries (DLLs) [for release 8.1 and
earlier] were built using either VC 5 or VC 6 , or some combination when a
Tuxedo certification involved testing of older binaries on new Windows
platforms. Because of binary compatibility support on Windows in the past,
Microsoft fully supported the "co-mingling" of older VC binaries with newer
version of the compiler (i.e. VC 5 with VC 6). However, MS has recently
stated that their support for VC 6 runtime in a VC.net environment
(co-mingled environment containing both a VC 6 runtime (Tux DLL) and a .Net
runtime (application built using VC.net)) is limited to invocations of
system APIs that do not span across both runtime libraries (ie objects must
be managed by it's own runtime libraries). For example, memory space
allocated via a malloc() call in one runtime library(e.g. VC 6) cannot be
released by a free() call in another runtime library (e.g. .Net 2003).
Based on BEA's own investigations and tests, the following issues have been
identified for Tuxedo applications in the co-mingled environment using VC
.Net:
1. If a Tuxedo application compiled with VC.net performs writes using
buffered IO library functions (e.g. fprintf) via a FILE handle (including
stdout, and stderr) and calls a Tuxedo function that also writes to the same
FILE handle, the output may not appear in same order as written. A similar
behavior occurs on input. This happens because separate buffers are used to
buffer the input and output in the two versions of the C runtime library.
NOTE: To date Microsoft has proposed several possible workarounds for
managing unbuffered output by calling setbuf(., _IONBF) , and  GetProcAddr()
in the application to get the address of setbuf in the VC 6 library.
However, these workarounds have potential performance implications and have
not been fully tested by the Tuxedo team and would require the customer to
verify their specific application and workaround with Microsoft Support.
2. Based on our analysis of buffer I/O within Tuxedo, the following
Tuxedo FML APIs are affected and cannot be used in the co-mingled .Net VC
environments. These APIs involve passing a FILE pointer from the application
to Tuxedo and violate the restriction on using CRT-bound objects across
different CRT versions:
FMLread(), FMLread32(), FMLwrite(), FMLwrite32(), Fread(), Fread32(),
Fwrite(), Fwrite32(), Fboolpr(), Fboolpr32(), Fvboolpr(), Fvboolpr32(),
Fextread(), Fextread32(), Ffprint(), Ffprint32()
3. A related issue occurs for Tuxedo servers. If the -e or -o options are
specified as command line options for an application server instance (to
redirect output to user-specified files), buffered output to stdout or
stderr (e.g. via fprintf) may not appear in the redirected files. NOTE: The
only known workaround for this problem is for customer applications to
explicitly manage own output redirection in their Tuxedo servers.
Microsoft has compiler compatibility information available at the following
URLs:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_c_run.2d.time_libraries.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.MD.2c_2f.ML.2c_2f.MT.2c_2f.LD.asp
http://support.microsoft.com/?id=140584
http://support.microsoft.com/default.aspx?scid=kb;en-us;94248
"Malcolm Freeman" <[email protected]> wrote in message
news:[email protected]...
I have been checking out the new Tuxedo 9.0 release with a small testsetup that worked fine with 8.1 on Win XP Pro, but gives a problem running
on 9.0 - a native client crashes on a Fextread32 resulting in the message:
"<clientprogramname>.exe has encountered a problem and needs to close.We are sorry for the inconvenience."
(followed by an invitation to submit the problem to Microsoft!).
The only OS difference is that I am now using XP pro SP2. Does anyonehave any words of wisdom regarding this before I open a case with Support?
(It appears that the server also crashes on a Fwrite32 - can't say for sure
as I haven't researched this yet).
>
(I am aware that the reference docs for these functions state that theymay not be used in a /WS client, but I have used a native client. There
seems to be a certain similarity with an earlier problem described in the
thread "10 minute delay on Windows XP" - in a response Todd Little mentioned
that XP Pro is not certified to run as a Tuxedo node executing BBL, etc. If
this is the reason for the above problem then it is a bit unfortunate - I'm
sure I am not alone in using the Windows XP Pro platform (whi
ch is our company standard for a laptop) for prototyping Tuxedosolutions!)
>
Thanks & best regards,
Malcolm.