Mumble wants to alter my Embroidery Machine Communications

[unokitsune]

http://img.photobucket.com/albums/v43/unokitsune/Mumble%20Communication.jpg Picture proof.

My Embroidery Machine Communcations refers to my $800 5D Embroidery Extra for Husqvarna Viking Embroidery Machines, mine is a Topaz 30. Dongle is required to use the program. I also have Floriani Embroidery Suite and I do not wan't Mumble to alter my Embroidery Machine files in anyway shape form or coding which includes files. Between the two programs they cost $1,800.

All I wanted to do was to go to talk with Pathfinder University on golarion.mumble.com but I can't even install the program for fear that it will alter my machine in some form and the problem is I don't know where my physical disks are to reinstall the Embroidery Machine Programs which are my source of work. I have already been to Pysical Court over my Embroidery and Sewing Machines and I don't want a program to mess with them in any way. Mumble is the only one that wants to mess with them.

How do I install the client without having my programs be messed with in any way shape or form?

[Lindee]

It *shouldn't* be touching the embroidery stuff at all. All it's looking to do is update a file that the embroidery suite is using. Which is probably just a standard operating system support file.

[unokitsune]

I decided for safety sake to not finish the installation. I don't want my embroidery machine programs messed with. They are expensive and have to be purchased separately from the machine and I can't risk them being altered.

[ngollan]

This is benign and you can ignore it. The Mumble overlay gets injected into pretty much any application that uses a 3D accelerated surface, and the installer indicates that. The installation will not "alter" any other applications.

[mkrautz]

TL;DR: We have added a fix for this issue to Mumble 1.2.x, a fix will be included in 1.2.9.

There are two possible problems with this.

As ngollan said, the Windows Installer will prompt you to close down programs that use the Mumble overlay.

This is because you cannot delete files that are in use by other programs on Windows.

Unfortauntely, what you saw with your embroidery machine software was NOT that issue.

I investigated this yesterday, and I found out why this was happening.

I actually thought I had fixed this in the newer 1.2.x releases of Mumble -- but it turns out I had made a typo.

What went wrong here is that Mumble includes the Microsoft Visual-C Runtime DLLs.

When you include these DLLs, you can do so in two ways.

Either you just stick the DLLs in the Program's folder in Program Files. This way, the files are local to the program, in this case, Mumble.

Or you use what's called a merge module, to splice Microsoft's Visual-C Runtime DLL installer component into your own programs installer.

Some time ago, we had switched to bundling the DLLs *without* making use of merge modules -- or at least, I thought so. This was specifically to work around this issue, because I had a hunch that it was the CRT DLLs that were causing some of these issues for people.

When I implemented the bundling of the DLLs, I had made a typo. The result was that for some of the more recent installers in the 1.2.x series, we were using BOTH methods. So, we included the merged CRT DLL installer in our package, AND we bundled the DLLs themselves.

Here's the relevant change to our build script, which fixes the typo:

https://github.com/mumble-voip/mumble-releng/commit/34b9e04bf546bcd2c1704acfa6ddbbfbe64fd7cd

So, the issue where a clean installation of Mumble will complain about files in use should now be gone. It has been gone for a good while in the 1.3.x series of Mumble -- so that's at least something.

I'd also like to touch on the issue that ngollan brought up, which is the problem that Mumble's overlay DLLs often cause the same "files in use" dialog, which is a major pain-point when updating Mumble snapshots -- at least for some people. It can be very scary, as you've also seen with the other, related, issue.

The direction we're going in for the overlay DLLs is to have a version-specific directory in the Mumble Program Files directory.

So, consider an installation of Mumble 1.3.0. An installation that only includes the client will in the future look something like this:

 

   C:\Program Files (x86)\Mumble\mumble.exe
  C:\Program Files (x86)\Mumble\msvcr120.dll
  C:\Program Files (x86)\Mumble\msvcp120.dll
  C:\Program Files (x86)\Mumble\d3dcompiler_43.dll
  C:\Program Files (x86)\Mumble\d3dcompiler_47.dll
  C:\Program Files (x86)\Mumble\Versions\1.3.0\mumble_app.dll
  C:\Program Files (x86)\Mumble\Versions\1.3.0\mumble_ol.dll
  C:\Program Files (x86)\Mumble\Versions\1.3.0\mumble_ol_x64.dll
  C:\Program Files (x86)\Mumble\Versions\1.3.0\mumble_ol_helper.exe
  C:\Program Files (x86)\Mumble\Versions\1.3.0\mumble_ol_x64_helper.exe
  C:\Program Files (x86)\Mumble\Versions\1.3.0\mumble-g15-helper.exe
  C:\Program Files (x86)\Mumble\Versions\1.3.0\speex.dll
  C:\Program Files (x86)\Mumble\Versions\1.3.0\celt0.0.7.0.dll
  C:\Program Files (x86)\Mumble\Versions\1.3.0\celt0.0.11.0.dll
  C:\Program Files (x86)\Mumble\Versions\1.3.0\opus.dll

This should avoid the problem of deleting the files because they're in use. With this system in place, Windows can instead schedule to remove the files on reboot -- because it will not need to overwrite the files when updating to a new version of Mumble.

Snapshots will, in the scheme above, use their full version strings. For example, "1.3.0~628~gfcb908b~snapshot" instead of just "1.3.0."

I am not yet sure of the locations of the runtime DLLs in this scheme, but we will see.