By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,968 Members | 1,871 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,968 IT Pros & Developers. It's quick & easy.

How to talk to hardware devices in C

P: n/a
When programming in C (not C++) how does one send information to a
hardware device such as a video card or modem? How is this done in
Linux C programming versus Microsoft C programming?

Aug 6 '07 #1
Share this Question
Share on Google+
41 Replies


P: n/a
x01001x wrote:
When programming in C (not C++) how does one send information to a
hardware device such as a video card or modem? How is this done in
Linux C programming versus Microsoft C programming?
Interfacing with hardware is almost always architecture and operating system
specific and is thus off-topic to this group. You might try a group for
your system like <news:comp.os.linux.development.appsor
<news:comp.os.ms-windows.programmer.win32or <news:comp.arch>.

Aug 6 '07 #2

P: n/a

"x01001x" <xe****@softhome.netwrote in message
news:11**********************@b79g2000hse.googlegr oups.com...
When programming in C (not C++) how does one send information to a
hardware device such as a video card or modem? How is this done in
Linux C programming versus Microsoft C programming?
In the same way, essentially.
Let a third party, maybe the OS authors or maybe someone else, produce a
C-callable library that makes the hardware do things. For instance under
Linux you can call Xlib to open a window and draw pixels on it.

If you are asking how to implement something like Xlib itself, the answer is
with a mixture of C and assembler, that maybe writes to the video memory on
vertical retrace interrupts or similar - I no longer know exactly how it is
done.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Aug 6 '07 #3

P: n/a
Interfacing with hardware is almost always architecture and operating system
specific and is thus off-topic to this group. You might try a group for
your system like <news:comp.os.linux.development.appsor
<news:comp.os.ms-windows.programmer.win32or <news:comp.arch>.
You've really GOT to be nuts.
I came all the way to the holy comp.lang.c and asked a SPECIFIC
question about sending DIRECT communication to hardware and you give
me that?
GEEZ just throw me a useful C command or something! Even a BASH
command like cat post >/dev/null would be more useful than that.

LOOK, in the more professional world of IT, we have reserved issues
concerning the DIRECT COMMUNICATION of code to hardware.
I understand this is what concerns the HARDWARE ABSTRACTION LAYER. It
is a matter of SECURITY.

Cmon guy, I even told you the 2 main pieces of hardware, modems and
video cards.
I'm not going to give you guys a specific spec of either device,
except to say I am talking about a modem that would work like a 28.8
modem.

We've found this regards libraries. Please give information regarding
how to obtain these libaries from either hardware manufacturers or
Microsoft corp. Obviously, this is so easy for linux we should focus
more on Microsoft if we want to learn something new. Also, is the
information regarding the functions contained in the libaries more
often printed in hard-copy, or in an ASCII file?

Can I get a call script for calling USRobotics/3Com or Microsoft? Are
you all able to follow my train of thought?

Aug 9 '07 #4

P: n/a
x01001x wrote:
[what he wrote has been snipped]

Is there something lurking under this bridge?
Aug 9 '07 #5

P: n/a
On Aug 9, 10:41 am, Mark Bluemel <mark_blue...@pobox.comwrote:
x01001x wrote:

[what he wrote has been snipped]

Is there something lurking under this bridge?
Yeah chief some wicked code!
May I have a job?

Aug 9 '07 #6

P: n/a
x01001x wrote, On 09/08/07 16:25:
>Interfacing with hardware is almost always architecture and operating system
specific and is thus off-topic to this group. You might try a group for
your system like <news:comp.os.linux.development.appsor
<news:comp.os.ms-windows.programmer.win32or <news:comp.arch>.

You've really GOT to be nuts.
No, whoever said that was being completely sensible.
I came all the way to the holy comp.lang.c and asked a SPECIFIC
question about sending DIRECT communication to hardware and you give
me that?
What you can do and how you can do it depends on the OS.
GEEZ just throw me a useful C command or something! Even a BASH
command like cat post >/dev/null would be more useful than that.

LOOK, in the more professional world of IT, we have reserved issues
concerning the DIRECT COMMUNICATION of code to hardware.
I understand this is what concerns the HARDWARE ABSTRACTION LAYER. It
is a matter of SECURITY.
<snip>

