Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited


Everything posted by mavr

  1. mavr

    Windows shutdown

    JET-compiled programs are pure Java programs, with no semantic extensions. So, if something is impossible in Java, then it is also impossible under JET. However, I have a feeling that catching such events is possible in Java by using native methods. So, you have to write handlers in C/C++ and use them via JNI.
  2. mavr

    Swing support

    No, due to the Sun licensing policy, you have to use the entire JRE bundle.
  3. mavr

    Swing support

    For this case, JRE is indeed required, but only AWT/Swing natives (awt.dll) are used from it. All JRE classes, as well as classes of your application are compiled to native x86 code, giving you all common benefits of native compilation: performance increase, resistance to reverse engineering, etc (see Common benefits for details). But, in case of using Swing, JET cannot help you to reduce installation package size.
  4. mavr

    JDK 1.4.2_04

    Maintenance pack 3 with the support of 1.4.2_04 is expected at the beginning of April.
  5. mavr

    Mixed Compilation Model in linux ?

    There should be a project file for jEdit3.0 in the samples, maybe it would help. Regarding the segmentation fault, please contact our Support Dept. through the form at http://www.excelsior-usa.com/jetsupportform1.html.
  6. mavr

    support for jdk1.5?

    Probably, some support may be expected by the start of this summer's JavaOne.
  7. mavr

    DLL Breaks Upon Deployment

    Once the trial run was successful, please try to exclude extra files (i.e. 3rd-party app) from the package files, create the package and test it on another PC. If won't help, please contact our Support Dept. The slow-down may be caused by JIT: on a developer machine dynamically loaded classes are likely to be already compiled (and stored in JIT cache), while on the target 'clean' PC emulated in trial run they are to be compiled again. This may be avoided by deploying JIT cache, please refer to documentation for details.
  8. mavr

    DLL Breaks Upon Deployment

    You may try to include the whole JET RT into the package. If it would help, DLLs may be excluded one by one with the proper testing. Another variant is to temporarily include the 3rd-party app into the package, and perform the trial run of it to determine, which RT DLLs are required for your DLL to work.
  9. No maintenance packs are included into the trial version. MPs are recommended to download if you need the support of latest JDK versions not supported in the original 3.5, or if you have found a bug in JET that may be fixed with MPs. It is our customers who judge
  10. mavr

    DLL Breaks Upon Deployment

    It sounds like you have skipped trial run in JetPackII. Please perform it and re-create the installer.
  11. mavr

    reference to unknown Struct

    No manipulating is needed. Have you provide the buffer of enough size? Try to increase it, for example, to 10000 bytes. If it won't help, pelase send your program and dll to our Support Dept.
  12. Hi, If the problem persist, please contact our Support Dept. through the form at http://www.excelsior-usa.com/jetsupportform1.html. I have never met such problem before, probably its cause is some non-standard hardware or software, so please be sure to include the detailed description of your computer.
  13. mavr

    reference to unknown Struct

    As far as I can understand, what you need is not a structure, but just a buffer that is big enough to store the unknown structure instance. If you know that the structure size is SIZE (or, at least, that the size of the structure is no more than SIZE), you could create the handle as, for example, Argument pGeoEngHandle = new Argument("", Argument.CSTRING, SIZE); Of course, "newStruc*" should be replaced with the "CSTRING" in function signatures.
  14. mavr

    Stack Overflow Frustration

    Do you use JetPerfect? If yes, does this problem appear in the default build mode without enabling JetPerfect?
  15. mavr

    Inefficiency of Pointer.CreateArray

    xFunction uses the ordering of the underlying OS, so, as far as I can remember, for x86 Win32 it is little-endian.
  16. mavr

    Inefficiency of Pointer.CreateArray

    Hi, Actually, xFunction is designed not for efficience, but for ease-of-use and reliability. Particularly, while sending a data, initial Java array is copied into the internal buffer, in order to avoid concurrent modification and GC issues. In your case, I would recommend to use 'clean' JNI. However, there are some 'tricks' those potentially may increase the performance of your code. First of all, use 'int' array instead of 'char', because of the Java 'int' type has full correspondance with C 'long' type, so no conversion is needed. Surely, the buffer size should be aligned to 4 bytes, and divided by 4. You can also try to use Java 'long' type, that corresponds to C's '__int64'. Then, if the buffer size is a constant, or is never exceeds some limit (as far as I can understand, 32Kb), you may use the single instance of Argument for sending and receiving data: Pointer srb_bufpointer = (Pointer)Argument.create("int*", buf); foo1.invoke(srb_bufpointer); //use for sending foo2.invoke(srb_bufpointer); //use for receiving int[] arr = (int[])srb_bufpointer.createArray(length);
  17. Also, maybe this Knowledge base article would help.
  18. Please contact our Support Dept. through the form at http://www.excelsior-usa.com/jetsupportform1.html.
  19. mavr

    Error: "Class <...> not found" at runtime

    Please contact our Support Dept. at support@excelsior-usa.com. Please make sure to include the example and description of the problem into the report.
  20. mavr

    Question on Excelsior 3.5

    If it works under Sun's JVM (HotSpot), it should also work under JET. Is not WFC only MS extension for Java? I have no experience with it. As for JDirect, it seems that there are several versions, one (JDirect 2) is Apple's extension, while JDirect 3 should be compatible with all other VMs. Again, if it is compatible with HotSpot, it should also be compatible with JET. By the way, our own library with the same functionality (xFunction), is tested with JET, and works with no problems.
  21. mavr

    Error: "Class <...> not found" at runtime

    Non-static internal classes can't be used as arguments, because of additional implicit argument (this of enclosing class) is passed into constructor. In your case, it is recommended to make securityAttributes and processInformation static, e.g. static class securityAttributes ...
  22. mavr

    How do I use unsigned char*

    The only reason why the 'byte' type was not implemented is trying to avoid confusion with 2 Java types (byte, char) corresponding to one C type. However, we will take into account your wishes and maybe will implement it in future.
  23. mavr

    Error: "Class <...> not found" at runtime

    The fully qualified name for class securityAttributes is "de.ikb.forms.execLoader_jpi$securityAttributes", but not "de.ikb.forms.execLoader_jpi.securityAttributes" BTW, have checked Where sample with 1.4.2_03, but found no problems. Maybe you had modified it somehow?
  24. mavr

    How do I use unsigned char*

    Suppose underlying dll fills buffer with bytes {0xAB, 0xCD, ...}. The code in xFunction may looks like xFunction f=new xFunction("s87d.dll", "int CreateSignature(char*, int, short*, int, int)"); Pointer arg1 = (Pointer) Argument.create("char*", new char[48000]); .... f.invoke(arg1, ...); char[] buff = (char[])arg1.createArray(48000); byte b1 = (byte)buff[0]; //=0xAB byte b2 = (byte)buff[1]; //=0xCD ...
  25. mavr

    How do I use unsigned char*

    From the point of view of underlying dll, there is no difference what type was used in xFunction's signature. The only matter is the binary layout of the arguments. So, specifying simple "char*" is correct.