I strongly suspect your XP was missing some dependency (like the printing subsystem) that the .net installation corrected. Some plugin that you are using might require .net (ESS maybe? I don't know). But Mach does not require .net for the GUI and core. It never has and never will. I'm not a fan of anything .net and I will do ANYTHING not to use it. But Microsoft pushes that stuff like crack! So some program installers (the programs that install the applications) try to include it whenever they can, by default, unless the programmer writing the installer explicitly turns it off. Obviously, our installer does install .net. But that might explain why .net is installed with other applications, even if it is not used or needed.
Side by side is the term used when referring how DLL dependencies are loaded. Old school Windows would load DLLs in the Windows/System32 directory, if they existed there, first. Side by side give preference to the DLLs in the application's directory. Side by side, or "SxS" was the fix for "DLL Hell" caused by different versions of the same DLL. ComCtl32.dll, for instance. If a newer version of that DLL exists in the application directory, it will use it instead of the ComCtl32.dll in the Windows\System32 directory.
At one time, Mach did not require any of the printing subsystem. So it might have installed and run previously. But we added printing in the G code and LUA editors, so that subsystem is now required. It is possible that installing the .net stuff also installed a missing printing subsystem, etc...
There is a program called Dependency Walker that is used for figuring stuff like this out. But I will be the first to say that it is cryptic and hard to use. But if you strip down the OS to the point of the application not being able to run, you may have to use a tool like Dependency Walker to figure out what is needed. Or, get lucky and install something like .net that happens to also install the needed dependency.
Since Mach 4 is now running, but takes a long time to load, it may be a virus software thing. For example, Windows Defender delays the loading of Mach when it is launched for the first time in a certain amount of time. It scans the EXE and all of its' dependencies before launching. And it can delay the launch for a ridiculous amount of time! Excluding Mach4GUI.exe in Defender sizes the problem. There is another post on this forum related to that. So look for something like that.
Also, think about upgrading your Operating System. Microsoft ended support of XP on April 8, 2014. So we are coming up on the 4 year anniversary of that date. My current compiler (Visual Studio 2013) won't even run on XP! Luckily, it will still compile an executable that will run on XP. We have to do some tricks to even get an executable that will run on XP with 2013. I would say the writing has been on the wall that XP is dead has been there for a good period of time now. We are fixing to make the jump to the Visual Studio 2017 compiler and there is no guarantee that it will even produce an executable for XP. If it doesn't, then that will end Mach 4 running on XP, for sure.
![Sad :(](https://www.machsupport.com/forum/Smileys/default/sad.gif)
My point being is that we are fast running into the possibility of not being able to support XP. Windows 10 seems to be a very stable OS at this point. As good or better than Windows XP.
Steve