What errors are you getting with MinGW? Usually the most common errors are a lack of dependencies resolved by adding libraries appropriately (like libsdl, etc)

You can always run a newer (32-bit) Windows in a VM. Did that myself when I still had XP on my main rig and was facing a similar issue to yours; 32-bit Windows 7 under VirtualBox, in my case. That may sound back-asswards, but it's probably less trouble than successfully getting a complex project to compile in an unsupported environment.

Be aware however that you may have to fiddle with some VS2013 settings, since IIRC it won't produce XP-compatible executables out of the box.

leileilol wrote:

What errors are you getting with MinGW? Usually the most common errors are a lack of dependencies resolved by adding libraries appropriately (like libsdl, etc)

I get;

1process_begin: CreateProcess(NULL, uname -s, ...) failed.
2process_begin: CreateProcess(NULL, uname -s, ...) failed.
3process_begin: CreateProcess(NULL, uname -s, ...) failed.
4process_begin: CreateProcess(NULL, uname -s, ...) failed.
5process_begin: CreateProcess(NULL, uname -s, ...) failed.
6process_begin: CreateProcess(NULL, uname -s, ...) failed.
7process_begin: CreateProcess(NULL, uname -s, ...) failed.
8process_begin: CreateProcess(NULL, uname -s, ...) failed.
9process_begin: CreateProcess(NULL, uname -s, ...) failed.
10Makefile:55: *** OS type "" not supported.  Please file bug report at 'http://code.google.com/p/mupen64plus/issues'.  Stop.

As I said, I know very little about compiling programs and the instructions are rather vague. It mentions needing some libraries, but doesn't actually tell you what you need to do with them. I guess it's just assumed that anyone attempting to compile the program will automatically know what to do. 🙁

VileRancour wrote:

You can always run a newer (32-bit) Windows in a VM.

Well, I don't actually have a newer version of Windows and don't really want to pay $50+ for a copy on eBay that may or may not be legit. I suppose there's the other option that can't be discussed here...

VileRancour wrote:

Did that myself when I still had XP on my main rig and was facing a similar issue to yours; 32-bit Windows 7 under VirtualBox, in my case. That may sound back-asswards, but it's probably less trouble than successfully getting a complex project to compile in an unsupported environment.

I suppose. For a while, there were XP compatible versions being supplied with a front-end program called M64PY, but that hasn't been updated past 2.3.

VileRancour wrote:

Be aware however that you may have to fiddle with some VS2013 settings, since IIRC it won't produce XP-compatible executables out of the box.

I know. IIRC, MS initially removed the ability to make XP compatible binaries completely, but added it back in after some backlash from their customers.

For some reason the Makefile is not properly detecting you have MinGW installed. It fails:

1ifeq ("$(patsubst MINGW%,MINGW,$(UNAME))","MINGW")
2  OS = MINGW
3  PIC = 0
4endif

and instead executes:

1ifeq ("$(OS)","NONE")
2  $(error OS type "$(UNAME)" not supported.  Please file bug report at 'http://code.google.com/p/mupen64plus/issues')
3endif

Can you do this. Inside mingw can you execute:

1uname -s

And tell us what you get?

Path problem to MINGW?

vladstamate wrote:

Can you do this. Inside mingw can you execute: […]
Show full quote

Can you do this. Inside mingw can you execute:

Copy code to clipboard

1uname -s

And tell us what you get?

I have no idea how to do that. I typed it from a normal command line and it didn't recognize it as a valid command. I searched the MinGW directory and there's no file by that name. I have no idea how to enter that command "inside" MinGW.

As I said, I know virtually nothing about compiling programs. I downloaded MinGW, installed it, made sure that the command path was set to include the Bin sub-directory in the install directory so it could find the commands, then I CDed to the source code's Projects\Unix directory and entered;

mingw32-make.exe all

Beyond that, I don't have the faintest clue what I'm supposed to do. The one time in the past that I used it to compile a program, there were explicit instructions that told you step-by-step how to do it.

gdjacobs wrote:

Path problem to MINGW?

The path includes the MinGW\Bin directory, but I also tried adding the MinGW install directory to the path and that didn't work either.

The instructions for how to compile most programs are the equivalent of telling someone who's never seen a car before to just start it up, put it in drive and step on the gas. Logical instructions for someone familiar with cars, but no help whatsoever to someone who has no idea what those terms mean or where the controls are.

Rekrul wrote:

However, the Windows version is normally compiled with Visual Studio 2013, which doesn't work under XP.

