Printable View
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.
clrscr() and gotoxy() were originally implemented with Borland products. Historically, they originated in a Borland product named Delphi, which was one of the first Rapid Application Development (RAD) environments (using a variant of Pascal) for DOS-based user interface (and later windows applications). The library from Delphi was then reused in Turbo C and C++, and later in C++ Builder.
Some other compilers and libraries, targeting windows, also support them - at least in versions dating from before 2000. Microsoft is a notable exception (historically, the first version of Visual Basic was a direct competitor to Delphi, so Microsoft did not need [or probably want] to support Borland functions) so, if you want to use such functions with any Microsoft compiler you will need to emulate them.
Older versions of gcc (gnu compilers) - or one of the libraries shipped with said compilers - support the functions. I'm not sure if modern versions of gcc (eg those that come bundled with IDEs like Code::Blocks or Eclipse) still do - never had a reason to check.
The functions only work in a MS-DOS environment, or - sort of - in console mode applications under modern windows and (thanks to support by gcc) under various unix flavours (although the curses/ncurses library is more commonly used for developing console applications under unix). Support by vendors has sort-of faded out in modern compilers (as most modern development concerned with a user interface targets GUI-based applications, not console mode).
So, if you want to use such functions, you probably need to limit yourself to compilers/libraries more than a decade old, or emulate the functions.
Actually, from Lattice C.Quote:
Originally Posted by grumpy
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.)
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.Quote:
Originally Posted by grumpy
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.
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.Quote:
Originally Posted by grumpy
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.
ansicon is a decent replacement.Quote:
Originally Posted by Nominal Animal
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.
Pelles is free, runs on Windows XP and Windows 7 in 32 bit or 64 bit versions, and has it's own forum for questions or problems. It has an extensive help section, as part of it's IDE. Conio.h runs fine in both Windows XP and Windows 7.
The advantage of using the Windows API is that every Windows compiler can take advantage of it, even though they don't have conio.h. Also, it has more a richer command set, of the console screen, as does Curses, NCurses, and PDCurses.
The disadvantage of using the Windows API is it's more awkward, and won't work on Linux or OSX.
The Pelles C forum is here:
http://forum.pellesc.de/index.php
Download from:
Pelles C - Download
I won't be using or recommending ASNI escape codes, (ansicon), EVER, in this lifetime! :cool:
mingw supports conio.h too, but crippled if my memory serves me well.Quote:
Originally Posted by Adak
Why not? It's just an alternative option (I for one have used successfully a few times).Quote:
...
I won't be using or recommending ASNI escape codes, (ansicon), EVER, in this lifetime! :cool:
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.
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!Quote:
Originally Posted by Adak
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? :wink:
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
will work on any system, not just in Windows.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;
}
(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!)
Hell yes. ;)Quote:
So, if I may ask, are ANSI escape codes really that horrible, Adak?
This kind of gobblety-goop, is insufferable:
I'll stick with knowing the numbers for each terminal color: Black is zero, etc.Quote:
"\033[0m", "\033[1;32m", "\033[1;33m", "\033[1;32m", "\033[1;36m", "033[1;34m", "\033[1;37m".
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.
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? :tongue:Quote:
Originally Posted by Adak
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.Quote:
Originally Posted by Adak
My own opinion, since I don't use Windows, does not count.
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.Quote:
Originally Posted by Adak
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.
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:Quote:
Originally Posted by Nominal Animal
\033[1;37m;
IS gobblety-goop. :cool:
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.Quote:
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.
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.Quote:
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 like the Windows API, but I certainly appreciate what Windows has done for the PC application programs, and the PC user.
Well, Microsoft themselves have, it is called PowerShell and it is excellent. Then there is Console2 which has been around since 2003. So i don't really know about that.Quote:
Originally Posted by Nominal Animal
Console2 uses cmd.exe as default, but supports any shell you throw at it. I have mine setup using PowerShell as standard, but when opening a new tab i can choose between cmd.exe, PowerShell, MSYS and Cygwin shells, also the look and feel is _completely_ configurable. I can say with a fair bit of confidence that Console2 with PoweShell rivals any shell on UNIX or Linux. And since it has been around for over 10 years now i can also confidently say that you haven't done your research on cmd.exe alternatives before making the above statement :D
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?Quote:
Originally Posted by Neo1
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.
PowerShell is a shell, not a terminal emulator.Quote:
Originally Posted by Neo1
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.
I didn't know about that! Do you know if it supports ANSI escape codes? Perhaps via a configuration setting or something?Quote:
Originally Posted by Neo1
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.
Well i tried running your above example program and it didn't work. I suppose it depends on the actual shell being used, since Console2 is simply a terminal emulator, as you call it.Quote:
Originally Posted by Nominal Animal