Jump to content
Excelsior Forums

snowman

Excelsior Staff
  • Content count

    0
  • Joined

  • Last visited

Everything posted by snowman

  1. Usage in Open Source

    You mix compilation and distribution. Simply put, GPL permits you to do whatever you want with the source code, the restrictions are on distribution. You may only redistribute GPL apps compiled with VC++ if you link to the VC++ runtime dynamically. The Excelsior JET Runtime contains our proprietary code and Sun code licensed under SCSL Commercial Use, which is not GPL-compatible.
  2. Question about academic license

    First of all, the Excelsior JET Runtime license is not GPL-compatible. LGPL, BSD, CPL, and many other open-source licenses are all fine, but not GPL. If you own the copyright, you may dual-license your project or change the license. The free non-commercial license would be more appropriate. Yes, absolutely. No. Yes, it has all features of the Professional Edition, only the license is different. If you break all links with the academic environment, the executables will remain legal, but you must stop using the Academic Edition. Thanks.
  3. Can you reduce the problem module to the smallest piece of code that still exhibits the error and post it here?
  4. How do I suppress the warnings?

    From our previous porting/migration efforts, I would suggest you to switch warnings off one by one, and only after reviewing the respective pieces of code. Warnings may indicate problems. Even if there is one real problem for 100 warnings, debugging it with warnings disabled is likely more expensive than reviewing all warnings.
  5. How do I suppress the warnings?

    If you are working on a commercial project, check out our Modula-2 source code migration and porting services.
  6. Excelsior JET 6.0 Maintenance Pack 1 (MP1) is available for download. It is a highly recommended update that fixes multiple customer issues. MP1 is available to Excelsior JET 6.0 customers at no cost. If you are a registered customer of Excelsior JET 6.0 Standard, Professional or Enterprise Edition, but have not received a user/password combination for MP1 download, request it from our Support Dept. Download Now
  7. RFP contact

    Sent you an email...
  8. This topic has been moved to Defect Reports. [iurl]http://www.excelsior-usa.com/forum/index.php?topic=1564.0[/iurl]
  9. Cannot attach files

    I have changed the permissions and extended the file types list. Please try again.
  10. Excelsior Installer helps you create installation packages for your Windows applications. It is freely available. Excelsior Delivery is a commercial product that has all features of Excelsior Installer plus some advanced features. Please feel free to use this board to report your Excelsior Installer / Excelsior Delivery usage experience, ask for help and suggest improvements.
  11. We have released Excelsior JET 6.0, featuring the long-awaited support for Java SE 6. Other news are: - support for Windows Vista and RHEL 5, - support for version information and post-install actions, added due to popular demand, - Difference Tracker in JetPackII to help you create updates, and, as usual, - application performance improvements. Full information on new features and improvements Download Excelsior JET 6.0 Evaluation Package
  12. Usage in Open Source

    No, it is not. The evaluation license does not allow redistribution. And in any case, the evaluation package produces executables that time out on a fixed date. We do grant free licenses to authors of non-commercial Java apps (not necessarily open source) in return for some promotion for our product. However, the Excelsior JET runtime license is not GPL-compatible. You would have to change the license for the natively compiled version, which is only possible if you own the copyright for all GPLed pieces code in your app. LGPL is ok, as well as many other open source licenses. Please feel free to email our Sales Dept. with more questions.
  13. Apple OS X Support?

    Dave, I regret we cannot promise the Mac OS X version to become available any time soon. I am sure however that your Windows users would appreciate that huge benefit you are mentioning. Dmitry
  14. New Maintenance Packs are available for all four Excelsior JET 4.x releases: Excelsior JET 4.0 Maintenance Pack 3 Excelsior JET 4.1 Maintenance Pack 2 Excelsior JET 4.5 Maintenance Pack 4 Excelsior JET 4.8 Maintenance Pack 3 Please refer to the Release Notes sections on the above linked pages for details.
  15. Given the broadness of your question, I could say that we are working on it right now. However, that is going to be a custom Modula-2 compiler targeting a CPU architecture other than x64, and an operating system other than Windows or Linux... Then, the core components of Excelsior JET, namely the AOT compiler and the JVM (except the fast JIT compiler), are written in Oberon-2 and Modula-2 respectively. So if we ever decide to do a 64-bit version of Excelsior JET, we would have to either convert the runtime to C++ or retarget XDS Modula-2 to x64. In that sense, there is a chance that there will be Native XDS-x64. However, the compiler we are using for Excelsior JET development is again a Native XDS-x86 branch customized for our specific needs, so I do not think we'll ever release it to the public. In short, we are not going to finance a complete port of XDS to x64 or, for that matter, any other platform, ourselves.
  16. Excelsior JET 5.0 Released

    Excelsior JET 5.0 introduces Java Runtime Slim-Down, a new deployment model that may help you significantly reduce the download size of Java SE applications. With it, you may exclude certain components of the Java SE platform from the installation package, namely AWT/Java2D, CORBA, JDBC, JNDI, JSound, Management, RMI, Swing, and XML, provided they are not used by your Java application. This release also delivers a major performance increase over the previous versions. As measured with two standard benchmark suites (SciMark2 and SPEC JVM98), the composite scores have improved by a factor of 1.7 compared to Excelsior JET 4.x. Full information on new features and improvements Download the fully functional Excelsior JET 5.0 Evaluation Package Vote for Excelsior JET now! Voting for 2007 Java Developer's Journal Readers' Choice Awards ends on May 31st. Excelsior JET is nominated in the "Best Java Virtual Machine" category. This is your last chance to support our nomination. Please vote for us today!
  17. Please make JET compatible with upx

    Maybe this can be worked-arround some time in future, as it effectivly destroys the ability to decompress in-location. I guess this is also the reson why aspack works (but needs exectly the size of the compressed executable more RAM). Is it possible to instruct UPX or any other packer to compress executable sections selectively?
  18. Please make JET compatible with upx

    . . . By the way the "Global optimizer" has the same disadvantage. If applications would be linked only dynamically all jet-dlls could be shared every time an jet-compiled application is launched. However you also give the developer the choice here to reduce download size and enhance performance. This is not quite the same disadvantage. You can optimize several Java apps sharing most of their classpaths together into one EXE, adding a main() method that would dispatch control to one of those apps' main() methods accoring to the command-line arguments. Well personally I would like to be able to compress jet-executable because of real use-cases: * Deploy jet compiled demo's on an USB stick which should be able to run right out of the box. Every MB is quite expensive if you deploy hundreds of sticks. This is a very good point. I have no idea why USB sticks and flash memory cards escaped my attention when I was writing my previous post... OK, yet another point taken. Have you used the Executable Image Optimizer? It may substantially reduce the startup time, especially combined with the Global Optimizer. The disk footprint of the complete Sun JRE 5.0 is 70MB and you cannot remove much from it without violating the Sun license. We have no idea what all those packers expect to find inside the executable, and have no resources to investigate. Most likely, this segfault is not the only problem and finding all of them will likely take much more than 10-15 minutes. What we could possibly do and what I think would actually work much better than reverse engineering all those packers on our side is us providing packer authors with a document describing the parts of a JET-compiled executable that must not be compressed, under a non-disclosure agreement. But again, this will take much more than 10-15 minutes and we have other commitments right now. After we figure this one out, there will likely be more "interesting things to find out". We have gone through this more than once, with our own products and with third-party software. I have not heard back at all from authors of quite a few Java tools and applications whom I contacted in the hope that they might be interested in what we are doing here at Excelsior. You have to ask the packer authors whether they would be willing to help; without that, your statement is worth nothing. Sure. However, there are just a few users asking for this feature (maybe one user less, as LinuxHippy and JavaJulia post from the same IP address ). In particular, we have many paying customers asking for Java 6 support, that's a #1 request. I do not think we'll be able to work on anything else except Java 6 plus some features that we did not finish in time for Excelsior JET 5.0 release, schedule for next week.
  19. Please make JET compatible with upx

    Compressing an executable file has a big disadvantage: it will not be mapped to memory by the operating system and therefore your application will need more RAM. Moreover, if you run two copies of the application, or two applications that use the same DLLs, memory pages will not be shared among processes, thus increasing RAM usage further. Then, Excelsior Installer already supports LZMA compression, so there won't be any significant download size reduction if you compress the executables before packaging. Finally, with all the optimization and compression methods ever invented you won't bring the size of "Hello, World" written in Java even close to the size of "Hello, world" written in C. The Java runtime overhead would remain very big for a small utility. That said, I really don't understand why do you care so much about disk footprint. A typical desktop computer has 100 times more hard disk space than RAM. I still have gigabytes of free disk space on my workstation, but regular slowdowns due to Firefox eating half of its 512 MB of RAM drive me crazy. It is memory usage and in some cases download size that you have to care about, not disk footprint. Embedded systems are a totally different story of course.
  20. Please make JET compatible with upx

    Excelsior JET generates executables that are perfectly valid from the operating system standpoint, otherwise they would not load. So it is the executable packers that have to be fixed. There is a chance that we'll implement our own packer, but I cannot commit to any particular availability date.
  21. Licensing question

    Hello, 1. If you have a license for Excelsior JET, you can distribute your compiled application royalty-free, in any number of copies, provided your end-users will run it on general purpose desktop computers and/or servers. Only applications deployed to embedded systems are subject to royalties. Third-party plug-ins would be handled by the JIT compiler. 2. We do not plan any special offers on new license purchases in the near future. But we can negotiate a special price on special conditions. For instance, we have provided free licenses to a few non-commercial Java projects in exchange for some free marketing for Excelsior JET. See e.g. the JAlbum download page. If you are interested, email our Sales Dept.
  22. reverse engineering

    We have certain internal tools to aid field engineering, and of course our engineers know the product inside out, so they have an advantage over the rest of the world. But without debug information the tools are of not much help, and optimized x86 code is much harder to comprehend than a decompiled class file, for everyone. lg Clemens: Some of the high-level information has to be preserved, e.g. for the reflection to work. So it may be a good idea to do name obfuscation and string encryption before native compilation. See Knowledge Base Article 000023, "HOWTO: Maximize protection of your application against reverse engineering" for more information.
  23. Just use "x<>y" or "x#y" instead of "NOT (x=y)".
×