- Forum
- General C++ Programming
- Command prompt buffer problem.
Command prompt buffer problem.
I've coded a packet sniffer as console application that outputs a lot of different data into console. I use SetConsoleScreenBufferSize to increase maximum buffer size. On Windows 7 system it works fine, but on Windows XP it has problems dealing with large data output. On Windows XP application usually just terminates without any error notifications if it receives a large amount of data in a relatively short period of time.
Is there any way to improve program's behaviour on XP system? If not, what would be the good alternatives to it?
Is there any way to improve program's behaviour on XP system? If not, what would be the good alternatives to it?
Drop windows xp and worry more about linux / mac portability.
Other than that, an alternative is to not use console, you can use ncurces, or a gui (which is a bit overkill).
Other than that, an alternative is to not use console, you can use ncurces, or a gui (which is a bit overkill).
I really can't stand responses like that. They're myopic -- how does telling OP to ditch XP help him solve his problem on XP systems?
The Windows Console is not designed to have unlimited scroll -- even on nixen very few are so designed (the cost is not inconsequential).
No matter your system there are limits to the amount of data buffered by the console emulator. And each person's emulator setup may be different. IIRC, the default xterm buffer size is only 1000 lines, which isn't a whole lot for scrolling back over large files dumped to the terminal.
Heck, there are still people using plain old, non-emulated text terminals, which don't have scrollbuffers.
If OP really wants to have all this information available, dump to file. Thereafter other utilities can observe the file -- even in real time -- and make life a lot easier for the user.
It isn't necessary to output to only one file stream either -- you can print to both the console and to a file. Personally I would make this tee action an optional configuration -- it takes very little for the code to do it and helps those on systems that don't, by default, have command utilities like tee and tail and less (like Windows).
BTW, NCurses does not replace the console, it is simply a library that allows users to query and use the full powers of their standard console. It cannot help you manage the scrollbuffer of your favorite terminal emulator.
Hope this helps.
The Windows Console is not designed to have unlimited scroll -- even on nixen very few are so designed (the cost is not inconsequential).
No matter your system there are limits to the amount of data buffered by the console emulator. And each person's emulator setup may be different. IIRC, the default xterm buffer size is only 1000 lines, which isn't a whole lot for scrolling back over large files dumped to the terminal.
Heck, there are still people using plain old, non-emulated text terminals, which don't have scrollbuffers.
If OP really wants to have all this information available, dump to file. Thereafter other utilities can observe the file -- even in real time -- and make life a lot easier for the user.
It isn't necessary to output to only one file stream either -- you can print to both the console and to a file. Personally I would make this tee action an optional configuration -- it takes very little for the code to do it and helps those on systems that don't, by default, have command utilities like tee and tail and less (like Windows).
BTW, NCurses does not replace the console, it is simply a library that allows users to query and use the full powers of their standard console. It cannot help you manage the scrollbuffer of your favorite terminal emulator.
Hope this helps.
Thanks, I guess I'll add an option to dump to file then and disable console output if program is running on XP.
I haven't looked at the API for you, but I'm pretty sure you can query the maximum size you can set the console screen buffer before trying -- there's no need to let your program crash. And the user will probably still like seeing stuff dump to screen, even if they need to open a file to review it.
I don't know what utilities exactly you could use, but it's also easily possible to pipe the output of your program into something that will buffer and display the data on the console (like less). You could probably write one for yourself if you wanted.
I don't know what utilities exactly you could use, but it's also easily possible to pipe the output of your program into something that will buffer and display the data on the console (like less). You could probably write one for yourself if you wanted.
Do you mean a sort of middleman between collected data and console output? I guess I could store collected data in another buffer and send it to console at slower pace then, good idea, thanks.
Topic archived. No new replies allowed.