That does not mean that you cannot get it to compile using an older version of Visual Studio.

Ok. You are trying to compile from outside mingw. Lets do something else instead. In the MinGW/Bin folder there should be an executable that runs a shell. Like mingw32.exe or something like that. Find one that opens a shell and execute it. Inside there run "uname -s". If that is all good, still inside that shell, navigate to your makefile path "Projects\Unix" and just type "make all".

It will save some navigating in this new shell if you start it from withing the "Projects\Unix" folder. So use the Windows' command prompt to navigate there first, then type "mingw32.exe" (or whatever the shell name is) then do the stuff I said above.

If you use an older version of VS (pre 2013), the 2013 solution file *may* not be entirely compatible, so you would be forced to rebuild the solution file with the source (including all issues from dependencies, build configurations etc... wouldn't recommend this unless you were more comfortable with solution files and what/how they do their thing).

VS2013 most certainly can build XP compatible binaries, however the problem you have come across is known and requires (again) some solution file mutilation (described here : https://software.intel.com/en-us/articles/lin … n-on-windows-xp).

Not entirely sure what happened, however given the time frame, my guess is the new toolset for Windows8 got rolled out (with VS2013 possibly?) by default when this version of VS came to light (would have been prior to 2013 despite the name), and thus by default build with the wrong toolset to work on XP. Certainly XP only supports up to .Net 4 (not later) so this is already another restriction by default (new projects with VS will default to latest .Net, i.e default to later than what XP can support). I digress...

I would have thought the easiest thing to do is download VS2015 Community edition (or whatever its called, its the free one!) and open the VS2013 solution in that (it will update/convert the VS2013 to a VS2015 with hopefully no problems, I've never had a problem 😀 anyhows) and then compile and build it with VS2015. I can confirm that VS2015 will build XP compatible binaries (And I have never had to change the settings to do so, you might have to if so it will be minor and I can guide you through it, but tbh I doubt it) out of the box and all you need to ensure is that it is .Net 4 (no later), which it will be since its VS2013 era solution in the first place, and that you have the VS2015 Redist c/c++ installed in XP to run it. 😀

VS2015 here: https://www.visualstudio.com/downloads/

They have 2017 out o.0, when did that happen?

spiroyster wrote:

VS2015 here: https://www.visualstudio.com/downloads/

They have 2017 out o.0, when did that happen?

Ugh, you got me excited there for a moment, but there is no 2017 Community Edition (the free one). 😀

vladstamate wrote:

spiroyster wrote:

VS2015 here: https://www.visualstudio.com/downloads/

They have 2017 out o.0, when did that happen?

Ugh, you got me excited there for a moment, but there is no 2017 Community Edition (the free one). 😀

Try this: https://www.visualstudio.com/downloads/#visua … mmunity-2017-rc 😀

Looks like a 'free one' 😀, cannot test though as I only have my work laptop atm, and can't risk possibly breaking important stuff 😵
Its only a Release Candidate phase (not calling them beta's anymore Microsoft? or did I miss that one) o.0

[EDIT:] Ah there probably was a beta, Never heard them suffixing 'Candidate' to 'Release' publically before o.0

RC is the stage after beta - they just keep releasing RCs until they think it's good enough to ship, at which point they take the RC label off and call it stable.

vladstamate wrote:

Ok. You are trying to compile from outside mingw. Lets do something else instead. In the MinGW/Bin folder there should be an executable that runs a shell. Like mingw32.exe or something like that.

Unfortunately there isn't. I tried every EXE file in the MinGW directory and the only one that opened any kind of shell was gdb.exe, but that doesn't recognize either the command uname, or make. In the Start menu, there's a link to open a MinGW Command Prompt, but that just opens a normal shell window with some extra parameters, none of which make it recognize uname or compile the source code.

spiroyster wrote:

I would have thought the easiest thing to do is download VS2015 Community edition (or whatever its called, its the free one!) and open the VS2013 solution in that

Yes, that would be the easiest solution. If you can just point me to a version of VS2015 that runs on Windows XP, I'll be all set...

I believe the shell refers to MSYS. If you set up MinGW using its installation manager, make sure mingw-developer-toolkit is selected (msys-base should be automatically added). Check for something like msys\1.0\MSYS.BAT under your main MinGW directory.

Rekrul wrote:

As I said, I know very little about compiling programs and the instructions are rather vague. It mentions needing some libraries, but doesn't actually tell you what you need to do with them. I guess it's just assumed that anyone attempting to compile the program will automatically know what to do. 🙁

Oh I see. This is just a standard developer apathy problem where instead of having graceful understandable errors it'll just forbid all compiling for older Windows platforms altogether. This isn't a real bug.

VileRancour wrote:

I believe the shell refers to MSYS. If you set up MinGW using its installation manager, make sure mingw-developer-toolkit is selected (msys-base should be automatically added). Check for something like msys\1.0\MSYS.BAT under your main MinGW directory.

MinGW doesn't work properly without its own custom shell?

No, I don't have MSYS. I installed MinGW a few years ago using a self-contained installer. I'm not sure where I got it, as I can't seem to find the installer file now (I normally keep everything I download). I'd be happy to try installing MSYS, if I could find a self-contained, offline installer for it. Call me weird, but I absolutely hate web-installers.

Not that I really think it'll make any difference...

leileilol wrote:

Oh I see. This is just a standard developer apathy problem where instead of having graceful understandable errors it'll just forbid all compiling for older Windows platforms altogether. This isn't a real bug.

This is why the majority of people don't bother trying to compile their own programs from source code.

Since it looks like I'm not going to be able to compile Mupen64Plus 2.5 myself, would anyone be willing to compile an XP compatible version of it for me?

Rekrul wrote:

No, I don't have MSYS. I installed MinGW a few years ago using a self-contained installer. I'm not sure where I got it, as I can't seem to find the installer file now (I normally keep everything I download). I'd be happy to try installing MSYS, if I could find a self-contained, offline installer for it. Call me weird, but I absolutely hate web-installers.

Not that I really think it'll make any difference...

The universe does not work like that. You either want to compile your stuff or you don't. Putting arbitrary conditions will no get you far. People use web installers because MingW like any open source software is a moving target. A web installer will make sure to always grab latest. Since you got yours a few years ago I suspect a large number of bugs have since then been fixed.

And yes getting MSYS will make a difference. The makefile is specifically running shell commands: search for "shell uname -s" for example. You need MSYS.

You asks us to work within your confines which is fine, but then asking someone else to do the job for you is NOT staying within your confines either.

calvin wrote:

RC is the stage after beta - they just keep releasing RCs until they think it's good enough to ship, at which point they take the RC label off and call it stable.

I just find it strange use of terminology used to publically name a version, since it gives no merit to end-testers/users. Its an internal phrase for a non-regression tested beta, but its still a beta? Where I work, distinguishing it as a beta (as opposed to release) is also important for liable reasons, i.e we cannot support, nor be held responsible for non-release (beta) versions.

Seems like MS have been doing this years (trying to figure what the phrase means that is) 😀
http://www.informationweek.com/analysts-micro … /d/d-id/1046790

Rekrul wrote:

Since it looks like I'm not going to be able to compile Mupen64Plus 2.5 myself, would anyone be willing to compile an XP compatible version of it for me?

If you have VS2013 installed, all you need to do is...

Open the solution in VS2013
right click on the project icon in the 'Solution Explorer'
click 'Properties'
click 'General' (under Configuration Properties on the left panel)
choose 'Visual Studio 2013 - Windows XP (v120_xp)' from the drop down menu next to 'Platform Toolset'
click 'OK'
then menuitem 'Build'-> 'Rebuild Solution'

This should compile with the correct platform toolset. Also note to build a Release version (for performance reasons), rather than Debug.

You will also need to install the redist runtime to run on XP.
https://www.microsoft.com/en-us/download/deta … s.aspx?id=40784

If needs be I can give a go at building those repos for you in VS2015 (with the correct v140_xp toolset), but I cannot test as I don't have access to an XP machine. At some point, I'm rather busy atm though so cannot say when I can apply some time to this.

You'll have to tell me which repos you want as I don't want to build all of them unless need to. And it doesn't appear to be any single 'repo' with what you need. Rather a collection of the all components and I have no idea what mupen64plus needs to be setup to run?

https://github.com/mupen64plus

It should be pretty easy to 'downgrade' the solution to VS2010 (the last VS to work in XP). The solution and project files are just simple XML files. Just edit the version number, and you're probably halfway there already.
If it doesn't work, what I usually do is to create a new VS2010 solution and project of the same type, then use WinMerge to compare the solution files and see what the problem is.
Worst case, I just import the source files into a new project, and try to get it running from there.

Once you can open the solution and project files, the compiler will tell you if there's any source issues that it can't deal with. But it will probably be pretty smooth sailing.

I wouldn't try an alternative environment like MinGW. That's probably a lot more work.