Is there a library function for placing cursor position in the cosole?

[JeffS]

Honest, I scoured the comp.lang.c.faq for this but found nothing. :)

Is there a library function for placing the cursor position in the
console? Or is it something that can only be done with a platform API
call?

I was able to do this in Windows with a Windows.h function, but I want
to also do it on Linux/Unix as well.

I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group. But if someone knew it off
the top of their head, I won't stop you from writing it in a post! ;)
;)

Anyway, it would be really ideal if there were a standard C library
function that postitions the cursor in the console. This way, I can
keep my code more portable.

[Mike Wahler]

"JeffS" <ja****@yahoo.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

Honest, I scoured the comp.lang.c.faq for this but found nothing. :)
That's because standard C does not support direct device
access. All i/o is abstracted as 'streams of characters'.
C does not require the existence of a video display at all.

Is there a library function for placing the cursor position in the
console?
There are many, but all all platform-dependent. Also many implementations
provide library 'extensions' for this sort of thing, when applicable.
You might want to check your documentation for that.
Or is it something that can only be done with a platform API
call?
Essentially yes. But there are some third-party 'portable'
libraries available too.

I was able to do this in Windows with a Windows.h function, but I want
to also do it on Linux/Unix as well.
Sounds like you want some (relatively) 'portable' method. 'curses'
is one possiblity.


I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group. But if someone knew it off
the top of their head, I won't stop you from writing it in a post! ;)
;)

Anyway, it would be really ideal if there were a standard C library
function that postitions the cursor in the console.
There is not.
This way, I can
keep my code more portable.

Well, I hope you find my comments helpful anyway.

-Mike

[Gordon Burditt]

>Is there a library function for placing the cursor position in the

console?
Which console? What cursor? An ASR33 teletype doesn't have a
cursor. (I suspect C was originally developed on this kind of
terminal, although maybe something older than the ASR33.)

Remember also that many operating systems provide ways to direct
stdin and stdout to something else, like files or pipes.
Or is it something that can only be done with a platform API
call?
Some hardware doesn't HAVE a cursor (printing terminals, for
example). Some hardware doesn't HAVE a coin return slot, either.
I was able to do this in Windows with a Windows.h function, but I want
to also do it on Linux/Unix as well.
If you know what the type of CRT terminal is (or what it emulates)
such as VT100, there is a specific character sequence you can send
it to position the cursor (generally, independent of the OS, but
dependent on the character set.). But you don't know that. It may
not even be the same terminal type on two different terminals
connected to the same Linux machine. And thanks to dialup ports
and network connections, there may not be a way to figure this out
by looking at the hardware of the machine itself.
I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group. But if someone knew it off
the top of their head, I won't stop you from writing it in a post! ;)
;)

Anyway, it would be really ideal if there were a standard C library
function that postitions the cursor in the console. This way, I can
keep my code more portable.

Your code is not very portable if it expects to be connected to
a console.

Gordon L. Burditt

[E. Robert Tisdale]

JeffS wrote:

Honest, I scoured the comp.lang.c.faq for this but found nothing. :)

Is there a library function for placing the cursor position in the
console? Or is it something that can only be done with a platform API
call?

I was able to do this in Windows with a Windows.h function, but I want
to also do it on Linux/Unix as well.

I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group. But if someone knew it off
the top of their head, I won't stop you from writing it in a post! ;)
;)

Anyway, it would be really ideal if there were a standard C library
function that postitions the cursor in the console.
This way, I can keep my code more portable. man ncurses

ncurses(3X) ncurses(3X)

NAME
ncurses - CRT screen handling and optimization package

SYNOPSIS
#include <curses.h>

DESCRIPTION
The ncurses library routines give the user a
terminal-independent method of updating character screens
with reasonable optimization.
This implementation is ‘‘new curses’’ (ncurses) and is
the approved replacement for 4.4BSD classic curses,
which has been discontinued.

[dandelion]

"JeffS" <ja****@yahoo.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...
<snip>

I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group.

<OT>
Good. Linux does not have one.
</OT>

[Richard Bos]

"JeffS" <ja****@yahoo.com> wrote:

