Update on MinGW convertion project...

[Bahamut_ZERO_Clue]

Well after compiling, recompiling, and rebuilding the sources as stated by Nach and others I have concluded that MinGW simply will not compile ZSnes and here's the reason.

DirectX 8.0 SDK w/ D3DX Import Libraries is not compatible completely with the ZSnes sources. There is simply too much conflict within the winlink.cpp code due to the heavy usage of very strict VC-only code to be compatible with GCC. So I declare the project dead but not buried.

However there is a way and it's very contravertial but I think I can report back the Linux SDL code for compiling and usage on Windows. I've been looking over the Linux specific code and discovered its very compatible with MinGW though some minor changes would be needed. It's gonna take time, possibly a few monthes at best guess because now I have to study SDL specifics but I feel it can be done and be a lot cleaner at that in the final code. Yes I know SDL wraps to DirectX when used in Windows but it would still carry the same DirectSound and DirectInput and draws would be done in OpenGL.

In fact I think I could even consolidate the SDL code for usage on both Windows and Linux equally with enough work and time.

BTW after looking over the Linux source, I want to commend the guys who wrote it. Very clean and somewhat simplistic code guys.

[funkyass]

. Yes I know SDL wraps to DirectX when used in Windows

Directx 5, SDL wraps to DX5. Something rather important to note.

[Nach]

BTW after looking over the Linux source, I want to commend the guys who wrote it. Very clean and somewhat simplistic code guys.

Gotta thank theoddone33 and zinx, and probably a few others.

[Noxious Ninja]

BTW after looking over the Linux source, I want to commend the guys who wrote it. Very clean and somewhat simplistic code guys.

Gotta thank theoddone33 and zinx, and probably a few others.

Prometheus from Loki?

[evilant]

DirectX 8.0 SDK w/ D3DX Import Libraries is not compatible completely with the ZSnes sources. There is simply too much conflict within the winlink.cpp code due to the heavy usage of very strict VC-only code to be compatible with GCC. So I declare the project dead but not buried.

Out of curiosity, what are the VC-only problems in winlink.cpp? Are you talking about compile problems, or runtime problems? I scanned through it quickly and the only obvious compiler-specific things that leaped out at me was a few _int64's and a few 64-bit initializers.

I ask because I was under the impression that all this code could be compiled without problems with MinGW (maybe with a few tweaks), but that the resulting binary would not work. *That* is the problem I would like to get solved. Maybe when I get home tonight I will give this a try.

[Bahamut_ZERO_Clue]

The DirectX 8.0 SDK used by MinGW even with the Import libraries is not the same exact SDK as the genuine Microsoft DirectX 8.0 SDK. Lots of things were changed to make the SDK more compatible with the GNU code. In turn the genuine Microsoft SDK is incompatible with MinGW.

In short neither SDK would work successfully within MinGW. One would be more compatible with ZSnes and break up MinGW like an old stale cookie, and reverse for the other.

[BFeely]

However there is a way and it's very contravertial but I think I can report back the Linux SDL code for compiling and usage on Windows. I've been looking over the Linux specific code and discovered its very compatible with MinGW though some minor changes would be needed. It's gonna take time, possibly a few monthes at best guess because now I have to study SDL specifics but I feel it can be done and be a lot cleaner at that in the final code. Yes I know SDL wraps to DirectX when used in Windows but it would still carry the same DirectSound and DirectInput and draws would be done in OpenGL.

In fact I think I could even consolidate the SDL code for usage on both Windows and Linux equally with enough work and time.

If the code has Linux/Unix specific code, then maybe you should consider trying Cygwin, which emulates many of those Linux/Unix APIs not available in Windows. Note that programs compiled with Cygwin require the Cygwin DLL to work though.

[Bahamut_ZERO_Clue]

You do have a point but I consider Cygwin to be a bit bloated in some cases. The problem also with Cygwin is I'm really unsure how SDL will behave with it. I've never had good luck with SDL under Cygwin. And remember Cygwin isn't a way to make Linux apps run under Windows. You still have to go back and rebuild everything for it.

MinGW would be a better solution as it's more Windows specific. BTW the porting is going slow but it's progressing.

[Jonas Quinn]

I compiled the mingw build with the latest CVS revision today.

I noticed that the crashes when loading a rom are gone.

The speed with PAL games is perfect but the NTSC speed is like there is no frame limiter.

I need to check if it has more problems.

[Nach]

I compiled the mingw build with the latest CVS revision today.

I noticed that the crashes when loading a rom are gone.

I recently went around the source fixing some sections where we write to invalid variables. To prevent us from crashing in MSVC, we used a special link option, and in Linux, we used mprotect(), but we never did anything for MinGW before.

I still don't know if I fixed every last error like that, to make sure the MinGW build is really stable, we need to find to do something similar to MSVC's make .text writable or mprotect() for POSIX OSs.

Edit:
Jonas Quinn:
Can you send me your latest CVS changes to build a MinGW binary?

[Jonas Quinn]

Here is my file with the mingw-changes for the current cvs.

(removed)

I included a .diff for winlink.cpp and my makefile.

[Nach]

Thanks, I'll try to have a look later and see what I can do about making MinGW mainstream.

[byuu]

I still don't know if I fixed every last error like that, to make sure the MinGW build is really stable, we need to find to do something similar to MSVC's make .text writable or mprotect() for POSIX OSs.

