Visual Studio 2005 Support

Aefix · Post by **Aefix** » Wed Sep 20, 2006 3:57 pm

In Visual Studio 2005, functions such as sscanf and sprintf are declared as deprecated, and replaced with `secure' forms (e.g. sscanf_s, sprintf_s...). Is there any intent on adding support for this in the future?

If not, you could easily add in _CRT_SECURE_NO_DEPRECATE as a define for the msvc platform; this would avoid screenfuls of compiler warnings.

Aefix · Post by **Aefix** » Fri Sep 22, 2006 1:01 am

Also, 2005 tells me 'stricmp' isn't ISO C++ compliant anymore, as is its substitution, '_stricmp'.

Furthermore, I'm having some problems making the source. I have everything set up as per 'install.txt' (or so I am led to believe).

The make begins with parsegen and dspemu1.c compiling successfully. As soon as it hits an assembly file, 'fxemu2.asm', it spits out the following and aborts the make:

Code: Select all

nasm -O1 -f win32 -D__WIN32__ -o chips/fxemu2.obj chips/fxemu2.asm
process_begin: CreateProcess((null), nasm -O1 -f win32 -D__WIN32__ -o chips/fxem
u2.obj chips/fxemu2.asm, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [chips/fxemu2.obj] Error 2

However, nasm is working correctly. If I enter the exact nasm command that make is complaining about onto the command line, the .obj file is assembled correctly. So what gives with the error in the make?

This sounds like something wrong with my setup but I can't see what. Here's the specifics:

- using GNU make from unxutils
- using NASM v0.98.39
- using MSVC++ 8.0
- using the December 2005 DirectX SDK, with libraries and headers placed in VC's header and library directories
- using current releases of zlib and libpng

Anyone have any clues?

Aefix · Post by **Aefix** » Fri Sep 22, 2006 2:53 am

For anyone interested (by the number of posters that have replied, likely not many), I've gotten it compiling and running games; however not without modifications.

1) Used mingw's make utility (pagefault's suggestion).
2) Got the source for pdcurses (this is not mentioned in install.txt, but it should be).
3) Added a line to the top of panel.c in pdcurses to get it to compile:

Code: Select all

#define __override __new_override

4) Made the pdcurses lib and put it in VC's libs directory, headers in the headers directory.
5) Recompiled zlib in VC 8.0, added library files and headers to VC's directories. Note that in the properties, projects must be using /MT as opposed to /MD in code generation.
5) Got the sources for libpng and using its VC 7.1 project, compiled a release LIB. Used /MT again.
6) Added libpng's libs and headers to VC's.
7) Added an option to ZSNES's makefile to disable the MSVCRT lib:

Code: Select all

cl /nologo /MT @link.vc ${WINDIR}/zsnes.res /link /NODEFAULTLIB:MSVCRT

After doing all this, zsnes compiles and the program runs fine - the first time. Running it a second time crashes because of something in zsnesw.cfg.

Aefix · Post by **Aefix** » Fri Sep 22, 2006 5:45 am

So I've figured out the reason for that crash: it's due to a call to access() in zpath.c. Passing it X_OK in the mode mask causes the program to crash; this must not be supported in 8.0. Changing the code as per this diff

Code: Select all

210c210
<               if (*LoadDir && !access(LoadDir, F_OK|X_OK|R_OK))
---
>               if (*LoadDir && !_access(LoadDir, F_OK|W_OK|R_OK))

makes it run nice again.

Also, I've made a VS 8.0 project to work with the ZSNES code. I won't put it up yet; too tired to trust myself... But if you want to see it in action take a look at this

.

Post by **Nach** » Sun Sep 24, 2006 11:53 pm

Go out and shoot MSVC. We really don't care about MS stupidity. Yet we maintain MSVC compiling support, but we don't want to hear about the stupidity seriously.

mozz · Post by **mozz** » Mon Sep 25, 2006 3:07 am

Nach wrote:Go out and shoot MSVC. We really don't care about MS stupidity. Yet we maintain MSVC compiling support, but we don't want to hear about the stupidity seriously.

Its been a long time since I tried to compile zsnes. Is GCC/mingw now the preferred way to compile it on Windows?

Aefix · Post by **Aefix** » Mon Sep 25, 2006 4:43 am

Well, if you want to support x64 on Windows, currently Microsoft's compilers are the only way to go. The first reason I ever looked at the ZSNES code is when the compile failed on my 64-bit Linux system... ever since then I've always wanted to try porting it to 64-bit. The ZSNES development team may not have any current plans to do this themselves (and I can see why not), but it gives me a reason to actually get into assembly.

Deathlike2 · Post by **Deathlike2** » Mon Sep 25, 2006 4:46 am

Aefix wrote:Well, if you want to support x64 on Windows, currently Microsoft's compilers are the only way to go. The first reason I ever looked at the ZSNES code is when the compile failed on my 64-bit Linux system... ever since then I've always wanted to try porting it to 64-bit. The ZSNES development team may not have any current plans to do this themselves (and I can see why not), but it gives me a reason to actually get into assembly.

Getting 64-bit support requires some redoing on the assembly. Simply put, 32-bit assembly does not migrate immediately to 64-bit on a recompile. There is actual work required to make this happen. This is definately on the things to do list, but not important since you can still compile a 32-bit binary.

Aefix · Post by **Aefix** » Mon Sep 25, 2006 5:13 am

I realize how much of an overhaul getting all of ZSNES to run in 64-bit would be, but I'm the type of person that just wishes everything would just get 64-bit already.

Deathlike2 · Post by **Deathlike2** » Mon Sep 25, 2006 6:01 am

Aefix wrote:I realize how much of an overhaul getting all of ZSNES to run in 64-bit would be, but I'm the type of person that just wishes everything would just get 64-bit already.

You should also realize that there are no real measurable benefits for doing so. It's not that there are no benefits all, but ZSNES isn't hitting problems simply because the "lack of 64-bit support". You will already be running ZSNES pretty damn fast if you are using a 64-bit processer in the first place....

Seriously, it will come when it comes.

Post by **Nach** » Mon Sep 25, 2006 11:39 am

mozz wrote:
Nach wrote:Go out and shoot MSVC. We really don't care about MS stupidity. Yet we maintain MSVC compiling support, but we don't want to hear about the stupidity seriously.
Its been a long time since I tried to compile zsnes. Is GCC/mingw now the preferred way to compile it on Windows?

Our releases for Windows have only been compiled with MSVC.

But I don't want to hear complaints how MSVC says standard functions are bad and we should use their proprietary functions instead. Nor do I want to hear about any other stupidity it makes up. You're free to use it though, and I have no problem if official releases still use it. We also plan to maintain support for it for a while, since native XBox requires it right now, and pagefault likes it's debugger, not to mention there's no reason not to.

In fact recently I just added ~100 lines of code to ZSNES just to reimplement POSIX functions that MSVC lacks that GCC on every single platform has.