Embarcadero C/C++ Compiler available

Discussion in 'C Programming' started by Mel Smith, May 3, 2013.

  1. Mel Smith

    Mel Smith Guest

    Hi:

    If you would like to test/try out the new 'Borland' C/C++ Compiler
    (from Embarcadero) BCC 6.6.0, there is a link below.

    This console-only compiler was extracted from the C++ Builder package
    XE4

    http://www.mediafire.com/?655px1guh9z5isy

    --
    Mel Smith
     
    Mel Smith, May 3, 2013
    #1
    1. Advertising

  2. "Mel Smith" <> writes:
    > If you would like to test/try out the new 'Borland' C/C++ Compiler
    > (from Embarcadero) BCC 6.6.0, there is a link below.
    >
    > This console-only compiler was extracted from the C++ Builder package
    > XE4
    >
    > http://www.mediafire.com/?[DELETED]


    Embarcadero offers a free 30-day trial of C++ Builder, which appears not
    to be free software. I believe the above link is a copyright violation.

    And I see no mention of C on their web page (perhaps I just didn't find
    it), so it's not even clear this is topical.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 3, 2013
    #2
    1. Advertising

  3. Mel Smith

    Mel Smith Guest

    Keith said:
    > Embarcadero offers a free 30-day trial of C++ Builder, which appears not
    > to be free software. I believe the above link is a copyright violation.


    BullPucky ! Embarcadero is aware of this, and encourages it.
    >
    > And I see no mention of C on their web page (perhaps I just didn't find
    > it)


    No, its not advertisedf, just provided.

    >, so it's not even clear this is topical.


    a C-Language compiler is *not topical* ?!?

    In my own news group, thoudsands of us use their BCC offerings:
    including BCC5.8, BCC 6.5, and BCC 6.6.0

    We don't sell it, only use it to compile our apps.


    -Mel
     
    Mel Smith, May 4, 2013
    #3
  4. "Mel Smith" <> writes:
    > Keith said:
    >> Embarcadero offers a free 30-day trial of C++ Builder, which appears not
    >> to be free software. I believe the above link is a copyright violation.

    >
    > BullPucky ! Embarcadero is aware of this, and encourages it.


    Perhaps you could provide some evidence of that. (That doesn't imply
    that I disbelieve you.) If they're willing to allow their compiler to
    be distributed for free, I wonder why they don't just do it themselves.
    Or do they? If so, I'd frankly rather download it from their site than
    from mediafire.com in a proprietary format (it's a .rar file).

    >> And I see no mention of C on their web page (perhaps I just didn't find
    >> it)

    >
    > No, its not advertisedf, just provided.
    >
    >>, so it's not even clear this is topical.

    >
    > a C-Language compiler is *not topical* ?!?


    As I said, it *appeared* from the information I found in a cursory
    examination of embarcadero.com to be just a C++ compiler. I just looked
    again, and http://www.embarcadero.com/products/cbuilder says they
    support both C and C++ -- including the C11 and C++11 standards. The
    existence of a C compiler that supports (how well?) the C11 standard is
    interesting news.

    > In my own news group, thoudsands of us use their BCC offerings:
    > including BCC5.8, BCC 6.5, and BCC 6.6.0


    What is your "own news group"?

    > We don't sell it, only use it to compile our apps.


    Whether you sell it or not is not particularly relevant.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 4, 2013
    #4
  5. Mel Smith

    Luuk Guest

    On 03-05-2013 18:40, Mel Smith wrote:
    > Hi:
    >
    > If you would like to test/try out the new 'Borland' C/C++ Compiler
    > (from Embarcadero) BCC 6.6.0, there is a link below.
    >
    > This console-only compiler was extracted from the C++ Builder package
    > XE4
    >
    > http://....
    >



    Abstract: The free download version of the Borland C++ Compiler version
    5.5 is now available.:
    http://edn.embarcadero.com/article/20633

    C++ Compiler 5.5
    C++Builder Compiler (bcc compiler) free download. See the file
    bcb5tool.hlp in the Help directory for complete instructions on using
    the C++Builder Compiler and Command Line Tools. We recommend downloading
    the C++Builder or RAD Studio Trial editions instead to get the latest
    compilers for Windows and Mac with a complete IDE experience.
    https://downloads.embarcadero.com/free/c_builder
     
    Luuk, May 4, 2013
    #5
  6. On Saturday, May 4, 2013 2:29:33 AM UTC+1, Keith Thompson wrote:
    > "Mel Smith" <> writes:
    >
    >
    > As I said, it *appeared* from the information I found in a cursory
    > examination of embarcadero.com to be just a C++ compiler.
    >

    I don't think it's possible to get a C++ compiler which won't compile files with
    a .c extension as C. It would be possible to write one, of course, but the
    extra effort involved in supporting at least some dialect of C is so small
    that it would be a pointless exercise.
     
    Malcolm McLean, May 4, 2013
    #6
  7. In article <>,
    Malcolm McLean <> wrote:
    >On Saturday, May 4, 2013 2:29:33 AM UTC+1, Keith Thompson wrote:
    >> "Mel Smith" <> writes:
    >>
    >>
    >> As I said, it *appeared* from the information I found in a cursory
    >> examination of embarcadero.com to be just a C++ compiler.
    >>

    >I don't think it's possible to get a C++ compiler which won't compile files with
    >a .c extension as C. It would be possible to write one, of course, but the
    >extra effort involved in supporting at least some dialect of C is so small
    >that it would be a pointless exercise.


    I agree, but you must keep in mind that *most* of Keith Thompson's posts are
    pointless exercises. Keith excels in pointless exercises [*].

    Of course, one might also say that of the Usenet in general, but it, at least
    among (nominally) technical groups, CLC and Keith Thompson are standout examples.

    [*] Such as constantly reminding us that C and C++ are distinct languages, and
    generally pretending that they are completely unrelated to each other - as
    different as, say, C and Fortran.

    --
    "The anti-regulation business ethos is based on the charmingly naive notion
    that people will not do unspeakable things for money." - Dana Carpender

    Quoted by Paul Ciszek (pciszek at panix dot com). But what I want to know
    is why is this diet/low-carb food author doing making pithy political/economic
    statements?

    Nevertheless, the above quote is dead-on, because, the thing is - business
    in one breath tells us they don't need to be regulated (which is to say:
    that they can morally self-regulate), then in the next breath tells us that
    corporations are amoral entities which have no obligations to anyone except
    their officers and shareholders, then in the next breath they tell us they
    don't need to be regulated (that they can morally self-regulate) ...
     
    Kenny McCormack, May 4, 2013
    #7
  8. Malcolm McLean <> writes:
    > On Saturday, May 4, 2013 2:29:33 AM UTC+1, Keith Thompson wrote:
    >> "Mel Smith" <> writes:
    >>
    >> As I said, it *appeared* from the information I found in a cursory
    >> examination of embarcadero.com to be just a C++ compiler.
    >>

    > I don't think it's possible to get a C++ compiler which won't compile
    > files with a .c extension as C. It would be possible to write one, of
    > course, but the extra effort involved in supporting at least some
    > dialect of C is so small that it would be a pointless exercise.


    Maybe. Microsoft has certainly decided not to devote much further
    effort to C. Their Visual Studio supports only C (plus a very few C99
    features), and that's probably only because it already had that support,
    since C is older than C++. I can imagine some vendor developing a new
    C++ compiler from scratch and not bothering with C support.

    But I don't know of any that have actually done so.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 4, 2013
    #8
  9. On Saturday, May 4, 2013 9:01:24 PM UTC+1, Keith Thompson wrote:
    > Malcolm McLean <> writes:
    >
    > > On Saturday, May 4, 2013 2:29:33 AM UTC+1, Keith Thompson wrote:

    >
    >
    > Maybe. Microsoft has certainly decided not to devote much further
    > effort to C. Their Visual Studio supports only C (plus a very few C99
    > features), and that's probably only because it already had that support,
    > since C is older than C++. I can imagine some vendor developing a new
    > C++ compiler from scratch and not bothering with C support.
    >

    Microsoft seem to have a policy of deliberately breaking legacy source
    (but not legacy executables). However they daredn't do that to standard
    C, because too many fundamental routines which applications developers
    rely on and don't have the skills to write themselves are written in C.
     
    Malcolm McLean, May 4, 2013
    #9
  10. Malcolm McLean <> wrote:
    > On Saturday, May 4, 2013 2:29:33 AM UTC+1, Keith Thompson wrote:
    >> "Mel Smith" <> writes:


    >> As I said, it *appeared* from the information I found in a cursory
    >> examination of embarcadero.com to be just a C++ compiler.


    > I don't think it's possible to get a C++ compiler which won't compile files with
    > a .c extension as C. It would be possible to write one, of course, but the
    > extra effort involved in supporting at least some dialect of C is so small
    > that it would be a pointless exercise.


    One thing that always bothered me about unix, as compared to some
    DEC systems like VMS is the way it treats file extensions.

    For VMS commands, most have a default extension, but will work fine
    if you supply a different one.

    One that always surprised me was the PRINT command default of .LIS,
    though I rarely named my files that way, even if I did plan to PRINT
    them.

    Having not tried recently, I would expect a VMS C++ compiler to happily
    compile C++ code with a .c extension, and the C compiler to compile
    C code with a .cpp extension. (I don't remember if + is a legal
    character in VMS file names or extensions.)

    -- glen
     
    glen herrmannsfeldt, May 4, 2013
    #10
  11. Mel Smith

    Tim Prince Guest

    On 05/04/2013 05:05 PM, glen herrmannsfeldt wrote:
    > Malcolm McLean <> wrote:
    >> On Saturday, May 4, 2013 2:29:33 AM UTC+1, Keith Thompson wrote:
    >>> "Mel Smith" <> writes:

    >
    >>> As I said, it *appeared* from the information I found in a cursory
    >>> examination of embarcadero.com to be just a C++ compiler.

    >
    >> I don't think it's possible to get a C++ compiler which won't compile files with
    >> a .c extension as C. It would be possible to write one, of course, but the
    >> extra effort involved in supporting at least some dialect of C is so small
    >> that it would be a pointless exercise.

    >
    > One thing that always bothered me about unix, as compared to some
    > DEC systems like VMS is the way it treats file extensions.
    >
    > For VMS commands, most have a default extension, but will work fine
    > if you supply a different one.
    >
    > One that always surprised me was the PRINT command default of .LIS,
    > though I rarely named my files that way, even if I did plan to PRINT
    > them.
    >
    > Having not tried recently, I would expect a VMS C++ compiler to happily
    > compile C++ code with a .c extension, and the C compiler to compile
    > C code with a .cpp extension. (I don't remember if + is a legal
    > character in VMS file names or extensions.)
    >
    > -- glen
    >

    The tradition (from some flavor of unix?) embodied in gnu compilers has
    spread. By default, language is chosen according to file extension,
    with options provided to over-ride that selection.
    People trip up all the time over the way .cpp changes the C compiler to
    C++ but the change doesn't carry over to the link step.
    Note the use of
    gcc -E -P -x c -traditional file.whatever
    to invoke cpp translation of source files for other languages in
    accordance with C89.
    Is this a small inconsistency to use -traditional to mean C89 here
    (otherwise defaulting to C99), where the compiler itself uses other
    options for that purpose, so the net default is C99 pre-processing fed
    to c89 plus gnu89 extensions?
     
    Tim Prince, May 5, 2013
    #11
  12. Tim Prince <> writes:
    [...]
    > The tradition (from some flavor of unix?) embodied in gnu compilers has
    > spread. By default, language is chosen according to file extension,
    > with options provided to over-ride that selection.
    > People trip up all the time over the way .cpp changes the C compiler to
    > C++ but the change doesn't carry over to the link step.
    > Note the use of
    > gcc -E -P -x c -traditional file.whatever
    > to invoke cpp translation of source files for other languages in
    > accordance with C89.
    > Is this a small inconsistency to use -traditional to mean C89 here
    > (otherwise defaulting to C99), where the compiler itself uses other
    > options for that purpose, so the net default is C99 pre-processing fed
    > to c89 plus gnu89 extensions?


    gcc's "traditional" option causes the preprocessor to behave in a
    pre-ANSI manner, not as C89. See the GNU cpp documentation for details.
    Defining "pre-ANSI" can be non-trivial since, well, there was no
    standard. The "traditional" option is no longer supported without "-E"
    (which says to invoke only the preprocessor)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 5, 2013
    #12
  13. Mel Smith

    Jorgen Grahn Guest

    On Sat, 2013-05-04, glen herrmannsfeldt wrote:
    > Malcolm McLean <> wrote:

    ....
    >> I don't think it's possible to get a C++ compiler which won't compile files with
    >> a .c extension as C. It would be possible to write one, of course, but the
    >> extra effort involved in supporting at least some dialect of C is so small
    >> that it would be a pointless exercise.

    >
    > One thing that always bothered me about unix, as compared to some
    > DEC systems like VMS is the way it treats file extensions.


    But Unix /doesn't/ treat file extensions, most of the time.

    Compilers are an exception. Perhaps because Make (another exception)
    relies on them anyway, so you have foo.c, foo.o and libfoo.a and so on.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, May 6, 2013
    #13
  14. Mel Smith

    Ken Brody Guest

    On 5/4/2013 4:29 PM, Malcolm McLean wrote:
    [...]
    > Microsoft seem to have a policy of deliberately breaking legacy source
    > (but not legacy executables). However they daredn't do that to standard
    > C, because too many fundamental routines which applications developers
    > rely on and don't have the skills to write themselves are written in C.


    They do, however, like to give warnings about "unsafe" and "deprecated"
    functions, and suggest that you change to, not the ANSI-standard "safe"
    version, but the MS-specific "safe" version.

    For example:

    warning C4996: 'fopen': This function or variable may be unsafe.
    Consider using fopen_s instead.

    (Although some forum comments I saw say that fopen_s() is now part of C11, I
    can't confirm/refute that statement.)

    --
    Kenneth Brody
     
    Ken Brody, May 10, 2013
    #14
  15. Mel Smith

    James Kuyper Guest

    On 05/10/2013 10:05 AM, Ken Brody wrote:
    > On 5/4/2013 4:29 PM, Malcolm McLean wrote:
    > [...]
    >> Microsoft seem to have a policy of deliberately breaking legacy source
    >> (but not legacy executables). However they daredn't do that to standard
    >> C, because too many fundamental routines which applications developers
    >> rely on and don't have the skills to write themselves are written in C.

    >
    > They do, however, like to give warnings about "unsafe" and "deprecated"
    > functions, and suggest that you change to, not the ANSI-standard "safe"
    > version, but the MS-specific "safe" version.
    >
    > For example:
    >
    > warning C4996: 'fopen': This function or variable may be unsafe.
    > Consider using fopen_s instead.
    >
    > (Although some forum comments I saw say that fopen_s() is now part of C11, I
    > can't confirm/refute that statement.)


    It is indeed in C11, section K.3.5.2.1. The functions described in Annex
    K only need to be defined on implementations that choose to pre#define
    __STDC_LIB_EXT1__.
     
    James Kuyper, May 10, 2013
    #15
  16. Am 10.05.2013 16:32, schrieb James Kuyper:

    >>
    >> They do, however, like to give warnings about "unsafe" and "deprecated"
    >> functions, and suggest that you change to, not the ANSI-standard "safe"
    >> version, but the MS-specific "safe" version.
    >>
    >> For example:
    >>
    >> warning C4996: 'fopen': This function or variable may be unsafe.
    >> Consider using fopen_s instead.
    >>
    >> (Although some forum comments I saw say that fopen_s() is now part of C11, I
    >> can't confirm/refute that statement.)

    >
    > It is indeed in C11, section K.3.5.2.1. The functions described in Annex
    > K only need to be defined on implementations that choose to pre#define
    > __STDC_LIB_EXT1__.


    Sorry for getting off-topic, but could anyone explain me what on fopen()
    might be insecure? It does not write to its arguments, expects just
    const strings as arguments it has to parse, so how could one use fopen
    in a way that breaches security that is not available with fopen_s()?
    Ok, shoot yourself in the foot by potentially writing to files you want
    to (or need to) keep, but that's not different from fopen_s(), is it?

    I do see the point for sprintf, for example.
     
    Thomas Richter, May 10, 2013
    #16
  17. In article <kmjfoo$7t4$-stuttgart.de>,
    Thomas Richter <-berlin.de> wrote:
    ....
    >Sorry for getting off-topic, but could anyone explain me what on fopen()
    >might be insecure? It does not write to its arguments, expects just
    >const strings as arguments it has to parse, so how could one use fopen
    >in a way that breaches security that is not available with fopen_s()?
    >Ok, shoot yourself in the foot by potentially writing to files you want
    >to (or need to) keep, but that's not different from fopen_s(), is it?
    >
    >I do see the point for sprintf, for example.
    >


    I think the idea is that any function that takes a string argument has to also
    include a length parameter for that string arg. Essentially, replacing C-style
    strings (which are inherently unsafe) with Pascal-style strings. Well, not
    really, since the length parameter would specify the max length of the string,
    not the actual length (IIRC).

    Because otherwise, an evil user could supply a non-null-terminated "string"
    (have to put that in scare quotes, else Kiki will have a heart attack), and
    thus invoke UB. And then God knows what could happen...

    --
    "The anti-regulation business ethos is based on the charmingly naive notion
    that people will not do unspeakable things for money." - Dana Carpender

    Quoted by Paul Ciszek (pciszek at panix dot com). But what I want to know
    is why is this diet/low-carb food author doing making pithy political/economic
    statements?

    Nevertheless, the above quote is dead-on, because, the thing is - business
    in one breath tells us they don't need to be regulated (which is to say:
    that they can morally self-regulate), then in the next breath tells us that
    corporations are amoral entities which have no obligations to anyone except
    their officers and shareholders, then in the next breath they tell us they
    don't need to be regulated (that they can morally self-regulate) ...
     
    Kenny McCormack, May 10, 2013
    #17
  18. Mel Smith

    James Kuyper Guest

    On 05/10/2013 02:54 PM, Thomas Richter wrote:
    > Am 10.05.2013 16:32, schrieb James Kuyper:
    >
    >>>
    >>> They do, however, like to give warnings about "unsafe" and "deprecated"
    >>> functions, and suggest that you change to, not the ANSI-standard "safe"
    >>> version, but the MS-specific "safe" version.
    >>>
    >>> For example:
    >>>
    >>> warning C4996: 'fopen': This function or variable may be unsafe.
    >>> Consider using fopen_s instead.
    >>>
    >>> (Although some forum comments I saw say that fopen_s() is now part of C11, I
    >>> can't confirm/refute that statement.)

    >>
    >> It is indeed in C11, section K.3.5.2.1. The functions described in Annex
    >> K only need to be defined on implementations that choose to pre#define
    >> __STDC_LIB_EXT1__.

    >
    > Sorry for getting off-topic, but could anyone explain me what on fopen()
    > might be insecure? ...


    I think, at least in this case, that it's more about safety than about
    security.

    > ...It does not write to its arguments, expects just
    > const strings as arguments it has to parse, so how could one use fopen
    > in a way that breaches security that is not available with fopen_s()?
    > Ok, shoot yourself in the foot by potentially writing to files you want
    > to (or need to) keep, but that's not different from fopen_s(), is it?


    Here's the declaration for fopen():
    FILE *fopen(const char * restrict filename,
    const char * restrict mode);

    Here's the declaration for fopen_s():
    errno_t fopen_s(FILE * restrict * restrict streamptr,
    const char * restrict filename,
    const char * restrict mode);

    There are two mistakes you can make when calling fopen() that fopen_s()
    protects against:

    FILE *file = fopen(NULL, inmode);

    This code has undefined behavior "by the omission of any explicit
    definition of behavior" (4p2), since the description of what fopen()
    does with its filename argument (7.21.5.3p2) is meaningless when that
    argument is a null pointer. The corresponding code using fopen_s() has
    defined behavior: it will make no attempt to open a file, *streamptr
    will be set to a null pointer value (K.3.5.2.1p2,3), and fopen_s() will
    return a non-zero value. This strikes me as a good idea.

    The second mistake would be something like the following:

    fopen(outfilename, outmode);

    This code opens a file without having any way to do anything with it,
    including close it. The corresponding code using fopen_s() would be:

    FILE *outfile;
    fopen_s(&outfile, outfilename, &outmode);

    You can still discard outfile immediately, producing the same net
    result, but the necessity of creating a valid pointer to a FILE* object
    makes it harder to make that particular error accidentally.

    I don't see any value in adding a level of indirection to the mode. All
    is does is create new ways for the function to fail: if the third
    argument is null, it fails with defined behavior: no attempt will be
    made to open the file, and *streamptr will be set to a null pointer
    value, and fopen_s(). However, because of the restrict qualifiers, if
    the third argument points at memory which overlaps that pointed at by
    streamptr, filename, the behavior is undefined; a situation that
    couldn't meaningfully be a problem with fopen().
     
    James Kuyper, May 10, 2013
    #18
  19. Kenny McCormack <> wrote:
    > In article <kmjfoo$7t4$-stuttgart.de>,

    (snip)
    >>Sorry for getting off-topic, but could anyone explain me what on fopen()
    >>might be insecure? It does not write to its arguments, expects just
    >>const strings as arguments it has to parse, so how could one use fopen
    >>in a way that breaches security that is not available with fopen_s()?
    >>Ok, shoot yourself in the foot by potentially writing to files you want
    >>to (or need to) keep, but that's not different from fopen_s(), is it?


    (snip)
    > I think the idea is that any function that takes a string argument has to also
    > include a length parameter for that string arg. Essentially, replacing C-style
    > strings (which are inherently unsafe) with Pascal-style strings. Well, not
    > really, since the length parameter would specify the max length of the string,
    > not the actual length (IIRC).


    It you know the length, then just stuff in '\0' as the last character.
    You might cut off the end of the file name, but you are sure that there
    is at least one in there.

    -- glen
     
    glen herrmannsfeldt, May 10, 2013
    #19
  20. Mel Smith

    James Kuyper Guest

    On 05/10/2013 03:49 PM, glen herrmannsfeldt wrote:
    > Kenny McCormack <> wrote:
    >> In article <kmjfoo$7t4$-stuttgart.de>,

    > (snip)
    >>> Sorry for getting off-topic, but could anyone explain me what on fopen()
    >>> might be insecure? It does not write to its arguments, expects just
    >>> const strings as arguments it has to parse, so how could one use fopen
    >>> in a way that breaches security that is not available with fopen_s()?
    >>> Ok, shoot yourself in the foot by potentially writing to files you want
    >>> to (or need to) keep, but that's not different from fopen_s(), is it?

    >
    > (snip)
    >> I think the idea is that any function that takes a string argument has to also
    >> include a length parameter for that string arg.


    The new functions have new length parameters only for pointers to the
    first element of arrays that they write to, and it doesn't matter
    whether those arrays contain strings either before or after the function
    is called (for instance, memmove_s() takes a length parameter).
    fopen_s() has no such arguments, so it doesn't take any length parameters.
     
    James Kuyper, May 10, 2013
    #20
    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. Natty Gur
    Replies:
    0
    Views:
    2,597
    Natty Gur
    Jun 6, 2004
  2. =?Utf-8?B?VHJldm9yIEJlbmVkaWN0IFI=?=
    Replies:
    0
    Views:
    2,406
    =?Utf-8?B?VHJldm9yIEJlbmVkaWN0IFI=?=
    Jun 7, 2004
  3. =?Utf-8?B?SmF5?=
    Replies:
    1
    Views:
    2,138
    Jim Andersen
    Jan 26, 2006
  4. Replies:
    1
    Views:
    844
    Sebastian Millies
    Nov 2, 2006
  5. Luke Kenneth Casson Leighton
    Replies:
    0
    Views:
    444
    Luke Kenneth Casson Leighton
    Jan 18, 2009
Loading...

Share This Page