system() always returns 0?

Discussion in 'C Programming' started by barry, Jun 1, 2010.

  1. barry

    barry Guest

    Has anyone encountered a problem with the Microsoft C 5.0 compiler always
    returning a 0 from the system() call, no matter what the actual command
    executed by system() returns?

    Is there a fix for this or am i misunderstanding something fundamental
    about
    the way the system() call works in msc5.0? (Like the command.com always
    returning the 0, which system(), in turn, returns to my program?)

    I'm trying to determine whether or not the executed command succeeded or
    not by
    looking at the completion code from system, ala:

    char buf[BUFSIZ];

    sprintf(buf,"rnews < D_elricf.3aa");
    if (!system(buf)) perror(buf);

    and i'm having a hard time of it since system() always (seems) to return
    0!
     
    barry, Jun 1, 2010
    #1
    1. Advertising

  2. barry <> writes:
    > Has anyone encountered a problem with the Microsoft C 5.0 compiler always
    > returning a 0 from the system() call, no matter what the actual command
    > executed by system() returns?
    >
    > Is there a fix for this or am i misunderstanding something fundamental
    > about
    > the way the system() call works in msc5.0? (Like the command.com always
    > returning the 0, which system(), in turn, returns to my program?)
    >
    > I'm trying to determine whether or not the executed command succeeded or
    > not by
    > looking at the completion code from system, ala:
    >
    > char buf[BUFSIZ];
    >
    > sprintf(buf,"rnews < D_elricf.3aa");
    > if (!system(buf)) perror(buf);
    >
    > and i'm having a hard time of it since system() always (seems) to return
    > 0!


    <joke>But 0! is 1.</joke>

    How sure are you that "rnews < D_elricf.3aa" is returning a
    non-zero status? It might just be a problem with rnews command.
    If so, there's not much that system() can do about it.

    All the standard says about this is:

    If the argument is not a null pointer, and the system function
    does return, it returns an implementation-defined value.

    It may be reasonable to assume, on your particular implementation,
    that the result returned by system() is related to the exit status
    of the invoked program. But you should check your implementation's
    documentation. The input redirection might have some effect on the
    handling of the exit status; for example, I can imagine that you
    might be getting the status of the command processor that invoked
    the command "rnews < D_elricf.3aa" rather than the status of the
    "rnews" command.

    If there is a problem with your implementation's system()
    function, you'll need to ask about it in a forum that deals with
    your implementation, perhaps comp.os.ms-windows.programmer.win32
    or one of the microsoft.* groups.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 1, 2010
    #2
    1. Advertising

  3. In article <hu37hs$c41$>, barry <> wrote:
    >Has anyone encountered a problem with the Microsoft C 5.0 compiler always
    >returning a 0 from the system() call, no matter what the actual command
    >executed by system() returns?
    >
    >Is there a fix for this or am i misunderstanding something fundamental
    >about the way the system() call works in msc5.0? (Like the command.com
    >always returning the 0, which system(), in turn, returns to my
    >program?)


    Kiki has already given you the "CLC standard" answer, which is, of
    course, a) entirely correct in all its particulars and b) entirely
    useless.

    Now, onto a (hopefully) useful answer. As far as I know, this has never
    worked correctly (for suitable assumptions about what "correct" means)
    under DOS/Windows. I.e., the returned value returned by
    COMMAND.COM/CMD.EXE/whateverElseFromMS tells you only that COMMAND.COM
    itself succeeded (which is true 99.999999% of the time). This behavior
    is unlikely to ever change in the Windows product line.

    In Unix, it does work correctly - that is, sh "passes down" the value
    returned by the command:

    $ sh -c 'ls ksdfjh';echo $?
    ls: ksdfjh: No such file or directory
    1
    $

    P.S. Once, a long, long time ago, I wrote a DOS device driver to
    address this problem. It was a little "hinky", but it did work. Was
    rather cool, in its own little way.

    P.P.S. The FGA for this sort of problem is to somehow hack the command
    line that you run so that it indicates the status in some "out of band"
    way, such as:

    system("yourcommand & if errorlevel 1 echo Failed > atmpfile");

    Note that in Unix, you could do: echo $? > atmpfile, but the seemingly
    equivalent DOS syntax (%errorlevel%) just doesn't quite do it...

    HTH

    --
    Just for a change of pace, this sig is *not* an obscure reference to
    comp.lang.c...
     
    Kenny McCormack, Jun 1, 2010
    #3
  4. barry

    sandeep Guest

    Kenny McCormack writes:
    > In article <hu37hs$c41$>, barry <>
    > wrote:
    >>Has anyone encountered a problem with the Microsoft C 5.0 compiler
    >>always returning a 0 from the system() call, no matter what the actual
    >>command executed by system() returns?
    >>
    >>Is there a fix for this or am i misunderstanding something fundamental
    >>about the way the system() call works in msc5.0? (Like the command.com
    >>always returning the 0, which system(), in turn, returns to my program?)

    >
    > Kiki has already given you the "CLC standard" answer, which is, of
    > course, a) entirely correct in all its particulars and b) entirely
    > useless.
    >
    > Now, onto a (hopefully) useful answer. As far as I know, this has never
    > worked correctly (for suitable assumptions about what "correct" means)
    > under DOS/Windows. I.e., the returned value returned by
    > COMMAND.COM/CMD.EXE/whateverElseFromMS tells you only that COMMAND.COM
    > itself succeeded (which is true 99.999999% of the time). This behavior
    > is unlikely to ever change in the Windows product line.
    >
    > In Unix, it does work correctly - that is, sh "passes down" the value
    > returned by the command:
    >
    > $ sh -c 'ls ksdfjh';echo $?
    > ls: ksdfjh: No such file or directory 1
    > $
    >
    > P.S. Once, a long, long time ago, I wrote a DOS device driver to
    > address this problem. It was a little "hinky", but it did work. Was
    > rather cool, in its own little way.
    >
    > P.P.S. The FGA for this sort of problem is to somehow hack the command
    > line that you run so that it indicates the status in some "out of band"
    > way, such as:
    >
    > system("yourcommand & if errorlevel 1 echo Failed > atmpfile");
    >
    > Note that in Unix, you could do: echo $? > atmpfile, but the seemingly
    > equivalent DOS syntax (%errorlevel%) just doesn't quite do it...
    >
    > HTH


    No waranties expressed or implied, use at own risk, etc.

    I've been using these patches for years with no problems. Source (sort
    of)
    is included for those worried about virus problems.

    (This is from a make package some friends and I wrote a while ago--ignore
    any
    references to make that didn't get edited out.)

    -------------------------------------------------
    COMMAND.COM patch to return ERRORLEVEL from child
    _________________________________________________

    There is a feature (bug) in COMMAND.COM that causes MAKE not to be able to
    detect when commands that involve redirection fail. This is because MAKE
    executes these commands using a sub-shell and the sub-shell does not
    return
    the exit code of the command it executed.

    What follow are patches for COMMAND.COM version 2.11 (MS only) and
    versions
    3.20 and 3.30 (MS and IBM versions).

    ______________________________________________________________________________

    Patch to return ERRORLEVEL as exit code when COMMAND.COM terminates.
    Note that in 3.20 and 3.30, ERRORLEVEL is already returned correctly when
    a
    sub-shell is terminated with the EXIT command. This patch does not cause
    built-in commands (DEL, etc.) to return failure exit codes.

    This patch is valid for MSDOS version 2.11. THIS IS NOT VALID FOR PCDOS!

    0220: B8 00 4C CD 21 MS-DOS 2.11
    0AC0: 00 00 00 00 00 00 00 00 COMMAND.COM
    19C0: 06 8E 06 BA 2C 26 A1 35 08 26 A3 16 00 07
    19D0: 8E 06 BC 2C B4 49 CD 21 B8 00 4C CD 21

    0220: E9 9D 08 90 90 2.11 Patch
    0AC0: B4 4C 2E A0 75 08 CD 21
    19C0: 8E 06 BA 2C 06 B8 C8 0A 50 26 A1 35 08 26
    19D0: A3 16 00 8E 06 BC 2C B4 49 CD 21 CB 90
    _________________________________________________________

    This patch is valid for MSDOS and PCDOS version 3.20.

    0210: A1 9C 0A 2E A3 16 00 A1 9E 0A 2E A3 0A 00 A1 A0 3.20
    COMMAND.COM
    0220: 0A 2E A3 0C 00 B8 00 4C

    0210: 0E 07 FC BE 9C 0A AD 26 A3 16 00 BF 0A 00 A5 A5 3.20 Patch
    0220: A0 FA 0A B4 4C 90 90 90
    _________________________________________________________

    This patch is valid for MSDOS and PCDOS version 3.30.

    023A: A1 8C 0B 2E A3 16 3.30
    COMMAND.COM
    0240: 00 A1 8E 0B 2E A3 0A 00 A1 90 0B 2E A3 0C 00 B8
    0250: 00 4C

    023A: 0E 07 FC BE 8C 0B 3.30 Patch
    0240: AD 26 A3 16 00 BF 0A 00 A5 A5 B4 4C A0 EA 0B 90
    0250: 90 90
    ______________________________________________________________________________

    MS-DOS 2.11 COMMAND.COM

    0228 B8004C MOV AX,4C00 ; "/C" termination
    022B CD21 INT 21

    19C2 06 PUSH ES ; "EXIT" command processor
    19C3 8E06BA2C MOV ES,[2CBA] ; in transient section
    19C7 26A13508 MOV AX,ES:[0835]
    19CB 26A31600 MOV ES:[0016],AX
    19CF 07 POP ES
    19D0 8E06BC2C MOV ES,[2CBC]
    19D4 B449 MOV AH,49
    19D6 CD21 INT 21
    19D8 B8004C MOV AX,4C00
    19DB CD21 INT 21
    ____________________________________________

    MS-DOS 2.11 Patch

    0228 E99D08 JMP 0AC8 ; "/C" termination -- jump to
    022B 90 NOP ; exit patch
    022C 90 NOP

    0AC8 B44C MOV AH,4C ; terminate process with exit
    0ACA 2EA07508 MOV AL,CS:[0875] ; code set to ERRORLEVEL
    0ACE CD21 INT 21

    19C2 8E06BA2C MOV ES,[2CBA] ; "EXIT" command in overlay
    19C6 06 PUSH ES
    19C7 B8C80A MOV AX,0AC8 ; put address of exit patch in
    19CA 50 PUSH AX ; root on stack
    19CB 26A13508 MOV AX,ES:[0835]
    19CF 26A31600 MOV ES:[0016],AX
    19D3 8E06BC2C MOV ES,[2CBC]
    19D7 B449 MOV AH,49
    19D9 CD21 INT 21
    19DB CB RETF ; jump to exit patch
    19DC 90 NOP
    ______________________________________________________________________________

    0210 A19C0A MOV AX,[0A9C] ; MSDOS COMMAND.COM
    3.20
    0213 2EA31600 MOV CS:[0016],AX
    0217 A19E0A MOV AX,[0A9E] ; "/C" termination
    021A 2EA30A00 MOV CS:[000A],AX
    021E A1A00A MOV AX,[0AA0]
    0221 2EA30C00 MOV CS:[000C],AX
    0225 B8004C MOV AX,4C00
    0228 CD21 INT 21

    2728 B44C MOV AH,4C ; "EXIT" command termination
    272A 26A0FA0A MOV AL,ES:[0AFA]
    272E CD21 INT 21
    ____________________________________________

    0210 0E PUSH CS ; 3.20 Patch
    0211 07 POP ES
    0212 FC CLD
    0213 BE9C0A MOV SI,0A9C
    0216 AD LODSW
    0217 26A31600 MOV ES:[0016],AX
    021B BF0A00 MOV DI,000A
    021E A5 MOVSW
    021F A5 MOVSW
    0220 A0FA0A MOV AL,[0AFA]
    0223 B44C MOV AH,4C
    0225 90 NOP
    0226 90 NOP
    0227 90 NOP
    0228 CD21 INT 21
    ______________________________________________________________________________

    023A A18C0B MOV AX,[0B8C] ; MS-DOS COMMAND.COM
    3.30
    023D 2EA31600 MOV CS:[0016],AX
    0241 A18E0B MOV AX,[0B8E] ; "/C" termination
    0244 2EA30A00 MOV CS:[000A],AX
    0248 A1900B MOV AX,[0B90]
    024B 2EA30C00 MOV CS:[000C],AX
    024F B8004C MOV AX,4C00
    0252 CD21 INT 21

    2CE8 B44C MOV AH,4C ; "EXIT" command termination
    2CEA 26A0EA0B MOV AL,ES:[0BEA]
    2CEE CD21 INT 21
    __________________________________________

    023A 0E PUSH CS ; 3.30 Patch
    023B 07 POP ES
    023C FC CLD
    023D BE8C0B MOV SI,0B8C
    0240 AD LODSW
    0241 26A31600 MOV ES:[0016],AX
    0245 BF0A00 MOV DI,000A
    0248 A5 MOVSW
    0249 A5 MOVSW
    024A B44C MOV AH,4C
    024C A0EA0B MOV AL,[0BEA]
    024F 90 NOP
    0250 90 NOP
    0251 90 NOP
    0252 CD21 INT 21

    ------------------------------------------
     
    sandeep, Jun 1, 2010
    #4
  5. barry

    Richard Bos Guest

    barry <> wrote:

    > Has anyone encountered a problem with the Microsoft C 5.0 compiler always
    > returning a 0 from the system() call, no matter what the actual command
    > executed by system() returns?


    I don't know if this is still true, but at least in the MS-DOS days it
    was not system() which had the problem, but the command shell.
    Command.com always returned 0 to _its_ calling process, no matter what a
    called program returned to command.com. Thus, regardless of the
    implementation, system() never got anything but 0 to return to you in
    the first place. The compiler writer would have had to implement a
    completely new command shell to load and run programs, which was a bit
    too hairy for most to bother with.

    Richard
     
    Richard Bos, Jun 1, 2010
    #5
  6. barry

    Gene Guest

    On Jun 1, 11:04 am, barry <> wrote:
    > Has anyone encountered a problem with the Microsoft C 5.0 compiler always
    > returning a 0 from the system() call, no matter what the actual command
    > executed by system() returns?
    >
    > Is there a fix for this or am i misunderstanding something fundamental
    > about
    > the way the system() call works in msc5.0?  (Like the command.com always
    > returning the 0, which system(), in turn, returns to my program?)
    >
    > I'm trying to determine whether or not the executed command succeeded or
    > not by
    > looking at the completion code from system, ala:
    >
    >         char buf[BUFSIZ];
    >
    >         sprintf(buf,"rnews < D_elricf.3aa");
    >         if (!system(buf)) perror(buf);
    >
    > and i'm having a hard time of it since system() always (seems) to return
    > 0!


    I ran into this once and frankly can't remember how I fixed it. I do
    remember it was ugly. I believe I ended up calling exeve() directly.
    Of course you'll have to implement the file redirection yourself if
    you do this. But I ran across this recently:
    https://briandamaged.org/blog/?p=179
    It might offer a solution in the form of a 2-line script that runs a
    command and then causes the shell to exit with the current errorlevel
    as its return value.

    Good luck.
     
    Gene, Jun 1, 2010
    #6
  7. barry

    barry Guest

    hi can anyone explain how to apply this patch thanks

    sandeep wrote:
    Kenny McCormack writes:
    >> In article <hu37hs$c41$>, barry <>
    >> wrote:
    >>>Has anyone encountered a problem with the Microsoft C 5.0 compiler
    >>>always returning a 0 from the system() call, no matter what the actual
    >>>command executed by system() returns?
    >>>
    >>>Is there a fix for this or am i misunderstanding something fundamental
    >>>about the way the system() call works in msc5.0? (Like the command.com
    >>>always returning the 0, which system(), in turn, returns to my
    >>>program?)

    >>
    >> Kiki has already given you the "CLC standard" answer, which is, of
    >> course, a) entirely correct in all its particulars and b) entirely
    >> useless.
    >>
    >> Now, onto a (hopefully) useful answer. As far as I know, this has
    >> never worked correctly (for suitable assumptions about what "correct"
    >> means) under DOS/Windows. I.e., the returned value returned by
    >> COMMAND.COM/CMD.EXE/whateverElseFromMS tells you only that COMMAND.COM
    >> itself succeeded (which is true 99.999999% of the time). This behavior
    >> is unlikely to ever change in the Windows product line.
    >>
    >> In Unix, it does work correctly - that is, sh "passes down" the value
    >> returned by the command:
    >>
    >> $ sh -c 'ls ksdfjh';echo $?
    >> ls: ksdfjh: No such file or directory 1
    >> $
    >>
    >> P.S. Once, a long, long time ago, I wrote a DOS device driver to
    >> address this problem. It was a little "hinky", but it did work. Was
    >> rather cool, in its own little way.
    >>
    >> P.P.S. The FGA for this sort of problem is to somehow hack the command
    >> line that you run so that it indicates the status in some "out of band"
    >> way, such as:
    >>
    >> system("yourcommand & if errorlevel 1 echo Failed > atmpfile");
    >>
    >> Note that in Unix, you could do: echo $? > atmpfile, but the seemingly
    >> equivalent DOS syntax (%errorlevel%) just doesn't quite do it...
    >>
    >> HTH


    No waranties expressed or implied, use at own risk, etc.

    I've been using these patches for years with no problems. Source (sort
    of)
    is included for those worried about virus problems.

    (This is from a make package some friends and I wrote a while
    ago--ignore any
    references to make that didn't get edited out.)

    -------------------------------------------------
    COMMAND.COM patch to return ERRORLEVEL from child
    _________________________________________________

    There is a feature (bug) in COMMAND.COM that causes MAKE not to be able
    to detect when commands that involve redirection fail. This is because
    MAKE executes these commands using a sub-shell and the sub-shell does
    not return
    the exit code of the command it executed.

    What follow are patches for COMMAND.COM version 2.11 (MS only) and
    versions
    3.20 and 3.30 (MS and IBM versions).


    ______________________________________________________________________________

    Patch to return ERRORLEVEL as exit code when COMMAND.COM terminates.
    Note that in 3.20 and 3.30, ERRORLEVEL is already returned correctly
    when a
    sub-shell is terminated with the EXIT command. This patch does not
    cause built-in commands (DEL, etc.) to return failure exit codes.

    This patch is valid for MSDOS version 2.11. THIS IS NOT VALID FOR
    PCDOS!

    0220: B8 00 4C CD 21 MS-DOS 2.11
    0AC0: 00 00 00 00 00 00 00 00 COMMAND.COM
    19C0: 06 8E 06 BA 2C 26 A1 35 08 26 A3 16 00 07 19D0: 8E 06
    BC 2C B4 49 CD 21 B8 00 4C CD 21

    0220: E9 9D 08 90 90 2.11 Patch
    0AC0: B4 4C 2E A0 75 08 CD 21 19C0:
    8E 06 BA 2C 06 B8 C8 0A 50 26 A1 35 08 26 19D0: A3 16 00 8E 06 BC
    2C B4 49 CD 21 CB 90
    _________________________________________________________

    This patch is valid for MSDOS and PCDOS version 3.20.

    0210: A1 9C 0A 2E A3 16 00 A1 9E 0A 2E A3 0A 00 A1 A0 3.20
    COMMAND.COM
    0220: 0A 2E A3 0C 00 B8 00 4C

    0210: 0E 07 FC BE 9C 0A AD 26 A3 16 00 BF 0A 00 A5 A5 3.20 Patch
    0220: A0 FA 0A B4 4C 90 90 90
    _________________________________________________________

    This patch is valid for MSDOS and PCDOS version 3.30.

    023A: A1 8C 0B 2E A3 16 3.30
    COMMAND.COM
    0240: 00 A1 8E 0B 2E A3 0A 00 A1 90 0B 2E A3 0C 00 B8 0250: 00 4C

    023A: 0E 07 FC BE 8C 0B 3.30 Patch
    0240: AD 26 A3 16 00 BF 0A 00 A5 A5 B4 4C A0 EA 0B 90 0250: 90 90

    ______________________________________________________________________________

    MS-DOS 2.11 COMMAND.COM

    0228 B8004C MOV AX,4C00 ; "/C" termination 022B CD21
    INT 21

    19C2 06 PUSH ES ; "EXIT" command processor
    19C3 8E06BA2C MOV ES,[2CBA] ; in transient section 19C7
    26A13508 MOV AX,ES:[0835] 19CB 26A31600 MOV
    ES:[0016],AX 19CF 07 POP ES
    19D0 8E06BC2C MOV ES,[2CBC] 19D4 B449 MOV AH,49
    19D6 CD21 INT 21
    19D8 B8004C MOV AX,4C00
    19DB CD21 INT 21
    ____________________________________________

    MS-DOS 2.11 Patch

    0228 E99D08 JMP 0AC8 ; "/C" termination -- jump
    to 022B 90 NOP ; exit patch 022C 90
    NOP

    0AC8 B44C MOV AH,4C ; terminate process with
    exit 0ACA 2EA07508 MOV AL,CS:[0875] ; code set to
    ERRORLEVEL 0ACE CD21 INT 21

    19C2 8E06BA2C MOV ES,[2CBA] ; "EXIT" command in overlay
    19C6 06 PUSH ES
    19C7 B8C80A MOV AX,0AC8 ; put address of exit patch
    in 19CA 50 PUSH AX ; root on stack 19CB
    26A13508 MOV AX,ES:[0835] 19CF 26A31600 MOV
    ES:[0016],AX 19D3 8E06BC2C MOV ES,[2CBC] 19D7 B449
    MOV AH,49
    19D9 CD21 INT 21
    19DB CB RETF ; jump to exit patch 19DC 90
    NOP

    ______________________________________________________________________________

    0210 A19C0A MOV AX,[0A9C] ; MSDOS COMMAND.COM
    3.20
    0213 2EA31600 MOV CS:[0016],AX 0217 A19E0A MOV
    AX,[0A9E] ; "/C" termination 021A 2EA30A00 MOV
    CS:[000A],AX 021E A1A00A MOV AX,[0AA0] 0221 2EA30C00
    MOV CS:[000C],AX 0225 B8004C MOV AX,4C00
    0228 CD21 INT 21

    2728 B44C MOV AH,4C ; "EXIT" command termination
    272A 26A0FA0A MOV AL,ES:[0AFA] 272E CD21 INT 21
    ____________________________________________

    0210 0E PUSH CS ; 3.20 Patch 0211 07
    POP ES
    0212 FC CLD
    0213 BE9C0A MOV SI,0A9C
    0216 AD LODSW
    0217 26A31600 MOV ES:[0016],AX 021B BF0A00 MOV
    DI,000A
    021E A5 MOVSW
    021F A5 MOVSW
    0220 A0FA0A MOV AL,[0AFA] 0223 B44C MOV AH,4C
    0225 90 NOP
    0226 90 NOP
    0227 90 NOP
    0228 CD21 INT 21

    ______________________________________________________________________________

    023A A18C0B MOV AX,[0B8C] ; MS-DOS COMMAND.COM
    3.30
    023D 2EA31600 MOV CS:[0016],AX 0241 A18E0B MOV
    AX,[0B8E] ; "/C" termination 0244 2EA30A00 MOV
    CS:[000A],AX 0248 A1900B MOV AX,[0B90] 024B 2EA30C00
    MOV CS:[000C],AX 024F B8004C MOV AX,4C00
    0252 CD21 INT 21

    2CE8 B44C MOV AH,4C ; "EXIT" command termination
    2CEA 26A0EA0B MOV AL,ES:[0BEA] 2CEE CD21 INT 21
    __________________________________________

    023A 0E PUSH CS ; 3.30 Patch 023B 07
    POP ES
    023C FC CLD
    023D BE8C0B MOV SI,0B8C
    0240 AD LODSW
    0241 26A31600 MOV ES:[0016],AX 0245 BF0A00 MOV
    DI,000A
    0248 A5 MOVSW
    0249 A5 MOVSW
    024A B44C MOV AH,4C
    024C A0EA0B MOV AL,[0BEA] 024F 90 NOP
    0250 90 NOP
    0251 90 NOP
    0252 CD21 INT 21

    ------------------------------------------
     
    barry, Jun 1, 2010
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. feng

    IsPostBack always returns False

    feng, Dec 9, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    572
    Jose L Rodriguez
    Dec 9, 2003
  2. Jon Davis
    Replies:
    1
    Views:
    400
    Jon Davis
    Jan 27, 2004
  3. Jon Davis
    Replies:
    3
    Views:
    485
    Jon Davis
    Jan 27, 2004
  4. Deryck
    Replies:
    4
    Views:
    519
    derek giroulle
    Jun 22, 2004
  5. Neel
    Replies:
    21
    Views:
    2,347
    Default User
    Feb 15, 2006
Loading...

Share This Page