DOS box gets messed up with win32gdk version

ROOT
#1

Hello,
Has anybody seen this difficult-to-reproduce phenomena with win32gdk root (3.10/01) on win2k? Occasionally, the DOS window (e.g. Rint interface) gets into a mode where it stops displaying text properly: it stops processing CR and LF characters - the cursor ends up at the right hand side of the last line. I can still type commands (e.g. Inspect()) but output to stdout is lost forever. I’ve never seen this problem with the win32.

When this happens, where there should be a CR LF pair, I see instead a symbol that looks like a music note and a symbol that looks like a square with a dot in it [These are the characters that show up on my ASCII Character codes chart for CR and LF respectively]

Does anybody know how to coax the dos box to interpret rather than display these special characters - that would be a useful workaround…

Thanks,
Ed

#2

Hi Ed,
strange, never seen. How to reproduce it?

Thanks. Regards. Valeriy

#3

Hi Valeriy,

The problem only seems to happen after the following code is called in response to a TGPopupMenu’s Entry click. This code re-directs stdout to a file, calls the printout method of my object, *pMyObject, displays the text in a TRootHelpDialog and then restores (or does it?) stdout:

Thanks,
Ed

	int oldstdout = _dup(1);		// file handle = 1 for stdout

Also, somethimes, when I call the above code, I get the following messages:

	if (oldstdout==-1) exit(1);
	FILE  *newstdout = fopen("myobject","w");
	if (!newstdout) exit(1);
	if (-1==_dup2(_fileno(newstdout),1)) exit(1);

	// Capture the text to a file and flush it
	pMyObject->Print();
	fflush(stdout);
	fclose(newstdout);

	// And here's where we restore stdout
	_dup2(oldstdout,1);

	// Now, open the TRootHelpDialog
	TRootHelpDialog *hd = new TRootHelpDialog(this,"ImagoRoot: MyObject",850,750);
	char *text = new char[10000];
	FILE *fp = fopen("myobject","rb");
	fread(text,1,10000,fp);
	fclose(fp);
	hd->SetText(text);
	hd->Popup();
	fClient->WaitFor(hd);

Note: somethines, I get the following message when I execute this code (usually when launched from devstudio, but not always). The presense of these warnings does not appear to be correlated to dos box screwup…

Gdk-WARNING **: gdk_text_size: gdk_nmbstowchar_ts failed

Gdk-WARNING **: gdk_draw_text: gdk_nmbstowchar_ts failed

Gdk-WARNING **: gdk_draw_text: gdk_nmbstowchar_ts failed

#4

Hi Ed,
could you attach the whole program source (if possible)
or simplified version which I could compile and test?

Thanks. Regards. Valeriy

#5

Hi Valeriy,
I will attempt to isolate this particular problem, but it is not reproducable (hence my earlier query about thread safety…) Also, just today it happened again, and without the above code snippet getting called…
Ed

#6

I’m still experiencing this problem, but I found a way to recover: when it happens I execute the following win32 code SetConsoleMode(GetConsoleHandle(STD_OUTPUT_HANDLE),ENABLE_PROCESSED_OUTPUT)from the gui.

Ed

#7

Hi Ed, thanks.
I’ll try to add this statement somewhere in
the console input processing loop.

Regards. Valeriy

#8

Hi Ed,
do you mean

GetStdHandle(STD_OUTPUT_HANDLE)
NOT GetConsoleHandle(STD_OUTPUT_HANDLE) ?

Regards. Valeriy

#9

now in CVS

#10

Hi Valeriy,
I don’t know whats wrong with my fingers, yes, I mean GetStdHandle(STD_OUTPUT_HANDLE). Thnaks!
Ed

#11

Hi,
I saw the patch is in, but it doesn’t resolve it. Maybe it’s related to this problem:

gives (with my win width)

I can’t remember having seen this “in the old days” (win32). Is there some extra buffer that does the std output handling in win32gdk?
Axel.

#12

Hi! I’ll check it. Valeriy

#13

Hi,
any progress? I checked the VC libs call part - looks fine. The VC libs call WriteFile with the proper characters, but somehow the FILE descriptor (2) doesn’t eat them properly. So - is this file descriptor replaced somewhere inside gdk? I couldn’t find any obvious replacement…

