Re: Settle a Bet

Bart wrote:


"Bart" <bborb@fusedotnet> wrote in message
news:ca1da$467de278$d8442f1f$22917@xxxxxxxxxxx
"Barry" <barryg@xxxxxxxxxxxxxxxxxx> wrote in message
news:137rgtofb5qvnc9@xxxxxxxxxxxxxxxxxxxxx

"Richard Heathfield" <rjh@xxxxxxxxxxxxxxx> wrote in message
news:fb6dnbfycdIDh-DbnZ2dnUVZ8smonZ2d@xxxxxxxxx
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

.

Relevant Pages

  • Re: Why is it dangerous?
    ... When I compile a program from our C course with a windows compiler ... Is linux more dangerous than windows? ... to the first character in a buffer, and stores an entire line from stdin ...
    (comp.lang.c)
  • Re: C++ with VS.NET and Twilight of the Microsoft Era
    ... this has to do diddly squat with the compiler used to compile ... VC6 is of the same generation. ... Most of the time we use the best tool for the job, and on windows, VC++ is ... tried to use GDB and DDD on linux to debug multithreaded frameworks. ...
    (microsoft.public.vc.language)
  • Re: Einsteig in Microcontroller und Programmierung
    ... Linux Format nix anfangen kann. ... Problem und der Ignoranz von anderen Systemen für Quellcode Änderungen ... Und wenn ein Compiler abkackt, weil er ohne CR nicht leben kann, ist der ... Unter Windows konzernweit entwickelt und compiliert. ...
    (de.sci.electronics)
  • Re: interface
    ... Writing portable code has nothing to do with the operating system or ... That having said, if you want to use only one compiler, GCC is a very ... Don't mess around with the Windows API. ... Even if you're working only on one platform, ...
    (comp.programming)
  • Re: Seeing VERSIONINFO under Vista?
    ... All operating systems since 1988 have been based on Windows NT. ... Maybe I'll try again with a new Linux distro... ... People told me "You know compiler technology. ...
    (microsoft.public.vc.mfc)