A few points:
- I already sent a PR your way. It's not about C#. Not yet. 😀
- Before refactoring, I'd add unit tests so no regressions occur. Of course the code has to be testable, which may trigger refactorings. 😁
- Windows 98 only supports .NET Framework 2.0 at most. For Windows XP it's .NET Framework 4.0. Both are ancient. C# 2.0/4.0 will be no fun at all.
- The Mono implementation of WinForms is not useable.

edit:
-If you target .NET Framework before 4.7, you'll have to use Visual Studio 2019, not 2022.
- It's possible to use multitargeting, but you'll have to use the lowest common denominator (ie. C# 2.0 if one of your targets is .NET Framework 2.0)

I first once see so such a decision , what for do editor for very old Roland LA synthesizers so , what need one of latest dot net framework ? Who is this for? People use MT-32 synthesizer or MUNT or VST MT-32 version for if work on old PC , or work in older operating system , but not what be work with latest system ) that variant whitch now have , if make portable version with integrate dot net 6.0 - takes 130 megabytes this is mad very big mad.
I offer remake this editor on 32 bit version and rollback to dot net 4.0 or dot net 2.0

There is a huge cost in maintenance to go back to .NET Framework 4.0, and 2.0 is downright insane. For starters, VS 2022 doesn't support it anymore.

Also .NET 8 (the latest LTS) can trim WinForms apps, so the release, even with the runtime included, is very small.

I offer remake this editor on 32 bit version and rollback to dot net 4.0 or dot net 2.0

You sent a PR ?

Why? To do portable version include NET , I do this https://yadi.sk/d/Kcyp-vwS2kLYdw , you meen what this normal ?

I don't understand you. Can you rephrase that ?

Yes , I think what this size for easy editor too big , I want to this editor will be smaller and compatible with 32 bit versions Windows )

Again, that's a lot of work to make the code base compatible with the old .NET Framework of the Windows XP era.
It also demands that the developer uses outdated and slow IDEs, such as VS 2019.

I think people who value their own free time and don't want to burn out will avoid that.

You are welcome to fork the code and make it yourself.

xcomcmdr wrote on 2024-01-03, 18:46:

Again, that's a lot of work to make the code base compatible with the old .NET Framework of the Windows XP era. It also demands […]
Show full quote

Again, that's a lot of work to make the code base compatible with the old .NET Framework of the Windows XP era.
It also demands that the developer uses outdated and slow IDEs, such as VS 2019.

I think people who value their own free time and don't want to burn out will avoid that.

You are welcome to fork the code and make it yourself.

I'm not knowning as do compile in visual studio , I newer not do this.

https://visualstudio.microsoft.com/vs/getting-started/

Apparently I'm stupid , I installed Visual Studio 2019 components only for compile , and I not understand as do compile.

xcomcmdr wrote on 2024-01-03, 18:46:

Again, that's a lot of work to make the code base compatible with the old .NET Framework of the Windows XP era. It also demands […]
Show full quote

Again, that's a lot of work to make the code base compatible with the old .NET Framework of the Windows XP era.
It also demands that the developer uses outdated and slow IDEs, such as VS 2019.

I think people who value their own free time and don't want to burn out will avoid that.

You are welcome to fork the code and make it yourself.

Hi,
Frequently Roland User is not an easy one to understand but I feel this time he is at least partly right.
I do not think that your answer regarding why this editor is not "compatible with 32 bit versions of Windows" is correct. I'm not talking about Win XP but Win 7/8/10 32-bit. Releasing a 32-bit executable requires neither WinXP era frameworks nor "slow" outdated IDEs ( let alone for now that VS 2022 is nowhere faster than older VS versions...).
To be honest I do not understand either why this software has to be 64-bit only (only 64-bit versions are available currently as releases). This editor does not require 4GB+ memory (or 4GB+ address space). It uses the legacy WinMM Midi API for handling Midi In/Out ports. I have never seen 64-bit only legacy WinMM Midi drivers/tools/software but I know some that are 32-bit only (Maple, Midi Yoke etc.).
The current 64-bit version of this editor cannot see/handle 32-bit only ports.
So even on modern 64-bit versions of Windows a 32-bit version of this editor would be more useful and more compatible than the currently available 64-bit one.