It also depends on the OS.

Since it depends on the OS you need to ask where people who know about
the OS will respond. People here are here to talk about C not about any
particular OS.
--
Flash Gordon
Aug 9 '07 #7

P: n/a
In the same way, essentially.
Let a third party, maybe the OS authors or maybe someone else, produce a
C-callable library that makes the hardware do things. For instance under
Linux you can call Xlib to open a window and draw pixels on it.
Is this library always a .dll file in Microsoft or a .h file in linux?

Aug 9 '07 #8

P: n/a
In article <11**********************@r34g2000hsd.googlegroups .com>,
x01001x <xe****@softhome.netwrites
>
>Interfacing with hardware is almost always architecture and operating system
specific and is thus off-topic to this group. You might try a group for
your system like <news:comp.os.linux.development.appsor
<news:comp.os.ms-windows.programmer.win32or <news:comp.arch>.

You've really GOT to be nuts.
I came all the way to the holy comp.lang.c and asked a SPECIFIC
question about sending DIRECT communication to hardware and you give
me that?
GEEZ just throw me a useful C command or something! Even a BASH
command like cat post >/dev/null would be more useful than that.

LOOK, in the more professional world of IT, we have reserved issues
concerning the DIRECT COMMUNICATION of code to hardware.
I understand this is what concerns the HARDWARE ABSTRACTION LAYER. It
is a matter of SECURITY.

Cmon guy, I even told you the 2 main pieces of hardware, modems and
video cards.
I'm not going to give you guys a specific spec of either device,
except to say I am talking about a modem that would work like a 28.8
modem.

We've found this regards libraries. Please give information regarding
how to obtain these libaries from either hardware manufacturers or
Microsoft corp. Obviously, this is so easy for linux we should focus
more on Microsoft if we want to learn something new. Also, is the
information regarding the functions contained in the libaries more
often printed in hard-copy, or in an ASCII file?

Can I get a call script for calling USRobotics/3Com or Microsoft? Are
you all able to follow my train of thought?
Most modems are addressed via a serial port using the V25 or Hayes
command set.

Video cards I have no idea about.

You have to excuse the OT net Nannies on here. However they do have a
point that it does depend on your OS or compiler as to the calls used.
On the Keil C51 I would use direc register manipulation and putC/getc
which is not the way you do it in windows. UNIX will be different
again.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Aug 9 '07 #9

P: n/a
In article <11**********************@k79g2000hse.googlegroups .com>,
x01001x <xe****@softhome.netwrote:
>In the same way, essentially.
Let a third party, maybe the OS authors or maybe someone else, produce a
C-callable library that makes the hardware do things. For instance under
Linux you can call Xlib to open a window and draw pixels on it.
>Is this library always a .dll file in Microsoft or a .h file in linux?
No to both. There are non .dll ways of doing it in Microsoft Windows;
and libraries are never .h files in Linux (unless someone is
trying to be deliberately confusing.) There are several ways that
it can be done under Linux, some of which are version or compiler
specific; the details are part of the Linux architecture, not part of C,
so you should consult an appropriate Linux development newsgroup.

--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
Aug 9 '07 #10

P: n/a
x01001x wrote:
>
>Interfacing with hardware is almost always architecture and
operating system specific and is thus off-topic to this group.
You might try a group for your system like
<news:comp.os.linux.development.appsor
<news:comp.os.ms-windows.programmer.win32or <news:comp.arch>.

You've really GOT to be nuts.
I came all the way to the holy comp.lang.c and asked a SPECIFIC
question about sending DIRECT communication to hardware and you
give me that?
No, you are the one that is off. Hardware devices are system
specific. This newsgroup is about the _language_ C, and
specifically excludes such specific matters.

comp.arch.embedded might be suitable, or some group that discusses
your actual system.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Aug 9 '07 #11

