Ought to implement most of the following suggested sourcecode cleanups to
make porting the win32 runtime easier:

Date: Mon, 01 Apr 1996 13:42:43 -0800
From: Regis Crelier <###@###.###>
To: fy@Eng
Subject: more changes

Frank,

As we tried to compile the Win32 version of the
JDK 1.0 with our Borland compiler instead of using
Microsoft's VC, we found several problems in the
sources.
Please find attached, a list of them.

Concerning the initialization of the floating
point unit: you should add the following include
and statement in the initialization routine of the
interpreter (or somewhere else).

#include <float.h>

_control87(MCW_EM | RC_NEAR | PC_53, MCW_EM |
MCW_RC | MCW_PC);


Thanks,
Regis


------------------- sun.txt follows --------------------
These are the "inconsistencies" I found in the Java/Jdk sources, things that
shouldn't be there no matter what compiler is used to compile the sources:


- src\\share\\java\\include\\sys_api.h:
around line 74 there is the prototype:
  int sysAddDLSegment(char *);
this should be ( see definition in src\\win32\\java\\runtime\\linker_md.c ):
bool_t sysAddDLSegment(char *);

[FY: Probably, change the definition in win32\\java\\runtime\\linker_md.c to
 return an int. The Sun one is consistent with the declaration
]

- src\\share\\java\\lang\\io.c:
function java_io_FileInputStream_skip returns 0 instead of ll_zero_const.

[The above seems to already be fixed.]

- The floating point processor has to be switched in a state where
  floating point exceptions are turned OFF in javai.dll. Right now the
  java sources depend on a side effect of MSC compiles where floating point
  exceptions are caught and handled by the MSC RTL.
This causes 2 headers to be build wrong with MSC. Look in
  build\\win32\\java\\java\\cclassheaders\\java_lang_float.h and you'll see:
typedef struct Classjava_lang_Float {
#define java_lang_Float_POSITIVE_INFINITY 1.#QNANf
#define java_lang_Float_NEGATIVE_INFINITY 1.#QNANf
#define java_lang_Float_NaN 1.#QNANf
#define java_lang_Float_MAX_VALUE 1.#QNANf
#define java_lang_Float_MIN_VALUE 1.#QNANf
float value;
} Classjava_lang_Float;

In build\\win32\\java\\java\\cclassheaders\\java_lang_double.h:
typedef struct Classjava_lang_Double {
#define java_lang_Double_POSITIVE_INFINITY 1.#INFD
#define java_lang_Double_NEGATIVE_INFINITY -1.#INFD
#define java_lang_Double_NaN -1.#INDD
#define java_lang_Double_MAX_VALUE 1.79769e+308D
#define java_lang_Double_MIN_VALUE 0D
double value;
} Classjava_lang_Double;

  You can see that those sources are not compilable...

[I got no idea what the first part is talking about. As for the defines,
 it's okay for defines to contain crap, if no one ever uses it.
]


- src\\win32\\java\\runtime\\system_md.c:
The FT2INT64(ft) macro uses the '<<' and '|' operators instead of
  ll_shl and ll_or. It also uses int64_t casting instead of using the
  int2ll macro. Further down in the sysTimeMillis function the '-' and
  '/' operators are used instead of ll_sub and ll_div. Also constant
  10000 is used instead of going through the int2ll macro.
Further down again, in the ll2str function, a lot of int64_t math is
  done with operators instead of the macros. Lot of cleaning up to do there.
Further down again they supply a definition of an ll_shl function,
  claiming they do this to work around an optimizer bug in MSC. This should
  be bracketed with a MSC define so it doesn't interfere with an ll_shl
  function supplied with other compilers.

[Could you check?]

- There are a bunch of places where ll_zero_const and ll_one_const are
  used instead of ll_zero_const() and ll_one_const() which we use. I'm
  not sure what the policy is on those. Easy to find with grep. The
  issue is really that these macros use an int64_t cast instead of the
  int2ll macro. Maybe we should change our strategy by #defining
  ll_zero_const as int2ll(0) and ll_one_const as int2ll(1) in
typedefs_md.h.

[Could you check?]

- build\\win32\\java\\java\\mkopcodes.c:
The program never closes ANY of the files it opens and writes to ( there
  are about five of them ). The program exits with 'exit(0)'. It would
  be nice if a 'fcloseall()' or something similar was inserted at the end
  before exiting. We happen not to save the (complete) files if they are
  not closed properly before exiting. I guess MSC is so nice to close any
  open outstanding files.

- build\\win32\\makefiles\\make.rules:
The $(SUBDIRS) target executes the DOS command "@mkdir $@". Under some
  DOS versions this will return an errorcode if the directory already
  exists, which can stop the make proccess in its tracks. A better way
  to do this is "@if not exist $@ mkdir $@".