Honest, I scoured the comp.lang.c.faq for this but found nothing. :)

Is there a library function for placing the cursor position in the
console?
You can't have scoured very hard. Next time, use a steel brush.
<http://www.eskimo.com/~scs/C-faq/q19.4.html>.
Anyway, it would be really ideal if there were a standard C library
function that postitions the cursor in the console.

There are very good reasons why there isn't such a function in the
Standard, one of which is that it would be hard to come up with an
interface which is both useful and portably implementable. Consider, for
example, that you have no way (and there may _be_ no way) to tell
whether stdout is connected to a local console, or to a line printer on
the other end of a long serial connection.

Richard

[Chris Croughton]

On 14 Dec 2004 16:43:36 -0800, JeffS
<ja****@yahoo.com> wrote:

Honest, I scoured the comp.lang.c.faq for this but found nothing. :)

Is there a library function for placing the cursor position in the
console? Or is it something that can only be done with a platform API
call?
The concepts 'console' and 'cursor' are inherently platform-specific
(try positioning a cursor on a Teletype(R) Model 33!). It is therefore
OT for c.l.c (but see below for suggestions).
I was able to do this in Windows with a Windows.h function, but I want
to also do it on Linux/Unix as well.
If you are dealing with a text-mode console, look for curses. It is
available on all Unices I know and under Cygwin for MSWin32 systems.
I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group. But if someone knew it off
the top of their head, I won't stop you from writing it in a post! ;)
;)
<ESC>[a;bH

a and b are the row and column number in decimal ASCII (1,1 is the top
LH corner). That's the VT100/ANSI cursor control sequence, which works
with xterms, but of course is not guaranteed to work on anything else.
Anyway, it would be really ideal if there were a standard C library
function that postitions the cursor in the console. This way, I can
keep my code more portable.

The curses library (implemented by ncurses and others) has its own
standard from XSI.

HTH

Chris C

[Lawrence Kirby]

On Wed, 15 Dec 2004 11:31:50 +0000, Chris Croughton wrote:

On 14 Dec 2004 16:43:36 -0800, JeffS
<ja****@yahoo.com> wrote:

Honest, I scoured the comp.lang.c.faq for this but found nothing. :)

Is there a library function for placing the cursor position in the
console? Or is it something that can only be done with a platform API
call?
The concepts 'console' and 'cursor' are inherently platform-specific

To a degree but libraries like Curses have shown you have create a pretty
portable programming model for them.
(try positioning a cursor on a Teletype(R) Model 33!).
The fact that you can find environments that don't support this doesn't
invalidate the creation of a portable API for those that do. Such an
interface could simply say "Sorry can't do that" where that is
appropriate. Some programs (well any program) just can't run usefully on
platforms with inadequate functionality, that's true of standard C as it
is.
It is therefore OT for c.l.c (but see below for suggestions).

It is OT because the C language designers chose not to provide such
support in standard C, not because they couldn't have done. Curses exists
despite things like the Model 33.

Lawrence

[Chris Croughton]

On Wed, 15 Dec 2004 13:13:34 +0000, Lawrence Kirby
<lk****@netactive.co.uk> wrote:

On Wed, 15 Dec 2004 11:31:50 +0000, Chris Croughton wrote:

On 14 Dec 2004 16:43:36 -0800, JeffS
<ja****@yahoo.com> wrote:

Honest, I scoured the comp.lang.c.faq for this but found nothing. :)

Is there a library function for placing the cursor position in the
console? Or is it something that can only be done with a platform API
call?

The concepts 'console' and 'cursor' are inherently platform-specific

To a degree but libraries like Curses have shown you have create a pretty
portable programming model for them.

