Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-1246923

(porting) win32 sourcecode cleanups for portability



    • Subcomponent:
    • CPU:
    • OS:


      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


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


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

      [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 $@".




            hongzh Hong Zhang
            egilbertsunw Eric Gilbertson (Inactive)
            0 Vote for this issue
            0 Start watching this issue