graphics.h Header File with no functions!

[Mavericks]

Why does not graphics.h have required modules?

Do i need to import them or use another different graphics.h from another version of compiler?

What is the possible solution here?


http://www.docstoc.com/docs/34119635...aphics-Using-C

Page #136


I am trying to compile the code for lineChart but it's tough as I get the following errors upon using the Turbo C 2.01 version.

Linker Error: Undefined symbol '_closeGraphics' in module XYZ.C
Linker Error: Undefined symbol '_openGraphics' in module XYZ.C
Linker Error: Undefined symbol '_pPolymarker' in module XYZ.C
Linker Error: Undefined symbol '_pPolyline' in module XYZ.C
Linker Error: Undefined symbol '_pText' in module XYZ.C


Following is the XYZ.C code:

#include <stdio.h>
#include <GRAPHICS.H>
#include <conio.h>
#include <math.h>

#define WINDOW_WIDTH 600
#define WINDOW_HEIGHT 500

/* Amount of space to leave on each side of the chart */
#define MARGIN_WIDTH 0.05 * WINDOW_WIDTH
#define N_DATA 12

typedef struct { float x, y; } wcPt2;

typedef enum
{ Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec } Months;
char * monthNames[N_DATA] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun",
"Jul", "Aug", "Sep", "Oct", "Nov", "Dec" };

pPolyline ( int n, wcPt2 * pts );
pText ( wcPt2 position, char * txt );
pPolymarker( int n, wcPt2 * pts );

int readData (char * inFile, float * data)
{
int fileError = 0;
FILE * fp;
Months month;

if ( ( fp = fopen(inFile, "r")) == NULL)
fileError = 1;
else {
for (month = Jan; month <= Dec; month++)
fscanf ( fp , "%f", &data[month]);
fclose (fp) ;
}
return fileError;
}

void linechart (float * data)
{
wcPt2 dataPos[N_DATA], labelPos;
Months m;
float mWidth = (WINDOW_WIDTH - 2 * MARGIN_WIDTH) / N_DATA;
int chartBottom = 0.1 * WINDOW_HEIGHT;
int offset = 0.05 * WINDOW_HEIGHT; /* Space between data and labels */
int labelLength = 24; /* Assuminq fixed-width 8-pixel characters */
labelPos.y = chartBottom;

for (m = Jan; m <= Dec; m++) {
/* Calculate x and y positions for data markers */
dataPos[m].x = MARGIN_WIDTH + m * mWidth + 0.5 * mWidth;
dataPos[m].y = chartBottom + offset + data[m];
/* Shift the label to the left by one-half its length */
labelPos.x = dataPos[m].x - 0.5 * labelLength;
pText (labelPos, monthNames[m]);
}
pPolyline (N_DATA, dataPos);
pPolymarker (N_DATA, dataPos);
}

void main (int argc, char ** argv)
{
float data[N_DATA];
int dataError = 0;
long windowID;

if (argc < 2 )
{
fprintf (stderr, "Usage: %s dataFileName\n", argv[0]);
exit();
}
dataError = readData (argv[1], data);
if (dataError)
{
fprintf (stderr, "%s error. Can't read file %s\n", argv[1]);
exit ();
}
windowID = openGraphics (*argv, WINDOW_WIDTH, WINDOW_HEIGHT);
setbkcolor(WHITE);
setcolor(BLACK);
linechart(data);
sleep(10);
closeGraphics(windowID);
}

[S_M_A]

You need to link your application with a library as well. Probably graphics.lib or something similar. Search the Turbo C lib folder.

[Mavericks]

Now, I understand that CS.LIB's for the Math Model Library.

Atleast the linker says linking to as GRAPHICS.LIB.

Now upon doing tlink /x linechar.obj, graphics.lib.

When I run the program after successful compilation,
I get the following error:

LINKER ERROR: Illegal OBJ record in file .\GRAPHICS.LIB


When I enter tlink /x linechar.obj, graphics.lib at command prompt,
I get the following errros:

Turbo Link Version 2.0 Copyright (c) 1987, 1988 Borland International
Undefined symbol '_CLOSEGRAPHICS' in module LINECHAR.C
Undefined symbol '_SLEEP' in module LINECHAR.C
Undefined symbol '_SETCOLOR' in module LINECHAR.C
Undefined symbol '_SETBKCOLOR' in module LINECHAR.C
Undefined symbol '_OPENGRAPHICS' in module LINECHAR.C
Undefined symbol '_EXIT' in module LINECHAR.C
Undefined symbol '_FPRINTF' in module LINECHAR.C
Undefined symbol '__STREAMS' in module LINECHAR.C
Undefined symbol '_PPOLYMARKER' in module LINECHAR.C
Undefined symbol '_PPOLYLINE' in module LINECHAR.C
Undefined symbol '_PTEXT' in module LINECHAR.C
Undefined symbol 'SPUSH@' in module LINECHAR.C
Undefined symbol 'FIWRQQ' in module LINECHAR.C
Undefined symbol 'FIDRQQ' in module LINECHAR.C
Undefined symbol '_FCLOSE' in module LINECHAR.C
Undefined symbol '_FSCANF' in module LINECHAR.C
Undefined symbol '_FOPEN' in module LINECHAR.C
Warning: no stack

Hope this information helps

[Paul McKenzie]

Why does not graphics.h have required modules?

The errors you posted are linker errors, not compiler errors. Those errors have nothing to do with header files.

You need to do research and find where these functions that are missing are found. In one of those libraries is where you find those functions.

Do i need to import them or use another different graphics.h from another version of compiler?

Is there a reason why you're using a compiler that is over 20 years old? It makes it more difficult to find help on this old compiler, since practically no one uses it. There are much more modern free versions of C++ (and C) compilers.