For a limited set of terminals (I don't know of any versions for GUI,
for example, and there are a number of functions of some terminals which
can't be manipulated using curses). It also has to know about what the
terminal type is, if the one actually connected is different frm what it
expects it won't work.

(try positioning a cursor on a Teletype(R) Model 33!).

The fact that you can find environments that don't support this doesn't
invalidate the creation of a portable API for those that do. Such an
interface could simply say "Sorry can't do that" where that is
appropriate. Some programs (well any program) just can't run usefully on
platforms with inadequate functionality, that's true of standard C as it
is.

The point is that the C library is mostly designed around things which
any C implementation can do. A program written to the C standard should
work on most platforms, if it needs to do something else then it becomes
less portable. Adding curses, which is inherently system-specific not
only in its implementation but also in its functionality, would bloat
the spec. with hundreds of functions which a lot of systems can't use
but which still take up space in the namespace.

As it is, I can have a perfectly portable program which has functions
called erase(), flash() etc. with no problem, only if I include the
(non-standard) curses.h do I encounter naming clashes. The C standard
mandates that standard functions must not be redefined.

It is therefore OT for c.l.c (but see below for suggestions).

It is OT because the C language designers chose not to provide such
support in standard C, not because they couldn't have done. Curses exists
despite things like the Model 33.

Well, no, it's orthogonal to the language. The curses library can
theoretically be used from any language on a system it supports (as long
as the calling conventions are compatible), it's a system feature not a
C one. It can also easily have multiple implementations (on my system I
have both curses and ncurses, and just link the appropriate one), and
can be extended without affecting the language standard.

Also, the standard for it is not dependent on the C standards
committees, which would take even more time arguing over it every time
new hardware comes along which needs an additional function.

There is something to be said for decoupling most of the existing C
library from the language, to make the language standard not dependent
on its environment at all...

Chris C

[Default User]

JeffS wrote:

Honest, I scoured the comp.lang.c.faq for this but found nothing. :)
Really?
Is there a library function for placing the cursor position in the
console? Or is it something that can only be done with a platform API
call?

http://www.eskimo.com/~scs/C-faq/q19.4.html


Brian

[Malcolm]

"Chris Croughton" <ch***@keristor.net> wrote

The point is that the C library is mostly designed around things which
any C implementation can do. A program written to the C standard should
work on most platforms, if it needs to do something else then it becomes
less portable. Adding curses, which is inherently system-specific not
only in its implementation but also in its functionality, would bloat
the spec. with hundreds of functions which a lot of systems can't use
but which still take up space in the namespace.

Actually this is already the case. Try printing a message to stderr in an MS
Windows GUI program, for example. There might be a way to catch the output,
but I haven't found it.
Most games consoles also have a very limited subset of the standard library,
and often that is useless, for instance because double precision arithmetic
is emulated in software.
My own view is that many programs need to be able to address a text raster
on a console, and many more need to be able to access a graphical window and
mouse. It would only take half a dozen functions to support these things

Win * TextWindow(int width, int height, int *wgot, int *hgot)
void printat(Win *win, int x, int y, char ch)
Win *GraphicsWindow(int width, int height, int *wgot, int *hgot, COLORMAP
*col)
void setpixel(Win *win, int x, int y, long rgb)
/* this one for efficiency */
void drawimage(Win *win, int x, int y, int width, int height, long *image)
/* if delay is non-zero, this could double as the synch function to flush
output to
the screen */
int querymouse(Win *win, int *x, int *y, int delay)
int kbhit(void)
void closeWindow(Win *win)

This would release third parties to produce systems for buttons and drivers
and so on. Text could default to 16 pixels by 20, or whatever is convenient.
Anyone really worried out appearance in graphics mode would build a font
library on top of the access functions anyway.

[Mark McIntyre]

On Wed, 15 Dec 2004 22:33:43 -0000, in comp.lang.c , "Malcolm"
<ma*****@55bank.freeserve.co.uk> wrote:

Actually this is already the case. Try printing a message to stderr in an MS
Windows GUI program, for example. There might be a way to catch the output,
but I haven't found it.

MS's debugger from the resource kit, and also I think Sysinternals'
DBGVIEW.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[CBFalconer]

Malcolm wrote:

"Chris Croughton" <ch***@keristor.net> wrote

The point is that the C library is mostly designed around things
which any C implementation can do. A program written to the C
standard should work on most platforms, if it needs to do
something else then it becomes less portable. Adding curses,
which is inherently system-specific not only in its
implementation but also in its functionality, would bloat the
spec. with hundreds of functions which a lot of systems can't
use but which still take up space in the namespace.

