[3.1] How to package a self-contained game?

I want to deploy a self-contained game (with JRE bundled inside). On the master I see these two screens:

What is the difference between the two? Isn’t the first one redundant?

One controls including a JRE bundle… the other controls building the actual app bundle just like JME has always had.

What’s confusing?

Edit: I missed the checkbox at the bottom. I have no idea what the difference is.

This thread explains:

Probably the first one is from Netbeans, the second one is from @normen

Suggestion: I would change the

You can further configure the application launchers (icons etc.) by modifying the templates in the resources folder.


You can further configure the application launchers (icons etc.) by modifying the templates in the
< your project >/resources folder. Hint: google for ‘ReplaceVistaIcon.exe’

Yes the first is from NetBeans and only works for the platform you’re running on.

Tried but when trying to run the bundle got this error on non-development pc.

It says “MSVCP100.dll isn’t present on the computer. Please reinstall the program”

Yeah, thats an issue with Oracles binary stub though. The problem is what the message says.

1 Like

Try to install this on your Windows
https://www.microsoft.com/en-us/download/details.aspx?id=5555 (for 32-bit app)
Download Microsoft Visual C++ 2010 Redistributable Package (x64) from Official Microsoft Download Center (64)

1 Like

I appreciate the advices and I realize that 3.1 is unstable; however I guess that this means that I will be better off by NOT bundling a JRE and tell my users to download a JRE themselves… until Oracle fixes this.

Or you go ugly, just also add the dll to the executable folder XD

I guess most people actually have this dll when they have a few games installed but yeah, as you think.

I’ve just upgraded to 3.1, and I gave the Windows 64-bit distributable to someone else to play. They ran into this same MSVCP100.dll issue. We fixed it by me giving him the MSVCP100.dll and MSVCR100.dll files from my own System32 folder, and him placing those alongside the executable. So, it seems that including these DLLs in the distributable certainly does work.

So, what I’m wondering is:

  1. How ugly a solution is this? Should I seriously consider grabbing those DLLs from my Windows, and putting them into desktop-deployment, or is there a good reason why not? I don’t like bundling magic DLLs with my distribution, but if it means people can get going with the game without having to screw around with things first, then it might be worth it.
  2. How do other jMonkeyEngine games deal with this problem? Or don’t they?
  3. Does Steam have a solution for this?
  4. As kasha1232 suggests, installing Microsoft Visual C++ seems like it might also be a solution (and I’ve also seen that stated as a solution by Microsoft, here). I didn’t try that, but, is that a better solution? So, if any players run into this problem, should I instruct them to install Visual C++?
  5. Ideally, would you have a proper installer that checks whether Visual C++ is already installed, and if it isn’t, installs it (presumably causing those two DLLs to get put into the Windows folder), and then installs the game? Does anyone making jMonkeyEngine games do anything like that?


This is an old thread, I’m now using javafx-gradle-plugin that builds a self contained archive that actually works.

To clarify a few things:
These DLLs are part of the Microsoft Visual C(++) Runtime Redistributable.
As such they are to C/C++ what the Java Class Library is to Java. They provide the implementations of fopen/printf and many more. That means, that nearly every C/C++ program should already need them to work and as such it might be already available on your system.

  1. Better would be something like this https://support.microsoft.com/de-de/help/2977003/the-latest-supported-visual-c-downloads
    However I can already see that at least MSVCP100.dll (Which would be the C++ (VCR == C) 2010 runtime), isn’t supported by MS anymore, however a newer JRE might need a different version (considering it’s the JRE depending and not launch4j)
  2. Another Idea would be a simple batch file with a content like ../jre/java.exe -jar ../MyGame.jar optionally with a pause behind, so the window doesn’t insta-close
  3. Yes, each game you install will re-install the Redistributable. Pay Attention to a Games first launch, even if you know you already have it, they will reinstall it.
  4. See 1. However “Installing Visual C++” sounds like installing the Visual Studio and all, but it’s actually only those dll’s that contain implementations, much like all class files for java.*;
  5. Would be the cleanest solution, but it depends: When the installer notices that it’s already installed, it’s fine to leave that check away. Also: What happens if you supply “Version 10 Security Patch 1”, but you detect that the Version 10 without that patch is already installed? Would you be able to tell the difference and what to do? Especially: What if it’s the other way round? You detect SP1, but have bundled the old version, would you probably overwrite it?

Somebody simply needs to update the executable stubs in the SDK, its the same ones as the JavaFX packager creates.

So, @Darkchaos, in point 3, are you saying that Steam installs (and re-installs) the Microsoft Visual C++ Runtime Redistributable with each game that it installs? I see now that I have a multitude of Microsoft Visual C++ Redistributables installed on my PC, from versions 2005 to 2015, x86 and x64, and various different versions of each. Perhaps these were all installed by Steam over the years, when I’ve downloaded and upgraded various games from it?

So, seeing as 3.1 specifically requires the 2010 version of the Redistributable, will Steam know to install that one if it’s not already installed? I’d imagine you’d just specify something on Steam when you’re preparing your game for download?

If what I’ve said is correct, then for those of us planning on distributing our games via Steam, this DLL problem sounds like it’s not an issue. Is that right?

Regarding the batch file approach, that’s basically a way to avoid having an executable, thereby avoiding this whole issue. I see what you’re saying. I’ll bear it in mind as a plan B.

Regarding what you’re saying, @normen, how do the JavaFX packager’s stubs fix the problem? Do they not need Visual C++? Or do they use a later version of Visual C++, that’s more likely to be present?

To test what you’re saying, I created a JavaFX project, then I created an EXE from it (for which I needed to first install something called Inno Setup 5). Running the resulting EXE installed the JavaFX application on my PC. Then, in the folder it installed that to, I saw there was an EXE roughly the same size as the stub.exe files that 3.1 uses. Would these be the stubs you are talking about?

I did try copying the EXE, and running my game with it (both the 32 and the 64-bit versions), but it didn’t work. It just says “JavaFXApplication8.exe has stopped working.” Would you have expected that to work, or is what you’re saying slightly more (or less) complicated than that?

Basically something like that yeah.