Thanks, but since installing .NET cures the problem, this is mostly an academic question.

I want to know so I can avoid possible issues in the future with non-Windows systems.

The guy writing the core code assures me that there are no .NET dependencies in
the code, but something could have crept into the installer along with all the non-core
stuff that gets into the package.

My regular test XP machine has been running Mach4 for well more than a year and it may
have something successfully installed that cannot now be installed without .NET present.

Steve Stallings
PMDX

We do not use .net at all.  Mach 4 is all native C++.  Some 3rd party plugins may require .net.  But we don't. 

The 2013 runtime redistribution package may be required to be installed (and you will need to be Administrator to do it).  We supply the runtime files in the Mach 4 directory but some XP systems are incapable of using the runtime in a side by side (SxS) configuration.  I believe some KB update needs to be installed in order for SxS to work in XP, although I do not know which one it is.

Steve

Was this the final resolution on the problem? 

I'm trying to run Mach 4 4.2.3481 on a Windows XP machine that's been updated to the XP Service Pack 3, but I've stripped out as much as possible since this will be dedicated only to running Mach 4.  When I tried to run Mach 4, it gave me the message that the core could not be initialized, and stated: "rc = -17" in the error message.  I have an Ethernet Smooth Stepper, and installed NET 4.0 as part of the installation process for it.  Is there a difference between NET 4.0 and NET 3.5? 

I installed the .NET service pack 3.5 and it now runs, but it takes more than a minute for Mach 4 to come up, and the screen scaling changes.  If Mach 4 doesn't require .net, how is it that it now runs?

I should also mention that I was able to run an earlier version of Mach 4 on this same computer, using the same XP image as a starting point.  I also had Mach 3 installed, so I don't know if it installed something that made Mach 4 work as well?

Should I be trying the 2013 runtime redistribution package?  I don't understand the side by side configuration, but has anyone been able to get it working using your recommended method?  What is a "KB update" referring to?

Thanks.

Ryan

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

Thanks for the reply and all the information. I hate to say it (after you wrote all of that), but I’m taking your advice from your last paragraph and upgrading my OS.  This computer will only be running Mach and the ESS plugin, and would never be connected to a network, so XP was still an option.  But trying to get new software (or hardware) to run on an obsolete OS isn’t much fun!