Actually this is already the case. Try printing a message to
stderr in an MS Windows GUI program, for example. There might be
a way to catch the output, but I haven't found it.

This is not a criticism of the standard, but of MS perversion of
existing standards. There is no reason for this failure. All gui
systems have at least a title area, which can be used for the
purpose.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Richard Bos]

"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"Chris Croughton" <ch***@keristor.net> wrote

The point is that the C library is mostly designed around things which
any C implementation can do. A program written to the C standard should
work on most platforms, if it needs to do something else then it becomes
less portable. Adding curses, which is inherently system-specific not
only in its implementation but also in its functionality, would bloat
the spec. with hundreds of functions which a lot of systems can't use
but which still take up space in the namespace.

Actually this is already the case. Try printing a message to stderr in an MS
Windows GUI program, for example. There might be a way to catch the output,
but I haven't found it.

Neither have I, but then again, have you ever found a conforming hosted
implementation that creates MS Windows GUI programs? If you want a
conforming hosted implementation that creates MS Windows programs, try,
for example, Dev-C++'s C compiler. The non-GUI console programs it
creates have no problems with stdin/out/err.

Richard

[Chris Croughton]

On Wed, 15 Dec 2004 22:33:43 -0000, Malcolm
<ma*****@55bank.freeserve.co.uk> wrote:

"Chris Croughton" <ch***@keristor.net> wrote

The point is that the C library is mostly designed around things which
any C implementation can do. A program written to the C standard should
work on most platforms, if it needs to do something else then it becomes
less portable. Adding curses, which is inherently system-specific not
only in its implementation but also in its functionality, would bloat
the spec. with hundreds of functions which a lot of systems can't use
but which still take up space in the namespace.
Actually this is already the case. Try printing a message to stderr in an MS
Windows GUI program, for example. There might be a way to catch the output,
but I haven't found it.

That's a Windoze problem (in other words, it isn't meeting the standard
in that respect). It could easily pop up a message box, for instance,
or a text window. Complain to M$...
Most games consoles also have a very limited subset of the standard library,
and often that is useless, for instance because double precision arithmetic
is emulated in software.
They are catered for as freestanding implementations, which only need to
support the functions in <float.h>, <limits.h>, <stdarg.h> and
<stddef.h> (in C90; C99 adds a few more). There is, of course, no
guarantee that any aspect of the implementation is suitable for any
specific purpose (speed, size of object code, etc.) only that it works
according to the standard and produces the correct result.
My own view is that many programs need to be able to address a text raster
on a console, and many more need to be able to access a graphical window and
mouse. It would only take half a dozen functions to support these things
And many more don't. Almost all of the programs I've written in the
last 25 years (about 20 of them using C or C++ full-time) are quite
happy with a text stream as user input and output.
Win * TextWindow(int width, int height, int *wgot, int *hgot)
void printat(Win *win, int x, int y, char ch)
Win *GraphicsWindow(int width, int height, int *wgot, int *hgot, COLORMAP
*col)
void setpixel(Win *win, int x, int y, long rgb)
/* this one for efficiency */
void drawimage(Win *win, int x, int y, int width, int height, long *image)
/* if delay is non-zero, this could double as the synch function to flush
output to
the screen */
int querymouse(Win *win, int *x, int *y, int delay)
int kbhit(void)
void closeWindow(Win *win)
Well, you've now extended it to graphics terminals, thus limiting it
even more to certain hardware and operating systems.
This would release third parties to produce systems for buttons and drivers
and so on. Text could default to 16 pixels by 20, or whatever is convenient.
What is 'convenient' is a text mode terminal which can display at least
80 characters width in sequential order, and an input device which
generates characters. That is all that is needed for a conforming
hosted C implementation. Your suggestion would make it necessary to
provide even more hardware and functions to interrogate it (there is no
point in having a portable window without means to find out how big it
can be, how many colours it supports, how big the text is, etc.).
Anyone really worried out appearance in graphics mode would build a font
library on top of the access functions anyway.

