Why is stdprn not defined under Windows?

[Sathyaish]

I am trying to print to the printer. I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined. Why is
that? Is it because of Windows, I am guessing? Do I have to use only
the GDI32 functions for printing under Windows? Can I not use the
stdprn under Windows to print from memory to the window?

 

[E. Robert Tisdale]

I am trying to print to the printer. I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined. Why is
that? Is it because of Windows, I am guessing? Do I have to use only
the GDI32 functions for printing under Windows? Can I not use the
stdprn under Windows to print from memory to the window?

I don't do Windows so I can't answer any of your questions about them.
Try one of the many Windows specific newsgroups.

In UNIX, a printer is just another file
that you can open for writing if you have the correct permissions.
Unlike terminals, printers are usually shared.
This can cause problems if two or more applications
are trying to write to the same printer at the same time
so you may need some kind of monitor to mange requests
and queues for print jobs.

 

[Martin Ambuhl]

I am trying to print to the printer. I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined.

There is no pre-defined stream named 'stdprn' in C. You might be able
to do what you want by opening a stream with the name your platform uses
for the printer. That might be "prn". For example, this works on my
Windows box:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
FILE *prn;
if (!(prn = fopen("prn", "wb"))) {
perror("Could not open \"prn\" for output");
exit(EXIT_FAILURE);
}
fprintf(prn, "This is a simple test.\n");
fclose(prn);
return 0;
}

Why is
that?

Because there *is no such thing as stdprn* defined in C.

Is it because of Windows, I am guessing?

If so, Windows got something right.

 

[Artie Gold]

I am trying to print to the printer. I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined. Why is
that? Is it because of Windows, I am guessing? Do I have to use only
the GDI32 functions for printing under Windows? Can I not use the
stdprn under Windows to print from memory to the window?

As it's not a part of the C language, why are you asking here?

--ag

 

[Gordon Burditt]

I am trying to print to the printer.

There is no standard way to do that in standard C, unless stdout is
connected to the printer.

I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined. Why is

There is no stdprn in standard C.

that? Is it because of Windows, I am guessing? Do I have to use only

There is no stdprn in standard C, regardless of platform.
"stdprn" is a name reserved for the programmer. Header files

the GDI32 functions for printing under Windows? Can I not use the
stdprn under Windows to print from memory to the window?

Make up your mind: are you printing to a printer or to a window?
Or does your printer itself have windows? Also remember that there
is no guarantee that a computer has a printer. Or that it has only
one printer.

Many applications that want to print something put it in a file and
then either use system() with a platform-specific command to print
it, or let something else do it after the program has finished.

Some applications open a system-specific device (e.g. "PRN:" or
"/dev/lpt0") and output directly to it as though it were a file.
There is no guarantee that an application gets to talk to a "live"
printer rather than going through a spooler.

Gordon L. Burditt

 

[Mark McIntyre]

I am trying to print to the printer. I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined. Why is
that?

Because there's no such thing as a printer. Seriously.

Is it because of Windows, I am guessing? Do I have to use only
the GDI32 functions for printing under Windows? Can I not use the
stdprn under Windows to print from memory to the window?

The ability to print is totally system specific, and you should reasonably
expect to have to use system-specific functionality to do it. You'd need to
ask in a Windows group for how to do that tho.

 

[pete]

E. Robert Tisdale wrote:

In UNIX, a printer is just another file

In C, streams are associated with files.
What your standard output stream goes to,
and where your standard input stream comes from,
are files.

 

[Dan Pop]

I am trying to print to the printer. I am using a VC++ 6.0 compiler on
Win 2K, but I get an error saying that stdprn is not defined. Why is
that?

It is the implementation's way to suggest that you should "talk" to the
printer using the Windows printing services and not <stdio.h> streams.
Take the hint.

Dan

 

[Ben Pfaff]

In C, streams are associated with files.
What your standard output stream goes to,
and where your standard input stream comes from,
are files.

Not all C streams are associated with files, as C99 7.19.2 points
out:

Input and output, whether to or from physical devices
such as terminals and tape drives, or whether to or from
files supported on structured storage devices, [...]

 

[Mark McIntyre]

Not all C streams are associated with files,

sort-of depends how you choose to define "file".

File (n): end point of a C stream.

 

[pete]

In C, streams are associated with files.
What your standard output stream goes to,
and where your standard input stream comes from,
are files.

Not all C streams are associated with files,
as C99 7.19.2 points out:

Input and output, whether to or from physical devices
such as terminals and tape drives, or whether to or from
files supported on structured storage devices, [...]

I disagree.
A physical device, such as a terminal, is an example of a file.