Is there a way to turn off threading for gdk, to test whether that’s the source of the problems?

Axel.

#14

Hi Axel,
I see weirdness, but have no idea of origin for a moment.

Regards. Valeriy

++
btw, I looked for “printf” code at CRT sources, but didn’t find.
There is it?

#15

Hi,

this is still unchanged and unresolved. printf’s source is at …MSVStudio.NET\Vc7\crt\src\fprintf.c. Here’s the relevant backtrace of a warning:

> msvcr70.dll!write_char(char ch='W', _iobuf * f=0x7c0495a8, int * pnumwritten=0x01c02104) Line 1139 C msvcr70.dll!write_string(char * string=0x7c0495a8, int len=162, _iobuf * f=0x7c0495a8, int * pnumwritten=0x00000057) Line 1258 + 0xd C msvcr70.dll!_output(_iobuf * stream=0x7c0495a8, const char * format=0x1033fefe, char * argptr=0x01c02178) Line 1031 + 0xe C msvcr70.dll!fprintf(_iobuf * str=0x1033ff4c, const char * format=0x1033ff08, ...) Line 48 C libCore.dll!DefaultErrorHandler(int level=1000, bool abort=false, const char * location=0x103cb237, const char * msg=0x066a0de8) Line 124 + 0x16 C++ libCore.dll!DefaultErrorHandler(int level=1000, bool abort=false, const char * location=0x103cb237, const char * msg=0x066a0de8) Line 124 + 0x16 C++ libCore.dll!ErrorHandler(int level=1000, const char * location=0x103cb237, const char * fmt=0x01a88768, char * ap=0x01c0222c) Line 167 + 0x21 C++ libCore.dll!TObject::DoError(int level=1000, const char * location=0x01a89148, const char * fmt=0x01a88768, char * va=0x01c0222c) Line 948 + 0x38 C++ libCore.dll!TObject::Warning(const char * location=0x01a89148, const char * fmt=0x01a88768, ...) Line 971 + 0x1d C++

From the debug output I can see that the stream is ==stderr. write_char calls _putc_lk(char, FILE*) (see output.c:1135), but for that there are no sources anymore. This part just fills the buffer, directly afterwards the buffer (file handle==2) is flushed:

> msvcr70.dll!_write_lk(int fh=2, const void * buf=0x06563d88, unsigned int cnt=163) Line 182 C msvcr70.dll!_write(int fh=2, const void * buf=0x06563d88, unsigned int cnt=163) Line 79 + 0xc C msvcr70.dll!_flush(_iobuf * str=0x7c0495a8) Line 163 + 0xa C msvcr70.dll!_ftbuf(int flag=1, _iobuf * str=0x7c0495a8) Line 154 C msvcr70.dll!fprintf(_iobuf * str=0x7c0495a8, const char * format=0x1033fefc, ...) Line 69 + 0x9 C libCore.dll!debugPrint(const char * fmt=0x1033ff4c, ...) Line 69 + 0x1d C++ libCore.dll!DefaultErrorHandler(int level=1000, bool abort=false, const char * location=0x103cb237, const char * msg=0x066a0de8) Line 124 + 0x16 C++ libCore.dll!ErrorHandler(int level=1000, const char * location=0x103cb237, const char * fmt=0x01a88768, char * ap=0x01c0222c) Line 167 + 0x21 C++ libCore.dll!TObject::DoError(int level=1000, const char * location=0x01a89148, const char * fmt=0x01a88768, char * va=0x01c0222c) Line 948 + 0x38 C++ libCore.dll!TObject::Warning(const char * location=0x01a89148, const char * fmt=0x01a88768, ...) Line 971 + 0x1d C++
where _write_lk calls WriteFile((HANDLE)_osfhnd(2), char* buffer, len, &written, NULL) (again, no source). Looks all good to me, I can’t see any corruption in the buffers - but it still doesn’t work.

What can we do about that? Philippe, do you have any idea? I still suspect threading (well, more precisely locking) to be the issue, but I wouldn’t know how to test that.
Axel.