Thread: conio.h clrscr() & gotoxy(); wtf? :o

Hi guys, its me again

before you get mad at this because I know i can find answers in FAQ, please tell me which complier stands for those codes (clrsrc() and gotoxy() ) since the book that im learning from is guidding me this way to code and i wanna have fun with it (atleast untill i'll become a 'pro' programmer ^^)

I'm using VS2010express to code C atm,

You recommand on something else?

Thank you, best regrads,

Or Ellenbogen

Those are not standard C functions and may be implemented differently depending on what system you are on.

The FAQ does cover this: FAQ > gotoxy() in a Windows Console - Cprogramming.com

There are some older compilers that come packaged with these non-standard libraries, but I think you'll find the majority of the community recommends against using such deprecated tools. It is entirely feasible (as the link shows), to implement the functions using windows API calls.

Originally Posted by grumpy

clrscr() and gotoxy() were originally implemented with Borland products. Historically, they originated in a Borland product named Delphi

Actually, from Lattice C.

I remember using those in late 80s with Borland's Turbo Pascal IDE (in DOS on a 80286 machine); it did that by directly manipulating the graphics memory.

Turbo Pascal was a massive improvement on earlier products. Although not a Rapid Application Development environment, the integrated development environment allowed a very rapid code development - execution cycle; so much so to impress even Bill Gates.

Borland also provided graphics support you might run into. In Turbo Pascal, this was the graph unit, and it supported several different hardware drivers (EGA/VGA, CGA, et cetera) with the same API. In C, Borland used graphics.h. (I've seen one for C++ which is logically similar, but uses CamelCase names and C++ return types.)

Originally Posted by grumpy

The functions work [...] (thanks to support by gcc) under various unix flavours

No. I know there are implementations (or header files containing an inline implementation that produces the effects via ANSI codes, or by directly accessing the framebuffer in DOS) that provide conio.h, but those are definitely not provided by GCC.

DJ Delorie's DJGPP for DOS and DOS compatibles, a port of GCC and a few other GNU utilities, did provide an implementation of conio.h, but the latest stable version is from 2002.

Originally Posted by grumpy

although the curses/ncurses library is more commonly used for developing console applications under unix

Not just unix, for all text-based applications. There is PDCurses, a stable free implementation that works in Windows, too. If you distribute a Windows program using curses, just include a copy of the library with your binaries; the library is, like the name says, in public domain.

It is easy to write curses-based code that works on all curses implementations; just use the X/Open curses documentation. For text-based applications, the results are very lightweight (code size and CPU time used), and your code can even react to window size changes (LINES and COLS are variables, not constants) -- very useful for example for text-based applications run remotely over SSH; allows the user to resize the window to fit their need. In the non-Windows world, curses libraries are still actively used to make interactive text-based interfaces.

(If you write code for text-based applications that are used over an SSH connection, you can use ANSI escape codes directly, instead: all SSH clients I know support them. They work in most terminal emulators -- so in all Linux, Mac OS X, and Unix command line applications -- and on Linux console (without X or any sort of GUI). They used to work in DOS and Windows command line too, if you activated the ANSI.SYS driver, but Microsoft dropped that, of course, a few years ago.)

I personally have a few user accounts on remote servers that receive quite a lot of spam, and dangerous files. Instead of risking security compromises via e-mail reader bugs (or tracking via automatically loaded images), I simply use ssh and alpine (a curses-based e-mail reader) to read the mail.

Originally Posted by Nominal Animal

...
(If you write code for text-based applications that are used over an SSH connection, you can use ANSI escape codes directly, instead: all SSH clients I know support them. They work in most terminal emulators -- so in all Linux, Mac OS X, and Unix command line applications -- and on Linux console (without X or any sort of GUI). They used to work in DOS and Windows command line too, if you activated the ANSI.SYS driver, but Microsoft dropped that, of course, a few years ago.)
...

ansicon is a decent replacement.

Originally Posted by Adak

conio.h is supported with the Pelles C compiler. (Which is a modern C only compiler for Windows.) What Pelles does is use a leading underline for non-standard C functions: _gotoxy(), etc.

mingw supports conio.h too, but crippled if my memory serves me well.

...
I won't be using or recommending ASNI escape codes, (ansicon), EVER, in this lifetime!

Why not? It's just an alternative option (I for one have used successfully a few times).

The ANSI code itself is an ugly thing to look at and decipher, by itself. People don't know if they have ANSI.sys installed on their system or not, so you can't assume it's even going to run on a Windows system (it doesn't with either of my default installs of either WinXP 32 bit, or Win 7 64 bit).

conio.h may not be as good as some versions of curses, but it's WAY better than using ANSI escape sequences.

Originally Posted by Adak

I won't be using or recommending ASNI escape codes, (ansicon), EVER, in this lifetime!

Hey, there is absolutely nothing wrong with ANSI escape codes. It wouldn't be at all difficult for Microsoft to add ANSI escape code support for their command-line application; they just don't want to do that, because if they do their Embrace-Extend-... thing, developers and users get locked in to their system! Ka-ching!

In any case, the last time I used Windows' Command Prompt, it was absolutely horrible. Why haven't anybody written a better terminal ("command prompt") for Windows? It could even use the very same command interpreter, cmd.exe, Microsoft provides.

Actually.. Adak, would you mind trying out MobaXterm? It is free, and has a tabbed local terminal mode -- a Command Prompt on steroids --, that definitely supports ANSI escape codes. For best results, just remember to change the character set in the MobaXterm session settings to UTF-8.

mintty and cygwin -- you only need mintty.exe from mintty-1.1.3-cygwin17.zip and cygwin1.dll from cygwin-1.7.20-1.tar.bz2, and make sure that the .exe can see the .dll file (so in working directory or along PATH) -- does work with Windows' cmd.exe, kinda, and ANSI escape codes are supported in the output, but cmd.exe doesn't understand cursor up/down, and freaks out if you try to close or resize the window. It supports UTF-8 output by default, I think.

So, if I may ask, are ANSI escape codes really that horrible, Adak?

Just think how nice it would be to tell new programmers that for Windows, they should use one of the alternatives, not Command Prompt. That's it. As long as they have a relatively recent OS, a free or a proprietary one, then

Code:

#include <stdio.h>

#define NORMAL "\033[0m"
#define RED "\033[1;32m"
#define YELLOW "\033[1;33m"
#define GREEN "\033[1;32m"
#define CYAN "\033[1;36m"
#define BLUE "\033[1;34m"
#define WHITE "\033[1;37m"

int main(void)
{
    printf("Hello " RED "w" YELLOW "o" GREEN "r"
           CYAN "l" BLUE "d" WHITE "!" NORMAL "\n");
    return 0;
}

will work on any system, not just in Windows.

(Telling the terminal not to buffer input character by character is still a bit of an issue, because it requires different code for Windows and everyone else. Curses is still the way to go for those. It's not like installing one frigging library, that is already in the public domain, is such a big thing. Microsoft could do it themselves, if they wanted to, without paying a cent to anybody. But they don't, because they want you locked to Windows. Free yourself, man!)

So, if I may ask, are ANSI escape codes really that horrible, Adak?

Hell yes.

This kind of gobblety-goop, is insufferable:

"\033[0m", "\033[1;32m", "\033[1;33m", "\033[1;32m", "\033[1;36m", "033[1;34m", "\033[1;37m".

I'll stick with knowing the numbers for each terminal color: Black is zero, etc.

It's an exercise in futility to try and persuade a majority of the Windows users to replace their console program. I have no interest in replacing mine, since I need it to match exactly with any callers I support.

I remember distinctly, how horrid the programs were before Windows came along. Each one was completely different in it's interface, and the learning curve for them, was a lot more involved.

All but one of my computers use Ubuntu 12.04 atm, but I don't game much or program, on them. They either work for Folding@Home, or BOINC projects.

Originally Posted by Adak

This kind of gobblety-goop, is insufferable

You gotta be kidding me. You think "\033[", or ASCII ESC (27) followed by [ is gobblety-goop, but are happy with the bastardized Hungarian notation all over Windows APIs?

Originally Posted by Adak

It's an exercise in futility to try and persuade a majority of the Windows users to replace their console program. I have no interest in replacing mine, since I need it to match exactly with any callers I support.

Yeah.. I was thinking about all the learners here; schools and universities and such. Having someone like you giving your opinion on whether those are actually worth trying out, might help them.

My own opinion, since I don't use Windows, does not count.

Originally Posted by Adak

I remember distinctly, how horrid the programs were before Windows came along.

Yeah, we're old. Honestly, don't mind me; I just grumble because I think the programs and especially Windows are really horrid, and could be much, much better.

But, to get any real improvement, we'd need to get rid of the platform lock-in first.

Open standards like HTTP and HTML have made a real difference already, and that's the way to go, I think. Not necessarily Linux, but something that at least tries to conform to open standards. Portability for user data, if not user interfaces and applications.

(Honestly, I like Linux because I can, and have, configured it to fit my own and my clients needs and workflow. I've even written and applied ksplices myself, fixing a kernel security hole without having to restart the machine; try that with Windows. I think there are huge business opportunities in customizing desktops to fit business workflows -- as soon as the generation who's used to Android replaces the current Windows-locked management who believe there is exactly one right way, the Vendor Way, to do stuff.)

The only reason I even bother to kid you and others about this, is because I'm hoping a newbie reading this and other threads will realize it's not worth the ease and simplicity, to rely on Windows alone -- at least with respect to programming.

I don't have any problems with ANSI escape sequences either.

Almost a year ago I wrote a little x-platform c/c++ preprocessor interface for colored output on the console, that uses either Win32 API calls or ANSI escape sequences, depending on the compilation platform (although it can be forced to either one). I wrote it on Windows, using ansicon and mintty (both the standalone and the mingw versions) for testing purposes during development, so ANSI escape sequences do have their usefulness merit on Windows too.

Here's the docs and the latest source-code left in alpha stage, if anyone is interested (it only does colors, nothing else).

That being said, I also consider curses/ncurses/pd-curses to be the most robust & portable way of doing sophisticated text-interfaces.

Originally Posted by Nominal Animal

You gotta be kidding me. You think "\033[", or ASCII ESC (27) followed by [ is gobblety-goop, but are happy with the bastardized Hungarian notation all over Windows APIs?

I didn't say that. I said the colors used by DOS (and also by conio.h), are easy to work with (long since memorized). And this:
\033[1;37m;

IS gobblety-goop.

Yeah.. I was thinking about all the learners here; schools and universities and such. Having someone like you giving your opinion on whether those are actually worth trying out, might help them.

My own opinion, since I don't use Windows, does not count.

Yes, it would help, BUT it doesn't matter. You'll never get Windows users to replace part of Windows, for a better console terminal. Moot issue.

Yeah, we're old. Honestly, don't mind me; I just grumble because I think the programs and especially Windows are really horrid, and could be much, much better.

But, to get any real improvement, we'd need to get rid of the platform lock-in first.

Open standards like HTTP and HTML have made a real difference already, and that's the way to go, I think. Not necessarily Linux, but something that at least tries to conform to open standards. Portability for user data, if not user interfaces and applications.

(Honestly, I like Linux because I can, and have, configured it to fit my own and my clients needs and workflow. I've even written and applied ksplices myself, fixing a kernel security hole without having to restart the machine; try that with Windows. I think there are huge business opportunities in customizing desktops to fit business workflows -- as soon as the generation who's used to Android replaces the current Windows-locked management who believe there is exactly one right way, the Vendor Way, to do stuff.)

The only reason I even bother to kid you and others about this, is because I'm hoping a newbie reading this and other threads will realize it's not worth the ease and simplicity, to rely on Windows alone -- at least with respect to programming.

Linux has a great product - but they don't have the faintest idea how to make it work as a product, for the mass market. Unrelentingly clueless, and painful to see. Their maket share is increasing, but it could be SO MUCH better, if only they weren't so damn smart, and so damn stupid, all at the same time.

I don't like the Windows API, but I certainly appreciate what Windows has done for the PC application programs, and the PC user.

Originally Posted by Neo1

you haven't done your research on cmd.exe alternatives before making the above statement

No, you misunderstand. I don't have a problem with cmd.exe -- I'm used to using a number of different shells --, only the Command Prompt application. You know, the command-line emulator? The terminal emulator (or console) part?

If I remember correctly, it's fixed to 80 character width, and you cannot even switch between encodings, or fonts, or color schemes, or enable ANSI escape sequence support; things even a minimal terminal emulator (or console) should be able to do.

Originally Posted by Neo1

Well, Microsoft themselves have, it is called PowerShell and it is excellent.

PowerShell is a shell, not a terminal emulator.

I do prefer bash, because that lets me use the same scripts everywhere (assuming the accompanying tools are also available), but I'll use whatever is available.

Originally Posted by Neo1

Then there is Console2 which has been around since 2003.

I didn't know about that! Do you know if it supports ANSI escape codes? Perhaps via a configuration setting or something?

If it does, I think it would be the perfect stepping-stone to show new programmers how to do text-based stuff portably, without locking themselves into Windows-land. Use that and ANSI escape codes to show them you can do it portably, then recommend they get their hands on curses (pdcurses for windows, and ncurses for Linux/Unix/Mac) for full control of the text terminal.