If you want.. I know how to modify a PE image to make .text writable.
In its section there is a characteristics DWORD value. 0x80000000 is the mem_write flag which will do what you like.
If you'd like, you can send me a MinGW EXE and I will make .text writable, just to see if it helps.
I've got a ton of information on the PE format that I can send your way as well.

Worst case scenario, you can use this as an immediate workaround while tracking down the stray memory accesses. I can make a small ansi-c tool that you can run on the final binary for the win32 port that will patch the .text section automatically.

[Nach]

Sounds excellent, I'd love such a tool.

Just remember that MSVC object files and MinGW object files aren't the exact same format.

[byuu]

Here's the tool

In the code, line 130 is what sets the attributes for the .text section.
At present, this program will only add mem_write to the flags, and not remove any existing ones.
I don't think its needed, but you may need to add the 'Contains initialized data' flag (or unitialized data, or both...). Just change line 130 from
patch_val = x | MEM_WRITE;
to
patch_val = x | MEM_WRITE | 0x40;
The table of flags is directly above it for you to reference as well.
contains_initialized_data = 0x40, contains_uninitialized_data = 0x80

Also, please bear in mind that patching .text to be writeable is generally a bad idea, as this makes it possible to overwrite program code.

To use it, just drag any EXE onto it, and if it has a .text section, it'll be made writeable. Verify by running the app on the EXE again, and it should show up in the .text attributes section output.

---

Edit: peload.c and pedump.c are -really- old pieces of code I wrote a few years ago when working on something else (API tracer). They're coded very poorly, but I stuck them in anyway since it completely breaks apart the entire PE header.

[byuu]

I wrote an example c app that you can use to see the effects of making .text writeable.

Code: Select all

#include <stdio.h>
#include <conio.h>

int main() {
char *p = (char*)main;
  printf("main = %0.8x\n", p);
  printf("v = %0.2x\n", p[0]);
  p[0] = 0x02;
  printf("v = %0.2x\n", p[0]);
  getch();
  return 0;
}

If you compile this with MinGW/MSVC, and run it, it will crash immediately with a GPF, as you're writing to read-only memory.
If you run pe_patch.exe on it, it will run fine: and overwrite the start of int main().

[Nach]

Thanks, looks like I have a new toy to play with

Although you forgot to include defs.h in the archive.

[byuu]

Sorry about that. It's included now, try downloading the archive again.
That's basically a tool that will tear apart the PE header and tell you tons of information about it. It doesn't give you the offsets to stuff though, so it isn't much use for modifying PE headers.

Good luck reading the older code though >_<

[Nach]

Thanks again byuusan.

Here is my file with the mingw-changes for the current cvs.

http://s7.yousendit.com/d.aspx?id=A2105 ... F8866070B5

I included a .diff for winlink.cpp and my makefile.

Okay, I spent a while getting winlink.cpp to be happy with both MSVC and GCC, not such an easy task I tell you.

I'm suprised your makefile worked, by me it says windres isn't correct. You're using -I, when in mine it needs --include-dir.

Anyways, for some reason when I compile now, I'm getting a segfault in the MMX code in winlink.cpp and I'm not sure why yet.

Which GCC and DX are you using?

[Jonas Quinn]

I'm using GCC 3.42, the "DirectX 9.0 SDK (October 2004)" and DirectX 9.0c.

Are you using any Optimization flags with winlink.cpp?
I found out that zsnes doesn't start if any optimization flags are used.

Maybe it's the -march=i586 flag that is causing the problems.

[Nach]

Okay fixed my segfault stupid mistake I made. Got a working binary now

PAL games seems fine, been playing SFA2 with HQ3X full speed no prob.
NTSC games though are going extremely slow despite it saying 60/60 on the bottom.

Once ipher comes back online I'm going to see if my changes are still compatible with MSVC, if so I'll commit it.

We also need to track down what is giving the black screen when using optimizations on winlink.cpp

[Nach]

Okay fixed NTSC. The jury is still out on why we need -O0 though.

[Nach]

Okay I commited my changes to CVS.

Jonas Quinn: Thanks for all your help in the summer for getting winlink.cpp to compile in MinGW and for afxres.h

Okay, ZSNESW is now compilable and working on both MSVC and GCC.
GCC build's NTSC is slighty too fast though, will have to look into that.

I will also try to work on the MinGW makefile so it doesn't need a special NASM, and use byuusan's program so we don't have to worry about segfaults.

I'll also setup cross compiling when I get a chance.

I'm so happy that I can develop ZSNESW too now

[burning shadow]

May I ask for a short FAQ on how to compile zsnes using mingw? What tools are needed exept mingw itself? Coz with last changes zsnes doesn't compile neither with mingw nor with MSVC6.

[TheDanish]

May I ask for a short FAQ on how to compile zsnes using mingw? What tools are needed exept mingw itself? Coz with last changes zsnes doesn't compile neither with mingw nor with MSVC6.

Fairly trivial now that 1.40 is out. Just in case anybody wants to do it now, and can't get it to work for some reason, I slapped together a package with everything you need here, and that should work until there's official support.

Edit: Nevermind, the newest Cygwin special build of NASM works. I was actually invoking that weird -O0 problem.
Edit2: I have been shown the light, and it's now up to date.