From: vtailor AT gte DOT net
Subject: RE: Escape sequences
11 Jun 1998 19:58:05 -0700
Message-ID: <199806112105.QAA08235.cygnus.gnu-win32@smtp2.mailsrvcs.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
To: gnu-win32 AT cygnus DOT com
Cc: vtailor AT gte DOT net

>   Edward Avis (EPA AT datcon DOT co DOT uk)
>   Tue, 9 Jun 1998 17:35:54 +0100
>   
>>What I am getting at is that I believe that cygnus `bash' ought to come
>>up in its own xterm window, which is a `true' Windows window, and not a
>>Unix emulation layer grafted onto the Microsoft console.
>
>We already have xterm and rxvt ported to Cygwin32.  The problem is that
>many "badly behaved" applications which access the screen "directly"
>(and not just DOS programs; native Win32 text-mode things do it too)
>will not display in such windows.
>
>Any alternative to the Microsoft Command Prompt window would have to
>provide support for such programs.
>
I think you are confused here.  First of all, `real' Dos programs would
launch into their own _separate_ Microsoft console window, and will not
be the concern of the cygwinbxx.dll.  In fact, the Microsoft console
standard, in which programs overlay each other in one window, will go
away, to be replaced by Unix-style separate windows for each launched
application.

I went on a tour of cygwinb19.dll using the QuickView program in
the '95 Explorer, and I came up with the following assessment of
what it would take to cut the Unix emulation loose from the MSoft
console:

Basically, your DLL uses a subset of the MSoft console functions that
provide display and raw key (but not mouse) input.  This corresponds
to the slang library slw32tty.c, slgetkey.c and slvideo.c modules, and
nothing more, and I have already demonstrated that I can make that work,
mouse and all.  For this situation, the only parts of my libwstdio.a
library that would be used would be

(a) the console window initialization code that would be called from
crt0.o to a CYGNUS_WinMain function of the DLL.  This would set up
a Windows window, register it, and call the appropriate display
functions to make it visible.  It would also pass the WM_KEYDOWN,
WM_KEYUP, WM_CHAR, WM_LBUTTON_CLICK, WM_PAINT, etc., window callback
function to the appropriate Windows registration function.

(b) the getch(), putch(), fputs(...., stdout), and fputs(...., stderr),
KeyPressed(), GoToXY(), etc., code would be the only libwstdio code
that would be activated by the cygwin DLL, with the DLL actually handling
the identities of stdin, stdout, stderr, stdprn, stdaux, etc. and taking
over the other functionality of my library.

That means that the actual amount of object code that would be added
to the cygwinb19.dll would be somewhat less than 50 KB, perhaps no more
than 30 KB.


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".