VOGONS


Munt issue with Windows 10

Topic actions

Reply 20 of 82, by Dagar

User metadata
Rank Newbie
Rank
Newbie
sergm wrote on 2020-05-29, 07:18:
Actually, there is a nice solution for it found quite some time ago by Tobias Erichsen. There is just one drawback with this app […]
Show full quote

Actually, there is a nice solution for it found quite some time ago by Tobias Erichsen.
There is just one drawback with this approach: "This software is NOT freeware or shareware. This software is copyrighted by Tobias Erichsen".

Although, using just his loopmidi driver for routing MIDI is way easier than that USB-MIDI+VM setup described 😜
and mt32emu-qt is already capable to communicate with other applications that way.

Thanks for the feedback and suggestion on loopmidi sergm.
http://www.tobias-erichsen.de/software/loopmidi.html

With this part however:

The ports created are unique for each user and only exist while the loopMIDI-application is running. So if you log-off, the created ports cease to exist.

The better option for me right now is just to run the Munt installer again for whenever I need it. Quick and painless.

Reply 21 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
Dagar wrote on 2020-05-29, 11:11:

The better option for me right now is just to run the Munt installer again for whenever I need it. Quick and painless.

Heh

Even faster to run

drvsetup.exe repair

as I mentioned above 😀
Though, it might be annoying to elevate and click OK each time, so could be improved. Say, have a scheduled task or a service running with relevant permissions.

Reply 23 of 82, by darry

User metadata
Rank l33t++
Rank
l33t++
sergm wrote on 2020-05-29, 12:03:

Actually, having a service to register the MIDI port on-demand could work. So far... Not sure if that survives the next windows version.

I will have to test it again to be 100% sure, but the driver seems to get unregistered by Windows after a certain, possibly variable, amount of time . If that is the case, it may well get unregistered during use .

Reply 25 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
darry wrote on 2020-05-29, 12:40:

Definitely, we use an unsupported way of installing the drivers. This way has been working since MIDIYoke times up to now. The only problem with the "official" supported way is the requirement to sign userland drivers who handle MIDI ports. In all "normal" operating systems I know, applications can happily create MIDI endpoints without bothering with drivers though 😀

As to possibility to remove the registry entry after we happily started the target application (e.g. DOSBox), it doesn't actually matter. Upon startup, the DLL is loaded to the process address space, the port gets created, so nothing else matters anymore. To reflect the changes in the MIDI setup, one always needs to restart the MIDI application. Therefore, if the service creates a port right before starting the application, all should be smooth. As long as M$ doesn't remove this function altogether 😀

Reply 26 of 82, by darry

User metadata
Rank l33t++
Rank
l33t++
sergm wrote on 2020-05-29, 12:52:
darry wrote on 2020-05-29, 12:40:

Definitely, we use an unsupported way of installing the drivers. This way has been working since MIDIYoke times up to now. The only problem with the "official" supported way is the requirement to sign userland drivers who handle MIDI ports. In all "normal" operating systems I know, applications can happily create MIDI endpoints without bothering with drivers though 😀

As to possibility to remove the registry entry after we happily started the target application (e.g. DOSBox), it doesn't actually matter. Upon startup, the DLL is loaded to the process address space, the port gets created, so nothing else matters anymore. To reflect the changes in the MIDI setup, one always needs to restart the MIDI application. Therefore, if the service creates a port right before starting the application, all should be smooth. As long as M$ doesn't remove this function altogether 😀

Thank you very much for the detailed explanation .

Reply 27 of 82, by Srandista

User metadata
Rank Oldbie
Rank
Oldbie

Can you use munt integrated in DOSBox-ECE with May 2020 update?

Socket 775 - ASRock 4CoreDual-VSTA, Pentium E6500K, 4GB RAM, Radeon 9800XT, ESS Solo-1, Win 98/XP
Socket A - Chaintech CT-7AIA, AMD Athlon XP 2400+, 1GB RAM, Radeon 9600XT, ESS ES1869F, Win 98

Reply 28 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
ghuber wrote on 2020-05-23, 20:35:

But as long as DOSBox ECE manages to work with MUNT included, I guess I can live with it.

I see no reason for it not to work. Just use the internal MIDI device "mt32" and not a windows one.

Although, I'm sure, the demand to have mt32emu incorporated into DOSBox will grow with this new windows feature 😀

Reply 29 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

