Settle a Bet

[Bart]

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

 

[Richard Heathfield]

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.

 

[Barry]

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/>

 

[Bart]

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]

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.

 

[Chad]

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

 

[Richard Heathfield]

Bart said:

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

 

[Walter Roberson]

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?

 

[Eric]

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

 

[John Gordon]

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.