Member Avatar for karan.rks

hey...

I'm coding a program for my school project and i have come across a very different problem!!

I was using graphics.h in my program... everything is running great.. even graphics are doing well... but after some time... that is after some input... the size of the text shrinks... and it shrinks after every command and in d end it is a block as if all the text is shrinked into a block... and even the program stops after the maximum shirnking.....

is dere some problem with the memory??
is it because of many function calls and storage... because it is a big project... around 1000 lines of codes...
is it because the memory is full..??

  • 2 Contributors
  • 3 Replies
  • 381 Views
  • 21 Hours Discussion Span
  • Latest Post Latest Post by Ancient Dragon

Dani AI

Generated

— the shrinking text you describe is a classic symptom when using Borland’s old BGI graphics.h: BGI is a DOS-era graphics library that loads drivers and font data into memory, and it was written for 16-bit DOS environments rather than modern Windows. That incompatibility plus any in-program memory corruption can produce exactly the “text gets smaller then becomes a block” behavior you’re seeing. (en.wikipedia.org)

As suggested, the compiler memory model matters: 16‑bit Turbo C++ uses memory models (tiny/small/medium/large/huge) that change whether pointers are near/far and whether data is limited to a 64KB data segment; switching to a larger model can remove that particular 64KB DGROUP limit. However, even with a large model the most common root cause is memory corruption (stack overflow, overrunning local arrays, bad pointers, strcpy/scanf overruns) which produces unpredictable graphical glitches. (stackoverflow.com)

Practical troubleshooting (in order):

  • Make a minimal reproducer that only draws text in a loop; if it fails there you’ve isolated the problem.

  • Check initgraph/graphresult() right after init to ensure the driver/font loaded correctly. Example check:

    int gd = DETECT, gm;
initgraph(&gd, &gm, "C:\\TC\\BGI");
if (graphresult() != grOk) { printf("graph init failed: %d\n", graphresult()); return 1; }

  • Look for large local arrays or deep recursion (move big buffers to heap or static/far data), audit every use of string functions, and initialize pointers. Use small test programs and incremental builds to narrow the fault. Valgrind-like tooling or careful code review helps find subtle overwrites. (valgrind.org)

If the program only runs under Turbo C++ on modern Windows, try running it under DOSBox or porting the code to a modern BGI port (WinBGIm or SDL_bgi) so the DOS/16‑bit compatibility layer isn’t the variable. That often both fixes weird behavior and avoids the 16‑bit toolchain limits. (dosbox.com)

Recommended Answers

All 3 Replies

Member Avatar for Ancient Dragon

Are you using Turbo C++? What version of MS-Windows are you using? The number of lines of code is not relevent. What is relevant is how much memory your program uses. Are you compiling with Large memory model? If not, try that and see if it helps.

Member Avatar for karan.rks

How much memory can a compiler have ??
And should I calculate all the size of the variables used and d objects used??

I'm facing this problem n windows 7 and also win xp... Both...
And yes.. I'm using turbo c++ as my compiler

Member Avatar for Ancient Dragon

Large memory model programs can have at most about 640K (actually less because MS-DOS operating system consumes some of it), which is not very much. Small memory models are limited to 64K. You can check the memory size of your program with MS-Windows Task Manager. Here is a more complete explaination.

Edited by Ancient Dragon
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.