Menu
▾
▴
zsnes-main
|
From: Ben F. <be...@ka...> - 2004-09-26 11:02:26
|
I'm trying to run zsnes with freevo, and for the life of me, I can't get
zsnes to actually load the games. Freevo calls it with the game as a
parameter, but zsnes just opens up its gui with the menu ready for you
to browse and load a game.
I even tried running zsnes manually under strace to see what was
happening, and it never even *tried* opening the file.
-- start strace --
ben@pluto ~ $ strace zsnes /home/ben/game.smc 2>&1 | grep smc
execve("/usr/games/bin/zsnes", ["zsnes", "/home/ben/game.smc"], [/* 50
vars */]) = 0
-- here is where it sat after zsnes loaded.
stat64("game.smc", {st_mode=S_IFREG|0644, st_size=3146240, ...}) = 0
stat64("game.smc", {st_mode=S_IFREG|0644, st_size=3146240, ...}) = 0
stat64("game.smc", {st_mode=S_IFREG|0644, st_size=3146240, ...}) = 0
-- and this is after I opened the open file dialog
open("game.smc", O_RDONLY) = 8
-- and here is it finally loading the game after I selected it.
Anybody know what's going on? I even cut+pasted the command line from
the damn help output and it did the same thing.
zsnes 1.36 & 1.37_pre20040920
gentoo linux
2.6.8.1 kernel
2 separate systems, one w/ reiserfs and one with jfs
-b
|
|
From: Jeremy B. <je...@br...> - 2004-09-26 17:05:46
|
Ben Ford wrote: > I'm trying to run zsnes with freevo, and for the life of me, I can't get > zsnes to actually load the games. Freevo calls it with the game as a > parameter, but zsnes just opens up its gui with the menu ready for you > to browse and load a game. > > I even tried running zsnes manually under strace to see what was > happening, and it never even *tried* opening the file. Have you tried checking out and compiling the code currently in CVS? I just did that and it seems to work correctly. When I do something like: bash$ zsnes /home/jeremy/downloads/roms/zelda3.smc.gz ...then ZSNES starts up and is playing Zelda 3. Is it possible Freevo is passing the wrong filename to ZSNES, or maybe not escaping it appropriately if it contains spaces? Can you give us a sample command that Freevo is using to try to run the ROM, along with the output of "ls -l $romfile"? The argument processing code for Linux ZSNES looks kinda kooky too. If you're a programmer type, you might take a glance at the file "zsnes/src/linux/zloaderw.c", particularly the main() function. Jeremy |
|
From: Ben F. <be...@ka...> - 2004-09-30 08:39:50
|
Jeremy Brown wrote: > Ben Ford wrote: > >> I'm trying to run zsnes with freevo, and for the life of me, I can't get >> zsnes to actually load the games. Freevo calls it with the game as a >> parameter, but zsnes just opens up its gui with the menu ready for you >> to browse and load a game. >> >> I even tried running zsnes manually under strace to see what was >> happening, and it never even *tried* opening the file. > > > > Have you tried checking out and compiling the code currently in CVS? > I just did that and it seems to work correctly. When I do something > like: I have not had time to check out CVS, but this has been a problem for at least the last 3 releases, including the 9/20 release. > bash$ zsnes /home/jeremy/downloads/roms/zelda3.smc.gz > > ...then ZSNES starts up and is playing Zelda 3. This is exactly the behaviour I want and am not getting. > Is it possible Freevo is passing the wrong filename to ZSNES, or maybe > not escaping it appropriately if it contains spaces? Can you give us > a sample command that Freevo is using to try to run the ROM, along > with the output of "ls -l $romfile"? Freevo is not the problem. I ran zsnes from the command line, exactly as you have above, no spaces or weird characters and it failed. zsnes game.smc zsnes ~/game.smc zsnes /home/ben/game.smc ls -l game.smc -rw-r--r-- 1 ben users 3146240 Sep 26 03:47 game.smc Nothing tweaky. It happens whether the smc file is gzipped or not. > The argument processing code for Linux ZSNES looks kinda kooky too. > If you're a programmer type, you might take a glance at the file > "zsnes/src/linux/zloaderw.c", particularly the main() function. If I have time someday. Last time I looked at it, it was a terrifying experience. -b |
|
From: Shawn <dr...@wa...> - 2004-09-30 18:06:41
|
On Thu, 2004-09-30 at 01:40 -0700, Ben Ford wrote: > > The argument processing code for Linux ZSNES looks kinda kooky too. > > If you're a programmer type, you might take a glance at the file > > "zsnes/src/linux/zloaderw.c", particularly the main() function. > > > If I have time someday. Last time I looked at it, it was a terrifying > experience. Actually, I'm the guilty person who wrote the Linux command parsing for zsnes. But, it uses getopt, and unless someone has drastically changed it since I wrote it, it shouldn't be *that bad*. It does work differently than the DOS / Win32 versions because of using getopt. I haven't looked at zsnes source in a long time though... -- Shawn <dr...@wa...> http://drevil.warpcore.org/ |
|
From: Jeremy B. <je...@br...> - 2004-09-30 18:57:53
|
Shawn wrote: >On Thu, 2004-09-30 at 01:40 -0700, Ben Ford wrote: > > >>>The argument processing code for Linux ZSNES looks kinda kooky too. >>>If you're a programmer type, you might take a glance at the file >>>"zsnes/src/linux/zloaderw.c", particularly the main() function. >>> >>> >>If I have time someday. Last time I looked at it, it was a terrifying >>experience. >> >> > >Actually, I'm the guilty person who wrote the Linux command parsing for >zsnes. But, it uses getopt, and unless someone has drastically changed >it since I wrote it, it shouldn't be *that bad*. It does work >differently than the DOS / Win32 versions because of using getopt. > >I haven't looked at zsnes source in a long time though... > > Yeah, at a second glance the argument processing code does look relatively simple. I just have no idea. It works for me. And zloaderw.c hasn't been touched in 11 months, so no recent activity would have fixed anything. Without being able to reproduce the problem, there's little I can do. Ben, you might still try peppering the code with some debug-flavored printf statements, in an effort to find out what's going on here...if the "load a file at start time" code is even being called at all, or if it's throwing an error of some sort. Jeremy |
|
From: Ben F. <be...@ka...> - 2004-10-04 09:28:08
|
> I just have no idea. It works for me. And zloaderw.c hasn't been
> touched in 11 months, so no recent activity would have fixed
> anything. Without being able to reproduce the problem, there's little
> I can do.
It's been broken for close to that length of time, apparently (from
other users in the forums with the same problem.)
> Ben, you might still try peppering the code with some debug-flavored
> printf statements, in an effort to find out what's going on here...if
> the "load a file at start time" code is even being called at all, or
> if it's throwing an error of some sort.
I gave it a precursory lookover. It doesn't appear that the code to
load the rom is ever loaded. If I comment out the if(optopt == '?')
condition as shown below, it loads the game fine. It does exit with an
invalid pointer warning though. What is the question mark supposed to
mean, anyways? Should it be NULL instead? From the limited getopt
knowledge I have, I don't this is strictly necessary, as the
if(argv[optind] != NULL) should take care of that.
ben@pluto ~/Projects $ diff -u zsnes/src/linux/zloaderw.c.orig
zsnes/src/linux/zloaderw.c
--- zsnes/src/linux/zloaderw.c.orig 2003-10-22 20:10:08.000000000 -0700
+++ zsnes/src/linux/zloaderw.c 2004-10-04 02:18:40.744794080 -0700
@@ -336,8 +336,8 @@
}
/* execute rom filename: file.x */
- if (optopt == '?')
- {
+// if (optopt == '?')
+// {
if (argv[optind] != NULL)
{
fvar=&fname;
@@ -345,7 +345,7 @@
strncpy(&fvar[1], argv[optind],127);
makeextension();
}
- }
+// }
zstart();
return 0;
-b
|
|
From: Ben F. <be...@ka...> - 2004-10-07 17:14:28
|
Ben Ford wrote:
> I gave it a precursory lookover. It doesn't appear that the code to
> load the rom is ever loaded. If I comment out the if(optopt == '?')
> condition as shown below, it loads the game fine. It does exit with
> an invalid pointer warning though. What is the question mark supposed
> to mean, anyways? Should it be NULL instead? From the limited getopt
> knowledge I have, I don't this is strictly necessary, as the
> if(argv[optind] != NULL) should take care of that.
Shawn, can you comment on this?
-b
>
> ben@pluto ~/Projects $ diff -u zsnes/src/linux/zloaderw.c.orig
> zsnes/src/linux/zloaderw.c
> --- zsnes/src/linux/zloaderw.c.orig 2003-10-22 20:10:08.000000000
> -0700
> +++ zsnes/src/linux/zloaderw.c 2004-10-04 02:18:40.744794080 -0700
> @@ -336,8 +336,8 @@
> }
>
> /* execute rom filename: file.x */
> - if (optopt == '?')
> - {
> +// if (optopt == '?')
> +// {
> if (argv[optind] != NULL)
> {
> fvar=&fname;
> @@ -345,7 +345,7 @@
> strncpy(&fvar[1], argv[optind],127);
> makeextension();
> }
> - }
> +// }
>
> zstart();
> return 0;
|
|
From: Jeremy B. <je...@br...> - 2004-10-07 17:33:28
|
Ben Ford wrote:
> Ben Ford wrote:
>
>> I gave it a precursory lookover. It doesn't appear that the code to
>> load the rom is ever loaded. If I comment out the if(optopt == '?')
>> condition as shown below, it loads the game fine. It does exit with
>> an invalid pointer warning though. What is the question mark
>> supposed to mean, anyways? Should it be NULL instead? From the
>> limited getopt knowledge I have, I don't this is strictly necessary,
>> as the if(argv[optind] != NULL) should take care of that.
>
> Shawn, can you comment on this?
I'll go ahead and comment, since I researched this a little bit.
The getopt(3) man page says:
If getopt() does not recognize an option character, it
prints an error message to stderr, stores the character in
optopt, and returns `?'. The calling program may prevent
the error message by setting opterr to 0.
If getopt() finds an option character in argv that was not
included in optstring, or if it detects a missing option
argument, it returns `?' and sets the external variable
optopt to the actual option character. If the first char-
acter of optstring is a colon (`:'), then getopt() returns
`:' instead of `?' to indicate a missing option argument.
If an error was detected, and the first character of opt-
string is not a colon, and the external variable opterr is
nonzero (which is the default), getopt() prints an error
message.
The manpage doesn't really specify when optopt will be set to '?' (other
than the condition where you actually have an option like "-?"), only
when getopt will return '?'. Maybe there's some condition not mentioned
in the manpage that the coder was testing for? Either way it does seem
like the code should read something more like:
case '?':
filename = argv[optind];
break;
...
if (filename)
{
...
makeextension();
}
zstart();
Maybe Shawn can clarify.
Jeremy
|
|
From: Shawn <dr...@wa...> - 2004-10-07 18:32:39
|
On Thu, 2004-10-07 at 10:15 -0700, Ben Ford wrote: > Ben Ford wrote: > > > I gave it a precursory lookover. It doesn't appear that the code to > > load the rom is ever loaded. If I comment out the if(optopt == '?') > > condition as shown below, it loads the game fine. It does exit with > > an invalid pointer warning though. What is the question mark supposed > > to mean, anyways? Should it be NULL instead? From the limited getopt > > knowledge I have, I don't this is strictly necessary, as the > > if(argv[optind] != NULL) should take care of that. > > > Shawn, can you comment on this? When I have a moment later tonight, I'll look into it. Thanks, -- Shawn <dr...@wa...> http://drevil.warpcore.org/ |
|
From: Shawn <dr...@wa...> - 2004-10-08 00:40:53
|
On Thu, 2004-10-07 at 10:15 -0700, Ben Ford wrote: > Ben Ford wrote: > > > I gave it a precursory lookover. It doesn't appear that the code to > > load the rom is ever loaded. If I comment out the if(optopt == '?') > > condition as shown below, it loads the game fine. It does exit with > > an invalid pointer warning though. What is the question mark supposed > > to mean, anyways? Should it be NULL instead? From the limited getopt > > knowledge I have, I don't this is strictly necessary, as the > > if(argv[optind] != NULL) should take care of that. > > > Shawn, can you comment on this? Yep. Okay, I just finished testing, reading through the code, and piecing together what I originally did. Here's the deal. Everything is working exactly like it's supposed to here: The code checks for the user *explicitly* passing a '-?' option to zsnes to determine whether or not to display the 'options help text'. If the user doesn't *explicitly* pass any option, optopt is set to '?' (should be anyway). Since optopt is set to '?', I know the user didn't pass any options. Now that I know the user didn't pass any options, I attempt to get a filename from the command line if they passed one in: If there is no filename, zsnes starts up normally and displays the file menu. If there is a filename, zsnes starts up and executes the specified ROM file. Now, I just tested this to make sure all of the above happens exactly like it's supposed to, and it does. My guess is that the getopt implementation on your system is somehow faulty, or is not behaving the same as the one I'm using. What Operating System and version of it are you using? -- Shawn <dr...@wa...> http://drevil.warpcore.org/ |
|
From: Ben F. <be...@ka...> - 2004-10-11 19:26:46
|
Shawn wrote: >On Thu, 2004-10-07 at 10:15 -0700, Ben Ford wrote: > > >>Ben Ford wrote: >> >> >> >>>I gave it a precursory lookover. It doesn't appear that the code to >>>load the rom is ever loaded. If I comment out the if(optopt == '?') >>>condition as shown below, it loads the game fine. It does exit with >>>an invalid pointer warning though. What is the question mark supposed >>>to mean, anyways? Should it be NULL instead? From the limited getopt >>>knowledge I have, I don't this is strictly necessary, as the >>>if(argv[optind] != NULL) should take care of that. >>> >>> >>Shawn, can you comment on this? >> >> > >Yep. Okay, I just finished testing, reading through the code, and >piecing together what I originally did. > >Here's the deal. Everything is working exactly like it's supposed to >here: > >The code checks for the user *explicitly* passing a '-?' option to zsnes >to determine whether or not to display the 'options help text'. If the >user doesn't *explicitly* pass any option, optopt is set to '?' (should >be anyway). Since optopt is set to '?', I know the user didn't pass any >options. > >Now that I know the user didn't pass any options, I attempt to get a >filename from the command line if they passed one in: > >If there is no filename, zsnes starts up normally and displays the file >menu. > >If there is a filename, zsnes starts up and executes the specified ROM >file. > >Now, I just tested this to make sure all of the above happens exactly >like it's supposed to, and it does. > >My guess is that the getopt implementation on your system is somehow >faulty, or is not behaving the same as the one I'm using. > >What Operating System and version of it are you using? > > > This is Gentoo with glibc 2.3.4.20040808 My guess is that the interface has changed slightly. When I commented out the ? check, everything worked fine. It would load a ROM and it would also display the help text. -b |
|
From: Shawn <dr...@wa...> - 2004-10-12 14:32:18
|
On Mon, 2004-10-11 at 12:27 -0700, Ben Ford wrote: > This is Gentoo with glibc 2.3.4.20040808 > > My guess is that the interface has changed slightly. When I commented > out the ? check, everything worked fine. It would load a ROM and it > would also display the help text. Well, you'll have to live with doing that I guess for now. Because doing what you've done breaks on other distributions (at least mine anyway...), and since showing the help text while loading the ROM isn't supposed to happen :) Are you sure freevo is passing legitimate options (i.e. all options are valid)? When I'm feeling suicidal, I'll install Gentoo and try that if you can't find something else :) -- Shawn <dr...@wa...> http://drevil.warpcore.org/ |
|
From: Ben F. <be...@ka...> - 2004-10-12 19:06:54
|
Shawn wrote: >On Mon, 2004-10-11 at 12:27 -0700, Ben Ford wrote: > > >>This is Gentoo with glibc 2.3.4.20040808 >> >>My guess is that the interface has changed slightly. When I commented >>out the ? check, everything worked fine. It would load a ROM and it >>would also display the help text. >> >> > >Well, you'll have to live with doing that I guess for now. Because doing >what you've done breaks on other distributions (at least mine >anyway...), and since showing the help text while loading the ROM isn't >supposed to happen :) > > Err, poor wording on my part. It worked exactly as expected. When you passed a filename, it loaded, when you passed a ?, it displayed the help. >Are you sure freevo is passing legitimate options (i.e. all options are >valid)? > > Ignore the part about Freevo, I'm running it from the command line until the problem is solved. >When I'm feeling suicidal, I'll install Gentoo and try that if you can't >find something else :) > > When I've got a little time for debugging, I'll step thru it and see what the variables are and why that check is failing. -b |
|
From: Ben F. <be...@ka...> - 2004-10-27 22:54:35
|
Shawn wrote: >On Thu, 2004-10-07 at 10:15 -0700, Ben Ford wrote: > > >>Ben Ford wrote: >> >> >> >>>I gave it a precursory lookover. It doesn't appear that the code to >>>load the rom is ever loaded. If I comment out the if(optopt == '?') >>>condition as shown below, it loads the game fine. It does exit with >>>an invalid pointer warning though. What is the question mark supposed >>>to mean, anyways? Should it be NULL instead? From the limited getopt >>>knowledge I have, I don't this is strictly necessary, as the >>>if(argv[optind] != NULL) should take care of that. >>> >>> >>Shawn, can you comment on this? >> >> > >Yep. Okay, I just finished testing, reading through the code, and >piecing together what I originally did. > >Here's the deal. Everything is working exactly like it's supposed to >here: > >The code checks for the user *explicitly* passing a '-?' option to zsnes >to determine whether or not to display the 'options help text'. If the >user doesn't *explicitly* pass any option, optopt is set to '?' (should >be anyway). Since optopt is set to '?', I know the user didn't pass any >options. > > This useage is not correct. If it works, it is due to an undocumented oddity in the glibc version you are using. From the man page (http://www.frech.ch/man/man3p/optopt.3p.html): If /getopt/() encounters an option character that is not contained in /optstring/, it shall return the question-mark ( *'?'* ) character. If it detects a missing option-argument, it shall return the colon character ( *':'* ) if the first character of /optstring/ was a colon, or a question- mark character ( *'?'* ) otherwise. In either case, /getopt/() shall set the variable /optopt/ to the option character that caused the error. If the application has not set the variable /opterr/ to 0 and the first character of /optstring/ is not a colon, /getopt/() shall also print a diagnostic message to /stderr/ in the format specified for the /getopts/ utility. This is the only mention of optopt. Try this patch: ben@pluto ~/Projects/zsnes/src/linux $ diff zloaderw.c* -u --- zloaderw.c 2003-10-22 20:10:08.000000000 -0700 +++ zloaderw.c.new 2004-10-27 15:32:30.000000000 -0700 @@ -336,15 +336,14 @@ } /* execute rom filename: file.x */ - if (optopt == '?') + /* getopt permutates argv until all non options are at the end of argv. */ + /* since we only expect one non option, it should be the last argument. */ + if ( optind == argc - 1 && argv[optind] != NULL) { - if (argv[optind] != NULL) - { - fvar=&fname; - fvar[0] = strlen(argv[optind]); - strncpy(&fvar[1], argv[optind],127); - makeextension(); - } + fvar=&fname; + fvar[0] = strlen(argv[optind]); + strncpy(&fvar[1], argv[optind],127); + makeextension(); } zstart(); (and off the subject, why use Pascal style strings?) -b |
|
From: Shawn <cul...@wa...> - 2004-10-27 23:14:23
|
Ben Ford wrote: > This useage is not correct. If it works, it is due to an undocumented > oddity in the glibc version you are using. It was at the time I wrote it, but it's been years since I wrote it :) And shockingly, this 'undocumented' oddity has worked all those years on several different Linux distributions. But, I digress. :) > From the man page (http://www.frech.ch/man/man3p/optopt.3p.html): > > If /getopt/() encounters an option character that is not > contained in > /optstring/, it shall return the question-mark ( *'?'* ) > character. If it > detects a missing option-argument, it shall return the colon > character > ( *':'* ) if the first character of /optstring/ was a colon, or a > question- > mark character ( *'?'* ) otherwise. In either case, /getopt/() > shall set > the variable /optopt/ to the option character that caused the > error. If > the application has not set the variable /opterr/ to 0 and > the first > character of /optstring/ is not a colon, /getopt/() shall also > print a > diagnostic message to /stderr/ in the format specified for the > /getopts/ > utility. > > This is the only mention of optopt. > > Try this patch: When I get a chance later this week, I'll try it out and let you know what works for me. Hey, if it fixes your problem and still works here, then I say go for it! Thanks for taking the time to further research the issue you were having. As far as the pascal style strings? Well, I just added command line option parsing, and I probably just did what others were doing in the Windows / DOS code :) Or, I was young and needed the money, whichever sounds more believeable :D Thanks, -Shawn |
Thanks for helping keep SourceForge clean.
X