VOGONS


Munt issue with Windows 10

Topic actions

Reply 40 of 82, by darry

User metadata
Rank l33t++
Rank
l33t++
sergm wrote on 2020-06-03, 21:04:

Oh, of course the .INF file from the driver distro isn't meant to work, it is 32-bit only (since it's the platform when it "just works"). I'm hacking on a 64-bit version.

Thanks again .
Now I'm getting this error at the end of the wizard .

mt32_dev_err.png
Filename
mt32_dev_err.png
File size
81.9 KiB
Views
3773 views
File license
Public domain

Reply 41 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Oops, sorry. An intermediate version sneaked in... Also, it's currently installing just the driver for x64 platform, so not finished, but still this is the "correct way" that makes windows to be mt32emu-aware 😀

Attaching a package that I just tested and it's proven to work.

Attachments

Reply 42 of 82, by darry

User metadata
Rank l33t++
Rank
l33t++
sergm wrote on 2020-06-04, 01:21:

Oops, sorry. An intermediate version sneaked in... Also, it's currently installing just the driver for x64 platform, so not finished, but still this is the "correct way" that makes windows to be mt32emu-aware 😀

Attaching a package that I just tested and it's proven to work.

It works perfectly for me too and survives a reboot.

Thank you very much for your work .

Reply 43 of 82, by darry

User metadata
Rank l33t++
Rank
l33t++

On a related note, is there way to donate to the Munt project to possibly raise funds for eventually purchasing a signing certificate for the driver or for other needs ? I know I would want to participate in that and I am sure I am not the only one .

Reply 44 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
darry wrote on 2020-06-04, 01:49:

On a related note, is there way to donate to the Munt project to possibly raise funds for eventually purchasing a signing certificate for the driver or for other needs ? I know I would want to participate in that and I am sure I am not the only one .

Hmm, it could be that nothing is actually required to get the driver signed. As it is a user-mode driver, a non-Microsoft certificate could suffice, as WDK docs promise. We might check that with a free cert from one of those free certification centres. Anyway, it may well be not so costly as it seemed at a glance.

Reply 45 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

I hope I'm done with the .INF horror... Now it can be installed either on 32-bit (including XP) or on 64-bit. WIll see if the installation can be automated (and possibly the reboot-to-unsafe avoided).

Attachments

Reply 46 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

And it seems very possible to make the drvsetup work around all that stuff. As of commit f06219376, it can happily register the virtual synth device in the PnP manager, so the configuration now persists Windows restarts. There's a snapshot build available.

Well, I personally like this way more. The "official" way Microsoft intends to install non-PnP devices seems to me very annoying. All that wizards and masters add 0 convenience but frustration. They do a lot of work in several seconds with the end result very close to drvsetup's which does it's dirty job in a few millis 😀
Yet it doesn't bother the user with driver signing that is not required for user-mode drivers.

Though, the current implementation isn't 100% clean, and probably can't be, but I'll play a bit more with it.

Reply 48 of 82, by Dagar

User metadata
Rank Newbie
Rank
Newbie
sergm wrote on 2020-06-06, 03:55:
And it seems very possible to make the drvsetup work around all that stuff. As of commit f06219376, it can happily register the […]
Show full quote

And it seems very possible to make the drvsetup work around all that stuff. As of commit f06219376, it can happily register the virtual synth device in the PnP manager, so the configuration now persists Windows restarts. There's a snapshot build available.

Well, I personally like this way more. The "official" way Microsoft intends to install non-PnP devices seems to me very annoying. All that wizards and masters add 0 convenience but frustration. They do a lot of work in several seconds with the end result very close to drvsetup's which does it's dirty job in a few millis 😀
Yet it doesn't bother the user with driver signing that is not required for user-mode drivers.

Though, the current implementation isn't 100% clean, and probably can't be, but I'll play a bit more with it.

Working very well now - even after a reboot.

To test it out I first deleted the task I was using to re-enable Munt after rebooting.
Next, from your snapshot archive above I ran drvsetup install from the command line
Rebooted and it retained the registration. As a plus it's also now listed in Device Manager under ' Sound, video, and game controllers '.

Reply 49 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

As I've found, user-mode drivers really can be signed with virtually any certificate. I now have a test self-signed certificate deployed on a test machine and as soon as I have installed this cert to the system store "Third-party Root Certification Authorities" (i.e. on the Local Machine), the driver can be installed happily (and legally), the user just has to ack the installation.

Also, I've found a REALLY convenient tool devcon.exe in the WDK which turn the whole process in a snap, it's just a matter of running

devcon.exe install mt32emu.inf mt32emu

from the Administrator command line in the driver's directory. That's kinda a good news.

A bad news is that this tool is not redistributable 😀 But M$ publish some closer functioning sample code.

To conclude, it seems to be likely that we'll have a free cert to sign the driver package, yet make a convenient way to install it via a custom tool.

Edit: Forgot to mention, I don't need to reboot the test machine to install both the test cert and the driver.

Last edited by sergm on 2020-06-06, 15:26. Edited 1 time in total.

Reply 50 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
Dagar wrote on 2020-06-06, 15:17:

As a plus it's also now listed in Device Manager under ' Sound, video, and game controllers '.

The problem is in that the OS doesn't recognise the driver installation files, and as I fear, it may well get broken with another OS update (that is in 6-12 months). I only want to avoid the hassle M$ enforced... 😀

Reply 51 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
sergm wrote on 2020-06-06, 15:21:

To conclude, it seems to be likely that we'll have a free cert to sign the driver package, yet make a convenient way to install it via a custom tool.

Alas, there are no more free code-signing certificates, even for open-source software developers (but there were just a few years ago). Although, there are really cheap offers out there.

Or maybe we'll base off of https://www.codenotary.io or http://www.cacert.org, not sure yet...

Reply 52 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

After more thought, I now heavily doubt that purchasing a code-signing cert is worth it. It appears, Windows has no real protection from tampering by default, only a domain administrator may configure something. A brand new installation of e.g. Home edition allows any program to install a self-signed certificate into the system trust store without questions (for instance, using the built-in certutil.exe prog), so I don't really get what's the idea behind the restriction on signing driver packages...

Moreover, we could have a tool that does approximately (np, I can really write it if necessary, all just to save the user from a reboot): 😀

  1. creates a temporary self-signed certificate in volatile memory;
  2. signs the driver catalog file;
  3. installs the certificate to the system store (easily done, since the driver installer already implies administrator permissions);
  4. installs the driver (being in fact signed but untrusted) silently;
  5. remove the helper certificate from the store and happily finish.

So, I'd avoid throwing away a couple of hundred $ just to have an illusion of protection. Because I personally have nfi who are those people signing certificates at all; how could I trust them if they trust in $ only as it seems? Atm, I 100% agree with the point of Dennis Zimmer about the existing digital certification approaches, so if it comes to code security for the project (by popular demand), I see exactly CodeNotary as a clear winner.

But back to the matter at hand, I hope a chance will come and M$ will hear our demand to stop this hassle and offer a saner API for software synths, so a developer doesn't have to jump through the hoops to make his synth merely accessible to other applications.

P.S. Interesting to note, that the new tool infinstall I've recently added (in order to install the driver "properly", yeah) sometimes fails to register the legacy MIDI driver entry(!), meaning that drvsetup remains the most reliable and the least annoying way of installing the MIDI driver for the user.

Reply 53 of 82, by Dagar

User metadata
Rank Newbie
Rank
Newbie

It IS annoying. MS continues to break and change things with every major update to Windows 10. It gets tiring.
I appreciate that you were able to find a way for Munt to survive a shut down or reboot in the latest version of Windows 10 ( Version 2004).
I use Munt with more applications than DOSBox, which include PCem and various Japanese computer emulators.

Reply 54 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
sergm wrote on 2020-06-14, 11:24:
Moreover, we could have a tool that does approximately (np, I can really write it if necessary, all just to save the user from a […]
Show full quote

Moreover, we could have a tool that does approximately (np, I can really write it if necessary, all just to save the user from a reboot): 😀

  1. creates a temporary self-signed certificate in volatile memory;
  2. signs the driver catalog file;
  3. installs the certificate to the system store (easily done, since the driver installer already implies administrator permissions);
  4. installs the driver (being in fact signed but untrusted) silently;
  5. remove the helper certificate from the store and happily finish.

And in the meantime, a large portion of work in this direction has already been done libwdi: Library for automated Windows Driver Installation, I assume by people who were no less frustrated...

Reply 55 of 82, by ShirBlackspots

User metadata
Rank Newbie
Rank
Newbie

Well, now... I updated to Windows 10 2004, had to reinstall Munt and Virtual Midi Synth. Even after this, Windows Media Player AND Media Player Classic won't play midi files, but Munt will play them and after editing the DOSBox config files, DOSBox will use Munt (if its running). Also, I can't figure out how to install the above download, right clicking and selecting install on the file will get "A problem was encountered while attempting to add the driver to the store".

Looks like it might be the end of days for MIDI on the Windows platform.

--EDIT--
I followed the prompt from drvsetup.exe to do 'drvsetup install' (through a command prompt window) and it installed the driver in the Device manager (Windows Media Player and MPC still won't play midis). I also like how I don't have to have the Munt GUI running when I'm playing a DOSBox game (like Wing Commander) for it to use the Munt MIDI driver.

--EDIT 2--
Using 64bit GraphStudioNext (from the K-Lite Codec Pack), I was able to change the midi renderer from default to the MT-32 emulator and Media Player Classic will play midis. (I can't get it to change merit in the filter list, though)

--EDIT 3--
Using 32bit GraphStudioNext, I did the same as above, and now Windows Media Player will play midis. (lets see if this will all survive a reboot)

Reply 56 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Uploaded the updated build of the MIDI driver that incorporates library 2.4.0 and improved installers at Source Forge. It doesn't yet contain full support for the new features of 2.4.0 hence an update to 2.3.0.

Now, with the help of PKI code from libwdi, we can smoothly install driver using .inf with just a single command

infinstall install -sign

so that Windows no longer shows stupid dialogs, yet no leftover stays in the system afterwards.

Apparently, signing fails to work on Windows XP, but who needs it on that system after all 😀

Please everyone see if it works as intended.

Reply 57 of 82, by citrixscu

User metadata
Rank Newbie
Rank
Newbie
sergm wrote on 2020-06-20, 13:13:
Uploaded the updated build of the MIDI driver that incorporates library 2.4.0 and improved installers at Source Forge. It doesn' […]
Show full quote

Uploaded the updated build of the MIDI driver that incorporates library 2.4.0 and improved installers at Source Forge. It doesn't yet contain full support for the new features of 2.4.0 hence an update to 2.3.0.

Now, with the help of PKI code from libwdi, we can smoothly install driver using .inf with just a single command

infinstall install -sign

so that Windows no longer shows stupid dialogs, yet no leftover stays in the system afterwards.

Apparently, signing fails to work on Windows XP, but who needs it on that system after all 😀

Please everyone see if it works as intended.

Not sure here, but it looks like infinstall_x64.exe may be installing the 32-bit driver to \Windows\System32 rather than the 64-bit one?

Reply 58 of 82, by Dagar

User metadata
Rank Newbie
Rank
Newbie

Extracted mt32emu_win32drv-1.5.1-win32-amd64.zip
from: https://sourceforge.net/projects/munt/files/m … /2.3.0-Updates/
to a temp directory and then ran the following from a command prompt where I extracted the archive:

infinstall_x64 install -sign

Drivers updated to ..
Driver Date: 6/20/2020
Driver Version: 1.5.1.0

Rebooted and tested and everything seems to be working fine !

Reply 59 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
citrixscu wrote on 2020-06-20, 19:51:

Not sure here, but it looks like infinstall_x64.exe may be installing the 32-bit driver to \Windows\System32 rather than the 64-bit one?

That'd be odd, but the installers (all sorts of them) do install a .dll in \Windows\System32. The thing is, the installer copies the 64-bit .dll in there, while the 32-bit .dll is copied to \Windows\SysWOW64. These two are easily distinguishable by size 😀