P: n/a
In article <11**********************@r34g2000hsd.googlegroups .com>,
x01001x <xe****@softhome.netwrote:
>You've really GOT to be nuts.
I came all the way to the holy comp.lang.c and asked a SPECIFIC
question about sending DIRECT communication to hardware and you give
me that?
No you didn't. You asked a -general- question about communicating
with hardware -somehow-. You did not specify "direction communication",
and your two hardware devices were obviously just examples, so
the question was -general- not -specific-.
Suppose you had gone to a automotive newsgroup and asked "how do I
control devices such as the wheels or brakes in a Honda?" Now is that a
Honda passenger car, truck, or racing car? What year and model is it?
Are you talking about mechanical linkages or about the controlling the
microprocessor that directs the ABS (anti-lock braking system)? Are you
talking about interfacing with the cardbus internal data communication
system? Are you trying to get read access to the diagnostics module, or
are you trying to override the anti-smog device?

There is no one-size-fits-all answer to such a general question:
the methods are going to depend a lot on exactly what you are trying
to do and on exactly what hardware you have.

Perhaps it would make more sense if I pointed out that Linux does
not have a Hardware Abstraction Layer, and that Linux runs on a large
number of very different devices, some of which have unique methods of
accessing hardware.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
Aug 9 '07 #12

P: n/a
On Aug 6, 3:10 am, x01001x <xem...@softhome.netwrote:
When programming in C (not C++) how does one send information to a
hardware device such as a video card or modem? How is this done in
Linux C programming versus Microsoft C programming?
Take a look at following C code which directly communicate with
Monitor and Fills the entire screen with letter 'A'. You don't need
the printf statement.

#include<stdio.h>
#include<conio.h>

void main()
{
int i;
char far *vidmem=0xB8000000;
for(i=0;i<=3999; i=i+2)
*(vidmem+i)='A';
}

for more C programs and assembly language codes which directly
communicates with hardware go to

http://geocities.com/t1softwares/cprg.htm

and http://geocities.com/t1softwares/asemprg.htm
Aug 9 '07 #13

P: n/a
Bliton wrote, On 09/08/07 18:34:
On Aug 6, 3:10 am, x01001x <xem...@softhome.netwrote:
>When programming in C (not C++) how does one send information to a
hardware device such as a video card or modem? How is this done in
Linux C programming versus Microsoft C programming?
^^^^^^^
>
Take a look at following C code which directly communicate with
Monitor and Fills the entire screen with letter 'A'. You don't need
the printf statement.

#include<stdio.h>
#include<conio.h>
conio.h is traditionally associated with some compilers for DOS and the
OP asked about Linux.
void main()
{
int i;
char far *vidmem=0xB8000000;
for(i=0;i<=3999; i=i+2)
*(vidmem+i)='A';
}
markg@brenda:~$ gcc -ansi -pedantic t.c
t.c:2:18: error: conio.h: No such file or directory
t.c: In function ‘main’:
t.c:7: warning: ISO C forbids nested functions
t.c:7: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
‘*’ token
t.c:7: error: ‘vidmem’ undeclared (first use in this function)
t.c:7: error: (Each undeclared identifier is reported only once
t.c:7: error: for each function it appears in.)
t.c:5: warning: return type of ‘main’ is not ‘int’
markg@brenda:~$

Doesn't seem to work too well on a Linux box which is what the OP asked
about. If I remove the inclusion of conie.h (and the unneeded inclusion
of stdio.h), which is not needed as well as being non-standard, remove
the use of 'far' which is also non-standard, add in the cast required to
convert an integer to a pointer and correct the return type of main we get:
markg@brenda:~$ cat t.c
int main(void)
{
int i;
char *vidmem=(char*)0xB8000000;
for(i=0;i<=3999; i=i+2)
*(vidmem+i)='A';
return 0;
}
markg@brenda:~$ gcc -ansi -pedantic -Wall -Wextra -O t.c
markg@brenda:~$ ./a.out
Segmentation fault (core dumped)
markg@brenda:~$

So it still fails spectacularly. Finally, I happen to remember that not
all video cards had the video memory starting at the same location in
all modes, so even on DOS it might not always do what you thought.
>
for more C programs and assembly language codes which directly
communicates with hardware go to

http://geocities.com/t1softwares/cprg.htm
The other examples I looked at from this were also examples of how NOT
to write C and C++ programs (some files have the extension .CPP) since
none of them will compile on this machine.
and http://geocities.com/t1softwares/asemprg.htm
I can't be bothered to brush off my assembler skills to see if the
assembler is as bad.
--
Flash Gordon
Aug 9 '07 #14

P: n/a
>>>>"B" == Bliton <sh********@gmail.comwrites:

BTake a look at following C code which directly communicate with
BMonitor and Fills the entire screen with letter 'A'. You don't
Bneed the printf statement.

It doesn't work! I ran it on my Mac and it just said Segmentation fault.
Should I try it on my DeathStation 9000?

(Hint: this newsgroup discusses portable standard C, and the program
you provided is neither.)

Charlton


--
Charlton Wilbur
cw*****@chromatico.net
Aug 9 '07 #15

P: n/a

"x01001x" <xe****@softhome.netwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
>In the same way, essentially.
Let a third party, maybe the OS authors or maybe someone else, produce a
C-callable library that makes the hardware do things. For instance under
Linux you can call Xlib to open a window and draw pixels on it.

Is this library always a .dll file in Microsoft or a .h file in linux?
No.
Normally you just include the .h file, which contains little more than
function prototypes, and the compiler handles the rest.
Occasionally things are not set up as they ought to be and you've got to
specify the library, the path to the directory the library files are kept
in, whether it is a static or a shared library, whether you've paid the
vendor his shekels to allow you to link it in, and so forth.
Library files proper are basically compiled functions with as little bit of
C information retained in them to allow the compier to link the functions by
name. dlls are dynamic link libraries, "dynamic" means that they are not
included in the program but linked when the program is launched. Hence bug
fixes or enhancements to the library functions don't require a recompile.
Static libraries are included in your program at compile time, hence you
don't need to know if the user has a version of the library on his machine.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Aug 9 '07 #16

P: n/a
Walter Roberson wrote:
In article <11**********************@k79g2000hse.googlegroups .com>,
x01001x <xe****@softhome.netwrote:
>>In the same way, essentially.
Let a third party, maybe the OS authors or maybe someone else, produce a
C-callable library that makes the hardware do things. For instance under
Linux you can call Xlib to open a window and draw pixels on it.
>Is this library always a .dll file in Microsoft or a .h file in linux?

No to both....
Either I'm completely paranoid or you have just been trolled. My belief
is that I'm not paranoid...
Aug 10 '07 #17

P: n/a
No, you are the one that is off. Hardware devices are system
specific. This newsgroup is about the _language_ C, and
specifically excludes such specific matters.
Yes, but it's OK because I was aware of this. I posted here because I
wanted the opinion of the comp.lang.c community regarding this issue.

Really it's OK...

Aug 10 '07 #18

P: n/a
No.
Normally you just include the .h file, which contains little more than
function prototypes, and the compiler handles the rest.
Yes this is what I was aware of too. I believe this process is used in
C and C++, although I mainly want to discuss just plain C in this
thread.
Someone before said linux never used .h libraries.
This sounds very ominous.
Isn't it always
#include hayesmodem.h
#include library.h
#include libcat.h

or something like that?

Aug 10 '07 #19

P: n/a
x01001x <xe****@softhome.netwrites:
>No, you are the one that is off. Hardware devices are system
specific. This newsgroup is about the _language_ C, and
specifically excludes such specific matters.

Yes, but it's OK because I was aware of this. I posted here because I
wanted the opinion of the comp.lang.c community regarding this issue.
The comp.lang.c community has no opinion regarding this issue.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 10 '07 #20

P: n/a
x01001x <xe****@softhome.netwrites:
[...]
Someone before said linux never used .h libraries.
This sounds very ominous.
Isn't it always
#include hayesmodem.h
#include library.h
#include libcat.h

or something like that?
Headers are not libraries.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 10 '07 #21

P: n/a
x01001x wrote, On 10/08/07 09:22:
>No, you are the one that is off. Hardware devices are system
specific. This newsgroup is about the _language_ C, and
specifically excludes such specific matters.

Yes, but it's OK because I was aware of this. I posted here because I
wanted the opinion of the comp.lang.c community regarding this issue.

Really it's OK...
Ah, so you think it is OK to post off topic questions as long as you
know they are off topic? Why not just have one big group alt.everything
then as it is OK to post anything to any group anyway?
--
Flash Gordon
Aug 10 '07 #22

P: n/a
x01001x wrote, On 10/08/07 09:24:
>No.
Normally you just include the .h file, which contains little more than
function prototypes, and the compiler handles the rest.

Yes this is what I was aware of too. I believe this process is used in
C and C++, although I mainly want to discuss just plain C in this
thread.
Someone before said linux never used .h libraries.
This sounds very ominous.
Isn't it always
#include hayesmodem.h
#include library.h
#include libcat.h

or something like that?
No, see the post you were responding to. The .h files are not libraries
in Linux any more than they are in Windows, AIX, or any other system.
--
Flash Gordon
Aug 10 '07 #23

P: n/a
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>x01001x <xe****@softhome.netwrites:
>>No, you are the one that is off. Hardware devices are system
specific. This newsgroup is about the _language_ C, and
specifically excludes such specific matters.

Yes, but it's OK because I was aware of this. I posted here because I
wanted the opinion of the comp.lang.c community regarding this issue.

The comp.lang.c community has no opinion regarding this issue.
What he means is he doesn't

The community does.
Keith you speak for your self and a couple of others NOT the community
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Aug 10 '07 #24

P: n/a
x01001x wrote:
>
>No.
Normally you just include the .h file, which contains little more than
function prototypes, and the compiler handles the rest.

Yes this is what I was aware of too. I believe this process is used in
C and C++, although I mainly want to discuss just plain C in this
thread.
Someone before said linux never used .h libraries.
The *.h files are _headers_, not libraries. They contain declarations
necessary to properly use the corresponding library or object file. The
libraries themselves usually end with a '.a' or '.so' suffix on UNIXes
and '.lib' or '.dll' under Windows.

<OT>
For example to use the GNU Scientific library, (GSL), you need to include
the gsl.h header and link your code with the 'libgsl.a' or 'libgsl.so'
object file. Details may vary from system to system.
</OT>
Aug 10 '07 #25

P: n/a
Chris Hills <ch***@phaedsys.orgwrote:
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
x01001x <xe****@softhome.netwrites:
>No, you are the one that is off. Hardware devices are system
specific. This newsgroup is about the _language_ C, and
specifically excludes such specific matters.

Yes, but it's OK because I was aware of this. I posted here because I
wanted the opinion of the comp.lang.c community regarding this issue.
The comp.lang.c community has no opinion regarding this issue.

What he means is he doesn't

The community does.

Keith you speak for your self and a couple of others NOT the community
And who, pray, is this community, then? Apart from a handful of known
(and occasionally self-confessed) trolls, one or two kooks and spammers,
and you, I know of nobody who is a regular in this newsgroup who
wouldn't mostly agree with Keith.

Richard
Aug 10 '07 #26

P: n/a
x01001x <xe****@softhome.netwrote:

[ Please do not snip attributions unless you also snip the corresponding
contents. ]
No.
Normally you just include the .h file, which contains little more than
function prototypes, and the compiler handles the rest.

Yes this is what I was aware of too. I believe this process is used in
C and C++, although I mainly want to discuss just plain C in this
thread.
Apparently not, because plain C doesn't allow you to talk directly to
hardware devices. C-on-MSDOS may, and C-on-Linux may or may not, but C,
/per se/, does not.
Someone before said linux never used .h libraries.
That someone made four big mistakes in one, then.
This sounds very ominous.
No, it sounds stupid. It neither predicts nor promises anything, good
nor bad. Therefore, it is not ominous.

As for stupid: .h-files are headers, not libraries; whether they are
used or not is not controlled by the OS, but by the implementation; the
Standard requires the presence of at least the Standard headers with
names ending in .h, although it does not require that they be actual
files; most Linux-borne C implementations (all I know of, in fact) do in
fact use real files for their .h headers.

Richard
Aug 10 '07 #27

P: n/a
Chris Hills <ch***@phaedsys.orgwrites:
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>>x01001x <xe****@softhome.netwrites:
>>>No, you are the one that is off. Hardware devices are system
specific. This newsgroup is about the _language_ C, and
specifically excludes such specific matters.

Yes, but it's OK because I was aware of this. I posted here because I
wanted the opinion of the comp.lang.c community regarding this issue.

The comp.lang.c community has no opinion regarding this issue.

What he means is he doesn't

The community does.

Keith you speak for your self and a couple of others NOT the community
So you speak for the community?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 10 '07 #28

P: n/a
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>Chris Hills <ch***@phaedsys.orgwrites:
>In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>>>x01001x <xe****@softhome.netwrites:
No, you are the one that is off. Hardware devices are system
specific. This newsgroup is about the _language_ C, and
specifically excludes such specific matters.

Yes, but it's OK because I was aware of this. I posted here because I
wanted the opinion of the comp.lang.c community regarding this issue.

The comp.lang.c community has no opinion regarding this issue.

What he means is he doesn't

The community does.

Keith you speak for your self and a couple of others NOT the community

So you speak for the community?
No, Like you I speak for my self.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Aug 10 '07 #29

P: n/a
The comp.lang.c community has no opinion regarding this issue.
These are not the droids you are looking for.

Aug 13 '07 #30

P: n/a
On Aug 10, 3:36 am, Keith Thompson <ks...@mib.orgwrote:
x01001x <xem...@softhome.netwrites:

[...]
Someone before said linux never used .h libraries.
This sounds very ominous.
Isn't it always
#include hayesmodem.h
#include library.h
#include libcat.h
or something like that?

Headers are not libraries.
What's the difference? You could think better to explain this kind of
stuff when arguing a point,
especially considering code.

Aug 13 '07 #31

P: n/a
the comp.lang.c community regarding this issue.
>
Really it's OK...

Ah, so you think it is OK to post off topic questions as long as you
know they are off topic?
No, the rule I normally follow is no binaries on non-binary
newsgroups.
I am a big fan of UUENCODE, however people act like THAT is the real
sin on USENET.

Aug 13 '07 #32

P: n/a
x01001x wrote, On 13/08/07 18:44:
On Aug 10, 3:36 am, Keith Thompson <ks...@mib.orgwrote:
>x01001x <xem...@softhome.netwrites:

[...]
>>Someone before said linux never used .h libraries.
This sounds very ominous.
Isn't it always
#include hayesmodem.h
#include library.h
#include libcat.h
or something like that?
Headers are not libraries.

What's the difference? You could think better to explain this kind of
stuff when arguing a point,
especially considering code.
What is the difference between a sign I used to pass regularly that said
"You are now entering Hadliegh" and the town named Hadliegh? Or even the
difference between the sign on the bus saying "Hadliegh" and the actual
town?
--
Flash Gordon
Aug 13 '07 #33

P: n/a
On Mon, 13 Aug 2007 10:45:15 -0700, x01001x <xe****@softhome.net>
wrote:
>the comp.lang.c community regarding this issue.
>>
Really it's OK...

Ah, so you think it is OK to post off topic questions as long as you
know they are off topic?

No, the rule I normally follow is no binaries on non-binary
newsgroups.
I am a big fan of UUENCODE, however people act like THAT is the real
sin on USENET.
Apparently you have no wish to either contribute or learn. Bye, now.

--
Al Balmer
Sun City, AZ
Aug 13 '07 #34

P: n/a
On Mon, 13 Aug 2007 10:44:04 -0700, in comp.lang.c , x01001x
<xe****@softhome.netwrote:
>On Aug 10, 3:36 am, Keith Thompson <ks...@mib.orgwrote:
>x01001x <xem...@softhome.netwrites:

[...]
Someone before said linux never used .h libraries.

Headers are not libraries.

What's the difference?
This is a FAQ
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Aug 13 '07 #35

P: n/a
x01001x <xe****@softhome.netwrites:
On Aug 10, 3:36 am, Keith Thompson <ks...@mib.orgwrote:
>x01001x <xem...@softhome.netwrites:

[...]
Someone before said linux never used .h libraries.
This sounds very ominous.
Isn't it always
#include hayesmodem.h
#include library.h
#include libcat.h
or something like that?

Headers are not libraries.