N869
7.19.3 Files
[#1] A stream is associated with an external file (which may
be a physical device) by opening a file, which may involve
creating a new file. Creating an existing file causes its
former contents to be discarded, if necessary. If a file
can support positioning requests (such as a disk file, as
opposed to a terminal), ...

 

[Alan Balmer]

E. Robert Tisdale wrote:

In UNIX, a printer is just another file

In C, streams are associated with files.
What your standard output stream goes to,
and where your standard input stream comes from,
are files.

Not all C streams are associated with files,
as C99 7.19.2 points out:

Input and output, whether to or from physical devices
such as terminals and tape drives, or whether to or from
files supported on structured storage devices, [...]

I disagree.
A physical device, such as a terminal, is an example of a file.

N869
7.19.3 Files
[#1] A stream is associated with an external file (which may
be a physical device) by opening a file, which may involve
creating a new file. Creating an existing file causes its
former contents to be discarded, if necessary. If a file
can support positioning requests (such as a disk file, as
opposed to a terminal), ...

That says a file *may be* a physical device. It does not say a
physical device *is* a file.

Some OS's, notably Unix, treat devices as files. Some don't.

 

[Dan Pop]

E. Robert Tisdale wrote:

In UNIX, a printer is just another file

In C, streams are associated with files.
What your standard output stream goes to,
and where your standard input stream comes from,
are files.

Not all C streams are associated with files,
as C99 7.19.2 points out:

Input and output, whether to or from physical devices
such as terminals and tape drives, or whether to or from
files supported on structured storage devices, [...]

I disagree.
A physical device, such as a terminal, is an example of a file.

Be careful when dealing with semantics issues. A physical device and a
file are two completely different things. A file is something else
than the physical storage device on which it resides.

Even if the OS provides a file-like interface to a physical device, the
physical device is still not a file. A terminal is a lot more than the
one, two or three streams that may be connected to it at program startup.

Dan

 

[pete]

E. Robert Tisdale wrote:

In UNIX, a printer is just another file

In C, streams are associated with files.
What your standard output stream goes to,
and where your standard input stream comes from,
are files.

Not all C streams are associated with files,
as C99 7.19.2 points out:

Input and output, whether to or from physical devices
such as terminals and tape drives, or whether to or from
files supported on structured storage devices, [...]

I disagree.
A physical device, such as a terminal, is an example of a file.

Be careful when dealing with semantics issues.
A physical device and a
file are two completely different things. A file is something else
than the physical storage device on which it resides.

Even if the OS provides a file-like interface to a physical device,
the physical device is still not a file.
A terminal is a lot more than the one,
two or three streams that may be connected to it at program startup.

I'm under the impression, that when standard output
shows up on my PanaSync S70 monitor and that when I enter
standard input on my Lexmark model M keyboard,
that those two devices are files.
They are files, aren't they?

 

[Mike Wahler]

I'm under the impression, that when standard output
shows up on my PanaSync S70 monitor and that when I enter
standard input on my Lexmark model M keyboard,
that those two devices are files.
They are files, aren't they?

I wouldn't say so. I'd say they are devices (to which
standard streams are attached).

-Mike

 

[Dan Pop]

Ben Pfaff wrote:


E. Robert Tisdale wrote:

In UNIX, a printer is just another file

In C, streams are associated with files.
What your standard output stream goes to,
and where your standard input stream comes from,
are files.

Not all C streams are associated with files,
as C99 7.19.2 points out:

Input and output, whether to or from physical devices
such as terminals and tape drives, or whether to or from
files supported on structured storage devices, [...]

I disagree.
A physical device, such as a terminal, is an example of a file.

Be careful when dealing with semantics issues.
A physical device and a
file are two completely different things. A file is something else
than the physical storage device on which it resides.

Even if the OS provides a file-like interface to a physical device,
the physical device is still not a file.
A terminal is a lot more than the one,
two or three streams that may be connected to it at program startup.

I'm under the impression, that when standard output
shows up on my PanaSync S70 monitor and that when I enter
standard input on my Lexmark model M keyboard,
that those two devices are files.
They are files, aren't they?

The answer is available in the included text from the standard that is
still visible above: they are physical devices. If they were files,
you could destroy the output you have generated on your monitor with
a remove() function call and reread the user input as many times as you
wanted by closing and reopening the keyboard.

Why do you think the standard *explicitly* talks about two categories of
sources/destinations for I/O operations: physical devices and files
supported on *structured storage devices*?

Dan

 

[Keith Thompson]

The answer is available in the included text from the standard that is
still visible above: they are physical devices. If they were files,
you could destroy the output you have generated on your monitor with
a remove() function call and reread the user input as many times as you
wanted by closing and reopening the keyboard.

