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 9 1251
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" <rj*@see.sig.invalidwrote in message
news:fb******************************@bt.com...
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" <ba****@nullhighstream.netwrote in message
news:13*************@corp.supernews.com...
>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:fb******************************@bt.com...
>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" <bborb@fusedotnetwrote in message
news:ca***************************@FUSE.NET...
"Barry" <ba****@nullhighstream.netwrote in message
news:13*************@corp.supernews.com...
>> "Richard Heathfield" <rj*@see.sig.invalidwrote in message news:fb******************************@bt.com...
>>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.
On Jun 23, 6:08 am, Richard Heathfield <r...@see.sig.invalidwrote:
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
Bart said:
>
"Bart" <bborb@fusedotnetwrote in message
news:ca***************************@FUSE.NET...
<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
In article <ca***************************@FUSE.NET>,
Bart <bborb@fusedotnetwrote:
>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
Bart wrote:
>
"Bart" <bborb@fusedotnetwrote in message
news:ca***************************@FUSE.NET...
>"Barry" <ba****@nullhighstream.netwrote in message news:13*************@corp.supernews.com...
>>> "Richard Heathfield" <rj*@see.sig.invalidwrote in message news:fb******************************@bt.com.. . 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
In <f2***************************@FUSE.NET"Bart" <bborb@fusedotnetwrites:
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 go****@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies" This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: mathilda |
last post by:
My boss has been adamant that SELECT DISTINCT is a faster query than
SELECT all other factors being equal. I disagree. We are linking an
Access front end to a SQL Server back end and normally are...
|
by: scorpion53061 |
last post by:
in my head......
I need my application to work with Office 97, 2000, XP and 2003 versions of
MS Word and MS Excel.
IN order to acomplish this I have to install in different folders:
1....
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |