Jump to content
Excelsior Forums


Excelsior Staff
  • Content count

  • Joined

  • Last visited

Everything posted by kit

  1. Yes, you may use xpack utility now to make such "removing" automatically: xpack -source AppDir -target TargetDir then TargetDir will not contain your jars and moreover it could be copied to another PC and work there. To improve protection of .xml files that are packed into exe you may enable "Encrypt strings and resources" setting on the Page Target of JET Control Panel. After that you should not see any readable strings that are critical for you to hide in the executable
  2. kit

    Console output

    Use Linux -- it has exactly this behavior . On Windows, it is an executable property to have or not to have a console, that is not sensitive to the calling context. As workaround, I can only suggest to have two executables: one with console and another without, like "java" and "javaw". It may be fake executables that call main executable after making "gui -" or "gui +" on it.
  3. kit

    Two usability issues with Jet Pack II

    1. To remove After-install runnable, click on the appropriate textfield and press "DEL" key. It is not obvious behavior indeed and there is a RFE for this in our issue tracker. 2. Yes, it is quite strange behavior of the installer. I have created an issue for this. Since it is not fatal misbehavior, the fix is likely to appear in the next JET version only. PS. NullPointerException you reported earlier has been fixed for two days. However, you have not contacted us since then.
  4. kit

    Digital Cert being stripped on install

    You are right. You may sign <JET_INSTALL_DIR>/bin/xuninst.exe directly for this purpose. Please let us know if it works
  5. I have reproduced the problem and now we are preparing the hotfix. Please contact our Support Department (java at excelsior-usa.com) to get the fix.
  6. kit

    Digital Cert being stripped on install

    In your case, you need to change the sequence of actions you perform as following: 1. build an executable (say "a.exe") 2. Call xpack a.jpn -make-image for_sign_a_dir 3. Sign a.exe in "for_sign_a_dir" directory (you may also sign uninstall.exe here) 4. Create the installer with this command: xpack a.jpn -from-image for_sign_a_dir For more information, please read JET User's Guide, Chapter "Deployment automation", Section "Installations protected by license managers" Please let us know what else we can do to help.
  7. This topic has been moved to How Do I?. [iurl]http://www.excelsior-usa.com/forum/index.php?topic=1564.0[/iurl]
  8. Perhaps, it will be fixed in the next JET version, but it is scheduled as optional task only. We may also implement this on a consultency basis. Please contact our support ( java at excelsior-usa.com ) if you are interested.
  9. kit

    Jet 6.4 beta, zip exception

    I have just compiled your application with the JET 6.4 beta 1, however it works flawlessly. Can you provide us the run scenario that reveals the problem?
  10. DestroyJavaVM is not implemented yet in Excelsior JET. So you may not switch the jet-compiled DLLs from one to another currently. We will address this issue in a future version of Excelsior JET. Why is it important for you to reinit JET runtime? Why the jars cannot live in one JVM?
  11. I would like to clarify the feature request. Note, that common installation is not available for users without administrator rights. So actually we can implement the feature in two ways: 1. If the user has no administrator rights, the program is always installed for himself (personal installation) and the Installation type panel is not shown. 2. If the user has no administrator rights, the installation will not be done and an appropriate message will be shown. For both ways, the installation is done for all users, if the user has administrator rights. What way do you prefer?
  12. There is no way to do this currently. I will add this feature request to our issue tracker.
  13. kit

    JET 6.0 Invocation/cMain sample error

    Hello, I have just compiled the cMain sample on Vista with JET 6.0 eval and it works fine. Do not you modify the sample before compiling? Can the problem be reproduced on another PC?
  14. kit

    highlight status in console log

    Honestly speaking, I do not understand why current output is not enough for your needs. Moreover these lines occur in the log at the very begining and do not take much of the compilation process.
  15. kit

    Hardlock Protection with Aladdin HASP

    Hi, I do not know how Aladdins HASP SRM works and why it cannot work properly with Excelsior JET. Have you tried to ask this question to Aladdins technical support?
  16. kit

    Recovery excel file was clean by Excelsior JET!

    Excelsior JET never asks to clean Drive, the most probably Windows OS asked it after the disk space was over during Excelsior JET using. Note, that the same might occur, if you would perform another disk space consuming task (download video, for instance). So the problem does not relate to Excelsior JET.
  17. Hi, There is no way to pack the jar into executable using JetPackII. Please contact our Support Dept. as zztop suggested to get an alternative solution.
  18. There is no such switch. Explicitly set properties can be viewed by means of System.getProperty(prop) call. We use standard forum engine, and honestly speaking I do not know, if it is configurable in this way. Now, we consider an issue to be solved, if there is no additional questions asked by initial poster.
  19. Explicitly added means: 1. !classpathentry, if either -protect or -optimize equations set to "all" for it 2. !module YourJar.jar, except both -protect and -optimize equations are not set to "all" globally . 3. !module YourClass.class 4. !batch *.class YourPackage 5. -main=YourClass Yes. Note however, that once you add a class to the compilation set, all its import is also automatically added. So in general, you add an import closure of the class with it. To get a complete freedom with defining of the compilation set, use -superimportonly+ secret option. With this option, the compiler will automatically add only superclasses and superinterfaces of explicitly added class.
  20. Usage (.usg) files are mainly intended to be used with Global Optimizer: they contain classes and members that were used during Trial Run with a special information on their usage and the later is used only by Global Optimizer. Without Global Optimizer enabled, only information about referenced classes are used from .usg files. So .usg files mainly complete your project in this mode, if not all classes from the classpath was explicitly added to the project (so .usg inclusion has impact on compilation in such case). However there should be at least one class that is explicitly added to the compilation set to let .usg files to take any effect. If you compile EXE, the main class is always such explicitly added class. For DLL, if you set -optimize=autodetect and -protect=nomatter, then the compiler does not know from which class it should start optimizing and hence issues "no classes to compile" error. You may explicitly add a class to the compilation set in such case using the !module YourClass.class directive.
  21. kit

    Using the SmartCard IO API

    We have fixed the problem. Anybody, who would like to receive the hotfix, may email to Support: java at excelsior-usa.com
  22. 128m No. Some of them listed at JET User's Guide, Chapter "Application Considirations", Section "Java system properties / JET runtime properties", however there are many secret properties and there is no way to see them. No, it is not expected. Note, however, that the process' memory usage is a sum of the heap, loaded code and data of imported DLLs, its own code and data, JITed code, JIT, JIT heap, etc. So it might happen, that even if the application itself uses not so much dynamic memory, the process may use much memory. We have seen such cases. And it might happen that there is no memory for JIT to load, since it requires quite a large amount of continuous address space available at the point. Due to address space fragmentation, the OS may fail to provide it even if there are relatively much memory available at this time. So, to understand if it is your case, please look at Task Manager to see how much memory your application uses just before crash with the error. If it's far from 4 GB and there is no other processes that use much memory then probably it is a flaw in our engine. In this case, I would prefer to continue this thread via support email: java at excelsior-usa.com However there is a (secret) workaround for the above problem. You need to enable -Djet.jit.do.not.unload.compiler to force JIT to stay in the memory once it is loaded. However it causes permanent memory overhead . It depends on your meaning of "minimum set". A reasonable trade-off is to compile all classes that are always loaded by your application at any run, plus those classes that are often loaded, plus those that you wish to protect and keep the rest in the bytecode form expecting JIT compiler to cope with them. With this flag, there is only theoretical possibility for the compiler to lack of the memory. A typical JIT session with this flag is 1-2 classes, and there should be a very big class to make JIT failing. So you may have the certainty with the flag enabled. Note also that a plugin by users may occupy so much heap memory itself that it cannot be handled by any other JVM. Thus, in general, you have not 100% certainty with the subject at all. Yes, it is. And the most probably will stay. AOT is the main feature that differentiates us from other JVM implementations. Yes, you can expect that. We are interested to improve and evolve any piece of our software including JIT and we have this task on our "todo" list. The ideal JVM for us is a real mix of AOT and JIT approaches: the application's core and platform classes should be compiled ahead-of-time, but the rest classes should be handled dynamically without significant performance penalty. I believe that both traditional JVMs such as Sun JVM and our JVM will meet at this point.
  23. kit

    Using the SmartCard IO API

    I have just found the following note at Sun site http://java.sun.com/javase/6/docs/technotes/guides/security/enhancements.html: "Sun's Java SE 6 implementation bundles the Smart Card I/O API defined by JSR 268 as well as a provider called SunPCSC which uses the platform's native PC/SC Smart Card stack, if available. Note that neither the API nor the SunPCSC provider are part of the Java SE 6 platform specification and may not be present on other compliant Java SE implementations. " However, as I said, we are working to support it.
  24. Our JIT compiler is scaled down version of the main AOT compiler and its memory usage and the speed is the subject to improve for almost every JET release. So now, it is strongly recommended to compile as many classes as possible ahead-of-time to avoid this JIT overhead. On the other hand, you certainly cannot avoid it for plugins.