Unless there is a native x64 dependency, the code is compiled to IL, so it's neither 64 bit or 32 bit. It can run on a 32 bit version of the .NET 6 runtime just fine. Or at least, the code can be adapted to 32 bit easily.

But .NET 6 itself requires a recent operating system. At least Windows 10.

For it to work on (and I quote) "old PC" with an "older operating system":

If you want to use it on an older PC with an "older operating system", that means at least Windows XP, which at most can run .NET Framework 4.0, which means going back to VS 2019 (and yeah, VS2022 is 64 bit and way faster and stable than the old slow and 32 bit VS2019), and going back to older C#. Not. Fun.

Busy work with a huge risk of regressions, for a very small reward.

As you can see , I run this application on Windows 7 x64 , but what for this appliacation x64 code ? Realy not need 4 GB or more RAM for work

xcomcmdr wrote on 2024-01-04, 13:39:

But .NET 6 itself requires a recent operating system. At least Windows 10.

According to this .NET 6 is NOT Win 10+ only:
https://learn.microsoft.com/en-us/dotnet/core … dows?tabs=net60

xcomcmdr wrote on 2024-01-04, 13:39:

and yeah, VS2022 is 64 bit and way faster and stable than the old slow and 32 bit VS2019

Try to work with it using a PC with 4 cores and 8GB RAM...

And let me repeat myself: I was not talking about WinXP 32-bit. I was talking about a 32-bit version of the editor that is currently released as 64-bit only.

It can run on a 32 bit version of the .NET 6 runtime just fine.

No, currently it cannot. And the bigger problem is that even if it had been released as "Any CPU" instead of "x64" it would still be executed as a 64-bit executable on 64-bit Windows so its compatibility with 32-bit ports would be the same.
So an explicit "x86" release is still the better solution.

Falcosoft
Yes and this limiting in use operating system , can not use Windows 7x86 or Windows 8x86 or Windows 10 x86 and this very weird )

Roland User wrote on 2024-01-04, 13:52:

As you can see , I run this application on Windows 7 x64 , but what for this appliacation x64 code ? Realy not need 4 GB or more RAM for work

4 GB is the maximum a 32 bit application can address.

It does not use 4GB.

Understand what for 32 bit application with 4 GB will be work with small errors , but in this application at all not need 4 GB RAM or addressing space.

You don't need to care about an application's address space.

Hi,
I would like to report 2 problems I have noticed:

1. The attached SysEx dump from the DOS game Operation Stealth that contains valid MT-32 SySex messages throws an unhandled exception (index was outside the bounds of the array) when I try to load it.

2. If the current directory is changed by a driver/operation then the save file (MT32Edit.ini) is saved to the arbitrary path that is the actual current directory and not to the start up directory where MT32Edit.exe can be found.

Thanks in advance.

Hi all,

I was planning to do some further updates last Autumn but it's ended up being a very busy few months. I'm happy to make an x86 build of the app, but I'll only be able to test it on a 64-bit OS.

Falcosoft wrote on 2024-01-04, 22:37:

1. The attached SysEx dump from the DOS game Operation Stealth that contains valid MT-32 SySex messages throws an unhandled exception (index was outside the bounds of the array) when I try to load it.

That's a really strange SysEx file- thanks for sharing! Inspecting it with MIDI Tools shows that the 18th sysex message is missing a checksum byte- removing this message from the SysEx file prevents MT32Editor from crashing but it can still only recognise one of the 42 timbre definitions which appear in the file. Below the timbre definitions there are a large number of patch definitions which seem to repeat over and over again for no purpose. I'll have a look at the code this weekend and see if I can get it to do a better job of interpreting this file without crashing.

Falcosoft wrote on 2024-01-04, 22:37:

2. If the current directory is changed by a driver/operation then the save file (MT32Edit.ini) is saved to the arbitrary path that is the actual current directory and not to the start up directory where MT32Edit.exe can be found.

Not quite sure how to duplicate this bug, but it'll be an easy fix to detect the directory at start-up and make sure the .ini file is always saved there.