No, they would (and do) go directly to the system API (or to the
hardware) to do it efficiently (try telling a games programmer that he
has to use functions which set one pixel at a line to draw a line, when
the hardware implements it as a single operation!). And no one would
ever agree about which functions are basic and which can be built
sensibly on top, because all of the hardware is different. Look at how
many graphics libraries there are, all with different interfaces because
they are designed for different things.

The point of the C library is that it is supposed to support the minimum
necessary to write workable programs, and allow extra libraries and
headers to do anything else.

Note that the curses library can be implemented using only the standard
C functions -- of course, it has to know which escape sequences to
issue to do things like cursor addressing, switching echo off, etc., but
for many terminals those can be done without any direct OS access at
all. The same could be true for a graphics system (the Tektronics
terminals, which are still emulated in some xterms, used an serial
character stream for graphics) and for pointing devices. But it's up to
the implementer and the user to determine the hardware characteristics
for those, not for the C standard to specify minimum hardware levels.

(I'm not too happy with some of the C99 specifications, they seem to be
going in the direction of too much hardware knowledge. It started with
specification of a particular floating point format, and supporting
complex arithmetic and the horrible type-generic macros...)

Chris C

[Mark McIntyre]

On Thu, 16 Dec 2004 05:31:25 GMT, in comp.lang.c , CBFalconer
<cb********@yahoo.com> wrote:

Malcolm wrote:

Actually this is already the case. Try printing a message to
stderr in an MS Windows GUI program, for example. There might be
a way to catch the output, but I haven't found it.
This is not a criticism of the standard, but of MS perversion of
existing standards.

Hang on. In point of fact, there's no perversion taking place here.
fprintf(stderr, is working, you just can't trivially see stderr.

There is no reason for this failure.

There /is/ no failure.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Michael Wojcik]

In article <a8********************************@4ax.com>, Mark McIntyre <ma**********@spamcop.net> writes:

On Thu, 16 Dec 2004 05:31:25 GMT, in comp.lang.c , CBFalconer
<cb********@yahoo.com> wrote:

Malcolm wrote:

Actually this is already the case. Try printing a message to
stderr in an MS Windows GUI program, for example. There might be
a way to catch the output, but I haven't found it.

This is not a criticism of the standard, but of MS perversion of
existing standards.

