ZSNES board

[gblues]

Hmm, well I discovered a couple issues with my work:

1) My build dynamically links with msvcrt9.dll which means it will fail spectacularly on systems that don't already have it.

2) Even with the appropriate runtime library, it doesn't work at all in XP, despite my attempts to preserve XP compatibility.

I resolved #1 by updating the project settings (also had to rebuild zlib1.lib and libpng.lib) for statically linking libcmt.lib.

#2 I am working on now; my XP laptop is not a convenient testbed, but I have access to XP Pro through school so I am going to try Virtual PC + XP Pro. Here's hoping the DirectX calls don't fail miserably inside VPC. :\

[gblues]

Well, DirectX didn't fail, although it doesn't capture the mouse properly inside VPC.

I found the source of the problem--turns out the dynamic linking wants to resolve all symbols referenced, even if they're never actually called. Yeah, this is my first foray into this kind of thing, shut up. Anyway, I resolved it by extracting the function pointer inside useKnownFolders() and referencing the function pointer at runtime.

It now works like a champ in XP. I've re-re-uploaded the archive:

http://www.strong-consultants.com/zsnes2008.zip

[kode54]

What is the difference between SHGetKnownFolderPath and SHGetFolderPath, other than the former requiring Vista?

[gblues]

[gblues]

So now that I have my code working, I am now attempting to merge it back in to the main codebase in a way that does not break the Linux and MS-DOS builds. To that end, I've put together a Virtual PC environment running Ubuntu 9.10. I also had to bring in code changes from this thread to get it to build and run correctly.

I think the simplest way to do it is going to be to use MSVC's TEXT() macro which will dynamically change a literal string from multibyte to wide char depending on if the macro UNICODE is defined. MSVC sets the UNICODE setting based on the character set specified in the project file; other OSs that want/need to use wchar_t can simply add -DUNICODE to the compile flags. In the same manner, I'll probably change char * to LPSTR or something similar, so that LPSTR can be defined as wchar_t transparently. This avoids cluttering every function with a bunch of #ifdefs.

I will then wrap the various path handling code in #ifdef UNICODE blocks and ensure there are char * versions and wchar_t * versions defined accordingly.

I'm also doing a little code cleanup, like making sure certain definitions are only done once, and using full macro wrappers for the POSIX functions (to quell MSVC's compiler warnings) instead of using the potentially hazardous method of "#define strncmp _strncmp".

I'm exploring this approach, as opposed to making everything wchar_t internally and using mbstowcs()/wcstombs() because I'm pretty sure trying to use wchar_t paths in DOS is a waste of time.

[Nach]

Sorry for the late reply to this thread, I haven't been around much as of late. We've had a patch which is better than this one in our developer tree for well over a year. If it is indeed an issue, I can see about backporting some of our patches and putting out a new release.
_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding

[gblues]

Yeah, the patch in the OP isn't the best, although it is functional. I'm working on something more portable--putting path-related string literals into MSVC's TEXT() macro (and porting the TEXT() macro for DOS/Linux) and then using an "#ifdef UNICODE" test to choose between char * and wchar_t* versions of the path code.

I've finally got ZSNES compiling successfully in DOS and Linux via VirtualPC! I hope to have v. 2.0 of the patch done within the next couple weeks.

[Nach]

[gblues]

[byuu]

Yeah, even if it's in SVN, it'll be helpful until the next official release is out for some.