mavr

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.

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

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.

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

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.

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

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.

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.

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

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

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.

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.

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.

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

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

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);

Also, maybe this Knowledge base article would help.

Please contact our Support Dept. through the form at http://www.excelsior-usa.com/jetsupportform1.html.

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.

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.

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 ...

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.

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?

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 ...

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.