Jump to content
Excelsior Forums

pdot

Members
  • Content count

    0
  • Joined

  • Last visited

    Never

Community Reputation

0 Neutral

About pdot

  • Rank
    Newbie
  • Birthday 01/01/01
  1. Fantastic feature, we've been using it in our local test environments to diagnose a weird issue with a third party library. Any information about when 6.5 might be released ? EDIT: Never mind found a reference in another thread, "We are planning to release JET 6.5 in the middle of March 2009".
  2. Runtime error #3 trap

    Hi I wonder if someone can provide me with a bit of information, I'm investigating the source of a 'Runtime error #3 trap' error appearing at various times in our application apparently (I say 'apparently' because I've never personally seen it and cannot duplicate the issue using the same scenario which caused it). I understand that it's generated when the jet runtime encounters an uncaught exception, can someone elaborate? I'm trying to exhaust all possibilities from our code before submitting a support inquiry, a bit of background info would make it a bit easier. We're using Jet version 5.0 and a 1.5.0_13 jvm profile, the application does use native libraries, namely the swt library, build 3346. The application class files are compiled using a 1.5.0_12 jvm version. Thanks
  3. Jet 5, integrity of rt.jar in xjre

    thanks for the reply, that's what I thought .. I just wasn't 100% certain exactly what was in the libs left in the xjre (I should have had a closer look at what was in the jar) ... so the global optimizer essentially does the same job that jet perfect used to do in 3.6 and 3.7 versions of jet ... then packaging includes the remainder of the jre that wasn't detected during runtime profiling and compiled into the native binary ?
  4. reverse engineering

    I've posted a question in another section but thought it might be relevant here as well http://www.excelsior-usa.com/forum/index.php?topic=1493.0 As mentioned previously your code is as hard to reverse engineer as C++ code but what about the classes shipped in the xjre ? If I was to modify the contents of rt.jar before the first execution of my application, do those changes get executed ? is there something which verifies the integrity of the libs in the xjre ? Do the libs in the rt directory get compiled and linked at runtime, ie does ClassLoader.class get compiled natively and executed ? Or does the bytecode from the jar's which were used to produce the native executable get passed to the classloader without compilation ?
  5. Hi I'm in the process of evaluating jet 5 (we currently use Jet 3.7 to compile our application into a Windows native executable). I'm trying out the high disk footprint reduction where the components not used by the application are stripped out and downloaded as required. The question I have is related to the contents of the rt directory which gets distributed with the product during an installation of a packaged product. Is there anything which ensures the integrity of libraries like the rt.jar in libs ? How are the contents of the rt used at runtime ? What's to stop someone altering, say the ClassLoader class from rt.jar and storing the bytes from the loaded classes to disk at runtime ? Any information would be greatly appreciated.
  6. If I have a jar file with ONLY resources (let's say they're images for argument sake), is there a way using jet to build a dll with this jar ... rather than getting a '#no class-files in the project' message. Before anyone says it, yes I know it doesn't really make sense to have a jar file with no classes, what I'm trying to achieve is to seperate the resources from the exe because the resources can change without the exe changing. Any help/advice would be greatly appreciated.
×