Settle a Bet

Discussion in 'C Programming' started by Bart, Jun 23, 2007.

  1. Bart

    Bart Guest

    Hello All,
    I had a buddy looking to write a program to manipulate a
    printer's movements. He said he was proficient in C and C++ but
    didn't know where to begin. I suggested he go to some Linux sites
    and look for printer programs/drivers, as the Linux sites often
    include the C or C++ source code and maybe he could get some
    ideas from them. He replied stating that was no good because he
    didn't know the Linux OS at all and it would take him too long to
    learn.
    I argued that C was a language and Linux/Windows were operating
    systems. A C-language program could be compiled to run in Linux
    with a Linux compiler, or it could be compiled to run in Windows
    with a Windows compiler. I think back to the infamous "Hello
    World" program (everybodies first program) and can't help but
    think it could be compiled to run in Linux with a Linux compiler
    on a Linux machine, or it could be compiled to run in Windows
    with a Windows compiler on a Windows machine. He disagrees.

    Any input is appreciated, feel free to "flame" since I don't have
    any C-language experience to justify posting in this forum.
    Bart
     
    Bart, Jun 23, 2007
    #1
    1. Advertising

  2. Bart said:

    > Hello All,
    > I had a buddy looking to write a program to manipulate a
    > printer's movements. [...]
    > I argued that C was a language and Linux/Windows were operating
    > systems. A C-language program could be compiled to run in Linux
    > with a Linux compiler, or it could be compiled to run in Windows
    > with a Windows compiler. I think back to the infamous "Hello
    > World" program (everybodies first program) and can't help but
    > think it could be compiled to run in Linux with a Linux compiler
    > on a Linux machine, or it could be compiled to run in Windows
    > with a Windows compiler on a Windows machine. He disagrees.


    You're both right. Bear with me.

    #include <stdio.h>

    int main(void)
    {
    puts("Hello, world!");
    return 0;
    }

    This is a very, very, very simple example of a C program which can
    indeed be compiled on Linux with a Linux compiler or on Windows with a
    Windows compiler or a Mac with a Mac compiler or a mainframe with a
    mainframe compiler, and it'll work correctly on all of them, without
    modification. It's *portable* (i.e. you can carry it around easily from
    one system to another).

    That's why you're right. So why is your friend right, too?

    A great many tasks can be achieved with portable code. You can write
    entire compilers in portable code. There are, in fact, a colossal
    number of tasks that you can achieve in portable code.

    But not all.

    When you start talking to hardware, for example, things start to get
    sticky. The kind of code you need to talk to a printer on a Linux
    system is quite different to the code you need to talk to a printer on
    a Windows system.

    So when C programmers write programs that must access non-portable
    features, they tend to do it like this:

    +---------------------------------+
    | application layer |
    +---------------------------------+
    | portable | abstraction |
    | routines | layer |
    +------------------+--------------+
    | non-portable |
    | routines |
    +--------------+

    Then, when they need to move the program to another machine or platform,
    they rewrite the non-portable routines in a way that the new machine or
    platform will understand. The rest of the program can stay untouched.

    If this is done well, even an inherently platform-dependent program such
    as a Web browser can be moved to a new platform with as much as 99% of
    the code remaining intact, and the rewrite might only take one person a
    few weeks (rather than a whole team several years).

    The 99% figure is not made up, by the way. I have personally worked on a
    Web browser that comprised around half a million lines of code, only
    5000 of which needed to be rewritten for each new platform. (I must add
    that I wasn't responsible for the design, but I salute those who were,
    because they made a fabulous job of it.)

    So, as you can see, the answer is indeed both "yes" and "no". I suggest
    you each agree to keep your stakes, because your bet has no clear
    winner.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Jun 23, 2007
    #2
    1. Advertising

  3. Bart

    Barry Guest

    "Richard Heathfield" <> wrote in message
    news:...
    > Bart said:
    >
    >> Hello All,
    >> I had a buddy looking to write a program to manipulate a
    >> printer's movements. [...]
    >> I argued that C was a language and Linux/Windows were operating
    >> systems. A C-language program could be compiled to run in Linux
    >> with a Linux compiler, or it could be compiled to run in Windows
    >> with a Windows compiler. I think back to the infamous "Hello
    >> World" program (everybodies first program) and can't help but
    >> think it could be compiled to run in Linux with a Linux compiler
    >> on a Linux machine, or it could be compiled to run in Windows
    >> with a Windows compiler on a Windows machine. He disagrees.

    >
    > You're both right. Bear with me.
    >
    > #include <stdio.h>
    >
    > int main(void)
    > {
    > puts("Hello, world!");
    > return 0;
    > }
    >
    > This is a very, very, very simple example of a C program which can
    > indeed be compiled on Linux with a Linux compiler or on Windows with a
    > Windows compiler or a Mac with a Mac compiler or a mainframe with a
    > mainframe compiler, and it'll work correctly on all of them, without
    > modification. It's *portable* (i.e. you can carry it around easily from
    > one system to another).
    >
    > That's why you're right. So why is your friend right, too?
    >
    > A great many tasks can be achieved with portable code. You can write
    > entire compilers in portable code. There are, in fact, a colossal
    > number of tasks that you can achieve in portable code.
    >
    > But not all.
    >
    > When you start talking to hardware, for example, things start to get
    > sticky. The kind of code you need to talk to a printer on a Linux
    > system is quite different to the code you need to talk to a printer on
    > a Windows system.
    >
    > So when C programmers write programs that must access non-portable
    > features, they tend to do it like this:
    >
    > +---------------------------------+
    > | application layer |
    > +---------------------------------+
    > | portable | abstraction |
    > | routines | layer |
    > +------------------+--------------+
    > | non-portable |
    > | routines |
    > +--------------+
    >
    > Then, when they need to move the program to another machine or platform,
    > they rewrite the non-portable routines in a way that the new machine or
    > platform will understand. The rest of the program can stay untouched.
    >
    > If this is done well, even an inherently platform-dependent program such
    > as a Web browser can be moved to a new platform with as much as 99% of
    > the code remaining intact, and the rewrite might only take one person a
    > few weeks (rather than a whole team several years).
    >
    > The 99% figure is not made up, by the way. I have personally worked on a
    > Web browser that comprised around half a million lines of code, only
    > 5000 of which needed to be rewritten for each new platform. (I must add
    > that I wasn't responsible for the design, but I salute those who were,
    > because they made a fabulous job of it.)
    >
    > So, as you can see, the answer is indeed both "yes" and "no". I suggest
    > you each agree to keep your stakes, because your bet has no clear
    > winner.
    >


    <OT>
    I would suggest the opponent is closer to correct. Given the context of
    the question. Useful printing is< quite different on *nix and Win/32,
    in most cases.

    The code may be worth examining and testing. Richard may have more
    experience on simply opening a Win32 text printer than I have or can
    recall.
    <OT/>
     
    Barry, Jun 24, 2007
    #3
  4. Bart

    Bart Guest

    "Barry" <> wrote in message
    news:...
    >
    > "Richard Heathfield" <> wrote in message
    > news:...
    >> Bart said:
    >>
    >>> Hello All,
    >>> I had a buddy looking to write a program to manipulate a
    >>> printer's movements. [...]
    >>> I argued that C was a language and Linux/Windows were
    >>> operating
    >>> systems. A C-language program could be compiled to run in
    >>> Linux
    >>> with a Linux compiler, or it could be compiled to run in
    >>> Windows
    >>> with a Windows compiler. I think back to the infamous "Hello
    >>> World" program (everybodies first program) and can't help but
    >>> think it could be compiled to run in Linux with a Linux
    >>> compiler
    >>> on a Linux machine, or it could be compiled to run in Windows
    >>> with a Windows compiler on a Windows machine. He disagrees.

    >>
    >> You're both right. Bear with me.
    >>
    >> #include <stdio.h>
    >>
    >> int main(void)
    >> {
    >> puts("Hello, world!");
    >> return 0;
    >> }
    >>
    >> This is a very, very, very simple example of a C program which
    >> can
    >> indeed be compiled on Linux with a Linux compiler or on
    >> Windows with a
    >> Windows compiler or a Mac with a Mac compiler or a mainframe
    >> with a
    >> mainframe compiler, and it'll work correctly on all of them,
    >> without
    >> modification. It's *portable* (i.e. you can carry it around
    >> easily from
    >> one system to another).
    >>
    >> That's why you're right. So why is your friend right, too?
    >>
    >> A great many tasks can be achieved with portable code. You can
    >> write
    >> entire compilers in portable code. There are, in fact, a
    >> colossal
    >> number of tasks that you can achieve in portable code.
    >>
    >> But not all.
    >>
    >> When you start talking to hardware, for example, things start
    >> to get
    >> sticky. The kind of code you need to talk to a printer on a
    >> Linux
    >> system is quite different to the code you need to talk to a
    >> printer on
    >> a Windows system.
    >>
    >> So when C programmers write programs that must access
    >> non-portable
    >> features, they tend to do it like this:
    >>
    >> +---------------------------------+
    >> | application layer |
    >> +---------------------------------+
    >> | portable | abstraction |
    >> | routines | layer |
    >> +------------------+--------------+
    >> | non-portable |
    >> | routines |
    >> +--------------+
    >>
    >> Then, when they need to move the program to another machine or
    >> platform,
    >> they rewrite the non-portable routines in a way that the new
    >> machine or
    >> platform will understand. The rest of the program can stay
    >> untouched.
    >>
    >> If this is done well, even an inherently platform-dependent
    >> program such
    >> as a Web browser can be moved to a new platform with as much
    >> as 99% of
    >> the code remaining intact, and the rewrite might only take one
    >> person a
    >> few weeks (rather than a whole team several years).
    >>
    >> The 99% figure is not made up, by the way. I have personally
    >> worked on a
    >> Web browser that comprised around half a million lines of
    >> code, only
    >> 5000 of which needed to be rewritten for each new platform. (I
    >> must add
    >> that I wasn't responsible for the design, but I salute those
    >> who were,
    >> because they made a fabulous job of it.)
    >>
    >> So, as you can see, the answer is indeed both "yes" and "no".
    >> I suggest
    >> you each agree to keep your stakes, because your bet has no
    >> clear
    >> winner.
    >>

    >
    > <OT>
    > I would suggest the opponent is closer to correct. Given the
    > context of
    > the question. Useful printing is< quite different on *nix and
    > Win/32,
    > in most cases.
    >
    > The code may be worth examining and testing. Richard may have
    > more
    > experience on simply opening a Win32 text printer than I have
    > or can
    > recall.
    > <OT/>


    So to just send a "CR" (carriage return) to LPT1 would look SO
    different in C-language source code for a Linux compiler,
    compared to C-language source code for a compiler in Windows,
    that someone with C-language proficiency wouldn't be able to
    decipher one from/or the other?
    Still scratching my head on this one.
     
    Bart, Jun 24, 2007
    #4
  5. Bart

    Bart Guest

    "Bart" <bborb@fusedotnet> wrote in message
    news:ca1da$467de278$d8442f1f$...
    > "Barry" <> wrote in message
    > news:...
    >>
    >> "Richard Heathfield" <> wrote in message
    >> news:...
    >>> Bart said:
    >>>
    >>>> Hello All,
    >>>> I had a buddy looking to write a program to manipulate a
    >>>> printer's movements. [...]
    >>>> I argued that C was a language and Linux/Windows were
    >>>> operating
    >>>> systems. A C-language program could be compiled to run in
    >>>> Linux
    >>>> with a Linux compiler, or it could be compiled to run in
    >>>> Windows
    >>>> with a Windows compiler. I think back to the infamous
    >>>> "Hello
    >>>> World" program (everybodies first program) and can't help
    >>>> but
    >>>> think it could be compiled to run in Linux with a Linux
    >>>> compiler
    >>>> on a Linux machine, or it could be compiled to run in
    >>>> Windows
    >>>> with a Windows compiler on a Windows machine. He disagrees.
    >>>
    >>> You're both right. Bear with me.
    >>>
    >>> #include <stdio.h>
    >>>
    >>> int main(void)
    >>> {
    >>> puts("Hello, world!");
    >>> return 0;
    >>> }
    >>>
    >>> This is a very, very, very simple example of a C program
    >>> which can
    >>> indeed be compiled on Linux with a Linux compiler or on
    >>> Windows with a
    >>> Windows compiler or a Mac with a Mac compiler or a mainframe
    >>> with a
    >>> mainframe compiler, and it'll work correctly on all of them,
    >>> without
    >>> modification. It's *portable* (i.e. you can carry it around
    >>> easily from
    >>> one system to another).
    >>>
    >>> That's why you're right. So why is your friend right, too?
    >>>
    >>> A great many tasks can be achieved with portable code. You
    >>> can write
    >>> entire compilers in portable code. There are, in fact, a
    >>> colossal
    >>> number of tasks that you can achieve in portable code.
    >>>
    >>> But not all.
    >>>
    >>> When you start talking to hardware, for example, things start
    >>> to get
    >>> sticky. The kind of code you need to talk to a printer on a
    >>> Linux
    >>> system is quite different to the code you need to talk to a
    >>> printer on
    >>> a Windows system.
    >>>
    >>> So when C programmers write programs that must access
    >>> non-portable
    >>> features, they tend to do it like this:
    >>>
    >>> +---------------------------------+
    >>> | application layer |
    >>> +---------------------------------+
    >>> | portable | abstraction |
    >>> | routines | layer |
    >>> +------------------+--------------+
    >>> | non-portable |
    >>> | routines |
    >>> +--------------+
    >>>
    >>> Then, when they need to move the program to another machine
    >>> or platform,
    >>> they rewrite the non-portable routines in a way that the new
    >>> machine or
    >>> platform will understand. The rest of the program can stay
    >>> untouched.
    >>>
    >>> If this is done well, even an inherently platform-dependent
    >>> program such
    >>> as a Web browser can be moved to a new platform with as much
    >>> as 99% of
    >>> the code remaining intact, and the rewrite might only take
    >>> one person a
    >>> few weeks (rather than a whole team several years).
    >>>
    >>> The 99% figure is not made up, by the way. I have personally
    >>> worked on a
    >>> Web browser that comprised around half a million lines of
    >>> code, only
    >>> 5000 of which needed to be rewritten for each new platform.
    >>> (I must add
    >>> that I wasn't responsible for the design, but I salute those
    >>> who were,
    >>> because they made a fabulous job of it.)
    >>>
    >>> So, as you can see, the answer is indeed both "yes" and "no".
    >>> I suggest
    >>> you each agree to keep your stakes, because your bet has no
    >>> clear
    >>> winner.
    >>>

    >>
    >> <OT>
    >> I would suggest the opponent is closer to correct. Given the
    >> context of
    >> the question. Useful printing is< quite different on *nix and
    >> Win/32,
    >> in most cases.
    >>
    >> The code may be worth examining and testing. Richard may have
    >> more
    >> experience on simply opening a Win32 text printer than I have
    >> or can
    >> recall.
    >> <OT/>

    >
    > So to just send a "CR" (carriage return) to LPT1 would look SO
    > different in C-language source code for a Linux compiler,
    > compared to C-language source code for a compiler in Windows,
    > that someone with C-language proficiency wouldn't be able to
    > decipher one from/or the other?
    > Still scratching my head on this one.

    Remember, we just want the printer to move (line feed, TAB,
    carriage return, etc.). No fancy GUI, no fonts, no printing AT
    ALL, nothing but send a single code, one at a time. For example,
    I want the printer to line feed three times. Simple code, then
    compiled, then when I double click on the application the printer
    line feeds three times, and thats it.
     
    Bart, Jun 24, 2007
    #5
  6. Bart

    Chad Guest

    On Jun 23, 6:08 am, Richard Heathfield <> wrote:
    > Bart said:
    >
    > > Hello All,
    > > I had a buddy looking to write a program to manipulate a
    > > printer's movements. [...]
    > > I argued that C was a language and Linux/Windows were operating
    > > systems. A C-language program could be compiled to run in Linux
    > > with a Linux compiler, or it could be compiled to run in Windows
    > > with a Windows compiler. I think back to the infamous "Hello
    > > World" program (everybodies first program) and can't help but
    > > think it could be compiled to run in Linux with a Linux compiler
    > > on a Linux machine, or it could be compiled to run in Windows
    > > with a Windows compiler on a Windows machine. He disagrees.

    >
    > You're both right. Bear with me.
    >
    > #include <stdio.h>
    >
    > int main(void)
    > {
    > puts("Hello, world!");
    > return 0;
    >
    > }
    >
    > This is a very, very, very simple example of a C program which can
    > indeed be compiled on Linux with a Linux compiler or on Windows with a
    > Windows compiler or a Mac with a Mac compiler or a mainframe with a
    > mainframe compiler, and it'll work correctly on all of them, without
    > modification. It's *portable* (i.e. you can carry it around easily from
    > one system to another).
    >
    > That's why you're right. So why is your friend right, too?
    >
    > A great many tasks can be achieved with portable code. You can write
    > entire compilers in portable code. There are, in fact, a colossal
    > number of tasks that you can achieve in portable code.
    >
    > But not all.
    >
    > When you start talking to hardware, for example, things start to get
    > sticky. The kind of code you need to talk to a printer on a Linux
    > system is quite different to the code you need to talk to a printer on
    > a Windows system.
    >
    > So when C programmers write programs that must access non-portable
    > features, they tend to do it like this:
    >
    > +---------------------------------+
    > | application layer |
    > +---------------------------------+
    > | portable | abstraction |
    > | routines | layer |
    > +------------------+--------------+
    > | non-portable |
    > | routines |
    > +--------------+
    >
    > Then, when they need to move the program to another machine or platform,
    > they rewrite the non-portable routines in a way that the new machine or
    > platform will understand. The rest of the program can stay untouched.
    >
    > If this is done well, even an inherently platform-dependent program such
    > as a Web browser can be moved to a new platform with as much as 99% of
    > the code remaining intact, and the rewrite might only take one person a
    > few weeks (rather than a whole team several years).
    >
    > The 99% figure is not made up, by the way. I have personally worked on a
    > Web browser that comprised around half a million lines of code, only
    > 5000 of which needed to be rewritten for each new platform. (I must add
    > that I wasn't responsible for the design, but I salute those who were,
    > because they made a fabulous job of it.)
    >
    > So, as you can see, the answer is indeed both "yes" and "no". I suggest
    > you each agree to keep your stakes, because your bet has no clear
    > winner.
    >


    I would just like to point out that in the second edition of the book
    "The C Programming Language" by K & R, in section 8.6, they have a
    Listing Directories example that follows that same basic design
    pattern that you just showed.


    Chad
     
    Chad, Jun 24, 2007
    #6
  7. Bart said:

    >
    > "Bart" <bborb@fusedotnet> wrote in message
    > news:ca1da$467de278$d8442f1f$...


    <snip>

    >> So to just send a "CR" (carriage return) to LPT1 would look SO
    >> different in C-language source code for a Linux compiler,
    >> compared to C-language source code for a compiler in Windows,
    >> that someone with C-language proficiency wouldn't be able to
    >> decipher one from/or the other?
    >> Still scratching my head on this one.


    Tell ya what - if you don't believe me, why not give it a whirl?

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Jun 24, 2007
    #7
  8. In article <ca1da$467de278$d8442f1f$>,
    Bart <bborb@fusedotnet> wrote:

    >So to just send a "CR" (carriage return) to LPT1 would look SO
    >different in C-language source code for a Linux compiler,
    >compared to C-language source code for a compiler in Windows,
    >that someone with C-language proficiency wouldn't be able to
    >decipher one from/or the other?


    I'm not familiar with Linux, but I've worked with several Unix
    systems. Not one of the the ones I worked with had LPT1, so
    Yes, if you had working code on Windows then it would have to
    look very different than the Unix code to work with a non-existant
    device.

    What is LPT1 anyhow? A parallel printer? If so, is it bidirectional
    with the status information obtained by reading the parallel port,
    or is it unidirecitonal with the status information obtained
    by reading the parallel port status lines? Is LPT1 a serial printer?
    What baud rate, what parity, how many nulls have to be sent after
    sending a line, is it monodirectional or bidirectional printing?
    Is LPT1 a printer connected through a USB port? If so, what kind of
    work do you have to go through to detect it's presence and
    USB device designation? Do the minor device numbers for Linux
    USB devices partially encode any control information such as
    (e.g.,) whether the device is to be talked to vis USB 1.1 or USB 2.0 ?
    If you had complete Linux source code for driving the printer,
    would that give you any useful information about what you have to
    go through on Windows to enter the device into the registry and
    connect it up properly to the Printer Control Panel?
    --
    Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
     
    Walter Roberson, Jun 24, 2007
    #8
  9. Bart

    Eric Guest

    Bart wrote:

    >
    > "Bart" <bborb@fusedotnet> wrote in message
    > news:ca1da$467de278$d8442f1f$...
    >> "Barry" <> wrote in message
    >> news:...
    >>>
    >>> "Richard Heathfield" <> wrote in message
    >>> news:...
    >>>> Bart said:
    >>>>
    >>>>> Hello All,
    >>>>> I had a buddy looking to write a program to manipulate a
    >>>>> printer's movements. [...]
    >>>>> I argued that C was a language and Linux/Windows were
    >>>>> operating
    >>>>> systems. A C-language program could be compiled to run in
    >>>>> Linux
    >>>>> with a Linux compiler, or it could be compiled to run in
    >>>>> Windows
    >>>>> with a Windows compiler. I think back to the infamous
    >>>>> "Hello
    >>>>> World" program (everybodies first program) and can't help
    >>>>> but
    >>>>> think it could be compiled to run in Linux with a Linux
    >>>>> compiler
    >>>>> on a Linux machine, or it could be compiled to run in
    >>>>> Windows
    >>>>> with a Windows compiler on a Windows machine. He disagrees.
    >>>>
    >>>> You're both right. Bear with me.
    >>>>
    >>>> #include <stdio.h>
    >>>>
    >>>> int main(void)
    >>>> {
    >>>> puts("Hello, world!");
    >>>> return 0;
    >>>> }
    >>>>
    >>>> This is a very, very, very simple example of a C program
    >>>> which can
    >>>> indeed be compiled on Linux with a Linux compiler or on
    >>>> Windows with a
    >>>> Windows compiler or a Mac with a Mac compiler or a mainframe
    >>>> with a
    >>>> mainframe compiler, and it'll work correctly on all of them,
    >>>> without
    >>>> modification. It's *portable* (i.e. you can carry it around
    >>>> easily from
    >>>> one system to another).
    >>>>
    >>>> That's why you're right. So why is your friend right, too?
    >>>>
    >>>> A great many tasks can be achieved with portable code. You
    >>>> can write
    >>>> entire compilers in portable code. There are, in fact, a
    >>>> colossal
    >>>> number of tasks that you can achieve in portable code.
    >>>>
    >>>> But not all.
    >>>>
    >>>> When you start talking to hardware, for example, things start
    >>>> to get
    >>>> sticky. The kind of code you need to talk to a printer on a
    >>>> Linux
    >>>> system is quite different to the code you need to talk to a
    >>>> printer on
    >>>> a Windows system.
    >>>>
    >>>> So when C programmers write programs that must access
    >>>> non-portable
    >>>> features, they tend to do it like this:
    >>>>
    >>>> +---------------------------------+
    >>>> | application layer |
    >>>> +---------------------------------+
    >>>> | portable | abstraction |
    >>>> | routines | layer |
    >>>> +------------------+--------------+
    >>>> | non-portable |
    >>>> | routines |
    >>>> +--------------+
    >>>>
    >>>> Then, when they need to move the program to another machine
    >>>> or platform,
    >>>> they rewrite the non-portable routines in a way that the new
    >>>> machine or
    >>>> platform will understand. The rest of the program can stay
    >>>> untouched.
    >>>>
    >>>> If this is done well, even an inherently platform-dependent
    >>>> program such
    >>>> as a Web browser can be moved to a new platform with as much
    >>>> as 99% of
    >>>> the code remaining intact, and the rewrite might only take
    >>>> one person a
    >>>> few weeks (rather than a whole team several years).
    >>>>
    >>>> The 99% figure is not made up, by the way. I have personally
    >>>> worked on a
    >>>> Web browser that comprised around half a million lines of
    >>>> code, only
    >>>> 5000 of which needed to be rewritten for each new platform.
    >>>> (I must add
    >>>> that I wasn't responsible for the design, but I salute those
    >>>> who were,
    >>>> because they made a fabulous job of it.)
    >>>>
    >>>> So, as you can see, the answer is indeed both "yes" and "no".
    >>>> I suggest
    >>>> you each agree to keep your stakes, because your bet has no
    >>>> clear
    >>>> winner.
    >>>>
    >>>
    >>> <OT>
    >>> I would suggest the opponent is closer to correct. Given the
    >>> context of
    >>> the question. Useful printing is< quite different on *nix and
    >>> Win/32,
    >>> in most cases.
    >>>
    >>> The code may be worth examining and testing. Richard may have
    >>> more
    >>> experience on simply opening a Win32 text printer than I have
    >>> or can
    >>> recall.
    >>> <OT/>

    >>
    >> So to just send a "CR" (carriage return) to LPT1 would look SO
    >> different in C-language source code for a Linux compiler,
    >> compared to C-language source code for a compiler in Windows,
    >> that someone with C-language proficiency wouldn't be able to
    >> decipher one from/or the other?
    >> Still scratching my head on this one.

    > Remember, we just want the printer to move (line feed, TAB,
    > carriage return, etc.). No fancy GUI, no fonts, no printing AT
    > ALL, nothing but send a single code, one at a time. For example,
    > I want the printer to line feed three times. Simple code, then
    > compiled, then when I double click on the application the printer
    > line feeds three times, and thats it.

    Whats the printer port at 278? (Cripes its been a long time since i did dos
    work) anyway, the method you use in windows to send bytes to that port is
    not the same way you send bytes to the port in linux. Windows is going to
    make you jump through hoops before you can do that ie probably via
    createfile and its ilk, in linux there is no such api call - not even
    close, because linux does things differently (and in my opinion - better)
    Eric
     
    Eric, Jun 25, 2007
    #9
  10. Bart

    John Gordon Guest

    In <f274f$467de8f4$d8442d5e$> "Bart" <bborb@fusedotnet> writes:

    > I want the printer to line feed three times. Simple code, then
    > compiled, then when I double click on the application the printer
    > line feeds three times, and thats it.


    Part of this is very simple and portable, and part isn't.

    The simple part is the linefeed characters themselves. A simple printf
    statement will do the trick nicely.

    However, the non-portable part is this: where do you *send* those linefeed
    characters?

    On some systems, the printer might be represented by a disk file that can
    be opened for writing, just like any other file. But even in this simple
    scenario, the name of the disk file will vary from one system to another.

    On other systems, accessing the printer might require using a specialized
    API.

    And if the printer is networked rather than being directly attached, that
    can add another layer of complexity altogether.

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
     
    John Gordon, Jun 25, 2007
    #10
    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. Sham Ramakrishnan

    SOAP remote method calls? the best bet?

    Sham Ramakrishnan, Jul 2, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    355
    Sham Ramakrishnan
    Jul 2, 2003
  2. Daniel Bass
    Replies:
    2
    Views:
    3,769
    dave wanta
    Jul 4, 2003
  3. Raja Balaji R

    information bet. aspnet pages

    Raja Balaji R, Jan 9, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    330
    Kevin Spencer
    Jan 9, 2004
  4. =?Utf-8?B?RmF0Ym95Y2FudGVlbg==?=

    How to add dynamic event(asp.bet)

    =?Utf-8?B?RmF0Ym95Y2FudGVlbg==?=, Jan 21, 2004, in forum: ASP .Net
    Replies:
    5
    Views:
    2,100
    Marshal Antony
    Jan 21, 2004
  5. G Dean Blake

    Bet nobody is smart enough to solve this!!

    G Dean Blake, Jan 15, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    410
    G Dean Blake
    Jan 15, 2005
Loading...

Share This Page