Console and stdout under Windows

Hi to everyone… I found something that could be of interest.

When “console application” project is made under VC, that annoying console window appears.
However, I have to use “console application” to be able to
print to stdout correctly ( not to stdout.txt ).
It is possible to close that console window with
ShowWindow(console_hwnd,SW_HIDE)

To find console_hwnd I enumerate all top-level windows with
EnumWindows() and find one with matching title
(although there has to be a better way, I am just not to comfortable with this
win32-things)

Note: There are problems when starting this kind of program under VC since it adds line
"Press any key to continue" to console and waits for keypress before closing program.
Since console is already closed, it can’t get a keypress and program
never exits. But if program is run from command line, or on any other way,
just not from VC, all will be fine.

BTW how to redirect stderr under win98?

And another thing… I noticed that under “Win32 application” project,
one VIDEOEXPOSE event is sent when application starts
(and I use this event to redraw screen),
but under “Win32 console application” this event is not sent.
Anyone noticed this before, or is it an error in my program?
I thought VIDEOEXPOSE should always be sent on program start.

Hi,

It is I, Leclerc!

When “console application” project is made under VC, that annoying
console window appears.
However, I have to use “console application” to be able to
print to stdout correctly ( not to stdout.txt ).
It is possible to close that console window with
ShowWindow(console_hwnd,SW_HIDE)

It is possible to detach the console from the calling process using
FreeConsole(), and attach the new one using AllocConsole(). Be warned,
that process is allowed to have only one console. I like these API-es
because there are no aditional parameters to think about.

BTW how to redirect stderr under win98?

In console win32 application, it is possible to get handles of processes
console using function GetStdHandle. It is also possible to redirect
console IO using SetStdHandle. Using this API, it is possible to
redirect all std console IO to something else, like stderr->stdout, or
stderr -> file (which should be opened using CreateFile). According to
the documentation, this should work for winNT as well as Win9x. Hope
this is what you were looking for.

ciao,

Gordan Sikic

mailto:gordan.sikic at inet.hr> ----- Original Message -----

From: atomic@email.hinet.hr (Kresimir Cosic)
To:
Sent: Sunday, February 03, 2002 7:04 PM
Subject: [SDL] Console and stdout under Windows

Hi to everyone… I found something that could be of interest.

To find console_hwnd I enumerate all top-level windows with
EnumWindows() and find one with matching title
(although there has to be a better way, I am just not to comfortable
with this
win32-things)

Note: There are problems when starting this kind of program under VC
since it adds line
"Press any key to continue" to console and waits for keypress before
closing program.
Since console is already closed, it can’t get a keypress and program
never exits. But if program is run from command line, or on any other
way,
just not from VC, all will be fine.

And another thing… I noticed that under “Win32 application” project,
one VIDEOEXPOSE event is sent when application starts
(and I use this event to redraw screen),
but under “Win32 console application” this event is not sent.
Anyone noticed this before, or is it an error in my program?
I thought VIDEOEXPOSE should always be sent on program start.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

I think you’ve already got the answer to your question, but IIRC wasn’t
there someone else here who was planning to work on an addon lib for SDL
for cross-platform server consoles? I recall a fair bit of interest in
the project (including my own), but don’t recall anyone ever posting a
link to code or a fledgling project busy creating it.On Sun, Feb 03, 2002 at 07:04:50PM +0100, Kresimir Cosic wrote:

Hi to everyone… I found something that could be of interest.

When “console application” project is made under VC, that annoying console window appears.
However, I have to use “console application” to be able to
print to stdout correctly ( not to stdout.txt ).
It is possible to close that console window with
ShowWindow(console_hwnd,SW_HIDE)


Joseph Carter This thing is an AI

“…It was a lot faster than I thought it was going to be, much faster
than NT. If further speed increases are done to the server for the final
release, Oracle is going to be able to wipe their ass with SQL SERVER and
hand it back to M$ while the Oracle admins … migrate their databases
over to Linux!”

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020203/b77c6e10/attachment.pgp

Uhm, I might have been involved in that discussion…

Either way, I’m going to start hacking it right away. (In fact, I started
last week!)

I need it for a port of a Borland C++/DOS application to Linux. The way
the application is using the screen, and the way it’s supposed to work
evntually (with this text screen in a window on a remote Windoze box),
makes it seem like the best way is to reimplement my extended version of
Borland’s “constream”. (Large part of it isn’t using control codes, so
it’s not a simple matter of translating codes into some real terminal
standard…)

Goals for my little project:

* Simulated text screen. (More powerful than VGA, but similar
  design.)

* Windows with clipping and scrolling.