Why do you think the standard *explicitly* talks about two categories of
sources/destinations for I/O operations: physical devices and files
supported on *structured storage devices*?

Whether a device is considered a file is a question about the meaning
of the word "file". The standard doesn't provide an explicit
definition, but it does have wording that clearly implies that a
device can be a file.

In the following, I'll use underscores to denote italics.

C99 7.19.2 p1 says:

Input and output, whether to or from physical devices such as
terminals and tape drives, or whether to or from files supported
on structured storage devices, are mapped into logical data
_streams_, whose properties are more uniform than their various
inputs and outputs.

This makes a clear distinction between physical devices and files on
structured storage devices, but it doesn't quite state that physical
devices are not files. The ambiguity is in the interpretation of the
phrase "files supported on structured storage devices"; does it imply
that *all* files are "supported on structured storage devices", or is
it merely talking about the subset of files that are "supported on
structured storage devices"? Since it doesn't refer to physical
devices as files, it's difficult to tell from this passage alone.

But C99 7.19.3 p1 says:

A stream is associated with an external file (which may be a
physical device) by _opening_ a file, which may involve _creating_
a new file.

That seems pretty clear to me.

Presumably a remove() operation on an external file that is a physical
device would fail (though it could conceivably unplug the device from
the system if the implementer is sufficiently perverse). Similarly,
there's no reason to expect that closing and re-opening a physical
device will let you re-read the same input. You can't even assume
that for a disk file, since some external entity (such as another
process) might have modified the file in the meantime.

 

[pete]

Ben Pfaff wrote:


E. Robert Tisdale wrote:

In UNIX, a printer is just another file

In C, streams are associated with files.
What your standard output stream goes to,
and where your standard input stream comes from,
are files.

Not all C streams are associated with files,
as C99 7.19.2 points out:

Input and output, whether to or from physical devices
such as terminals and tape drives, or whether to or from
files supported on structured storage devices, [...]

I disagree.
A physical device, such as a terminal, is an example of a file.

Be careful when dealing with semantics issues.
A physical device and a
file are two completely different things. A file is something else
than the physical storage device on which it resides.

Even if the OS provides a file-like interface to a physical device,
the physical device is still not a file.
A terminal is a lot more than the one,
two or three streams that may be connected to it at program startup.

I'm under the impression, that when standard output
shows up on my PanaSync S70 monitor and that when I enter
standard input on my Lexmark model M keyboard,
that those two devices are files.
They are files, aren't they?

The answer is available in the included text from the standard that is
still visible above: they are physical devices. If they were files,
you could destroy the output you have generated on your monitor with
a remove() function call and reread the user input as many times as you
wanted by closing and reopening the keyboard.

Why do you think the standard *explicitly*
talks about two categories of sources/destinations
for I/O operations: physical devices and files
supported on *structured storage devices*?

Because disk files are substantially different from files
which are physical devices.
What kind of physical device do you think the standard
is refering to, when it says that a file may be a physical device?

This sentence:
N869
7.19.3 Files
[#1] If a file
can support positioning requests (such as a disk file, as
opposed to a terminal), then a file position indicator
associated with the stream is positioned at the start
(character number zero) of the file, unless the file is
opened with append mode in which case it is implementation-
defined whether the file position indicator is initially
positioned at the beginning or the end of the file.

doesn't make any sense, unless a disk file is one kind of file,
and a terminal is another kind of file.

 

[Mabden]

Presumably a remove() operation on an external file that is a physical
device would fail (though it could conceivably unplug the device from
the system if the implementer is sufficiently perverse).

I don't think that "unplugging the device" is necessarily "perverse". I
have a USB device that reads memory cards. I can plug in my camera
memory stick and copy files from it. When I want to remove the stick, I
"unplug or eject" the media. If there is no memory stick in the device
and I click "unplug or eject", it just shuts off the SmartDisk device
(the LED goes off and the icon is removed from the taskbar).

 

[Keith Thompson]

I don't think that "unplugging the device" is necessarily "perverse". I
have a USB device that reads memory cards. I can plug in my camera
memory stick and copy files from it. When I want to remove the stick, I
"unplug or eject" the media. If there is no memory stick in the device
and I click "unplug or eject", it just shuts off the SmartDisk device
(the LED goes off and the icon is removed from the taskbar).

Sure, but the question is whether a call to remove() should do this.
I would find such behavior odd, but it would be perfectly legal as far
as the standard is concerned.

<OT>On a Unix-like system, remove() would be more likely to delete the
entry in /dev rather than doing anything to the physical device, but
only if the caller has appropriate privileges.</OT>