Re: Win32 TSR program skeleton
- From: "Chris Becke" <chris.becke@xxxxxxxxx>
- Date: Fri, 27 Jul 2007 11:34:48 +0200
I am sorry if I sounded at all condecending. That was not my intention.
Anyway, under windows a "comsole" is just a thing used for display. The
actual processes attached to, and displaying on a console, are multitasked.
It is just that the behaviour of "cmd.exe" is to physically block its own
execution until the last app it launched is finished.
If you run "debug.com" or any ms-dos type application inside a cmd.exe
session, it gets boxed up in a 16 bit virtual machine. Each ms-dos
application would get its own virtual environment, and those environments
are not avaible to Win32 apps, and are not created for Win32 console
applications. The memory address "B800:0000" is completely meaningless to
every application, ms-dos in a16 bit virtual machine, or native Win32
application on the system, except the specific instance of debug.com that
you are running.
<mpiceni@xxxxxxxxxxxxxxxx> wrote in message
news:%23AT7p7C0HHA.5152@xxxxxxxxxxxxxxxxxxxxxxx
Oh, sorry, maybe I make a mistake in programming my Delorian, is not 1987
today ???
Frankly speaking I don't work as a programmer, I'm a sysadmin. But
sometimes I wrote small programs for my needing. by know I only programmed
hi level in Windows, like Visual C++ or even scripting.
Uhm, I didn't think about named pipes. I'll make a try. Hope they work
also in WinPE (not sure).
Thanks Chris for your suggestion.
By the way, what I wrote makes sense. Windows is a multitasking OS, but
CMD console not. You can multitask several instances of CMD, but not
multitask several apps inside a single instance of CMD. CMD is a sort of
virtual Ms-Dos box, but at 32bit. If you run DEBUG and the D B800:0000,
you'll see what's on screen. Also old flawor TSRs works fine in Windows
CMD, but not in WinPE, cause it lacks 16bit support.
Thanks again.
Massimo.
"Chris Becke" <chris.becke@xxxxxxxxx> ha scritto nel messaggio
news:uoZCetC0HHA.4928@xxxxxxxxxxxxxxxxxxxxxxx
Where exactly have you been for the last, er, 20 years?
First up. There are no TSRs on windows. Windows is a multi tasking
operating system and has been since Windows 3.1 - To get the behaviour
you want, all you need to do is make a perfectly normal windows
application that creates a timer that fires off once per second.
forget everything you know about DPMI. About interrupts. And about DOS
tsr's None of that knowledge is relevent any more.
You also have to forget what you know about direct access to video
memory. B800:0000 is meaningless to win32 apps.
I think the best way to approach this problem under Win32 is to create an
application that launches the Win32 console progam in question, but set
the stdin and stdout handles to named pipe handles that your process
creates. You can then read the data stream as its generated without
polling.
If you have a Win32 development environment, you will hopefully have a
copy of the MSDN or Win32 SDK. In which case you should have access to a
microsoft sample program that does almost exactly what you need in an
article with the title "Console: Console Named-Pipe Sample"
<mpiceni@xxxxxxxxxxxxxxxx> wrote in message
news:u%23IdGZC0HHA.1164@xxxxxxxxxxxxxxxxxxxxxxx
Hi,
don't sure this is the right group, but I expect to find a lot of low
level programming gurus here...
I need to write a TSR that does some periodical checks over another
runnig Win32 console application. My old knowledge of DOS programmer
remind me about TSR and INT 08h hooking (system timer). The problem is
that my TSR need to be a 32bit application (because I need to run under
WinPE that doesn't support 16bit apps). I cannot find much documentation
about 32bit TSR. I only know that rely on DPMI and INT31h 0C01 function,
but cannot find much documentation on this.
Does anyone have experience on this and could provide a simple C++ (or
ASM) skeleton of such a TSR ?
To better explain what I need to do: I've a Win32 console program that
outputs events to the stdout, and I need to capture these events in real
time. You should say that I can simple pipe the output to my app, but,
unfortunately, this program outputs in realtime only when the output is
leaved on console. If redirected (to app or file), the output is
buffered to a 4K buffer and send to the redirect only when the buffer is
full. This means I'll have the events (in batches) several minutes after
the raising and this is not acceptable to me. My idea is:
1) run a TSR that get activated once a second
2) run the app leaving its output to console (no redirection)
3) my TSR, when activated, checks memory area B800:0000 (the console
screen) for modifications and makes something (still thinking about
what) if new output is found. By the way, I don't know if I can deal
with files inside a TSR. In pure DOS was not possible because of DOS
calls non reentrant. Not sure if in Win32 there's some way. As you
probably saw, I've good knowledge of low level DOS programming, but poor
on Win32 (I only used high level visual tools by now).
Thanks to anyone that could help.
Massimo.
.
- Follow-Ups:
- Re: Win32 TSR program skeleton
- From: Jan Bruns
- Re: Win32 TSR program skeleton
- References:
- Win32 TSR program skeleton
- From: mpiceni
- Re: Win32 TSR program skeleton
- From: Chris Becke
- Re: Win32 TSR program skeleton
- From: mpiceni
- Win32 TSR program skeleton
- Prev by Date: Re: Win32 TSR program skeleton
- Next by Date: Re: How to convert ANSI_STRING (or UNICODE_STRING) to UTF-8
- Previous by thread: Re: Win32 TSR program skeleton
- Next by thread: Re: Win32 TSR program skeleton
- Index(es):
Relevant Pages
|