* Targets:	SDL graphics console
		Real Linux console (limited to ANSI codes)
		VGA hardware text screen (not for normal apps!)
		Remote console via pluggable "link drivers"

* Speed!!! :-)

Stuff that I don’t need right now, but will try to keep in mind:

* Redirection of stdout to the simulated console.

* Overlapping windows.

* Graphics windows.

* "Opaque standard widgets". (Edit boxes, buttons etc.)

* OpenGL target.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Sunday 03 February 2002 23:01, Joseph Carter wrote:

On Sun, Feb 03, 2002 at 07:04:50PM +0100, Kresimir Cosic wrote:

Hi to everyone… I found something that could be of interest.

When “console application” project is made under VC, that annoying
console window appears. However, I have to use "console application"
to be able to
print to stdout correctly ( not to stdout.txt ).
It is possible to close that console window with
ShowWindow(console_hwnd,SW_HIDE)

I think you’ve already got the answer to your question, but IIRC wasn’t
there someone else here who was planning to work on an addon lib for
SDL for cross-platform server consoles? I recall a fair bit of
interest in the project (including my own), but don’t recall anyone
ever posting a link to code or a fledgling project busy creating it.

I think you’ve already got the answer to your question, but IIRC wasn’t
there someone else here who was planning to work on an addon lib for
SDL for cross-platform server consoles? I recall a fair bit of
interest in the project (including my own), but don’t recall anyone
ever posting a link to code or a fledgling project busy creating it.

Uhm, I might have been involved in that discussion…

Maybe. I know I commented about something, but I’d have to go digging in
the archives to know what.

Either way, I’m going to start hacking it right away. (In fact, I started
last week!)

I need it for a port of a Borland C++/DOS application to Linux. The way
the application is using the screen, and the way it’s supposed to work
evntually (with this text screen in a window on a remote Windoze box),
makes it seem like the best way is to reimplement my extended version of
Borland’s “constream”. (Large part of it isn’t using control codes, so
it’s not a simple matter of translating codes into some real terminal
standard…)

Sounds like a tall order.

Goals for my little project:

  • Simulated text screen. (More powerful than VGA, but similar
    design.)

  • Windows with clipping and scrolling.

  • Targets: SDL graphics console
    Real Linux console (limited to ANSI codes)
    VGA hardware text screen (not for normal apps!)
    Remote console via pluggable “link drivers”

  • Speed!!! :slight_smile:

Yup, tall order. =)

My immediate goals are slightly simpler:

  • string output
  • scrollback and clipboard access, where supported
  • win32 window
  • Linux/whatever curses support (slcurses subset)
  • fallback to stdio when nothing else is available
  • Speed!!! =)

Stuff I don’t immediately need, but would be nice:

  • Character attributes, colors and the like
  • MacOS X window (maybe classic as well?)
  • Drawing to SDL_surfaces
  • Drawing to OpenGL contexts

I don’t need multiple windows, my target is a simple server console,
though obviously if it writes to both SDL and OpenGL surfaces it can be
used in-game as well. If it is to be used in-game though, attributes are
a necessity for me at least. As I already have an in-game console which
works fine, I’d rather spend my effort on doing a good server console,
which could like as not throw the character attributes away with little
harm.

MacOS classic windowing can wait for my purposes because I currently don’t
have any other support for it anyway. MacOS X could easily enough just
use the curses stuff for Linux and BSD and whatever else.

The reason for using the slcurses subset is pretty clear - some people
prefer slang’s broken behaviors to ncurses broken behaviors. :wink: Since
the slcurses stuff provides more than enough features for what I intend,
it’s worthwhile to develp[ to run under either.

Stuff that I don’t need right now, but will try to keep in mind:

  • Redirection of stdout to the simulated console.

  • Overlapping windows.

  • Graphics windows.

  • “Opaque standard widgets”. (Edit boxes, buttons etc.)

  • OpenGL target.

This is an even taller order. =) I don’t need a GUI here. I can direct
output to the console my own way - in fact all output at this stage goes
either to Com_Printf or Sys_Printf anyway. Both are capible of logging
and other nice features. Given that this is meant for servers, it should
be as lightweight as possible, so multiple windows and the like are just
too fat for my purposes.On Mon, Feb 04, 2002 at 11:44:26PM +0100, David Olofson wrote:


Joseph Carter Sanity is counterproductive

“As you journey through life take a minute every now and then to give a
thought for the other fellow. He could be plotting something.”
– Hagar the Horrible

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020205/3f6171e9/attachment.pgp

Sounds like a tall order.

Nah! Used to hack that kind of stuff in asm back in the Amiga days. It
was usually the easy part! :slight_smile:

Goals for my little project:

* Simulated text screen. (More powerful than VGA, but similar
design.)