As a quick win, here's a scheduled task that can be imported in the "Computer Management/Task Scheduler/Task Scheduler Library/Import Task..." to execute "drvsetup repair" (from the default location the munt installer it writes to) at the system startup. During importing, it should be configured to run either with SYSTEM user or the local admin "with highest privileges". It seems to be enough to convince windows 10 (at least ver. 19041.264) to keep the mt32emu driver running.

Still, this is in no way a complete solution, as for example (re-)attaching USB device can break things again.

Attachments

  • Filename
    Repair mt32emu.zip
    File size
    986 Bytes
    Downloads
    153 downloads
    File comment
    A scheduled task to repair mt32emu registration at boot. Unzip and import...
    File license
    Public domain

Reply 30 of 82, by Dagar

User metadata
Rank Newbie
Rank
Newbie
sergm wrote on 2020-05-30, 06:47:

As a quick win, here's a scheduled task that can be imported in the "Computer Management/Task Scheduler/Task Scheduler Library/Import Task..." to execute "drvsetup repair" (from the default location the munt installer it writes to) at the system startup. During importing, it should be configured to run either with SYSTEM user or the local admin "with highest privileges". It seems to be enough to convince windows 10 (at least ver. 19041.264) to keep the mt32emu driver running.

Still, this is in no way a complete solution, as for example (re-)attaching USB device can break things again.

Looks like a good solution for the time being. However, I do not use a password for logging into my Windows 10 system. A password seems to be required by Microsoft when importing a task via Task Scheduler. If you leave the password blank it will give you an error when trying to import the task.

Reply 31 of 82, by Dagar

User metadata
Rank Newbie
Rank
Newbie

sergm,

Using the XML file from your archive above as a guideline, I was able to create the necessary task myself. Windows did not complain about needing a password.
Re-started the computer and it works.
Thank you!

Reply 32 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
Dagar wrote on 2020-05-30, 15:21:
sergm, […]
Show full quote

sergm,

Using the XML file from your archive above as a guideline, I was able to create the necessary task myself. Windows did not complain about needing a password.
Re-started the computer and it works.
Thank you!

Unfortunately, it'll stop working if you e.g. attach a USB camera or a similar device. A service that monitors the registry entry used by the driver is required to ensure more-or-less reliable work. But I'm not going to fight with Microsoft for it 😀

Also, I had a look at their brand new MIDI API (supported in Universal Windows Platform). Unfortunately, I see that it contains 0 improvements for developers of software synthesizers, but allows "to detect hot plug/unplug of devices" 😀
So for now, I see no other viable solution except a full-blown signed driver package (I can actually use a self-signed certificate for testing it though).

Probably, the driver installer can be improved to add more stuff to the registry so that windows admits that the driver is installed "correctly" and will not purge it, hopefully. I'll try to play with this a bit more, albeit not really sure to pull it off.

Reply 33 of 82, by darry

User metadata
Rank l33t++
Rank
l33t++
sergm wrote on 2020-05-30, 17:20:
Unfortunately, it'll stop working if you e.g. attach a USB camera or a similar device. A service that monitors the registry entr […]
Show full quote
Dagar wrote on 2020-05-30, 15:21:
sergm, […]
Show full quote

sergm,

Using the XML file from your archive above as a guideline, I was able to create the necessary task myself. Windows did not complain about needing a password.
Re-started the computer and it works.
Thank you!

Unfortunately, it'll stop working if you e.g. attach a USB camera or a similar device. A service that monitors the registry entry used by the driver is required to ensure more-or-less reliable work. But I'm not going to fight with Microsoft for it 😀

Also, I had a look at their brand new MIDI API (supported in Universal Windows Platform). Unfortunately, I see that it contains 0 improvements for developers of software synthesizers, but allows "to detect hot plug/unplug of devices" 😀
So for now, I see no other viable solution except a full-blown signed driver package (I can actually use a self-signed certificate for testing it though).

Probably, the driver installer can be improved to add more stuff to the registry so that windows admits that the driver is installed "correctly" and will not purge it, hopefully. I'll try to play with this a bit more, albeit not really sure to pull it off.

Would creating a signed virtual MIDI driver that other projects (softsynths) could hook into using a simple API be an option ? That way resources could be pooled (and thus costs shared) into signing one single driver .

NOTE : I am not a programmer, I am just floating a potentially dumb idea .

Reply 34 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Hmm, I think I've already mentioned virtualMIDI above. This driver and related SDK already exists, and it's cool and solid. But not free, so this kinda contradicts with the spirit of munt.