Hang on. In point of fact, there's no perversion taking place here.
fprintf(stderr, is working, you just can't trivially see stderr.

It doesn't matter whether fprintf(stderr, ...) works for an MS Windows
GUI program. It's a freestanding environment.

There is no reason for this failure.

There /is/ no failure.

Indeed.

--
Michael Wojcik mi************@microfocus.com

I would never understand our engineer. But is there anything in this world
that *isn't* made out of words? -- Tawada Yoko (trans. Margaret Mitsutani)

[Michael Wojcik]

In article <41***************@yahoo.com>, CBFalconer <cb********@yahoo.com> writes:

Malcolm wrote:

Actually this is already the case. Try printing a message to
stderr in an MS Windows GUI program, for example. There might be
a way to catch the output, but I haven't found it.
This is not a criticism of the standard, but of MS perversion of
existing standards. There is no reason for this failure.

There is no failure. MS Windows GUI programs are C programs running
under a freestanding implementation. There's no need for such an
implementation to support stdio at all, or if it does to do anything
useful with stdin, stdout, and stderr.

For that matter, there's no requirement for a hosted implementation to
successfully produce visible output when the program writes to stderr,
though obviously in that case it's a QoI issue.
All gui systems have at least a title area,
Not true. For years I used X Windows with various window managers
that did not waste screen real estate on pointless decorations like
window titles. (I still prefer that, but for work reasons I have to
run Windows, so I just use an X implementation on Windows that uses
the standard Windows look. Fortunately screen real estate is cheaper
these days.)
which can be used for the purpose.

Though how often that would be useful is dubious.

Certainly Windows could have done something useful by default with
stderr, such as writing it to a non-modal scrolling popup that could
be closed, moved, or minimized by the user. However, considering how
many gross usability errors there are in Windows even today (I don't
know how many times a week I encounter a window with text that can't
be selected and copied, for example), this wouldn't be high on my
list.

--
Michael Wojcik mi************@microfocus.com

She felt increasingly (vision or nightmare?) that, though people are
important, the relations between them are not, and that in particular
too much fuss has been made over marriage; centuries of carnal
embracement, yet man is no nearer to understanding man. -- E M Forster

[Lawrence Kirby]

On Fri, 17 Dec 2004 16:04:00 +0000, Michael Wojcik wrote:

In article <a8********************************@4ax.com>, Mark McIntyre <ma**********@spamcop.net> writes:

On Thu, 16 Dec 2004 05:31:25 GMT, in comp.lang.c , CBFalconer
<cb********@yahoo.com> wrote:

>Malcolm wrote:
>> Actually this is already the case. Try printing a message to
>> stderr in an MS Windows GUI program, for example. There might be
>> a way to catch the output, but I haven't found it.
>
>This is not a criticism of the standard, but of MS perversion of
>existing standards.
Hang on. In point of fact, there's no perversion taking place here.
fprintf(stderr, is working, you just can't trivially see stderr.

I guess the question is whether program output is output if it can't be
observed.
It doesn't matter whether fprintf(stderr, ...) works for an MS Windows
GUI program. It's a freestanding environment.

That depends on whether MS C compilers claim to provide a hosted
environment for console apps. Probably not but not impossible.

Lawrence

[Mark McIntyre]

On Fri, 17 Dec 2004 17:47:22 +0000, in comp.lang.c , Lawrence Kirby
<lk****@netactive.co.uk> wrote:

On Fri, 17 Dec 2004 16:04:00 +0000, Michael Wojcik wrote:

In article <a8********************************@4ax.com>, Mark McIntyre <ma**********@spamcop.net> writes:

Hang on. In point of fact, there's no perversion taking place here.
fprintf(stderr, is working, you just can't trivially see stderr.

I guess the question is whether program output is output if it can't be
observed.

And if a tree falls when there's no-one to hear it?
That depends on whether MS C compilers claim to provide a hosted
environment for console apps. Probably not but not impossible.

They do, but for console apps fprintf(stderr, works perfectly. Its for GUI
apps that there's an issue.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Mark McIntyre]

On Fri, 17 Dec 2004 17:47:22 +0000, in comp.lang.c , Lawrence Kirby
<lk****@netactive.co.uk> wrote:

On Fri, 17 Dec 2004 16:04:00 +0000, Michael Wojcik wrote:

In article <a8********************************@4ax.com>, Mark McIntyre <ma**********@spamcop.net> writes:

Hang on. In point of fact, there's no perversion taking place here.
fprintf(stderr, is working, you just can't trivially see stderr.

I guess the question is whether program output is output if it can't be
observed.

And if a tree falls when there's no-one to hear it?
That depends on whether MS C compilers claim to provide a hosted
environment for console apps. Probably not but not impossible.

They do, but for console apps fprintf(stderr, works perfectly. Its for GUI
apps that there's an issue.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Michael Wojcik]

In article <pa****************************@netactive.co.uk> , Lawrence Kirby <lk****@netactive.co.uk> writes:

On Fri, 17 Dec 2004 16:04:00 +0000, Michael Wojcik wrote:

It doesn't matter whether fprintf(stderr, ...) works for an MS Windows
GUI program. It's a freestanding environment.

That depends on whether MS C compilers claim to provide a hosted
environment for console apps.

Did you mean whether they claim to provide a hosted environment for
GUI apps? Otherwise, I don't see how that would be relevant to
whether they provide a freestanding implementation for GUI apps.

If that is what you meant, then yes, I agree that if MS claims that
it provides a conforming hosted implementation for GUI apps, that
claim appears to be invalid. For one thing, GUI apps use a different
form for the function called at program startup.

For the record, I couldn't find any such claim in the MS documentation
I have at hand.

--
Michael Wojcik mi************@microfocus.com

This is a "rubbering action game," a 2D platformer where you control a
girl equipped with an elastic rope with a fishing hook at the end.
-- review of _Umihara Kawase Shun_ for the Sony Playstation

[Richard Bos]

mw*****@newsguy.com (Michael Wojcik) wrote:

In article <41***************@yahoo.com>, CBFalconer <cb********@yahoo.com> writes:

All gui systems have at least a title area,

Not true. For years I used X Windows with various window managers
that did not waste screen real estate on pointless decorations like
window titles.

And this shows the risk of off-topic discussion: it isn't actually true
for M$ Windows, either. By far most M$ windows have a title bar, of
course, but they don't have to. Details would be off-topic.

Richard

[Lawrence Kirby]

On Sat, 18 Dec 2004 18:20:04 +0000, Michael Wojcik wrote:

In article <pa****************************@netactive.co.uk> , Lawrence Kirby <lk****@netactive.co.uk> writes:

On Fri, 17 Dec 2004 16:04:00 +0000, Michael Wojcik wrote:

> It doesn't matter whether fprintf(stderr, ...) works for an MS Windows
> GUI program. It's a freestanding environment.
That depends on whether MS C compilers claim to provide a hosted
environment for console apps.

Did you mean whether they claim to provide a hosted environment for
GUI apps?

Not really, since as you mention below they don't use a valid program
startup mechanism for a hosted implementation.
Otherwise, I don't see how that would be relevant to
whether they provide a freestanding implementation for GUI apps.
Console apps can use GUI facilities, so that's really the only
area combination that could be relevant.
If that is what you meant, then yes, I agree that if MS claims that
it provides a conforming hosted implementation for GUI apps, that
claim appears to be invalid. For one thing, GUI apps use a different
form for the function called at program startup.

For the record, I couldn't find any such claim in the MS documentation
I have at hand.

Then of course they can do what they like, but we know that anyway. :-)

Lawrence

[Roger Leigh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Croughton <ch***@keristor.net> writes:

On 14 Dec 2004 16:43:36 -0800, JeffS
<ja****@yahoo.com> wrote:

I won't ask for a Linux API call that positions the cursor, as that is
beyond the scope of the comp.lang.c group. But if someone knew it off
the top of their head, I won't stop you from writing it in a post! ;)
;)

<ESC>[a;bH

a and b are the row and column number in decimal ASCII (1,1 is the top
LH corner). That's the VT100/ANSI cursor control sequence, which works
with xterms, but of course is not guaranteed to work on anything else.

It should work on any terminal implementing ISO-6429 (ECMA-48;
http://www.ecma-international.org/pu...t/ECMA-048.pdf)

BTW, while the escape sequence is correct for the VT-100, strictly
speaking it's defined as

CSI Pn1;Pn2 04/08

where CSI (control sequence inducer) is typically 01/11 05/11 (ESC [),
but this could equally be 09/11 (0x9B) for 8-bit character sets with
the C1 control set designated as CR (0x80 to 0x9F). 04/08 is "H".

Best to just use curses and have it do all this stuff for you ;-)
Regards,
Roger

- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFByIWlVcFcaSW/uEgRAmoHAJ9mHa1kc6QBg9bt+n/4bkzhwhv/XACgp4dZ
DHlgRajFeH+N2xCsxyy65nM=
=CJnX
-----END PGP SIGNATURE-----

[Dave Thompson]

On 15 Dec 2004 04:33:27 GMT, go***********@burditt.org (Gordon
Burditt) wrote:

Is there a library function for placing the cursor position in the
console?

Which console? What cursor? An ASR33 teletype doesn't have a
cursor. (I suspect C was originally developed on this kind of
terminal, although maybe something older than the ASR33.)

Not officially, but practically the little ribbon-guide thingies
functioned well enough to let you position the carriage w.r.t.
something on the paper, or more often vice versa. (On any model 33 of
course, not just ASR which is irrelevant to the print mechanism.)

The 33 was the first ASCII machine from Teletype, and I think at all,
so it wouldn't have been older. More likely newer; by 1970 I think at
least VT05's were out from DEC and maybe VT50's. And definitely
Teletype model 35's, and I think 38's, which would support the
lowercase that Unix and C strongly prefer.

- David.Thompson1 at worldnet.att.net