* Windows with clipping and scrolling.

* Targets:	SDL graphics console
  	Real Linux console (limited to ANSI codes)
  	VGA hardware text screen (not for normal apps!)
  	Remote console via pluggable "link drivers"

* Speed!!! :-)

Yup, tall order. =)

My immediate goals are slightly simpler:

  • string output
  • scrollback and clipboard access, where supported
  • win32 window
  • Linux/whatever curses support (slcurses subset)
  • fallback to stdio when nothing else is available
  • Speed!!! =)

Stuff I don’t immediately need, but would be nice:

  • Character attributes, colors and the like
  • MacOS X window (maybe classic as well?)
  • Drawing to SDL_surfaces
  • Drawing to OpenGL contexts

I’d say this sounds very much like something that could be implemented
on top of what I’m just about to hack.

What I need to implement is basically just a text screen “emulator” (not
VGA register compatible or anything!), the “conio” interface, and a
function that writes printf() formatter strings onto the emulated screen.

Everything beyond that is either implemented in the standard C or C++
libraries, or stuff that I won’t be needing right now.

I don’t need multiple windows, my target is a simple server console,
though obviously if it writes to both SDL and OpenGL surfaces it can be
used in-game as well.

That’s exactly what I was thinking about! :slight_smile:

If it is to be used in-game though, attributes
are a necessity for me at least.

I’ll need them right away, as well as simple, non-overlapping text
windows, as that DOS app uses it a lot.

As I already have an in-game console
which works fine, I’d rather spend my effort on doing a good server
console, which could like as not throw the character attributes away
with little harm.

I’ll probably start with the text screen emulation -> SDL_Surfaces. Seems
like some fun, and will be usable for various things I have in mind,
apart from the DOS->Linux port (the local “terminal”), and it’s remote
Windows terminal.

MacOS classic windowing can wait for my purposes because I currently
don’t have any other support for it anyway. MacOS X could easily
enough just use the curses stuff for Linux and BSD and whatever else.

The reason for using the slcurses subset is pretty clear - some people
prefer slang’s broken behaviors to ncurses broken behaviors. :wink: Since
the slcurses stuff provides more than enough features for what I
intend, it’s worthwhile to develp[ to run under either.

Would *curses be able to “push” an array of characters + attributes to
the console without incredible amounts of overhead?

(In fact, all you need is “cursor locate” commands, and a way of telling
the window size in characters. You can even get away with “home” + "nl"
and/or “cr” if you really have to!)

Stuff that I don’t need right now, but will try to keep in mind:

* Redirection of stdout to the simulated console.

* Overlapping windows.

* Graphics windows.

* "Opaque standard widgets". (Edit boxes, buttons etc.)

* OpenGL target.

This is an even taller order. =) I don’t need a GUI here.

What I’m thinking about here is basically a Delphi remote terminal
implementation that can smack in native Windows widgets, as an
alternative to the primitive text “widgets” that I’ve already implemented
on top of my extended constream interface in the DOS app.

I can
direct output to the console my own way - in fact all output at this
stage goes either to Com_Printf or Sys_Printf anyway.

My problem is that the application needs some notion of “windows” at
the very least. If I just pipe everything to stdout, it’ll just be a big
mess - unless I disable some very useful debugging and testing
features… heh

Both are capible
of logging and other nice features.

That sort of stuff is actually much higher level than what I have in mind
for the actual “text screen emulation”. The closest feature I’ve
considered is windows with a virtual offscreen buffer, that may be larger
than the window.

Given that this is meant for
servers, it should be as lightweight as possible, so multiple windows
and the like are just too fat for my purposes.

The kind of “windows” I’m talking about have been available in MS-DOS,
probably since the first few versions. :slight_smile:

In fact, they’re not even real windows, in that DOS only keeps track of
one at a time. The “constream” class simulates multiple windows by saving
the state of the text screen API, and then swapping that data around as
needed when writing into multiple windows.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 05 February 2002 12:40, Joseph Carter wrote:

Sounds like a tall order.

Nah! Used to hack that kind of stuff in asm back in the Amiga days. It
was usually the easy part! :slight_smile:

The PC lacks the hardware and OS of the Amiga.

My immediate goals are slightly simpler:
[…]

I’d say this sounds very much like something that could be implemented
on top of what I’m just about to hack.

All of your windowy stuff sounds like it is far overengineered from what
I’m looking for.

What I need to implement is basically just a text screen “emulator” (not
VGA register compatible or anything!), the “conio” interface, and a
function that writes printf() formatter strings onto the emulated screen.

Basically that’s all I need really, with a scrollback and an input line,
but that’s more or less seperate from drawing anyway.

