(This is just a place holder for submitting patches - I have got fixes for this and will attach when I have thoroughly tested the change) In the course of looking at bug 688653, I tried to compile my ijs server under mingw, does not work properly, and tried with borland and going back to the ijs example client/server code and they don't work correctly with mingw-gcc or borland either. Had a little discussion with Russell Lang on irc, and managed to figure out the issue as follows, mostly to do with binary<->text translation policies: (1) on the server end (which isn't used by ghostscript), "ifdef (MSC_VER) setmode binary" needs to be changed to "if defined(MSC_VER) || defined (BORLAND) || defined (MINGW) setmode binary". (2) on the client end (which is also used by ghostscript's gdevijs), the situation is a bit complicated - it seems different compiler+runtime has different opinion about what "0" means for the 2nd argument of open_osfhandle: _open_osfhandle((LONG)hChildStdinWr, 0) The behavior seems to be this: VC+wine: binary VC+win2k: binary Borland+wine: text borland+win2k: text mingw+wine: text mingw+win2k: binary My guess for this anomaly is that both VC and borland inlines or statically links part of the C runtime, where as mingw don't; wine's msvcrt _open_osfhandle implementation (the source is available) defaults to text unless _set_fmode(binary) has been called.
It is still somewhat curious that unpatched borland client/server binaries don't talk to each other nor the others - borland may have some strange asymetric defaults - e.g. write ascii but read binary or vice versa.
tested and confirmed borland's read/write default is asymmetric - write is ascii, read is binary. (by setting only one of setmode's in ijs_server.c).
The changed code is in (for the impatient ones): http://bugs.ghostscript.com/attachment.cgi?id=2220&action=view Will tidy it up, add some suitable comments and send it as a diff soon.
Created attachment 4730 [details] patch for building with mingw/borland/watcom Please review and commit. All the compilers I tested (borland,mingw,openwatcom) besides MSVC defines _WIN32, so I think it is more appropriate to use _WIN32 for generic windows changes, and only use a compiler-specific define when a compiler behaves differently from the others. This patch basically declares explicitly that the ijs client/server should be in binary mode, and fixes up some differences between compilers. In addition, there are two bug fixes, one for an unchecked error in ijs_invoke_server which falls through and causes mysterious error later, and a printf %s format correction for char *(ph->cs).
I have tried all the combinations of ijs_client_example -s ijs_server_example This should finish silently without any error messages. Out of the 8 binaries and 4x4 combinations, unfortunately openwatcom-compiled client (with any of the 4 servers) is still broken; but it failure seems not to be due to binary/text translation - it fails to write the very first message to the file handle. I suspect it might be a compiler bug (openwatcom's O_BINARY is 0x200 rather than 0x8000 like everybody else, and I tried changing that) so I am somewhat reluctant to spend any more time on it. If somebody has the older and less-buggy watchcom 10.6 wants to test and report, it might be interesting. The commands I used for building the 3 sets of binaries besides msvc ones are this: mingw: gcc -o output.exe <SOURCES> borland: set path=C:\Borland\BCC55\Bin;%path% bcc32 -I"C:\Borland\Bcc55\include" -L"C:\Borland\Bcc55\lib" -eoutput.exe \ <SOURCES> openwatcom: wcl386 -cc -fe=output.exe <SOURCES> where <SOURCES> is either ijs_server_example.c ijs_server.c ijs.c or ijs_client_example.c ijs_exec_win.c ijs_client.c ijs.c
Hello Hin Tak, please update the status of this bug. Is it complete?
The patch is complete regarding the original reported issue - please review and commit. openwatcom-1.7-compiled client still seems to be broken, but its cause seem to be different and 1.8 (released in Feb) may work better. I'll post the patch to gs-code-review.
patch commited as r10234 .