Bug 688714

Summary:	ijs code doesn't work properly if compiled by mingw or borland c++
Product:	Ghostscript	Reporter:	Hin-Tak Leung <htl10>
Component:	Other Driver	Assignee:	Hin-Tak Leung <htl10>
Status:	RESOLVED FIXED
Severity:	normal	Keywords:	bountiable
Priority:	P4
Version:	master
Hardware:	PC
OS:	Windows 2000
Customer:		Word Size:	---
Attachments:	patch for building with mingw/borland/watcom

Description Hin-Tak Leung 2006-05-21 08:31:11 UTC

(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.

Comment 1 Hin-Tak Leung 2006-05-21 08:49:30 UTC

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.

Comment 2 Hin-Tak Leung 2006-05-21 09:14:42 UTC

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).

Comment 3 Hin-Tak Leung 2006-05-22 14:30:00 UTC

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.

Comment 4 Hin-Tak Leung 2009-01-18 20:30:35 UTC

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).

Comment 5 Hin-Tak Leung 2009-01-18 20:54:00 UTC

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

Comment 6 Henry Stiles 2009-06-18 11:26:42 UTC

Hello Hin Tak, please update the status of this bug.  Is it complete?

Comment 7 Hin-Tak Leung 2009-06-18 17:18:04 UTC

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.

Comment 8 Hin-Tak Leung 2009-10-27 11:25:19 UTC

patch commited as r10234 .