I don’t need multiple windows, my target is a simple server console,
though obviously if it writes to both SDL and OpenGL surfaces it can be
used in-game as well.

That’s exactly what I was thinking about! :slight_smile:

Good - except that we need the non-graphics immediately and the graphics
stuff is a maybe future thing. =p

If it is to be used in-game though, attributes
are a necessity for me at least.

I’ll need them right away, as well as simple, non-overlapping text
windows, as that DOS app uses it a lot.

nod Understandable if you’re porting a dos program, it’s easier to have
different priorities since this is for new code here.

As I already have an in-game console
which works fine, I’d rather spend my effort on doing a good server
console, which could like as not throw the character attributes away
with little harm.

I’ll probably start with the text screen emulation -> SDL_Surfaces. Seems
like some fun, and will be usable for various things I have in mind,
apart from the DOS->Linux port (the local “terminal”), and it’s remote
Windows terminal.

MacOS classic windowing can wait for my purposes because I currently
don’t have any other support for it anyway. MacOS X could easily
enough just use the curses stuff for Linux and BSD and whatever else.

The reason for using the slcurses subset is pretty clear - some people
prefer slang’s broken behaviors to ncurses broken behaviors. :wink: Since
the slcurses stuff provides more than enough features for what I
intend, it’s worthwhile to develp[ to run under either.

Would *curses be able to “push” an array of characters + attributes to
the console without incredible amounts of overhead?

Yes and no. curses assumes that it knows best how to draw things. If
you have a reasonably good terminfo database and your terminal is fairly
smart, it can just go mad. OTOH, less intelligent terminals will be
slower. And of course, incorrect terminfo entries will result in odd
looking things.

(In fact, all you need is “cursor locate” commands, and a way of telling
the window size in characters. You can even get away with “home” + "nl"
and/or “cr” if you really have to!)

You have both of those, plus the ability to move the cursor around. You
can use that to draw to what curses SHOULD have on the screen. It then
attempts to determine the best way to make that happen, which may or may
not involve a similar set of commands to the ones you issued since last
update.

The analogy to something in OpenGL would be vertex arrays. Lots of pain
to carefully stuff the right things in the right places, make sure the
right states are set up, etc. Then you just call one function and what
you need just happens, just about as fast as the hardware can do it. =)

Stuff that I don’t need right now, but will try to keep in mind:

* Redirection of stdout to the simulated console.

* Overlapping windows.

* Graphics windows.

* "Opaque standard widgets". (Edit boxes, buttons etc.)

* OpenGL target.

This is an even taller order. =) I don’t need a GUI here.

What I’m thinking about here is basically a Delphi remote terminal
implementation that can smack in native Windows widgets, as an
alternative to the primitive text “widgets” that I’ve already implemented
on top of my extended constream interface in the DOS app.

Hell, why not just implement a VNC server! That’ll get you a remote
console with complete text and graphics support under just about any OS!

I can
direct output to the console my own way - in fact all output at this
stage goes either to Com_Printf or Sys_Printf anyway.

My problem is that the application needs some notion of “windows” at
the very least. If I just pipe everything to stdout, it’ll just be a big
mess - unless I disable some very useful debugging and testing
features… heh

I understand that. And I need a concept of a window too - for the curses
implementation at least. Need a status and edit line, so the screen needs
some division. I’m just intending to do that at a little higher level.

Both are capible
of logging and other nice features.

That sort of stuff is actually much higher level than what I have in mind
for the actual “text screen emulation”. The closest feature I’ve
considered is windows with a virtual offscreen buffer, that may be larger
than the window.

nod I wouldn’t do that even at the lowest levels. I think the key
approach to making it work well is the layering.

Given that this is meant for
servers, it should be as lightweight as possible, so multiple windows
and the like are just too fat for my purposes.

The kind of “windows” I’m talking about have been available in MS-DOS,
probably since the first few versions. :slight_smile:

In fact, they’re not even real windows, in that DOS only keeps track of
one at a time. The “constream” class simulates multiple windows by saving
the state of the text screen API, and then swapping that data around as
needed when writing into multiple windows.

The conio.h API at least has it, and that goes back at least to Borland C
3.0 and further.On Wed, Feb 06, 2002 at 12:08:22AM +0100, David Olofson wrote:


Joseph Carter Don’t feed the sigs

8am is an ungoldly hour to be awake :slight_smile:

  • gorgo usually gets up at 11am

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020205/13f3617a/attachment.pgp

I just hacked up a preliminary API spec for the lowest level of the “text
console emulator” I’m about to hack. It’s documented and on-line:

http://olofson.net/download/conemu.h

