Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited


Everything posted by mavr

  1. 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. Swing support

    No, due to the Sun licensing policy, you have to use the entire JRE bundle.
  3. 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. JDK 1.4.2_04

    Maintenance pack 3 with the support of 1.4.2_04 is expected at the beginning of April.
  5. 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. support for jdk1.5?

    Probably, some support may be expected by the start of this summer's JavaOne.
  7. 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. 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. DLL Breaks Upon Deployment

    It sounds like you have skipped trial run in JetPackII. Please perform it and re-create the installer.
  11. 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. 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. Stack Overflow Frustration

    Do you use JetPerfect? If yes, does this problem appear in the default build mode without enabling JetPerfect?
  15. 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. 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. 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. 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. 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. 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. 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. 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. 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.