BTW, with windows 10 2004 we should be able to run linux on windows in WSL2, that is with full support of system calls and linux MIDI. Maybe it works with linux versions of DOSBox and mt32emu-qt already? I'm going to check it, as that'd be a real shame 😁

Reply 35 of 82, by darry

User metadata
Rank l33t++
Rank
l33t++
sergm wrote on 2020-05-30, 17:39:

Hmm, I think I've already mentioned virtualMIDI above. This driver and related SDK already exists, and it's cool and solid. But not free, so this kinda contradicts with the spirit of munt.

I was thinking of an open-source option .

Reply 36 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
sergm wrote on 2020-05-30, 17:20:

Probably, the driver installer can be improved to add more stuff to the registry so that windows admits that the driver is installed "correctly" and will not purge it, hopefully. I'll try to play with this a bit more, albeit not really sure to pull it off.

And it appears that works. Just moving all registry entries found in Windows XP after "proper" installation of the driver (i.e. using the .INF file) convinced windows 10 that it is "valid" 😀
Also, it is now shown in the Device Manager, for added validity. So far, so good...

I'll try to conjure something in drvsetup.

Reply 37 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

It appears, windows isn't that strict at security as we assumed, it just made the process of installing unsigned drivers as annoying as possible... 😀
We can choose to reboot windows in the "unsecure" mode, so it will simply ask the user whether he wants to install an unsigned driver. Also, one now needs to start the wizard capable of installing drivers for non-PnP devices from the command line (or the Run box), making it even simpler 😀

We start our quest from the new control panel (yes, the other control panel which is called "Settings"). In the Update & Security, go to the Recovery pane and initiate the Advanced startup. When it reboots to the boot loader config, proceed to the Troubleshooting / Advanced options / Startup settings. After yet another restart, we'll be able to switch the desired "unsecure" mode by pressing key F7 or 7 and windows will boot up. Nice eh?

BTW, this mode will last until the next reboot only. But while it is active, we can make the driver installer finally do its dirty work. Fire hdwwiz.exe, this is the old and the coolest hardware install wizard, which allows to install drivers for software-only devices like mt32emu, and point to the directory with the unzipped driver via the Advanced / Have Disk options. After all that, things go blazingly fast, and the driver will start to work in a second.

A long way indeed. I'll be seeking for better choices yet, at least the hdwwiz.exe step should be possible to eliminate using an automated driver installer.

Reply 38 of 82, by darry

User metadata
Rank l33t++
Rank
l33t++
sergm wrote on 2020-06-03, 19:56:
It appears, windows isn't that strict at security as we assumed, it just made the process of installing unsigned drivers as anno […]
Show full quote

It appears, windows isn't that strict at security as we assumed, it just made the process of installing unsigned drivers as annoying as possible... 😀
We can choose to reboot windows in the "unsecure" mode, so it will simply ask the user whether he wants to install an unsigned driver. Also, one now needs to start the wizard capable of installing drivers for non-PnP devices from the command line (or the Run box), making it even simpler 😀

We start our quest from the new control panel (yes, the other control panel which is called "Settings"). In the Update & Security, go to the Recovery pane and initiate the Advanced startup. When it reboots to the boot loader config, proceed to the Troubleshooting / Advanced options / Startup settings. After yet another restart, we'll be able to switch the desired "unsecure" mode by pressing key F7 or 7 and windows will boot up. Nice eh?

BTW, this mode will last until the next reboot only. But while it is active, we can make the driver installer finally do its dirty work. Fire hdwwiz.exe, this is the old and the coolest hardware install wizard, which allows to install drivers for software-only devices like mt32emu, and point to the directory with the unzipped driver via the Advanced / Have Disk options. After all that, things go blazingly fast, and the driver will start to work in a second.

A long way indeed. I'll be seeking for better choices yet, at least the hdwwiz.exe step should be possible to eliminate using an automated driver installer.

Thank you .

I tried it, but when I point the wizard to the folder with mt32emu.inf ( C:\Program Files\munt\mt32emu_win32drv ) , I get

munt_install.png
Filename
munt_install.png
File size
6.47 KiB
Views
2454 views
File license
Public domain

I am using a 64-bit version of Windows 10 Pro build 2004 .
I have attached the directory with the driver in case you need it .

Filename
mt32emu_win32drv.zip
File size
340.63 KiB
Downloads
81 downloads
File license
GPL-2.0-or-later

Reply 39 of 82, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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.

Attachments