No SDL_Surface target yet - I wanted to keep the basic API totally
independent of SDL and other libraries, as I might have to backport it to
DOS or something… heh

I’m going to add ce_open_sdl(SDL_Surface *screen, …) or something like
that… A similar approach could be used to render into a raw RGB or RGBA
buffer, for OpenGL and the like. (Actually, that would work with SDL as
well, to some extent!)

Sounds like a tall order.

Nah! Used to hack that kind of stuff in asm back in the Amiga days.
It was usually the easy part! :slight_smile:

The PC lacks the hardware and OS of the Amiga.

Yeah - but this stuff was directly on the hardware, bypassing or entirely
disabling the OS.

Also note that the original Amiga lacked hardware text modes entirely -
everything was done in bitplane based graphics mode. :slight_smile:

My immediate goals are slightly simpler:

[…]

I’d say this sounds very much like something that could be
implemented on top of what I’m just about to hack.

All of your windowy stuff sounds like it is far overengineered from
what I’m looking for.

Dunno. Looking at conemu.h, you may notice that it could be
interpretted as supporting overlapping windows - but so could DOS
conio.h, which doesn’t! :wink:

conemu probably will support overlapping windows eventually, although I
don’t really need them right now. (Other projects I have in mind will,
though.)

What I need to implement is basically just a text screen “emulator”
(not VGA register compatible or anything!), the “conio” interface,
and a function that writes printf() formatter strings onto the
emulated screen.

Basically that’s all I need really, with a scrollback and an input
line, but that’s more or less seperate from drawing anyway.

Yeah. Calling ce_scanf() should give you something like a line editor at
the current cursor position, and suitable keys could be used to inc/dec
the virtual scroll postion of the current window.

I think I’ll have ‘\n’ on the last line of a virtual window scroll the
whole buffer up one line, just as DOS conio does it by default, so that’s
all there is to it - except that someone needs to figure out what to do
about the cursor '\n’ing outside the visible part of the window. Maybe
just scroll (using the virtual offset) automatically - but I’d rather
have that optional, as some applications may not like it…

I don’t need multiple windows, my target is a simple server
console, though obviously if it writes to both SDL and OpenGL
surfaces it can be used in-game as well.

That’s exactly what I was thinking about! :slight_smile:

Good - except that we need the non-graphics immediately and the
graphics stuff is a maybe future thing. =p

Whereas I need the graphics mode right away, and perhaps the text part
later… :slight_smile:

If it is to be used in-game though, attributes
are a necessity for me at least.

I’ll need them right away, as well as simple, non-overlapping text
windows, as that DOS app uses it a lot.

nod Understandable if you’re porting a dos program, it’s easier to
have different priorities since this is for new code here.

Yeah… But how about my proposed API? If I hack up the skeleton and a
rudimentary SDL and stdio implementations, could your implementation fit
in? (I’ll probably use some “backend plugin struct” internally, so you
just have to fill one in and add it to the list of targets. Would be nice
to know more about *curses before designing that, though.)

[…]

Would *curses be able to “push” an array of characters + attributes
to the console without incredible amounts of overhead?

Yes and no. curses assumes that it knows best how to draw things. If
you have a reasonably good terminfo database and your terminal is
fairly smart, it can just go mad. OTOH, less intelligent terminals
will be slower. And of course, incorrect terminfo entries will result
in odd looking things.

But if say, mc works, can I assume that such operations will work? (Don’t
know how mc does stuff.)

(In fact, all you need is “cursor locate” commands, and a way of
telling the window size in characters. You can even get away with
"home" + “nl” and/or “cr” if you really have to!)

You have both of those, plus the ability to move the cursor around.
You can use that to draw to what curses SHOULD have on the screen. It
then attempts to determine the best way to make that happen, which may
or may not involve a similar set of commands to the ones you issued
since last update.

The analogy to something in OpenGL would be vertex arrays. Lots of
pain to carefully stuff the right things in the right places, make sure
the right states are set up, etc. Then you just call one function and
what you need just happens, just about as fast as the hardware can do
it. =)

Well, that’s kind of similar in philosoyhy to my conemu - although my API
is based on a simple, “brute force” buffer paradigm. Kind of like an
emulator of on of those old video controllers with hardware window
support. :slight_smile:

Stuff that I don’t need right now, but will try to keep in mind:

* Redirection of stdout to the simulated console.

* Overlapping windows.

* Graphics windows.

* "Opaque standard widgets". (Edit boxes, buttons etc.)

* OpenGL target.

This is an even taller order. =) I don’t need a GUI here.

What I’m thinking about here is basically a Delphi remote terminal
implementation that can smack in native Windows widgets, as an
alternative to the primitive text “widgets” that I’ve already
implemented on top of my extended constream interface in the DOS app.

