Jump to content
Excelsior Forums

kornelio

Members
  • Content count

    0
  • Joined

  • Last visited

    Never

Posts posted by kornelio


  1. zztop,

    I'll send the prj file ASAP.

    More information:

    The error seems to happen during link phase. This is the message I get:

    files: 61831  errors: 0  warnings: 0  notices: 0

    61 methods were compiled with a lower optimization level

    due to their very large sizes. These methods' names are logged in kdm-workbench-

    native.vaz

    with the "LONGLONGTIME:" prefix.

    Your project has been successfully compiled.

    Note however that 833 methods were compiled with a lower optimization level,

    most probably due to obfuscated bytecode.

    We would appreciate if you could e-mail the file kdm-workbench-native.vaz

    and the .class files listed in it to us at java@excelsior-usa.com. By doing so,

    you would help us improve the quality of our product. Thank you!

    For more details, see JET User's Guide (Chapter "Application considerations",

    Section "Baseline compilation").

    XDS Link Version 2.11.19 Copyright © Excelsior 1995-2008.

    Fatal error (3): Insufficient memory

    external command fault 255:

    xlink @"kdm-workbench-native_jetpdb/kdm-workbench-native.rsp"

    Link time 5:00.49

    Total compilation time 715278:28.14


  2. Hi,

    for some extrange reason, I have successfully compiled our Eclipse RCP with Excelsior 6.5 beta, 2 times at least, and now I can't get to do it :( If I recall correctly, I used all default options, and changed some minor things.

    Anyway, all compilations of my RCP end up in this message:

    Fatal Error (3): Insuficient Memory

    This happens at the very end of the compilation process. After everything is compiled, a message is shown indicating that everything went fine (in fact, no compilation errors), but the build script takes some time before ending (the last copyright message is shown), probably writting the output compiled executable file. It's then when the error comes up. Unfortunately, this happens before the log is written, too...

    Our compilation is taking more than 10 hours, and compiling quite a lot of classes (can't recall the number now, sorry, the windows batch file windows closes inmediately after finishing, I'll try executing it from prompt to avoid it being closed)

    I have 2Gb memory. Should I get more? Before finishing, the jet.exe process was taking more than 1Gb of RAM.

    Any thoughts on this?


  3. Nevertheless they should not contain original classes and jar files but only resources. To pack them as a whole, just choose "original jar/zip" item of "Pack into exe" combobox in the Classpath Grid of Classpath Page of the JET Control Panel (you see, texts are in beta stage now :) ). However be very careful with this! If you have native code libraries that accesses non-jar resources directly the resulting application may not work because non-java native code has no knowledge where the packed resources are. That's why default mode for directory plugins does not pack them into exe as a whole.  The typical misbehavior you may see -- if you have directory plugin that contains welcome screen resources,  then after packing the resources into exe, the welcome screen will not appear correctly, because Eclipse shows welcome screen via MS Internet Explorer that will not find the resources in the executable. On the contrary, if you make such plugin as a jar, everything will work after packing because Eclipse Runtime retrieves required resources  into "configuration" directory for IE before showing in this case and since Eclipse Runtime is Java code we know how to feed it packed-into-exe resources.

    I see. What you describe sounds reasonable. I think we should pack things in .jar files whenever possible :)

    We are planning to release JET 6.5 in the middle of March 2009.  Regarding the license for the beta, I do not think so, but you'd better to contact our Support or Sales department with this at "java at excelsior-usa.com" and "sales at excelsior-usa.com" respectively.

    Good! Looking forward to the official release :D We are quite happy with the results, I belive excelsior new version will attract many eclipsers :P I'll try to contact sales and support department.

    Thanks for your support, Kit! Really appreciated :)

    Cheers.


  4. Hi kit,

    Thanks for your support. The xpack hint did the trick :P

    I've tried the resulting product and works great!

    I've noticed that non-jar plugins are not included in the .exe file. Is it possible to include them?

    Regarding "Encrypt strings and resources", I just saw it, that's perfect for us, thanks!

    Finally, when are you planning to release 6.5? We are releasing our product soon, so we really need it as soon as possible :P Will it have the same costs as 6.4 (just to have an estimation for our budget). Do you think it is possible to reach an agreement to pay for a license for the beta version, and we take the risk :P?

    Kind Regards.


  5. Hi guys,

    we are interested in protecting our Eclipse-based RCP using Excelsior technology, which certainly fits our needs (only with 6.5 RCP support). Our product is of medium size, let's say around 350 bundles. Some of these bundle contain critical data in the form of XML files. We are targeting Windows XP platform.

    So our objective is to get all critical bundles compiled and encrypted into the main .exe. However, and using the provided GUI for latest beta 3, I've found some limitations.

    First, I tried default compilation options (using "typical" compilation preset). My first problem was that lots of consistency warnings/errors came up from the consistency check. I decided to ignore them, It would be great if you guys could provide some guidelines on how to fix these consistency problems.

    After leaving my computer compiling the whole night, I saw the result the next morning: a 359MB native executable. It did actually work! But I didn't achieve what I wanted: most of my critical propietary bundles weren't compiled inside the main .exe, they were just left as-is. Fair enough for a "typical" preset.

    So my next step was to customize the compilation options. Please take into account that I'm making many assumptions, so please correct me when needed.

    I realized the compilation options were quite constrained.

    The "Pack into exe" Option: there are 3 possible values: auto-detect, original jar/zip and none. The thing is that if you set original jar/zip, the GUI warns you that you won't be able to protect your code (:huh:). Then, if want to protect my code, I would need to leave it as .jar files (and the point of excelsior was making java code native!). Furthermore, the bundles didn't look like protected after the compilation (not even .class obfuscation).

    So in the end, the result of the compilation process was:

    - Unprotected compiled code in a main exe

    and

    - (unprotected) .jar bundles

    Whereas my objective was to get

    - Compiled and protected code

    Do I miss something? What am I missinterpretting from the results of the compilation process?

    How can I tweak compilation options to obtain:

    - a single all-in .exe file

    - all code should be natively compiled and protected (and desirable, optimized)

    - non-java artifacts (lets say, XML files) should be, at least, encrypted and packed in the .exe as well.

    Thanks in advance!

×