Subject: C to JVM compiler (AMPC)

Discussion in 'C Programming' started by Mohd Hanafiah Abdullah, May 14, 2005.

  1. Axiomatic Solutions Sdn Bhd announces the availability of AMPC version 1.2.
    You can purchase AMPC online now at:
    http://www.axiomsol.com/hedesu/shopping/index.php

    Major Changes
    -------------
    Version 1.2 supports the MS Windows XP platform, beside Linux x86 and
    Mac OSX. It also supports the DOUBLE floating point type. Please see the
    README file for details on DOUBLE floating point type.

    AMPC (Axiomatic Multi-Platform C) is a C compiler/IDE targeting the JVM
    (generates Java Bytecode). The resulting .class executables will be
    able to run on any Java Virtual Machine (tm). AMPC enables programmers
    to write/port applications using C targeting the JVM, thus, opening up a
    whole new market dimension vis-a-vis JVM-enabled devices such as desktop
    systems, PDAs, cell-phones, game consoles, set-top boxes, automotive systems
    (GPS based displays, OnStar, Satellite radio systems, etc), and so forth.
    AMPC can also be used to turn legacy applications written in C into JVM
    applications, with a single source base to manage. Use existing C skill sets
    instead of learning new Java skill sets.

    AMPC includes a Graphical User Interface (GUI) as part of the Integrated
    Development Environment (IDE) for fast and organized software
    development.

    AMPC is based upon the American National Standards Institute C (ANSI C),
    X3.159-1989. There are however a few differences between AMPC and a
    fully compliant ANSI C compiler. The differences of AMPC with a fully
    compliant ANSI C compiler are described in AMPC's product description.

    JNI (JVM Native Interface) support is available for the purpose of
    calling native C or C++ functions from AMPC.

    AMPC can also generate assembly code for the Jasmin assembler using the
    asm() directive.

    It also can call most Java classes using the functions INT_java(),
    FLOAT_java(), DOUBLE_java(), and so forth.

    Hardware Requirements:
    - Any x86 compatible computer running MS Windows XP
    - Any Macintosh computer running Mac OSX
    - Any x86 compatible computer running Linux
    - 128MB RAM minimum

    Software Requirements:
    - Java SDK 1.4.2 or newer (JDK 1.5 recommended).

    More info on AMPC can be found at http://www.axiomsol.com

    Thank you and best regards.

    --
    Axiomatic Solutions Sdn Bhd
    http://www.axiomsol.com

    --
    http://www.axiomsol.com
    http://www.cs.indiana.edu/hyplan/napi.html
     
    Mohd Hanafiah Abdullah, May 14, 2005
    #1
    1. Advertising

  2. Mohd Hanafiah Abdullah wrote:

    > AMPC (Axiomatic Multi-Platform C) is a C compiler/IDE targeting the JVM
    > (generates Java Bytecode).


    C is a procedural language and as far as I know JVM is an OO framework. How can C code
    create class definitions, inheritance, use objects etc? May you provide a hello world
    example in C by using the JVM facilities?



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, May 14, 2005
    #2
    1. Advertising

  3. Mohd Hanafiah Abdullah

    Rapscallion Guest

    Ioannis Vranos wrote:
    > C is a procedural language and as far as I know JVM is an OO

    framework. How can C code
    > create class definitions, inheritance, use objects etc? May you

    provide a hello world
    > example in C by using the JVM facilities?


    This is easy. Use only static functions in Java. The hard thing (which
    cannot be reached directly) is to map the low level functions (memmove,
    ....) to Java.

    R.C.
     
    Rapscallion, May 14, 2005
    #3
  4. Rapscallion wrote:

    > This is easy. Use only static functions in Java. The hard thing (which
    > cannot be reached directly) is to map the low level functions (memmove,
    > ...) to Java.


    I have no JVM experience, but I have .NET experience, which is a CLI VM platform.

    In .NET, in most (perhaps all) cases, static methods are more run-time expensive than
    usual methods which do the same operations, and are used either for-do-something-only-once
    (having the same cost as the initial call of the equivalent method of an object of the
    class) since it doesn't make sense to create an object of the class for doing something
    only once - an example is a file operation -, or thread safety (the same resource being
    shared by more than one threads, and thus additional checks and locks) or other reasons.

    Also many static methods return objects by themselves.

    I suppose these are also the case for the JVM. So how does C code can handle returned
    objects of a static/non-static method?


    memmove etc are more applicable to native code and not VM code.



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, May 14, 2005
    #4
  5. Ioannis Vranos wrote:

    > Mohd Hanafiah Abdullah wrote:
    >
    >> AMPC (Axiomatic Multi-Platform C) is a C compiler/IDE targeting the JVM
    >> (generates Java Bytecode).

    >
    >
    > C is a procedural language and as far as I know JVM is an OO
    > framework. How can C code create class definitions, inheritance, use
    > objects etc? May you provide a hello world example in C by using the
    > JVM facilities?
    >

    Your question makes no sense to me. The product is a C --> Java
    compiler, not a Java --> C compiler. The point of the product is to use
    C skillsets and not learn Java. C programmers don't do class
    definitions, inheritance, etc. If they wanted to do all of that in
    Java, they'd do Java. Presumably their "hello world" is going to be
    written in C, although I do think it's an interesting question if the C
    standard libraries are available and output JVM bytecode.

    --
    Cheers, www.indiegamedesign.com
    Brandon Van Every Seattle, WA

    "We live in a world of very bright people building
    crappy software with total shit for tools and process."
    - Ed McKenzie
     
    Brandon J. Van Every, May 14, 2005
    #5
  6. Brandon J. Van Every wrote:

    > Your question makes no sense to me. The product is a C --> Java
    > compiler, not a Java --> C compiler. The point of the product is to use
    > C skillsets and not learn Java. C programmers don't do class
    > definitions, inheritance, etc. If they wanted to do all of that in
    > Java, they'd do Java. Presumably their "hello world" is going to be
    > written in C, although I do think it's an interesting question if the C
    > standard libraries are available and output JVM bytecode.



    From my .NET experience, I do not think it is easy (and in some cases even possible) to
    provide managed versions of C standard library.

    Again from this experience of mine, the main difference between a native machine and a VM
    is that the assembly language of a VM is more high level than the assembly of a native
    machine. Having C++ in mind here, for example the assembly language of CLI standard (.NET
    is a CLI compliant VM) has also the concepts of class, enumeration, etc which have some
    (perhaps minor but existent) differences compared with C++ native ones. That's why in C++
    case (and perhaps in other platform neutral languages), CLI features are provided
    *separately* from the native features (currently in "managed extensions" and in the
    upcoming C++/CLI).

    Regarding C things should be even more difficult since it lacks the built-in concept of
    OO, I can't understand how C programs can interact with the JVM APIs. Unless you can't do
    anything else under JVM apart from ISO C code, which doesn't make much sense and which is
    not possible under its entirety (GC is moving objects around and thus you can't rely on
    pointer arithmetic, or compare two pointers to see if they point to the same object
    (memory area), memmove etc. You could pin them (I do not know if JVM permits object
    pinning), but this implies additional run-time cost, forgetting pinned objects which will
    not be garbage collected possibly resulting in memory leaks, etc).



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, May 14, 2005
    #6
  7. Ioannis Vranos wrote:

    > From my .NET experience, I do not think it is easy (and in some cases
    > even possible) to provide managed versions of C standard library.
    >
    > Again from this experience of mine, the main difference between a native
    > machine and a VM is that the assembly language of a VM is more high
    > level than the assembly of a native machine. Having C++ in mind here,
    > for example the assembly language of CLI standard (.NET is a CLI
    > compliant VM) has also the concepts of class, enumeration, etc which
    > have some (perhaps minor but existent) differences compared with C++
    > native ones. That's why in C++ case (and perhaps in other platform
    > neutral languages), CLI features are provided *separately* from the
    > native features (currently in "managed extensions" and in the upcoming
    > C++/CLI).
    >
    > Regarding C things should be even more difficult since it lacks the
    > built-in concept of OO, I can't understand how C programs can interact
    > with the JVM APIs. Unless you can't do anything else under JVM apart
    > from ISO C code, which doesn't make much sense and which is not possible
    > under its entirety (GC is moving objects around and thus you can't rely
    > on pointer arithmetic, or compare two pointers to see if they point to
    > the same object (memory area), memmove etc. You could pin them (I do not
    > know if JVM permits object pinning), but this implies additional
    > run-time cost, forgetting pinned objects which will not be garbage
    > collected possibly resulting in memory leaks, etc).



    I checked their web site (I guess I should have done this since the beginning), and saw
    that they provide their own APIs (probably have encapsulated JVMs APIs to functions). In
    this way I guess it is possible to do JVM programming (this must have been a real pain for
    them though). :)



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, May 14, 2005
    #7
  8. In article <1116096955.568188@athnrd02>,
    Ioannis Vranos <> wrote:

    > Regarding C things should be even more difficult since it lacks the built-in
    > concept of
    > OO, I can't understand how C programs can interact with the JVM APIs. Unless
    > you can't do
    > anything else under JVM apart from ISO C code, which doesn't make much sense
    > and which is
    > not possible under its entirety (GC is moving objects around and thus you
    > can't rely on
    > pointer arithmetic, or compare two pointers to see if they point to the same
    > object
    > (memory area), memmove etc. You could pin them (I do not know if JVM permits
    > object
    > pinning), but this implies additional run-time cost, forgetting pinned
    > objects which will
    > not be garbage collected possibly resulting in memory leaks, etc).


    You are confusing "pointers" and "memory addresses". They are the same
    in many C implementations (depending on what you mean exactly with
    "memory address"), but in a JVM based C compiler they would most
    definitely not be the same. Most likely a C pointer would be implemented
    as a pair (object, offset); possibly (array of byte, index into array).
     
    Christian Bau, May 14, 2005
    #8
  9. "Brandon J. Van Every" <> writes:
    > Ioannis Vranos wrote:
    >> Mohd Hanafiah Abdullah wrote:
    >>> AMPC (Axiomatic Multi-Platform C) is a C compiler/IDE targeting the JVM
    >>> (generates Java Bytecode).

    >>
    >> C is a procedural language and as far as I know JVM is an OO
    >> framework. How can C code create class definitions, inheritance, use
    >> objects etc? May you provide a hello world example in C by using the
    >> JVM facilities?
    >>

    > Your question makes no sense to me. The product is a C --> Java
    > compiler, not a Java --> C compiler. The point of the product is to
    > use C skillsets and not learn Java. C programmers don't do class
    > definitions, inheritance, etc. If they wanted to do all of that in
    > Java, they'd do Java. Presumably their "hello world" is going to be
    > written in C, although I do think it's an interesting question if the
    > C standard libraries are available and output JVM bytecode.


    According to the initial description, it's not a C --> Java compiler,
    it's a C --> Java Bytecode compiler. Java is a high-level language; a
    C --> Java compiler would generate Java source code from C source
    code.

    There's an unfortunate tendency to fail to distinguish between Java
    (the high-level language) and Java bytecode (a low-level intermediate
    or interpreted form). They were designed together, but they aren't
    necessarily logically linked -- and many of the concepts in Java
    bytecode predate Java the language. It's entirely possible to compile
    languages other than Java to Java bytecode (for example, there's at
    least one Ada compiler that generates Java bytecode). It's also
    entirely possible to compile Java to machine language.

    C presents some interesting challenges, because its freewheeling use
    of pointers is difficult to express in Java bytecode. I suspect that
    a lot of constructs that invoke undefined behavior but happen to work
    perfectly well with a traditional C compiler will actually fail with a
    C --> JVM compiler. That's probably a good thing; it provides a way
    to weed out non-portable constructs in C code that's intended to be
    portable. Perhaps the C --> JVM compiler can serve the purpose of the
    DS9000 (a mythical machine with a C implementation that behaves as
    perversely as possible without actually violating the standard).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, May 14, 2005
    #9
  10. Mohd Hanafiah Abdullah

    Malcolm Guest

    "Ioannis Vranos" <> wrote
    > C is a procedural language and as far as I know JVM is an OO framework.
    > How can C code create class definitions, inheritance, use objects etc? May
    > you > provide a hello world example in C by using the JVM facilities?
    >

    The program takes as input the text

    #include <stdio.h>

    int main(void)
    {
    printf("Hello world\n);
    return 0;
    }

    The C to JVM compiler then creates a class called something (probably based
    on the name of the C source file)

    class hello_c
    {
    static void main()
    {
    system.out.println("Hello world");
    }
    }

    It has the intelligence to know that the call to printf() can be relaced by
    a call to System.out.println() if you remove the trailing newline.

    This file then gets fed to a Java complier, which produces a Java .class
    file.

    In practise it wouldn't bother creating an intermediate human-readable Java
    file and the Java compiler would be integrated into the C to JVM compiler.
    But that's just a detail. Also it would have to generate lots of fancy Java
    code to handle more complicated printf() calls.
     
    Malcolm, May 15, 2005
    #10
  11. Ioannis Vranos wrote:

    >
    > Regarding C things should be even more difficult since it lacks the
    > built-in concept of OO, I can't understand how C programs can interact
    > with the JVM APIs. Unless you can't do anything else under JVM apart
    > from ISO C code, which doesn't make much sense


    Sure it does. The product is aimed at the embedded market. A lot of
    that "other Java stuff" is not needed. Customers may also wish to
    bridge legacy code from C to the JVM, given that Java is also used in
    the embedded market. I think the problem here is you're envisioning
    some kind of "do everything a Java applications developer would want to
    do" sort of package, which is what actually doesn't make sense. The
    target audience is embedded C developers, who want to retarget their
    code to the JVM.

    > and which is not possible under its entirety (GC is moving objects
    > around and thus you can't rely on pointer arithmetic, or compare two
    > pointers to see if they point to the same object (memory area),
    > memmove etc.


    Well, it would be interesting to see what subset of C possibility the
    JVM could support. Those are intelligent questions for the vendor, if
    you're interested.

    --
    Cheers, www.indiegamedesign.com
    Brandon Van Every Seattle, WA

    "We live in a world of very bright people building
    crappy software with total shit for tools and process."
    - Ed McKenzie
     
    Brandon J. Van Every, May 15, 2005
    #11
  12. Keith Thompson wrote:

    >
    >According to the initial description, it's not a C --> Java compiler,
    >it's a C --> Java Bytecode compiler. Java is a high-level language; a
    >C --> Java compiler would generate Java source code from C source
    >code.
    >
    >

    Eh, semantics. Java, bytecode, whatever. The point is, it goes C
    Universe --> Java Universe, and not in the other direction. This
    implies certain usage patterns and not others.

    > It's entirely possible to compile
    >languages other than Java to Java bytecode (for example, there's at
    >least one Ada compiler that generates Java bytecode).
    >

    Indeed the Bigloo and Kawa Scheme compilers can produce Java bytecode.
    I'm not sure how well. The Eclipse Schemeway plugin developer is big
    into Kawa though. http://schemeway.sourceforge.net/

    >C presents some interesting challenges, because its freewheeling use
    >of pointers is difficult to express in Java bytecode. I suspect that
    >a lot of constructs that invoke undefined behavior but happen to work
    >perfectly well with a traditional C compiler will actually fail with a
    >C --> JVM compiler. That's probably a good thing; it provides a way
    >to weed out non-portable constructs in C code that's intended to be
    >portable.
    >

    Sure, and as an aide de port it may be a valid business model.

    > Perhaps the C --> JVM compiler can serve the purpose of the
    >DS9000 (a mythical machine with a C implementation that behaves as
    >perversely as possible without actually violating the standard).
    >
    >

    Is DS9000 an acronym? Any relation to HAL9000?

    --
    Cheers, www.indiegamedesign.com
    Brandon Van Every Seattle, WA

    "We live in a world of very bright people building
    crappy software with total shit for tools and process."
    - Ed McKenzie
     
    Brandon J. Van Every, May 15, 2005
    #12
  13. "Brandon J. Van Every" <> writes:
    > Keith Thompson wrote:

    [...]
    >> Perhaps the C --> JVM compiler can serve the purpose of the
    >>DS9000 (a mythical machine with a C implementation that behaves as
    >>perversely as possible without actually violating the standard).
    >>
    >>

    > Is DS9000 an acronym? Any relation to HAL9000?


    DS stands for DeathStation. The 9000 was probably inspired by HAL.

    It goes along with the idea that a permitted consequence of undefined
    behavior in C is that the implementation makes demons fly out your
    nose (often abbreviated to "nasal demons").

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, May 15, 2005
    #13
  14. Mohd Hanafiah Abdullah

    Ed Jensen Guest

    In comp.lang.c++ Mohd Hanafiah Abdullah <> wrote:
    > AMPC (Axiomatic Multi-Platform C) is a C compiler/IDE targeting the JVM
    > (generates Java Bytecode).


    I wonder if this, combined with the Comeau compiler, would allow one
    to run C++ programs on a JVM?

    C++ source -> Comeau -> C source -> AMPC -> JVM
     
    Ed Jensen, May 15, 2005
    #14
  15. Mohd Hanafiah Abdullah wrote:

    > AMPC (Axiomatic Multi-Platform C) is a C compiler/IDE targeting the JVM
    > (generates Java Bytecode). The resulting .class executables will be
    > able to run on any Java Virtual Machine (tm). AMPC enables programmers
    > to write/port applications using C targeting the JVM, thus, opening up a
    > whole new market dimension vis-a-vis JVM-enabled devices such as desktop
    > systems, PDAs, cell-phones, game consoles, set-top boxes, automotive systems
    > (GPS based displays, OnStar, Satellite radio systems, etc), and so forth.
    > AMPC can also be used to turn legacy applications written in C
    > into JVM applications, with a single source base to manage.
    > Use existing C skill sets instead of learning new Java skill sets.


    This is, of course, a great idea.
    Have you got customers?
    A user base?
     
    E. Robert Tisdale, May 15, 2005
    #15
  16. Brandon J. Van Every wrote:

    > Is DS9000 an acronym? Any relation to HAL9000?



    A DS9000 is a comp.lang.c imaginary machine, that you do not want to write code with
    undefined behaviour and run on it. :)


    I just searched google to find out who thought it up, and the interesting thing is that
    there are a few real DS 9000 machines:

    http://groups.google.com/groups?q="&rnum=1

    http://groups.google.com/groups?q="ds 9000"&hl=el&lr=&selm=7brpa0$&rnum=6


    I found who thought it, and he explains some of its naming:

    http://groups.google.com/groups?hl=el&lr=&selm=


    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, May 15, 2005
    #16
  17. Malcolm wrote:

    > The program takes as input the text
    >
    > #include <stdio.h>
    >
    > int main(void)
    > {
    > printf("Hello world\n);
    > return 0;
    > }
    >
    > The C to JVM compiler then creates a class called something (probably based
    > on the name of the C source file)
    >
    > class hello_c
    > {
    > static void main()
    > {
    > system.out.println("Hello world");
    > }
    > }
    >
    > It has the intelligence to know that the call to printf() can be relaced by
    > a call to System.out.println() if you remove the trailing newline.
    >
    > This file then gets fed to a Java complier, which produces a Java .class
    > file.
    >
    > In practise it wouldn't bother creating an intermediate human-readable Java
    > file and the Java compiler would be integrated into the C to JVM compiler.
    > But that's just a detail. Also it would have to generate lots of fancy Java
    > code to handle more complicated printf() calls.



    Yes, C and any language can be used to produce java bytecode. I had two misconceptions.
    The first that it somehow enabled the developer to access the OO API of JVM directly, and
    secondly that it was aimed to PCs and not toward to embedded devices only.


    The answer to the first is that they created a procedural API and the second is embedded
    devices of course and thus a smaller pain than what it would be to wrap the entire JVM API
    to procedural. It is something like the case of .NET framework vs .NET compact framework.
    Still the wrapping must have been a pain, unless they have not wrapped everything.


    In any case, it can be done. However I imagine (since I do not know JVM API), mapping all
    C structures, libraries and abilities to JVM bytecode, can't be that easy or even
    possible, when we are talking about *maintaining the C semantics*.


    Anyway, I am not personally interested in JVM. :)



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, May 15, 2005
    #17
  18. In article <d66e59$4ok$>,
    E. Robert Tisdale <> wrote:
    >Mohd Hanafiah Abdullah wrote:
    >
    >> AMPC (Axiomatic Multi-Platform C) is a C compiler/IDE targeting the JVM
    >> (generates Java Bytecode). The resulting .class executables will be
    >> able to run on any Java Virtual Machine (tm). AMPC enables programmers
    >> to write/port applications using C targeting the JVM, thus, opening up a
    >> whole new market dimension vis-a-vis JVM-enabled devices such as desktop
    >> systems, PDAs, cell-phones, game consoles, set-top boxes, automotive systems
    >> (GPS based displays, OnStar, Satellite radio systems, etc), and so forth.
    >> AMPC can also be used to turn legacy applications written in C
    >> into JVM applications, with a single source base to manage.
    >> Use existing C skill sets instead of learning new Java skill sets.

    >
    >This is, of course, a great idea.
    >Have you got customers?
    >A user base?


    It's a relatively new product which has gone through the beta period and
    we are marketing it. Beside being downloaded for free for the last 6 months,
    we have interests from Telekom Malaysia's R&D and Universiti Teknologi
    Petronas here in Malaysia.

    Napi
    --
    http://www.axiomsol.com
    http://www.cs.indiana.edu/hyplan/napi.html
     
    Mohd Hanafiah Abdullah, May 15, 2005
    #18
  19. Ioannis Vranos wrote:

    > I found who thought it, and he explains some of its naming:
    >
    > http://groups.google.com/groups?hl=el&lr=&selm=
    >


    Ouch. As an ex-DEC employee, that hurts! Well, some of the DEC Alpha
    workstations were great, and others were pieces of junk. Some idiot
    decided to ship a 533 MHz machine without much of anything in the way of
    memory cache. I forget when this super cheapass memory controller was
    supposed to actually be justifiable / not harmful, but talk about
    pigeonholeing the applicability of your hardware! We had a 533 MHz box
    like that in our lab, and it was regularly getting whipped by our 300
    MHz machines that had proper caches. We nicknamed the sucker "the Yugo"
    and put a photo of that ignoble automobile on it as the desktop background.

    --
    Cheers, www.indiegamedesign.com
    Brandon Van Every Seattle, WA
     
    Brandon J. Van Every, May 15, 2005
    #19
  20. Brandon J. Van Every wrote:

    > Ouch. As an ex-DEC employee, that hurts! Well, some of the DEC Alpha
    > workstations were great, and others were pieces of junk. Some idiot
    > decided to ship a 533 MHz machine without much of anything in the way of
    > memory cache. I forget when this super cheapass memory controller was
    > supposed to actually be justifiable / not harmful, but talk about
    > pigeonholeing the applicability of your hardware! We had a 533 MHz box
    > like that in our lab, and it was regularly getting whipped by our 300
    > MHz machines that had proper caches. We nicknamed the sucker "the Yugo"
    > and put a photo of that ignoble automobile on it as the desktop background.



    Interesting. This also makes his explanation more clear. :)



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, May 15, 2005
    #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. Mohd Hanafiah Abdullah

    Subject: C to JVM compiler (AMPC)

    Mohd Hanafiah Abdullah, May 14, 2005, in forum: C++
    Replies:
    25
    Views:
    1,010
    those who know me have no need of my name
    May 17, 2005
  2. napi
    Replies:
    0
    Views:
    484
  3. napi
    Replies:
    0
    Views:
    293
  4. napi

    AMPC: C to Java Class Files compiler

    napi, Sep 8, 2006, in forum: C Programming
    Replies:
    0
    Views:
    276
  5. napi
    Replies:
    6
    Views:
    351
Loading...

Share This Page