Points for rstaveley

I think we should continue here.
There is no use filling up the mailbox of the poor OP of that question as this is quite off-topic from that thread.

Repeating my last comment in the other thread:

>   Options | Compiler | Code generation | Standard stack frame | On/Off
>   Options | Stack warning | On/Off
>What are these set to in your IDE?

Both are ON.

>Do you get the linker warning, when you set Options | Compiler | Code Generation | OBJ >debug information | Off  and build this program? [I'd expect this to ensure that the library >stack code gets linked.]

Yes,but only when i set it to OFF.When i turn it back to ON,the warning vanishes.

>Do you mean large memory model programs or complex (lots of code) programs? If you >are routinely using a library or set of modules, in these programs it could be that you >have a wild pointer lurking in them and the default command line settings and debug IDE >settings happen allow you to get away with them. Or this could be related to the stack.

I use Huge Memory Model and the LOC is right now around 5 KLOC
The program works even then ,just that the o/p screen and the IDE screen come merged.
i.e. my background should be black but i get a blue background which is the bgcolor of the IDE and the o/p comes on top of that.
And the program works fine when i change both (i) and (ii) back to ON.
This program has been tested in various compilers and it works fine.

I'll try downloading and executing my program on TC2.01

I'll give a link to this question in the other thread,just in case,the OP there thinks there is overlap of requirements.

I start my cmd prompt with "%comspec% /k "C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\vsvars32.bat"" because I mostly use the Microsoft compiler on Windows. With Turbo C 2.01 installed in c:\tc, I get the output displayed when I press Alt+F5 for the "user screen", and I see the hello.c output overwriting what was there before the IDE started up:
--------8<--------
Hello, worldronment for using Microsoft Visual Studio .NET 2003 tools.
(If you have another version of Visual Studio or Visual C++ installed and wish
to use its tools from the command line, run vcvars32.bat for that version.)

c:\Devt>cd\tc

C:\TC>tc hello.c


--------8<--------

Are you starting the IDE directly from a shortcut (or Start | Run), or are you doing it from the cmd.exe prompt?

One last thought with reference to your 3.0 set-up... try renaming c:\tc\tcconfig.tc to (say) c:\tc\tcconfig.old. That should cause your IDE to run with shipped defaults.

You can use tcconfig.exe to reconfigure your compiler to new defaults.

According to my compiler defaults,which came after renaming my tcconfig.tc file,

Options | Compiler | Code generation | Standard stack frame | On/Off
Options | Stack warning | On/Off

Both are ON.

I dont have a tcconfig.exe.

I am starting TC from a windows shortcut(.pif).

In my case,the O/p screen merges with the IDE screen(the blue screen)  and not the command screen before the IDE loaded.

More importantly,

The other options are also ON.

Debug info. in OBJ -ON
Source Debugging -ON

I guess you can call system("cls") at the beginning of your program or call conio's clrscr(), if you need an easy fix for the shared screen, but it does sound odd.

Do you overwrite the screen previously seen at the DOS prompt if you start tc from the command prompt?

I've noticed that direct screen writes and hardware access are a bit flakey in Windows.

e.g. The following "classic":
--------8<--------
#include <dos.h>

display_char(char c,int column,int row,unsigned char attr)
{
char far *dst = (char far*)MK_FP(0xb800,row*80*2+column*2);

        *dst++ = c;
        *dst++ = attr;
}

display_string(char *str,int column,int row,unsigned char attr)
{
        while (*str)
                display_char(*str++,column++,row,attr);
}

main()
{
        display_string(" Hello, World! ",20,20,0xcf);
}
--------8<--------

The direct screen writes only show up, if I have previously written or read from the virtual CGA/VGA screen memory using debug.exe.

debug
--------8<--------
e b800,0 7             <- Writes the bell character into top left hand corner
q

--------8<--------

Debug must do something in Windows to get it to virtualise the screen memory properly in virtual 8086 sessions, which our humble DOS executables built by Turbo C fail to do.

It could well be that you are getting bitten by direct screen writes, which it is a fair assumption the IDE uses (I recall that the screen updated very quickly on my old 80286, which suggests that Borland wrote directly to screen memory in its IDEs).

> More importantly,...The other options are also ON.

Yes but they would be in the IDE, because it has an integrated debugger. You need to disable debug for the release build only. You can of course disable debug by default, but you shouldn't expect the integrated debugger to work.

Oh yes,my program calls clrscr() first up.

>Do you overwrite the screen previously seen at the DOS prompt if you start tc from the >command prompt?

No.I clear the screen and then start my display.

>display_char(char c,int column,int row,unsigned char attr)

Isnt this attr value used for setting the background color or is it something else?

This is what i i think i can do:

Since i might need the debugger while writing the program,i'll enable the debugging options
in the IDE.

When i'm done and if i need to distribute the EXE,i can compile and link my program using TCC rather than having to change my IDE settings and then changing them back for the next program.

...I've been on holiday for a week.

> attr

In a 80x25 CGA (or VGA) screen you have 80x25x2 bytes. The first byte is the first 8 bit character and the second is its attribute. The attribute consists of the foreground and background colours, the least significant nibble being the foreground colour.

Sounds like you've got an expedient solution, but it sounds very wrong that you can't reliably create a release with the IDE.

Did you have time to see if you got the same on 2.01?

Not till now.Sorry.

I am having Exams right now so i'll try it out this weekend.
Sorry for the delay.

Good luck in your exams :-)

Hi rstaveley,

Thanx for the wishes.

I tried executing my program on TC 2.01 but it didnt work.
My program is in C++ and the IDE doesnt support C++.
It doesnt even have iostream.h

In which case, you'd need to try Turbo C++ 1.01 from the museum - see http://community.borland.com/museum/ 

It is 2.7M (vintage 1991)

I can't believe i am going *back* versions. :~))

I know it seems a bit retrograde, but if you can reproduce your problems in a freely available version of the Borland compiler, we stand a better chance of identifying whatever it is that's causing the problem. It sounds like you have something corrupt in your set-up, but it is hard to figure out at this point.

How complex is the simplest project you can put together, which reproduces the problem?