What's the difference? You could think better to explain this kind of
stuff when arguing a point,
especially considering code.
Since you are being rude (deliberately posting off-topic material),
I'm not inclined to be particularly helpful or to engage you in any
lengthy conversation.

If you want to ask about libraries on Linux, try a Linux-specific
newsgroup.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 13 '07 #36

P: n/a
On Aug 6, 3:10 pm, x01001x <xem...@softhome.netwrote:
When programming in C (not C++) how does one send information to a
hardware device such as a video card or modem? How is this done in
Linux C programming versus Microsoft C programming?
You need to look into the hardware device datasheet and program
accordingly as per your requirement.
The question is very generic.

Lot of ways of communication protocols are there.
I2C, SPI, CAN, UART, RS232, RS485, MODBUS, IR , Bluetooth, CDMA, WiMax
etc ...
Display communication standards like DDC , DDC2AB etc...

You may need to write small interfaces / device drivers to interact
with them.

Karthik Balaguru

Aug 14 '07 #37

P: n/a
On Mon, 13 Aug 2007 10:44:04 -0700, x01001x <xe****@softhome.net>
wrote:
>On Aug 10, 3:36 am, Keith Thompson <ks...@mib.orgwrote:
>x01001x <xem...@softhome.netwrites:

[...]
Someone before said linux never used .h libraries.

Headers are not libraries.

What's the difference? You could think better to explain this kind of
stuff when arguing a point,
especially considering code.
I have tried linking in the specified .h libraries, but I get link
errors. Why?

I have also tried it the other way around and #include .lib/.a files
from my .c files. The compiler excretes messages I don't understand.
Why?

I am urgently expecting your immediate reply.

--
Dan Henry
Aug 14 '07 #38

P: n/a
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>x01001x <xe****@softhome.netwrites:
[...]
>Someone before said linux never used .h libraries.
This sounds very ominous.
Isn't it always
#include hayesmodem.h
#include library.h
#include libcat.h

or something like that?

Headers are not libraries.
I think we have some pedantry here.

The library files are usually the compiled source code of the functions
to call the functions in the linked libraries you will need the
associated library header or include files.

As such the header files are part of the library but not part of the
library object file. Neither stands on it's own

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Aug 14 '07 #39

P: n/a
On Mon, 13 Aug 2007 18:56:10 -0600, in comp.lang.c , Dan Henry
<us****@danlhenry.comwrote:
>On Mon, 13 Aug 2007 10:44:04 -0700, x01001x <xe****@softhome.net>
wrote:
>>On Aug 10, 3:36 am, Keith Thompson <ks...@mib.orgwrote:
>>x01001x <xem...@softhome.netwrites:

[...]

Someone before said linux never used .h libraries.

Headers are not libraries.

What's the difference? You could think better to explain this kind of
stuff when arguing a point,
especially considering code.

I have tried linking in the specified .h libraries,
but I get link >errors. Why?
Headers are not libraries. Someone already said that. You don't link
in headers, you #include them in your code. You ALSO have to link the
library.
>I have also tried it the other way around and #include .lib/.a files
libs are binary data, not text. You need to link them, not #include
them.

This IS a FAQ...
>I am urgently expecting your immediate reply.
Huh? This is usenet.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Aug 14 '07 #40

P: n/a
Dan Henry wrote:
>
.... snip ...
>
I have tried linking in the specified .h libraries, but I get
link errors. Why?

I have also tried it the other way around and #include .lib/.a
files from my .c files. The compiler excretes messages I don't
understand. Why?

I am urgently expecting your immediate reply.
So why don't you bother to read the previous replies.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Aug 15 '07 #41

P: n/a
CBFalconer <cb********@yahoo.comwrote:
Dan Henry wrote:

I have tried linking in the specified .h libraries, but I get
link errors. Why?

I have also tried it the other way around and #include .lib/.a
files from my .c files. The compiler excretes messages I don't
understand. Why?

I am urgently expecting your immediate reply.

So why don't you bother to read the previous replies.
I believe Mr. Henry was being sarcastic.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com
I'm not. Fix your .sig.

Richard
Aug 15 '07 #42

This discussion thread is closed

Replies have been disabled for this discussion.