Hell, why not just implement a VNC server! That’ll get you a remote
console with complete text and graphics support under just about any
OS!

Yeah, I’ve considered that and similar solutions (like running an X
server on Windoze), but how about running it over RS-232, preferably
without blocking the real communication that goes on over the same
line, at the same time…? Does VNC support pure text modes?

(Old instruments don’t have NICs, and we’d like to be able to upgrade
them without entirely replacing the electronics.)

I can
direct output to the console my own way - in fact all output at
this stage goes either to Com_Printf or Sys_Printf anyway.

My problem is that the application needs some notion of "windows"
at the very least. If I just pipe everything to stdout, it’ll just be
a big mess - unless I disable some very useful debugging and testing
features… heh

I understand that. And I need a concept of a window too - for the
curses implementation at least. Need a status and edit line, so the
screen needs some division. I’m just intending to do that at a little
higher level.

Ok. That’s basically how conio + constream works; conio has only a “clip
rect”, which constream keeps moving around to simulate windows - although
without overlapping support. (If they overlap, it’s just “last move
wins”! :slight_smile:

Both are capible
of logging and other nice features.

That sort of stuff is actually much higher level than what I have in
mind for the actual “text screen emulation”. The closest feature I’ve
considered is windows with a virtual offscreen buffer, that may be
larger than the window.

nod I wouldn’t do that even at the lowest levels. I think the key
approach to making it work well is the layering.

Yeah - but in some cases, scrolling the whole screen, or an area of the
screen a few lines can be significantly faster than repainting the
whole screen. That’s why I want window support on the “conio” level
already.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 06 February 2002 02:00, Joseph Carter wrote:

On Wed, Feb 06, 2002 at 12:08:22AM +0100, David Olofson wrote:

Hi Everyone,

I’ve successfully been able to move a window to a
position I request (from the FAQ and reading the
archives :wink:

If there is anyone that could help me with the
following, I’d be forever greatful… I am currently
using the FOX Gui toolkit… I would love to be able to
use a SDL surface very similar to the way the GTK
widget was done, but believe that it is out of my
scope of knowledge on how to add it… is there
anyone out there that would be willing to help me
create a widget in FOX (www.fox-toolkit.org)?

Thanks,
Michael__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com

I just hacked up a preliminary API spec for the lowest level of the “text
console emulator” I’m about to hack. It’s documented and on-line:

http://olofson.net/download/conemu.h

No SDL_Surface target yet - I wanted to keep the basic API totally
independent of SDL and other libraries, as I might have to backport it to
DOS or something… heh

I’m going to add ce_open_sdl(SDL_Surface *screen, …) or something like
that… A similar approach could be used to render into a raw RGB or RGBA
buffer, for OpenGL and the like. (Actually, that would work with SDL as
well, to some extent!)

The API looks reasonably complete.

If it is to be used in-game though, attributes
are a necessity for me at least.

I’ll need them right away, as well as simple, non-overlapping text
windows, as that DOS app uses it a lot.

nod Understandable if you’re porting a dos program, it’s easier to
have different priorities since this is for new code here.

Yeah… But how about my proposed API? If I hack up the skeleton and a
rudimentary SDL and stdio implementations, could your implementation fit
in? (I’ll probably use some “backend plugin struct” internally, so you
just have to fill one in and add it to the list of targets. Would be nice
to know more about *curses before designing that, though.)

As I said, it looks reasonably complete. I do not know if I’ll be able to
use it or not yet. If not, I shall have to begin SDL_syscon in our CVS
tree. I will probably have to put it on sourceforge for the time being in
our existing CVS. (We’re leaving sourceforge for servers we have more
control of and which do not puke on multiple cronjobs each day… 'Course
the fun part starts when we get vickery online since we then get to test
out the (hopefully) quickly developed and stable infrastructure thing…)

But if say, mc works, can I assume that such operations will work? (Don’t
know how mc does stuff.)

Yes. If you are not depressed by the speed of mc on a given terminal, you
should be fine with other curses stuff on the same terminal.

Yeah, I’ve considered that and similar solutions (like running an X
server on Windoze), but how about running it over RS-232, preferably
without blocking the real communication that goes on over the same
line, at the same time…? Does VNC support pure text modes?

I was being somewhat facetious. No, vnc is graphics only, but it does
allow very nice remote graphics. Text is pretty easy since if your
terminfo is set right on the server, you can simply use curses.

nod I wouldn’t do that even at the lowest levels. I think the key
approach to making it work well is the layering.

Yeah - but in some cases, scrolling the whole screen, or an area of the
screen a few lines can be significantly faster than repainting the
whole screen. That’s why I want window support on the “conio” level
already.

I’ve found curses is at least that smart, if the terminal you’re using it
on is also that smart. Plain dos ansi.sys for example is not smart enough
to allow scrolling backward, so scrolling up in things like less are very
unbearably slow.On Wed, Feb 06, 2002 at 03:44:10AM +0100, David Olofson wrote:


Joseph Carter Sanity is counterproductive

If I have trouble installing Linux, something is wrong. Very wrong.
– Linus Torvalds

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020206/22226028/attachment.pgp

[…]

http://olofson.net/download/conemu.h

[…]

The API looks reasonably complete.

So did I think, but I forgot a few details! :slight_smile:

No major problems implementing it so far, though - except that using
scanf() semantics for any serious “command line” style stuff seems to
suck real bad, so I’m just going to leave it for now. (My DOS program has
it’s own editors anyway…)

[…]

But if say, mc works, can I assume that such operations will work?
(Don’t know how mc does stuff.)

Yes. If you are not depressed by the speed of mc on a given terminal,
you should be fine with other curses stuff on the same terminal.

heh Oh well, as long as I don’t try to run text mode scrolling
shooters, I’ll be fine. :wink:

[…]

nod I wouldn’t do that even at the lowest levels. I think the
key approach to making it work well is the layering.

Yeah - but in some cases, scrolling the whole screen, or an area of
the screen a few lines can be significantly faster than repainting
the whole screen. That’s why I want window support on the "conio"
level already.

I’ve found curses is at least that smart, if the terminal you’re using
it on is also that smart. Plain dos ansi.sys for example is not smart
enough to allow scrolling backward, so scrolling up in things like less
are very unbearably slow.

remembers the old days of running the SEKA assembler in AmigaDOS console
windows
:slight_smile:

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 06 February 2002 12:02, Joseph Carter wrote:

I have searched for an answer to this very question and would like to know
if anyone knows the answer. I tried ShowWindow(hwnd, SW_HIDE) but I need to
know how to get the console windows handle (hwnd). I am not mush of a win32
programmer.

Cheers!
Robin.> ----- Original Message -----

From: david.olofson@reologica.se (David Olofson)
To:
Sent: Monday, February 04, 2002 5:44 PM
Subject: Re: [SDL] Console and stdout under Windows

On Sunday 03 February 2002 23:01, Joseph Carter wrote:

On Sun, Feb 03, 2002 at 07:04:50PM +0100, Kresimir Cosic wrote:

Hi to everyone… I found something that could be of interest.

When “console application” project is made under VC, that annoying
console window appears. However, I have to use "console application"
to be able to
print to stdout correctly ( not to stdout.txt ).
It is possible to close that console window with
ShowWindow(console_hwnd,SW_HIDE)

I think you’ve already got the answer to your question, but IIRC wasn’t
there someone else here who was planning to work on an addon lib for
SDL for cross-platform server consoles? I recall a fair bit of
interest in the project (including my own), but don’t recall anyone
ever posting a link to code or a fledgling project busy creating it.

Uhm, I might have been involved in that discussion…

Either way, I’m going to start hacking it right away. (In fact, I started
last week!)

I need it for a port of a Borland C++/DOS application to Linux. The way
the application is using the screen, and the way it’s supposed to work
evntually (with this text screen in a window on a remote Windoze box),
makes it seem like the best way is to reimplement my extended version of
Borland’s “constream”. (Large part of it isn’t using control codes, so
it’s not a simple matter of translating codes into some real terminal
standard…)

Goals for my little project:

  • Simulated text screen. (More powerful than VGA, but similar
    design.)

  • Windows with clipping and scrolling.

  • Targets: SDL graphics console
    Real Linux console (limited to ANSI codes)
    VGA hardware text screen (not for normal apps!)
    Remote console via pluggable “link drivers”

  • Speed!!! :slight_smile:

Stuff that I don’t need right now, but will try to keep in mind:

  • Redirection of stdout to the simulated console.

  • Overlapping windows.

  • Graphics windows.

  • “Opaque standard widgets”. (Edit boxes, buttons etc.)

  • OpenGL target.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -’


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

You can’t using the default stuff. You need to modify and recompile the
SDL_main.c from the source and link it to your program manually.

-MarkOn Thu, 28 Feb 2002, Robin Forster wrote:

I have searched for an answer to this very question and would like to know
if anyone knows the answer. I tried ShowWindow(hwnd, SW_HIDE) but I need to
know how to get the console windows handle (hwnd). I am not mush of a win32
programmer.

Cheers!
Robin.

----- Original Message -----
From: “David Olofson” <david.olofson at reologica.se>
To:
Sent: Monday, February 04, 2002 5:44 PM
Subject: Re: [SDL] Console and stdout under Windows

On Sunday 03 February 2002 23:01, Joseph Carter wrote:

On Sun, Feb 03, 2002 at 07:04:50PM +0100, Kresimir Cosic wrote:

Hi to everyone… I found something that could be of interest.

When “console application” project is made under VC, that annoying
console window appears. However, I have to use "console application"
to be able to
print to stdout correctly ( not to stdout.txt ).
It is possible to close that console window with
ShowWindow(console_hwnd,SW_HIDE)

I think you’ve already got the answer to your question, but IIRC wasn’t
there someone else here who was planning to work on an addon lib for
SDL for cross-platform server consoles? I recall a fair bit of
interest in the project (including my own), but don’t recall anyone
ever posting a link to code or a fledgling project busy creating it.

Uhm, I might have been involved in that discussion…

Either way, I’m going to start hacking it right away. (In fact, I started
last week!)

I need it for a port of a Borland C++/DOS application to Linux. The way
the application is using the screen, and the way it’s supposed to work
evntually (with this text screen in a window on a remote Windoze box),
makes it seem like the best way is to reimplement my extended version of
Borland’s “constream”. (Large part of it isn’t using control codes, so
it’s not a simple matter of translating codes into some real terminal
standard…)

Goals for my little project:

  • Simulated text screen. (More powerful than VGA, but similar
    design.)

  • Windows with clipping and scrolling.

  • Targets: SDL graphics console
    Real Linux console (limited to ANSI codes)
    VGA hardware text screen (not for normal apps!)
    Remote console via pluggable “link drivers”

  • Speed!!! :slight_smile:

Stuff that I don’t need right now, but will try to keep in mind:

  • Redirection of stdout to the simulated console.

  • Overlapping windows.

  • Graphics windows.

  • “Opaque standard widgets”. (Edit boxes, buttons etc.)

  • OpenGL target.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -’


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Mark K. Kim
http://www.cbreak.org/
PGP key available upon request.

if you simply want to hide it (under gcc), add -mwindows at the end of gcc
line:

gcc -o YourSDLProg.exe YouSDLProgCode.c -lmingw32 -lSDLmain -lSDL -mwindows

Jocelyn.

“Robin Forster” <robin.forster at sympatico.ca> a ?crit dans le message news:
mailman.1014874637.8757.sdl at libsdl.org

I have searched for an answer to this very question and would like to know
if anyone knows the answer. I tried ShowWindow(hwnd, SW_HIDE) but I need
to
know how to get the console windows handle (hwnd). I am not mush of a
win32> programmer.

Cheers!
Robin.

----- Original Message -----
From: “David Olofson” <david.olofson at reologica.se>
To:
Sent: Monday, February 04, 2002 5:44 PM
Subject: Re: [SDL] Console and stdout under Windows

On Sunday 03 February 2002 23:01, Joseph Carter wrote:

On Sun, Feb 03, 2002 at 07:04:50PM +0100, Kresimir Cosic wrote:

Hi to everyone… I found something that could be of interest.

When “console application” project is made under VC, that annoying
console window appears. However, I have to use "console application"
to be able to
print to stdout correctly ( not to stdout.txt ).
It is possible to close that console window with
ShowWindow(console_hwnd,SW_HIDE)

I think you’ve already got the answer to your question, but IIRC wasn’t
there someone else here who was planning to work on an addon lib for
SDL for cross-platform server consoles? I recall a fair bit of
interest in the project (including my own), but don’t recall anyone
ever posting a link to code or a fledgling project busy creating it.

Uhm, I might have been involved in that discussion…

Either way, I’m going to start hacking it right away. (In fact, I started
last week!)

I need it for a port of a Borland C++/DOS application to Linux. The way
the application is using the screen, and the way it’s supposed to work
evntually (with this text screen in a window on a remote Windoze box),
makes it seem like the best way is to reimplement my extended version of
Borland’s “constream”. (Large part of it isn’t using control codes, so
it’s not a simple matter of translating codes into some real terminal
standard…)

Goals for my little project:

  • Simulated text screen. (More powerful than VGA, but similar
    design.)

  • Windows with clipping and scrolling.

  • Targets: SDL graphics console
    Real Linux console (limited to ANSI codes)
    VGA hardware text screen (not for normal apps!)
    Remote console via pluggable “link drivers”

  • Speed!!! :slight_smile:

Stuff that I don’t need right now, but will try to keep in mind:

  • Redirection of stdout to the simulated console.

  • Overlapping windows.

  • Graphics windows.

  • “Opaque standard widgets”. (Edit boxes, buttons etc.)

  • OpenGL target.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -’


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl