Jump to content
Excelsior Forums

snowman

Excelsior Staff
  • Content count

    0
  • Joined

  • Last visited

Posts posted by snowman


  1. It seems you guys need a reality check.

    First, when XDS sales dropped to zero - there had been literally no sales for about a year - we had two options:

    • Dtop the product altogether, as we did with another failed product
    • Release it as freeware with no obligations on support and/or further development

    We opted for the latter.

    Second, Excelsior is a commercial company. We have a selling product that has many more paying customers than XDS ever had. We have clients paying us for software engineering services. We also mentor interns and teach a course on compiler construction at the local Uni. All this leaves very little room to work on a product put aside many years ago.

    Finally, the few remaining employees that worked on XDS back in the 1990s now have families, other projects, and other interests. Even when they have spare time, they are not necessarily willing to spend it on XDS.

    You are nearly a couple of decades late. Sorry.


  2. Then, what is technology that you propose in XDS to developing GUI applications for Win32? WinAPI only?

    Yes.

    Eh, easy development of GUI apps is unsolved problem in XDS-x86.

    Yes. The best attempt to solve this problem was Amadeus-3. It did not take off the ground.

    And I think it does not promote the growing to popularity of the product, in spite of its perfect code optimization.

    You are perfectly correct. But why do you think we are interested in investing in the growth of the popularity of XDS?

    Problem is, there is no market for Modula-2/Oberon-2, and we are not in a position to create it. But we like the languages and have some good connections in their communities. That is why we set XDS free instead of dropping it altogether.


  3. I'll second the interest in an OS X version. With that, this would be an excellent write once, compile everywhere tool.

    XDS-C has always been such a tool. I recall a customer who targeted five platforms with it, including Mac OS 9 and SunOS.

    If your development machine is a Mac, configure a small Linux VM and run XDS-C in it.


  4. We have issued Excelsior JET 7.6 Maintenance Pack 1 today, optionally bundled with the Java SE 6u29 support add-on. Download now if you are experiencing any issues or need to bring the Java SE 6 version up to date.

    If you are a paying customer of Excelsior JET 7.6, but the download instructions for the above updates are neither in your inbox nor in the junk mail box, request them from our Support Dept. at support@excelsior-usa.com.


  5. This canonical program

    public class hello
    {
     static public void main (String args[])
     {
       System.out.println("Hello, world!");
     }
    }

    compiled with Excelsior JET into a 64-bit Windows executable has been successfully run. After that, it has finished in time with the expected result. ;)

    Note: Even though many runtime routines and native methods are still replaced with stubs, a lot of compiled Java code has been executed. This is an important milestone that shows we are moving in the right direction.

    Stay tuned!


  6. Do you suggest we deploy the game without music and sound effects? The bugs are rare - letting thousands people download a version without music/sound would be worse IMHO.

    Cannot you send a version without sound specifically to people who reported the problem?

    Also try running my app on the conventional JRE with the -Xcheck:jni option and see if that generates any warnings on your system and on those people's systems.


  7. But our game depends on those libraries. It doesn't work without them. And I don't have a way to reproduce the problem on my machine. So how do you suggest to solve the problem?

    What exactly are those libraries? Cannot you subset your game's source so that it does not use one of them? Or perhaps you can switch off a feature (e.g. audio)?

    Fact is, that the Oracle JVM doesn't crash.

    We had a few customer issues like this in the past, and most of them were JNI misuses that did not trigger any crashes on the Sun JRE simply by coincidence. And all those apps crashed when run on JRockit and/or IBM JDK.

    Our CTO had written an article closely related to this topic last year:

    Switching JVMs May Help Reveal Issues in Multi-Threaded Apps

    I am not ruling out a bug in our product, but we need some way to reproduce it reliably.


  8. The updated Excelsior JET Roadmap is back online.

    In brief: the last 32-bit-only version is on track for October release, the first 64-bit preview is set to see the light of day before the end of 2011, and Java 7 is put aside in favor of an earlier 64-bit release, in turn expected to occur in about a year from now.

    We understand this may not align with your plans for Java 7 and therefore would greatly appreciate your feedback!


  9. I have similar crashlogs from all over the world (different operating systems & hardware). That's why I suspect it's not a hardware issue. Since we use some native libraries it might well be that one of them corrups memory somehow. But I have no idea how I could verify this hypothesis.

    Yes, most likely it's a misbehaving native library. I would try to disable them one-by-one, or use older/newer versions.


  10. We have reached the next internal milestone in the development of 64-bit Excelsior JET:

    • 64-bit JET Runtime DLLs are now part of regular automatic build
    • Compiled executables correctly load the JET Runtime components
    • Initialization of the 64-bit Runtime has passed and reached the point of first execution of Java code

    The next goal is running “Hello, world!”, which, in turn, requires execution of multiple Java SE platform classes on startup.


  11. Excelsior JET has produced the first 64-bit executable that starts and terminates correctly. It was compiled by a baseline (non-optimizing) AOT compiler that currently supports only “simple” bytecodes such as arithmetic operations and direct calls.

    All this may sound trivial, but actually indicates successful completion of a few large engineering tasks:

    • The baseline compiler has been completely re-implemented in Java (BTW, its 32-bit version has passed all JCK 6 tests)
    • 64-bit code emitter has been successfully integrated into the new baseline compiler
    • Lots of work have been done in the linker to support various JET Runtime structures for 64-bit platforms (which will not be limited to Windows and Linux, we hope ;) )

    Now we are working actively on the 64-bit runtime. Stay tuned.


  12. As you may have noticed, our forums were closed down for maintenance for over two weeks. The reason is that we've switched to a new hosting provider, and decided that it would be a good time to migrate to a new forum engine with more adequate counter-spam measures. We apologize for the migration taking a bit more time than expected.

    We have chosen IP.Board, which comes with converters from a couple dozen engines, including our good old SMF 1.1. So far it looks as if all the members and topics and posts were preserved. The password reset feature is in place too.

    If you notice any problems with the new forums, please do not hesitate to let us know. Just reply to this topic, or email our support.


  13. What we really say is that our product has passed the official Java Compatibility Kit test suite on those flavors of Linux. That does not preclude it from working on other flavors.

    Please note however that it only makes sense for us to run the JCK on systems officially supported by Sun, as our product includes the reference implementation of the Java SE API, licensed for commercial use.

×