In addition, none of these functions may work for a modern operating system. Learn real Windows console programming instead of old MSDOS stuff that may not even work.

Regards,

Paul McKenzie

[Mavericks]

Originally Posted by Mavericks
Why does not graphics.h have required modules?

The errors you posted are linker errors, not compiler errors. Those errors have nothing to do with header files.

You need to do research and find where these functions that are missing are found. In one of those libraries is where you find those functions.

Quote:
Do i need to import them or use another different graphics.h from another version of compiler?

Is there a reason why you're using a compiler that is over 20 years old? It makes it more difficult to find help on this old compiler, since practically no one uses it. There are much more modern free versions of C++ (and C) compilers.

In addition, none of these functions may work for a modern operating system. Learn real Windows console programming instead of old MSDOS stuff that may not even work.

The text with the example program was made in '97.
So, I am really curious to know the environment authors used to implement those programs.

It would help if Borland compiler was used for testing/implementations purposes.
Hope this helps.

yes, I'm certainly interested in implementation with modern compilers, and real windows console programming.

However, I'm interested to know the way it works using both old and new compilers.

[Paul McKenzie]

The text with the example program was made in '97.

So the authors used a compiler that was 12 years old. That is bad enough, but it is now 2010.

So, I am really curious to know the environment authors used to implement those programs.

The environment is MSDOS, a 16-bit operating system that was popular before the first version of Windows 95 came out. Windows NT had "DOS compatibility mode", where old MSDOS programs were able to run in a 16-bit subsystem.

It would help if Borland compiler was used for testing/implementations purposes.
Hope this helps.

Those graphics commands may not even work, since they rely on BIOS calls, calls that may not even exist anymore in any "compatibility mode". It makes no sense trying to revive old history, especially if you are attempting to run these programs an anything above Windows NT (and it may not even work there).

I've been doing programming on Microsoft operating systems ever since the IBM PC first came out. I know about the Hercules, VGA, and EGA video modes, addressing screen memory directly, video pages, and all of the other tricks used to do output in the MSDOS system. I've written commercial 'C' libraries that did this type of programming. So take this advice, and I'm being honest -- this type of programming you are doing is now obsolete. If you really want to learn modern graphics programming, get into OpenGL, DirectX, or even just plain old Windows API programming.

However, I'm interested to know the way it works using both old and new compilers.

You don't need a compiler to know how it was done using MSDOS. Just google "MSDOS","graphics programming", "interrupt" and you get all the information you need to set the video mode to do graphics in MSDOS. All those functions that the Turbo C compiler did was to turn on the graphics mode and light up pixels so that you can easily do circles and lines. An intermediate programmer could easily duplicate all of those functions that the Turbo C compiler provided.

But as I stated, there is no guarantee that any of these programs will even work on a modern OS -- I haven't tried to run such programs in years.
A simple call to a BIOS function to set the video mode will tell you right away whether you are wasting your time or not. If it doesn't work on your OS, then forget about it and learn modern graphics programming.

Regards,

Paul McKenzie

[Mavericks]

Those graphics commands may not even work, since they rely on BIOS calls, calls that may not even exist anymore in any "compatibility mode".
It makes no sense trying to revive old history, especially if you are attempting to run these programs an anything above Windows NT (and it may not even work there).

This was my concern at the beginning but I wasn't totally sure due to lack of experience. Thanks for the confirmation.
So, I thought if this was the case, then I could just use an emulator to get windows NT or below and then run it.

I've been doing programming on Microsoft operating systems ever since the IBM PC first came out. I know about the Hercules, VGA, and EGA video modes, addressing screen memory directly, video pages, and all of the other tricks used to do output in the MSDOS system. I've written commercial 'C' libraries that did this type of programming. So take this advice, and I'm being honest -- this type of programming you are doing is now obsolete. If you really want to learn modern graphics programming, get into OpenGL, DirectX, or even just plain old Windows API programming.

Thank you so much for the above information. It's great to hear your programming experience. I will surely take your advice. No doubt about that
As convincing as it is for me to just get into OpenGL (especially considering the text mentioned in my first post of this thread which has a new edition coming out in a few months based on OpenGL as well )
I'm trying to see if I will be able to better understand the scenario or the transition from the pros and cons obsolete to modern graphics programming.
Just like I can't appreciate light until I see darkness.
Let me know your thoughts on this.
I have to say that I shall eventually or rather left with no option but to move into modern graphics programming.
How soon is the question? right away?

You don't need a compiler to know how it was done using MSDOS. Just google "MSDOS","graphics programming", "interrupt" and you get all the information you need to set the video mode to do graphics in MSDOS. All those functions that the Turbo C compiler did was to turn on the graphics mode and light up pixels so that you can easily do circles and lines. An intermediate programmer could easily duplicate all of those functions that the Turbo C compiler provided.

When I looked at the files in the zip file of the Turbo C compiler , I just thought that with enough patience, research, programming and may be testing, I could write my own compiler that does the same as Turbo C. I got this feeling after I looked at the some of the libraries or header files in the Turbo C folder ,but I wasn't confident enough on my c programming skills.(assumption that I needed to be really good at C to write those libraries)
I really did think so however I wasn't bold enough to take that step and resorted to see what Turbo C had to offer. I guess I was lazy if I think about it for a second , and was constrained by time apart from circumstances that weren't in my favor to perform such tasks.

But as I stated, there is no guarantee that any of these programs will even work on a modern OS -- I haven't tried to run such programs in years.
A simple call to a BIOS function to set the video mode will tell you right away whether you are wasting your time or not. If it doesn't work on your OS, then forget about it and learn modern graphics programming.

Yeah, I will try this and post my result later on.