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 .

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.

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 .

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 .

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.

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

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.

The driver works and it survives reboot.

Thanks Sergey! A job well done.

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

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

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

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

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

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.

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.

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

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)

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

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

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

Copy code to clipboard

1infinstall 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?

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:

1infinstall_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 !

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 😀